学習速度という競争優位
AIによるコーディング支援がソフトウェア開発に必要なコスト、スキル、時間を着実に削減しているという事実を所与のものとしよう。（中略）プログラムを書くコストが昨日より今日、安くなっているのなら、私たちは今日プログラムを書く可能性が高くなるはずだ。しかし、もし明日になればもっと安くなるのなら、コストがゼロになるまで待てばよいのではないか？
ケント・ベック氏が自身のブログ記事 Programming Deflation で投げかけたこの問いは、生成AIという不可逆な変化の渦中にいる私たちの足元を鋭く照らし出している。コードを書くという行為の経済性が根本から覆されつつある今、その圧倒的な生産性を、私たちはどこへ向けるべきなのだろうか。目先の開発コスト削減に安住していては、本質的な価値を見失うことになる。 価値の源泉は「実装」から「統合」へ
ベック氏が指摘するように、プログラミングのデフレは、価値の源泉が根本的にシフトしたことを意味する。コードを書く行為そのものは、やがて文字をタイプするような基本的なスキル、すなわちコモディティ（ありふれたもの）になる。 誰もが安価にコードを生成できる世界で、本当に希少で価値ある能力とは何だろうか。
それは、「何を創るべきか」という問いを立てる判断力であり、無数に生み出される安価なソフトウェア部品を組み合わせ、首尾一貫したシステムとしてまとめ上げる統合力だ。
ビジネスや顧客の課題に対する深い理解に基づき、個別の機能ではなくシステム全体を俯瞰して最適な構造を考えるシステム思考。これからのエンジニアや組織に求められるのは、こうしたAIには代替不可能な、より高次の知的能力である。
組織が得るべきAIの真のメリット
この価値観の転換は、組織が生成AIから得るべきメリットを再定義する。多くの組織がAI導入の目的を「開発コストの削減」や「生産性の向上」に置いているが、それはあまりに近視眼的だ。
AIがもたらす真の価値は、組織の「学習速度」を爆発的に高めることにある。
これまで、新しい事業アイデアや業務改善の仮説を検証するには、相応の時間とコストが障壁となっていた。これが、組織が市場から学ぶ速度を制限する最大のボトルネックだった。
しかし、生成AIはこの「実験コスト」を劇的に引き下げる。エンジニアはもはやゼロからコードを書くのではなく、AIとの対話を通じて、アイデアを瞬時にプロトタイプとして形にできる。これにより、組織はかつてないほどの頻度で仮説検証のサイクルを回せるようになるのだ。
競合他社が1年に1度しか学べないことを、1ヶ月に1回、いずれは1日に1回学べるようになる。この 「学習速度」は、不確実な時代における唯一持続可能な競争優位たり得る。
変革を実現するために必要な「2つの役割」
では、この「学習する組織」へと進化するために、リーダーは何をすべきか。そこには、異なる視点とメッセージを持つ2つの役割が必要不可欠だと考える。
一つは、組織全体の「なぜ変わるのか」を定義し、変革の土壌を耕すリーダーの存在。
彼らは、「我々の競争力の源泉は『実装速度』から『学習速度』へ変わった」と繰り返し説き、失敗を許容し、学びを称賛する文化を醸成する。評価制度や予算プロセスといった組織のOSそのものを、「製造モデル」から「実験モデル」へと大胆に書き換える設計者である。
もう一つは、現場チームの「何をすべきか」「どうやるのか」を具体的に示すフォロワーの存在。
彼らは、「君たちの価値は、問いを立て、AIを使いこなし、システムを統合するスキルだ」と語りかける。プロダクションコードをAIに書かせ、そのレビューや検証に頭を悩ませるだけではなく、プロダクトが提供すべき価値は何か、幸せにすべき顧客は誰か、我々は何を創るべきか、そのために検証すべきことは何かを考え抜くための具体的なスキルと思考法を教え、チームが新しい働き方へ軟着陸できるよう伴走する。
より困難なフォロワーロール
生成AIを使って生産性を高めたいと思うのは自然な流れと思われるが、それはビルドトラップと隣り合わせの危険な思考かも
しれない。
フォロワーロールを担う人物は、この罠にチームが陥らないようガードレールとなり、思考のベクトルを「How（どう作るか）」ではなく「What/Why（何を/なぜ作るか）」に向かうよう仕向ける責務を持つ。
さらに、What/Whyを高速に検証し、より価値のあるアプリケーションを開発するために生成AIを用いる術をチームにインストールする形式知も必要となるだろう。
チームにインストールすべき具体的なスキルと思考法の例
スキルセット:
仮説構築スキル: 顧客の課題を「もし〇〇があれば、顧客は△△してくれるはずだ」という検証可能な仮説に分解する能力。
対話型プロトタイピング: 生成AIを壁打ち相手に、アイデアの断片を瞬時にUIデザインやAPI仕様書の叩き台に変換し、チーム内の議論を活性化させるスキル。
顧客インタビュー術: 作ったプロトタイプを携え、顧客から本質的なフィードバックを引き出す質問力。
データ分析能力: 小さな実験から得られた定性・定量データを解釈し、「次は何を学ぶべきか」を定義する力。
思考法（マインドセット）:
Outcome over Output: 「機能をリリースした」というアウトプットではなく、「顧客の行動がどう変わったか」というアウトカムに執着する。
Disagree and Commit（反対して、そしてコミットする）: チーム内で健全な意見対立を奨励し、一度決まった仮説検証には全員で全力で取り組む。
AIは思考のパートナー: AIを単なるコード生成係としてではなく、アイデアの壁打ち相手、リサーチアシスタント、そして凡庸な思考への「ツッコミ役」として活用する。
振る舞いとしては「スクラムマスター」っぽい？
だが、守るべきはスクラムの柱や価値基準ではなく、価値に拘るためのより具体的な振る舞いやマインドセットになるのだろう。（いやスクラムも価値に集中するから同じなのかもしれない。ニュアンスがむずい）
最も重要な責務は、チームの認知資源を常に「価値探索」に向け続けること。
高品質なゴミを量産するのではなく、「顧客が本当に必要だったもの」を最小の労力で探求し、最速で提供し、改善し続けるチームを育てること。
（事業会社の業務システムにあっては、「顧客が本当に必要だったもの」を提供する業務プロセスが、宣言的に行われるようになること）
だがまだ具体性が足りない...