20 並列で開発者が PM 化する——受容設計がボトルネックになる現場
はじめに
この稿は、日本の現場で「AI を導入したのに効果が言えない」と悩む方に、1 つの個人の実践記から答えます。
採用は進みました。けれど、成果を数字で示せと言われると何を出せばよいか分からない。その理由の 1 つは、効果を測る物差しを持っていないことです。では、実際に AI でほぼ全部のコードを書かせた人は、何を物差しにしたのでしょうか。
20 並列で起きた役割の変化
Zenn で 2026 年 10 月 10 日に、welchi 氏が実践記を公開しました。その記事によりますと、AI エージェントを 10〜20 並列で回すと、エンジニアの仕事が PM（プロジェクトマネジャー）の仕事に近づくそうです。
2 か月ほどで、AI が書いた行は延べ約 370 万行（平均 1 日 5 万行）になりました。そのうち本番の判定の入口からつながるコードは約 4 万行、現在の開発ブランチに残っている量は約 58 万行です。コミットは 5,699 件、PR とイシューは 261 件と 229 件でした。
これらの数字は、あくまで 1 人の開発者の案件における途中経過（2026 年 10 月上旬の時点）です。正式な調査報告ではなく、個人の実践記です。
ボトルネックの正体
注目すべきは、コードを書く時間ではなく、AI の成果を受け入れる仕組みに時間が向いたことです。
welchi 氏は、作業役・統括役・相談役・評価役と役割を分け、作業した AI とレビューする AI を別の会話にしています。作業した AI が自分でマージしない仕組みです。また、終わったかは「測った・報告した・自分が確認した」の 3 つの証拠がそろった時だけ、終了とみなす決まりにしています。
つまり、多産した出力をどう受け入れ、何を人が握るかという「受容設計」が、並列開発の鍵になっています。
日本の現場との対比
この知見は、日本の現場でよく聞く「採用は進んだのに、効果を数字で示せない」という構造と重なります。効果が言えない理由の 1 つは、測る物差しの不在でした。
welchi 氏の場合、物差しは個人が作っています。製品には DORA の指標（リードタイム、デプロイ頻度、復旧時間、失敗率、やり直し率の 5 つ）を使っています。ハーネスには「同じ失敗の繰り返し」や「マージ前のチェック待ち」など、12 個までの指標を週 1 枚にまとめます。DORA の 2025 年報告では、回答者の 90% が仕事で AI を使い、80% 超が生産性向上を感じたとされます（二次引用、原文は未取得）。同報告は、AI がスループットとは正の関係、デリバリーの安定性とは負の関係にあるとも述べています。
技術者が持ち帰れるもの
AI を 1 つ使う場合でも効く原則が 3 つあります。
受け入れの判定を先に決める。 AI に頼む前に、終わったことを何で確かめるかを定めます。
長い会話は引き継ぐ。 決まったことと次の作業を短く書き出し、新しい会話へ渡します。
同じ失敗を 2 回したら仕組みにする。 注意の文を足すのではなく、チェックか記録の仕組みにします。
これらは、制度を変えなくても技術者が今日から始められる受容設計です。
参考情報
- welchi 氏「AI を 1 つ使う開発から、任せて回す開発へ：20 並列で学んだ役割分担と仕組み」、Zenn、2026 年 10 月 10 日公開。一次資料（本人の実践記）。取得経路は Zenn の当該記事。
- 数値（約 370 万行、約 58 万行、約 4 万行、コミット 5,699 件、PR とイシュー 261 件と 229 件）は、同記事内の「2026 年 10 月上旬の時点」の途中経過。正式報告ではない旨を記事内で確認。
- DORA の指標（5 つ）と 2025 年報告の引用は、welchi 氏の記事からの二次引用。DORA 一次報告は未取得。
- 背景文献として、OpenAI が提唱する「ハーネスエンジニアリング」の考え方と、Anthropic の「効果的なコンテキストエンジニアリング」の解説がある。いずれも、同記事が参照している。
本記事は AI の支援を受けて執筆されました。事実の確認と内容の責任は筆者にあります。