SIerへの丸投げがブラックボックスを生む原因は、「成果物の所有権」と「ナレッジの所在」が発注側に残らない契約・体制にあります。初期構築はスムーズに進み、SIerは期日通りに納品し、受け入れテストも合格、2年目までは順調に見えます。しかし3年目あたりから「中身を説明できる人が誰もいない」「SIerの担当者が退職して引き継ぎが曖昧」「軽微な変更でも多額の見積もりが返ってくる」といった症状が現れ、気づけば自社の基盤は誰にもコントロールできない代物になっています。本記事では、この経年劣化のメカニズムと、健全なパートナーシップへの組み換え方を整理します。

SIer丸投げデータ基盤の典型パターン

丸投げ型プロジェクトは、初期は非常にうまくいきます。経験豊富なSIerが標準的な方法論で構築し、品質も安定。発注側の担当者は「プロに任せてよかった」と安堵します。問題が表面化するのは、納品後しばらく経ってからです。事業部門から新しい要望が出てきた瞬間、あるいはインフラ障害が起きた瞬間、発注側に「中を理解している人」が不在であることが露呈します。

年次状態リスク対応コスト
1年目構築完了・安定運用低（問題顕在化前）初期構築費用のみ
2年目軽微な改修を依頼中（変更見積もりが高額化）月次保守費 + 改修追加費
3年目担当者の入れ替わりで不透明化高（説明できる人が減少）追加費用の上振れ
4年目SIer交代の検討開始極高（切り替え困難）リバースエンジニアリング費用
5年目ブラックボックス化完了塩漬け or 全面再構築初期費用の3〜5倍

ブラックボックス化の4つのメカニズム

ドキュメントが発注先にしかない

納品時に発注側が受け取るのは、概要図・操作手順書・運用手順書程度の高レベルドキュメントです。設計判断の根拠、代替案の検討過程、トラブルシューティングの暗黙知などは、SIer側のプロジェクトメンバーの頭の中にしか残りません。そのメンバーが異動・退職すれば、その知見は消滅します。発注側は「あれ、これは何のためにこう実装されているんだっけ」という疑問に答える術を持ちません。

属人的なスキル依存

SIerも内部ではプロジェクトをキーパーソンで回しており、その人がチームを離れた瞬間にSIer内部でも理解度が低下します。発注側は「SIerに任せているから大丈夫」と思っていても、実際にはSIer側の1〜2名のキーパーソンに依存しているだけ、という構図が多く見られます。その人が退職・休職すれば、問い合わせへの返答に時間がかかるようになり、品質も低下します。

変更のたびに追加見積もり

保守契約が「現状維持のみ」に設計されていると、軽微な追加・変更でも個別見積もりが必要になります。「この画面の列を1つ増やしたい」という依頼に対し、2週間後に「120万円」という見積もりが返ってくる。発注側は「自社でやれば数時間の作業なのに」と気づくが、技術理解が不足しているため反論できません。この非対称性が重なるほど、交渉力は失われていきます。

テスト・監視の仕組みが不透明

自動テストの仕組み、CI/CDパイプライン、監視・アラートの設計は、いずれも発注側が把握できないケースが多いものです。障害が起きた時、原因追及にSIerの対応を待つしかなく、対応スピードはSIerのSLAに依存します。発注側は自分たちでログを確認することもできず、ダウンタイム中に打てる手がありません。

【ブラックボックス化の進行プロセス】

[初期構築]
    |
    v
[ドキュメントはSIer側のみ]
    |
    v
[運用開始] --> [問題なく稼働]
    |
    v
[2年目: 担当者異動]
    |
    v
[暗黙知の消失] --> [問い合わせ時間の増加]
    |
    v
[3年目: 変更見積もりの高額化]
    |
    v
[発注側の技術理解が追いつかない]
    |
    v
[交渉力の喪失] --> [言い値での発注継続]
    |
    v
[4年目: SIer交代の検討]
    |
    v
[リバースエンジニアリング必須 --> 数千万円]
    |
    v
[塩漬け or 全面再構築]

※ 契約時の設計だけで9割が決まる

SIerとの健全な関係の構築

観点丸投げ型パートナーシップ型
関係性発注 – 受注共同チーム
ドキュメント概要レベルのみ設計判断の根拠まで共有
コード所有権不明瞭発注側に明記
ナレッジトランスファー未実施契約条項で義務化
変更対応追加見積もり定額保守枠で吸収
レビュー納品時のみ四半期アーキテクチャレビュー
EXIT戦略考慮なし引き渡し条件を契約書に明記

ナレッジトランスファー条項の契約組み込み

契約書に「発注側メンバーへの週次ハンズオン勉強会」「設計判断ドキュメントの提出義務」「運用手順書だけでなくトラブルシューティング集の提出」を明文化します。口約束では必ず省かれるため、契約条項にする必要があります。

