【初心者向け】初めてのSES（客先常駐）で失敗しない立ち回り完全ガイド

初めて客先常駐に参画する方はもちろん、すでに客先常駐をされている方でも、「この動き方で合っているのかな」「もっと評価される立ち回りがあるのでは」と不安になったり、緊張したりすることがあると思います。私自身も参画当初は、現場のルールや空気感が分からず、質問の仕方や報連相のタイミングで悩んだ経験があります。

客先常駐では、技術力と同じくらい「現場での立ち回り」が成果や信頼につながります。逆に言うと、ちょっとした行動のズレで誤解が生まれたり、進捗が見えにくくなったりして、必要以上に評価を下げてしまうこともあります。

そこで本記事では、私の経験を踏まえながら、客先で失敗しないための立ち回りを“完全ガイド”としてまとめました。参画初日からの動き方、コミュニケーションの取り方、報連相・質問・進捗共有のコツ、やりがちなNG例まで、明日からそのまま使える形で具体的に解説していきます。緊張や不安を少しでも減らし、自信を持って現場で動けるようになる内容を目指しましたので、ぜひ最後までご覧ください。

参画初日～1週間の動き方（環境構築・あいさつ・仕様理解）

客先常駐の立ち上がりで一番大切なのは、**「仕様を理解するための土台を最速で作ること」**です。環境構築やあいさつももちろん重要ですが、ここで仕様理解を疎かにすると、その後の作業スピードも品質も一気に落ちます。逆に言えば、最初の1週間で仕様理解の導線を押さえられると、現場での信頼が一気に積み上がります。

1日目：まずは“動ける状態”を作る（環境構築）

初日は、成果を出すというより**「明日から自走できる状態にする」**ことを最優先にします。

• アカウント発行、VPN、社内ツール（チケット、Git、チャット、勤怠）へのアクセス確認
• ローカル環境構築（ビルド・起動・デバッグができるか）
• 開発端末、権限、ネットワーク制限などの詰まりポイントを洗い出す
• つまずいた点は、必ずメモして「何ができないのか」を言語化して相談する

ここで大事なのは、詰まったときに「できません」だけで終わらせず、どこまでできて、どこからできないのかをセットで伝えることです。これだけで印象が変わります。

1日目：あいさつは“安心材料”を渡す

初日のあいさつは、気合いよりも**「この人はやり取りしやすい」**と思ってもらうのが目的です。

• 自己紹介（所属・担当予定・得意分野・経験年数は簡潔でOK）
• 「分からない点は早めに相談します」「進捗はこまめに共有します」など、姿勢を一言添える
• 連絡手段（チャットが良いのか、会話が良いのか）を確認する

最初に“コミュニケーション方針”を置いておくと、相手も接しやすくなります。

参画初日～1週間で最重要：仕様の理解が本当に大事です

私の経験上、客先常駐でつまずく原因の多くは「技術不足」ではなく、仕様を曖昧なまま進めてしまうことでした。
仕様理解が浅いと、次のような事故が起きやすくなります。

• 手戻りが増える
• 進捗が遅く見える
• 認識ズレが原因で信頼が落ちる
• 「聞いてない」「言ってない」が頻発する

だからこそ、最初の1週間は“仕様理解の仕組み”を作る期間だと割り切るのが大事です。

仕様の説明がない現場もあります

意外かもしれませんが、現場によっては口頭での仕様説明がほとんどないことがあります。
その代わりに、新規参画者向けに以下のような情報がまとまっているケースがあります。

• 新規参画者向け資料（読み物、全体像、用語集、画面一覧など）
• 課題・チュートリアル（環境構築後にやる小さなタスク集）
• 過去のチケット・WBS・障害一覧（実質これが仕様書になっている現場もあります）

ここで大切なのは、「説明がない＝放置」ではなく、「資料とログを読め」という文化の可能性が高いと理解しておくことです。

仕様説明がない現場で大事なこと

仕様説明がない場合、受け身で待っていると本当に詰みます。
私が強く意識していたのは、次の3点です。

① 仕様の“正解の置き場所”を最初に確認する

• 仕様書はどこか（Confluence/SharePoint/Box/社内Wikiなど）
• 画面定義・API定義・DB定義はどこか
• 変更履歴はどこで追うのか（チケット？差分？）
• 最終的に判断に迷ったら誰に聞けばよいか

これが分かるだけで、作業の迷いが減ります。

② WBSで降りた作業は、着手前に“仕様確認の質問”をセットにする

仕様説明がない現場ほど、WBSの文言がふわっとしていることがあります。
そのまま着手すると高確率で手戻りになります。

• 目的（何のための対応か）
• 完了条件、期待するアウトプット
• 影響範囲（画面、API、バッチ、DBなど）
• 参考チケットや過去事例の有無

これを最初に短く確認するだけで、事故率が下がります。

③ 自分用の“仕様ノート”を作る

資料があっても散らばっていることが多いので、
自分が理解した仕様を1ページにまとめておくと強いです。

• 前提、用語、画面遷移、データの流れ
• よく出る例外パターン
• 「この仕様は誰が決めるのか（担当/承認者）」

後で別プロジェクトに回されたときにも効いてきます。

大企業の現場で起きがちなこと：別プロジェクトへ参画するケースがあります

大きい企業へ参画すると、同じエンドユーザー様の中で別プロジェクトへ移動・兼務することがあります。
その際に、仕様の説明がないまま、いきなりWBSで仕事が降ってくることもあります。

このパターンは特に危険です。理由は、**「前提知識がある人向けに進んでいる」**ことが多く、
新規参画者が置いていかれやすいからです。

そのため、WBSが降りたらまず次を確認するのが安全です。

• このタスクは、どの業務フローのどこに位置するのか
• 関連する仕様書・画面・API・DBはどれか
• 過去に同じような改修をしたチケットはあるか
• 影響範囲の確認は誰が責任を持つのか

「まずこれだけ教えてください」と言えるテンプレを持っておくと、現場でも戦えます。

「設計書作成・プログラミング・テスト」でAIは使うべき？

客先常駐で AIの使用ルールを最初に確認するのはとても重要です。理由はシンプルで、ユーザ企業側で「社内向けAIツール（独自ChatGPTや社内LLM、許可済みの生成AI環境）」が用意されていることもあれば、逆に「外部AIは原則禁止」「入力データに制限あり」など、ルールが厳格な現場もあるからです。ルール確認を怠ると、悪意がなくても情報漏えい扱いになり得ます。

結論は **「使うかどうか」ではなく「何を、どこまで、どのツールで」**をルールに合わせるのが正解です。よくある整理は下記になります。

設計書作成でのAI利用

• 使いやすい場面
  • 章立てのたたき台、観点の洗い出し、レビュー観点の列挙、文章の整形
• 注意点
  • 仕様や画面情報を入れるとアウトになりやすい（機密度が高い）
  • 事実と推測が混ざりやすいので、必ず人間が検証する

プログラミングでのAI利用

• 使いやすい場面
  • ボイラープレート、リファクタ案、関数の分割案、テストコードの雛形
• 注意点
  • ソースそのものを外部AIに貼るのが禁止の現場は多い
  • 生成コードは品質が保証されないので、レビューと動作確認が必須

テストでのAI利用

• 使いやすい場面
  • テスト観点の網羅、境界値・異常系の洗い出し、テストケースのテンプレ化
• 注意点
  • 実データ、ログ、障害チケットを入力すると危険（情報分類的にアウトになりやすい）
  • 「抜け漏れがない」と盲信しない（AIは抜けます）