アジャイル解説 – アジャイルが求められる理由とメリット／デメリット

はじめに

近年、アジャイルを導入するプロジェクトが増えています。

開発者とユーザが柔軟に連携しながら開発するアジャイルの考え方は1990年代中頃から登場してきました。
そして2001年に「アジャイルソフトウェア開発宣言」が提唱されると、スクラムやXPなど様々な開発フレームワークに取り込まれ、発展していきました。
先進的なチームや開発者で徐々に浸透し、今ではアジャイルが広く認知され、一般的に利用されるようになりました。

経済産業省が提供しているDXレポートにもある通り、デジタル産業を拡大するためには「ユーザ企業とベンダー企業の共創の推進」を挙げています。
そしてアジャイルはDXとも相性が非常に良いため、より活用する場が増えていくでしょう。

そこで、知らないでは済まされないアジャイルの基礎について解説していきます。

アジャイルとは

アジャイルとフレームワーク

アジャイルとは、素早く柔軟にソフトウェア開発するための概念を指します。
この概念はアジャイルソフトウェア開発宣言として４つの宣言と１２の原則によって構成されています。
そしてアジャイルソフトウェア開発宣言を実現するための様々な開発手法、フレームワークが存在します。
このフレームワークとして「スクラム」「XP」「カンバン」といった手法が有名ですが、それ以外にも多種多様のフレームワークが存在します。

アジャイルは概念であり、具体的な開発手法は別ということを理解しないと混乱することもあるので注意してください。

ウォーターフォールとアジャイルの違い

アジャイルと対を成すのがウォーターフォールです。
この２つの特徴を以下に整理します。

ウォーターフォール

ウォーターフォール開発では最初に何を作るのか要件定義で決定し、その内容に従って開発します。
何を作ればよいか明確であることが前提にあり、その開発作業を詳細化していくことで計画を立てやすくするのが特徴です。

このウォーターフォールが得意とするのは「既存業務のシステム化」という場合です。
既に存在する業務を要件ベースにするため、完成形のイメージもつきやすいです。
逆に何を作ればよいか不明確な場合は、多くの手戻りが発生することもあり不得意です。

ウォーターフォール型開発のプロジェクト管理については、こちらの記事「【基礎から学べる】プロジェクト管理の全体解説」を参考にしてください。

アジャイル

アジャイルの特徴として真に求める機能を作るため、短期間で動くものを作り、動作確認しながら改善を繰り返すことです。
繰り返し改善していくので、手戻りや仕様変更を行うことも含まれます。
戻り作業が無駄のように見えますが、この紆余曲折が大切です。

失敗も含めて多くの気づきを得て、それらを反映することがアジャイルの強みです。
これまで存在しなかった新しい業務やサービスを構築する場合にアジャイルは有効です。

逆に計画立ててプロジェクト遂行したくてもスケジュールやコスト計算が難しく、ウォーターフォールのような精度の計画を立てることは苦手です。

なぜアジャイルが求められるのか

業務効率化から価値創造へ

従来のシステム開発で求められていたのは、業務の効率を上げることを目的とするのが主体でした。
例えば生産管理システムや物流管理システムなど、既存業務をサポートすることが目的で開発します。
新しいツール導入や機能追加をする場合も、現在の業務を拡張することがメインでした。

この観点でシステム導入するだけでも企業としては十分に価値があったのですが、それら効率化するためのシステムは既に導入されており、さらに効率化する余地は少ないです。

そのような中、ITインフラの性能向上や、AI、IoT、ロボット、ブロックチェーンなどのデジタル技術を活用することで、従来までなかったサービスを創造するケースが増えてきました。
この流れは加速していき、従来の業務から変化できない企業は取り残されていくと思われます。

そのため多くの企業はDX（デジタルトランスフォーメーション）のように、デジタル技術を活用した新しい価値創造に取り組んでいます。
価値創造とは、新しい事業やサービスを作り出すことです。

価値創造と言っても何を作ればよいか答えがあるわけではありません。
そこで最初に何を作るのか決めるウォーターフォールではなく、試行錯誤しながら開発を進めるアジャイルが注目されています。

スピード感が要求される

上記で説明したように、新しい事業やサービスを提供することが求められるのですが、じっくりと時間をかけて開発する時間はありません。

先行者利益という言葉もありますが、時世や提供タイミングが重要になることもあるため、必要なサービスは１日でも早く提供することが求められます。

従来のシステム開発では早くて半年、長いと年単位という期間のプロジェクトもありますが、じっくり腰を据えて開発するのでは遅いです。
そこで一部機能だけでも早く提供できるような開発手法が求められています。

アジャイルのメリット／デメリット

メリット

変更に強く柔軟な対応ができる

アジャイルソフトウェア開発宣言に「計画に従うことよりも変化への対応を」というものがあります。
原則にも「要求の変更はたとえ開発の後期であっても歓迎します」とあるように、変更に対して柔軟に対応することが前提となっています。

実際に動く成果物を確認した結果、新しい気づきを得ることもあります。
これらを取り込むことで、より競争力のある機能を開発することができます。

もちろん何でも変更を取り込むという話ではなく、変更要求に対して本当に必要な対応なのか、また取り込む時期の調整などは行います。
ただ従来のウォーターフォールのように開発終盤に仕様変更を取り込むのとは非常に困難ですが、アジャイルでは変更の取り込みを想定したプロジェクト遂行のため、変更に向いています。

開発スピードが速い

