「アジャイル vs ウォーターフォール」からプロジェクト管理を考える

現在の日本におけるアジャイルとウォーターフォールの捉え方は「欧米ではアジャイル型開発が一般的になっているのに日本はいまだウォーターフォール型開発が主流である。アジャイル型開発は欧米の競争力の源泉であり、日本も早急にキャッチアップせねばならない」というものでしょう。¹

典型的な出羽守論法のようにも思いますが、重要なのはそれが事実か否かです。欧米でアジャイル型開発が一般的になっているというのは事実なのか、また、アジャイル開発が欧米の競争力の源泉になっている、すなわちウォーターフォールよりも優れているのか。

個人的にサーベイ論文を中心に 40 本ほど文献を読んだので、それらの紹介も兼ねて、プロジェクト管理について考えたことを紹介してみようと思います。²

欧米ではアジャイル開発が主流になっているのか？

欧米でウォータフォール開発よりもアジャイル開発が主流になっているとする論拠は概ね下記の情報が元になっているようです。

• Gartner「Results Summary:Agile in the Enterprise」
• Digital.ai「State of Agile Report」
• Forrester「Agile Development: Mainstream
  Adoption Has Changed Agility」

ウォーターフォール開発との比較という意味では Gartner の資料 14 ページにある割合を見るのがよさそうです。これによると 47% がアジャイル型開発、41% がウォーターフォール型開発となっており、たしかにアジャイル開発こそが最も利用されている開発手法であることがわかります。

とはいえ、ウォーターフォールがまだまだ大きなシェアを占めていることも伺えます。もし、今や欧米ではウォーターフォールなど採用する会社はない、などの言説があるならば、それ言い過ぎでしょうし、"Excludes ‘Don’t know’" と書かれているのも気になります。回答できない企業が、新しい考えであるアジャイルを積極的に導入しているとみなすのは無理があります。

もうひとつ、（後ほども出てくる）産業界特有のバイアスも気になります。どの企業も新技術の採用に積極的であるとアピールしたいと考えているはずです。ほとんどウォーターフォール型開発なのにバックログと朝会の実施をもってアジャイルをやってますと言っているのかもしれません。事実、D. West 2011 "Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today" によれば現実のアジャイルでは既存のプロジェクト管理とハイブリッドされた形で導入されているという報告もあります。

そうはいっても、欧米でアジャイルがかなり普及していることは否定しようのない事実だと言ってよいとは思います。

では、日本ではどうなのか？

日本に関しては IPA「ソフトウェア開発データ白書2018-2019」に調査結果が掲載されています。さてその割合は……

なんと、ウォーターフォールが 97.4% です！

IT技術者の世界では、あれだけ「アジャイル！、アジャイル！」と言われているのにびっくりする数字です。この数字、高すぎるきらいはあるものの、別の観点から見るとそれほど不思議でというわけでもありません。

同じく IPA が公開している「『グローバル化を支えるIT人材確保・育成施策に関する調査』概要報告書」に掲載されている「IT人材の動向：各国のIT技術者数（p.22）」を見てみましょう（順番は入れ替えてあります）。

	日本	米国	中国	インド	ベトナム	韓国	ロシア
ITサービス企業IT技術者数	771,426	941,410	1,452,000	1,446,809	49,024	128,000	100,000
ユーザー企業IT技術者数	254,721	2,362,300	554,069	365,416	49,669	104,732	124,170

日本ではユーザー企業で働いているITエンジニアが全体の 25% にすぎないのに対し、アメリカでは 72% です。ユーザー企業が自社でエンジニアを抱えて開発するのであれば、アジャイル開発が中心になるのは自然な流れです。

また、この傾向があるのはアメリカだけで、他の国ではせいぜい半分程度であることもわかります。欧米におけるアジャイル開発の採用率の高さは、競争力の源泉であることを示しているわけではなく GAFA のような SaaS 企業や Microsoft、Oracle に代表されるソフトウェア製品の販売企業が産業の中心にいるという逆の因果関係によるのかもしれません。

アジャイル型開発はウォーターフォール型開発よりも優れているのか？

コスト、期間、品質に関して、あるモデルが他のモデルよりも優れていることを裏付ける経験的な証拠はほとんどない

これは「A comparison of software cost, duration, and quality for waterfall vs. iterative and incremental development: A systematic review」からの引用です。

品質に関しては多少議論があるものの、基本的にはどのサーベイ論文でも同様の結論です。ただし、この最大の理由は学術的な判断に使える品質の高い研究がほとんどないことに起因していることも記載しておかなかればなりません。「A critical examination of recent industrial surveys on agile method usage」では次のように指摘されています。³

