なぜ、アジャイル開発なのか
アジャイルによる開発手法の採用が進んできた背景には、昨今のビジネスの不確実さ、変化の速さがある。そのビジネスをサポートするために、IT（情報システム）が積極的に変化に対応することが求められているのである。
従来のビジネスとITの関係
ソフトウェアは単独で存在するのではなく、それが製品に組み込まれたり、企業システムとして利用されたり、Webのサービスとして公開されたりすることでビジネスとつながっている。このビジネスの主体、そして、そのビジネスが対象とする市場（あるいはユーザー）、そして情報システム開発の主体（IT）、という3者の関係を表したものが図2‐1である。
図2-1 ゴール分割型ビジネス
従来の手法では、まずビジネスの主体が「市場分析」し、それを要求仕様書というドキュメントにまとめる。そしてそれをもとにITにシステム開発を「発注」する。ここまでが「行き」の流れ。その後、ITはその要求を満たすべくシステムを開発し「納品」する。そしてビジネス主体が納品されたシステムを市場へと「リリース」する。ここまでが「帰り」の流れである。この一周の往復に、半年から長い場合は数年かかるものもある。
これはコンシューマー向けのシステムの例だが、業務システムなど社内にユーザーがいるケースでは、「市場」を「ユーザー部門」、「ビジネス」を「IT部門」、「IT」を「ベンダー」と読み替えると、よりイメージが湧くかもしれない。
どちらの場合でも、ビジネスの主体（ビジネス、もしくはIT部門）と開発の主体（IT、もしくはベンダー）の間には発注と納品という手続きがあり、契約を介することになる。このような開発形態のどこに問題があるのだろうか
ゴールが分断され、要求が劣化する
図2‐2はスタンディッシュ・グループのレポートに掲載されているデータである。リリースされたシステムの機能のうち、まったく使われない機能が45%、ほとんど使われない機能の19%を足すと、何と3分の2が使われない機能だという。この数字を見ると、ほとんどの情報システム開発に携わる人たちは「うんうん確かに」とうなずく。日常的に身の回りで起こっている現象なのだ。私たちは、壮大なムダを日々作っている。では、なぜこうなるのか。
まず、1つ目はゴールがビジネスとITの間で分断される、という問題があるからだ。ビジネスはシステムを開発し、投資した以上の効果を上げることが目的である。ところが、ITは契約を満たすこと、すなわち「仕様通りのシステムを納品すること」が目的になってしまう。そうなると、両者の間で綱引きが起こる。ビジネスが「ここをこうしてほしい」というとITは「それは当初の仕様に書いてありません」と答える。ゴールが違うから、お互い自分の利益を追求してしまう。
さらに悪いことに、このようなやり取りが続くと、ビジネスは契約の最初にできるだけ多くの機能を仕様に盛り込んでしまおうと考える。後で追加を要求すると「別途、お見積させてください」という回答が返ってきてコストが高くなるからだ。こうなると、最初に要求仕様書をできるだけ大きく作り、それを固めて両者で合意する、ということになる。その結果、このようにほとんど使われない機能をたくさん作ってしまうのだ。
もう1つの問題は、開発にかかる時間だ。市場を調査してから実際にシステムが市場に投入されるまでの間に半年や1年以上の時間がたつと、もはや市場が動いてしまっている。例えば、競合他社の新機能リリース、法律の改定、ユーザーの嗜好の変化などによって、もともと狙っていた的がこの時間ロスの間にずれてしまう。この「要求の劣化」が問題の核心だ。ビジネスの旬を逃してしまった要求は、いくらうまく実装したところで使われない機能となってしまう。
要求の全体を満たすホールケーキの設計図をしっかり描いたにもかかわらず、できあがったときにはもうそのケーキを食べたいと思っている人がいなかった、ということになる。
ゴールを共有した開発
次に、アジャイルが目指す新しいビジネスの形を図2‐3に描く。
この図では、市場、ビジネス、ITの3者が入れ子になっている。ITのゴールは仕様を満たすことではなく、ビジネスとしての効果を上げることだ。そして、要求を実現してリリースするサイクルは、1週間から1ヶ月という短期。この間で実際に動くものを作って市場の反応を見る。
そして、次の優先順位を決めながら開発を進めることになる。このような開発手法は、Webのサービス開発、スマートフォンのアプリなどを考えると容易に想像できると思う。スピード重視なのだ。まったくユーザーからのフィードバックなしに1年間開発投資を続けることはありえない。これらのサービスでは、コアとなる機能を作って先にリリースしてしまい、市場やユーザーの反響を見ながら人気が出そうな部分を中心にさらに投資をする、という資金投入のやり方をとる。この分野ではアジャイル開発は最も自然な手法だといえるだろう。
しかし、アジャイル開発が広まっているのはこの分野だけではない。従来適用が難しいと考えられていた、通常の業務システム、基幹システム、組み込みシステムにまで、アジャイル開発は浸透し始めている。
アジャイル採用の動機は「スピード」と「変化への対応」
では、実際にアジャイルを採用した組織は、どういう目的を持っていたのだろう。
図2‐4は、アジャイル開発管理ツールを開発・販売しているVersionOne社が、2006年から毎年行っている調査の2020年における結果だ。ここでは、既にアジャイルを採用しているチームがその採用動機について答えており、「市場投入までの時間短縮」「要求の優先順位変更が可能」が上位にきている。これは、変化の激しいビジネスの現状から、スピード重視で製品やサービスを市場に投入する必要性、競合製品などの市場環境に応じて柔軟に要求の優先順位を変える能力の必要性を表しているといえる。
また、同調査によると、数あるアジャイル開発の方法論の中で、スクラムの占める割合が半分以上であり、スクラムとその他のハイブリッドを合わせると全回答者の77%がスクラムを採用しているという（図2‐5）。ここからも、現在のアジャイル開発の中でスクラムが主に採用されている事実がわかる。
本章のまとめ
- アジャイル開発が浸透してきた背景には、ビジネスの変化の速さがある。
- アジャイル開発では、ビジネスとITがゴールを共有する。
- アジャイル開発では、すばやくユーザーや顧客のフィードバックを得ることで、ムダな機能を作ることを防ぎ、市場投入のスピードを上げ、ビジネスの投資対効果を高める。
