プログラマー面接で作品を説明する：デモ・コード・自分の貢献の見せ方

プログラマー面接で作品を説明するときは、動く画面を見せて終わりにしないでください。デモで確認した動作から、その動作を支えるコード、自分が担当した変更、判断の理由へ移れるように準備します。見栄えのよい作品と、技術的な会話ができる作品は同じとは限りません。

作品が小さくても、入力、状態、失敗、検証を説明できれば材料になります。反対に、機能が多くても、どこを自分が作ったか分からなければ、聞き手は本人の能力を判断しにくくなります。

まず PracHubの技術判断と個人の貢献を深掘りする質問で、一つの機能について説明してみてください。この記事は作品の紹介順とデモの準備に絞り、特定企業の面接内容や提出許可を保証しません。

作品を選ぶ前に、提出と共有の条件を確認する

最初に面接案内を読みます。画面共有があるか、事前提出が必要か、実行ファイルやソースコードを求められるか、ファイル形式や容量の指定があるかを確認してください。一般的なポートフォリオの助言より、応募先の指示を優先します。

一社の例として、グッド・フィールの2027年入社プログラマー募集は、自作プログラムのソースコードを必須とし、実行ファイルがあれば望ましいとしています。またゲーム以外の作品も可とし、チーム制作では担当箇所の記載を求めています。これは同社の募集要件であり、すべてのプログラマー職の共通ルールではありません。

この例でも、ゲームを作らないと応募できないと読み替えてはいけません。要件を正確に読み、見せる作品と説明の範囲を決めます。提出数が指定されていない場合も、面接で全部を同じ深さで説明する必要はありません。

共有できる権利も確認します。前職のコード、顧客データ、未公開の共同研究、他人の素材を無断で公開してはいけません。秘密情報を隠した独自例や、許可された概要で説明できるかを考え、判断が必要なら権利者に確認します。

最初に見せる作品は、会話への入口で選ぶ

作品選びでは、応募職種との関連、自分の担当の明確さ、再現可能性、深掘りできる判断を見ます。ダウンロード数や機能数だけで順位を付ける必要はありません。測っていない数値を加えて魅力的に見せることも避けます。

Webアプリなら、画面からAPI、データ保存、失敗処理へのつながりが候補になります。ゲームなら、入力、状態更新、描画、負荷や操作感の判断を説明できます。CLIツールなら、入力と出力、例外、テストで動作を見せられます。

動く作品がまだ少ない場合は、一つの機能を完成させて説明可能にする方が準備しやすいことがあります。大規模なアプリを急に増築し、どの依存関係も説明できなくなるより、既存の機能の境界と検証を整理してください。

紹介する主作品を一つ、質問に応じて出せる補助作品を一つ用意するのは本文の提案です。応募先の指定があるならそちらに従い、「必ず二作品」という採用規則にはしません。

デモの順序：目的、正常動作、失敗、回復

デモを始める前に、誰のどの問題を扱う作品かを短く伝えます。次に代表的な入力で動かし、出力や状態変化を確認します。画面のどこを見てほしいかを言わずに操作を続けないでください。

正常動作の後は、説明したい失敗を一つ見せます。無効な入力、通信失敗、権限不足、到達不能など、作品に実際にある状態を選びます。そして、ユーザーがどう回復するか、内部状態が壊れていないかを示します。

最後に、その動作を担当したコードへ移ります。デモと関係のない大きなファイルを開くより、「今見た重複拒否はこの条件で判断しています」と接続すると、コードの読み方が明確になります。

例えば三分で練習するなら、概要、正常動作、失敗と回復、担当コードへの移動に時間を分けます。三分は自主練習の枠であり、面接の指定時間ではありません。質問が入ったら、予定していたスライドより質問を優先します。

独自の迷路例で、デモとコードを結び付ける

以下は説明の練習用に作成した架空の作品例です。既存企業の課題や、実際に公開したゲームの実績ではありません。上下左右に一マスずつ移動し、壁を通れない格子で、開始点から終点までの最短移動回数を返すツールを想定します。

開始点は左上、終点は右下とし、.は通行可、#は壁です。まず次の固定入力を使います。

....
.##.
....
.##.

最短移動回数は6です。上の行を右へ進み、右端を下へ進む経路があります。各移動のコストは同じなので、幅優先探索を使えば距離の小さい順に探索できます。到達不能な場合は、距離0ではなく None を返すと決めます。

from collections import deque

def distance(grid, start, goal):
    height, width = len(grid), len(grid[0])
    if grid[start[0]][start[1]] == "#" or grid[goal[0]][goal[1]] == "#":
        return None
    queue = deque([(start, 0)])
    seen = {start}
    while queue:
        (row, col), steps = queue.popleft()
        if (row, col) == goal:
            return steps
        for dr, dc in [(1, 0), (-1, 0), (0, 1), (0, -1)]:
            nr, nc = row + dr, col + dc
            if (0 <= nr < height and 0 <= nc < width
                    and grid[nr][nc] != "#" and (nr, nc) not in seen):
                seen.add((nr, nc))
                queue.append(((nr, nc), steps + 1))
    return None

