エージェントの実態

エージェントが曖昧にしがちな責任分界の話

SES案件に参画するとき、担当範囲や指揮命令系統をエージェントから明確に伝えられた経験がある人は少ないと思います。それはエージェントが怠けているからではありません。責任分界を確認することが、エージェントの業務に最初から含まれていないからです。

エージェントの業務は、希望条件のヒアリングから始まり、案件とのマッチング、契約締結、定期連絡で終わります。現場に入った後、担当範囲がどこまでか、指揮命令は誰が持つか、問題が起きたときの責任はどこにあるか、これらを確認して伝える業務はどこにも存在しません。

その結果、多くのエンジニアは入場当日まで現場の詳細がわからないまま参画することになります。何をどこまでやるのか、誰の指示で動くのか、それが現場に入って初めてわかる状態です。

この記事では、エージェントの業務の実態と本来あるべき姿のギャップを整理しながら、なぜ責任分界が曖昧なまま参画が進むのかを説明します。参画前に自分で何を確認すべきかの判断軸も合わせて示します。

そもそもエージェントは責任分界を理解していない

責任分界を理解するには、技術的な知識が前提になります。何が入力で何が出力か、どこまでが対象範囲でどこからが対象外か、これらは技術がわかっていないと境界を引けません。

しかし現状のエージェントに求められているのは営業・調整スキルであり、技術を習得するコストを負う理由がありません。結果として責任分界に踏み込めないまま業務が終わります。

本来であれば技術的な文脈で責任分界を確認しエンジニアに伝える役割があるはずですが、現状はその役割が機能していません。

技術的な話が通じない相手に責任分界は整理できない

責任分界を確認するには、現場で何が起きているかを技術的な文脈で把握できなければなりません。本来のエージェントと現状のエージェントの業務を比較すると、その差は明確です。

本来のエージェントの業務

  • 参画前に現場の担当範囲を確認してエンジニアに伝える
  • 指揮命令系統が誰にあるかを契約前に明確にする
  • 責任分界が曖昧な場合はエンドユーザーと調整する
  • 契約内容にエンジニアが不利になる曖昧さがあれば事前に整理する
  • 参画後に問題が起きたときの窓口として機能する

現状のエージェントの業務

  • 希望条件のヒアリング
  • 案件とのマッチング
  • 契約締結
  • 定期連絡(問題がなければ放置)

本来の業務と現状の業務を並べると、責任分界に関わる項目が現状の業務フローに一切存在しないことがわかります。技術的な話が通じない相手に責任分界の整理を期待しても、そもそも何を確認すればいいかがわかりません。エージェントに責任分界の確認を求めること自体が、現状の業務フローでは成立しないのです。

実際にエージェントに責任分界について直接確認したことがあります。返ってきた回答は3点でした。

回答3点

  • 我々の業務はエンドユーザーの求める人材を探して案件に参加させること。
  • 斡旋したエンジニアは作業時間分の対価を受け取り、そこから適正な利益を得ること。
  • SES契約である以上、案件の遅れや問題が発生してもエンジニアに責任はない

ということでした。
一見するとエンジニアを守る論理に聞こえます。

しかし現場の実態は違います。

契約上の責任がなくても、作業が止まれば矢面に立つのは現場にいるエンジニアです。品質を問われても、関係者から詰められても、その場にいるのはエンジニアです。エージェントはその場にいません。

契約上の話と現場の実態の話を意図的に混同しているのか、それとも現場の実態を知らないのか、どちらにしても現場のエンジニアには関係のない論理です。責任分界が曖昧なまま送り込まれたエンジニアが、現場でその帳尻を合わせることになります。

エージェントが曖昧にしたまま進める理由

エージェントが責任分界を曖昧にしたまま進める理由には、明確な利益構造があります。順を追って整理します。

ポイント

  • 未経験エンジニアは単金が安く、エージェントはその差額で利ざやを稼ぐことができる
  • しかし未経験だけでは現場が回らないため、ベテランエンジニアを同じ現場に入れて穴埋めさせる
  • その役割分担を参画前に表に出すと契約が成立しにくくなる
  • だから責任分界を曖昧にしたまま進める
  • さらに多重構造の商流の中では、エージェント間で人の融通による貸し借りが発生している
  • この貸し借りの関係を維持するために、水面下の取り決めを表に出すわけにはいかない
  • 責任分界を明確にすることがエージェント間の利益構造を壊すリスクになる

実際にこんなことがありました。親の介護のために時間を確保する必要があり、単金を大幅に抑えてでも軽作業の案件を探して参画したことがあります。業務内容はWebシステムのリニューアルで、既存のサーブレットコンテナを新しいバージョンに移行する作業でした。過去に同種の構築案件を数十年やってきた経験があったため、WBSは常にオンスケで進めていました。

