コンサルタントで作家でもあるScott W. Ambler氏は、2007年以来、毎年ITプロジェクトの結果に関する調査を行なっている。Ambler氏は調査結果とその評価を自由に利用できるようにしている。そのため、他の誰もがこの結果を使って、独自の分析を行うことができる。
Dr Dobbsの記事"実際のところ、ITプロジェクトはどの程度成功を収めるのか？"において、Ambler氏は2011年の調査結果の要約を掲載している。
Ambler氏は、最もよいアプローチを特定するため、プロジェクトの結果における"開発パラダイム"の影響を詳しく調べた。Ambler氏は5つのアプローチをこのように説明している。
アドホックなソフトウェア開発プロジェクトでは、チームは明確なプロセスに従いません。
イテレーティブなソフトウェア開発プロジェクトでは、チームはイテレーションやタイムボックスと呼ばれる期間で計画されたプロセスに従います。チームメンバーは毎日のように要件を収集し、設計し、コードを書き、テストする、といった活動を行います。イテレーティブプロセスの例はRUPです。
アジャイルソフトウェア開発プロジェクトでは、チームは軽量で、コラボレーションを重視し、自己組織化され、品質にフォーカスしたイテレーティブプロセスに従います。アジャイルプロセスの例としては、OpenUP、Scrum、XPなどがあります。
伝統的なソフトウェア開発プロジェクトでは、チームはまず要件を特定し、その後アーキテクチャや設計を定義し、次にコーディングを行い、次にテストを行い、その次に本番環境に配置するといった、段階分けされたプロセスに従います。伝統的なプロセスはよく"ウォーターフォール"や、単に"シリアル"プロセスと呼ばれます。
顧客価値にフォーカスした考え方や哲学は、リーンと呼ばれます。リーンプロセスは、時間、品質、コストの浪費を最小限にしつつ、顧客の価値を最適化するための努力を継続的に行います。最終的に、リーンの行き着く先は学習組織の開発です。リーンの方法やプロセスの例は、KanbanやScrumbanなどです。
Ambler氏は調査結果の分析において、成功したプロジェクト、課題があるプロジェクト、失敗したプロジェクトを次のように定義した。
この調査では、ソリューションが納品され、その組織の許容できる範囲の成功基準を満たしている場合、そのプロジェクトは成功したとみなしました。ソリューションは納品されたものの、チームがそのプロジェクトの許容できる成功基準を完全に満たさなかった場合(例えば、品質に優れ、ほぼスケジュール通りに進んだが、ROIがとても低い)、そのプロジェクトは課題があるものとみなしました。プロジェクトチームが全くソリューションを納品出来なかった場合、そのプロジェクトは失敗とみなしました。将来の調査では、ステークホルダの意見が完全に一致して意図的にキャンセルされたプロジェクトは除外するように、失敗の定義を見直すつもりです。
これらの定義を用いて、Ambler氏は次のような結果を見出した。
- イテレーティブアプローチとアジャイルアプローチは、統計的には同程度の成功率でした。イテレーティブプロジェクトは69%が成功、25%が課題あり、一方のアジャイルプロジェクトは67%が成功、27%が課題ありでした。
- 伝統的なアプローチ、アドホックなアプローチを採用しているチームも、統計的には同程度の成功率でしたが、アジャイルやイテレーティブなアプローチを採用しているチームよりも、成功率は低くなりました。伝統的なアプローチでは50%が成功、36%が課題あり、アドホックなアプローチでは49%が成功、38%が課題ありでした。
- リーンプロジェクトの62%が成功、30%が課題ありで、アジャイル／イテレーティブと伝統的／アドホックの中間でした。
さらに、プロジェクトの成功に寄与する様々なファクターと、使われたアプローチとの関係について分析している。Ambler氏は次のような多次元構造としてプロジェクトの成功をとらえている。
- 時間／スケジュール: 20%はスケジュールに従い、予定通りの納品を求めます。26%はシステムの出荷準備が整った時点での納品を求めます。51%は両方が同じように重要であると言っています。
- 投資利益率(ROI): 15%は予算内での納品を求めます。60%は投資利益率(ROI)のよさを求めます。25%は両方が同じように重要であると言っています。
- ステークホルダの価値: 4%は仕様通りにシステムを構築することを求めます。80%はステークホルダの実際のニーズを満たすことを求めます。16%は両方が同じように重要であると言っています。
- 品質: 4%はスケジュール通り、予算内の納品を求めます。57%は容易に維持できる高品質のシステムを求めます。40%は両方が同じように重要であると言っています。
Ambler氏は使われた開発アプローチと各次元の結果を比較し、最終的に次のようにまとめている。
繰り返しますが、この調査では、アジャイルソフトウェア開発、イテレーティブソフトウェア開発が、伝統的戦略やアドホックな戦略に比べてより成功率が高いという結果が得られました。これは前回の調査と一致しており、アジャイル戦略の採用に対するITコミュニティにおける一般的な傾向の説明にもなっていると思います。
Ambler氏だけが、プロジェクトの成功についての調査を行なっているわけではない。最も一般的なのは、Standish GroupのChaos Surveyで、時間通り、予算通り、スコープを満たすというより限定的な成功の定義を用いている。最新のStandish Group Chaos Reportは、2011年3月に公開されている。Standishの会長、Jim Johnson氏はこのように述べている。
"今年の結果は、これまでのCHAOS Researchの歴史の中で成功が最も多く、我々はプロジェクトの成功／失敗理由の再認識に入っています。"
Ambler氏の成功の定義は正当なものだろうか？そして、Ambler氏の調査結果はあなたの組織の現実を反映しているだろうか？
この調査への参加は自己選択である - 結果への影響はあるだろうか？
著者の Shane Hastie はアジャイルの指導者であり、オーストラリアとニュージーランドでソフトウェア教育に従事しているコンサルタントでもある。