アジャイル開発はなぜ失敗するのか？
2022.02.28
「ウォーターフォールはダメだ！これからの時代は変化に対応だ！アジャイルだ！」と声高に叫ばれるようになって久しいですが、いまだにウォータフォール型開発が多くを占めている現状だと思います。
新たな開発スタイルを確立すべく、多くの開発現場でアジャイル導入のチャレンジが繰り返されてきたのと同時に、たくさんの死屍累々とした敗北を重ねてきました。結果、その難しさから「アジャイル開発は銀の弾丸ではない」などと言われたりします。
ぼくの経験上、「～に銀の弾丸はない」というフレーズが登場したら、大抵は「人間が泥臭いことをせっせとやったら結果が出るときもあるよ」ということを表現しているだけなので、アジャイル開発も同様です。
ということで今日はアジャイル開発はなぜうまくいかないのか？ということを書いていきます。
結論から言うと以下です。
- アジャイル開発の「型」だけ模倣してしまうため
- 作り手だけでアジャイル開発してしまうため
- アジャイル開発は人に依存していて再現性が低いため
アジャイル開発の「型」だけ模倣してしまう
アジャイル開発にはいくつかの具体的な手法群があります。最も代表的なものにはスクラムやXP（エクストリーム・プログラミング）という単位が存在し、それに紐づく形で具体的な「プラクティス」と呼ばれる型があります。
例えば、一定期間ごとに反復的に設計・開発を繰り返す手法のことを、XPでは「イテレーション」、スクラムでは「スプリント」と呼ばれています。その他にも、「振り返り」「プランニングポーカー」「インセプションデッキ」など、何十種かのプラクティスが存在しています。
具体的なプラクティスは模倣しやすいので、アジャイル開発を導入しよう！となるとまずはプラクティスの導入からやっていくことが多いのですが、大抵の場合それだけでは失敗します。以前のブログにて言及した通り、アジャイル開発は具体的なプロセスではなく人に依存しています。型だけを導入したところで、人の内面が変わらない限りうまくいくようにはならないのです。
作り手側だけでアジャイル開発してしまう
アジャイル開発（正確にはスクラム）には「プロダクトオーナー」という役割が存在します。これは、プロダクトを用いたビジネス的な結果に責任を持ち、どのようなプロダクトにしたいかを言語化して開発チームに伝える役割を担っています。
アジャイル開発はシステム開発の現場に関わる人達の間から生まれました。どのようにシステムを開発を進めていけば良いかを示す手法群なので、作り手側が主体となって導入していくケースが多く見られます。すると、プロダクトオーナーを立てず、開発側だけでアジャイル開発を導入しようとしてしまうことがよく起こります。ビジネス側の要求に開発側だけでなんとか応えようとした結果そうなりがちです。
「計画に従うことよりも変化への対応を」という言葉が、アジャイルソフトウェア開発宣言に明記されている通り、不確実性が高いシステム開発の世界では、計画を立てつつも、全てを計画通りにすすめることよりも、変化に対応して臨機応変に意思決定・行動していくことが要とされています。
では、計画に関する権限を持っているのは誰でしょうか？そう、それはプロダクトオーナーであり、そしてその先にはステークホルダー（利害関係者）がいます。ともすればプロダクトオーナーが参加していないアジャイル開発がどうなるかは想像に難しくないと思います。
システム開発の現場では、計画時には発覚しなかったリスクや、問題が頻繁に発生します。これはいかなる熟練者が対応してもそうなります。その度に、計画と現在を見比べて変化を受容し適応していかなければいけません。にも関わらず、計画が一切動かせないのなら、それは単に細切れに開発しているだけのウォーターフォール開発です。うまくいくはずもありません。
もし、どこかの開発会社が「うちはアジャイル開発でやってます！」と言いながらプロダクトオーナーの役割を求めてこないなら、それはほぼ確実になんちゃってアジャイル開発です。マーケティングや営業の都合で「アジャイル開発やってます」って言いたいだけです。
アジャイル開発は人に依存していて再現性が低い
上記のように、アジャイル開発の本質は型ではなく、チームを構成する人間の内面にあります。アジャイル開発のプラクティスを導入したところで、その価値観が内面化されていなければどうやったってうまくいきません。
逆に言えば、その本質を押さえてさえいればアジャイル開発じゃなくたってうまくいくのです。アジャイル開発のプラクティスは、単にそのためのヒントやテクニックを教えてくれているだけに過ぎないのです。つまり開発が上手くいくかどうかのほとんどは人に依存していて再現性が非常に乏しいわけです。
本来手法論というものは、人に依存する部分を減らすために、人の思考量を減らしてくれるものなのですが、アジャイル開発では真逆です。チーム全体の思考量を増やすことで、未知の問題へ対処する力となります。
では、どのような力を持っていればアジャイル開発を成功に導くことが出来るか？
- 問題を本質を明らかにする力
- 主体的に変化を推進する力
- 価値を理解する力
これらがアジャイル開発を支える3つの力です。
問題の本質を明らかにする力
アジャイル開発には振り返りというプラクティスがあります。一定周期ごとにチームでの活動を振り返って、良かったこと、改善すべきことをチーム全体で話し合う催しです。代表的なやり方にKPTというフレームワークがあり、mofmofでも導入しています。
これにより、問題を顕在化することは出来るのですが、多くの人が問題の深堀りを上手に出来ません。表面的な現象のみを捉え、本当の要因にまでたどり着くことが出来ないのです。
例えば、「リリースしてから仕様の認識違いが発覚して手戻りしてしまった」というような問題があげられたとして、その要因を「誰かの不注意」として処理してしまうようなことがよくあります。すると改善のアクションが「気をつけます」とか「ミスしないように意識します」のように表面的なアクションになってしまうのです。
なぜ仕様の認識違いが発生したのか？不注意だったとしたら、どうして不注意が発生したのか？仕様伝達の方法に欠陥はないか？など、問題の根本的な原因に辿りつくまで様々な角度から深堀りし続けなくてはなりません。それが問題の本質を明らかにする力です。
主体的に変化を推進する力
これまで何度も伝えている通り、アジャイル開発において重要なのは「計画に従うことよりも変化への対応を」ということです。
勘違いしがちですが、重要なのは、変化を受け入れることだけではなく、変化の必要性を正しく認識して、主体的に推進していくことです。変化を求められて受け入れ従うことは簡単です。しかし、問題が起こったときに、問題の本質を見極めて具体的な変化を提案し、それを実行するのはそれなりに高いハードルがあります。
大抵の人は現状維持を好みます。それが楽だからです。仮に何か問題があったとしても現状維持+αくらいで済ませたくなります。根本的な要因を認識していてもなお、出来るだけ楽な方法を取ってしまうのです。「こういうスタイルだから」「クライアントの事情だから」など、暗黙的なルールを自ら作り出して変化を推進することを拒むのです。主体的に変化を推進する力とは、そういった自らの変化を拒む力へ抵抗し越えていく力です。
システム開発プロジェクトでの失敗はまるでゆでガエル理論の様相を呈します。問題が小さいうちは、無視してもプロジェクト進行出来てしまいますが、気付かないうちに徐々に徐々に進行して、最後の最後に手を付けられないくらいに深刻になった状態で顕在化します。だから問題が小さいうちに、問題の根本を無視せずに行動を起こさなければならないのです。
これはとても難しいことです。ときにはものすごく言いにくいことを言わねばならないときもあれば、これまでのことを根本から覆すような提案をしなければならないときもあります。それでも目的達成のための最善は何かを考え、実行に移す力が重要なのです。
価値を理解する力
ぼくにも経験がありますが、多くの作り手は「システムは設計した通りに作りさえすれば価値がある」と考えてしまっています。つまり顧客が「欲しい」と言った仕様で合意し設計し、その通りに作れば価値があると考えているのです。
この前提は、「欲しいと言われたものを実現したんだから当たり前じゃん」と感じると思いますが、実際そうではないのです。顧客は自分が欲しい物の形を知りません。知っているのは解決したい課題のことだけです。つまり顧客は欲しい物を正しく伝えることが出来ない、という前提に立たなければならないのです。
引用：https://s-jsd.com/entry/1422.html
顧客が欲しいものは「システム」ではありません。「問題解決の手段」です。問題解決出来るのならシステムじゃなくてもいいかも知れないし、作る必要すらないかも知れません。何を実現すべきかは、「何が欲しいか」ではなくて「何を解決したいか」に耳を傾けなければならないのです。
「誰が」「どんなことに困っていて」「どうやって解決するのか」を自分ごととして共感しスラスラ語れるようでなければ本質的に価値を理解しているとは言えません。もし、あなたが作り手だとして、これが出来ないのだとしたら、価値を理解しないまま作っているということを自覚しなければなりません。
まとめ
上記のようにアジャイル開発ではプロセスを定式化しづらく、思考量が下がるどころか、上げなければならないものです。プロセスが人に依存してしまっている部分が大きいので、一朝一夕で上手くいくことはなく、試行錯誤の連続を乗り越えなければなりませんが、そうやって真摯に向き合っている人が多くいるチームほど成功に近づけるはずです。
mofmof inc.では決まった通りに作るのではなく、ユーザーニーズに合わせてプロダクトを随時進化させていく、月額制の開発サービス「開発チームレンタル」を提供しております。気になりましたらどうぞお気軽にお問い合わせいただければ。
