社長はPMと話すだけ ― Claude Codeで仮想外注ソフトウェア会社をつくり、外注費をゼロに近づける

私はいま、ソフトウェア開発の外注費をほぼゼロにすることを目標に、仕事の進め方を組み替えています。外注先を探すのをやめ、Claude Codeの中に「仮想の外注ソフトウェア会社」をまるごと一社つくることにしました。

この会社で、私は元請けの社長です。話す相手はPM一人だけ。PMの指示で、要件定義担当、設計担当、実装担当、テスト担当、セキュリティ監査担当といったAIエージェントが、案件の規模に応じて数十から数百並行で動きます。

外注先は、もう社内にいる

これまでの外注は、日本で設計してオフショアで実装し、品質の差を受入検査で埋める、という分業でした。しかし実装の大部分をAIが担える今、この分業で外に払っていた費用のほとんどは、社内の仕組みに置き換えられます。

この記事では、その仮想会社の組織と、開発の全工程をPDCAとして回す仕組みを紹介します。サイクルを回すほど会社自身が賢くなり、品質が上がっていく。その構造を伝えるのがこの記事の目的です。

ただし、先にはっきり書いておきます。外注をやめるということは、外注先に引き取ってもらっていた開発の責任も、すべて自社に残るということです。外注費ゼロは、責任ゼロではありません。この記事で一番伝えたいのは仕組みの作り方よりも、この責任とコストのバランス感覚です。後半で詳しく述べます。

仮想外注ソフトウェア会社の組織図

仮想会社は、人間のソフトウェア会社と同じように部門を分けて設計しています。違いは、全員がClaude Codeのサブエージェントだということと、開発部の人数を案件ごとに自由に増減できることです。

最初にSDLCをエージェント化したときは、要件定義、実装、レビュー、振り返りの4役しかいませんでした。実際に案件を流してみると、外注会社として回すには足りない役割がはっきりしました。社長の窓口になるPM、作業を並列化できる単位に分けるアーキテクト、並列で作ったものをまとめる統合担当、外注費との比較に欠かせない原価管理担当などです。

特に重要なのは、図の一番下にある改善室です。改善室は開発には一切関わらず、各部門が記録した数値だけを見て、社内ルールの改善案を週に一度、社長に提出します。この部門があることで、会社全体がサイクルを回すたびに賢くなっていきます。

社長はPM一人と話すだけ

社長である私が仮想会社と接する窓口は、PMエージェントただ一人です。社内に何十人のエージェントがいても、私がその一人ひとりに指示を出すことはありません。人間の会社で、元請けの社長が下請けのプログラマーに直接電話しないのと同じです。

1つの案件は、次のような会話で進みます。

1. 発注：「入居者がLINEから写真付きで修繕依頼を送れるようにしたい。来月中に」と、PMに一言伝えます。
2. 見積と提案：PMは社内で要件定義と見積をまとめ、受入基準の一覧、作業の分割数、想定原価、リスクを1枚の提案書にして返してきます。
3. 決裁：私が見るのは提案書だけです。受入基準が意図とずれていれば直させ、問題なければ「進めて」と返します。
4. 進捗報告：開発中、私から問い合わせない限りPMは黙々と進めます。判断が必要な事態（予算超過、仕様の矛盾、外部APIの制約など）が起きたときだけ、選択肢つきで相談が来ます。
5. 納品と検収：テストとレビューを通過した成果物が、受入基準ごとの検証結果を添えたプルリクエストとして届きます。私が確認してマージすれば検収完了です。
6. 週次の改善提案：週に一度、品質管理部門から「今週の不具合の傾向と、ルールの改善案」が届きます。採用するかどうかを決めるのは社長の仕事です。

社長の仕事は「何を作るか決める」「受入基準を承認する」「改善案を採否する」の3つに絞られます。それ以外の判断は、決裁権限表に従って社内で完結させます。

各フェーズを、それぞれPDCAにする

この仕組みの核は、SDLCの各フェーズの中にもPDCAを入れることです。要件定義も、実装も、テストも、それぞれが「計画→実行→振り返り→改善」を自分の中で回してから、次のフェーズに成果物を渡します。考え方の土台は、以前の記事「AI時代のいまさらPDCAサイクルが最強だった話」で紹介したものです。

ポイントは「振り返り」を必ず数値で行うことです。受入基準の件数、テストのカバレッジ、レビューで出た重大指摘の件数、差し戻しの回数などを、すべてのフェーズで記録します。AIに「よさそうですか？」と聞いて「よさそうです」と返ってくるような判定は、仕組みの中に一つも置きません。

もう一つのポイントは、作った本人に採点させないことです。実装担当とレビュー担当は別のエージェントにし、レビュー担当には実装担当の説明を渡しません。人間の組織で開発部門と品質保証部門を分けるのと同じ理由です。

SDLC全体を円にする

