AIで機能リリースを爆速にしたら、誰もついてこれなかった話『「ザ・ゴール」シリーズ 在庫管理の魔術』

スピードを爆上げして、価値を届ける

2025年度、現場のエンジニアたちによるDevinやCursor、Claudeの検証を終え、強力なエンジンを手に入れたと確信した私は、 2026年度 Claude Codeの組織的な採用を判断しました。
機能リリースのスピードを爆上げし、顧客へいち早く価値を届ける。つい半年前の私は、そんな期待に胸を躍らせていました。

4名から2名へ、生産性が爆上がりした現場

AI前提の開発フローが明文化され、プランニング当日の午後には実装が完了し、翌朝にはプルリクエストが出る。そんなスピード感が当たり前になりました。かつて4名で回していたスクラムチームは、AIを活用することで2名で動くようになりました。

スクラムチームあたりの人員を減らしても、世の中に送り出せるPBIの量は一気に倍増しました。画面の向こうで、AIが標準化されたワークフローとしてPR作成からレビュー、分析からイシュー作成までを数分で終わらせていく。私はその光景を見て、少数精鋭のまま、圧倒的な速度で市場を制覇できるとほくそ笑んでいました。

「もう、新機能のユースケースが追えません」

開発の馬力が2倍になれば、当然、その前段の工程が詰まります。そう考えて、私は先手を打っていました。

• PDMとプロダクトデザイナーを採用しそれぞれ倍増しました。

• プロダクトデザインのツールをFigmaからClaude Designに切り替えました。

• VOCからAIが自動でイシューを生成し、PDMがapproveするだけで、GitHub projectsにPBIが起票されるようにしました。

QAが検知する軽微なバグや改善は、PDMの工数を奪うことなく、2名体制のスクラムチームが自律的に片付けていく。一本のきれいな生産ラインが繋がった、と信じて疑わなかった私を待っていたのは、週次のスプリントレビューでの違和感でした。

ビジネスチームを交えて、開発した機能がユーザーの期待値に合致しているか目線合わせを行う場。そこで私は、メンバーたちの温度が次第にずれ始めていることに気づきました。毎週新しい機能がリリースされ大喜びのセールスとは裏腹に、CSからは既存機能やユースケースとの整合について確認が増えていました。機能リリースの速度に、人間の認知が追いついていけなくなっているようでした。

届けた新機能が、誰にも使われないまま放置されていく。開発スループットの向上に、一人で浮かれていた自分が急に恐ろしくなりました。

形にするのは一瞬、確かめるのは地獄

さらに深刻な事態が、開発チームの内側でも静かに首を絞めにきていたのです。コードが秒速で生成されるようになった結果、現場には「検証と判断」という底なし沼が出現しました。AIが実装を担うようになればなるほど、人の役割はすべてレビューへと移動します。

• AIが生成した膨大なコードを深く読み解き、真の品質を見極められるシニアエンジニアの時間が足りない。

• QAで検知するbugが増えたが、コードの調査に時間を要しどこまでリリースして問題ないかPDMが判断できない。

• AIが生成したコードの他チームが開発する機能への影響を考慮できず、デプロイ後にerrorが頻発する。

品質のガードレールをAIで補助しようと考え、テストの充足度を評価するコマンドを組み込み、QAプロセスへAIを織り込むプロジェクトも立ち上げました。
それでも、現場の忙しさは一向に消えません。上手くいかなかったプロンプトやルールを、メンテナンスし続ける終わりのない運用負債。それらのノイズに、人間の貴重なエネルギーが確実に削られていきました。

完璧な布陣を敷いた、という錯覚

人の認知限界という目詰まりを解消するため、私はさらに新しい手を打ちました。

全エンジニアのうち10％のメンバーを、FDE（Forward Deployed Engineer）にアサイン。一部のエンジニアを開発の現場から引き剥がし、顧客インタビューや営業プロセスの改善活動へと直接従事させました。プロダクトを作る速度を上げるのではなく、顧客の受容性を高めるために、エンジニア自らが顧客が本当に必要なことが何かを掴みに行くための配置でした。

プロダクト開発の上流も下流も、打てる手はすべて打ち、後は現場の歯車が正しく噛み合うことを見届けるだけだと思っていました。

誰も触らない新機能という負債

本書で描かれるのは、仕入れた商品が店舗の棚を圧迫し、キャッシュフローを殺していく小売業の悲鳴です。売上を最大化しようと仕入れを増やしても、客が買わなければそれはすべて過剰在庫という名の負債になる。その絶望的な構造は、今のソフトウェア開発の現場と完全に地続きでした。

どれだけ効率よくコードを書き、どれだけ高速に本番環境へデプロイしたところで、ユーザーがその変化を認知し、便益に繋げなければ、それは単なる「動く不用品」という名の在庫にすぎません。

AIというアクセルを手に入れたことで、私は在庫を量産するスピードを2倍にしてしまっただけでした。

アクセルを踏み続けるのをやめる覚悟

プロダクト開発のメソッドは、「早く出して小さく検証せよ」と急き立てます。しかし、現実は、出す速度が受け入れの限界を超えた瞬間に、機能の墓場と化します。
現場もユーザーも、変化の速度が限界を超えた瞬間に、静かに思考を停止してしまうのです。

ここから先は、綺麗事のプロセス論ではありません。ユーザーの認知という「最後の制約」の前に、開発リーダーがどうやってブレーキを踏み、真の価値を届けるかという生存戦略の話をします。