梗概
現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。
品質（Q）、コスト（C）、納期（D）のトレードオフ関係
第4回では、アジャイルについてよく誤解されるテーマの1つである「文書化」について解説しました。今回は根深い誤解がみられるもう1つの最頻テーマ、「品質」についてひも解いていきます。
なお、「品質」といった場合の対象には大きく2つあり、1つ目は作成されたものが仕様通りに安定して動くという意味（生成されたシステムの品質）、2つ目は、システムの仕様を決定する元となる要求自体が安定し、完全性があるという意味（要求自体の品質）です。このうち2つ目については、これまでに触れてきた通り、アジャイルではスプリント（反復）ごとに実施するデモを通じて得られたフィードバックを基に軌道修正を図ることで、要求の品質向上を図る仕組みがプロセスに組み込まれており、その優位性は明らかでしょう。よって、ここでは1つ目の「生成されたシステムの品質」に主眼を置いて解説します。
筆者の推測では、「アジャイル（俊敏な）」という言葉から、「アジャイルは確かに早く開発できるのかもしれないが、早さを優先する結果、品質が犠牲にされ、その点ではウォーターフォールに劣るのではないか」という連想をされている方が非常に多いように思います。別の言い方をすれば、ある一定の品質を確保するために必要な工数が、ウォーターフォールとアジャイルで同じであるという前提に基づき、アジャイルでは「そこの工数を削る（その分出来上がりは早い）」、という理屈なのだと思われます。この誤解を解くためには、両者の「品質（Q）」「コスト（C）」「納期（D）」に関する根本的な考え方の違いを押さえる必要があります。
従来のウォーターフォール方式では、まずシステムが満たすべき全ての要求を洗い出し、それらの要求を実現するためにどの程度のコスト（C）と納期（D）がかかるのかを見積ります。この方式の問題は、大きく2つあります。1つ目は第2回で見たように、何といっても要求自体の確度が低いプロジェクト初期の段階で、正確にコスト（C）と納期（D）を見積もることは至難の業であるということ。2つ目は、1つ目の難しさがあるにもかかわらず、ビジネス上その他の理由からコスト（C）と納期（D）を固定し、さらに、出来上がったシステムが使い物にならないと困るので品質（Q）も固定してしまえ、となるわけですが、このような方程式が成立しないことは容易に想像できるでしょう。
品質（Q）を確保するためにはレビューやテストなどの工数をかける必要があり、コスト（C）と納期（D）とはトレードオフの関係にあります。つまり、満たすべき要求の数（量）が一定という条件の下、後者2つを固定した状態で何か想定外のことが発生した場合（実際、システム開発では往々にして想定外のことが起きるわけですが）、やむを得ず品質（Q）を調整弁とすることが開発チームにとって唯一の窮余の策となってしまうのです。
一方のアジャイル方式では、あらかじめコスト（C）と納期（D）を固定し、その制約内で実現可能な要求がどの程度かを見積もります。つまり、優先度の高い要求から実現していくことで、品質を最優先しつつ、ユーザーにとっての価値（実現される要求の数または量）を最大化していくという考え方です。
このように書くと、アジャイルではユーザーが必要としている機能が充足されていない印象を持つかもしれませんが、システムで実際に使われている機能は全体の20％程度であり、64％はなくてもほぼ困ることはない、という米国の調査会社Standish Groupによる調査結果があります（図1）。これは有名な「パレート原理（20％の機能が80％の使用率を占める）」とも整合性のある結果といえます。
（図1）システムが提供する機能の利用度（出典：Standish Group Study Reported in 2000 Chaos Report）
