【案件自分で探させてくれや】元営業がSES企業の案件アサインフローをAXしたくて躍動・玉砕・棚ぼたした話

目次

• はじめに
• 結論
• 背景：顧客の現場がダメなら自社をハックすればいい
• 企画：経営課題をハックして自分の提案に「大義名分」を持たせる
• 情報収集：元営業のスキルをフル活用した「社内営業」と直談判
• 提案：技術論を捨て「費用対効果」に特化した15分
• 結果：まあそうですよね
• おまけ：GraphRAGを使った案件検索基盤の概要
• 感想

はじめに

SES企業って営業やらマネージャーがエンジニアの案件探しますよね。

会社から見るとステークホルダーとの関係性維持や売上向上を優先しやすく合理的なフローなのですが、エンジニアから見て下記のような情報が見えづらいなと思っています。

• 社内にどのような案件があるのか
• 自分はどの案件に参画できる可能性があるのか
• 希望案件に進むために、何が足りていないのか
• どの経験を積めば、希望するキャリアに近づけるのか
• いつ希望の案件に入れるタイミングが来るのか

こういった課題を解決する簡単な方法として、今回私は「エンジニア主導の案件アサインフローの確立と実現に向けたAX推進」を企画し、執行役員へ直接提案を持っていきました。

当然、提案自体は見事に玉砕。

しかし、組織の課題に対して当事者意識を持ってロジカルに提案したことを気に入ってくれたのか、社内で進めようとしているプロジェクト概要を共有してくれたりAX事業部への兼務を打診されたりとポジティブな反応をいただけました。

本記事は一エンジニアの思い付きから、1週間の間で企画を練りステークホルダーを巻き込み実現に必要なリソースを確保しながら執行役員の貴重な1時間をもらって提案を仕掛けたの記録です。

「現状に不満はあるけれど、どう動けばいいか分からない」という方の行動のきっかけになれば幸いです。

結論

• 「案件を自分で選べなくてキャリア実現がしづらい」という自分の中の課題感と「現場型AXを進めよう」「離職率を下げよう」という会社のビジョン・課題感をうまいこと統合して訴求して一定の成果を得た
• 今回の学びは「なにか不満があるなら改善できるよう行動するといい」ということ
• 今回の反省点は「特になし」。よく頑張ったと思います。

背景：顧客の現場がダメなら自社をハックすればいい

きっかけは、つい最近あった社員総会です。
経営陣から「全社的にAX（AIトランスフォーメーション）を進めていこう」という強い旗振りがされました。

※ちなみにAXとは、こういうものです。

これを聞いたとき、私は「参画している案件でAXを推進し、単価向上や人員拡大を狙いにいくのがミッションだな」と捉えました。

会社の経営方針にはいち早くコミットして成果を出したかったのですが、いざ自席に戻ると「現場の壁」にぶつかります。
私の参画案件はセキュリティ制約が非常に厳しく、ツール等の導入範囲も狭かったため、どうしても目に見えるインパクトを出しづらい状況だったのです。

「技術的な制約のせいで、全社方針の波に乗れないのはもったいない……」

そう考え込んでいたとき、ふと逆転の発想が浮かびました。
「顧客の現場でインパクトが出せないなら、いっそ自社の仕組みをAXでハックすればいいんじゃないか？」

これが、今回の無謀な挑戦の始まりでした。

企画：経営課題をハックして自分の提案に「大義名分」を持たせる

社員総会の中で経営陣から生々しい課題が共有されていたことを思い出しました。
「現在の離職率は下がってきているが、ここからさらに1〜2%下げたい。原因の一端は、エンジニアのキャリア実現性が低いことによる不満だ」

これを思い出したとき脳内に電流が走りました。
「前々から自分が課題に感じていた『案件アサインフロー』を、AIの力で変革すれば、それこそ会社が掲げるAXのド真ん中じゃないか！」と。

そこからの行動はシンプルです。
会社が掲げた「離職率低下」という経営課題をそのまま流用し、自分のやりたい企画に圧倒的な「正当性 = 大義名分」を持たせるロジックを組み立てました。

大まかな内容は下記のようになります。

1. 経営視点と現場課題のドッキング（なぜやるのか）

まず、SES企業の労働集約型モデルにおいて、売上を最大化する要素を因数分解しました。