実務家や研究者は、ここ数年でアジャイル手法が主流になったと主張することが多い。この主張を裏付けるために、彼らは最近の産業調査を参照し、アジャイル手法の使用率が高いことを報告する傾向がある。しかし、これらの産業調査の多くは、アジャイルコンサルタント、ツールベンダー、専門家協会、独立した技術・市場調査機関によって行われている。このことは、起こりうる利益相反や、これらの調査の全体的な信頼性について、いくつかの重要な懸念をもたらします。……ほとんどの研究は報告の徹底性が不十分であり、信頼性が低い

確実なことは言えないとはいえ、少なくとも現時点では「アジャイル型開発はウォーターフォール型開発よりも優れている」という言説に根拠はないと考えるべきでしょう。もっと実証研究が増えればアジャイル型の優位性が明らかになるということもできなくはないですが、（少数の事例に基づくとはいえ）現時点で実施済みの実証研究からは優位性が見つからなかったのも事実です。

では、アジャイル型開発とウォーターフォール開発にまったく違いはないのでしょうか。報告内容を見ていくと一定の傾向はあるようです。

• 総工数は変わらない（同じ機能を作るには同じ工数、期間がかかる）
  • 総工数は変わらないが開発者の生産性は上がる傾向があり書かれたソースコード量は増えるとのこと。詳細は書かれていないのでわかりませんが、テストコードなどが含まれているのかもしれません。
  • アジャイル型開発での生産性改善は、不要な機能やドキュメントを作らないことに起因していると言う報告があります。
• アジャイル型の方が品質が高くなるという報告も多い
  • 一方で、テスト工数が増えた分、要求定義や設計への割当が少なくなり、デザインやアーキテクチャに関する議論が十分に行われにくいという指摘もあります。例えば、UI の一貫性などはウォーターフォール型開発の方が有意に優れていた、ことが報告されています。
  • 技術的課題ばかりが先行してしまい、プロジェクト課題の解決が遅れてしまう、という問題も指摘されています。
  • アジャイル型開発をする場合でも、プロジェクトの目的設定やグランドデザインの設計は明確に工程を取って実施した方がよいようです。
• アジャイル型の方が顧客満足度、開発者の仕事への満足度を引き上げる
  • 一方で、顧客は、開発側の文化に馴染めない、役割に疲れを感じているとの報告もあります。開発者の中にもペアプログラミングは集中を要し疲れると報告する人がいます。
  • 実案件では、顧客も本業を抱えており関与できる時間が限られているケースも多いことを考えれば、アジャイルの特徴が生きるかは案件次第とも言えます。
• アジャイル型の方がメンバーのスキルや能力への依存度が高い
  • アジャイル型の成功にはスキルや人間的、社会的要因が重要であるとの報告が多いようです。管理職によるサポート、手厚いトレーニングも必要とされています。
  • 現在、ウォーターフォール型の開発で行われているように、人を投入して力技で解決するという方法論はより難しくなる可能性があります。
• アジャイル型の導入には組織的なコストがかかる
  • 一時的なビジネスの停滞、文化の衝突による退職の増加などがあり、必要な労力を過小評価すべきではないという指摘がされています。
  • チーム内のコミュニケーションは改善されたが、他のチームからは孤立していると認識されていたと言う報告があります。

これを読んで頂ければわかるように、アジャイル型開発の利点として喧伝されていることはある程度真実です。反面、同じ特徴が弱点に繋がっていることもわかります。

アジャイル型開発はいつ使えばよいのか

ウォーターフォール型開発でもアジャイル型開発でも結果が同じなら、今まで通りウォーターフォール開発を使い続けても良いはずです。では、どのようなときにアジャイル型開発を選ぶべきなのでしょうか。

私はこの問題を「なぜ、アジャイル型開発は必要とされたのか」という観点から捉えるべきだろうと考えています。

ウォーターフォール型開発の問題点とは

ウォーターフォール型開発は誰もが実施したことがあるが故に、誰もがひとつぐらい不満を持っています。しかし、それは本当にウォーターフォール型開発の問題なのでしょうか。政府や企業内部の業務改善プロジェクトを見るとたいした成果がなく終わっているものも多くないでしょうか。そういったプロジェクトはソフトウェア開発と違って結果が見えにくいだけで実際には失敗しているのかもしれません。

そもそも、プロジェクト自体が難しいのではないでしょうか。プロジェクト管理に銀の弾丸はありません。開発手法の選択自体、プロジェクト活動の40%にしか影響を与えていないという研究結果もあります。40%しか影響を与えない要素でプロジェクトの成否のすべてが決定づけられるはずはありません。