ドキュメント・コードの所有権の明確化

構築されたコード、設計書、運用手順、CI/CD設定、監視ルールなどの知的財産の所有権は、すべて発注側に帰属する旨を契約書に明記します。デフォルトではSIer側の著作物として扱われるケースが多いため、条項での明示が必須です。

段階的な内製化のロードマップ共有

「3年後には運用の50%を内製化する」というロードマップをSIerと共有し、契約もそれに合わせて設計します。SIerにとっても、発注側の成長を前提とした契約は長期的なパートナーシップの基礎になります。

定期的なアーキテクチャレビュー

四半期ごとに発注側のアーキテクトとSIerの設計責任者が揃うレビュー会を開催し、現状の構成・負債・今後の方針を議論します。これにより、発注側は技術理解を継続的に更新でき、SIerは「お任せ」にならずに緊張感を保ちます。

【健全なSIerパートナーシップの設計図】

[契約締結時]
     |
     +-- ナレッジトランスファー条項
     +-- コード・ドキュメント所有権の明記
     +-- EXIT条項の合意
     |
     v
[構築期]
     |
     +-- ペアワーク体制
     +-- 週次ハンズオン勉強会
     +-- 設計判断ドキュメントの蓄積
     |
     v
[運用期]
     |
     +-- 四半期アーキテクチャレビュー
     +-- 定額保守枠での小改修
     +-- 発注側エンジニアの参画拡大
     |
     v
[段階的内製化]
     |
     +-- 運用の50%を内製に移管
     +-- SIerは戦略領域に集中
     |
     v
[長期パートナーシップ]

※ 発注側の成長を前提に設計された関係だけが持続する

ブラックボックスからの脱出事例

事例A:大手製造業のリバースエンジニアリング
ある製造業は、10年前にSIerに発注したデータ基盤が完全にブラックボックス化していました。月次の保守費用は2,500万円、軽微な変更でも1ヶ月リードタイムという状態。経営判断で、別の専門企業にリバースエンジニアリングを依頼し、現行基盤の全体像を可視化しました。並行して内製チームを3名体制で立ち上げ、18ヶ月かけて運用を内製に移管。SIerとの契約は縮小し、戦略的な領域のみに再定義しました。結果、保守費用は月1,000万円に低減し、変更リードタイムは3営業日に短縮されました。

事例B:金融機関の契約リニューアル
ある地方銀行は、SIerとの20年契約の更新時期を機に、契約内容を全面的に見直しました。新契約には「コード・ドキュメントの完全開示」「発注側メンバーへの月4回の技術共有会」「3年後の内製化ロードマップ」を盛り込みました。SIer側は当初難色を示したものの、長期継続を前提に合意。2年後には、銀行内のデータエンジニアが設計レビューに参加できるようになり、要件の齟齬による手戻りは激減。SIerへの信頼は結果的に高まりました。

まとめ

SIerを使うこと自体は悪くありません。問題は「丸投げ」という姿勢と、それを許容する契約設計です。パートナーシップ型の契約、ナレッジトランスファーの義務化、段階的内製化のロードマップ、定期的なアーキテクチャレビュー、この4点を押さえれば、SIerを戦略的に活用しつつ、自社のコントロールを維持できます。

  • ブラックボックス化は契約設計の段階で決まる
  • ナレッジトランスファーとコード所有権は必須条項
  • 四半期アーキテクチャレビューで技術理解を維持する
  • 段階的内製化ロードマップをSIerと共有する
  • EXIT戦略を契約書に明記する

DE-STKでは、SIer契約レビュー、ブラックボックス基盤のリバースエンジニアリング、段階的内製化の伴走を行っています。関連記事として全部内製にこだわって3年遅れた会社、ベンダーロックインの正体、RFPで失敗するデータ基盤プロジェクトもご覧ください。

よくある質問

Q1. SIerに丸投げしたデータ基盤がブラックボックスになるのはなぜですか？

ドキュメント・ナレッジ・コードの所有権がSIer側に残り、変更のたびに追加見積もりが必要な構造が原因です。発注側に技術的な理解者がいないと、中身を検証する術がなくなります。

Q2. SIerとの契約で注意すべきポイントは？

ナレッジトランスファー条項、コード・ドキュメントの所有権の明確化、定期的なアーキテクチャレビューの義務付けの3つが最重要です。

Q3. ブラックボックス化したデータ基盤をどう立て直せばよいですか？

まず現行基盤の全体像の可視化（リバースエンジニアリング）を行い、段階的に社内にナレッジを移管します。並行して、新規要件は内製チームまたは別パートナーで構築し、依存度を徐々に下げていく戦略が推奨です。