$$\text{売上向上要因} = \text{エンジニアの質} \times \text{量} \times \text{在籍期間}$$

この中の「在籍期間」を延ばす（＝離職を防ぐ）ために、一般的な退職要因である「業務・給与・人間関係」と、SES特有の構造を結び付けました。

• 業務関係（★今回のターゲット)
  • 「やりがい」や「キャリア実現」の連動。SESでは“案件ガチャ”が発生しやすく、希望が通るか不透明なため最も不満が溜まりやすい。
• 給与関係
  • 下請け構造による単価限界があり、自社開発等に比べると構造的に一気に上げづらい。
• 人間関係
  • 現場が分散するため、帰属意識が希薄になりがち。

つまり、会社が求める「あと1〜2%の離職率低下」を達成するには、最もコントロールしやすく、エンジニアのエンゲージメントに直結する「業務関係 = キャリア実現性」の不満を解決するのが最短ルートだと結論づけました。

2. 課題感の共有：「情報非対称性」による不満

現状のアサインは、営業とマネージャーが案件を探してエンジニアに提案する「トップダウン型」です。
これは一定の合理性がある反面、エンジニア視点では以下の情報が完全にブラックボックス化していました。

• 社内にどんな案件があるのか見えない
• 自分がその案件に参画できる可能性（打診状況）が分からない
• 希望の案件に行くために、今自分に何が足りないのか不明確
• 次のチャンスがいつ来るのかのタイミングが見えない

結果として、エンジニア側には「自律性・透明性・公平性」の欠如による不満が溜まります。

特に市場価値に敏感なハイレベル人材ほど、この「キャリアの不透明さ」を嫌って早い段階で転職を検討してしまいます。

3. AXが目指す「三方良し」の自律型アサイン

本プロジェクトでは、アサインフローをAXし、情報格差を無くすことで、関係者全員が同じ情報ベースで判断できる仕組みを目指しました。

具体的には「GraphRAGを用いた案件検索基盤」を核として、エンジニアが案件情報にアクセスでき、営業・マネージャー・エンジニアが共通認識を持った状態で会話できることを目指しています。

AXによって期待されるのは

• 案件情報の透明化
• アサイン判断材料の可視化
• 専門性を活かした分業の徹底

であり、AX実現後の状態等は下記のようになる想定です。

AXによる変化	現状発生している負荷・制約	AX後に目指す状態	期待される効果
エンジニア	案件情報が複数の経路に分散しており、社内案件の全体像を把握しづらい 参画に必要なスキル・経験も見えづらく、希望キャリアと案件を結びつけにくい	案件を自ら検索・比較し、希望案件に必要なスキル・経験を確認できる 参画希望理由や現在のスキルとの一致・不足要素を整理し、マネージャーに共有できる	案件選択への納得度が上がる 社内でのキャリア実現可能性を判断しやすくなる 必要な経験や学習の方向性が明確になり成長速度向上が見込める
マネージャー	エンジニアごとの希望確認、案件探索、条件整理を個別に行う必要があり、アサイン検討に一定の工数がかかっている 参画可否の判断材料も属人性があり、案件や担当者によって整理方法が異なりやすい	案件要件、本人希望、スキル・経験、AIが整理した参画可能性をもとに、参画可否・育成方針・営業連携に集中できる	情報整理や案件探索にかかる工数を削減できる 判断材料が共通化され、説明の一貫性が高まる 育成・評価・組織運営に時間を使いやすくなる
営業	現場業務の専門性が高く、適切なマッチングには広範囲な知識とエンジニアに近い専門性が求められ難易度が高い 顧客折衝、案件獲得、社内アサイン調整を並行して行う必要があり、情報整理や社内調整の負荷が発生している	アサイン関連業務が激減する エンジニア情報や参画希望理由が整理された状態で共有され、顧客提案や面談調整に活用できる	案件ミスマッチを未然に防げる AIによってエンジニア情報が体系化され、顧客への提案精度/営業効率が向上 アサイン業務の自動化により、高単価案件確保や単価向上に特化できる

短期的には案件検索基盤の整備を目指しますが、中長期的にはジュニア層のキャリアビジョン作成の手助けができるAIエージェントや、エンジニアのやり取りを蓄積し営業支援への利用やハイパフォーマーの行動特性や成果の共有も目指しており、離職率低下のみならず採用競争力にも効く社内システムを構築する、というビジョンも持っているということを追記しています。