参画してしばらく経つうちに周囲のメンバーが激しく入れ替わり始めました。技術がついてこられないもの、体調を崩すものが続出し、最終的に技術をほとんど理解していないメンバーが大半を占める状況になりました。エンドユーザーからは「新しいメンバーの遅れは私が埋め合わせれば問題ない」と言われ続け、他のメンバーへのケアも重なり、介護の時間を確保するどころではない状態が続きました。

限界を感じて直談判した結果、エージェントが多重構造になっていたこともあり、間に入っていたエージェントも含めて5社面談をすることになりました。そこで発覚したのは、未経験のメンバーを安く雇い、ベテランエンジニアと同じ単金でプロジェクトに参画させていたという事実でした。エージェント間では、未経験メンバーの面倒は私がすべてカバーするという話が最初から決まっており、その取り決めはエンジニアである私には一切知らされていませんでした。

これがエージェントが責任分界を曖昧にしたまま進める理由の実態です。曖昧にしておくほど都合よく人を動かせる。明確にしてしまうとエージェント間の貸し借りと水面下の取り決めが表に出てしまう。責任分界を確認しないのは怠慢ではなく、曖昧なままにしておく方がエージェントの利益構造として都合がいいからです。

責任分界が曖昧なまま現場に入ると何が起きるか

責任分界が曖昧なまま現場に入ると、最初は何も問題がないように見えます。しかし作業が進むにつれて、担当範囲の境界がないことで起きる問題が少しずつ表面化してきます。ここでは責任分界が曖昧なまま参画した場合に現場で何が起きるかを整理します。

担当範囲が決まらないまま作業が始まる

エージェントの役割がマッチングと契約締結に特化していく中で、参画前に担当範囲を確認するという行為自体が業界の慣習から抜け落ちています。エージェントに担当範囲を確認しても、そもそもその概念がないため答えが返ってきません。確認する側も確認される側も、担当範囲を定義することが参画前の必須事項だという認識を持っていないのです。

その結果、現場に入ったエンジニアは担当範囲が何も決まっていない状態で作業を始めることになります。現場で最初に言われるのは「とりあえずこのあたりをお願いします」という程度の指示です。どこまでが自分の範囲でどこからが他の誰かの範囲かが定義されないまま、作業だけが始まります。

担当範囲が定義されていない現場では、空白の範囲を誰かが埋めることになります。動ける人間がその空白を引き受け続けた結果、参画時の想定をはるかに超えた範囲を抱えることになります。これはエンジニア個人の問題ではなく、参画前に担当範囲を確認する仕組みがエージェントの業務に存在しないことで起きる構造的な問題です。

エージェントの頭の中には「現場に入れば誰かが指示するだろう」という前提しかありません。担当範囲を定義する責任を現場に丸投げしたまま契約を結ぶことが当然になっている。その結果を引き受けるのは、現場に送り込まれたエンジニアです。

目隠しされたまま崖っぷちを歩かされる感覚

問題が起きても、エージェントは状況の危険度を正しく感知できません。だから壊れたレコードのように、「責任はない」「大丈夫です」と同じ言葉を繰り返します。その言葉は担当エンジニアをを守るための言葉ではありません。自分が先に言った説明を覆したくない、自分の判断ミスを認めたくない、その保身を維持するために回っている言葉です。

現場が崩れかけていても、状況に合わせて言葉を修正するのではなく、何とか言い回しだけで逃げ切ろうとします。だから、言われる側は安心するどころか、この相手は危機の大きさすら理解していないと感じて、余計に追い詰められます。

怖いのは、何をしたら踏み外すのかが見えないことです。もっと怖いのは、踏み外した瞬間だけははっきり想像できることです。問題が表に出た瞬間、それまで「大丈夫です」と言っていた人たちは引きます。取り残されるのは、曖昧な説明のまま現場に立たされていたエンジニアだけです。

契約上の責任はない。その言葉は、現場でエンジニアを守る盾にはなりません。責任分界が曖昧なまま送り込まれた側が感じるのは、安心ではありません。目隠しをされたまま、崖の縁を一歩ずつ、つま先で歩かされているような感覚です。落ちた後に誰が手を離したのかは曖昧にされるのに、落ちた責任だけは自分に集まる。その緊張が、毎日途切れず続きます。

参画前に責任分界を確認する方法

エージェントが責任分界を確認しない構造である以上、参画前に自分で確認するしかありません。ここでは何を確認すべきか、どう切り出すかを整理します。

