技術面接に向けて過去のプロジェクトを振り返る

先に結論

技術面接の準備では、応募する仕事に近い案件と、難しい問題に対応した案件を選び、目的・担当・制約・判断・検証・結果を整理します。チームの方針と本人の行動、当時の事実と後からの振り返りを分けて説明してください。

• 概要を短く話し、質問に合わせて技術的な詳細を補う。

• 選んだ案の理由と弱点、検証していない条件を整理する。

• 知らない点は範囲を示し、仮定と実際の経験を混ぜない。

対象：過去の開発・保守・運用経験について話す技術面接を準備する人。API改修などは架空例です。コーディング試験対策の網羅や、採用結果の保証は行いません。資料・ツールの利用は企業の案内に従ってください。

技術面接では、結論だけでなく判断した過程を説明する

過去の開発経験を聞かれたときは、使った技術と完成した機能だけでなく、どんな状況で何を判断したかを説明できるようにします。応募先が知りたいことは職種によって異なりますが、本人の担当、考えた選択肢、確かめた結果が分かれば、経験について対話を進めやすくなります。専門用語を増やす前に、仕事の流れを整理しましょう。

ハローワークの応募書類資料は、職務経歴書に基づく質問を想定し、完成した書類を面接前に確認することを案内しています。エンジニアの面接でも、まず提出した版を読み、どの案件と担当範囲を書いたかを確かめる準備が役立ちます。本文で提案する振り返りの枠や練習方法は編集上の提案で、特定企業の採点基準を示すものではありません。 （出典：厚生労働省・ハローワーク｜応募書類の作り方（面接を想定した準備：13ページ））

準備では、相手が聞きそうな質問への完璧な回答集を作ろうとするより、自分が説明できる事実を揃えます。話しやすい一つの案件から始め、目的、制約、担当、判断、検証、結果を短いメモにします。記憶が曖昧な部分を見つけたら、言い切れる範囲へ戻します。分からない数字や担当していない作業を、話のつながりのために補わないでください。

この記事は、過去のプロジェクトについて話す面接の準備を主に扱います。コーディング試験や設計課題の対策を網羅するものではありません。後半のAPI改修と障害対応の例は架空です。面接の形式や資料・ツールの利用条件は企業ごとに違うため、案内を確認したうえで、自分の経験に合う練習を選んでください。

話す案件は、応募業務との接点から二つ選ぶ

すべての案件を同じ詳しさで準備すると、時間が足りなくなりがちです。まず応募する仕事に近い案件と、難しい状況に対応した案件を一つずつ選びます。同じ案件が両方を満たす場合もありますが、別の場面も用意すると、質問に応じて話題を変えられます。規模の大きさより、自分の担当と判断を具体的に話せるかを基準にしてください。

応募先が運用改善を求めているなら、監視や不具合調査、手順の見直しが関係するかもしれません。新機能の開発なら、要求の整理、設計、実装、検証のつながりを話せる案件が候補になります。求人の単語と同じ技術を使った経験だけに絞らず、仕事の進め方の接点も考えます。違う技術を使った場合は、その違いも含めて説明しましょう。

選んだ案件ごとに、何を中心に話すかを決めます。仕様の曖昧さを整理したこと、制約の中で案を比較したこと、失敗から確認方法を変えたことなどです。一つの話で全部の長所を伝えようとすると長くなります。中心となる問いが決まれば、背景として必要な情報と、聞かれてから補う細部を分けられます。

古い案件しかない場合も、無理に最近の成功談を作る必要はありません。いつの経験で、今はどこまで記憶しているかを整理します。当時の技術や体制を現在の常識だけで評価し直さず、そのとき使えた情報と条件を説明してください。現在なら変えることは、当時の事実と分けて振り返りとして話せます。

最初の説明は、目的・規模・担当を短く揃える

案件の導入では、システムを使う人と目的、当時の変更や問題、自分の担当を先に示します。会社や製品の歴史を長く説明すると、面接官が技術的な問いへ進みにくくなります。背景は、その後の判断を理解するのに必要な範囲へ絞ります。固有名詞がなくても、用途や制約を一般化すれば具体的な仕事は説明できます。