こうして、「経営陣のコミット目標」と「現場の技術的解決策」を一気通貫で繋いだ企画書が完成しました。

あとは、「これを誰に、どういう順番で持っていけば、組織が一番最速で動くか」というステークホルダーのハックに移れるようになりました。

情報収集：元営業のスキルをフル活用した「社内営業」と直談判

こっから情報収集フェーズ。誰が何の権限・情報を持っているかを集めてクリティカルなキーマンに提案する必要がありました。

まず企画を机上の空論で終わらせないために、まずは何が必要かを冷静に洗い出しました。

• データ：RAGに食わせるための、営業が握っているリアルな案件情報
• 権限：セキュアなデータを扱うための社内リソース・LLM APIの使用権限
• 予算：PoCから実装運用までにかかるコストの決済

これらすべてを一撃でクリアするには、現場からボトムアップで承認を積み上げるのは時間がかかりすぎますし途中で否定されて止まる可能性がありました。

そこで私は、元営業の経験を活かし、「経営陣がAXの旗を振っている今、トップダウンで上を抑えにいくのが最速最強」と判断。
社員総会で登壇していた「AX推進担当の執行役員」を最終ターゲットに定めました。

1. 外堀を埋めるための徹底的なキーマンヒアリング

いきなり役員に突撃しても、現場のリアルな裏付けがなければ一蹴されます。
ターゲットが持っていない「現場のファクト」を揃えるため、社内のキーマンたちへ物怖じせず片っ端からヒアリングを仕掛けました。

• 営業部長/案件担当マネージャー：案件情報が今どこにどういう形式で散らばっているかの現状把握
• AX事業部部長：LLM API等の社内リソース権限を誰が握っているかの特定
• 社内システムエンジニア： 社内で進んでいるプロジェクトの動向探り

「一エンジニアが突然こんなことを聞いて怪しまれないか？」といった躊躇は1ミリもありません。目的を達成するためなら、部署や役職の壁なんて関係なく、誰にでもフラットに飛び込めるのが私の強みです。

このゲリラ的なヒアリングのおかげで、案件データの散らばり具合や社内政治の状況がクリアになり、企画書は「現場のリアルに即した、即効性の高いもの」へと仕上がっていきました。

2. 執行役員へ直談判：驚異の「2分後レス」で1時間枠を奪取

外堀を埋め、大義名分とファクトを詰め込んだ企画の概要を携え、ターゲットである執行役員へ直接DMを送付しました。

結果、送信からわずか2分後に返信通知が鳴りました。

内容に強い興味を持っていただき、「明日、1時間枠を取るから直接話そう」と、翌日のミーティングを勝ち取ったのです。

ターゲット選定と事前の情報収集という戦略がハマった瞬間でした。

提案：技術論を捨て「費用対効果」に特化した15分

執行役員とのミーティング時間は1時間。そのうち、私がプレゼンに割いたのは冒頭の15分だけです。

ここで意識したのは、エンジニアが陥りがちな「このAI技術がいかに先進的か」という技術論を一切排除すること。

なぜなら、経営層（執行役員）の最大の関心事は技術の凄さではなく、「それで、いくら儲かるのか／コストが浮くのか」の1点に尽きるという強い仮説があったからです。

相手の立場と関心事に完全に照準を合わせ、15分間で「SESの構造課題」から「具体的なマネーインパクト」までを一気通貫でプレゼンしました。

1. 執行役員に提示した「定性・定量」の費用対効果

経営層に一発で納得してもらうため、感覚値ではなく、具体的なモデルケースを立ててシミュレーションを提示しました。

もちろん確定で細かく試算できたわけではないし、本当にその効果があるかは分からない状況ですが、うまくいったらこうですよ、という可能性の話として訴求しています。
訴求内容は下記のようになります。

