【ITニュース解説】DOGFOOD 26'

このニュース記事は、ハッカソン「Dogfood 2026」で、Hackathon Raptorsというチームが、将来のイベントで実際に使うオープンソースの提出・審査プラットフォームを72時間で構築した経験について語っている。彼らの作品「RaptorGate」は、PythonのWebフレームワークであるDjango 5.2とデータベースのPostgreSQL 16を使って開発され、Docker Composeという技術を使えば、簡単なコマンド一つでローカル環境にシステムを立ち上げられるように作られた。公式の機能要件であるT1とT2ティアをクリアし、残りのT3とT4ティアについても部分的な実装を公開したという。

開発は予想以上に困難だったようだ。まず、イベントの開始時期が24時間前倒しになったことで、すべてのコードをその期間内に書くというルールに抵触してしまった。既に100以上のコミット（コードの変更履歴）を重ね、テストもパスしていた最初のコードベースは、ルールに違反するため全て破棄し、同じ設計思想でゼロから書き直すという苦渋の決断を強いられた。これは開発チームにとって、どんなバグよりも辛い経験だったと記されている。

次に直面したのは、締め切り処理の難しさだ。システムは、締め切り後に提出されたプロジェクトに対して「403 Forbidden」（アクセス拒否）のエラーを返す必要があった。しかし、Djangoに標準で備わるCSRF（クロスサイトリクエストフォージェリ）対策のミドルウェアも、同じ403エラーを返す場合がある。このため、システムが返す403エラーが、CSRFによるものなのか、それとも意図した締め切り処理によるものなのかを判別するのが難しかった。結果的に、CSRF機能を一時的に無効にして別途テストを行うことで、締め切り処理が正しく動作していることを確認したという。この経験から、テスト結果を鵜呑みにせず、その原因を深く掘り下げて確認することの重要性を痛感したと述べられている。

データベースの設計、つまりデータの構造についても反省点があったようだ。現在のシステムでは、プロジェクトがどのイベントに属するか、審査員がどのプロジェクトを審査するかといった重要な関係性が、データベースの制約としてではなく、アプリケーションのコード側でチェックされている。これでは、もし将来的にコードのチェック漏れがあった場合、誤ったデータ（例えば、別のイベントに属するプロジェクトを登録してしまうなど）がデータベースに保存されてしまうリスクがある。理想としては、データベース自体に「外部キー制約」と呼ばれる仕組みを導入し、データ間の正しい関係性を強制すべきだったと反省している。これにより、アプリケーションのバグがデータベースのデータ整合性を損なうのを防ぐことができるからだ。

審査員の採点を公平に扱うための「スコア正規化」という数学的な処理も大きな課題だった。審査員ごとに採点基準が異なるため、単純に平均点を出すだけでは比較できない。そこで、各レビューを機能性、品質、革新性で重み付けし、各審査員の採点の平均値とばらつき（標準偏差）を計算して、全てのスコアを一定の基準に合わせる正規化処理を行った。例えば、いつも同じ点を付ける審査員がいた場合、その審査員のスコアが不当に評価に影響しないように中立的な3.0点として扱うなどの工夫を凝らした。しかし、この正規化処理を適用した結果、プロジェクトの順位が大きく変動した。これに対し、開発チームは「新しい順位が本当に正確になったのか、単に変わっただけなのか」という疑問に直面したという。全ての審査員が全てのプロジェクトを審査したわけではなく、一部の審査員は一つのプロジェクトしか審査していないケースもあり、数学的な処理は正しくても、その「正確性」を完全に保証できるものではないと判断した。そのため、最終的なランキングには、正規化処理によるものだという注意書きを添え、主催者には生データやレビュー数も確認した上で最終的な判断をするよう促した。

セキュリティ面では、「役割分離のバグ」という重大な脆弱性が発見された。これは、審査員への招待メールをシステムがグローバルな（イベント全体で共通の）メールアドレスとして管理していた初期のバージョンで発生した。もし、あるイベントAで審査員を務めている人が、別のイベントBでも同じメールアドレスで招待された場合、イベントBの招待承認トークンを持つ人がそのアカウントのパスワードを変更し、イベントAの審査員アカウントにアクセスできてしまうというものだった。これはイベントをまたいだ権限の乗っ取りにつながる脆弱性であり、開発チームはすぐに修正を行った。具体的には、既にいずれかのイベントで審査員として登録されているメールアドレスは、新たな招待を受け付けないようにした（これを「フェイルクローズ」と呼ぶ）。このバグは本番環境にリリースされる前に、開発段階のレビューで見つけられたため、非常に幸運だったという。この経験から、セキュリティに対する高い意識が生まれ、スコアの書き込み時にも、所属トラックや割り当ての再確認、自己チームとの競合チェックを厳重に行うなど、さらなる対策を施した。

限られた時間の中で、実装を断念した機能もあった。例えば、「ペアワイズ審査」という、審査員がプロジェクトを二者択一で比較していくことで、より正確な順位付けを目指す手法が検討されたが、これは実装時間の不足から見送られた。中途半端な機能を作るよりも、重み付けスコアと正規化を確実に動作させ、検証済みとすることを選んだのだ。この決断が、ハッカソンでのポイント獲得につながったと開発チームは振り返っている。

最終的に、公開デモ機能は締め切り直前にテストが不十分な状態でリリースされ、コメント機能のエラーや投票のJSONエラーなど、複数のバグがユーザーからのフィードバックによって発見された。また、プロジェクト提出フォームも締め切り時間を2分過ぎて提出されたが、これは幸運にも受け入れられたという。この経験から、必須機能を優先し、見た目や細部の磨き上げは後回しにするという開発の優先順位の重要性を再認識したと締めくくっている。

プロジェクトは、Djangoテスト296件、pytestテスト299件という多数のテストコードによって品質が担保されており、公式チェッカーで7/7の検証をクリアした。テストデータとして、8トラック、30人の審査員、41のプロジェクト、126のスコアデータが用意され、正規化処理の結果も再現できるようになっている。GitHubで公開されているリポジトリを通じて、詳細なコードや仕組みを確認できる。