アジャイル開発＆インプロセスQAという神話があります。
高速に顧客へ届ける価値を検証し、短いリリースサイクルで改善を重ね、プロダクトの価値を高めていく開発スタイル。
一見、どこにも誤りがなさそうです。
私には、その「誤りの無さ」「あまりにも正しすぎる姿」が、不気味に見えることがあります。
あまりにも正解すぎる構造
アジャイル開発は、顧客への提供価値を第一に置いています。
インプロセスQAは、開発チームとの協調を第一に置いています。
どちらも、誰が見ても正しそうに見える。隙がなさそうです。
この隙のなさが、私には非常に怪しげに見えています。
明らかな弱点があるウォーターフォール開発＆フェーズゲートQA
対して、ウォーターフォール開発＆フェーズゲートQAはどうでしょうか。
ウォーターフォール開発は変化に弱く、最初に握った要件から最終成果物までの距離が遠い。顧客が価値を検証できるのは、ずっと後になってからです。
フェーズゲートQAもまた、リリースサイクルを遅らせる要因となり得ます。テストがボトルネックになることすらあります。
このように、誰がどう見ても、構造上、明確な弱点がある。
しかし、なぜか私は、この「明らかな不正解」としてのあり方が、かえって思考の強度を保つのではないかという感覚を持っています。
明らかな正確さは思考を奪う
弱点があれば、それを補強する対策を講じます。ウォーターフォール開発だけど、プロトタイピングをして先に顧客に触ってもらおう。フェーズゲートQAだけど、開発チームとの距離を近くして、情報をもっと得て協調できるようにしよう。
しかし、アジャイル＆インプロセスQAはどうでしょうか。そのあまりにも正しすぎるあり方がゆえに、自己批判的な姿勢を失いつつあるのではないかと、私は怖くなることがあります。
確かに、顧客への価値に目を向けるのも、開発チームと協調するのも重要です。
それでも、真に「完全完璧な開発スタイル」というのは、存在しないのではないですか。
そんなものがあったとしたら、「完全完璧なアジャイル開発」として、これ以上の変化を拒む自己矛盾的な存在になるのではないですか。
まとめ
私は別に、アジャイル開発もインプロセスQAも否定していません。
ただ、その「良さに対して、疑問を差しはさむ余地のなさ」に対しては、明確に否定しておきたいです。