本記事を書くに当たり、プロジェクト管理の歴史やサーベイ論文を調べたのですが、面白いことがわかりました。

現代的なプロジェクト管理手法の歴史を振り返ると、1980年代までは決定論的なプロジェクト観に基づいて論文が書かれていました。すなわち、プロジェクトの成否を左右する要因（因子）があり、その中の決定的要因さえ管理していれば、QCD（品質、コスト、納期）が守られ確実にプロジェクトを成功に導くことができる、という決定論的な考え方です。

しかし、この考えはうまくいきませんでした。まず、決定的要因というものが見つかりません。たとえば「Success factors of project management: The critical few - An empirical investigation」という論文では「8つの要因すべてがプロジェクトの成功に有意に関連」していることが報告されています。そして、因子とされる要素自体も徐々に増えていきます。

増えていくのは因子だけではありません、プロジェクトの成功を図る指標も追加されていきます。当初は QCD だけでしたが、まず顧客満足度が追加され、エンドユーザーやステークホルダーの満足度、そしてクライアント企業やビジネスの成功も追加すべきであるという議論が行われています。例えば PMBOK では顧客満足度は成功の指標に含まれており、最新の第7版では成果物から価値提供に焦点が移っています。もちろん、プロジェクト管理の成功とプロジェクトの成功は分けるべきであるという議論もありますが、その境界線は明確ではありません。

実のところ「Project Success as a Topic in Project Management Journals」の最後に引用されている抽象的な文章が本質なのかもしれません。

カオス、変化、不確実性、コントロールの緩和を、コントロールを得るための手段として受け入れる、量子的な世界観である……プロジェクトマネジメントとは、ビジョンを現実に変えるための芸術と科学である

プロジェクト管理を成功因子と成功基準から分析する取り組みは破綻しているように見えます。プロジェクトの成否を左右する要因は、プロジェクトを取り巻くあらゆる不確実性であり、プロジェクト成功の判断はその不確実性がすべて現実の何かに落とし込まれたことであると判断せざるを得ません。⁴

そして、このことがアジャイル型開発の必然性に繋がっています。

実は、ウォーターフォール型開発の問題はそれほど多いわけではありません。主要な問題は次の２つに集約されます。

1. 要件決定から受入テストまでの期間が長過ぎ、要件の変化に対応できない
2. 開発の遅れがテスト期間の短縮に繋がり品質が犠牲になる

この問題はまさにアジャイル開発で解決されるものです。しかし解決方法はひとつとは限りません。単にプロジェクトを分割するだけで解決するかもしれません。

ウォーターフォールは一方通行であり、戻れないと言われることもありますが、ウォーターフォールの元になった Royce の論文の図は双方向的であることが見て取れます。これは現実のウォーターフォール型開発でも同様です。

一方、次の条件下ではウォータフォール型開発の方が適していることがわかっています。

• 初期のユーザー要求が明確で、プロジェクトの目標も明確で、不確実性のレベルが非常に低い
• プロジェクトのどの時期にも正式な文書化が必要

そんなプロジェクトはほとんどないのだからアジャイルで良いのだという見解を聞くこともあります。しかし、業務システムの世界では、業務自体が変わるわけでもなく、過去数回の更改を経た現行システムがEOSLや技術的な陳腐化を起因として再構築されることがよくあります。この場合、不確実性とは現行システムを理解していないことで、要件の変化が起こるわけではありません。必ずしも文書化が必要なくとも、一定の社内外の基準の監査⁵や外部システムとの調整が必要なため、都度リリースすることが難しいシステムもあります。

不確実性が高いからと言ってアジャイル型開発にすれば解決するというものでもありません。いくら価値提供を重要な指標としておいたところで、顧客の要求が「ヒットするゲームを作ること」ならば、確実に達成する方法が存在しないことは明らかです。

アジャイル開発を使えば、ビジネス価値を提供できるという意見もあります。しかし、顧客要望に応え続けたとしても、顧客満足度や価値提供を高めることができる保証はありません。ヘンリー・フォードは「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう」と言ったとされますが、ビジネス価値を提供するのは創造性です。特定の開発手法に従えば創造性が産まれるという発想は安易に思えます。

アジャイル型開発にせざるを得ないとき

アジャイル型開発の優位性が明らかでない以上、すべてをアジャイルにするという発想は危険です。しかしながらアジャイル型開発が不要でないのも明らかです。伝統的なウォーターフォール型開発だと困る状況が実際にあるからこそ、アジャイル型開発に注目が集まっているわけですから。⁶

