世間的にずいぶんアジャイルという言葉が市民権を得てきたものの、日本においてはいまだウォータフォール全盛で、例えば多くの企業が参加する IPA 「ソフトウェア開発データ白書」によれば開発プロジェクトのうちウォーターフォールが全体の97.4%を占めており、アジャイル開発を含む反復型開発は 1.7% に過ぎない。
一方アメリカではかなり普及しているという話があるものの具体的なデータは見つけられなかった。多く見つかるのは「State of Agile Report」のアメリカ企業の95%がアジャイルを採用しているといった数字だが、会社で１回でもアジャイル開発を行えばカウントされることを考えればあまり意味はないだろう。すべてのプロジェクトでアジャイル開発をしているのは18%に過ぎない（十分多いとは思うけれども）。
アジャイル開発の方法論を踏まえれば、サービス型の企業であればアジャイル型で開発するのが自然であるし、アメリカではエンジニアを自社で集めて内製開発する企業も多いと聞く。ウォータフォールよりアジャイルの方が優れているかどうかとは関係なく、単に業種業態や歴史的な経路に依存するだけの話なのではなかろうか。
私自身はシステム会社で企業の基幹システムを中心に開発していることもあり、正直アジャイル開発を肯定的には捉えていない。XP自体は素晴らしい発想だとは思うが、それはあくまでソフトウェア開発の理屈であり、プロジェクト管理とは異なる次元の話であるように思える。しばしば、ウォータフォールは問題点ばかりが挙げられるが、特に大規模システムでは明確な利点もある。
とはいえ、世の風潮としてはアジャイルの素晴らしさを喧伝する声で溢れているのも事実だ。それらの喧伝がもし本当であれば、私はただの老害ということになる。
やはりまずは事実関係を調べるべきだろう、ということで実証研究系のサーベイを探して出てきたのが、今回紹介する「Empirical Studies of Agile Software Development: A Systematic Review」だ。2008 年の論文であり、やや古いようにも感じるが、引用数もそれなりに多く、内容も網羅的である。*1
まずは結論
先に結論だけ言うと、アジャイル開発が優れているとする学術的根拠はない。ただし、主たる理由は「研究の示すエビデンスの質が低い」ことによる。例えば、ある研究では良い結果が得られたが、別の研究では逆の結果が報告されていたりする。量の問題もある。アジャイルに関する論文は多いが、報告の多くはアジャイルを推進者であり、対象プロジェクトのメンバーの一員であることも多く、成功を報告しやすいインセンティブがある。客観的な実験計画に従った信用に足る研究は少ない。
しかし、これは昔の話かもしれない。最近ではどうだろうか。例えば、2016年の「Challenges and success factors for large-scale agile transformations: A systematic literature review」という論文がある。しかしながら、Abstract を読むと「収録された論文のほぼ90％が経験談であり、このテーマに関する健全な学術研究が不足していることを示している」などと書かれており、状況はあまり変わってなさそうだ。
アジャイル開発の唱導者は、アジャイル開発の良さを喧伝するが、現実の社会で実際に行われるプロジェクトには多くのバイアスがある。まず、アジャイルに適合しやすいプロジェクトほど実際にアジャイル開発を採用しがちだろう。一方、ウォーターフォールは適合可否に関わらずデフォルトの選択肢として採用される。
アジャイルは新しい考えであるから、そのプロジェクトには積極的な顧客や能力のあるPM、開発者が集まりやすいという事情もあるだろう。
宣伝という面でも、アジャイルの成功は積極的に広報されるのに対し、いまさらウォーターフォール開発での成功は報告も喧伝されない。
アジャイルとウォーターフォールのプロジェクトをその成功数で単純比較するというのは非常にまずいやり方だ。
というわけで、今回は前述の論文など数本読んだ感想として、4章に書かれた結論をベースをこの面では効果がありそう、ここら辺はそうでもないのでは？ という伊津野の感覚値を書いていくことにする。特にアジャイル開発に対して否定的なコメントは研究のインセンティブから考えても一定の意味があると考えている。
アジャイルの採用について
アジャイルの導入に際し必要な労力を過小評価すべきでない、という見解が書かれている。導入がスムーズにいったケースでも「最初の1週間は大変」という報告がされており、「How Agile Impacts a Software Corporation: An Empirical Study」という2018年のアジャイルに肯定的な論文でも「ビジネスの一時的な停滞があった」と書かれている。
個人的見解としても、ウォーターフォール開発の利点のひとつは誰もが知っているということがある。現在、基本設計フェイズです、システムテストフェイズです、と言えば、だいたいプロジェクトがどれくらいの状況にあるのかわかるし、新たに参画するメンバにどのようなスキルが必要なのかも想像がつく。
この項目に関して「XPチームはコミュニケーションが改善されたが、他のチームからは孤立していると認識されている」という記載はやや気になる。アジャイル関連の肯定的意見としてチームの一体感、ワクワクした雰囲気などが語られるが、一方で大規模プロジェクト全体としての一体感は損なわれているのかもしれない。ウォーターフォール開発では管理チームや他チームとの調整に多くの時間が割かれるが、逆に言えばプロジェクト全体のコミニュケーションは取りやすいとも言える。自身のチームの一体感を向上させることは得てして他のチームからの要求を拒否しがちな状況を生むことも考えられる。
組織文化、コミニュケーションについて
アジャイル開発では「顧客とのコミニュケーションが改善」され、「チーム内の会話が増え」、「欠陥に対するより迅速で徹底した対応」が得られるなど、組織文化、コミニュケーション改善に関する報告が多い。一方で「顧客はストレスを感じており、長時間労働を強いられてい」たり「フラストレーションが溜まり、生産性が低下した」人や「週に40時間もペアで作業するには集中力が必要であり、その結果、開発者は疲労困憊してしまった」人もいたようだ。
XPのプラクティスはたしかに顧客の積極的関与を生むが「持続性がないようにも見えるので、特に長期にわたるプロジェクトやプレッシャーの大きいプロジェクトでは大きなリスク」となる可能性も指摘されている。
アジャイル開発に関する議論全般に感じるのは、参加者に求められる意識が高すぎるのではなかろうか、ということだ。顧客にやる気があって、PMやメンバーにやる気があれば、ウォーターフォールであろうとなかろうと、そのプロジェクトはだいたい成功するだろう。実際の（特に業務システムの）プロジェクトでは、さほど改善を求めるでもなく、できるだけ安い金額で今まで通りのことができるようにリプレースしてほしい、ということも多々ある。大規模プロジェクトの実態を知っている人間としては、前提に違和感を覚える。
プロジェクト管理について
「小規模なリリースと迅速なフィードバックを伴う短いイテレーション、ユーザーの密接な参加、絶え間ないコミュニケーションと調整」によって知識が共有され、知識を創造し活用できるようになるという利点が挙げられている。一方で「ドメイン知識を持つ熟練したチームメンバー」は必須でありそれがなければうまくいかないこと、技術的問題がプロジェクトの早すぎるタイミングで上がってきてしまうこと、デザインやアーキテクチャに関する議論が十分に行われにくい、という問題が報告されている。
特に「技術的問題がプロジェクトの早すぎるタイミングで上がってきてしまう」というのは気づきにくい観点だと思う。プロジェクト失敗の理由の半分以上が要件定義フェイズにあると言われており、技術的な課題は必ずしも重要ではない。技術的な問題を解決するために労力が取られ、プロジェクトの本質的な課題解決がおそろかになってしまうのでは本末転倒だ。
品質と生産性
他にもいくつか関連する論文を読んで気づいたが、アジャイル開発を行うと品質が上がるという報告については一貫した傾向があるようだ。一方、生産性については良い報告もあれば逆に悪化したという報告もあり一貫していない。XPチームがV字型チームに比べ 3倍の生産性を発揮したが、調べてみると同じ機能を作るのに 3 倍の量のコードが存在していただけだった（むしろ生産性は下がっていた）という話が載っていて、ちょっと笑ってしまった。
「デザインやアーキテクチャに関する議論が十分に行われにくい」という話については「従来のチームの方がより優れた、より一貫性のあるユーザーインターフェースを開発した」という話も出ているので、やはり継続的開発とは別にアーキテクチャデザインの期間は必要なのだろう。
個人的な評価
アジャイル開発のウォーターフォールに対する利点ばかりに目が行き、アジャイル開発の利点がそのまま欠点にもつながっているという視点はなかったので、そこは面白かったです。とはいえ、思ったより実証研究が少なく、アジャイルとウォータフォールの成功率の実態を調べたかった身からすると残念な状況でした。同様のサーベイ論文で新しいのを知ってたら教えて下さい。
