AIで実装は速くなったのに、なぜアウトカムは増えないのか？ ボトルネックが移った先にあるエンジニアの仕事

【16-C-5】AI時代こそ、スケールしないことをしよう-「作る人」から「なぜ作るか」を考える人へ

　AIコーディングによって実装が速くなった今、チームのボトルネックはコードの外へ移動した。カミナシで新規BtoBプロダクトを開発するソフトウェアエンジニアの清水氏は、AIで機能を大量に作るだけでは意味がないと指摘する。新規プロダクトを開発するにあたって、AIで浮いた時間で取り組んできたのが、現場への直接訪問やドメイン理解、展示会で参加者にサービスを提案して商談を獲得するなど、「スケールしない仕事」だ。現場で一次情報を取りに行くエンジニアの実践から、AI時代に開発者が担う役割の変化を追う。

AIで「速く作れる」時代に、アウトカムは増えているか

　AIの登場によって、コーディングや資料作成といった作業は速くなった。清水氏は、多くのチームで「アウトプット」を出す速度は速くなったはずだとしたうえで、参加者に「AIで速く作れるようになって、『アウトカム』は増えましたか？」と問いかけた。

株式会社カミナシ ソフトウェアエンジニア 清水氏

　同氏はまず、機能をリリースしただけではアウトカムと呼べないと明言する。顧客がその機能を把握し、理解したうえで業務の中で使い、課題が解消されて初めてアウトカムになる。さらに「商談で引きがある」といった、プロダクトが売れる土台になることも求められる。「お客さまから『この機能があるからカミナシを使い続けているんだよね』と言われ、チャーン（解約）を防ぐ。そういうレベルになってこそ、ようやくアウトカムと呼べるものになります」と語る。

　では、AIで機能を大量にリリースし、その中からヒットするものが出ればいいのか。清水氏はこれも明確に否定し、「AIによって作るコストより取り下げるコストのほうが、圧倒的に大きくなりました」と述べる。理解が足りない状態で作った機能は負債につながる。

　清水氏は、負債をリリースの前後で4種類に整理する。まず1つ目は、AIが書いたコードを、なぜそうなっているのかを理解しないことで生まれる「理解負債」だ。コードを書く・設計するという行為はドメインを理解することにつながる。その行為を省いてしまうと、意味が希薄なコードが積み上がり、そこから業務ドメインを見つけることが難しくなる。2つ目はコードの内部品質が劣化する「技術負債」だ。3つ目はリリース後に発生する、誰の課題を解くのかが曖昧で一部の課題しか解決しない「仕様負債」。4つ目は課題は解決したが一部の顧客の業務に組み込まれてしまって取り下げられなくなる「機能負債」がある。たとえ1％のユーザーしか使っていない機能でも、取り下げるにはカスタマーサクセスや他チームと連携し、取り下げのスケジュールや代替手段を顧客に説明しなければならない。後ろにある負債ほど、取り下げは大変になる。

業務理解が浅い状態で開発することで発生する4つの負債

　つまり、AIでコーディングをさらに速くして機能を増やしても、負債が積み上がるだけで顧客の課題は解決しない。では、何をすればいいのか。清水氏が提案するのは2点だ。ひとつは、何を作るか、作らないかという意思決定の確度を上げること。もうひとつは、顧客に届けきるまでの全体の速度を上げること。その手がかりとして、まずボトルネックを見つけようと呼びかける。

ボトルネックがコードの外へ移ったとき、何をすべきか

　『ザ・ゴール』（ダイヤモンド社）は、工場を舞台に生産管理の考え方を描いたビジネス小説だ。同書では、一連の工程のうち最も処理能力が低い工程をボトルネックと呼び、それ以外の工程をいくら速くしても全体は速くならないと説いている。清水氏はこの考え方をソフトウェア開発に当てはめ、「ボトルネックの速度が全体の速度につながります」と話す。手前でいくらAIで大量に作っても、途中に絞られたところがあれば、顧客に届くのはそこを通過できた分だけだ。

　そしてボトルネックは移動する。1つ解消すると、次のボトルネックが現れる。ここ半年〜1年でAIによってコーディングは速くなり、ボトルネックはコードの外に移動した。「移動した先のボトルネックを解消しない限り、全体のスループット、アウトカムは上がりません」と語る。

ボトルネックは移動する