「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。
言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社）
記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。
記事への反応
記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。
- 失敗の定義は？
- そもそもアジャイルできてなくね？
- 下記が失敗するのはアジャイルかどうかとは関係なくね？
- 明確な要件が定まる前に開発が開始
- 仕様が固まってない
- 開発の後半で大幅な変更が行われる
- 本売りたいだけじゃね？
- 高品質のソフトウェアを予定通りに納品するため、Impact Engineeringの哲学を学ぶべきだと訴えました。ってなんだ？
- 失敗することが必ずしも悪ではないという考え方があるので、早く失敗したという事実をむしろ良い事として捉えるべきでは？
飛び火・脱線して、アジャイル vs ウォーターフォールのような文脈で考察している意見も見受けられますが、本件の元記事(Engprax)にはウォーターフォールという言葉は一切出てこないのでここでは触れません。（ギガジンやThe Registerの引用記事には出てきますが）
「エンジニアリング組織論への招待」によると
中規模のアジャイルプロジェクトの成功率は27%とあるので失敗の定義にもよりますが、あながちずれた数字ではないのかもしれません。
私もウェブ上の記事から読み取れる情報をもとにした感想は概ね上記と同じで、失敗の定義やあやふやな部分が多く、何が言いたいのか結局よくわからない
本の宣伝やろ？
というのが率直な感想です。
そして私の一番の疑問が
で、『Impact Engineering』てなんですの？
ていうところです。
プロモーションに負けた気がして若干悔しいですが、Kindle Unlimitedで読むことができる書物のようなので2024年6月4日にリリースされたばかりの出典元を読んでみることにしました。
忙しい人向けの結論
Kindle Unlimitedに入っていなくても上記から、5~9ドルほどで購入できるようです。
率直に読んだ後の感想を述べると「なんやこれ？」というのが正直なところです。
まず、ビジネス小説というところに拍子抜けしました。
21章で構成された本ですが、なんとその18章までが架空のビジネスプロジェクトの物語になっており、読んでると、「早くインパクトエンジニアリングについて教えて〜!!!」ってなります。
小説の内容は結構つまらないです。
で、『Impact Engineering』って具体的に何という点については最終のConclusionの後に、
おまけの如く、テクニック要約として載せられていたので、雑に解釈すると下記のようになります。
インパクトエンジニアリングのステップ
- 問題を定義づけする
- 問題に対する解決策を模索する
- ソリューションを実装する
- 解決策が要件を満たしているかどうかを分析する
- 必要に応じて繰り返し開始することではなく終了することに集中します。
インパクトエンジニアリングチェックリスト
- 開発プロセスを開始する前に明瞭な要件（リクアイアメント）を準備します。
- プロジェクト中に問題が生じた場合は迅速に話し合い対処します。
- 要件を実際の問題に基づいて設定します。
- 仕様書・要件書を文書化します。
- 開発プロセスの後半で大幅な変更を行わないように、十分に計画を立てることに注意します。
- 同時に過度の作業負荷を負わないことで、燃え尽き症候群をを回避します。
トランスフォーメーションのコツ
- 他人に変化を強要できないことを再認識します。
- 最大リスクを特定し、それに対処します。
- 損失回避が悪魔を抹殺することを止めないように注意してください。（多分損切りのタイミングを逃すなみたいなこと）
- 大きい変更を行うときには感情的にな健康を優先します。
- 大きい変化をする能力を向上させるには自己信念（ナルシズムではない）、自発性、感情的な自己調整、誠実さのスキルを磨いてください。
- 感謝、思いやり、プライドによって、人々は満足することに対して遅れを招きます。（報酬を後回しにすることで人々の生産性を高めることができる？らしい）
拍子抜けすると思いますが、これが『Impact Engineering』だそうです。
（インパクトエンジニアリングチェックリストが冒頭のアンケートでの「インパクトエンジニアリングを実践しているか」に該当するようです。）
プロジェクト参加者の感情論に触れているところは独自と言っていいかもしれないですが
「これってアジャイルのことじゃね？」
「当たり前のこと言ってるだけじゃなね？」
というのが正直なところ。
本書のアマゾンのレビューを見ると、筆者の知り合いではないレビューと思われる投稿に下記のように記されています。
The research is interesting but not surprising. The conclusion could just be a small blog post.
The whole thing boils down to:
- gather requirements early and write them down
- actually understand your problem
- be aware of the psychology of people and teams and how they can cause projects to fail
which any software engineer should already know.
While I appreciate actually doing research (in a field in desperate need of it), neither the study, nor the book provide a convincing argument that Impact Engineering is a significant new methodology that improves on Agile. In fact, it scarcely defines what Impact Engineering even is.
This book is just a couple of obvious ideas stretched out into a pretty terrible read, with a bold title, that tries to use research to assert its legitimacy.
要するに、
「エンジニアなら誰でも知ってるような内容なので、短いブログで十分」インパクトエンジニアリングが一体なんなのかも正確に述べずに、退屈な会話を引き延ばし、大胆なタイトルと共にそれを正当化するために研究結果を利用している。」
と書いてあり、私はこの意見に概ね同意します。
この本を読んでもアジャイルに変わるコペルニクス的転回が訪れることはありません。
筆者の言いたいことが伝わってこないと感じる部分もあるのでもう少し具体的な書評とアジャイル開発に関する私見を引き続き書いてみようと思いますが、Impact Engineeringについてそれがなんなのか知りたくて、この記事に辿り着いた人にとっては上記以外に書けることはないので、時間を無駄にする前にこの記事を閉じてしまって大丈夫だと思います。
続きが気になる方はどうぞ...
筆者は「アジャイル」 vs 「Impact Engineering」を問いたい訳ではない
データとして持ち出して比較しているのと、筆者自身もEngpraxのCEOを務めていることを考慮すると、誤読を誘っていると思えるのですが、「アジャイル」 vs 「Impact Engineering」を語ってる訳ではないです。
実際比べているのは元記事の一行目に出てくるAgile Manifesto practicesとImpact Engineeringを比較しています。つまり広義のアジャイルプラクティスではなくアジャイルソフトウェア開発宣言が、アジャイルプラクティスの誤用を生むという意図で対比しています。
小説の部分の要約
小説のネタバレを含むので小説を楽しみにしている人は注意ください。
この本の約9割を占める小説部分ですが 、登場人物は下記です。
- 顧客
- アジャイルプラクティスの手法に傾倒し、炎上ののちにプロジェクトから切られるチームA
- 火消しに呼ばれたコンサルチームB
- Jess: トランスフォーメーションに関心
- Daniel（主人公）: Jessの言動から学び、ソフトウェアを予定通り納品することに注力
あらすじ
前半部分ではプロジェクトで顧客の要望が実現できていないことなどからプロジェクトが炎上します。
しかし、プロジェクトを受けているコンサル会社Aは契約交渉よりも顧客との協調や計画に従うことよりも変化への対応を大事にしているなど、デプロイは最新技術を用いている、チーム のDevOps的な文脈の生産性指標は非常に高水準で安定していると言い返します。、顧客との噛み合わない会話を繰り返している訳です。
技術的・手法的意味合いでのアジャイルを実践しているが顧客への提供価値が低いチームを表現しています。
一方後半で出てくるコンサルB社では顧客の要求にシンプルなプロジェクト管理を実践し、
納期に高品質なシステムを完成させます。
筆者のバックグランド・舞台のコンテキスト
-
Junade Ali
- 1995年生まれ
- 17歳でSCの修士号
- 24歳で日本の技術士資格に相当するawarded Chartered Engineerを最年少取得(難関資格らしい)
- 2020年までCloudflareでエンジニアをしていた
- 現在はエンジニアマネジメントの研究指導するコンサルティングを行なっている
- 去年、認知心理学のCertを取得している
- GitHubアカウントを見るとここ5年ぐらいは地震は開発活動をしていなさそう
- EngpraxのCEOであるがフォロワーは一桁代なのでおそらく創業後まもない企業のよう
- ITエンジニアのメンタルヘルス・燃え尽き症候群について研究している人
小説でも、解説でも一貫して、納期のあるコンサルプロジェクトのプロジェクトマネジメント的な話をしているようです。
システムを内製しているIT企業のような形態は想定していなさそうです。
近年は燃え尽き症候群について研究しており、その文脈でこの本を執筆するに至ったようです。
またアンケートの対象はイギリスおよびアメリカなので日本は含まれていません。
筆者は一体何を言いたいのか、を都合よく汲み取ってみる
意外かもしれないですが、本の中で多くの割合を占めるのがメンタルヘルス（燃え尽き症候群）の話です。
欧米のシステム開発プロジェクト（ここでの文脈的に受託形態）において、見切り発車で作り始められたシステムで多くのプロジェクトが後半に炎上状態にあり、開発の後期であっても多くの対応に追われ、完了の定義捻じ曲げられた多くのITエンジニアが疲弊しメンタルヘルスが悪化している現状があるようです。
このような状況下において、筆者はエンジニアを取り巻く仕事の環境を調査している文脈で出てくるのが、表題の調査であり、そこから見えてきたコンセプトが『Impact Engineering』だということみたいです。
アジャイルプラクティスの誤用
そこでは詭弁的に「アジャイルソフトウェア開発宣言」 の
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
が誤用されがちであり、
プロジェクトの失敗（ここでの文脈は受託の炎上）の原因を分析すると要件定義・設計フェーズに問題があるにもかかわらず、その問題の本質はほとんどの場合でみすごされ、上流工程に関わった人たちは隠蔽し、プロジェクトの後半工程に転嫁されエンジニアは過剰負荷がかかった労働環境になったり、エンジニアは不具合の問題責任をテストの不足と結論づける傾向があるようです。
評価者・被評価者の認識乖離
エンジニアは手法にこだわる傾向があり、トレンドの実践に価値を置くことが多いようです。
小説部分のA社のように生産性指標やアジャイルプラクティスである最新のデプロイ形式の整備に傾倒しすぎるあまり、顧客の課題解決を軽視してしまうような状況が発生します。
しかし、エンジニアは専門性を有していることもあって、他の職種よりもパフォーマンスに対して自己評価が高い傾向にあるそうです。
一方、コンサルに依頼するビジネスオーナーの多くは、希望する納期に高品質なシステムが使える状態になっていることを望んでいて、エンジニアは納期の重要性について理解しているものの実態として多くのプロジェクトが遅延していると、筆者は論じています。
端的にいうと下記にギャップがあるということみたいです。
- エンジニアがエンジニアコミュニティや自己評価で期待する要素
- 最新技術を使いこなせる
- アジャイルプラクティスが実践できている
- 顧客がエンジニアをに期待する要素
- 期日最重視する傾向
- 実現される手法にこだわりはない
つまり、手法に傾倒するのではなく顧客の期待することを第一に考えてインパクトの順番に並べて、上から取っていこうということみたいです。
極めて当たり前のことを言ってますね
筆者のリサーチ意図は？
アジャイルプラクティスが形骸化していることを言いたかったようです。
アジャイルを実践していると答えていても目的意識まで浸透していないことが多く、形骸化していることを数値化したかったようです。
形骸化せずに適切に運用されているかを確かめるために、あえてアジャイルの文脈で語られる言葉を用いずに、実践されているかを問うと実践していると答える人の割合が下がったようです。
例） デイリースタンドアップなどスクラムイベントに参加しているがその意図は理解しておらず、機能不全になっている。
儀式のようにイベントや最新の手法を実践している一方でその意図やイズムについては浸透していないというのが欧米の現状としてあるようです。（自社サービスよりはコンサルプロジェクトの文脈？だと思います。）
そして、アジャイルプラクティスの後者３つである
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
に関して実際にソフトウェアの提供にどのような影響を与えるのかテストしたかった。
と記しています。
ソフトウェアプロジェクトは、文書化された事前の計画を軽視し、要件なしでソフトウェアをデリバリーし、要求に応じて変更することを優先して本当に成功するのでしょうか？
と書いています。
（アジャイルマニュフェストも文書と計画を軽視しているわけではないと思いますが、筆者はそう書いています）
本の感想
リサーチ内容についてどう思う？
今回の調査はコンサルタント会社「Engprax」が書籍「Impact Engineering」のために実施したもので、アメリカ合衆国およびイギリスの合計600人のエンジニアを対象に2024年5月3日から2024年5月7日まで実地調査を行いました。
まず期間が4日間と非常に短いかつ、本の発売日から約1ヶ月というと頃からもわかる通り、筆者がビジネス小説として「Impact Engineering」について書き終えた後に、後付けで取られたアンケートであることがわかります。
またアンケート前にインパクトエンジニアリングをレクチャーして実践していたというわけではなく、冒頭のチェックリストを満たしている場合にインパクトエンジニアリングを用いていると定義しているようです。
さらに
ソフトウェアプロジェクトは、文書化された事前の計画を軽視し、要件なしでソフトウェアをデリバリーし、要求に応じて変更することを優先して本当に成功するのでしょうか？
に関しては、後付けのアンケートで裏付けしても意味を成していないと感じました。
例えば要件が明確に文書化されなかったのは、軽視していたのか抽象度が高くて決められないようなプロジェクトだったのかわからないです。
というのも、この質問をすると、要件の簡単なプロジェクトほどインパクトエンジニアリングを実践していることになるので、単に簡単なプロジェクトだからインパクトエンジニアリングのチェックリストに当てハマっただけかもしれません。
「アジャイルマニュフェスト」・「インパクト エンジニアリング」という言葉を用いずに、アンケートの結果からその分類分けしているため、管理の雑なプロジェクトほど、「アジャイルマニュフェスト」を用いているということになってしまいます。
実際にそのプロジェクトでアジャイルマニュフェストを実践していたのかどうかは分かりません。
欧米のコンサルティング会社のシステム開発環境には精通していないですが、今時アジャイル開発を実践したいからといってアジャイルマニュフェストを用いている結構稀であると推察されます。
比較のグラフは失敗率の比較なので、母数600のうち、何人がインパクトエンジニアリング・アジャイルマニュフェストに分類されたのか言及されていません。実は母数600に対してどちらも非常に低い数値の可能性があります。実数を述べずに、その失敗率だけを記述しているのには理由があるのでしょうか？と思いました。
納期にシステムを提供できたかどうかをプロジェクトの指標にしているという大前提で、プロジェクトの後半に大幅な要件の変更変更をする必要がありましたか？の質問にYesをつけた時点で、そのプロジェクトは失敗したことを意味してしまうでしょう。
選択肢の中に、ほぼ失敗を結論づけるための十分条件を含んでいるので、この点からも意味が非常に薄いアンケートだと言えるでしょう。
結局、適切にアジャイルをやろうってことですよね？わざわざImpact Engineeringって名付ける意味有る？
無いと思います。
じゃあなぜ、筆者がVS アジャイルソフトウェア開発宣言の構図で語ってるのかというと、私は何度か読み直すことでやっと理解したのですが
結果から言えることで、重要なのはデリバリーのスピードではなく納期がオンタイムであることだ。これは些細に感じるかもしれないがとても大切な違いだ
などと言っていることから推察するに、筆者は開発コンセプトとしての「アジャイル」の価値観、には同意していて、ネーミングに納得していないのではないかと思いました。（実際に明確な言及箇所を私は本の中から見つけることができませんでした）
既存の物に自分流の名前とってつけるやつあれか、と思うかもしれないですが、筆者寄りにみて汲み取ると、定着している組織・経営手法としての「アジャイル」を一旦置いておいて、アジャイルという英単語の本来の意味は
アジャイル: 「素早い」「機敏な」
という意味です。
で、近年の「アジャイル開発」が時代の変遷とともに手法としてのアジャイルは変化していて、コアな部分（顧客への提供価値が優先で考える）、は変わらないものの、それを表すコンセプトとして「素早い」という一単語で表すのが適切なのか。このズレが誤用を生む一旦になっているのではないか？という部分に疑念を持っていてるのだと思われます。
顧客への提供価値の大きい順から並べて達成するのを試みるのであれば「顧客へのインパクトを最大提供する開発手法」として『Impact Engineering』と名付けたというわけです。
まどろっこしいねぇ
そして、コンサル請負の開発においては、ビジネスオーナーは納期へのコミットメントに対する期待が大きいので、そこの握りをうまくやろうってことを言っているのではないのかと思いました。
なんか記事の見せ方がやらしくね？
小説の末尾にエビデンスレベルの低い調査結果を載せている筆者であるCEOはvs アジャイルっぽく見せて本に興味を持たせようとしている意図が見えます。
ギガジンもあえてスクショを載せる際に、表のタイトルのAgile Manifestoの部分を切り取って、意図的にアジャイルに変わる概念であるかのように、記事を出しているなと思いました。
| Engprax社 | ギガジン |
|---|---|
 |
 |