アジャイル宣言の原則に「動くソフトウェアを、2～3週間から2～3か月というできるだけ短い時間間隔でリリースします」というのがあります。
とにかくスピード感をもって価値提供することを前提としているため、作るものを検討しながら開発を進めることが特徴です。
近年、クラウドのサービスや品質が向上しているため、それらを活用すれば簡単な機能は本当に短期間で開発することができます。

ただしアジャイルにすれば必ず早く開発できるわけではありません。
開発チームの能力や自己組織化されていること、そしてユーザ含めた協力体制が必要です。

ユーザのニーズに最大限応える

従来のシステム開発では、作ってみたが使えない機能やシステムというケースがありました。

ウォーターフォールでは、使い勝手を確認できるのがプロジェクト終盤になるため、実際に動かしたらイメージが違った、ということが発生します。

アジャイルでは短期間でユーザのフィードバックを受けながら開発するため、軌道修正など臨機応変に対応することで、本当に必要な機能開発につなげることができます。

デメリット

スケジュール、コストのコントロールが難しい

アジャイルでもスケジュールやコスト計画は立てます。
最初に想定する開発規模をもとにスケジュールの目安を立て、それに合わせてコスト算出を行います。
しかしウォーターフォールのように要件が決定しているわけでなく、また変更を取り込んでいくこともあるため「この期間、コストがあれば必ず成果が出る」と言い切れません。
とはいえ期間やコストは有限なので、その中で上手く成果物を出すためのコントロールが要求されます。

開発の方向性がぶれやすい

アジャイルは変更の取り込みを前提としているため、当初想定した成果物のイメージから離れていく可能性があります。
プロジェクト目的や期待されていることに向かって進んでいれば良いですが、しっかりプロジェクト管理しないと、方向性がぶれて何を作っているのかわからなくなる可能性があります。

開発メンバの変更が難しい

アジャイルのチームは自己組織化されていることが前提となります。
つまり各メンバが自立していることが前提であり、自主的に考えたりメンバ同士で連携することが求められます。

ウォーターフォールではリーダがメンバに管理、指示してプロジェクト遂行するため、メンバが変更してもリーダ指示により、それなりに対応することができました。
アジャイルでは新しくメンバが入ると、自立して活動できるまで慣れが必要になります。
ましてアジャイル未経験者の場合、いきなり自己組織化されたチームで活動することは無理なので、訓練や指導が必要になります。
そのためアジャイルチームを作成したら、極力、メンバ変更はしないことが大切です。

よくあるアジャイルの誤解

アジャイルについては認知度が上がっていますが、ヒアリングするとアジャイルを誤解している人がいまだに多いです。
この誤解を解かないまま学習しても、アジャイルを正しく理解することができません。
そこで、よくある誤解についてまとめてみました。

【誤解１】リーダやマネージャはいらない
ウォーターフォールではプロジェクトマネージャやリーダがメンバに指示を出して遂行しますが、アジャイルは自己組織化が前提となっています。
自己組織化により各メンバが率先して動くため、指示を出すリーダはいない、というものです。

確かにメンバ主体となって遂行しますが、プロジェクト目的に向かって進んでいるか確認し、必要あれば調整役に入るリーダは必要です。
また全体スケジュールやコストを管理するためのリーダも必要です。

【誤解２】アジャイルでは計画を立てる必要がない
アジャイル宣言の「計画に従うことよりも変化への対応を」から、アジャイルでは計画を立てないと考えている人がいますが、これは誤解です。

アジャイルでもプロジェクト計画書は作成します。
ただプロジェクト進行により、計画を厳守するのではなく柔軟に変更することが求められているだけです。

【誤解３】ドキュメントは作成しない
アジャイル宣言の「包括的なドキュメントよりも動くソフトウェアを」を誤解しているようですが、アジャイルでもドキュメントは作成します。
ドキュメントに優先順位をつけて、本当に必要なものだけを作るということが主旨です。

チームでシステムを作るので、機能間の仕様を口頭やメール、チャットだけで漏れなく連携することは出来ません。
またサービス開始後の運用で必要となるドキュメントもあります。

【誤解４】アジャイルにすれば、必ず早くリリースできる
アジャイルを導入したからといって、必ず開発スピードが上がるとはかぎりません。

素早く、有効な成果物を作成するには開発チームがアジャイルに慣れており、自己組織化していることが前提にあります。
各自で率先して考え、動ける開発メンバの集合体で構成されていることが、開発スピードを上げるポイントになっています。

アジャイルに慣れていない開発メンバだけでプロジェクト遂行しても期待する成果物が出てくるとは限りません。
チームが経験値を積んで成長することが必要です。

【誤解５】テストよりリリース優先
不具合があっても直ぐに修正するため、テストよりリリース優先することで開発期間を短くなると誤解している人がいます。
当然、アジャイルでも品質を確保する必要がありますし、不具合でサービス利用者に迷惑をかけるべきではありません。
サービス提供企業の信用低下につながります。

当然テストを実施するのですが、このテストに時間がかかるようでは素早いリリースは出来ません。
そのためアジャイルではテストを自動化するといった仕組みが必要になります。

【誤解６】アジャイルでは大規模開発は出来ない
アジャイルは小さなチームで遂行することが多く、スクラムでは3～9名のチームで体制を作ります。
そのため大規模開発には向いていないと言われていますが、近年は大規模開発でも導入されています。
「SAFe」という大規模アジャイル開発向けのフレームワークもあり、実際に多くの導入事例があります。

SAFeの導入事例については、SAFeの公式サイトを参考にしてください。