架空の導入例なら、「業務用の予約システムで、予約変更APIの改修を担当しました。既存利用者の操作を保ちながら入力の誤りを減らすことが目的で、私は仕様確認、実装、結合テストを担当しました」と話せます。ここでは全体設計を主導したとは述べていません。本人の担当が先に分かると、その後の質問も実際の経験に近づきます。

規模を説明する際は、チーム全体と自分が日常的に協働した範囲を分けます。人数や利用量は、開示できて根拠があるものだけを使います。正確な数が分からなければ、無理に作らず、判断に必要な関係だけを説明します。「複数チームが同じAPIを利用していたため、変更の影響を確認した」のように、数値以外でも制約を伝えられます。

概要を話したら一度区切り、どこを詳しく聞きたいかが分かる余地を作ります。面接は用意した原稿を最後まで読む場面ばかりではありません。「主に実装時の判断と、検証方法について説明できます」と話題を示す方法もあります。相手の質問に合わせて深さを変えられるよう、概要と詳細を別に練習しておくと役立ちます。

チームの方針と、自分が決めたことを切り分ける

過去の仕事を話すとき、「私たちは」という主語だけでは、本人が何をしたかが曖昧になります。チームで決めた方針、自分が提案した案、自分で実装した部分、レビューを受けて直した部分を分けてください。全体の成果を説明しつつ、その中での担当が分かるようにすると、協働の経験と本人の能力の両方を伝えられます。

技術選定を上位の担当者が行ったなら、その前提を説明したうえで、自分が選べた範囲を話します。既存の構成の中でも、入力の扱い、テストの観点、調査の順序、関係者への確認など、本人が判断した場面はあるはずです。大きな決定をしていないことを隠すより、担当した小さな判断を正確に話す方が、追加質問にも対応しやすくなります。

レビューで指摘された点は、本人の成長を説明する材料にもなります。「最初はこの実装にしたが、例外時の動作を指摘され、条件を追加して確認した」と話せば、何を学びどう修正したかが伝わります。初案から正しかったように作り替える必要はありません。指摘の内容を理解して修正した部分と、教わったまま対応した部分も区別して振り返ります。

「自分がいなかったらどうなったか」という問いを使うと、担当の具体性を点検できます。ただし、自分の貢献を大きく主張するための仮定として使うのではありません。何の情報を集め、どの作業を進め、誰が次の判断をできるようになったかを整理します。チームの成功を独占せず、本人の行動が見える説明を目指してください。

設計を説明するときは、選択肢と制約を先に示す

設計判断の説明は、採用した技術の一般的な長所を話すだけでは不十分です。扱うデータ、利用者の操作、既存環境、納期、保守する人など、今回の判断を左右した条件を選びます。その条件の下で何を比較し、どの利点を優先したかを述べると、なぜその選択になったかを聞き手が追えるようになります。

比較した案があるなら、それぞれが満たしやすい条件と、追加で必要になる作業を整理します。例えば、処理を一括で行う案と、範囲を区切って行う案では、実装の単純さや失敗時の再実行の扱いが異なるかもしれません。架空例を一般的な正解として話さず、自分の案件で実際に比較した観点へ置き換えてください。

実際には一案しか検討していなかった場合は、その事実を隠さなくて構いません。既存の方針があったのか、時間や権限の制約があったのかを説明できます。面接準備で別案を考えたなら、「当時は検討していませんでしたが、今振り返ると」と時点を区別します。制作当時から広く比較したように話を整える必要はありません。

採用案の弱点も用意しておきます。どんな条件で困るか、どの制約が残ったか、何が変われば見直すかを考えます。自分の案を守るために欠点を否定するより、判断の適用範囲を説明できる方が対話を進めやすくなります。設計の優劣を一言で断定せず、条件が変わったときに何を再確認するかまで話せると準備が深まります。

障害対応は、観測した事実と仮説を時系列で分ける

