何が起きているのか
LLMの普及で個人のコード生産量は急増し、企業はソフトウェア開発を「生産システム」として再設計し始めています。VentureBeatの記事「The Era of the Software Factory」は、従来のSDLCやCI/CDがAI生成コードの圧力に耐えられないと警鐘を鳴らしました。
Faros AIの調査では、開発者あたりのタスク処理量が33.7%、PRマージ率が16.2%向上した一方、インシデント/PR比は242.7%、開発者あたりのバグは54%増加しています。GoogleのDORA調査でも、AI採用の拡大はデリバリーの安定性悪化と相関していました。
なぜ重要か
論点は「速く書けるか」から「そもそも書くべきか」に移っています。出力が増えれば欠陥も増え、小規模組織のコードベースが10年前のテック企業並みに膨張する現象も起きています。寄稿者は1年で2件のAI生成データ基盤プロジェクトを観察し、わずか数か月で5〜6種類のコードスタイルが混在する事態を確認しました。これは10年前のセルフサービスBI普及期に起きた「初期の生産性向上が後段の複雑性を覆い隠す」パターンの再演です。
ソフトウェアファクトリーの設計原則
記事は、ツールの寄せ集めではなく「プラットフォーム」として設計することを求めます。具体的には、ツール同士がデータを共有し連携する統合基盤、シリアルIDから出力までを追跡できる再実行性とトレーサビリティ、ループではなくステートマシンによる制御、安全性とガードレール、標準化、品質管理の5原則です。
特に標準化と品質管理は「あとで足す」ではなく仕様記述の段階から組み込む必要があります。トヨタ生産方式が「異常があればラインを止める」発想で品質を工程に埋め込んだのと同様、静的解析やLLM向けテンプレートをスペック作成時から組み込むべきだ、というのが筆者の主張です。
💼 事業会社視点：これは自社にどう効くか
日本のSIer・受託開発企業にとって、これは「請負契約のリスク構造の再定義」を迫る話です。開発者あたり54%のバグ増は、瑕疵担保期間中の手戻り工数を直接押し上げ、固定価格案件の粗利を侵食します。Copilotを全エンジニアに配布して「生産性30%向上」を経営層に報告している企業ほど、半年後にインシデント対応で利益が消える構図に陥りやすい。
SaaS事業者は、機能リリース速度と障害発生率のKPIを切り離して見るべきです。PRマージ率16.2%向上をボードに報告する前に、インシデント/PR比を同じダッシュボードに並べる運用が必要です。
事業会社の経営者・CTOが今動くべきは、(1)スペック段階で静的解析とテンプレートを強制するレビュー基準の整備、(2)コーディング規約のLLM向け明文化、(3)「コード量」ではなく「本番で生き残った機能数」を生産性指標に置き換えること。Excelの延長で内製を増やしたい部門には、ガードレールなしのAI開発を許可しないルールが先に要ります。