一般的なSDLCは、要件定義から運用までの一本道です。アジャイル開発でこの道を何度も往復しても、往復の仕方そのものは変わりません。仮想会社では、運用の後に「振り返り・改善」を置き、その結果で社内ルールを書き換えます。次の案件の要件定義は、書き換えたルールを読んでから始まります。こうしてSDLCは一本道ではなく、円になります。

この円は、速さの異なる3つのループでできています。①と②は「作ったもの」を直すループです。③だけが「作り方」を直すループです。品質が上がり続けるかどうかは、③が回っているかどうかで決まります。

たとえば、ある週の振り返りで「権限のないユーザーに関する指摘が2案件続けて出ている」と分かったとします。改善室は「認証が絡む機能では、ロールごとに受入基準を最低1件ずつ書く」というルールを提案します。社長が承認すれば、翌週からは要件定義担当が最初からその観点を入れてきます。同じ種類の指摘は、それ以降出なくなります。

逆に、追加したのに同じ問題が続くルールは、効果がなかったとして削除か書き直しの対象になります。ルールが増え続けて会社が重くなるのを防ぐためです。

毎週の品質の推移は、次の4つの指標で追います。実測値の公開時期は未定です。

• 1案件あたりの差し戻し回数
• ゲートの不合格率
• レビューでの重大指摘の件数
• リリース後の本番エラー率

数十〜数百のエージェントを並行稼働させる

並列数を増やすこと自体は難しくありません。難しいのは、並列で作ったものが最後に一つにまとまることです。人間の開発チームでも、人を倍にしても速度は倍になりません。AIでも同じ問題が起きます。

仮想会社では、次の4つの考え方で並列化しています。

1. 分けられる単位まで設計で分ける：アーキテクト担当が、作業を「互いに同じファイルを触らない」チケットに分割します。チケットどうしの依存関係も明示します。並列度を決めるのは、エージェントの数ではなく、この分割の質です。
2. 作業場所を物理的に分ける：エージェントごとに独立した作業ディレクトリとブランチを与えます。他のエージェントの書きかけのコードは見えません。
3. 依存関係の順に、波状に投入する：依存のないチケットを一斉に流し、終わったものから次の波を流します。同時稼働数には上限を設け、APIの利用制限や原価を超えないようにします。
4. 統合担当がマージの順番を管理する：完成したチケットは統合担当がテストを通しながら順番にまとめます。衝突が起きたチケットは、修正指示つきで元の担当に戻します。

1つのClaude Codeセッションの中で同時に動かせるサブエージェントには限りがあります。そのため数百規模で動かすときは、PMのセッションが「発注元」となり、複数のClaude Codeを裏で起動して、チケットを配り、結果を回収する構成にしています。社長から見える窓口はあくまでPM一人のままです。

並列数を増やすほど、分割の失敗のコストも大きくなります。だからこそ、先に述べた③のループが、分割ルールそのものを毎週見直す対象にしています。分けたときに何が壊れやすいかは、マルチエージェントの破綻点の記事でも整理しました。

外注費ほぼゼロの経済性

外注費がゼロになっても、原価はゼロにはなりません。外注費の代わりに、AIの利用料と、社長である私の判断の時間が原価になります。大事なのは、この原価を案件ごとに見えるようにすることです。

そこで仮想会社には経理部門にあたる原価管理担当を置き、案件ごとに次の項目を記録させています。

実際の案件は、案件名、従来の外注で見積もった場合の金額、仮想外注会社でのAI利用料、社長の作業時間の4項目で比較します。具体的な数値の公開時期は未定です。

「ほぼゼロ」と言うのは、外に出ていくお金がAIの利用料だけになるという意味です。もう一つ大きいのは、外注では毎回リセットされていたノウハウが、社内の仕組みとして蓄積され続けることです。この点は、金額以上に効いてきます。

責任は外に出せなくなる：この記事で一番伝えたいこと

外注費がゼロになるとき、同時に失うものがあります。それは「責任の一部を外に出すこと」です。AI仮想開発会社をつくると、開発の責任はすべて自社に残ります。私はこの点こそ、導入を考える経営者が最初に理解すべきことだと考えています。

外注費には「責任の代金」が含まれていた

外注先に払うお金は、作業の対価だけではありません。請負契約であれば、外注先は完成させる義務と、不具合があったときの修補や賠償の責任を負います。納期遅延や人員確保のリスクも、外注先が引き受けています。つまり外注費には、「リスクを引き取ってもらう代金」が含まれていたわけです。

AIは、どれだけ優秀でも責任を負いません。不具合で顧客に損害が出ても、修補を請求する相手も、賠償を求める相手もいません。AI仮想開発会社で削減できるのは作業の対価であって、リスクの引き受け手までは置き換えられません。

ただし、外注でも責任は全部は移らない

