エンジニアの課題選考：要件確認からREADMEと提出後の説明まで

エンジニアの課題選考で、実装後に提出の説明がまとまらない時は、依頼された条件と確認結果を照合します。何を求められ、何を仮定し、相手がどう動作を確かめられるかです。READMEを書きながら不足に気付くより、最初から「約束した振る舞い」と「確かめる手順」を対にしておくと、実装と説明がつながります。

本稿は、架空のタスク期限レポートを題材に、要件確認、範囲の決定、再現できる提出、提出後の説明までを追います。証拠の区分： paizaの運営元による学生向け案内、GitHubとPythonの公式文書を、それぞれの説明の根拠にします。企業共通の選考時間や採点基準は主張しません。候補者報告も使っていません。台帳、架空データ、時間配分と提出方法の提案はPracHubの練習上の判断です。実行結果は、ローカルCLIの25項目と、ZIPを新しいフォルダへ展開した確認に限ります。

課題の曖昧さから練習したい場合は、Navigate an ambiguous take-home assessment を開き、確認事項を一つの具体的な質問にするところから始めてください。

最初に、依頼文の条件と自分の提案を分ける

案内元の説明： paizaのエンジニア面接対策 は、作品の提出と説明、お題に沿ったプログラムの作成を準備項目として挙げています。これは学生向けの案内であり、全企業が同じ課題や時間で選考するという意味ではありません。実際の指示は、応募先から届いた課題文と補足を確認します。

提出物の形式、期限、推奨作業時間、利用できる言語、外部サービスやAIの利用条件、提出先、公開してよい範囲を最初に抜き出します。たとえば「コードを提出」としか書かれていない時、公開リポジトリを作ることも、サービスをデプロイすることも自動的には決まりません。許可された共有方法を確認してから、その形に合わせます。

質問は、作業を変える点に絞ります。「何を作ればよいですか」より、「期限が今日の未完了タスクは、期限超過に含めますか。回答がない場合は当日を除外し、READMEに仮定を記載する予定です」の方が、何を決めたいか伝わります。ただし、仮定を書けば明示的な必須要件を省けるわけではありません。

返答を待つ間は、未確定の判断に依存しない作業を進めます。入力の読み込みと例の整理は先にできますが、認証を必須とするか、既存APIへ書き込んでよいかといった違いは実装全体に影響します。依頼文にない拡張を先に完成させて、肝心の確認が遅れないようにします。

要件台帳を、実行するコマンドまでつなげる

練習の依頼を「タスク一覧から、期限を過ぎた未完了タスクを報告するCLIを作る」とします。これだけでは、入力形式、当日の扱い、不正なデータが混ざった場合の処理が決まりません。そこで、次の台帳を作ります。ここにある番号と分類は、本稿独自の整理です。

「完了」の欄を作るなら、実装しただけで印を付けず、どの入力と期待値で確かめたかも残します。R2のテストが通ったことは、タイムゾーン処理が完成した証拠ではありません。本稿は日付だけを扱い、現在時刻や端末のタイムゾーンから基準日を推測しない契約です。

この台帳があれば、R1からR5を守る作業と、R6の追加機能を区別して優先順位を説明できます。通知を追加するより、R3の失敗時に途中の報告を出さない確認を先に置きます。どちらが一般に高評価かを断言するのではなく、今回約束した結果を優先したと述べられます。

最初の実装は、一つの入力から一つの結果まで通す

サンプルは次の三件です。T41は基準日より前のopen、T42は基準日と同じ日のopen、T43は前日以前でもdoneです。入力の項目を増やす前に、成功と境界の違いが一目で分かるデータにします。

{"tasks":[{"id":"T41","status":"open","due":"2026-10-10"},{"id":"T42","status":"open","due":"2026-10-11"},{"id":"T43","status":"done","due":"2026-10-09"}]}

今回の成功結果は、as-ofが 2026-10-11、overdueが ["T41"]、open_countが2、done_countが1です。open_countは超過件数ではなく、検証された全タスク中のopen件数です。この違いもREADMEに書けば、読み手が結果を誤解しにくくなります。

関数はJSONの文字列と基準日を受け取り、結果を返す形にします。CLIの引数処理や標準入出力と分けると、日付の境界を関数として確かめつつ、提出用コマンドの終了コードも別に確認できます。Web画面を追加しなくても、入力から結果まで一度通せます。