障害や不具合の説明では、後から分かった原因を最初から知っていたように話さないことが大切です。最初に見えた現象、調べた情報、考えた原因、確認して分かったことを順に並べます。原因の名前だけを言うより、限られた情報の中でどう調べたかが伝わります。利用者への影響と、自分の担当範囲も先に説明してください。

架空例として、APIの応答が遅くなった通知を受け、対象の操作、発生時間、直前の変更を確認したとします。そこでデータベース処理に原因があるという仮説を立てても、まだ確定ではありません。関連ログや検証の結果から何を支持できたか、どの可能性を外したかを分けます。事実と推測を混ぜると、調査の順序が分からなくなります。

復旧を優先した判断と、原因を詳しく調べる判断も分けます。いったん変更を戻した後で検証を続けたなら、その順序と判断者を説明します。自分が復旧操作を決めたのか、情報を集めて責任者へ共有したのかも区別してください。現場の実際の手順がある場合は、その枠の中で自分が何を担当したかを示します。

最後に、同じ問題へどう備えたかを整理します。監視の追加、手順の修正、テストの追加、連絡経路の見直しなど、実際に行ったことを挙げます。「再発しなくなった」と話すなら、確認した期間や対象を説明できる必要があります。観測できていない期間まで効果を広げず、対応済みの範囲と残る課題を区別しましょう。

架空のAPI遅延対応を整理するための質問例

検証の説明では、何を確かめて何を残したかを話す

実装できたことと、目的どおり動くことを確認できたことは別です。変更後にどんなデータや環境で、どの操作を試し、期待した状態とどう比べたかを整理します。正常な入力だけでなく、境界、失敗、再操作など、今回の変更で問題になりそうな条件をどう選んだかが説明候補になります。テストの件数だけでは、確認した範囲は伝わりません。

自動テストと手動の確認がある場合は、それぞれの役割を話せるようにします。入力条件の確認を自動化し、実際の画面で案内文を確かめたなら、その違いを説明します。ツールを導入したという事実より、何が壊れたときに気づけるようにしたかを述べると、検証の目的が伝わります。既存のテストを実行しただけなら、その担当範囲も正確に示してください。

性能の結果を使う場合は、指標と条件を確認します。平均、最大、ある一回の測定を混同せず、対象の処理と環境を説明します。検証環境で改善したことを、利用者全体の体験が同じ割合で改善したようには話しません。数字を覚えていなければ、正確な値は不明と伝えたうえで、何を測定し、結果をどう判断したかを説明できます。

確かめていない条件を聞かれたら、その場で検証済みと答えないでください。今回の範囲では対象外だったのか、必要性を見落としていたのかを振り返ります。今から確認するならどんな方法を使うかを考えることはできますが、実施済みの結果とは分けます。未検証の範囲を把握していることも、自分の仕事を正確に説明するための一部です。

うまくいかなかった経験は、影響と行動と学びを整理する

失敗の話では、何が起きたかを曖昧にして良い面だけへ急ぐと、実際にどう対応したかが伝わりません。予定から遅れた、確認が足りなかった、認識が合わなかったなど、起きたことを具体的にします。そのうえで影響を誰へ伝え、どう対応し、次の作業で何を変えたかを説明します。自分の責任と他の要因を落ち着いて分けてください。

例えば、仕様の確認が遅れて実装のやり直しが発生した架空例なら、最初に何を決まったものと考え、どの時点で違いに気づいたかを振り返ります。その後に、関係者へ論点を示して確認した、影響する作業を分けて日程を見直した、といった行動を整理します。単に「次から注意する」より、確認の位置や手順をどう変えたかが具体的です。

原因を他の人の能力や性格にまとめないようにします。情報が届かなかった、承認者が不明だった、前提を共有していなかったなど、仕事の進め方として説明できる点を探します。自分だけですべて解決した話にする必要もありません。支援を求めた相手と、その支援で何が進んだかを示せば、協働の中での対応が伝わります。

