現場で何かがおかしいと感じているなら、それは気のせいではありません。指示が噛み合わない、誰も決めない、問題を上げても何も変わらない。その感覚の正体は、あなたのスキル不足でも、現場の運の悪さでもありません。商流の深さが生み出す構造的な必然です。
SESという業態は、人を何層にも転売することで成立しています。商流が深くなるほど、現場の実態は上に届かなくなり、責任は拡散し、負荷だけが末端の実務者に落ちてきます。そしてその末端とは、現場で唯一「現実」を知っているあなたのことです。
この記事では、深い商流がどのように現場を壊すのかを構造として書きます。「なんかおかしい」ではなく、「これが原因だ」と言えるようになるために。
欧米生まれの現代奴隷商、それがSES
商流が深くなるのは偶然ではありません。SESという業態そのものが、深くなるように設計されています。なぜそうなるのか、構造から整理します。
合理性を追求した資本主義が行き着いた先がSES
人を使って差益を抜くという発想の起源は、イギリスの産業革命にあります。18世紀、資本家が工場を持ち、労働者を低賃金で酷使して利益を得る構造が生まれました。労働者は生産手段を持たず、資本家に時間と体を売るしかありませんでした。これがアングロサクソン型資本主義の原型です。
その発想はアメリカに渡り、IT業界の多重下請け構造という形に進化しました。1990年代半ばまで、アメリカのIT業界も日本と同じ構造を持っていました。元請けが大型案件を受注し、二次・三次請けへと再委託を繰り返す。人を調達して次に渡し、その差額で儲ける。アメリカはその後、インドや中国のオフショア開発の台頭により、この構造が90年代後半に崩壊しました。自分たちが生み出した構造を、自分たちで壊したのです。
日本はその崩壊が起きませんでした。欧米が手放した構造が、日本の終身雇用制度と雇用流動性の低さという土壌に落ちた結果、崩壊せずに根付いてしまいました。
日本にはもともと、人を売り買いして差益を抜くという商慣習はありません。それは欧米から輸入された負の遺産です。SESという業態は、その負の遺産が法律の抜け穴をくぐりながら今日まで生き延びたものに過ぎません。
人を転売する構造がそもそもの原因
SESのビジネスモデルを一言で言えば、人を調達して次に渡し、その差額で儲ける構造です。
資本主義は合理性と効率を突き詰めます。コストを下げ、利益を最大化する。その論理を徹底的に追求していくと、やがて人間そのものが調達・転売の対象になります。工場労働者を低賃金で酷使したイギリスの産業革命も、奴隷貿易で差益を抜いた大西洋三角貿易も、構造としては同じです。合理性の名のもとに、人を商品として扱い始める。SESはその現代版に過ぎません。
エンドクライアントが元請けに発注し、元請けが一次請けに流し、一次請けが二次請けに流す。それぞれの会社が「人を調達して次に渡す」という役割を担うことで、商流は自然に深くなります。各社は人を動かした時点で売上が発生するため、商流を深くすることに対して誰も止める理由を持っていません。
重要なのはここです。この連鎖の中で、誰もエンジニアの利益を守る必要がありません。人を次の会社に渡した時点で、前の会社の役割は終わっています。渡した先でエンジニアが何をされようと、前の会社の売上には影響しないからです。
合理性を追求した結果、人が商品になる。あなたが今いる現場はその構造の末端です。
深くなるほど中間業者だけが潤い、エンジニアの取り分と発言権が削られる
商流が1層深くなるたびに、何かが抜かれます。まず単価が抜かれます。エンドクライアントが支払う金額は変わらないのに、中間に入る会社が増えるほど、末端のエンジニアに届く単価は削られていきます。これは中抜きとして広く知られています。
しかし本当の問題は金額だけではありません。発言権も同じように削られるからです。
現場で問題が起きたとき、エンジニアが改善を求めようとすると、その声は何社もの中間業者を経由しなければ上に届きません。経由するたびに情報は薄まり、都合よく解釈され、最終的には「現場は問題なく動いている」という報告に変換されます。つまり商流が深い現場では、エンジニアがいくら声を上げても、上層には届かない構造になっています。
単価を抜かれ、発言権を奪われ、それでも現場の責任だけは末端に残る。これがSESの商流が深くなることの意味です。
現場の実態は上に届かない。届く頃には別の話になっている
商流が深くなると、情報は正確に伝わらなくなります。伝わらないのではなく、各層で都合よく変換されるのです。
このセクションでは、その変換がどのように現場を壊すのかを具体的に整理します。
単体試験未完了のまま「結合テスト消化」として報告される現実
現場では単体試験が終わっていない。設計も整備されていない。運用設計も成立していない。しかし対外的には「結合テスト消化中」として進捗が報告されています。
なぜこうなるのか。現場の実態をそのまま上げれば、プロジェクトが遅延していることが露呈します。遅延が露呈すれば、その責任を誰かが負わなければならない。だから各層で言い換えが起きます。「単体未完了」が「確認中」になり、「確認中」が「消化済み」になる。商流が深いほど、この変換が何層にも重なります。
ここで問題に気づいたエンジニアが注意を促すと、何が起きるか。他のメンバーは自分の責任になることを避けるために動き始めます。「今は忙しい」「自分の担当ではない」という言葉が出てきます。これは忙しいのではありません。責任の所在が自分に向くことを回避するための、現場で使われる免罪符のテクニックです。
問題を指摘した人間が孤立し、指摘しなかった人間が安全になる。その空気が現場に広がった結果、誰も問題を表面化させなくなります。放置すれば大問題に発展することすら、認識の外に追いやられていきます。工程管理ではなく、工程ラベルの貼り替えです。実態のない「完了」が積み上がっていく現場で、最終的にしわ寄せを受けるのは末端の実務者だけです。
異常を報告するほど、やり過ごしの言葉が返ってくる
知人からのヘルプを機に参画したプロジェクトでの話です。
現場に入って3日で異常を察知しました。指示系統が機能していない。責任の所在が誰にもない。仕様が固まっていないまま作業が進んでいる。そのタイミングでPMOから「このタスクいつまでに完了しますか」という質問が飛んできました。
まだ現場の解析中です。何が終わっていて何が終わっていないかすら把握できていない段階です。普通の判断力があれば、解析中であることを理解した上で話ができるはずです。しかしそこにそういう判断はありませんでした。ただ管理ツールの空欄を埋めるための質問が、サイボーグのように飛んでくる。そこに血の通った人間としてのやり取りはありませんでした。
これはIQの問題なのか、人間性の問題なのか。おそらくどちらもあります。ただ根本にあるのは、商流が深くなるほど現場の人間が「管理される対象」として扱われるようになるという構造です。状況を理解しようとする姿勢が消え、数字と期日だけが飛び交う現場が出来上がります。
この状況をエージェントに報告しました。返ってきた言葉は「問題があっても責任を追わせるようなことはしない」でした。現場を改善する気はない。席を埋めたい。参画を成立させるためだけに使われた方便です。報告は届きました。しかし対応は「やり過ごし」に変換されました。
異常を報告するほど、やり過ごしの言葉が返ってくる。あなたの現場でも同じことが起きていませんか。それはあなたの伝え方が悪かったのではありません。やり過ごすことが前提の構造の中に、あなたが置かれているだけです。
エージェントが機能しない現場で何が起きるか
エージェントが現場を把握できていない。改善できる立場にもない。その結果、現場では何が起きるのかを整理します。エージェントが機能しない現場の末路は、構造として決まっています。
責任の所在が誰にもない現場が出来上がる
かつてのエージェントは自社の開発部隊を持っていました。自社のエンジニアを核に置き、外部エンジニアをその周りに配置する。自社では足りない知識やリソースを外部から補うアウトソーシングとしての意味が大きく、管理できる人間が現場にいる分、ある程度の統制は機能していました。
久しぶりに参画した現場では、その構造が存在しませんでした。エージェントのプロパーは形の上では現場に存在するだけで、チームの役割を俯瞰した視野を持って作業をアサインする機能を果たしていません。当然、あとから参画したエンジニアはそれぞれ異なるベクトルで動くことになります。まるでパチンコ玉をひっくり返したように、全員が自分の思いだけで動いている状態です。
これはエージェントのビジネスモデルが変質した結果です。自社で技術力を持つ必要がない。管理できる人間を育てる必要もない。人材情報と案件情報をマッチングして差益を抜ければビジネスが成立する以上、現場の品質に責任を持つインセンティブがそもそも存在しません。商流が深くなるほど各社が「自分の範囲だけ」に閉じるようになり、管理責任を持つ会社が消え、バラバラに動くエンジニアだけが残ります。
その結果、技術的な判断や工程判断を行える有識者・責任者が現場に存在しない状態が出来上がります。窓口になっている人間もリーダーではない認識で、依頼を未整理のまま積み上げていく。指示する人はいるが、決める人がいない現場です。
誰も決めないまま作業が進むと、何かが起きたときに責任の矛先が定まりません。定まらないまま放置されると、最終的にその矛先は「現場にいた人間」に向かいます。契約上の担当と、現場で背負わされる実務が別物になるのはこのためです。
あなたの現場に「最終的に誰が決めるのか」を明確に答えられる人間はいますか。
問題を指摘した人間が責任者にされる構造
エージェントの本来の役割は、依頼人の状況を先読みして動くことです。プロスポーツ選手に例えるならば、負傷した選手を抱えるエージェントが、その負傷が試合出場・契約更改・スポンサーへの影響まで数ヶ月先まで脳内でトレースし、最善のルートを模索して先手を打って動くように、SESのエージェントも現場で異常が起きた時点で、それがエンジニアの契約・作業範囲・現場の体制にどう影響するかを先読みして動くべき存在です。
しかし実態は真逆です。現場で異常が起きても動かない。報告しても「やり過ごす」。自分の売上が確定した時点で関心が切れる。その結果、現場で何が起きるか。問題を指摘した人間が、その問題の責任者として扱われ始めます。
金融系Web-APアプリのリニューアルプロジェクトでの話です。AP基盤側とアプリ改修チームの責任分界が決まっていないまま、両チームが「現行踏襲」という言葉を旗印にそれぞれの認識で作業を進めていました。デプロイ時に両者のインターフェースが一致しないことが判明し、AP基盤側の構成変更が必要になりました。
そのタイミングでPMOから飛んできた言葉が「なぜ事前に認識を合わせてくれなかったのですか」でした。参画してまだ3日です。ステークホルダー間の調整はPMOの役割のはずです。しかしPMOにはその認識がありませんでした。問題が起きると相手を攻める。自分のタスクを自分のタスクと認識できていない。
本来の役割を果たせていないことをエージェントに伝えても、エージェント担当者がその意味を理解できていません。機能すべき立場の人間が全員機能していない。それでも誰もその事実に気づかず構造がそのまま回り続ける。
問題を見つけた人間が損をし、黙っている人間が安全になる。だから現場は腐ります。
「みんなで対応する」は責任者不在の言い換え
現場で「みんなで協力して対応します」「内部で揉んでみます」という言葉が出たとき、それは前向きな対応ではありません。担当者が答えを持っていないまま、会議の場で初めてみんなに解決してもらおうとしているだけです。問題を抱えた本人が答えを持たないまま会議を召集し、その場にいる全員に解決を委ねる。そこに集まった人数にかかる時間を工数として意識する感覚もありません。プロジェクト全体のコストを誰も計算していない中で、責任だけが集団の中に拡散していきます。
本来であればエージェントがここで機能すべきです。「2日間時間をください、こちらでも調べます」という言葉が出るのが、依頼人の状況を先読みして動くエージェントの姿勢です。
しかし実際に返ってくるのは「自分で調べられませんか」「誰かに聞けませんか」という言葉です。少しでも協力しようとする姿勢が皆無です。エージェントにとってエンジニアは利益を生む構造を維持するための部品に過ぎません。問題を解決する気はない。
人を席に座らせて売上が確定した時点で、その現場で何が起きようと関心の外にあります。
担当と責任の境界が曖昧なまま「みんなで」という言葉で責任が拡散していく。その構造をエージェントは把握していながら修正しようとしません。修正することで得られる売上が存在しないからです。
エージェントは現場が壊れても損をしない
商流が深くなるほど、エージェントと現場の距離は広がります。そしてその距離が広がるほど、エージェントが現場の崩壊から受けるダメージはゼロに近づきます。なぜエージェントは現場が壊れても平然としていられるのか、その構造を整理します。
人を席に座らせた時点で売上が発生する仕組み
エージェントのビジネスモデルはシンプルです。人を現場に送り込み、その稼働に対して対価を得る。つまり人を席に座らせた時点で売上が発生します。その後現場で何が起きようと、エージェントの売上には直接影響しません。
ここで根本的な矛盾があります。実際に収益を稼ぎ出しているのはエンジニアです。エージェントはその収益から分け前をもらう立場に過ぎません。にもかかわらず、現場では暗黙の了解としてエージェントがエンジニアの上位に位置する関係が成立しています。収益を生み出す側が下で、分け前をもらう側が上という構造です。この逆転こそが、SESという業態が抱える最大の問題です。
現場が崩壊しかけていても、エンジニアが消耗していても、エージェントにとってそれは「現場の問題」です。契約が続いている限り売上は入り続ける。契約が切れても、次の人材を送り込めば売上が回復する。現場の品質を改善するインセンティブが構造上存在しません。
このねじれた構造に気づき、本来のエンジニアとエージェントの関係を見直そうとする動きが一部のエージェントの間で出てきています。しかし既得権益の壁は厚く、その動きは容易には広がらないのが現状です。構造を変えようとする者が、構造に守られた者たちに阻まれる。それがこの業界の実態です。
エンジニアとエージェントでは「責任」の定義が根本から違う
参画3日目、現場の異常を報告したときにエージェントから返ってきた言葉が「問題があっても責任を追わせるようなことはしない」でした。現場に留まってもらうために使った言葉です。
しかしこの言葉の意味において、エンジニアとエージェントの間には深刻な温度差があります。
エンジニアにとっての責任とは、本来自分の担当ではない作業を引き取らされること、設計の不備を自分の判断で埋めること、誰かの失敗のしわ寄せを自分の工数で吸収することです。
アプリ側と基盤側の調整が行われていなかったことで問題が発生し、アプリ側の修正では膨大な工数が発生するため基盤側の構成変更を余儀なくされたケースがあります。担当範囲を超えた作業を引き取らされた。エンジニアの感覚ではこれが責任を負わされた状態です。
しかしエージェントにとっての責任とは、賠償などの金銭が発生することだけを指します。金銭的な損害が生じない限り、エンジニアがどれだけの負荷を引き取ろうと、エージェントの認識では「責任を追わせていない」ことになります。
言葉の定義がそもそも違う。だから「責任は追わせない」という約束は、最初から噛み合っていません。エンジニアが感じる理不尽と、エージェントが感じる「約束は守った」という認識が、永遠にすれ違い続けます。
言葉は安全、現場は危険。書面と実務が乖離する理由
エージェントは書面上の言葉を慎重に選びます。「責任は追わせない」「担当外の作業は引き取らせない」「負荷が集中する進め方はしない」。これらの言葉は文面として残ります。言質を取られないための言葉でもあります。
しかし現場の実態はその言葉と真逆の方向へ進みます。担当外の作業が流れ込む。負荷が一人に集中する。責任の所在が曖昧なまま作業が積み上がる。書面と現場が乖離していく。
なぜこうなるのか。エージェントは現場の実態を把握できていないからです。把握できていないのではなく、把握しようとする手段も動機もありません。商流が深いほどエージェントと現場の距離は広がり、書面の言葉が現場に届かなくなります。届かないまま放置されても、エージェントの売上には影響しません。
結果として言葉だけが安全で、現場だけが危険という状態が出来上がります。エージェントが約束した言葉は書面の上に残り、現場で起きている実態はエンジニアの体の中にだけ残ります。その乖離を誰かが埋めなければならないとき、その役割は必ず末端のエンジニアに落ちてきます。
書面に残った言葉を信じて参画したエンジニアが、現場の実態との乖離を一人で引き受ける。これがSESにおける書面と実務の乖離の正体です。
管理の失敗を現場の残業で埋める構造
現場が遅延しています。上位から「期日までに何とかするように」という指示が降りてきます。対応策として休日出勤が決まります。
しかし遅延の根本原因は残業で解決できるものではありません。設計が未整備、体制が機能していない、責任分界が曖昧、仕様が未確定。これらは工数を投入しても解決しません。管理の失敗を現場の体力で埋めようとしているだけです。
エージェントはこの構造を止めません。残業が発生しても、エージェントの売上には影響しないからです。むしろ時間精算型の契約であれば、稼働時間が増えるほど売上が増える構造になっています。現場のエンジニアが消耗するほど、エージェントは安全でいられる。現場の崩壊とエージェントの利益が、構造上切り離されています。
根本原因に誰も手をつけない。期日だけが動かない。その狭間で現場のエンジニアだけが体力を削られていく。管理の失敗を残業で埋める構造は、エージェントが機能しない現場で必ず発生します。あなたの現場で心当たりがあるとすれば、それは偶然ではありません
深い商流SESが技術者に与える最終的な害
商流が深くなることの害は、単価が抜かれることだけではありません。上に行くほど責任が薄まり、下に行くほど現実が重くなる。その構造の中で最終的にしわ寄せを受けるのは、現場で唯一動ける技術者です。
担当範囲を超えた作業が、できる人間だけに流れ込む仕組み
深い商流のSES現場では、契約上の担当と現場で実際に背負わされる実務が別物になります。
一例を挙げると、Web-APのAP基盤構築でTomcatやJBossといったサーブレットコンテナを担当したとします。構築した環境が現場で稼働し始めた瞬間から、その名前に紐づくあらゆる問題がAP基盤担当に振られてきます。アプリ内の不具合で障害が出てもAP基盤担当に振られる。アプリログの出力先の問題もAP基盤担当に振られる。本来アプリ側が責任を持つべき領域の障害まで全部飛んでくる。構築しただけなのに、その環境で動くものすべての責任者として扱われていきます。
この状況で責任分界点を明確に言い切り、本来の担当に付き返すことができるのは経験があるからです。経験の浅いエンジニアにはできません。そのまま引き取るしかない状況に追い込まれます。
期限までに問題が解決しない可能性が高いため、エージェントに相談します。しかしエージェント自体が技術的な内容を理解できていません。返ってくる言葉は直接的な丸投げではありません。「〇〇さんが困っているみたいで」「そこは少しあなたにも関係があるかもしれないので」という言い方で、数パーセントの責任がこちらにもあるかのようなニュアンスを滑り込ませてきます。問題の本質には何も触れず、言いがかりに近い言い方で責任の一端をエンジニアに向けて終わりです。
なぜこうなるのか。できるエンジニアにだけ仕事が流れる構造があるからです。答えを持っているエンジニアに質問が集まり、動けるエンジニアに依頼が集まり、解決できるエンジニアに責任が集まる。そのエンジニアの契約上の担当範囲は誰も気にしません。担当範囲を超えた作業を引き取るたびに、便利屋としての位置が固定されていきます。一度その位置に置かれると覆すことは困難です。断れば協力的でないと見られ、受ければさらに範囲が広がる。どちらに転んでも不利な状況に追い込まれます。
頼りにされているという感覚の正体
担当を超えて動いている。頼りにされている。現場で必要とされている。そう感じる瞬間があるかもしれません。しかしその感覚の正体は、評価ではありません。
技術力があり、状況を把握でき、動けるエンジニアは、深い商流SESの現場において最も都合のいい存在です。責任の所在が曖昧な作業を引き取らせやすく、仕様不明の作業を任せやすく、担当範囲を超えた依頼を断りにくい。そのエンジニアが消耗して離脱しても、エージェントは次の人材を送り込めばいい。
高く評価されたのではありません。使い潰しやすい位置に置かれただけです。
深い商流SESの害は単価を抜かれることだけではありません。技術力のあるエンジニアほど、責任と不確実性を全部引き受ける位置に追い込まれていきます。その構造に気づいたとき、あなたはどう動きますか。
まとめ
SESの多重下請け構造は、イギリスの産業革命に端を発した資本主義が合理性を追求した結果、人を商品として転売する形に行き着いたものです。アメリカが生み出し、日本が引き継いだ。アメリカはとっくに手放した構造を、日本だけが今も使い続けています。
商流が深くなるほど、エージェントは現場を把握できなくなります。現場の異常を報告しても、返ってくるのはやり過ごしの言葉だけです。エージェントにとって人を席に座らせた時点で売上が発生する以上、現場の品質を改善するインセンティブが構造上存在しません。
エージェントが機能しない現場では、責任の所在が誰にもない状態が出来上がります。問題を指摘したエンジニアが責任者にされ、集団対応を装った責任の拡散が起きます。書面上の言葉は安全で、現場だけが危険という状態が続きます。
そして最終的な害は、技術力のあるエンジニアほど便利屋として固定され、責任と不確実性を全部引き受ける位置に追い込まれることです。頼りにされているという感覚の正体は、使い潰しやすい位置に置かれているということに過ぎません。
商流の深さは偶然ではありません。構造として最初からそうなっています。その構造の中に置かれているとき、あなたに必要なのは個人の努力ではなく、構造を見抜く視点です。
現場で手が止まっている、論点が整理できない、責任分界が曖昧で前に進めない。そういう状況に置かれているなら、まず相談してください。
当ブログでは、必要な場面に向けたお手伝いも始めています。
論点整理、仕様整理、責任分界の切り分けなど、実務で前に進めなくなった場面を対象にしています。
まずは、対応できる内容を下記ページにまとめています。
依頼・問い合わせは、下記のページからお願いします。