本稿の提案として、練習に120分を割り当てるなら、確認と台帳に15分、最小の処理に40分、境界と失敗の確認に25分、READMEと別フォルダ実行に25分、提出確認に15分という配分が考えられます。これは実測した作業時間や企業の制限ではありません。実際の指示と自分の進捗に合わせ、最後の再現確認を省かないための仮置きです。

JSONが読めることと、契約が正しいことは違う

公式の技術的根拠： Pythonの json文書 は、JSONの読み書きと、object_pairs_hook や parse_constant による処理の変更を説明しています。本稿は標準parserを使い、読み取った後にアプリ側の契約を検証します。JSON構文が正しくても、statusが配列だったり、IDが重複していたりすれば、今回の入力としては不正です。

受け付けるrootはtasks配列だけです。各タスクもid、status、dueだけに絞り、IDはASCIIのTと数字、statusはopenかdoneに限定します。未知のキーを無視しない方針をREADMEに書きました。これは互換性を重視して未知の項目を許すAPIより厳しい契約です。どちらが常に正しいかではなく、依頼に合う方針を説明します。

同じJSONキーが繰り返された場合も、そのまま後の値に置き換えず拒否します。今回の実装では object_pairs_hook で重複を検出し、NaNやInfinityのような値は parse_constant で拒否します。この処理を入れたことだけで、大規模なデータ取込に必要な制限や運用まで実装したことにはなりません。入力サイズ制限や負荷検証は対象外です。

日付については、まず YYYY-MM-DD の形に限定し、その後 date.fromisoformat() でカレンダー上の有効性を確認します。文字の形が合っていても、2月30日は通しません。逆に、標準関数が読める他の形式を全て許すとも決めていません。書式の契約と、日付としての検証を分けています。

提出後に「なぜこの検証を入れたか」と聞かれたら、無効な二件目が一件目の結果を途中で出してしまう反例を示します。設計の説明が抽象的な好みに留まらず、R3を守るための判断になります。

失敗時の出力も、レビューできる結果にする

実行したCLIは、全件の検証が終わってからJSONを標準出力へ書きます。途中で不正を検出した場合は、標準エラーに理由を出し、終了コード2を返します。サンプルの二件目を 2026-02-30 にした確認では、標準出力は空で、エラーに tasks[1] が含まれました。配列の位置は0から数えています。

この「途中の成功結果を出さない」は、検証エラーに対する標準出力の契約です。ファイルの原子的更新、OSクラッシュからの復旧、標準出力への書き込み失敗まで証明したとは言いません。入力全体をメモリに置いているので、大量のデータをストリーミングする設計でもありません。

引数の不足や未知のオプションは argparse に処理させます。テストでは --as-of がない場合、未知の引数、ヘルプ表示も実際の子プロセスで確認しました。関数の例外だけを見て「CLIが失敗を正しく返す」と説明しないためです。

失敗の出力をREADMEに載せると、レビュー担当者は「想定された拒否」と「起動できていない」を区別できます。スタックトレースを全て見せる代わりに、何が不正で、どの終了コードになるかを明示します。ただし、本番のAPI向けエラー形式や機密情報の扱いを実装したと広げないでください。

READMEは、最初の一回を迷わず実行できる順に書く

GitHubの公式説明： READMEについての文書 は、プロジェクトの目的、利用方法、始め方などを伝える役割を説明しています。課題のREADMEでは、その最初に環境と実行手順を置き、長い設計論より先に動作を確かめられるようにします。これは本稿の編集上の提案です。

今回のパッケージはREADME、task_report.py、test_task_report.py、sample.json、invalid.jsonの五つです。Python 3.12を使うこと、外部packageやAPIキーが不要なことを明記しました。python3 がどの実行ファイルを指すかは環境によるため、最初にversionを確認します。実際の再現確認では、Python 3.12.14の同じ実行ファイルを明示して使いました。

python3 --version
python3 -X utf8 task_report.py --as-of 2026-10-11 < sample.json
python3 -X utf8 -m unittest -v
python3 -X utf8 task_report.py --as-of 2026-10-11 < invalid.json

これは、本稿で検証した提出パッケージ内のファイルを前提とするREADMEの例です。自分の提出物ではファイル名や期待値をその実装に合わせます。成功例はJSON一行、終了コード0、標準エラーが空。無効な例は終了コード2、標準出力が空です。後続のコマンドを実行するとシェルの直前の終了状態が変わるため、失敗コマンドの結果はその場で確認します。

続いて、入力契約、設計上の理由、未実装・未検証、変更例の順に書きます。「テスト済み」だけで終わらず、何をテストしたかを示します。「時間があれば改善」も、入力サイズ制限、実環境への配布、通知など、何が現状にないかが分かる言葉にします。

