アジャイル開発は必ず2度失敗する～「正しいものを正しくつくる」の感想

「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を読んだ。
この本はいいね。
アジャイル開発、スクラムを実践してきた人が、その経験を振り返って書いているので、すべての文章に重みがある。
たぶん、こういう苦労をしてきたのだろう、という想像ができる。

「アジャイル開発は必ず2度失敗する」というフレーズにしびれた。

【1】「アジャイル開発は必ず2度失敗する」とはどういう事なのか？

【2】アジャイル開発を導入した初めてのチームは、最初の壁にぶつかる。
それは、成長しないこと。
スクラムであれば、チームはスクラムもどきのプロセスでしか運営できず、本来のスクラムのプロセスを忠実に再現できていない。
たとえば、デイリースクラムやスプリントバックログはできても、スプリントレトロスペクティブをスルーしてしまい、スクラムの検査と適応が不十分になる。
結局、チームはたくさんのスプリントをこなしても、その経験を活用しきれていない。
つまり、「正しく作る」というプロセス面に問題がある。

特に、「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」では、プロダクトオーナーの役割についてフォーカスを置いている。
なぜならば、スクラムを導入すると、チームは開発に専念すればよく、技術者主体なので自分たちのペースで開発しやすくなる
しかし、プロダクトオーナーになった人は、スクラムを導入するとそういう役割をいきなり任されてしまい、どのように振る舞えばよいか、分からない場合が多いからだ。
実際、プロダクトオーナーになる人は、システム提案やシステム企画、ユーザ部門に関わる人だろうから、それほど技術面に詳しいわけでもなく、要件定義の技法を知っているわけでもなく、単にそのドメインに詳しいだけであって、開発者に整理された仕様を伝えるスキルがないからだ。

そこで、プロダクトオーナーに足りないスキルはチームの別メンバーがカバーするなどの解決法を提案している。
この点は、著者の経験が出ているなと思う。

【3】次の壁は、「間違ったものを作ってしまう」こと。
チームがスクラムをスムーズに運用できるようになると、定期的にプロダクトをリリースできるようになる。
しかし、実際に顧客に提供してみたら、本来欲しいものはそれではなかった、と突き返されてしまう。
「オレゴン大学の実験」の話と同じ。
つまり、チームは生産性は高いものの、高速に価値のないプロダクトを作り出しているだけ。
すなわち「正しいものを作る」という要件定義、要求開発の部分に問題がある。

［姿勢編］理由無き要求は機能化してはいけない | 日経クロステック（xTECH）

こういう話を聞くと、クネビンフレームワークの複雑系の問題を連想する。

クネビンフレームワークについて講演してきました | サーバントワークス株式会社

複雑系の問題では、正解がないから、過去の知見を利用できない。
実際に調査して、試してみて、初めて因果関係らしきものが分かるが、それでもその複雑性を完全にコントロールできるわけではない。
複雑系の問題では、調査→把握→対処という順番で解決するしかない。

「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」では、仮説検証やMVP以外にも数多くの手法を紹介して、「正しいものを作る」命題に対処しようとしている。
おそらく著者の市谷さんの数多くの経験が盛り込まれているのだろうと思う。