はじめに
今朝、こんな記事を読みました。
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されたという内容でしたが、にわかには信じがたい内容だったので研究結果の考察をしてみました。
違和感の正体
まず記事に目を通し、この記事の主張は下記だと読み取りました。
高品質のソフトウェアを予定通りに納品するためにImpact Engineeringの哲学を学ぶべきだ
こちらを読んで私は、3点の違和感を感じました。
- 本当にソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗確率が高いのか？
- 予定通りに納品するという成功の定義はアジャイルにも当てはめて良いのか？
- そもそもアジャイルは価値観だが、Impact Engineeringは全く別の概念なのか?
研究から読み取れたこと
記事に抱いた違和感払拭のためにこちらの研究情報を読みました。
こちらを読んでみて見解をまとめます。
1. 本当に「ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗確率が高い」のか？
まず違和感として感じた点が、本当にソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗確率が高いのか？ということです。
こちらについて研究結果を確認したところ以下のような記述がありました。
今日、新しい書籍「Impact Engineering」のために実施された新しい調査により、アジャイル要件エンジニアリング手法を採用したソフトウェア プロジェクトの 65% が、時間どおりに予算内で、高い品質基準で納品できていないことが明らかになりました。対照的に、今日リリースされた新しい書籍で詳細が説明されている新しいImpact Engineeringアプローチを採用したプロジェクトでは、失敗はわずか 10% でした。
各方法論を使用した場合としない場合での成功確率についても言及されていますが、上記の文章を引用しつつわかりやすい数値に変換すると以下のようになります。
- アジャイル開発の成功確率：35%
- Impact Engineeringの成功確率：90%
この記事内ではウォーターフォール開発の成功確率については言及されていませんでした。
なので、あくまで、ImpactEngineeringはアジャイル開発よりも成功確率が高いと言及しているのではないかと感じました。
加えて、エンジニアリング組織論への招待では、ウォーターフォール開発の成功確率は11%程度と言われています。
こちらの内容と合わせると下記のようになり、こちらの方が違和感なく理解できます。
- ウォーターフォール開発の成功確率：11%
- アジャイル開発の成功確率：35%
- Impact Engineeringの成功確率：90%
つまり、ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗確率が高いのではなく、アジャイルとImpact Engineeringを比較するとImpact Engineeringの方が成功確率が高いということだと読み取りました。
2. 「予定通りに納品する」という成功の定義はアジャイルにも当てはめて良いのか？
続いて、違和感を感じた点は予定通りに納品するという成功の定義はアジャイルにも当てはめて良いのか？ということです。
私は、アジャイルは価値提供に重きを置いていると認識しております。
だからこそ、リリースした製品だけが進捗の指標であり、リリースしたら終わりでなくて顧客の代弁者であるPOと対話を繰り返しつつ徐々に変更を加える必要があります。
ですが、記事では以下のように言及されております。
今日、新しい書籍「Impact Engineering」のために実施された新しい調査により、アジャイル要件エンジニアリング手法を採用したソフトウェア プロジェクトの 65% が、時間どおりに予算内で、高い品質基準で納品できていないことが明らかになりました。
つまり私が違和感を感じたポイントは、
アジャイルは価値提供に重きを置いているにも関わらず、単に納期・予算内での納品だけで成功・失敗を比較することはできないのではないか？ということです。
こちらの疑問に関する内容は残念ながら記事内に言及がありませんでしたが、前述した下記の数値はこの定義で成功・失敗を判断しているように見受けられました。
- アジャイル開発の成功確率：35%
- Impact Engineeringの成功確率：90%
そのため、こちらの数値はある一定のプロジェクトやプロダクトには当てはまるが、全てのソフトウェア開発に当てはまる数値ではないと考えております。
3. そもそもアジャイルは価値観だが、Impact Engineeringは全く別の概念なのか?
3つ目に違和感を感じた点は、そもそもアジャイルは価値観だが、Impact Engineeringは全く別の概念なのか?ということです。
こちらは言い換えると、アジャイルとImpact Engineeringは同じ粒度で比較することがそもそも正しいのかということになります。
記事内では以下のように言及されていました。
Impact Engineeringの著者、ジュナデ・アリ博士は次のように述べています。「アジャイル手法を採用したプロジェクトの 65% が予定どおりに納品されない状況で、アジャイルの熱狂的な支持に疑問を抱く時が来ています。当社の調査では、高品質のソフトウェアを予定どおりに予算内で納品するために重要なのは、堅牢な要件エンジニアリング プロセスと、問題が発生したときに話し合い、解決するための心理的安全性を持ち、開発者の燃え尽きを防ぐ対策を講じることであることがわかっています。これはImpact Engineeringの哲学の基本です。」
つまり、Impact Engineeringでは以下の要素が重視されています。
- 堅牢な要件エンジニアリングプロセス
- 問題が発生したときに話し合い、解決するための心理的安全性
- 開発者の燃え尽きを防ぐ対策を講じる
このうち堅牢な要件エンジニアリングプロセス以外はアジャイルと一致するのではないでしょうか？
（アジャイルが要件を固めないわけではないですが、そこは割愛します）
加えて、予算・期日内で納品することを成功と定義されるプロジェクトをアジャイルで開発するとなると、
スクラムのスプリント0に相当する期間で一定の要件を固めつつ、イテレーションを回しながら、実装や実現したい状態に合わせて要件調整を繰り返すことになるのが当然かと思います。
よって、Impact Engineeringはアジャイルと同列に語るものではなく、
予算・期日内で納品することに特化したアジャイル開発手法程度に理解しておくのが良いかと思いました。
結論
議論の余地は大いにあるかと思いますが少なくとも私はImpact Engineeringを以下のように理解しました。
- 成功を「納期・予算内での納品」と定義した時に、成功確率の高い開発手法
- アジャイルと共通する価値観を持っている = アジャイル開発手法の一種
- 対話が重要
- 燃え尽きを防ぐ工夫をする
- リリースや作業単位を小さく保つ
- デプロイプロセスを簡素化・自動化しよう
- etc...
- 予算と納期を遵守するためにスプリント0に相当する期間での要件定義に重点を置いている
総じて、開発内容に応じて柔軟に開発手法を選定するためにも、こういった新しい手法についてもフラットな目線から善し悪しを判断できることを心掛けていきたいと感じました！
レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech
Discussion
私もこの元記事を見て違和感を覚えました。アジャイルマニフェストに「計画に従うことよりも変化への対応を」とあるように、柔軟性があります。開発開始前に明確な要件が文書化されていたら成功率が上がるのは当然ですが、現実はそんな完璧な要件になっている事は稀です。後から仕様が変わったりする事が普通です。そういう時に柔軟に対応でき、顧客と「仕様変更すると納期に間に合いません。機能追加を優先するか、納期を優先するかどちらですか？」と対話ができるのがアジャイルの良い所じゃないかなと考えます。
実際の開発から納期までのフローを考えたら、今自分がやっているのも「Impact Engineering」なんじゃないかなと思ったので、これはこれで新たな発見かなと思いました。
これは私も思いましたね〜
例えばリプレースやリニューアルは最たる例で、ベースとなる要件定義は既存のシステムを元に大きくやった上で、
あたりは、スプリントを回して調整を進めていくものではあるので、自然とここでいう「Impact Engineering」になるんじゃないかな〜と思いました！