同じ問題を完全に防げるようになったと断定するより、変更した手順と、その後に確認できた範囲を話します。まだ改善中なら、何を試しているかを説明します。失敗の経験は、面接で有利な物語へ加工するものではなく、自分がどう不確実さを減らすようになったかを振り返る材料として扱いましょう。

分からない問いには、前提を確認して考える範囲を示す

面接で知らない技術や、経験のない条件を聞かれることは考えられます。答えを知っているふりをせず、どこまで経験があるかを伝えます。「その規模での運用経験はありませんが、まず確認する条件は説明できます」というように、経験した事実と仮の検討を分ければ、話を続けられます。推測が含まれる箇所は、その旨を示してください。

質問の前提が曖昧な場合は、利用者、データ量、必要な性能、既存の構成など、答えを左右する条件を確認します。何でも質問し返せばよいのではなく、自分がなぜその条件を知る必要があるかを短く伝えます。十分な情報がないまま答える場合は、仮定を置いてから検討すると、後で前提が変わっても話を修正しやすくなります。

考える時間が必要なら、一度整理したいと伝えます。沈黙を埋めるために技術名を並べるより、どの観点で検討するかを示す方が会話になります。仮説を述べた後に不足へ気づいたら、途中で修正して構いません。準備した回答と違う方向へ質問が進んでも、事実、仮定、未確認を分ける習慣があれば対応しやすくなります。

答えられなかった問いは、面接後に自分の学習課題として整理できます。ただし、面接中に外部ツールで調べてよいかは、その場のルールによります。資料、検索、生成AIなどの利用が認められているかを事前に確認し、案内に従ってください。使っていないように見せながら回答を作ることは、本人の経験を正しく伝える目的にも合いません。

図を使うなら、一つの操作が通る流れを描く

構成図を使って話すときは、最初からすべての要素を描かず、説明する操作に関係する部分を選びます。利用者、画面、処理、保存先を置き、入力がどう流れ結果がどう返るかを示します。その後に、今回変更した場所、問題が起きた場所、自分の担当を加えると、聞き手は全体の中での話題を理解しやすくなります。

矢印には、必要に応じて何が渡るかを短く書きます。単に箱同士がつながっているだけでは、同期的に待つのか、後で処理するのか、どこで失敗を検知するのかが分からない場合があります。今回の説明に必要な点だけ補い、図を完全な設計書にしようとしないでください。質問に応じて細部を足せる余地を残します。

画面共有やホワイトボードを使う場合は、面接案内の方法で操作できるかを確認します。文字が小さすぎないか、描きながら話せるかも練習できます。図が使えない形式なら、処理の順序を短い番号で説明するなど、言葉で伝える方法も用意しておきます。道具が使えることと、内容を伝えられることは分けて準備しましょう。

勤務先の図や管理画面をそのまま使わず、公開できる内容だけで説明用に作ることも検討します。情報を一般化しても、データの流れと判断は説明できます。実際と違う構成へ変えた場合は、説明のために簡略化したと伝えてください。開示してよいか分からない箇所を、質問されたからという理由だけで見せないようにします。

練習は、概要から質問に合わせて深める会話にする

最初の練習では、代表案件を短く説明して録音やメモで振り返ります。自分の端末で練習する場合も、記録に非公開情報を含めないようにします。背景が長すぎる、担当範囲が後まで出てこない、結果と仮説が混ざるなど、聞き手が迷いそうな箇所を探します。話す速度だけを上げて短くするより、情報の順序を見直すことが先です。

次は、一つの質問を追加して深めます。「その案を選んだ理由は」「別の方法は」「どこまで検証したか」といった問いから始めます。答えを暗記するためではなく、事実が不足している箇所を見つけるための練習です。説明できない部分があれば、言葉を飾る前に、記憶している範囲と確認できない範囲を分け直します。

他の人に練習を手伝ってもらうなら、評価点だけでなく、聞き取れた担当と残った疑問を教えてもらいます。技術に詳しくない人には背景の分かりやすさを、詳しい人には判断の前提を見てもらう方法があります。相手へ社内資料を渡さず、開示できる内容に整えた説明で練習してください。もらった指摘をすべて採用する必要はありません。

