【ITニュース解説】Grade the Ways It Breaks

ソフトウェア開発者の採用において、候補者の技術力を適切に評価することは常に大きな課題である。特に、AIや大規模言語モデル（LLM）の利用が広がる現代では、単に「動く」システムを作れるかだけでなく、そのシステムがどのように「壊れるか」、そのリスクをいかに理解し、管理できるかが極めて重要となる。従来の持ち帰り課題では、候補者が提出したコードが表面上は動作し、テストもパスして「グリーン」な結果を示す場合でも、その背後にある深い理解や設計思想までを評価することは難しかった。実際には、有料のサービスキーを使って動作させているだけで、レビュー側で再現しようとすると機能しない、といった問題も頻発している。これは、エンジニアリングの本質的な能力、つまり堅牢性やセキュリティ、リスク管理といった側面を見落とし、「見た目の良さ」や「プレゼンテーション」のみを評価してしまう危険性をはらんでいる。

このような課題を解決し、真のエンジニアリング能力を評価するために、本記事では持ち帰り課題に特定の4つのファイルを同梱することを提案する。これらのファイルは、候補者が作成するシステムがどのように機能し、どのように壊れる可能性があるのか、そしてその壊れ方に対してどのような対策を講じるべきかを明確にするための指針となる。具体的には、「PROMPT.md」という課題の要件定義ファイル、「RUBRIC.yml」という採点基準ファイル、「sample_solution/」というリファレンスとなるサンプル実装、そして「FAILURES.md」というシステムの潜在的な問題点を記述するドキュメントである。これらのファイルが揃っていれば、採用担当者は候補者のシステムが単に動くかどうかだけでなく、その設計の意図、潜在的な脆弱性への理解、そしてリスク管理の能力を客観的かつ深く評価できるようになる。一つでもファイルが欠けていれば、それはエンジニアリングの評価ではなく、表面的なプレゼンテーションの評価になってしまうと記事は指摘している。

まず「PROMPT.md」は、候補者に送付する課題の具体的な要件を記述するファイルである。これは、システムの機能だけでなく、そのシステムが満たすべき制約、そしてその制約の背後にある意図を明確に伝える役割を果たす。例えば、記事の提案する課題では、シンプルなHTTPサービスが大規模言語モデルから引用文を取得する機能を構築するよう求める。しかし、単にそれだけでなく、LLMとの連携は特定の無料のエンドポイントのみを使用すること、そのエンドポイントが利用できない場合はサービスが起動すらしないこと、AuthorizationやCookieなどの機密情報をログやレシートファイルに絶対に書き込まないこと、モデルの出力を500文字に制限し、超えた場合は切り捨ててその旨を示すこと、レシートファイルをアトミックに書き込むことなど、非常に具体的な技術的制約が課される。これらの制約は、単に機能を実装する能力だけでなく、セキュリティ、堅牢性、エラーハンドリング、リソース管理といった、実運用で不可欠なエンジニアリングの基礎的な能力を測るためのものとなる。

次に「RUBRIC.yml」は、持ち帰り課題の採点基準を明確に定義するファイルである。このファイルには、各評価項目に対して何点満点で採点するのか、どのような基準で合否を判断するのかが具体的に記述される。例えば、「無料エンドポイントなしでの起動」が4点、「機密情報の取り扱い」が4点といった形で、PROMPT.mdで示された制約への対応状況が点数化される。また、有料キーなしで課題が完了しない場合、特定の項目で0点とするなど、厳格な失敗条件も明記される。これにより、複数のレビューアが異なる主観で採点するのではなく、共通の客観的な基準に基づいて評価できるようになる。そして「sample_solution/」は、課題に対する参照可能なサンプル実装を提供するディレクトリである。これは、単なる「動くコード」ではなく、採点基準に照らしてどのように評価されるかを示す「手本」の役割を果たす。このサンプルは、意図的に特定の条件で壊れるように設計されることがあり、レビューアはそれを実際に動かし、期待通りの挙動をするか、特定の状況で「壊れる」かを確認することで、候補者の提出物を評価する際のベンチマークとして利用する。重要なのは、このサンプルがレビューアの環境で簡単に再現・検証できることである。

最も特徴的で重要なファイルが「FAILURES.md」である。これは、候補者が自ら作成したシステム設計に内在する潜在的な問題点や脆弱性、「嘘」、つまり「こう設計したけれど、実はこういう状況ではうまくいかない可能性がある」という点を記述するドキュメントである。記事ではこれを「解剖報告書」と呼び、候補者には、コードを書き始める前に、設計のどこに「嘘」があるかを洗い出すよう求めている。例えば、大規模言語モデルからの応答をそのまま信頼してしまう問題、文字数制限が単なるバイト数や文字数であって、絵文字などのマルチバイト文字でUIが崩れる可能性、URLリダイレクトによって意図しないサービスに誘導されてしまうリスク、アトミックでないファイル書き込みがデータ破損を招く可能性、ログ出力が意図せず機密情報を漏洩させる可能性などが挙げられている。これらの指摘は、単にコードを書けるだけでなく、そのコードが現実世界でどのように振る舞い、どのようなリスクをはらむかを深く洞察できるエンジニアリング能力を示すものとなる。また、時間制約の中で修正できなかった一つ以上の問題点を記述することも求められる。これは、エンジニアリングが常に「残されたリスク」との戦いであることを理解しているか、そしてそれを明確に言語化できるかを見極めるためである。このドキュメントが単なる一般的なLLMリスクの羅列ではなく、今回開発したHTTPハンドラ固有の具体的な問題点を指摘できているかが評価の鍵となる。

従来の持ち帰り課題の評価では、候補者が提出した画面収録ビデオしかなく、実際にコードを検証できないケースや、有料のサービスキーがなければ動作しないシステム、表面的なテストがパスしているだけで本質的な制約を理解していないケースなどが頻発していた。このような状況では、レビューアは候補者が週末に有料のトークンを使って作った「きれいなデモ」と、真の技術力との区別がつけられないという問題があった。本記事の提案する評価方法は、このような問題に対処し、「プレゼンテーション」や「デモンストレーション」ではなく、真の「エンジニアリング」能力を評価することを目的としている。つまり、与えられた制約をどれだけ深く理解し、その制約の中で堅牢で安全なシステムを構築できるか、そしてそのシステムが持つ潜在的なリスクをどれだけ正確に特定し、管理できるかという、実運用で最も重要な能力を見極めようとするものである。オンサイト面接では、コードの完璧さではなく、候補者が特定した「残されたリスク」について議論し、その理解度を深掘りすることで、本質的なエンジニアリング能力を評価する。

ただし、この評価方法が常に適切であるとは限らない。例えば、複数のサービスにまたがるシステム設計を行うような、より高度な「スタッフロール」の候補者には、このシンプルな課題は不十分で、彼らを侮辱することになるかもしれない。また、レビューする側に、提供されたサンプルを実際に実行し、評価する体制がなければ、この採点基準は意味をなさない飾り物となってしまう。候補者が課題に取り組む時間に対して、適切な報酬を支払うことも重要である。さらに、企業側が無料のエンドポイントを提供できず、候補者に有料のキーを使わせるしかない場合、この評価方法の根幹である「再現性」と「公正性」が失われてしまうため、他の面接方法を検討すべきである。この方法は、派手なAIエージェントのデモを求めるのではなく、候補者がシステムの「壊れ方」を具体的に特定し、その影響範囲を限定し、そして第三者が深夜にでも評価できるような透明性の高い成果物を残せるかを測るためのものである。