日本のSIer文化とドキュメント問題——多重下請けで仕様はどう失われるか
2026.06.16執筆者：DigKnow株式会社 CTO 桑原 脩
「このシステム、当時の元請けの担当者が辞めて、設計書も最新じゃないんですよ」——SI出身のエンジニアなら、一度は耳にしたことがあるのではないでしょうか。コードはサーバー上で動き続け、ベンダーも契約上まだ存在しています。それでも、仕様の中身を本当に把握している人間は、関係者のなかにも社内にも、もう残っていません。なぜ日本のシステム開発現場で、これほど普通に「仕様の行方不明」が起きるのでしょうか。
仕様が「揮発」する現場の典型例
ある中堅企業の基幹システムを思い浮かべてみてください。20年前にA社というSIerが元請けで構築し、実装はB社、データ連携はC社、運用はD社と、複数のベンダーが入った典型的な多重下請け案件でした。納品時には、A社が分厚い設計書一式を提出し、発注側の情シス部門にも製本された一式が今も棚に並んでいます。ところが20年経って、こういう状態になっています。
– A社の元担当者は、転職または退職。社内に残るのは引き継ぎを受けた別の担当者ですが、当時の経緯までは知りません
– B社・C社・D社は、契約変更や統廃合を経て、関係者がほぼ入れ替わっています
– 設計書は紙とPDFで残っていますが、その後の改修で実態と乖離しています。最新の状態は、コードを読まないとわかりません
– 発注側の情シスにも、当時の仕様策定に関わった人はもういません
この状態でも、システムは動いています。日次バッチも回り、ユーザーは毎日使っています。一方で、新しい機能を追加しようとすると、誰も全体像を即答できません。コードは残った。仕様は、関係者のあいだで静かに揮発した——これが、この現場で起きていることです。これは特定の会社の話ではありません。
なぜ多重下請け構造のなかで、仕様は揮発するのか
仕様が失われる原因を「ドキュメントを書かなかったから」と単純化したくなります。けれど現場を見ると、紙の量だけなら膨大に書かれていることが多いのです。問題は、書かれた紙と、実際に保守される現場との「距離」にあります。この距離は、大きく三つに整理できます。
①書く人と運用する人が分離している
元請けが要件をまとめ、下請けが実装し、別のベンダーが運用を引き継ぐ。工程は契約で区切られ、一つのチームがコードと仕様を一緒に育てていく構造になっていません。要件定義のときの「なぜそうしたか」は、運用フェーズに入る頃にはもう確認しようがありません。
②納品物としてのドキュメントと、生きたドキュメントは違う
SIerの納品物としての設計書には、契約の証跡として作られる側面があります。検収のために必要だから書く、というモードです。検収が終わった瞬間それは「過去の文書」になり、改修が入っても、契約上の改訂義務がなければ更新されません。「将来の保守者のために書く」のではなく「いまの検収を通すために書く」モードで作られている、という構造的な要因が大きいのです。
③人の入れ替わりが契約単位で起きる
一社のなかでメンバーが代わるなら、まだ近くに前任者がいます。SIer文化では、ベンダーごと入れ替わることが起きます。再委託先の変更、保守契約のリプレース、運用ベンダーの切り替え——契約が変わると、知識を持っていた人ごと入れ替わり、引き継ぎ書類はあっても頭のなかの文脈までは引き継げません。
ここで強調したいのは、これが書き手の能力や真面目さの問題ではないということです。検収を通る設計書を不備なく仕上げるのは、それ自体が高度な専門技能です。問題は頑張りの不足ではなく、その矛先が「契約を完了させること」に向くよう構造が誘導している点にあります。同じ労力が「次に保守する人が理解できること」へ向いていれば、結果はまるで違ったはずです。仕様の揮発は、サボりではなく構造のデフォルト挙動として起きている——これがSIer文化の核心だと、私は考えています。
「設計書がある」と「仕様がわかる」は別物
ここで一度、SIer文化で言われる「ドキュメント」の中身を見ておきます。伝統的なSI案件では、要件定義書、外部設計書、内部設計書、データベース定義書、テスト仕様書、運用マニュアルがひと通り揃い、確かにシステムの全体像はそこにあるように見えます。
しかし、保守フェーズに入ったエンジニアが本当に欲しい情報は、これらの書面にはあまり書かれていません。
– なぜこの業務フローでこの分岐になっているのか
– なぜこのテーブル設計なのか
– なぜこのバッチがこの時刻に走るのか
– なぜこのライブラリを選んだのか
設計書には「結果」が書かれています。保守で本当に必要なのは、その「結果に至った理由」のほうです。理由は、議事録の片隅か、当時の担当者の頭のなかにしかなく、議事録は数年で散逸し、担当者は数年で入れ替わります。「ドキュメントはある」けれど「仕様の意図はわからない」——この状態は、SI案件の保守で日常的に起きています。しかも気軽には直せません。新しいベンダーに洗い直しを頼めば莫大な調査費用が見積もられ、だからわからないままの運用がいつのまにか固定化していくのです。
AIコーディング時代に、SIer文化の積み残しはどう効いてくるか
ここまでは、AIコーディングがなくても起きていた現象で、新しい話ではありません。ただ、AI時代に入って、この積み残しの効き方が変わってきています。ここでも三つの観点で整理してみます。
①スピードの非対称が広がる
AIを取り入れた現場では新規実装が速くなる一方、20年前の基幹システムを保守するチームは相変わらず仕様の揮発と戦っています。AIで速く書ける部分と、人間が紙の設計書から推測している部分の速度差が以前より極端になり、同じ会社のなかに二つの時間軸が走り出します。
②AIに渡せる文脈が、そもそも手元にない
AIコーディングツールが力を発揮するのは、コードのほかに「文脈」を渡せるときです。仕様書や設計判断、過去の経緯を入力できれば、AIはかなり的確な提案を返します。けれど仕様が揮発した古いシステムでは、渡す文脈が手元にありません。AIに見えるのは結果としてのコードだけで、設計の意図までは復元しきれないのです。
③揮発したレガシーの上に、新しいブラックボックスが乗る
AIで新規部分を書き足すと、二層構造がSIer文化のシステムに重なります。古い仕様も誰もわからない、新しいAI生成コードも誰も完全には把握していない。SIer文化はこの問題を、契約とベンダー入れ替わりという別の経路から二重に押し上げてしまうのです。
「コードは残ったが、仕様は揮発した」——この核心は、私がシリーズで繰り返し述べてきた「コードは残るが、仕様は誰も知らない」という問題そのものです。日本のSIer文化は、その構造をもっとも長く、もっとも複雑な形で抱え込んできた業界の一つだと、私は考えています。
まとめ
日本のSIer案件では、納品時に分厚い設計書が揃います。それでもコードと仕様は、多重下請け、ベンダーごとの入れ替わり、検収のために書かれるドキュメントの性質という構造のなかで、年単位で静かに離れていきます。「設計書はある」が「仕様の意図はわからない」状態は、誰かのサボりではなく、頑張りの矛先を契約完了へ向けさせる構造のデフォルト挙動です。AI時代に入ると、文脈が不足したまま新規部分が加速し、揮発したレガシーの上に新しいブラックボックスが重なります。仕様の揮発は、業界が長年抱えてきた構造問題の、最も古典的な現れ方の一つなのです。
あなたの会社で運用しているシステムのうち、構築当時の意思決定の理由まで答えられる人が社内に残っているものは、何割あるでしょうか。残りのシステムは、いま誰の頭のなかに「仕様」があるのでしょうか。次回は視点を反転させ、SIerとは正反対に見えて同じ場所へ行き着く——「ドキュメントを書かないこと」に合理性を見出すスタートアップの側へ目を向けていきます。