一方で、外注すれば責任を丸ごと手放せるわけでもありません。元請けとして顧客から仕事を受けていれば、下請けの不備であっても、顧客に対して謝り、直し、説明するのは元請けです。外注で外に出せるのは、作業をやり直させる相手と、お金を請求できる相手です。顧客への信用と説明責任は、もともと元請けに残っています。

こう整理すると、問いは「外注かAIか」ではなくなります。「この案件のリスクを、自社で引き受けるべきか、お金を払って外に引き取ってもらうべきか」という、経営の判断になります。

責任の置き場所を決める2つの軸

私は、案件ごとに2つの軸で判断しています。不具合が起きたときの影響の大きさと、自社で品質を検証し、顧客に説明できる力です。

AI仮想開発会社が力を発揮するのは右下です。影響が大きい領域でも、検証力があれば内製はできます。ただし、削減した外注費の一部を「責任を支える装備」に回すのが前提です。左上の領域まで無理に内製するのは、節約ではなく、保険を解約したのと同じことです。

責任を引き受けるための装備

責任が自社に残るなら、それを引き受けられる体制を意図的に作る必要があります。私が仮想開発会社とセットで考えているのは次の5つです。

1. 品質の証跡を残す：受入基準、検証結果、レビューの指摘、差し戻しの履歴をすべて記録します。不具合が起きたとき、「どういう基準で、どう検証して納品したか」を顧客に示せることが、責任を果たす第一歩です。前の章で紹介したPDCAの数値記録は、そのままこの証跡になります。
2. 人間が判断する場所を決めておく：受入基準の承認、本番デプロイ、ルール変更は社長が決めます。責任を負う人が、責任を負う判断をしている状態を保ちます。
3. 第三者の目を買う：影響の大きい案件では、セキュリティ診断など外部のレビューを入れます。外注するのは開発ではなく「検証」です。
4. 保険で金銭的なリスクを移す：IT業務の賠償責任保険やサイバー保険は、外注先が担っていた「賠償の引き受け手」の代わりになります。保険料は、削減した外注費と比べて判断します。
5. 顧客との契約で責任の範囲を決める：受託案件では、請負か準委任か、責任の上限をどうするかを契約で明確にします。外注先に移せなくなった分、入口で責任の大きさを調整します。

契約や保険の具体的な設計は、案件ごとに弁護士や保険の専門家に確認してください。

責任が残ることは、弱点であり強みでもある

責任が自社に残ることは、重荷です。しかし裏を返せば、品質を自分の言葉で説明でき、ブラックボックスがなく、失敗から学んだことが社内に蓄積されるということです。外注先で起きた失敗は、多くの場合その会社の中で終わります。仮想開発会社で起きた失敗は、翌週のルールになります。

だからこそ、この記事で紹介した自己改善の仕組みは、効率化のためだけのものではありません。責任を外に出せない会社が、責任を引き受け続けられるようにするための仕組みです。外注費ゼロを目指すなら、このバランス感覚を持った上で、右下の領域から始めてください。

限界と、社長に残る仕事

この仕組みは万能ではありません。導入を考える方のために、現時点で見えている限界も書いておきます。

• 何を作るべきかは決められない：AIは受入基準を満たすものを作れますが、その受入基準が事業として正しいかは判断できません。ここは社長の仕事として残ります。
• 分割できない仕事は並列化できない：全体に波及する設計変更や、既存の大きな負債の整理は、並列度を上げても速くなりません。
• 自己改善はルールを緩める方向にも働きうる：エージェントが「ゲートを通りやすくする」改善を提案してくることがあります。そのため、ルールと閾値の変更は必ず社長の承認を通すようにしています。
• 原価は青天井になりうる：並列数を上げれば、AIの利用料も比例して増えます。同時稼働数の上限と、案件ごとの予算上限は必須です。
• 本番の権限は渡さない：本番環境の認証情報や、取り消せない操作は、人間の承認を通す設計にしています。

裏を返せば、社長に残るのは「何を作るか」「どこまでの品質を求めるか」「どの改善を受け入れるか」を決める仕事です。これはまさに、元請けの社長が本来やるべき仕事そのものです。

まとめ

• 外注先を探すのをやめ、Claude Codeの中に仮想の外注ソフトウェア会社をつくった。
• 社長はPM一人と話すだけ。社内では役割分担されたエージェントが、案件に応じて数十〜数百並行で動く。
• SDLCの各フェーズの中でPDCAを回し、数値で振り返る。
• 毎週の振り返りで、社内ルールそのものを書き換える。だからSDLC全体が円になり、回すほど品質が上がる。
• 外に出ていくお金はAIの利用料だけになり、ノウハウは社内に残り続ける。

そして何より、外注費と一緒に、責任を外に出す手段も手放すことになります。削減した外注費の一部を、品質の証跡、第三者の検証、保険、契約の整備といった「責任を引き受ける装備」に回すこと。そして、責任を持てる領域から始めること。これが、AI仮想開発会社を事業として成り立たせるためのバランス感覚です。