では、その状況とは何でしょう。やはりそれは各国のユーザー企業IT技術者数の比較の際に触れた産業形態の変化です。ハードウェアに付属するソフトウェアや業務システムのように一回リリースすれば、当面変更する必要がない（せいぜい不具合にパッチを当てればいい）時代から、SaaS を中心としたエンドユーザに価値を提供し続けなければならない時代に変わってきました。

「継続的なデリバリーとフィードバックが重要で、要件が十分に定義されておらず、市場投入までの時間がフル機能バージョンのリリースよりも重要な場合」にはアジャイル型開発が適しているとされています。

プロジェクトの定義が「有期で目的のある」ものとするならば、このような要件に応えられないことは明らかです。アジャイル型開発は、プロジェクト管理手法ではなく、プロダクト管理の手法だと捉えるべきなのです。

ウォーターフォールしか開発手法が知られていないような数十年前であっても、パッケージ開発の現場では定期的な課題の棚卸しと優先順位付けは当たり前のように行われてきました。アジャイル型開発はソフトウェア開発の中心がビッグバンリリース型から継続リリース型に変わってきたことに起因していると考えられます。

では、それ以外のプロジェクトは引き続きウォーターフォール型開発を採用すべきなのでしょうか。しかし、それでは前述のウォーターフォール型開発の問題は何も解決されないことになります。

ハイブリッド・アプローチという折衷案

アジャイル型開発に欠けているもの

XP、スクラム、かんばん、といったアジャイル型開発手法がカバーしている範囲を PMBOK が提供している範囲と比較してみれば、従来型のプロジェクト管理手法でカバーされていた多くの要素が欠けていることにすぐ気付くはずです。これは、アジャイル型開発手法がプロジェクトではなくプロダクトを主眼においていることの査証でもあります。

アジャイル型開発には、組織的なインターフェース（調達・契約手続き、下請け管理、エンタープライズリソースプランニングなど）への考慮が明らかに欠けています。スコープ管理も十分とは言えません。顧客との対話次第とはいえ、変化を擁護するが故に、不適切なスコープ拡大を放置してしまうかもしれません。⁷ステークホルダー管理はどうでしょう。チーム内のプラクティスに注力するあまり、外部との摩擦が発生するかもしれません。

（私が普段関わっている）大規模基幹系システムを想定した場合に気になるのは、外部システムや他社とのインターフェイス機能のリリースタイミングの管理です。いつ開発が終わるかわかりません、タスクが溢れたので次回のリリースに先延ばししますではスケジュールが確定ができず困ってしまいます。顧客満足を最大化と言うのであれば、コストと納期を守ることだってその一部であるはずです。

アジャイル型開発には、ソフトウェア開発の外部を管理するための枠組みが提供されていません。外部の重要性が低い小規模なソフトウェア開発であれば問題ありませんが、複数のチームや部署がからむ中規模以上のプロジェクトには不十分です。

Water-Scrum-Fall

Forrester の調査結果を分析した Dave West は、現実のアジャイル実装がウォーターフォールとのハイブリッドにより構成されていることに気付きました。彼はこれを元に「Water-Scrum-Fall」という概念を提唱しました。

ビジネス分析やリリース管理など、自分たちがコントロールできない領域では、従来型のアプローチを取り、スクラムの採用は開発チームレベルに限ります。コンプライアンス要件は、開発の前後に強力なガバナンスプロセスを要求するため、SaaS ベンダではない通常の企業においては自然な導入の仕方でしょう。

ウォーターフォールとスクラムを組み合わせる場合には、次のことが推奨されています。

• ドキュメントは、問題領域を明らかにし全体計画と開発作業を開始できる程度のものに留める
• ソフトウェアの提供に必要となる人がすべてチームに加わるようにする
• 本番環境へのリリースの頻度を上げる

このアプローチをとることで「開発の遅れがテスト期間の短縮に繋がり品質が犠牲になる」ことは防げそうです。しかしながら、要件の変化に十分対応できないことは明らかでしょう。ソフトウェア開発が主業務ではない会社のプロジェクトでは、請負契約で開発範囲が明示されているはずです。要件の変化に対応するには、請負契約の見直しが必要になります。請負契約ではなく準委任契約でプロジェクトを進める、プロジェクトを分割する、いずれかの方策を取るのでなければこの問題への解決は難しいと考えられます。