期日に納品できるかどうかがプロジェクト成功といえるの？
筆者のリサーチではそのように定義しています。
広義にはコンサルのトランスフォーメーションのプロジェクト以外に自社内のサービス開発なども存在するため、上記は一般化ができないと思います
さらにギガジンやThe Register社は
those which do the opposite(Impact Engineering」のこと)を、「その他の手法」と表現し、文中に全く関係ないウォーターフォールを持ち出して、著者の意図しないアジャイル vs ウォーターフォールの構図を誘発しているように思えます。
本を読んだ後に考えたこと
改めて「アジャイルとは」を考えるきっかけになりました。
「アジャイル」に対して思うこと
アジャイルソフトウェア宣言(The Agile Manifesto)について改めて
見てみると、これを鵜呑みにされて受託開発のプロジェクトにアサインされると辛いなと思いました。
特に
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
を顧客やプロジェクトの管理者が是として、運用されると確かに手を動かすプログラマやテスターはキツイだろうなと思いました。
準委任ならまだしも、請負契約で検収ありのプロジェクトでこれを可にしてしまうと、高確率でプロジェクトは破綻するだろうなと思いました。
なぜこんなこと書いてるのかなと思ったのですが、シンプルに時代背景ではないかと思います。
The Agile Manifestoは2001年に発表されたもので、2001年というと先進国でかろうじて携帯電話の普及率が50%を超える国がいくつかあるだけで、スマホも無ければ、日本でパケット使い放題のサービスが出るよりももっと前の時代です。
この時代のソフトウェアというと開発手法というとgitも存在しない世界線なので今と比べると、ユーザー・顧客・開発者全てが成熟してなかった時期といえます。
今以上に顧客は自分の作りたいソフトウェアを表現できないでしょう。
システム屋も顧客の欲しいものが一体何なのかを体現することが難しかった時代にまず、動くものを見せて期待を持たせつつ変更を重ねながら作っていくという手法が
今よりも合っていたことは想像できます。
2000頃から2015年ぐらいまでにかけて、各業務分野・事業ドメインで早いもの合戦が繰り広げられました。
経理・HR・営業など事業ドメインに関わらず事業活動の一部の業務を一般化し業務効率化するためのホリゾンタルSaaSや固有の事業ドメインでの業務に特化した業務支援をするバーティカルSaaSが登場し始めた頃で、この頃には素早く市場のニーズを捉えPMFした会社が各分野でのシェアを寡占できる状態だったので、リーンでより素早い開発手法が好まれたと思います。
そういった早い者勝競争の時代背景から、開発フレームワークとしてのRails（およびアクティブレコード）や、スクラム開発などが人気を集めたのだと思います。
| バーティカルSaaS | ホリゾンタルSaaS |
|---|---|
 |
 |
