みなさん、業務システム開発に関わったことはありますか？
この業務システム開発ですが、日本は海外に比べて特殊な構造になっていると感じます。
業務システムは企業の根幹を担う部分であり、AIの社会実装を考える場合、この現状を理解することは非常に重要だと言えるでしょう。
そして、今回はその「日本のIT業界の特殊な構造」に踏み込んでいきたいと思います。
日本のIT業界は一般的に「ウォーターフォール開発」という手法で開発していますが、これについては、前回のブログを読んでいただければと思います。
🏢年表で見る日米IT業界の変遷 🏭
IT業界の仕組みは日本とアメリカで大きく異なります。
この違いを理解しておかないと日本特有の事情を見落とし、AI導入でアメリカと同様の進め方をしてもうまくいきません。
実は、日本とアメリカのIT業界の事情は現在こそ大きく異なっていますが、最初からここまで離れていたわけではありません。
その流れを時代と共に探っていきたいと思います。
📅〘 1960年代 〙
【米国】
冷戦下で国防R&Dが巨大化し、研究投資が制度として継続する土台ができた。
1969年、IBMはハードとソフト／サービスの「別価格」（アンバンドル）を打ち出し、ソフトウェアを独立した商品として扱う市場形成へつながった。
ここで「ソフトはハード販促の付属物」ではなく、「ソフト単体の契約で独立しやすい」方向へ向かっていくことになる。
※R&D：新しい技術や製品を生み出すための研究開発活動
【日本】
1960年代〜70年代初頭にかけ、国産コンピュータ産業の育成・メーカーの協調・補助金の受け皿組織など、政策支援の枠組みが形成される。
この時点では、米国のように「ソフトを独立市場として育てる」より、ハード・周辺・OS・業務をまとめて供給するという、メーカー中心の垂直統合が強かった。
【米国】
アンバンドル後、ソフト／サービスが独立市場として成長し、発注側は「機能を買う」「作業を買う」選択肢を持ちやすくなった。一方、政府調達の規模拡大に伴い契約や下請管理のルール整備が進み、FARとして体系化された。
FARは下請への丸投げを強く制限し、下請前提のビジネスが成り立ちにくくなった。
※FAR：連邦調達規則。米国連邦政府が物品やサービスを調達する際の統一的な規則
【日本】
IBM System/370登場など競争環境の変化に対し、国産メーカーが性能改善と政策支援で対抗する構図が続く。主戦場は依然として大企業・官需の大型計算機であり、「運用も含む一式」志向が残りやすい土壌が作られる。
※System/370：日米の貿易摩擦（繊維など）を背景に日本の電子計算機市場が輸入自由化されると、IBM機が本格参入し、豊富なソフト資産や先進機能、強力な販売・保守体制により、日本メーカーにとって大きな脅威となった。
📅〘 1980年代 〙
【米国】
1981年のIBM PCは、「オープン標準」の採用で他社の参入を促し、短期間で対応ソフトが急増して市場に革命的な変化をもたらした。PCの標準化はソフトウェアの部品的利用を進め、企業ITでも「特定ベンダ一式」以外の選択肢を広げていった。
アウトソーシングが運用・データセンター運営を中心に大型化していき、1989年にはKodakがIBMに新データセンターの設計・運営を委ねたと報じられた。外部化されたのは主に運用領域で、統合や意思決定は発注側に残りやすかった。
※アウトソーシング：企業が自社の業務の一部を外部の専門企業に委託すること。
【日本】
国内PC市場では、日本語処理に強みを持つNEC PC-98の独自規格が事実上の標準となり国内向けソフトは増えたが、世界標準との乖離も招いた。
1988年、増大・複雑化する情報システムを一括して統合管理できる担い手を育成・明確化する狙いから、SI登録・認定制度や税制措置が導入され、SIer（統合請負主体）の位置づけが制度面で強化された。
同時に、コスト低減や業務専門化に加え、終身雇用下で人員運用の柔軟性を高める必要性を背景としてIT子会社化も進展した。
その結果、日本のIT体制では元請SIの下に実装工程を配分する多層分業が定着し、多重下請けが標準的な開発体制として固定化していった。
※NEC PC-98（PC-9800シリーズ）：1980年代から90年代前半にかけて日本のPC市場で事実上の標準となったNECの独自仕様パソコンシリーズ。日本語処理に強みを持つ一方、IBM PC互換機とは互換性がない。
※SI（システムインテグレーション）：企業の情報システムについて、設計・開発・導入・運用をまとめて構築すること。
※SIer（エスアイヤー）：SIの統合構築を請け負う企業（システムインテグレーター）のこと。
📅〘 1990年代 〙
【米国】
1995年にNSFNETバックボーンが退役して商用ネットワークへの移行が進み、インターネットは民間インフラとして本格普及した。
1990年代半ばにはERPが急速に普及し、コンサルティングや導入ビジネスが大きな需要源となったが、ERPはパッケージ中心の「製品＋導入サービス」型で、利用者が製品を選んで組み合わせやすい特徴を持っていた。
そのため、Web化・ERP化の進展とともに、発注者自身が全体構成の選定と統合責任を担う場面も増えていった。
※NSFNET：米国国立科学財団（NSF）が運営した学術向け基幹ネットワークで、初期インターネットの中核基盤。
※ERP（Enterprise Resource Planning）：企業の会計・人事・生産・販売などの基幹業務を統合管理するための業務パッケージソフトまたはその仕組みをいう。
【日本】
1990年、DOS/Vの登場によりIBM互換機でも日本語環境が実用化し、PC市場では世界標準志向が強まった。
しかし、企業の基幹システムの調達慣行はすぐには変わらなかった。大型基幹では個社業務に合わせたスクラッチ開発や重いカスタマイズが引き続き多く、要件を固めて検収するプロジェクト型と親和性が高かった。
この構造の下で、元請SIerの下に実装工程を配分する多重下請け体制も維持・拡大した。
後年のDXレポートも、こうしたスクラッチ偏重や過度なカスタマイズがブラックボックス化を招いたと指摘しており、その土台は1990年代以前から形成されていたと考えられる。
DOS/V：IBM互換PC上で日本語表示・入力を可能にしたMS-DOSの拡張方式。
スクラッチ開発：既存パッケージを使わず、要件に合わせてソフトウェアをゼロから個別に設計・開発する方式。
ブラックボックス化：システムの内部仕様や処理内容が文書不足・属人化・過度なカスタマイズなどにより見えにくくなり、全体構造や影響範囲を把握・変更しにくくなる状態を指す。
📅〘 2000年代 〙
【米国】
2001年、アジャイル（アジャイルマニフェスト）は、短いサイクルで継続的に価値を届ける開発思想を明確に示した。
2006年にはAWSがS3（3月）とEC2（8月）の提供を開始し、インフラをサービスとして調達する選択肢が現実化した。
クラウドの普及により、調達単位は「サーバ購入」から「API経由で利用する能力」へと移り、要件変更に柔軟に対応しやすい反復型の開発・契約と親和性が高まった。
※アジャイル（Agile）：短い開発サイクルで継続的に改善し、変化する要件に柔軟に対応する開発手法・思想。
※インフラ：システムやサービスを動かすための基盤となるサーバ、ネットワーク、ストレージなどの設備や仕組み。
※AWS（Amazon Web Services）：Amazonが提供するクラウドサービス群で、サーバやストレージなどのIT基盤をインターネット経由で利用できる。
※S3（Simple Storage Service）：AWSのオブジェクトストレージで、データを大容量で保存・取得できる。
※EC2（Elastic Compute Cloud）：AWSの仮想サーバサービスで、必要な分だけ仮想マシンを起動・停止して利用できる。
※クラウド（クラウドコンピューティング）：サーバやストレージ、ソフトウェアなどのIT資源を、インターネット経由で必要な分だけ利用できる仕組み。
【日本】
2007年、経産省は情報システムのモデル契約書を公表し、取引慣行の明確化、請負と準委任の整理、マルチベンダ方式や分割発注時の留意点などを体系化した。
これらは取引の透明化を目的としたものだったが、要件確定・検収を重視するプロジェクト型の進め方や、多層的な役割分担を前提とした内容であったため、結果として既存のウォーターフォール型開発や多重下請け構造を維持・固定化しやすい方向に働いた。
2000年代後半にはIT子会社の企画機能を親会社へ戻す動きも一部で見られたが、主導権が大きく移るには至らず、開発体制の基本構造は大きくは変わらなかった。
モデル契約書：取引当事者が契約を結ぶ際の参考として政府や業界団体が示す標準的な契約書ひな形のこと。
請負：成果物の完成を約束する契約形態。完成責任を負う。
準委任：業務の遂行を任せる契約形態。注意義務は負うが、成果の完成までは約束しない。（ITだと期間契約が多い）
📅〘 2010年代 〙
【米国】
2014年のState of DevOps Reportは、デプロイ頻度、変更リードタイム、障害復旧時間（MTTR）といったITパフォーマンス指標の整理を広く普及させた。
これにより、評価の焦点は個別の納品物よりも、継続的に価値を届ける能力へと比重が移っていった。調達や契約の面でも、固定的な成果物契約より、運用と改善を一体で回す形が取りやすくなった。
同年にはKubernetesが公開され、コンテナ運用の標準化が進展した。これにより、発注者側が運用まで含めて全体を統合管理しやすい技術的基盤が強まった。
DevOps：開発（Dev）と運用（Ops）が連携して、ソフトウェアを継続的に改善・提供する考え方。
デプロイ：開発したソフトウェアを本番環境に配置して、実際に利用できる状態にすること。
コンテナ：アプリと必要な実行環境を一体化し、環境差異に左右されず同じ動作を再現できるようにする実行技術。
Kubernetes（クバネティス）：多数のコンテナの配置・起動・拡張・復旧などを自動で管理・制御する基盤。
【日本】
2018年のDXレポートは、レガシーシステムの複雑化・ブラックボックス化の背景として、「ユーザ企業とベンダー企業の関係」を重要な要因に位置づけている。
日本ではITエンジニアの多くがベンダー企業側に偏在し、システム開発を外部委託する構造が定着してきた。このため、ユーザ企業側に運用・改善の知見が蓄積しにくく、要件確定型の開発やベンダー依存の体制が維持されやすいと整理されている。
その結果、クラウドやアジャイルといった新しい技術や開発手法が登場しても、開発の進め方や役割分担の基本構造は大きく転換せず、継続的な改善を前提とした運用モデルへ移行しにくい状況が続いた。
※DX（デジタルトランスフォーメーション）：データやデジタル技術を活用して、業務やサービス、ビジネスモデル、組織のあり方まで変革すること。
※レガシーシステム：古い技術や独自仕様で作られ、改修や連携が難しくなっている既存システム。
📅〘 2020年代 〙
【米国】
2022年11月、ChatGPTの公開により、生成AIは一般用途で広く利用可能な技術として急速に普及局面に入った。
生成AIは実装や開発の速度を大きく高める一方、継続的に価値を出すためには、誰がシステム全体の責任を持ち、運用と改善を回し続けるかが一層重要になった。
こうした変化を受け、米国政府でもソフトウェアを継続的に開発・更新することを前提とした契約・発注の仕組みの整備が進み、Adaptive Acquisition FrameworkやSoftware Acquisition Pathwayなどの枠組みが運用されている。
※ChatGPT：米国OpenAIが開発した対話型の生成AIで、質問に応じて文章やコードを自動生成できる。
※Adaptive Acquisition Framework（AAF）：米国国防総省（DoD）が整備した、ITシステムやソフトウェアなどを目的に応じた方法で素早く導入するための調達・契約の全体的な進め方。
※Software Acquisition Pathway：AAFの中のソフトウェア向けの方式で、ソフトを一度に完成させるのではなく、段階的に開発・改善しながら継続的に提供していく進め方。
【日本】
2022年、公正取引委員会はソフトウェア業の取引実態を調査し、これを「多重下請構造型サプライチェーン」と整理した。報告では、元請・中間下請・最終下請といった層構造の定義に加え、実質的な付加価値を持たない仲介的事業者の類型も示され、取引の多層構造が産業上の課題として公的に可視化された。
IPA「DX動向2025」は日米独比較において、重要なシステムの開発体制を見ると、日本は外部委託の比率が最も高く、米国は内製の比率が最も高いという対照的な構図を定量的に示している。
さらに2025年、経産省はレガシーシステム問題の現状と課題を総括し、「2025年の崖」の文脈の下で、レガシーの存在がDX推進を制約する構造要因として整理した。
すなわち、2020年代に入って日本のソフトウェア産業では、多層的な受託構造そのものが政策課題として明確に認識される段階に至った。
※サプライチェーン：製品やサービスが、原材料の調達から製造・流通・提供に至るまで、複数の企業を通って利用者に届くまでの一連の流れ。
🏢日本の制度と文化が生む構造――日本が変化できない理由 🏭
日本の業務システム開発は、なぜか毎回似た形になります。
請負契約、ウォーターフォール開発…成果物をそろえて、検収して、支払う。
工程は段階に分かれ、上流と下流が分断され、多重下請が増えていく…
これは、制度と文化がそうなるように働いている結果と言えます。
つまり、変えようとしても、結局は毎回同じ形に落ち着いてしまうのです。
このあたりを詳細に説明していきたいと思います。
📊 年度予算は「正しさ」より「説明しやすさ」が優先される
日本では、支出が会計年度（１年間）で管理されます。
年度の終わりには、その年にどのような目的で、いくら使い、どのような成果を得たのかを説明する必要が生じます。
説明のしやすさという観点から見ると…
「今年はこれを購入（発注）し、これを受領（検収）しました」
と言える状態が最も分かりやすく、監査や社内決裁のプロセスにも適合しやすくなります。
年度をまたいで予算を使う仕組み（繰越）はありますが、要件や手続きが複雑なため、実際には単年度で使い切る運用が基本になります。
ここで重要になるのが検収です。検収は、単なる形式ではなく、支払いの根拠、受領の証拠、責任境界の確定という意味を同時に持ちます。したがって「年度内に検収できる成果物を置く」ことが、制度上も運用上も扱いやすい選択になりやすいのです。
一方、アメリカも年度縛り自体は厳格ですが、制度として契約を切らずに続けられる仕組みが整っています。マルチイヤー契約やオプション延長、IDIQ などにより、年度をまたいで業務を運用する型が標準化されています。さらに T&M 契約も、不確実な業務に使う場合の条件や統制が明文化されています。
※マルチイヤー契約：複数年度にわたって継続的に履行することを前提に締結される長期契約。
※IDIQ：一定期間・上限の範囲内で、必要に応じて個別発注（オーダー）を行う不確定数量型の枠契約。
※T&M：作業に要した時間（Time）と実費材料費（Materials）に基づいて対価を支払う契約方式。
📊 発注側だけでなく、受注側（SIer）の決算も同じ方向に働く
発注側が年度で説明する必要があるのと同様に、受注側であるSIerも決算の観点から
「いつ売上が計上できるか」を見通したいという要求を持ちます。
検収や受領が売上計上の節目になることが多い場合、受注側にとっても
「どのタイミングで何を検収するか」「範囲をどこで区切るか」は極めて重要です。
その結果、発注側の「年度内に説明可能な成果を置きたい」という要請と、
受注側の「計上タイミングを明確にしたい」という要請が一致しやすくなります。
この一致が、成果物中心の契約、つまり請負（固定仕様・固定価格＋検収）を選びやすくする大きな要因になります。
📊 年度予算の制約が、要件定義を肥大化させる
年度予算で進める場合、「今年度の予算で、どこまでを成果として確認・支払うのか」を明確に説明する必要があります。監査や決裁に対応するため、契約に含まれる作業範囲をあいまいにできないからです。
このとき請負契約では、「契約に含まれるかどうか」が費用・納期・責任に直結します。その範囲を文書で固定する役割が要件定義に集中し、「書いていないものは契約外と見なされる」リスクを避けようとして、内容が過度に細かく・広くなりやすいのです。
さらに、日本の企業や組織では、方針管理などに代表されるように、上位目標を具体的な年次目標へ分解し、計画と実績を厳密に管理する手法が広く用いられてきました。
この管理様式では、目標や計画を文書で明確化し、進捗や達成度を測定することが重視されます。
その結果、年度予算による説明責任の要請と、計画・目標を明確化して管理しようとする組織慣行が重なると、契約範囲を事前に細かく確定しようとする圧力が強まり、要件定義が肥大化しやすくなるのです。
📊 ウォーターフォール開発になるのは「品質のため」より「説明と検収のため」
工程をいくつかの段階に分けると、節目ごとに成果物を確認し、承認し、その記録を残しやすくなります。これは品質管理の観点だけでなく、年度単位で「今年度はここまで完了した」と説明する上でも都合のよい進め方です。
政府契約では、原則として、作業の完了を確認した後でなければ代金を支払わないとされています 。そのため、「どこまで終わったか」をはっきり区切って示せる進め方は、実務上扱いやすくなります。
要件定義完了、設計完了、テスト完了、移行完了といった節目は、内部統制や監査、対外説明において、「進捗と成果を客観的に示す単位」として機能します。段階ごとに成果物と承認記録がそろっていれば、予算の使い道や契約の履行状況、支払の妥当性を説明しやすくなるためです。
特に、政府による発注（公共分野の契約）では、この傾向がさらに強まります。デジタル庁の調達手続マニュアルでも、契約は予算に基づいて行われ、透明性・公正性などを確保することが求められているとされています。
📊 工程分割が分業と多重委託を進め、実務の“回しやすさ"が構造を固定する
工程が細かく分割されると、作業単位を切り出して外部に委託しやすくなります。上流は要件整理・設計・承認・対外説明、下流は実装・テスト・運用といった役割分担が進み、委託階層が深くなるほど、情報と意思決定が工程ごとに分散しやすくなります。
こうした構造では、作業成果そのものよりも、「一定期間に何人を投入するか」という体制管理が実務上の調整軸になりやすくなります。そこで、人月という単位が便利に使われます。本来、人月は工数見積のための指標ですが、多層の委託関係の中では、「この期間にこの人数を確保する」という要員確保・体制契約の単位として運用されやすくなります。
その結果…
・工程は分割される
・人月で体制を積み上げる
・不足分は再委託で補う
という循環が生まれ、工程分割と人月運用が相互に補強し合い、分業と多重委託が“回りやすい形”として定着していきます。
この構造の副作用として、変更対応や手戻りの負担が下流に集中しやすくなります。実際、公正取引委員会も、ソフトウェア業界では多重下請構造の下流に対して、買いたたきや仕様変更への無償対応要求といった問題が生じ得ると指摘しています。
こうした指摘が示すように、工程分割と多層委託は単なる開発手法の選択にとどまらず、契約運用・体制確保・価格調整の仕組みと結びつきながら、構造的に維持されやすい特徴を持っているのです。
📊 文化は制度の圧力を増幅し、固定化を後押しする
制度だけなら、運用ルールを工夫して個別に対応することは可能かもしれません。ところが日本の組織では、制度が求める「成果物・承認・記録（証跡）」が、組織運営の安心の作り方と強くかみ合い、結果として同じ進め方が繰り返し選ばれるのです。
その背景の一つが、意思決定の進め方です。
日本企業では、稟議（りんぎ）のように、関係者の合意を段階的に集め、承認の履歴を文書として残しながら進める方法が広く使われています。この環境では、「後から経緯を説明できる状態」に価値が置かれ、成果物、議事録、承認記録、検査記録をそろえる動きが強まります。
もう一つは、不確実性をできるだけ減らそうとする判断姿勢です。文化比較研究では、日本は不確実性回避が高い国の一つとされ、未確定のまま進めるより、事前に決めて予測可能性を高める行動が選ばれやすいことが示されています。
現場レベルでは、「後で調整するより先に固める」「途中で揉めないように範囲を明確にする」といった判断として表れ、前工程で内容を細かく確定する方向を後押しします。
さらに、日本では製造業で成果を上げた発想を背景に、大規模開発を工場のように管理する「ソフトウェア工場」の取り組みが早い段階から実務に取り込まれてきました。
この考え方では、工程を区切り、成果物を確認し、検査と承認の記録を残す進め方が、品質管理と統制の基本形になります。
こうして、合意と記録を重視する意思決定、不確実性を減らそうとする判断姿勢、工程管理を重んじる開発観が同じ方向にそろうことで、制度が求める「成果物・承認・証跡」を中心とした運用が強まり、結果としてプロセスの形が変わりにくくなるのです。
🏢作業にかかる時間（工数）をお金に換算する人月という考え方 🏭
人月の話に入る前に、日本のシステム開発でよく使われる契約形態を整理しておきます。ここを理解しておくと、人月という単位がどのように使われるのかが見えやすくなります。
まず「工数」という言葉があります。これは、ある作業を完了するのに必要な作業量の見積もりを指します。たとえば「この機能の開発に3人月かかる」と表現された場合、その機能を作るのに延べ3人月分の作業量が必要、という意味になります。
先ほど出てきた「人月」という言葉は、この工数を人数と期間で表すときの単位で、1人のエンジニアが1か月作業した分の作業量、またはそれに対応する費用の目安です。
プロジェクトの規模を「何人が何か月関わるか」で見積もるときに使います。ここでいう要員とは、プロジェクトに投入する人員、つまりエンジニアや担当者のことです。
実務で中心になる契約形態は、請負契約と準委任契約の二つです。違いは明確で、完成した成果に対して対価を支払うのが請負契約、業務を適切に進めることに対して対価を支払うのが準委任契約です。
請負契約では、システムやプログラムなどの成果物の完成が契約の中心になります。受注側は約束した内容を完成させる責任を負い、発注側は納品物が仕様どおりかを確認したうえで代金を支払います。この前提では、作業範囲を事前に固め、工程を区切って確認する進め方が採られます。ウォーターフォール型の開発で請負が多いのは、この構造によるものです。
準委任契約は、業務を適切に遂行すること自体に対価を支払う契約です。受注側は専門家として注意深く業務を行う義務を負いますが、成果物の完成までは約束しません。実務では、開発や運用の作業を一定期間継続して担う場面で使われます。
責任の現れ方も異なります。請負契約では、成果物が完成しているかどうかについて受注側の責任が中心となり、発注側の結果責任は前面に出ません。これに対して準委任契約では、受注側は業務を適切に遂行する責任を負うものの、作業の進め方や優先順位の判断に発注側が深く関与するため、プロジェクトの結果について発注側の責任も問われる構造になります。
日本のシステム開発は請負契約を軸に組み立てられてきました。商流、検収、支払の流れも成果物中心で設計されています。このため準委任契約は個別の作業や支援では広く使われているものの、プロジェクト全体の基本形にはなりにくい、という実務上の位置づけにあります。
この違いを踏まえたうえで、次に人月という単位が実務の中でどのように使われているのかを見ていきます。
💴 人月は「価格の最小単位」として流通する
実務の見積は、多くの場合、工程を分解するところから始まります。工程ごとに必要な役割を割り当て、その役割ごとの人月単価を掛け合わせて金額を算出します。
こうして、PMの単価は高く、PGは低いといった役割別の単価表が、組織や商流の中で半ば標準として固定されていきます。
ここで重要なのは、人月が単なる見積の単位にとどまらない点です。人月は、契約、調達、検収の各場面で「なぜこの金額になるのか」を説明するための共通言語として機能します。
IPAのモデル契約も、取引構造の透明化や各局面での責務の明確化を重視しており、請負・準委任の整理、仕様の確定、検収方法の合意など、契約時点で何を確定させるかを重視しています。この前提に立つと、工程と成果物を先に定義し、そこに必要な人月を対応づける見積は、関係者間の説明と合意を取り付けやすい形になります。
さらに、多重下請の構造に入ると、人月は商流を通過する実質的な価格単位として扱われます。上位層は工程管理、体制確保、対外説明を担い、下位層は実装や試験といった実作業を担います。
この段階では、人月はもはや単なる労働投入の目安ではありません。調達、分業、価格調整を連動させて回すための基準単位として機能しているのです。
※PM（Project Manager）：プロジェクト全体の計画、進行、品質・コスト・納期を統括する責任者。
※PL（Project Leader）：開発チームの日々の作業を指揮し、現場レベルの進行管理を行うリーダー。
※SE（Systems Engineer）：要件整理や基本設計など、システム仕様を具体化する上流工程の担当者。
※PG（Programmer）：設計書に基づいてプログラムの実装（コーディング）を行う開発担当者。
💴 人月は成果でも期間でもなく、人の投入量を表す
ソフトウェア工学では、ソフトウェアの大きさと、それを作るために必要な作業量を明確に分けて扱います。ソフトの規模を測る指標としてはファンクションポイント などが用いられます。一方、人月は「どれだけの作業量が必要か」を表す単位であり、両者は役割の異なる指標です。
さらに見積理論では、人月、開発期間、金額は、それぞれ別に決まる要素として整理されています。人月はあくまで「どれだけの作業量が必要か」を示す指標であり、期間や費用を直接決めるものではないとされています。
たとえば理論上は、必要な作業量が50人月であっても、人を増やせば期間が単純に半分になるとは考えられていません。作業の並行には限界があり、人数が増えるほど調整の手間も増えるため、開発にかかる期間は別の要因で決まると整理します。
金額についても同様です。見積理論では、総作業量が同じでも、要員のスキル構成、役割の組み方、管理に要する負荷、手戻りの発生などによって、最終的な費用は変動し得るものとして扱います。
つまり理論上の整理では、人月はあくまで作業量の目安にとどまり、期間や金額が自動的に決まるわけではありません。
ところが実務では、人月が「人数を増やせば納期を縮められる」「人月を積み上げれば金額が決まる」といった意味まで含めて扱われることが多いです。本来は切り分けて考えるべき作業量・期間・金額が、運用の中で一体のものとして扱われてしまうのです。
ソフトウェア工学や見積理論では、開発の途中で仕様変更や手戻りによって作業量が増えることを前提にしています。
たとえば、開発の途中で要件が変わり、すでに作った部分を修正・再作成することになれば、その分だけ必要な人月は増えます。これは特別な失敗というより、ソフトウェア開発では起こり得るものとして扱われています。
言い換えれば、実際の開発が当初見積どおりの人月や単純な積算金額で収まらないこと自体は、理論の前提から外れた例外ではないという事なのです。
💴 人員を増やせば期間は縮む、という誤解——人月の神話
『人月の神話（The Mythical Man-Month）』は、米国の計算機科学者であるフレデリック・P・ブルックスが大規模システム開発の経験から、ソフトウェア開発で繰り返し起きる「落とし穴」を整理した古典です。中心テーマは「人と月は交換できる」という直感への問い直しで、遅れているプロジェクトに人を追加すると、教育と調整、コミュニケーションが増えて完了が遅れる――いわゆるブルックスの法則として広く知られています。
この指摘が重要なのは、精神論ではなく構造の問題だからです。
タスクが完全に独立していて相互連絡が要らないなら人数追加は効きますが、システム開発には統合、仕様のすり合わせ、結合試験のように「順番に進める部分」が残ります。ここは並列化できないので、人数を増やすほど統合と調整の負担が増え、加速どころか減速が起きます。
本書が扱う「落とし穴」は、人数と期間だけではありません。まず大規模開発そのものを、大規模開発そのものを、抜け出しにくい泥沼にたとえます。個々の問題は解けそうに見えても、相互に絡み合って全体が前に進みにくくなる、という感覚を言語化した比喩です。
次に本書は、「動くプログラム」を実際に使われる製品やシステムとして仕上げる段階で、必要な作業が大きく増える点を強調しています。単に動くだけでなく、十分なテスト、文書整備、運用対応、他システムとの連携や統合が求められるため、開発の負担は一段重くなるのです。ソフトウェア工学の文献でも、プログラム単体に比べて、製品化・システム化の工程で工数が大きく膨らむことが指摘されています。
設計面では、「概念的完全性」が最重要だと述べます。少数の設計者が一貫した思想で全体の設計を守らないと、寄せ集めの仕様になって使いにくく壊れやすいシステムになる、という主張です。
さらに、二作目で「盛り込みたくなる」罠として有名な第二システム効果も、典型的な失敗パターンとして言及され続けています。
この本が示す“人月の神話”の中核は、人月を交換可能な労働量として扱い、「人数を足せば期間と金額を取り戻せる」と考えるところにあります。現実のシステム開発では、並列化できない部分と調整コスト、設計の一貫性、製品化・システム化の負担が前面に出て、その前提が崩れるのです。
💴 人月で見積もる請負契約で、固定金額なのに作業が膨らむ現実
人月は本来「この仕事にどれだけ作業が必要か」を表す見積です。ところが日本のシステム開発では、人月がそのまま契約金額となり、多重下請の商流の中で価格の基準として扱われます。
この時点で、人月は“作業量の目安”ではなく“金額を作る単位”になります。そうなると、現場の行動は「良いものを早く作る」より、「赤字を出さず、利益を確保する」という判断が優先されます。
請負（固定価格）では、契約時点で「この範囲をこの金額でやる」を決めます。開発途中で業務に必須な機能が漏れているのが判明し、仕様変更や手戻りが起きて作業が増えても、請求金額は増えません。増えた分の費用を回収するには、変更点を切り出して追加費用として合意し直す必要があります。合意できなければ、その作業は受注側の持ち出しです。
そのため受注側は、見積の段階で「本来必要な工数」に加えて、仕様の揺れや手戻りに備えるためのリスク分の工数を、契約上は明示されない形であらかじめ上乗せします。これを入れずに正直に見積もると、仕様の変更が入った時点で確実に赤字になります。
それでも、ウォーターフォール型の運用では、上乗せ分を入れたから安心という話にはなりません。要件定義の段階では、本来必要な機能の一部が要件として書き出されないまま進むことが少なくありません。現場では当然に行われている処理ほど、担当者にとっては説明の対象として思い浮かびにくいためです。その中には、欠けると日常の運用そのものが成り立たなくなる機能も含まれます。こうした機能は要件として表に出ないまま、後工程で初めて問題として現れます。
※要件定義を完璧にすれば防げる、という意見もあります。しかし実務では、人が関与する以上、すべての業務前提を初期段階で完全に洗い出すことは、よほど小規模な案件でもない限り現実的ではありません。
ウォーターフォールは上流と下流の距離が長く、やり取りが文書中心になるため、こうした漏れが発生すると上流工程に戻って修正が必要になります。そのうえで、顧客満足を最優先にして「ユーザー要望はすべて受ける」という方針を取ると、追加作業は止まりません。最初に上乗せした工数は有限ですが、要望対応の増分は無制限に発生します。受注側がそれをすべて抱える前提では、いくら上乗せしても足りません。
さらに厄介なのが、発注側にとっても追加費用は簡単に動かせないことです。ユーザーはあらかじめ確保した予算の枠の中で発注しています。途中で増額するとなれば、再決裁が必要になり、社内説明の負担も一気に増えます。実務上、ここで予算を動かすのは容易ではありません。
そのため発注側からは、「追加で支払う」よりも「まずは今の契約の範囲で何とか収めてほしい」という強い要請を受けることになります。受注側にとっても、都度追加費用を求めれば調整は難航し、関係は悪化していきます。理屈としては請求できても、実務では追加費用が動きにくい構造になっているのです。
こうして、色々工夫しても「固定金額のまま、作業だけが膨らんでいく」状況ができあがります。契約は固定価格、要望は増える、追加費用は動かない。この三点がそろうと、作業増は止まりません。
💴 人月見積における実際の配分と、製造効率化の限界
実務の見積では、人月は工程ごとに配分して積み上げます。典型的な配分例を整理すると、次のような構成になります。
※本表は筆者の実務経験をもとに一般化して作成した参考モデルであり、特定の公開資料等からの引用ではありません。
この配分からまず読み取れるのは、実装（製造）が全体に占める割合は意外に小さいという点です。
通常案件では製造は約12％、高技術案件でも約16％にとどまります。一方で、設計工程、各種テスト、管理工数が全体の大半を占めています。
ここから分かるのは、仮に製造工程の生産性が大きく向上したとしても、プロジェクト全体の短縮効果には上限があるということです。工程構造を変えないまま部分最適だけを進めても、全体は期待したほど速くなりません。
近年は生成AIや各種自動化ツールによって、コーディング作業そのものの効率は確実に向上しています。いわゆるバイブコーディング（AI支援による高速実装）も、この流れの中に位置づけられます。しかし前述の配分を前提にすると、仮に製造工程が半分の時間で終わったとしても、全体短縮効果は限定的です。製造が12％の案件であれば、極端に言えば製造がゼロになっても全体は12％しか縮まりません。
工程構造を変えない限り、コーディング高速化の効果には物理的な上限がある、というのがまず押さえるべき前提です。
そして見落とされがちなのが、テストと修正工程への影響です。
業務システムの開発では、単に動作すること以上に、業務ルールを正確に確定し、例外なく再現できることが重視されます。そのため、ソースコードの分岐や計算根拠を開発側が明確に説明できる状態が前提になります。
ところが、バイブコーディングのように生成AIへの依存度を高めると、コードは一見正しく動いても、なぜその挙動になるのかを人間が十分に把握・説明できない部分が残りやすくなります。業務処理の厳密さが求められる領域では、この不透明さ自体が追加の検証負荷を生みます。
その結果、単体テストの観点は増え、不具合発生時の原因特定は長引き、結合テストやシステムテストでの手戻りも増加します。実装が速くなった分が打ち消されるどころか、検証と修正の負荷が後工程に大きく跳ね返る場面も珍しくありません。
人月配分を見れば分かるとおり、テスト関連工程はもともと製造より大きな比重を占めています。ここが膨らめば、製造で得た効率化分を上回る追加負荷が発生し、全体としてはむしろ工数が増える可能性も十分にあります。
以上を踏まえると、焦点は単純なコーディング高速化の是非ではありません。人月配分の構造、請負中心の契約形態、多重下請による役割分担、そしてテスト工程の比重が維持されたままでは、製造工程だけをいくら効率化しても、プロジェクト全体の改善効果は大きくは伸びません。
むしろ、人月を前提とした契約と商流の中で部分的な効率化だけを進めた場合、その効果は単価圧力や後工程の負荷増大という形で吸収され、結果として全体の最適化から遠ざかる可能性すらあります。
🏢ウォーターフォール開発・工程分離・多重下請の下で起こること 🏭
ここまで見てきたように、日本の業務システム開発では、人月見積、請負契約、工程分離、多重下請といった要素が、個別の選択として存在しているのではなく、互いにかみ合った一つの運用構造を形作っていることが分かりました。
本章では、この構造の下で結果として何が起きるのかを見ていきたいと思います。
🔥 人月見積と多重下請構造が、作業増分を下へ押し流す
請負の固定金額で走り出した案件は、途中で作業が増えても金額が自動では増えません。
この状態で次に起きるのは、「増えた作業を追加費用として扱う」ではなく、「契約の中に押し込む」動きです。
追加費用にすると予算と手続の話になり、発注側も受注側も動かしにくい。そこで増分は、金額を動かさない言い方に変換されます。
「仕様変更」ではなく「当初仕様の解釈」「当然含まれる範囲」「不具合対応」として扱い、契約内の作業にしてしまう。こうすると、ユーザー要望は通り、契約金額も動きません。動かないのは金額だけで、作業は増え続けます。
そして、その増えた作業がどこに行くかというと、多重下請の連鎖のいちばん下に向かっていきます。実装と試験が下流に集まっている以上、増分も下流に落ちる。ここまでは単純です。問題は、本来なら下流が「増えた分は追加工数だ」と言って上流に請求すべきなのに、それが簡単に通せない力が働くことです。
多重下請では、元請・一次請・二次請…は別契約でつながります。上位で増えた作業は、下位契約に自動では反映されません。基本的に作業の増分は、下位が上位に「追加費用の協議」を要求し、上位がそれを飲み、さらに上位がエンドユーザーにも増額を通す必要があります。つまり下流の追加請求は、上流の契約全体に影響するのです。
しかし、エンドユーザーは予算枠と社内手続の中で動いており、途中増額は簡単に出来ません。だから上流は作業の追加の話を「金額の話にしない」方向で下流方向に要求する方が上流にとっては合理的な動き方になります。
つまり…増えた作業を追加費用として認めるのではなく、「当初仕様の解釈」「当然含まれる作業」「不具合対応」という言い方に置き換え、可能な限り「契約内の作業である」という主張と交渉を行う方向に向かいます。公取委が、ソフトウェア分野で仕様変更への無償対応要求が問題になり得ると示しているのは、こういった事象になります。
これは、上流が下請けから搾り取り「儲けよう」という意図というよりは、固定金額の枠の中で、ユーザー要望をできるだけ通し、顧客満足を落とさないことを目指したいという意図が含まれます。つまり、ユーザーと下請けを天秤にかけているわけです。
顧客満足を上げるためには、下流に追加費用を払うより「この金額で何とかして」と詰めるほうが都合がいいのです。
上流は「お金を出す側」で、下流は「仕事をもらう側」です。下流は契約上は追加を言える立場に見えても、現実には取引継続や依存関係があり、強く押し返すほど次の仕事が危うくなります。取引上の力関係を使って相手に不利益を受け入れさせる、という構図は公取委が説明する優越的地位の濫用とも重なります。
こうして増分は、追加の請求書には乗らず、現場の追加対応として処理されます。さらに段が増えるほど、増分を押し戻す交渉力は薄くなり、最後の最も下流に残るのは「作業だけ増えて、代金は据え置き」という形に収束していく力が働くのです。
🔥 技術が分からない人が評価する組織では、効率化が罰になる
日本の開発現場で起きている厄介さは、特定の契約形態や立場の問題ではありません。
組織の評価構造そのものに原因があります。多くの企業では、昇進や出世が技術力ではなく、調整力や管理経験を軸に決まりやすいです。その結果、技術の中身を深く理解していない人が、工数や進捗を評価する立場に立つことも多いと思われます。
評価の物差しがこうなると、現場でどれだけ設計を工夫したか、どれだけ品質を高めたかといった技術的な成果は評価に繋がりにくくなります。見えるのは、予定どおり進んだか、大きな事故がなかったか、工数の枠に収まったかという数字だけです。技術で勝っても、評価では勝てない状態が常態化します。
さらに厄介なのは、見積の主体が誰であっても、効率化が報われにくい点です。開発者自身が見積を作るケースでは、予定より早く終わると「見積に余裕を持たせていたのではないか」と疑われます。技術的に工夫して短縮した場合でも、その差分は改善の成果ではなく“ぼったくっていたのでは？”と解釈されやすいのです。
一方、技術の内訳を十分に理解しない側が見積を主導した場合でも、結果は大きく変わりません。想定より早く終われば、「当初見積が過大だった」という評価と軌道修正がなされます。ここでも、短縮は能力の結果ではなく、見積精度の問題として処理されます。
どちらの経路を通っても、帰結は同じです。改善によって生まれた余力は、利益や裁量として残らず、次回の前提工数を削る根拠として回収されます。現場から見れば、速く終わらせるほど次の条件が厳しくなる構造です。
ここまで見えている以上、現場が合理的に選ぶ行動は明確です。最速で終わらせることではなく、確実に予定内で収めることを優先します。速く終えるほど次が苦しくなるなら、無理に前倒しする動機は生まれません。これは怠慢ではなく、評価構造に対する合理的な適応です。
問題の根は、技術を評価する仕組みが組織の中に十分に組み込まれていないことにあります。評価者が技術の内訳を判断できなければ、評価は必ず説明しやすい指標に寄ります。工数、進捗、会議回数、資料の整備状況――こうした管理指標が肥大化し、技術的な改善は重要視されません。
この状態が続くと、現場の動き方そのものが変わります。本気で取り組めばもっと早く終えられる場面でも、あえて余力を残して進めるほうが、見積との整合を保ちやすく、次回以降のスケジュールを過度に詰められず、結果として評価も得やすくなるからです。
この学習が積み重なると、効率化に踏み込む動機そのものが弱まり、能力も確実に下がっていきます。結果として、本質的な生産性を押し上げる力は、組織の中で徐々に失われていきます。
さらに、日本企業では専門職として技術を積み上げ続けるキャリアより、管理側に回るキャリアのほうが昇進経路として太い場合が多く見られます。その結果、組織の上に行くほど技術の解像度が下がり、技術を十分に評価できない構成が再生産されます。評価する側と作る側の距離は、時間とともに広がっていくのです。
この構造自体が、日本で効率化が進みにくい要因の一つになっています。
🔥 伝言ゲーム化する要件と「情報の多段変換」
業務システム開発の現場で要件が食い違うとき、私たちはしばしば「誰かの聞き漏らしではないか」「ユーザーの伝え方が悪かったのではないか」と、個人の資質やスキルの問題として片付けようとしてしまいます。しかし、現場で起きている「仕様のズレ」の本質は、もっと根深く、構造的な理由にあります。要件が原型を留めなくなる最大の要因は、情報が複数の工程を通過する中で何度も形を変えられる「多段変換」のプロセスそのものにあるのです。
この変換は、単なる言い換えではありません。責任、契約、工程といった組織の境界を越えるたびに、情報の意味や粒度が少しずつ削り取られ、変質していきます。
現場の利用部門が最初に抱いているのは、整えられた「機能仕様」ではなく、生々しい「業務上の要望」です。「この帳票を今まで通り出したい」「締め日の手作業を減らしたい」「この例外パターンだけは絶対に落とせない」といった声は、日常運用の前提や現場特有の慣習と分かちがたく結びついています。ところが、多重下請構造や工程分離が前提の環境では、この「生の要望」をそのまま扱うことができません。次の工程へバトンを渡すために、いったん「要件」という説明可能な形式に整理する必要があるからです。
この時点で、情報の取捨選択という名の「変質」が始まります。合意や契約に耐えうる論理的な形に整えれば整えるほど、現場の文脈や暗黙の前提といった「行間の情報」は文書からこぼれ落ちていきます。
さらに深刻なのは、この変換が一度では終わらないという点です。日本のIT開発で一般的な「上流から下流へ」という流れの中では、情報は「業務の言葉」から、ステークホルダーと合意するための「管理の言葉」へ、そして「設計の言葉」を経て、最終的に「実装の言葉」へと、何段階ものフィルターを通過します。ここで重要なのは、各段階で情報を変換している担当者たちは、決して不誠実な仕事をしているわけではないという事実です。
プロジェクトを推進するマネジメント層は、予算や責任の所在を明確にするために、情報を「合意と管理が可能な形」にまとめようとします。一方で、実際にシステムを組み立てる設計・開発担当者は、それを「論理的に矛盾がなく、実装可能な粒度」に落とし込もうとします。各レイヤーの全員が、それぞれの持ち場における「正義」に基づいて合理的に振る舞った結果として、皮肉にも元の業務実態との距離が少しずつ、確実に広がっていくのです。
この多段変換の過程では、主に三種類の情報劣化が起こります。
一つ目は「欠落」です。「当たり前」とされる暗黙知は仕様として固定しづらいため、文書化の過程で真っ先に抜け落ちます。
二つ目は「置換」です。本来は個別の特別扱いが重要であっても、システム上の扱いやすさを優先して一般形に整理されることで、意味そのものが別の形に置き換わります。
そして三つ目が「再解釈」です。全く同じ仕様書を読んでいても、契約担当、SE、プログラマーでは注目するポイントも解釈も異なります。文書という文書と図だけでは、動的な業務の解釈を一致させることは困難なのです。
これらの差異は、一段階だけを見れば小さな誤差に過ぎません。しかし、段をまたぐたびにその誤差は蓄積され、最終的に「動くシステム」として形になった段階で、仕様漏れや業務に合わない挙動といった目に見える問題として一気に表面化します。
この流れをさらに加速させるのが、組織の分断です。「組織のコミュニケーション構造がシステム構造に反映される」というコンウェイの法則が示す通り、関係組織が増えるほど直接対話は失われ、情報のやり取りは文書に強く依存するようになります。対話を増やそうとすれば調整コストが急増してプロジェクトが停滞し、その反動で現場は再び「仕様書中心」の硬直的な運用へと引き戻されてしまいます。
こうして、要件の伝言ゲームは偶発的なミスではなく、構造的に避けられない現象として定着していきます。要件が別物になってしまう本質は、誰か一人の失敗にあるのではありません。情報の多段階変換を前提とした現在の開発構造そのものが、一定の確率で不整合を生み出す仕組みになっているのです。
🔥 責任と承認——そして炎上への道
日本のIT産業におけるプロジェクトの失敗を語るとき、私たちはしばしば「マネージャーの管理不足」や「技術力の欠如」といった、個人の能力の問題に原因を求めてしまいがちです。しかし、現場で繰り返される「決められない」停滞と、その先に待つ爆発的な炎上の本質は、もっと根深く、日本特有の組織構造が抱える「責任」という概念の変質にあります。
本来、プロジェクトにおける責任とは、目標を達成するための「説明責任（アカウンタビリティ）」であるはずです。しかし、多くの現場においてそれは「失敗した際の謝罪」や「処罰の対象」という、極めて後ろ向きな意味へとすり替わっています。この認識の歪みが、意思決定を「前進のための決断」ではなく「回避すべきリスク」へと変貌させてしまうのです。
この病理を加速させるのが、日本企業に深く根付いた多層的な「承認」のプロセスです。一つの仕様を確定させるために、課長、部長、役員と幾重にも連なるハンコのリレーが必要とされる光景は珍しくありません。一見すると慎重な確認作業のように見えますが、その実態は「責任の分散」という儀式に他なりません。多くの人間が関与することで、万が一問題が起きた際に「組織として決定したことだ」という免責を得るための装置として機能しているのです。承認者が増えるほど、内容の技術的な妥当性よりも、資料の体裁や説明の整合性ばかりが重視され、本質的なリスクはむしろ見えにくくなっていきます。
このような環境下では、物事を「確定させる」こと自体が個人の大きなリスクとなります。たとえば、業務のルールを隅々まで具体的に定めることは、担当者にとって非常に勇気が要る作業です。ルールを明確に固定するということは、将来もし想定外の深刻なトラブルが起きた際、そのルールを定めた「犯人」として自らの名前を差し出すようなものだからです。たとえ滅多に起きないような特殊なケースであっても、それが一度発生した際に致命的な損失に繋がる可能性がある限り、人は「なぜそんなルールにしたのか」と後から責められる証拠を自ら残したいとは思いません。減点方式の評価が根強い組織では、正解を出すことよりも、責任を問われないように「白黒つけないこと」の方が、身を守るための合理的な生存戦略になってしまうのです。
この「決められない」停滞が限界に達し、納期という物理的な壁に突き当たったとき、負債は一気に表面化します。論理的なマネジメントが崩壊し、精神論と人海戦術による強行突破、すなわち「炎上」へと至る道は、偶発的な事故ではなく、構造的に用意された必然の結末と言えるでしょう。
🏢 死の行進——デスマーチとその後 🏭
日本の情報サービス産業の背後には、美しく磨き上げられた摩天楼の影に潜む、底なしの沼地のような構造が存在しています。私たちが日常的に利用している銀行のシステム、スマートフォンのアプリケーション、公共インフラを支えるネットワーク。これらを生み出す「システム開発」という営みは、しばしば「死の行進（デスマーチ）」という凄惨な言葉で形容される過酷な旅路を辿ります。この物語は、プロジェクトという名の巨大な機構が、いかにして制御を失い、関わる人々の生活と精神を磨り潰しながら、皮肉な結末へと突き進んでいくのか、その全容を解き明かすためのものです。
💀 ベテランと火消しの召喚
プロジェクトが中盤に差し掛かり、遅延が隠しきれなくなった頃、現場には異様な空気が漂い始めます。進捗報告会議では、虚偽の「順調」という報告が繰り返されますが、開発サーバーの中には動かないプログラムと山積みのバグ票が放置されています 。この段階で組織が繰り出す「解決策」は、さらなる人員の投入です 。上司から「二週間だけ応援に行ってくれ」と囁かれ、現場に送り込まれる下請けのベテラン技術者や、凄腕と称されるリーダー・マネージャーたちがその対象となります 。
彼らが現場に到着して目にするのは、一ヶ月の労働時間が三百時間を超え、オフィスに泊まり込むことが常態化したエンジニアたちの、生気を失った顔です 。しかし、投入された人員がすぐに戦力になるわけではありません。既存の疲弊したメンバーが、新しく来た人間に仕様を説明するために時間を割かなければならず、結果として進捗がさらに遅れるという「ブルックスの法則」を体現するような悪循環が始まります 。
技術者たちは、自分のキャリアや家庭、時には健康を犠牲にして、深夜までキーボードを叩き続けます。過重労働により、ある日突然、同僚が来なくなる。あるいは自分が倒れる。そうした光景が日常と化し、誰かが倒れればまた新しい「身代わり」が補充されるだけの、無限のループが繰り返されます 。
💀 消えるPM（プロジェクトマネージャー）とその後
デスマーチが極限状態に達したとき、事態を劇的に動かすのは、プロジェクトを最初から率いてきたPM（プロジェクトマネージャー）の完全な崩壊です 。
責任感の強いＰＭほど、すべてを自分一人で抱え込み、顧客とチームの板挟みになって磨り減っていきます。そしてある日、糸が切れたように彼は現場から姿を消します 。
こんなことありえない！と思われるかもしれませんが、結構あります。
これはプロジェクトにとって最大の悲劇であるはずですが、実態としては「強制リセット」としての機能を果たします 。中心人物がいなくなったことで、元請けの経営層やユーザーもようやく現実を認めざるを得なくなります。特にユーザーが危機感を持つことで、状況は大幅に変わります。
ここまでの状況となると、後任として送り込まれる新しいリーダーは理想を言うタイプは選ばれません。「前任者が倒れた以上、今の体制は継続不能です。機能を大幅に削るか、納期を延ばすか、どちらかを選んでください」という究極の二択を突きつけるような行動が起こせる人物が割り当てられます。
この対立を経て、ようやくプロジェクトは地に足のついた再計画へと動き出し、不完全ながらも収束の形が見えてくるのです 。
💀 冷徹さが無ければ火は消えない
前任PMの崩壊によってプロジェクトは強制的に現実へ引き戻され、新体制の下で再計画が走り始めます。しかし、立て直しの号令がかかったからといって、現場の火が自然に弱まるわけではありません。
納品期限が数週間から数日に迫った現場は、すでに疲弊しきっています。テスト終盤で露呈する致命的な設計ミス、そして「ここまで来たなら、これも欲しい」という追加要望。再建フェーズに入ったはずのプロジェクトに、再び火種が投げ込まれます。
さらに厄介なのは、形式上の納品を終えても戦いが続く点です。
「ユーザーが納得しなければ納品とは言えない」という論理の下、立ち合い検査と修正要求が際限なく積み上がっていく。ここで新リーダー――すなわち“火消し役”に本当に求められる資質が露わになります。
それは共感力でも、献身でもなく、プロとしての冷徹な線引きです。
火消し役は、顧客の怒号を正面から受け止めながら、実装対象を容赦なく削り込んでいきます。優先順位を「斧」で断ち切るように決め、「今回はやらない」という判断を明確に宣言します。この瞬間、作業は純粋な開発ではなく、利害が衝突する政治的交渉へと姿を変えます。
顧客は「金を払っているのだから、すべて作れ」と迫ります。しかし火消し役は、火を消すためにそこで迎合してはならないのです。
すべてを作ろうとすれば、プロジェクトそのものが燃え尽きる。
その不都合な現実を突きつけ、どこで止めるかを決断する――。
この冷徹さを持てるかどうかが、再建フェーズのプロジェクトを本当に鎮火させられるかの分水嶺になるのです。
💀 炎上現場における「伝言ゲーム回避」が違法を生む
多段の下請けで動く開発現場では、顧客→元請け→一次→二次→三次…と、指示の経路が階層的に設計されています。請負や業務委託の前提では、元請けは自社と契約関係にある会社に対して成果物や対応方針を求め、その会社が自社の管理の下で要員を動かす、という統制構造が保たれている必要があります。逆に言えば、この指示の流れを一社分でも飛び越え、元請けの管理者が下位の下請け企業の社員個人に直接作業指示を出し、実質的に人をコントロールし始めると、形式が請負でも労働者派遣に近い実態と評価され、「偽装請負」として違法と判断されます。
しかし現実の現場は、教科書どおりには動きません。本番稼働後に重大障害が発生し、業務が実際に止まってしまうと、復旧は一分一秒を争う事態になります。本来であれば、元請けPM→各社責任者→担当者という正規ルートで指示を流すべきですが、その経路を丁寧にたどっている間にも影響範囲は広がり、問い合わせは増え続け、現場の緊張は限界に近づいていきます。窓口となるはずの各社リーダーも対応に追われ、指示の取りまとめが追いつかないことがあります。
このとき、全体責任を背負う元請けPMの頭に浮かぶのは、極めて現実的な判断です。――責任者経由では間に合わない、いま手を動かせる人に直接言った方が早い。やがてPMは現場に降り、三次下請けのエンジニアに向かって「このエラー、最優先で対応してください」と声をかける。現場から見れば、それは復旧に直結する合理的な一手に見えます。
最初はあくまで確認や依頼のつもりでも、「これを先に」「この手順で進めて」と作業の進め方まで踏み込んだ瞬間、指示の流れは契約の階層を越え、法的な境界線に触れ始めます。怖いのは、この境界越えが悪意ではなく、責任感とスピードを求める合理性から自然に生まれてしまうことです。
そして火が消え、プロジェクトが表面上は収束した後、メールやチャットの履歴、指示の実態が精査されれば、偽装請負として行政指導や企業の信用低下を招く可能性は十分にあります。目の前の障害を止めるための“最短距離”が、後になって組織のリスクとして跳ね返り得る――それが、デスマーチの現場に潜む見えにくい危うさです。
💀 検収という最後の関門 — 赤字を回収する静かな戦略
プロジェクトが長い混乱を抜け、ようやく終盤の気配が見え始める頃、ベンダー側の視線ははっきりと変わります。それまで会議の中心にあった「品質は十分か」「不具合は潰し切ったか」という議論は、静かに後景へ退き、代わって前面に出てくるのが「検収はいつ通るのか」という一点です。現場の空気も変わります。品質会議は減り、代わりに検収条件の確認、未決事項の切り分け、責任範囲の整理といった、より実務的で、そしてどこか切迫したやり取りが増えていきます。
これは決して不誠実だからではありません。請負契約において、検収は単なる儀式ではなく、報酬請求権を確定させる決定的な関門だからです。どれだけ開発に人と時間を投じても、顧客の検収印がなければ売上は立たないのです。資金繰りの観点から見れば、検収は品質指標ではなく、企業のキャッシュフローを左右する生存条件そのものです。だからこそ、現場がどれほど疲弊していようと、ベンダーは最後に必ずこの一点へと照準を合わせてきます。
もっとも、この段階のシステムが、理想的な完成形に到達しているとは限りません。むしろデスマーチをくぐり抜けた案件ほど、細かな不具合や仕様の綻びがいくつも残っています。そこでベンダーが取り出すのが、半ば業界の定型句となったあの説明です。「残った不具合は保守契約の中で対応します」。この一言で、開発フェーズと運用フェーズの境界線を引き直し、検収のハードルを現実的な高さまで下げにかかる。顧客側も、これ以上開発を引き延ばしても得るものが少ないと判断すれば、しぶしぶながら印を押す――そうして幕引きが図られます。
ベンダーがここまで検収に執着する背景には、ＩＴ業界に深く根付いた収益構造があります。大規模案件では、開発フェーズ単体で見ると採算が大きく崩れていることは珍しくありません。追加要望への対応、度重なる手戻り、長期化した要員投入――それらのコストは、表面上の契約金額を簡単に食い潰します。それでもプロジェクトが止まらないのは、開発の赤字を、後続の保守・運用契約という手段で回収していく前提があるからです。
実際、数億円規模の開発損失が発生していても、数年間の保守費用、運用支援、機能追加の予算が積み上がれば、時間をかけて損失を吸収する道筋は見えてきます。だからベンダーにとって真に重要なのは、「完璧に仕上げること」以上に、「運用フェーズへ橋を架けること」なのです。検収印は、その橋の起点に置かれた通行証にほかなりません。
こうして、品質への執着はやがて検収への執着へと姿を変え、プロジェクトは表面上の収束へ向かいます。しかしその背後では、開発で生じた歪みを長期収益でならしていくという、きわめて冷徹な経済合理性が静かに働いています。終わりのない死の行進を本当に動かしているのは、技術でも情熱でもなく、この数字に裏打ちされた構造なのです。
🏢 さいごに… 🏭
非常に長い文章でしたが…ここまで読んでいただきありがとうございます。
まず、言いたいのが…このブログの内容は批判ではありません。
特定の企業、個人などを指して話している訳ではなく、あくまでも一般的な考察となります。
日本のＩＴ業界で、多くの優秀な人たちが関わり、悪意も持たず必死で努力した中での結果として…なぜか上手くいかない…どうして炎上するのか？という現状を分析したものとなります。
特に、アメリカでは比較的うまく機能しているケースが見られる一方で、日本ではなぜ難しくなりやすいのか？
その背景を知るうえで、歴史、制度、文化といった観点から日本特有の構造を理解することは非常に重要だと感じています。
もちろん上手くいっているケースもあるとは思います。
しかしながら、この構造でうまくいく場合でも…構造そのものが優秀だったというより、関わった人の力量に強く依存していた面もあるのではないか？…と私は考えています。
これからＡＩ時代が訪れると思いますが、ＩＴですらこの構造の中でこれだけ難しさが生じているのです。これをそのままＡＩ導入にスライドして持ってくると、さらに難しさが増すのではないかと感じています。
ＡＩ導入がＰｏＣで止まりやすいのも、偶然というより、こうした構造的要因も影響しているのではないかと感じているのです。
では、どうしたら良いのか？
それについては、決まった正解は１つではないので、ここでは言及しません。
立場が変われば見方も変わるので、色々な正解が乱立していても良いと思っているからです。
ただし、効率だけを追い求めることが最適解だとは、私は思っていません。
自分が大切に思う人たちが幸せに生きられるような…そんな方法を模索し続けたい――そう考えています。