二元論ではなく、要件に立ち戻ってのアプローチで合意点を見いだす
「アジャイルとウォーターフォール」では相いれなくても、そもそもの観点QCDS（Quality：品質、Cost：コスト、Delivery：デリバリー、Scope：スコープ）について「求められること」であれば、両者とも納得して共有できるだろう。つまり、QCDSごとに何が求められているのかを共有し、その解決策としての「ソリューション」に落とし込めれば、合意できるポイントを見いだせるのではないか、というわけだ。
Qualityなら、「大企業として、ブランドを毀損するような品質問題が発生しないこと」が求められ、その対策として「チケットの受け入れ基準の中で、品質要求を明確にする」というソリューションが考えられる。つまり、品質要求が満たされたものの総和によって求められる品質をクリアするという考え方だ。
Costも「限られた期間の限られた予算をオーバーしないこと」がマストなら、各機能の費用として個別に認められにくくても、「チームサイズを固定して費用を固めること」で月間または年間予算が明確となり、要望が通りやすくなるだろう。
Deliveryについてはちょっと難しいが、「約束した期日に約束した機能が利用可能になること」が求められると捉え直せば分かりやすい。
例えば、エピック（アジャイル開発における作業単位の一つ）単位で優先順位をつけ、ロードマップを引いたとしよう。市場とユーザーを理解していれば、直近の優先順位はそうブレることはない。先のものは「やってみてからどちらが大切かを決める可能性」はあるが、変更の際に、その都度しっかりとコミュニケーションがとれていれば、必ずしも厳格にスケジュール通りでなくとも認められるはずだ。
また、機能をプロダクトバックログに落とし込んだ時、仕様や要件をガチガチに決めずに、チケット単位で機能の一部の優先順位を下げてスコープアウトして「改善アイテム」にすることもできる。木下氏は、「スコープには広さだけでなく深さもあり、それを浅くすればデリバリーの期日に間に合わせる調整弁となる。アジャイルかウォーターフォールかというフレームワークに関わらず、求められていることと実際に行うべき解決策にフォーカスして考えると、案外突破口はあるのではないか」と語った。
木下氏は、「不可解で不合理に見えても、その社会・文化の中での合理性が必ずあり、その理解を深めなければ一緒に仕事をしていくことは難しい。そこで良い悪いという判断は留保し、まずはその文化がどのような合理性で駆動しているのかを観察し、理解していくことが重要だ」と語り、「さらに理解できても、合意形成の重力に抗えばうまくいかない。かといって、迎合して同化するのもうまくいかない。『どっちも』を取れる突破口を常に考え続けることが大切」と改めて強調した。
とりわけベンチャーと大手の論争の種になりやすい、「アジャイルかウォーターフォールか」については「まぜるな危険」と言われることも多く、調整は難しい可能性がある。しかし、プロジェクトが前に進まないことより、「たとえアンチパターンである可能性があっても、うまくいく方法を考え続け、進み続ける方が建設的ではないか」と木下氏は語り、「プロダクトマネージャーの最も重要な役割は、さまざまなステークホルダーの文化と文化の間に橋を掛けること」と言い切った。そして、「お互いの文化を理解し、その理解に基づいて、お互いが合意がしやすい解決策を考えていく。そのためにメタ認知を活用してみてほしい」と語り、セッションのまとめとした。
