アジャイルなのか、ウォーターフォールなのか

　時に奇妙な仕事に遭遇することがある。そのことに気づくのは、事が進んだ後だったりする。

　あるプロジェクトで、アジャイル開発の専門家として招聘された。アジャイルに取り組みたいが経験者がいないため、その補完をしたい。行き詰まったり、ダメな感じになっていたらメンタリングして欲しい。こういう話はよくある。

　話を聞いてみると、ハードウェアが絡み、かつ異なる組織の関係者が関わるようなプロジェクトで、これは状況の確実性を上げた方が良いと感じた。状況の確実性、つまり、決められることは出来る限り決める、むやみに先送りにしない。イテレーティブなプロセスの中で、徐々に状況を明らかにしていく、変更に適応的に臨む、こうした度合いを抑えた方が良い、と。

　アジャイルとは、ウォーターフォールとは、という定義以上に、いまからやろうとしているプロダクトの性質、それに取り掛かろうとしているチーム、関係者の状態、さらにプロジェクトを遂行する際の条件や制約、これらを鑑みて、どうやるかを決めることが重要だ。アジャイルか、ウォーターフォールかという捉え方では解像度が低い。2項対立では解決できない。

　プロダクト作りの「決定」をどのように行うかというデザインになる。どこを固めに決めるか、どこの決定は緩めるか（漸次的に行うか）。例えば、以下の状況が見えた場合は、固めの度合いを増やす。

・ハードウェアや外部のシステムが絡み、そちらの変更が容易ではない（取り返しがつかない）

・開発に多大な影響を与える先行タスクがまだ並行して走っている（例えば顧客開発やサービスデザイン）→並行で適応するには相当な練度が必要

・異なる組織の所属など、複数の利害関係者が絡む（期待マネジメントの難易度が高い）

など。意思決定のゲートを設けて、開発へ影響リスクを抑える。防火壁を設けるようなイメージだ。この手の作戦は以前にもまとめた。

　アジャイルの専門家として呼んだ人間が第一声で「フェーズを整えた方が良い」と言う。おそらく関係者は奇妙に感じただろうし、実際のところ、いくつかの事情から「アジャイルに開発する」という意思決定が変わることは無かった。

　その結果は？

　果たして予言どおりとなり、これはまずい、きちんとフェーズを決めようという流れに全体として合意するに至った。こうした取り返しが効く時間があることをもちろん踏まえているからこそ、状況を進行させようという判断をこちらもしている。そうでなければ、私が伴走する必要も無い。

　せっかくのアジャイルな取り組みだったのに結局はウォーターフォールに仕立てるってどうなの？　いやいや違うよ。取り組んだ結果、学びを得て、やり方を変える意思決定を行ったのだよ。このプロジェクトチームは経験主義に則っている、「アジャイル」なんだよ。