また、このアプローチが有効であるという根拠が現状あるわけではありません。品質が犠牲になることは防げるかもしれませんが、アジャイル型開発の抱える弱点がプロジェクトを失敗に導くかもしれません。

とはいえ、SaaS 型ではないいわゆる SI 企業がアジャイル型開発を導入するのであれば、現実的な落とし所にはなりそうです。

クリティカル・チェーン・プロジェクト・マネジメント（CCPM）

アジャイル型開発の影に隠れてしまっていますが、タスクの作業時間の不確実性を低下させるもう手法として CCPM があります。これは、「ザ・ゴール」で知られるゴールドラッドが制約条件の理論（TOC）の理論をプロジェクトマネジメントに拡張したものです。リーダーシップ、プロジェクトガバナンス、コミュニケーションなどの側面は含まれていません。

アジャイル開発の流行により淘汰されつつある RUP やプロトタイピングとは異なり、スケジューリングの不確実性を低減させる手法として地味に生き残っており、ウォーターフォール型開発やアジャイル型開発と組み合わせて使うことができます。

理論的な有効性は示されていますが、実際の効果についてはいまだ議論があるようです。

結局、どの開発手法を選べばいいのか

あなたが SaaS ベンダやソフトウェア製品の開発ベンダにいるのであれば迷うことはありません。アジャイル開発を選びましょう。

そうでない場合はどうすれば良いでしょうか。

ウォーターフォール型開発であろうとアジャイル型開発であろうと、総工数に変化がないという事実を踏まえると、ある予算と納期、品質目標が与えられたとき、標準的なプロジェクトメンバーの元で実現可能な機能の上限というのはある程度決まると思って良いでしょう。その範囲に収まるのであれば、どちらの開発手法を取ったとしても（顧客満足はわかりませんが）QCD は達成しプロジェクトは無事完了することができるでしょう。

問題は、何らかの不確実性の結果、その範囲を超えてしまった場合です。リリースタイミングの制約がなく、準委任契約が結べるのであればアジャイル開発が好ましいでしょう。しかしながら、顧客はそれを良しとすることは少ないはずです。請負開発において顧客は要件を増やすインセンティブがあるように、準委任契約では開発側に目標を達成するインセンティブが希薄になります。

ウォーターフォール型を選んだ場合には品質が犠牲となり、その品質が著しく低い場合、予算と納期も犠牲にせざるを得なくなります。アジャイル型開発とウォーターフォール型開発のハイブリッドを選んだ場合には、要件は完全に満たせなくとも動くものができているはずですから、とりあえずリリースできる可能性が上がるかもしれません（顧客のリリース判定基準次第ではあるでしょうが）。

いずれにしろ、請負開発を前提とするのであれば、「不確実性の結果、予定されていた開発範囲を超えてしまう」ことを防ぐのが一番です。

プロジェクト失敗の要因の多くは「予算・納期見積りの失敗」、「不安定な要件」にあるとされています。

できる限り情報を集め見積り精度を上げる、プロジェクトの目標を明確にする、プロジェクトを分割し不確実性を小さくする、そういった活動の方が開発手法選択よりも重要なのかもしれません。

1. 例えば、IPA 非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査 にはそれが背景であると書かれています。 ↩

2. 私自身はプロジェクト管理の専門家でも研究者でもないため、文献の選択が恣意的になっている可能性は否定できません。この論文を読めば意見が変わるはずなどあれば教えていただけると幸いです。 ↩

3. 同様の指摘は、K. Dikert 他 2014 "Challenges and success factors for large-scale agile transformations: A systematic literature review"、T Dybå 他 2008 "Empirical studies of agile software development: A systematic review" にも見られる。 ↩

4. 一見、曖昧で役に立たない定義のように思えますが、プロジェクトマネージャーの行動指針としては非常に有用なのではないかと感じています。曖昧な要素を確定させていくのがプロジェクトマネージャーの役割です。 ↩

5. モトローラ社での事例では、ペアの人間がシステム全体への影響をすべて考慮することは不可能であり、ペアプログラミングではコーディング時のミスをすべてなくすことはできないため、さまざまな立場の開発者が参加するレビューで補完する必要性が述べられている。 ↩

6. 逆に言えば「プロジェクトの成功率を上げたいからアジャイル型開発に転換が必要」などと考えてはいけないということです。 ↩

7. Barry Boehm "Get Ready for Agile Methods, with Care" では、多くのソフトウェア災害の原因として変化への過剰な対応があると指摘されている。例として、米国連邦航空局が行った国家航空交通管制のための先端的自動化システム開発で30億ドルの予算超過が発生したことが挙げられている。 ↩