SES面談の準備：スキルシートの担当範囲を技術質問で確かめる

SES面談の準備では、提出したスキルシートの一文を、担当した作業、判断の理由、確認した結果まで説明できる状態にします。「Java経験あり」だけで終えず、案件で求められる仕事と、自分が根拠を示せる仕事がどこで重なるかを確かめてください。

この記事は、SES企業に所属するエンジニアと参画先との案件面談を想定します。SES企業に入社するための採用面接とは目的を分けます。案内の名称だけでは判断せず、誰が何を確認する場なのか、所属会社の担当者に確認しましょう。

最初の練習には、PracHubの要件の曖昧さを確認する質問を使えます。技術質問を使い、案件票で求められる作業を自分がどこまで担当できるか確かめます。

案件面談と採用面接を、準備の入口で分ける

案件面談では、参画予定の仕事と、自分が提供できる経験や条件を照合します。ただし、面談の参加者、確認事項、進め方は案件ごとに確認が必要です。「面談だから技術の確認はない」と決めつけないでください。

事業者が公開している説明： Fairgritのコラムは、参画前に案件内容やスキルを確認する場としてSES面談を紹介しています。これは同サイトの業界向け説明であり、すべての案件の実施方法や契約上の扱いを定める規則ではありません。FairgritのSES面談の説明

本文で示す回答例とコードは、独自に作成した架空の練習です。候補者が実際の案件面談で受けた質問の報告ではありません。参画の可否、評価基準、契約の適法性を、この練習から推測することもできません。

所属会社の採用面接なら、志望理由や入社後のキャリアについて求められる説明も変わります。両方の準備が必要な場合でも、「所属先に入る判断」と「特定の案件を担当する判断」を一枚の回答に混ぜず、相手と目的を先に書き出します。

提出済みの版と、案件票の具体的な作業を照合する

最初に、自分の手元の最新版ではなく、相手へ提出されたスキルシートの版を確認します。営業担当者が整えた表現や、過去の版に残った工程名が、現在の説明と一致しているかを見てください。記載が実際の担当より広ければ、面談で取り繕う前に訂正を相談します。

公開されている準備の助言： MeGlio Futuroの2026年10月7日更新記事も、提出した版の確認、必須条件と経験の照合、本人の判断範囲の整理を扱っています。同記事の回答は架空の例と明記されており、候補者の体験談として扱いません。同社のSES面談の準備記事

案件票の「Java」「設計」「テスト」は、まだ作業の単位になっていません。既存APIの条件追加なのか、新しいAPIの設計なのか、障害調査なのかを読み分けます。「設計経験が必要」とだけあれば、画面、API、データモデル、システム構成のどれを想定しているかが確認事項になります。

以下は架空の案件票です。Java 17の既存サービスを改修し、送料計算の条件追加と単体テストを担当する想定です。周辺はSpringベースのAPIですが、本稿の実行対象は送料関数だけで、Springの起動やHTTP応答は検証していません。

最後の行を記載できるかは、この練習ではなく自分の実務経験で判断します。Java関数を書けることと、Spring APIの保守経験があることは別の主張です。経験がなければ、学習した範囲と未経験の作業を分けます。

「担当しました」を、本人の作業と判断に分解する

担当範囲とは、参加していた工程の名前ではなく、自分が実施した作業、判断した内容、レビューや承認を受けた境界です。チームが要件定義から運用まで担当していても、本人が全工程を担当したとは限りません。

例えば「送料機能の設計・開発・テストを担当」と書くと、新しい料金体系を決めたのか、既存の計算方法を修正したのかが分かりません。架空例なら、「確定した料金条件をもとに送料関数を修正し、境界値の単体テストを追加。料金条件の決定とリリース承認は責任者が担当」と限定できます。

レビューを受けたことは隠す情報ではありません。「条件の抜けを自分で調べた」「仕様の解釈は責任者と確認した」「実装案はレビューで修正した」を分ければ、どこまで任せられるかを判断する材料になります。共同作業をすべて自分の成果にする必要はありません。

逆に、指示どおりに変更しただけの部分へ、後から設計意図を付け足さないでください。当時は判断していなかったことを今なら説明できる場合は、当時の担当と現在の理解を分けて話します。学び直しは説明できますが、過去の責任範囲は書き換えません。

独自の送料仕様から、修正前の不具合を見つける

ここからは、実務の証拠の組み立て方を試す独自演習です。実際の顧客案件や採用課題ではありません。金額は円とし、商品金額は0以上の整数、通常送料は500円、商品金額5,000円以上では通常送料を0円、離島向けは金額にかかわらず800円を加算すると決めます。負の金額は拒否します。

この仕様では「送料無料」の意味が重要です。無料になるのは通常送料であり、離島向け加算まで無料になるとは決めていません。実務でこの点が不明なら、コードを先に直すのではなく、条件を決める人へ確認します。

修正前の関数は次のとおりです。

static int shippingFee(int amount, boolean remote) {
    if (amount < 0) throw new IllegalArgumentException("negative amount");
    if (amount >= 5000) return 0;
    return 500 + (remote ? 800 : 0);
}

言語仕様の事実： Javaのreturn文は呼び出し元へ制御を戻します。この関数では、その後の送料加算を実行しません。Java SE 17言語仕様のreturn文

商品金額4,999円、通常配送なら500円です。5,000円、通常配送なら0円で、ここまでは仕様に合います。しかし5,000円、離島向けでも先に0を返すため、必要な800円の加算へ到達しません。

技術質問への答えは「if文が間違っています」だけでは足りません。5,000円かつ離島向けという入力が早期returnを通り、800円の加算を落とすことを説明します。この例では、金額の条件を満たした時点の早期returnが、独立して適用する加算を飛ばしています。

