PMがコードをshipした日——AIが「実装コスト」を消して、ソフトウェアの組織図を破壊した

あなたの会社のPMが、昨日自分でコードを書いてプロダクションにshipした——そんな時代が本当に始まっている。

ソフトウェア開発の世界で、数十年ぶりの地殻変動が起きている。「エンジニアが実装する」という大前提が崩れ、PMやデザイナーが直接コードをshipする時代が静かに幕を開けた。

PMが1日でフィーチャーをshipした

Zencoderのアンドリュー・フィレフCEOがVentureBeatに書いた記事が話題だ。

先週、彼の会社のプロダクトマネージャーがフィーチャーを開発して本番にshipした。仕様を書いてチケットを起票したのではなく、自分でビルドしてテストして1日でshipしたのだ。

さらに数日前、同社のデザイナーがIDEプラグインの見た目がデザインシステムからズレていることに気づいた。以前なら、スクリーンショットを撮り、JIRAチケットを作成し、エンジニアに意図を説明して、スプリントに組み込んでもらうまで待つ必要があった。

代わりに彼は自分でAIエージェントを開き、レイアウトを調整し、リアルタイムで試行錯誤して修正をプッシュした。デザインの直感を最も持っている人間が、直接デザインを修正した。翻訳レイヤーは不要だった。

ボトルネックが移動した

2025年にAIファーストへ転換したZencoderでは、実装コストが崩壊した。エージェントがスキャフォールディング、テスト、スプリントの半分を食っていた反復的なグルーコードを引き受けた。サイクルタイムは数週間から数日へ、数日から数時間へと短縮された。

だがその結果、エンジニアリング容量がボトルネックでなくなると、別のことに気づいた。意思決定の速度こそがボトルネックになっていたのだ。

エンジニアリング時間を守るために作ったすべての調整メカニズム——仕様書、チケット、引き継ぎ、バックログのグルーミング——が、今やシステムの最も遅い部分になっていた。もはや存在しない制約を最適化していたのだ。

「実装」より「説明」の方が高コストになった

このパラダイムシフトの核心は、「何かを説明してエンジニアに作ってもらう」より「自分で作る」方が速くなったことだ。

考えてみてほしい。すべての近代的なソフトウェア組織は、「実装が高コストである」という前提の上に構築されている。その前提が崩れたとき、組織自体を変えなければならない。

PMはすでに仕様の言語で考えている。デザイナーはすでに構造、レイアウト、振る舞いを定義している。彼らはシンタックスで考えているのではなく、アウトカムで考えている。インテントを動くソフトウェアに変換するコストが十分に下がったとき、これらの役割は「コードを学ぶ」必要がなかった。実装コストが彼らのレベルまで下がってきただけだ。

複利効果：速度が加速する

さらに予想外だったのが複利効果だ。

PMが自分のアイデアを構築すると、仕様の書き方が鋭くなる。エージェントが何を必要としているかを理解したからだ。鋭い仕様はより良いエージェント出力を生む。より良い出力はイテレーションサイクルを減らす。速度は毎週複利で成長している——モデルが改善したからではなく、それを使う人々が仕事により近づいたからだ。

「インテントとアウトカムのフィードバックループが数週間から数分になった」とPMのドミトリーは言う。「仕様の結果をすぐに見られると、システムが必要とする精度を学び、本能的に提供し始める」

日本のIT組織への示唆

これは50人程度のスタートアップの話ではない。Zencoderでは数十人のエンジニアが複雑な本番コードベースで働いている。複数の言語、エンタープライズ統合、本物の本番システムの重さを背負った上での話だ。

日本の大手SI会社や事業会社のシステム部門はどうだろう。「要件定義→設計→実装→テスト」という分業体制は、実装コストが高かった時代に最適化されたものだ。実装コストが限りなくゼロに近づくとき、この分業体制は「翻訳コスト」の塊になる。

すべてのソフトウェア企業は間もなく、自分たちのPMやデザイナーが、スキルではなく実装コストによってブロックされた、未実現の構築能力を持っていることに気づくだろう。そのコストが下がり続けるとき、組織への影響は計り知れない。

「全員がship」する組織の時代

Zencoderが目指しているのは「ソフトウェアエンジニアリングを加速すること」ではなく、「全員がshipする会社になること」だ。

PMがコードをshipした。デザイナーがバグを直した。「ビルダー」は職種名ではなく、デフォルトの行動になった。

あなたの会社でも、同じことが始まろうとしている。