現在のシステム開発を取り巻く環境は日本だけでみても上記のように、大量のSaaS企業が存在し、バーティカルSaaS・ホリゾンタルSaaSともに、市場には上場済みの企業が存在するような状況です。
｀
２０００年頃に比べると、システムに対して遥かに親しみを持ち、さまざまなシステム使った経験もあるであろう顧客のITリテラシーが上がっています。
システム開発は性質上不確実性の高い活動で有ることに変わりはない一方で、適切にヒヤリングすれば、昔に比べればより解像度高く自分達の課題を表現できるようになっているでしょう。
Webシステムに期待する水準が昔よりも高い。
顧客の要望は複雑化している。
なぜなら、シンプルで費用対効果の高い分野・領域からシステム化されて行っているので、後発のプロジェクトは、大企業の隙間を縫いつつ、既存のシステムに勝る付加価値・品質の高いものを提供しないと市場から見向きもされないようになっているでしょう。
早い者勝ちであるには変わりないものの、20年前に比べると、競合分析に時間をかけて、最初から顧客の心を掴むシステムを作る必要があるでしょう。
さらに、既存の機能・システムを改修し付加価値を付け加える場合は、技術的負債という内部的な問題とも戦う必要があると思います。
同じアジャイルの手法といえどと、システム開発を取り巻く環境が目まぐるしく変化しており、現代においては開発前の工程で精度高く、プロジェクトを進行するための手法に変化していくのは当然だな言えると思いました。
これはコンウェイの法則的にいうと、2000年以降に速さを取るために、モデルの構造とDBの構造を1対1のアクティブレコード型のMVCのフレームワークが流行った一方で近年では、そのフレームワークを用いていても、独自のクラスを加えてドメインを純粋に保ち、複雑さを表現したりや将来の変更に備えるスタイルが人気を集めています。
初期コストをかけて未来の躓きを回避し、複雑な顧客のニーズ応えたいというマインドの現れではないでしょうか。
「素早い」というコンセプトの名で表現するかはおいておいて、アジャイル開発のマインドセットを適切に実践していると自然とそうなるというのが私の感想です。
アジャイル開発はその特性ゆえ、取り巻く環境が変わって顧客のニーズが変わっていくとそのコンセプトにあった手法としての部分は結構変化していっているのだなと気づきました。
学び
ドメイン駆動設計を学んだ時にも思いましたが古い情報から学ぶ場合は
- 時代背景を考える必要がある
- なぜそうするのか、なぜそうしていたのかを汲む
- 手法に傾倒して実現しようとしている目標や戦略部分を見失ってはいけない
と思いました。
銀の弾丸はないので目的にあった手法を模索し続けるしかないと思いました。
期待値コントロール
プロジェクトの成功の定義を納品とすることはできないと思いますが、成熟しつつある市場では、SaaSの自社内開発であっても納期へのコミットメントは求められる場面が実態として多々あるなと思いました。
特に to Bの大規模顧客の要望は受託開発の納期よりもコミットメントを求められる場面すらあると思います。
改めて振り返ってみると
- 特に大規模開発では慎重に期待値を汲み取り、手を動かす前に、合意形成してやる人が評価されている
- さらに手を動かす前の工程ちゃんとやる人の方が、結果的に早い
と思いました。
世にない全く新しい価値観を生み出すときを除いて現代のシステム開発、とりわけコンサルプロジェクトにおいて多分動くと思うからリリースしようぜを実践すると市場からもステークホルダーや上司からも失格の烙印を押されるだろうと思いました。
ちゃんと要件定義・設計・実装・テストしましょう
小説の中の価値観も踏まえてプロジェクトをリードする立場においては
- プロジェクトをマネジメントする上でできるだけ前の工程で不確実性を解消しておいて、ステークホルダと合意
- 遅れたら納得できる理由を説明できる
をやっておくことで、自身の身を守る意味でも有用で開発者からも信頼を得られるのではないかと思いました。
（簡単なことではないですが）
本意書かれていたことは真新しい概念ではないが、詭弁的にアジャイルプラクティスを使って、失敗しているプロジェクトがあるのであれば、名前はなんであれ筆者の提唱するテクニックが浸透して、一人でもメンタルヘルスを患うエンジニアが減ってプロジェクトを「成功」に導くのであればそれに越したことはない
と思いました。
結果的に色々考える機会にはなったかなぁ。と思いました。
終わり。
時代背景を考える上で参考にした本