差分と境界テストで、修正の理由を説明する

修正では、通常送料と離島向け加算を別に計算します。条件の順番を入れ替えるだけでなく、仕様の二つの要素がコードでも見える形にします。

- if (amount >= 5000) return 0;
- return 500 + (remote ? 800 : 0);
+ int base = amount >= 5000 ? 0 : 500;
+ return base + (remote ? 800 : 0);

負の入力を拒否する行は残します。5,000円以上なら通常送料0円、それ以外なら500円を求め、その後で離島向けの800円を加えます。この仕様では通常送料を計算してから加算することで、無料条件が加算条件を消してしまう構造を避けられます。

ローカルで確認した結果： OpenJDK 17.0.20.1で独自コードをコンパイルして実行しました。上の6入力と、負の金額を配送先別に拒否する2入力を確認し、修正後は8件すべて期待どおりでした。修正前は上表の最後の入力で不一致を再現しています。

これはJavaの関数と固定入力の検証です。APIの入力変換、DBの保存、並行処理、配送先の判定、実際の請求まで正しいと示したものではありません。テストを説明するときも、通った件数と確認できた範囲を一緒に伝えます。

追加質問には、用意した根拠の範囲で答える

次のやり取りも架空の練習です。「送料機能を担当した」と話した後、相手が何を確かめようとしているかを考えます。回答を丸暗記するより、コードと仕様へ戻れるかを試してください。

「なぜ5,000円をテストしましたか」には、無料になる境界だからと答え、その直前の4,999円も確認した理由を添えます。「離島も無料ではないのですか」には、この演習の確定仕様では通常送料だけが無料になると説明します。現場の仕様が違えば、期待値も実装も変わります。

「例外が出ることを確認しただけですか」と聞かれたら、負の入力の拒否は確認したが、呼び出し側が例外をHTTP応答へ変換する動作は未検証だと答えます。関数のテストを、画面やAPIまで含む結合テストとして説明しないでください。

「あなたが料金条件を決めましたか」には、練習では仕様が与えられていると答えます。実務の説明なら、誰が条件を決め、自分は何を確認して実装へ反映したかを話します。採用されそうな物語を作るために、判断者を自分へ置き換えません。

さらに「新しい配送区分を追加したら」と聞かれた場合、まず料金の組み合わせと優先順位を確認します。boolean一つで表現できる区分のままなのか、複数の料金種別が必要なのかは、新仕様次第です。まだ存在しない要件へ、完成した設計があるように答える必要はありません。

守秘情報を出さずに、実務と練習を区別する

コードを見せること自体が必須とは限りません。共有が認められない資料は持ち出さず、公開してよい概要、条件を一般化した図、独自に作成した再現例で説明できるかを確認します。顧客名を消すだけで、公開の許可を得たことにはなりません。

独自例を使う場合は、「実務で経験した問題の考え方を説明するため、新しく作った例です」と明示します。ただし、この送料演習を読んだだけなら「学習で試した例」です。実務で同じ問題を解決したという経歴にはできません。

提出物の版もそろえます。スキルシートでは単体テストのみなのに、口頭で結合テストも担当したと広げたり、後から追加した処理を当時の成果として説明したりすると、根拠が一致しなくなります。当時の実績と現在の技術理解を分けて準備してください。

作品を実際に操作しながら見せる準備は、既存のプログラマー面接で作品を説明する記事で扱っています。本稿では案件の要求と担当範囲の照合を中心にし、作品の見栄えやデモの順番を主題にしません。

五つの技術質問で、スキルシートの一文を確かめる

以下は担当範囲を説明するための補助練習です。日本のSES案件で必ず出る質問や、特定の参画先の評価基準ではありません。英語の題名を持つPracHubの問題ですが、回答は自分が実際に担当した作業へ結び付けて練習できます。

答えられない質問が見つかったら、スキルシート全体を弱く書き直すのではなく、該当する主張の範囲を見直します。実務では使っていない仕組みを、学習したから実務経験ありとする必要はありません。次に調べる内容と、現時点で任せてもらえる作業を分けます。

面談の最後は、任される仕事と支援の条件を確認する

準備した回答に加え、実際に任される仕事と支援体制も確認します。最初に担当する変更の規模、仕様の確認先、コードや設計のレビュー担当、テストとリリースの責任を確かめます。「サポートあり」という説明も、誰へ、いつ、どの資料で相談できるかまで具体化すると判断しやすくなります。

開始時期や出社条件は、希望と確定事項を分けて伝えます。その場で確約できない条件は、所属会社の担当者と確認して回答することを伝えます。技術の理解があることと、契約や勤務条件を自分だけで確定できることは別です。

面談後は、説明できた担当、追加で確認すると約束した点、案件側から新しく示された要求を記録します。食い違いがあれば、提出版と説明を整えて関係者へ確認してください。面談を通過したかどうかだけで、自分の説明の精度を判断しないことも大切です。

最後に、Javaの単体テストを修正するPracHubの演習を一つ解き、原因、変更、確認範囲を声に出して説明してみましょう。説明した作業がスキルシートの一文と一致するかを確かめ、広すぎる記載があれば提出担当者へ修正を相談してください。

Sources and Further Reading

• Fairgrit：SES面談の位置付けと質問例。事業者による業界向け説明

• MeGlio Futuro：SES面談の質問・担当範囲・提出版の確認。2026年10月7日更新

• Oracle：Java SE 17言語仕様、return文による制御の移動

資料確認日：2026年10月11日。本文の案件票、料金仕様、コード、回答例は独自の架空演習です。実際の担当経験へ置き換える際は、確認できる事実だけを使ってください。