確認すべき項目と確認の切り出し方

参画前にエージェントへ確認すべき項目には、動機に関わらず共通して押さえるべきものがあります。

エージェントへの確認項目

  • 担当範囲はどこまでか、契約書に明記されているか
  • 他メンバーのフォローが自分の範囲に含まれているか
  • 指揮命令系統は誰が持つか
  • 商流は何層になっているか
  • 単金の計算根拠は何か
  • エンドユーザーは自分のスキルレベルと参画目的を正確に把握しているか

この共通項目を押さえた上で、参画する動機によって追加で確認すべき項目が変わってきます。

  • 資金稼ぎが目的であれば、作業量が単金に見合っているか、残業や休日対応の想定がどうなっているかを確認します。
  • 技術習得が目的であれば、希望する技術が実際に使える案件かどうかをエージェントが把握しているかを確認します。
  • キャリアを積むことが目的であれば、担当範囲が経歴として使える実績になるかを確認します。
  • IT業界への入口として参画するのであれば、未経験を前提とした案件であることをエンドユーザーが正確に認識しているかを確認します。現職からの退避が目的であれば、作業範囲が際限なく広がらない構造になっているかを確認します。

動機が曖昧なまま参画すると、確認すべき項目も曖昧になります。自分がなぜこの案件に入るのかを先に明確にしておくことが、参画前の確認を機能させる前提になります。

参画前に自分で確認する項目

下記の表は、SES案件へ参画する前に、自分で何を確認しておくべきかを、参画動機ごとに整理した表です。単価、担当範囲、負荷、成長余地などを事前に見極めるための確認軸をまとめています。

参画前に自分で確認する項目
参画動機 確認項目 確認の切り出し方
資金稼ぎ ・単金と実際の作業量が見合っているか
・他メンバーのフォロー範囲が含まれていないか
・残業・休日対応の想定があるか
・今回の単価は、どの範囲の作業を前提にしていますか?
・他メンバーのフォローが発生する前提はありますか?
・残業や休日対応は、通常どの程度見込まれていますか?
技術習得 ・習得したい技術が実際に使える案件か
・指導を受けられる環境があるか
・担当範囲に学習の余地があるか
・この案件では、どの技術を実際に触ることになりますか?
・参画後に質問や相談ができる相手はいますか?
・担当範囲の中に、新しく学べる要素はありますか?
キャリア増 ・経歴として使える実績が積めるか
・担当範囲が明確に定義されているか
・この案件で自分の担当範囲はどこまでですか?
・経歴として説明できる成果物や担当領域は明確ですか?
IT業界への入口 ・未経験を前提とした案件か
・フォロー体制が明確にあるか
・責任範囲が限定されているか
・この案件は未経験参画を前提にしていますか?
・参画後のフォロー体制はどうなっていますか?
・未経験者に求める担当範囲はどこまでですか?
現職からの退避 ・精神的・物理的な負荷が前職より重くないか
・担当範囲が際限なく広がらない構造か
・この案件の残業や緊急対応の頻度はどの程度ですか?
・担当範囲が後から拡大することはありますか?
・役割追加が発生する場合、誰が判断しますか?

エージェントに確認すべき項目

下記の表は、SES案件へ参画する前に、エージェントへ何を確認すべきかを、参画動機ごとに整理した表です。契約範囲、責任分界、商流、フォロー体制などを確認するための観点をまとめています。

エージェントに確認すべき項目
参画動機 確認項目 確認の切り出し方
資金稼ぎ ・他メンバーのフォロー範囲が契約に含まれているか
・単金の計算根拠は何か
・商流は何層になっているか
・この単価は、どこまでの作業範囲を前提にした金額ですか?
・他メンバー支援や雑多なフォローは契約範囲に入っていますか?
・商流は何層ですか?
技術習得 ・担当範囲に希望の技術が含まれることを契約で確認できるか
・案件の技術スタックをエージェントは把握しているか
・担当予定業務に、希望している技術が含まれると確認できますか?
・案件の技術スタックを具体的に把握していますか?
キャリア増 ・担当範囲が契約書に明記されているか
・責任の所在が誰にあるかを確認できるか
・担当範囲は契約書や説明資料に明記されていますか?
・責任の所在は誰にありますか?誰が最終判断者ですか?
IT業界への入口 ・フォロー体制が契約上どこに定義されているか
・未経験前提であることをエンドユーザーが認識しているか
・フォロー体制は契約上どこで担保されていますか?
・エンドユーザー側は未経験参画を前提として認識していますか?
現職からの退避 ・作業範囲が際限なく広がらないことを契約で担保できるか
・指揮命令系統が誰にあるかを契約前に確認できるか
・作業範囲の拡大を防ぐ条件は契約上ありますか?
・指揮命令系統は誰にありますか?現場、上位会社、御社のどこですか?