• 定性面

  • 主体的なキャリア構築による在籍期間で最大化:
    • エンジニアが主体的にキャリアを選べる環境を整えることで、キャリア実現性向上・エンゲージメント向上が狙える
    • 結果として、ハイレベル人材の定着率を向上させ、1人あたりの在籍期間と総売上を最大化が期待できる
  • 共通言語による認識齟齬・作業工数の削減:
    • 案件情報の透明化により、エンジニア/マネージャー/営業が同じ情報をもとに会話できるようになる
    • 共通認識をそろえることで、事務的な情報収集・情報加工・情報授受・ドキュメンテーション・案件マッチング業務を削減できる
    • 結果として、マネージャー/営業は高付加価値業務へ集中でき、案件獲得や人材育成といった売上に直結する施策が打ちやすい土台が整う
  • 採用競争力の強化:
    • 案件情報の透明性や、エンジニアが主体的にキャリアを選択できる環境は、採用広報上の訴求材料になり得る
    • 特に、利用実績・参画事例・離職率の変化が蓄積されれば、他社との差別化要素として活用できる可能性が高まる
    • 結果として、現場型AX企業の地位確立に不可欠な人材確保に寄与できる

• 定量面

  • 在籍期間延長による売上向上：1人当たり500~1000万
    • 「単価×延長期間」がそのまま売上向上につながる
    • 年収500万・単価90万のエンジニア1名の退職を1年間延長できたとすると売上向上額は1080万、粗利は400万前後の向上になる
  • 採用・育成コストの削減：1人当たり250万~350万
    • 採用・育成コストは常に発生するものの離職率を低下させた結果として『人員補充』の採用を減らし、従来通りに『人員拡大』を行った場合、『人員補充』分のコストが削減される
    • 一般的にIT業界では年収の50～70%が採用・育成コストの目安と言われているため、年収500万のエンジニアを採用する際にかかるコストは250～350万かかる
    • 『人員補充』の採用を減らせば減らすだけ指数的に削減コストが増加する仕組み

端的に言えば、
「この仕組みでハイレベル人材の離職を数名食い止めるだけで、数千万規模のインパクトがダイレクトに会社に戻ってきます」
と言い切りました。

開発運用費用はどんだけでかくても年間500万とか行くわけないので効果ありますよって感じですね。

2. 明日から試せるPoCの費用感までセットで提示

さらに、提案を単なる理想論で終わらせないために、ファーストステップとなるPoCにかかる実装・運用のミニマムな費用感もその場で提示しました。

「大きな予算をいきなりドカンと使ってください」ではなく、「まずはこれだけの低コスト・短期間で効果を検証できます。リスクヘッジも含めて、まずはこのスモールステップで進めさせてください」という、ビジネスのセオリーに則った現実的な計画です。

経営層の脳内にシンクロし、「費用対効果は確実に出せます」と言い切ったこの提案。
手応えは十分。しかしここから、経営層ならではの「リアルな壁」が立ちはだかることになります。

結果：まあそうですよね

執行役員からのフィードバックは、非常に本質的、かつ経営層ならではの視点でした。

結論から言うと、「一気にアサインフローをオープンに入れ替えるのは、現時点では不可能」という判断でした。
理由は、技術的な問題ではなく、会社の「評価・給与制度の根幹」に関わるリスクでした。

現在のビジネスモデルでは、エンジニアに案件単価を公言していないから、この状態で案件情報を完全に透明化にすると、
『自分の単価が10万円上がったのに、なぜ給与は1万円しか上がらないんだ？』という、会社の原価構造や制度を無視した別の不満が爆発するリスクがある。

エンジニア主導のアサインを実現するには、まず評価制度や給与体系自体の抜本的な改革が必要で、それには他部署を巻き込んで1〜2年かけて制度設計を練る必要があり、システムだけで今すぐ解決できる話ではない

ってのが主な理由でした。

これを聞いたとき、私は「まあそうですよね！」と激しく納得しました。

現場の不満を解決しようとした提案が、経営視点で見ると「別の巨大なリスク」を引き起こすトリガーになり得る。
ただの理想論だけでは組織は動かせないという、至極当たり前な結果になってしまいました。

今後の展望：部署を巻き込んだ「公式プロジェクト」への昇華

元々プレゼンがすんなり通るとは思っておらず、残った時間は社内の課題感や今後の展望を聞く予定でした。
ところが、こちらから探りを入れるまでもなく、執行役員の口から驚くようなビジョンが次々と飛び出してきました。

詳細は伏せますがすでにいろいろやっている模様。
面白そうな構想を共有していただきました。

その壮大でエキサイティングなビジョンを聞いているうちに、「これは絶対に当事者として関わりたい！」という衝動が抑えきれなくなりました。