この関数は、空ではない長方形の格子と範囲内の座標を前提にします。画面から入力を受ける作品なら、その前提を別の入力検証で守る必要があります。また返すのは距離だけです。経路自体を描画するなら前のマスを記録して復元する処理が必要で、この関数だけで描画まで完成したとは言えません。

失敗のデモには、次の入力を使えます。右下は通行可能ですが、隣接するマスが壁で孤立しているため、到達できません。

....
.###
...#
.##.

説明する判断は「到達不能を距離0と区別する」「探索済みの集合を実行ごとに作る」「リセット後に以前の結果を残さない」です。画面で成功だけを見せる場合より、状態と失敗処理に関する質問へ進めます。

本文の検証対象は、この独自関数と小さな固定入力です。UI、通信、配布環境の動作まで検証したことにはなりません。自分の作品で話すときも、ローカルのテストと実際の利用環境を分けてください。

担当台帳を作り、チームの成果と自分の貢献を分ける

共同制作の場合、作品全体の目的を話した後、本人が担当した機能を示します。コミット数だけでは、変更の責任や判断の範囲は分かりません。説明できる変更と、その根拠を選びます。

次の台帳も架空の迷路ツールの例です。実在のチーム、ファイル、コミットを示すものではありません。

実際の作品では、関数、テスト、変更差分をすぐ開けるようにします。過去のコードなら、提出版と説明する版が一致しているかも確認してください。GitHubの通常のブランチURLは後から内容が変わるため、説明する版を固定したいときは特定コミットのファイルへの恒久リンクを使えます。後で加えた機能を、当時から存在したように話さないことが大切です。

生成AIを使った部分も同じです。生成された案、自分が修正した箇所、テストで確かめた範囲を分けます。応募先が利用を制限している場合は、その指示を守り、使用の有無を質問されたら正確に答えてください。

コードを開いたら、読み上げずに判断を説明する

迷路の例なら、「queueを使っています」で終わらず、移動コストが均一であるため距離順の探索が適していることを説明します。探索済みの印をキューへ追加するときに付けるのは、同じマスが繰り返し追加されるのを防ぐためです。

「斜め移動を許可したら？」と聞かれた場合、移動候補と距離の意味を確認します。「床ごとに移動コストが違ったら？」なら、同じ探索で最小コストを保証できるかを見直します。変更の内容を聞かずに、どんな仕様でも同じコードで動くと答えないでください。

計測していない性能を聞かれたら、まず理論上の範囲と未測定の範囲を区別します。この関数は格子のマス数に対して時間・空間が線形に増えますが、描画速度や起動時間は別の測定です。高速、軽量、安定という形容詞には、確認方法が必要です。

失敗の説明でも、修正後に何が保たれたかを示します。到達不能のケースを追加しただけで、正常な経路や開始点と終点が同じ場合を壊していないかを確認します。テスト名を並べるより、どの誤りを防ぐテストかを話してください。

動かない場合に備え、代替資料と復旧手順を用意する

面接当日に初めて起動確認するのは避けます。提出版、依存関係、起動コマンド、必要な環境変数、使用する固定データを事前に確認してください。秘密のキーや個人情報を画面共有で見せないよう、デモ用のデータを使います。

ネットワークが必要な作品なら、何が接続できないと動かないかを説明できるようにします。許可される場合は短い録画やスクリーンショットを代替資料にできますが、録画は現在の環境で動く証明にはなりません。撮影時の版や条件を添えます。

操作が失敗したら、無言で試行を繰り返すのではなく、何が起きているかを短く説明します。既知の復旧手順で直るか確認し、難しければコードや固定入力へ移って議論を続けます。画面だけに頼らない準備が役立ちます。

GitHub公式のREADME説明を参考に、作品の目的、開始方法、貢献者を整理できます。面接用には、デモ入力、担当範囲、既知の制限も分かるようにすると、説明する版を確認しやすくなります。

五つの質問で、作品の深掘りを練習する

以下は作品紹介の補助になるPracHubの質問です。企業の提出要件や日本の面接形式を表すものではありません。実装言語や自分の経験に合うものを選びます。

最後のリハーサルでは、相手に途中で質問してもらいましょう。「そのコードは誰が書いた？」「失敗した入力は？」「別の方法では？」と止められても、目的と根拠へ戻れるかを確かめます。

プログラマー面接で作品を説明する準備は、展示を豪華にすることではありません。動作を再現し、関係するコードを開き、自分の判断と検証を話せる状態にすることです。デモ、コード、貢献の三つが同じ機能を指しているかを確認してから、本番へ進んでください。

出典・参考資料

• グッド・フィール公式：2027年入社プログラマーの作品・ソースコード・担当箇所の要件。一社の例
• GitHub公式：READMEの目的と記載内容
• GitHub公式：説明するファイルの版を固定する恒久リンク