ディスカバリーが本当にボトルネックなのか

プロダクト開発の営みを「ディスカバリー」と「デリバリー」の２つのサイクルに大きく分けたときに、「最近はディスカバリーがボトルネックだ」という声をよく聞く。

AIの力を使って、エンジニアリングの設計や実装、テスト、デプロイ（＝デリバリー）のスピードは格段に速くなった。結果として、その前工程である「なぜ」「何を作るべきか」のところ（＝ディスカバリー）にボトルネックが移動した形。

自分が今いるプロダクト開発チームも、同様にボトルネックが「ディスカバリー」に移ったようにぱっと見は見える。

でも、本当にそうなのか。

「開発コストはほぼゼロになった」「だからプロダクト開発のやり方は根本的に変わる」という声や意見を聞くけど、少なくとも僕自身やその周りでは開発コストはゼロになっていない。AIで加速したとはいえ、設計や実装、テストに工数はしっかりかかっているし、それぞれのフェーズでレビューに工数をかけていたりもする。

もし、本当に開発コストがゼロになったらどうなるだろう。ディスカバリーはもっと「数を打てば当たる」戦略を取れるようになるんじゃないか。トライアンドエラーの回数を最大化できるのではないか

開発コストがかかるから、エンジニアやその作業に手戻りを発生させたくないから、そんな考えが無意識にでも考えをよぎってしまうことで、リスクをとった意思決定ができないとしたら、それはすごくもったいないことだ。

ディスカバリーとデリバリーは地続きだ。デリバリーのスピードは、ディスカバリーの意思決定のしやすさに直結する。デリバリーの質は、次のディスカバリーに必要なアイデアやインサイトを生み出す。

どちらか片方だけにボトルネックを見出して、片方だけをどうにか改善しようとしても、局所最適な結果になってしまう。

ディスカバリーがボトルネックだと感じたら、デリバリーやエンジニアリングをさらに改善することでも、改善できないか考えよう。

開発コストがゼロにはなっていないのが現実。ではゼロにするためにはどうすればいいか。同じアウトプットを同じクオリティで、これまでの半分の時間でデリバリーするには？

個人やチームが、こういう問いに対して答えを出し続けることで、ディスカバリーもデリバリーももっと高速に回せるようになるはず。

そんなことを、とある飲み会で学ばせていただきました。