AIや補助ツールを使う場合は、応募先の条件を先に確認し、利用した箇所と自分が検証した範囲を正確に記載します。本稿のCLIは実行時に生成AIを呼びませんが、それは作成時の支援がないという意味ではありません。ツールの利用可否を、一般的なブログから推測してはいけません。

提出する実物を、新しいフォルダで確認する

開発中のフォルダには、入れ忘れた設定や、以前入れた依存関係が残っていることがあります。そこで今回は、五ファイルだけをZIPに入れ、別の新しい一時フォルダへ展開し、CPython 3.12.14で実行しました。テスト出力やキャッシュを追加しなくても、25項目が同じように通ることを確認しています。

テストの内訳は、関数を対象とする18項目と、CLIの子プロセスを対象とする7項目です。正常値、当日境界、完了済み、入力順、空配列、日付書式、不正日付、タスクIDとJSONキーの重複、型やstatus、JSON構文、引数、ヘルプを確認しました。unittestの公式文書 は、コマンドからテストを実行する方法を説明しています。

さらに、展開先で成功例の基準日を11日と12日に変え、出力を確認しました。11日はT41だけ、12日はT41とT42が超過で、open2件とdone1件は変わりません。無効な例も展開先で再実行し、終了コード2と空の標準出力を確認しました。これは25項目と別の新しい25項目があるという意味ではなく、同じテストの再実行と、READMEにある代表コマンドの確認です。

ZIPのSHA-256も記録し、確認の前後でZIP自体のbytesが変わっていないことを照合しました。この値は、今回確認したローカルパッケージを特定するためのものです。署名、第三者の審査、提出先が同じbytesを受け取った証明ではありません。本稿では実際の応募先への送信はしていません。

提出前には、依頼されたファイルがあるか、不要な認証情報や個人データがないか、閲覧権限と提出先が合うかを、その実物で確認します。リンクを送る課題なら、相手が開ける範囲を確認します。公開を求められていなければ、課題の内容をポートフォリオとして自動公開する判断もしません。

提出後は、実装した判断と追加の変更を分けて答える

説明を求められたら、課題を短く言い直し、台帳のR2とR3を使って一つずつ判断を示します。たとえば「基準日当日は超過から除外する仮定を置きました。11日ではT42は入りません。不正な二件目がある場合は全体を失敗にし、途中の集計を標準出力へ出しません」と答えます。結果を開いて説明できるので、設計名を並べる必要はありません。

「基準日を12日に変えてください」なら、既存の引数で対応できます。T42が超過へ入り、件数の意味は変わりません。一方、「当日も超過として扱ってください」は、既存機能を動かすだけではありません。比較条件、当日の期待値、READMEのR2を変更する必要があります。この二つの依頼を、どちらも「対応済み」とは言いません。

また「100万件ならどうしますか」と聞かれた場合、今回の実装では未検証と答えます。入力全体のメモリ使用、ID重複の検出、結果の並べ替えに必要な量を確認し、要件に応じて入力制限や別の処理方式を考えます。まだ測っていない性能値や、実装していないストリーミング処理を実績として足さないことが大切です。

不足を見付けた場合も、提出物と口頭の修正案を区別します。「提出版では未知のstatusを拒否しています。pausedを許すなら、状態別の集計契約を決めてから変更します」のように、現在と次の判断をつなげます。差し替えが必要なら、提出先のルールに沿って変更内容と版を伝えます。

関連問題で、範囲・検証・説明を練習する

以下は全て同じ課題の報告ではありません。最初の二問は曖昧な依頼の扱い、次の二問はデータ契約、最後は既存テストから起動と不具合を調べる練習です。自分の提出物で同じ説明ができるかを確かめてください。

Scope an open‑ended take‑home under constraints で一つ課題を選び、必須項目を一つ、仮定を一つ、未実装を一つ説明してください。実装済みの項目には実行手順と結果、仮定には確認したい点、未実装には追加で必要な検証を添えてください。READMEと提出後の回答を、その区分に沿って揃えます。

Sources and Further Reading

• paiza新卒：選考別対策2 エンジニア面接 — 運営元による学生向け案内。個別企業の選考規則ではありません。
• GitHub Docs: About the repository README file — READMEの役割に関する公式文書。
• Python 3.12: json — JSON parserとhookに関する公式文書。
• Python 3.12: datetime — 日付処理に関する公式文書。
• Python 3.12: argparse — CLI引数とエラー処理に関する公式文書。
• Python 3.12: unittest — テスト実行に関する公式文書。