答えられないエージェントへの対処

参画前の確認をエージェントに投げたとき、明確な回答が返ってこない場合があります。「確認してみます」「現場に聞いてみます」「たぶん大丈夫だと思います」という返答が続くようであれば、それ自体が重要な判断材料です。問題は、その場で答えられないことではありません。何を確認すべき案件なのかが整理されておらず、責任分界や担当範囲が曖昧なまま話が進んでいることです。エージェントが答えられないという事実は、そのエージェントの質だけでなく、案件そのものが未整理である可能性も示しています。

このとき取るべき対処は、曖昧なまま参画を決めないことです。参画判断は保留にし、確認が必要な項目を切り分け、いつまでに回答が必要なのか期限を切ります。そして、回答は必ず文面で残します。電話で口頭説明を受けた場合でも、その内容をメールやメッセージで確認し、記録として残せないものは未確認として扱います。参画前に文面で残せない説明は、参画後も曖昧なまま使われる可能性が高いからです。

確認を急かしても曖昧な回答しか返ってこない場合、参画後に担当範囲や責任分界を確認しようとしても、同じことが繰り返されます。参画前に答えられないエージェントが、参画後に急に答えられるようになることはほとんどありません。むしろ、現場に入ってから「そこまでやる前提ではなかった」「その認識はありませんでした」と言われ、曖昧だった部分だけがこちらに押しつけられる形になりやすくなります。

判断の基準はシンプルです。確認項目に対して具体的な回答が返ってくるかどうかです。「契約書に明記されています」「担当範囲はここまでです」「指揮命令は現場のリーダーが持ちます」と答えられる案件と、「たぶん」「確認します」「大丈夫だと思います」しか返せない案件では、参画後のリスクが根本から違います。確認項目への回答の質は、そのエージェントの信頼性を見る材料であると同時に、その案件がどれだけ整理されているかを測る材料でもあります。

結論として、答えられないエージェントに対してすべきことは、曖昧な説明を信じて前に進むことではありません。回答期限を切り、文面で確認し、それでも未確認項目が残るなら、その案件には参画しないことです。参画前に確認できない責任分界は、参画後に自然と明確になることはありません。むしろ、現場に入ってから自分だけが背負わされる火種になります。

まとめ

この記事では、エージェントが責任分界を曖昧にしたまま参画が進む構造を整理しました。

エージェントの業務はマッチングと契約締結までであり、責任分界を確認するステップが業務フローに存在しません。技術的な知識がなければ責任分界は整理できず、現状のエージェントにその習得を求めるインセンティブもありません。責任分界が曖昧なまま現場に入ると、担当範囲が定義されないまま作業が始まり、問題が起きたときに目隠しされたまま崖っぷちを歩かされる状態に追い込まれます。

この構造はエージェント個人の問題ではなく、SESという商流全体の設計として定着しています。だからこそ、参画前に自分で確認するしかありません。動機を明確にし、確認項目を切り出し、回答を文面で残す。それが現場に入った後の自分を守る唯一の手段です。

当ブログでは、必要な場面に向けたお手伝いも始めています。

論点整理、仕様整理、責任分界の切り分けなど、実務で前に進めなくなった場面を対象にしています。
まずは、対応できる内容を下記ページにまとめています。

依頼・問い合わせは、下記のページからお願いします。

よく読まれている記事

1

「私たちが日々利用しているスマートフォンやインターネット、そしてスーパーコンピュータやクラウドサービス――これらの多くがLinuxの力で動いていることをご存じですか? 無料で使えるだけでなく、高い柔軟 ...

2

Linux環境でよく目にする「Vim」という名前。サーバーにログインしたら突然Vimが開いてしまい、「どうやって入力するの?」「保存や終了ができない!」と困った経験をした人も多いのではないでしょうか。 ...

3

ネットワーク技術は現代のITインフラにおいて不可欠な要素となっています。しかし、ネットワークを深く理解するためには、その基本となる「プロトコル」と「レイヤ」の概念をしっかり把握することが重要です。 こ ...

4

この記事は、Linuxについて勉強している初心者の方向けに「Shellスクリプト」について解説します。最後まで読んで頂けましたら、Shellスクリプトはどのような役割を担っているのか?を理解出来るよう ...

5

Javaは世界中で広く使われているプログラミング言語であり、特に業務システムやWebアプリケーションの開発において欠かせない存在です。本記事では、初心者向けにJavaの基礎知識を網羅し、環境構築から基 ...

-エージェントの実態