SIer のプロジェクトは、ときどき「炎上」という言葉で語られます。深夜まで続くタスク、顧客からの無理な要求、繰り返される手戻り。現場にいる人ほど、その熱量を自分の能力不足や努力不足として引き受けがちです。
けれど、炎上の多くは個人の力量の話ではなく、プロジェクトが立ち上がる前から組み込まれた「構造」の話であるように見えてきます。
本稿では、SIer のプロジェクトに炎上を運び込む構造的な原因を、3 つの切り口から整理してみます。
1. 契約形態が背負わせる、リスクの偏り
最初の構造は、契約の形そのものに現れます。
SIer のプロジェクトでは、一般的に、要件定義や基本設計の段階を準委任契約、詳細設計以降の実装部分を請負契約というように、フェーズごとに契約形態を使い分けます。上流の不確実性が高い部分は稼働ベースの準委任でリスクを分散し、仕様が固まった下流は成果物ベースの請負で責任を明確にする。これ自体は合理的な設計です。
それでも炎上が起きるのは、契約の切れ目と実際の不確実性の切れ目がずれてしまう場面です。要件が固まりきらないまま請負フェーズに入ってしまう、準委任で詰めきれなかった仕様を請負側が吸収する羽目になる、フェーズ移行で担当が変わって前提の引き継ぎが緩む——こうした接合点で、リスクが受注側へ寄せられていきます。
- フェーズの切れ目と契約形態の切れ目がずれると、請負側が不確実性を吸収する構図が生まれる
- 追加要求に「ノー」と言いづらい商習慣が、それを上乗せする
- 吸収されたコストは、品質や開発期間の圧縮として現場に戻ってくる
契約形態そのものが悪いというより、契約と実際の不確実性の「ずれ」が誰に寄せられているか——ここが炎上の起点になっているように見えます。
2. 要求定義の曖昧さと、スコープ管理の緩み
二つめの構造は、プロジェクトが動き出したあとにやってきます。
要求が曖昧なまま開発に入ってしまう——この一行を掘ると、その裏には、顧客側の複数の事情が重なっているのが見えてきます。
- 業務部門のメンバーが日々の業務で忙しく、要件整理の時間を確保できない
- 経営層は早期の着手を求めるのに、現場の要件整理が追いつかない
- そもそも IT 知見が薄く、ベンダーが要件を整理してくれるのを待ってしまう
本業の忙しさ、スピードと丁寧さのずれ、組織に蓄積されにくい IT 知識——構造的な事情として、どの現場にも一定の形で現れます。
そして SIer 側も、「言われたものを作る」受け身の姿勢に回ると、顧客の本当の課題から距離が広がっていきます。顧客側に要件を整理しきれない事情があるからこそ、こちら側がどこまで踏み込むか——ここで立ち位置を定められないと、完成した成果物が仕様を満たしているのに現場業務と噛み合わない、という齟齬が手戻りとして跳ね返ってきます。
プロジェクトの成否は、顧客の「真のニーズ」を、どこまで具体的な「要求」に翻訳できるかにかかっている。
スコープ管理も、同じ地平の話です。途中で増えていく追加要求を、誰が・どの基準で受けるのかが明文化されていない組織では、変更が積み重なるたびに計画が少しずつずれていきます。要求定義の曖昧さと、スコープ管理の緩み。この二つは、ひとつの構造の表裏として動いているのではないでしょうか。
3. 多層下請け構造と、責任の断絶
三つめの構造は、組織の並びに現れます。SIer 業界に特徴的な多層下請け構造では、一次請け・二次請け・三次請け……と情報と作業が階層状に流れていきます。
この形は、人員供給の柔軟性というメリットを組織に提供する一方で、プロジェクト運営には独特のコストを持ち込みます。
- 情報が階層を経るたびに、意図が少しずつ削られていく
- 「誰がどこまで責任を持つのか」が層ごとに曖昧になる
- 品質基準が各層でばらつき、最下層の品質が全体を規定してしまう
現場で何か問題が起きたとき、原因を辿るとどこかの層で意図が変質していた、ということは珍しくありません。責任の所在がはっきりしない場所では、問題解決よりも責任の押し付け合いに時間が流れてしまう。多層下請けの構造は、炎上の原因を見えにくい場所に分散させる装置としても働いています。
三つの構造は、別々に動いているわけではなく、互いを補強し合う関係にあります。契約の偏りが追加要求の吸収を招き、曖昧な要求定義がスコープの緩みを呼び込み、多層構造が責任の所在を溶かしていく。どれか一つを取り出して指摘するより、三つが重なり合った景色として眺めたほうが、炎上の火勢は腑に落ちるように思います。
まとめに代えて
契約の偏り、要求定義の曖昧さ、多層下請け——この三つは、互いに絡み合って SIer のプロジェクトに炎上を運び込んでいます。個人の努力では打ち消しきれないのは、燃えやすい薪があらかじめ積んである構造だからです。
それでも、現場にいる個人がまったく無力というわけではありません。要求を文書で可視化して関係者で共有する、スコープ変更の基準を早い段階で決めておく、責任の所在をプロジェクト計画の段階で明文化しておく——こうした小さな調整は、構造を一気に変えなくとも、火種の一部を取り除く働きをします。
そしてなにより、炎上の多くが構造に根ざしていると知っておくこと自体が、個人のキャリアにとって意味を持つように思います。現場に流れる熱量を、自分の力不足と引き受ける前に、構造の側に問題の多くが配置されていると見取り図を持てるかどうか。その視点が、次の現場や次のキャリアを選び直すときの、静かな支えになってくれるのかもしれません。