そこで、その場でストレートに「そのプロジェクト、私もメンバーとして参加させてください！」と志願してみました。

すると、執行役員からは「いいよ、ぜひやってよ！」と、まさかの快諾。

さらに嬉しいことに、今回私が持ってきた提案についても、現在進んでいる社内プロジェクトと合わせて実現できる可能性を模索していこう、という非常に前向きな反応をいただきました。

直球の提案自体は一度ストップがかかったものの、役員の懐に飛び込んでディスカッションした結果、「個人のゲリラ企画」が「会社公認で実行可能性を探る公式プロジェクト」へと大出世したのです。

おまけ：GraphRAGを使った案件検索基盤の概要

「エンジニアが自律的に案件を探せる検索基盤」を作るにあたり、私が裏で設計していたアーキテクチャの概要です。

SES企業における「案件情報」や「エンジニアのスキル・経歴」は、本質的に強固な関係性を持つデータです。
また、多くの現場ではそれらのデータが「Google スプレッドシート」などで管理されています。

このデータを単純に細切れにして通常のベクトルRAGに食わせると、スプシの行と列の関係性が壊れ、「どのスキルがどの案件と紐づいているか」という文脈が完全に喪失してしまいます。

そこで私は、スプシの構造を100%保持したままグラフ化する「BYOG（Bring Your Own Graph）型のGraphRAG」という構成を考案しました。

比較項目	通常のベクトルRAG（Vector RAG）	今回考案したGraphRAG（BYOGベース）
データの持ち方	文章を細切れ（チャンク）にしてベクトル空間にマッピングする。	スプシのデータをPythonで直接ノード・エッジ（網の目）化。関係性と要約をそのまま保持。
得意な検索	「Python, AWS, MLOps」といった、ピンポイントなキーワード類似度検索。	「Aというスキルを持つ人が、Bという案件を経て、Cというキャリアに至る」といった文脈・関係性の検索。
情報の統合・回答	検索時に上位の断片をかき集めてLLMにまとめさせるため、関係性が薄いと回答がブレる。	あらかじめ「コミュニティ要約」として関連情報が俯瞰的にまとまっているため、回答の精度が高い。
スプシデータの扱い	苦手。列の意味やデータの構造を喪失しやすい。	得意。スクリプトで直接DB化するため、構造を100%保持できる。
構築・更新コスト	非常に安い（Embeddingのみ）	やや高い（コミュニティ要約にLLMを使うため）

この技術選定に至った意思決定ロジック

今回の目的は、単に「キーワードが含まれる案件を引っ張ってくること」ではありません。
エンジニアが「自分の希望するキャリアに進むために、どの経験を積めばいいのか」を横断的に推論できることがゴールです。

「MLOps関連案件に共通する必須スキルと、現場での課題は何か？」
「Aさんの今のスキルセットから見て、次にステップアップするのに最適な案件はどれか？」

こうした、点と点を繋ぐような「横断的な文脈の検索」を行うには、データの関係性を殺さないGraphRAGがベストプラクティスであると判断しました。

GraphRAGの課題であったナレッジグラフ構築によるコスト増加も、コスト抑えつつ職種の包含関係を作って精度を向上させるオントロジーの作成でカバーできそうだと思っています。

最近MemvidなるGraphRAGに近しいことが軽量でできる技術も出たらしいので、それら踏まえつつこの基盤をベースに、さらにブラッシュアップしたシステムを形にしていきたいと考えています！

感想

企画から役員への直談判まで、わずか1週間。我ながらなかなかのスピード感で打席に立てたなと思っています。

今回動いてみて分かったのは、「自分の目の前にある課題」と「会社が掲げる全社ビジョン」をパズルのようにガッチャンコさせる感覚は、今後どんな場面でもかなり再現性高く使えそうだな、ということです。

正直、エンジニアになったはずなのに「営業やってた頃よりゴリゴリ営業してないか……？」と複雑な気分にもなりましたが。

でも、目的を達成するためなら四の五の言わず、自分の持っている過去のキャリアも技術も、使える武器は全部使ってやるだけ。そういう意味では、自分らしい泥臭くていい動きができたんじゃないかと思います。

これからも「技術」と「営業脳」をフル回転させて、会社も自分もおもしろくなるような価値提供を仕掛けていきたいです！精進します！