短い説明と詳しい説明を分けて用意すると、面接時間に合わせやすくなります。最初は概要と中心の判断だけを話し、質問が出たら検証や別案へ進みます。途中で話題が変わったら、用意した結論まで無理に戻さず、問いに答えます。自分の経験を決まった順序で再生することより、相手が知りたい範囲を正確に説明することを目指します。

自分からの質問は、振り返った経験と結び付ける

過去の経験を整理すると、応募先で確かめたいことも見つかります。レビューで学んだ経験があるなら、応募先のレビューの進め方を聞けます。障害対応で役割の曖昧さに困ったなら、緊急時の担当と判断者を質問できます。一般的な質問を大量に用意するより、自分がどんな仕事をしたいかに関わる問いを選びましょう。

質問では、現職の運用が唯一の正解だと決め付けないようにします。「コードレビューは当然この方法ですよね」と聞くより、「変更を取り込む前に、どのような確認をしていますか」と尋ねます。応募先の制約や体制が分かれば、自分の経験が活かせる点と、学ぶ必要がある点を考えられます。違いを見つけることと、優劣を決めることを分けてください。

制度について人事担当者が答え、実際の業務について現場が答えるなど、窓口によって分かる範囲が違う場合があります。その場で分からない質問は、後で確認できるかを相談します。返答が抽象的だったら、最近の例を一つ聞いてみましょう。具体的な運用が分かると、入社後に自分がどう参加するかを想像しやすくなります。

面接中に得た情報は、後で応募条件の比較へ戻します。魅力を感じた技術だけでなく、最初に任される役割、支援の相手、改善へ使える時間などを記録します。説明の練習で自分の経験を見直した結果、希望する仕事が変わることもあります。その変化を無視せず、次の応募や質問を調整する材料にしてください。

面接前日の確認と、面接後の振り返りを小さく分ける

前日には、提出書類、説明する案件、公開できる範囲、当日の形式を確認します。直前に新しい技術を広く覚えようとするより、既に書いた内容を矛盾なく説明できるかを見ます。オンラインなら接続、音声、共有する画面を確認し、対面なら場所と必要な持ち物を確認します。案内にない資料を使いたい場合は、利用してよいかを確認してください。

手元のメモは、長い模範回答より、目的、担当、制約、判断、検証、残る課題の見出しが使いやすい場合があります。見ることが認められている場合も、読み上げ続けないようにします。面接官の問いを聞き、何を答えるかを短く確認してから話すと、準備した内容と実際の質問のずれを小さくできます。

面接後は、聞かれたこと、説明が詰まったこと、得た情報を分けてメモします。面接官の反応を勝手に点数へ変えたり、結果を一つの回答だけのせいにしたりする必要はありません。自分で改善できる点を一つ選び、次の説明へ反映します。確認できなかった重要な条件があれば、適切な窓口へ追加で質問する準備をします。

振り返りの目的は、面接のたびに別の人物像を作ることではありません。事実をより短く明確に伝え、自分にも分からなかった判断や課題を整理することです。下の表に沿って代表案件を一枚にまとめれば、次の面接だけでなく、職務経歴書の見直しや、今後どの経験を増やしたいかを考える材料にもなります。

代表案件を一枚にまとめる振り返りメモ

比較するときの確認項目

• 概要を短く説明できる案件を選んだか

• 自分の担当とチームの判断を分けたか

• 代替案と見送った理由を説明できるか

• 面接形式と公開できる情報の範囲を確認したか

次に進めること

一つの案件を五分で説明し、説明が詰まった箇所をメモしましょう。専門用語を足す前に、その判断が必要になった背景を一文で補うと話の流れが整います。

参照先

• 厚生労働省・ハローワーク｜応募書類の作り方（面接を想定した準備：13ページ）

あわせて読む

• 職務経歴書に開発経験を書くときの整理方法

• ポートフォリオで伝えたい設計判断と改善の過程

• 内定後、入社前に確認したい開発チームの体制