プログラミングコンテストの審査をしてみて

Erlang/OTPやElixirなどの作品を競うSpawnFest 2018というプログラミングコンテスト(2018年11月24日0000UTC〜25日2359UTCの48時間開催)の審査を依頼された。人生初の作業だったので緊張したが、審査員としても大いに学ぶものがあった。以下、審査員としての感想を記す。(審査の結果や詳細については守秘義務があるため書かない。また審査にあたり金銭報酬は一切得ていない。)

まず基本的なこととして、審査員の時間は参加者と同様に有限であり、審査する側が審査する技術に対して必ずしも全てを熟知しているわけではないことは留意しておく必要があると思う。具体的には以下のようなことは押さえておいて欲しい。

* 参加したら何か結果を残しておいて欲しい。今回はGitHubを審査に使用したが、コミットのないプロジェクトのレポジトリには点数は与えようがなかった。
* コンパイルやビルドができないプロジェクトは評価できない。動かないものには低い評価を与えざるを得ない。そして審査員は参加者と同じ実行環境を使っているとは限らない。実行環境依存の要素は極力排除しておくべきだろう。実行環境のセットアップを容易にする試みとして、今回はdocker-composeで評価対象以外のデータベースなどの周辺環境を用意しておくという参加例がいくつかあった。
* ドキュメントが書かれていないプロジェクトは評価のしようがない。試しようがないからである。高い評価ができたプロジェクトはREADMEを読んでその通りにするだけであっさりと動いた。
* 視覚的な要素に訴えるプロジェクトはそうでないものより判断しやすい。ただし、その分複雑になるため、まともに動かすのは難しくなるというリスクもあるように思う。今回はElixirのプロジェクトでPhoenixフレームワークを使うものがいくつかあったが、この場合はどうしてもnpmを使うため、そこで問題が出ることがある。言い換えれば、Erlang/OTPやElixirのコンテストであっても、場合によっては呼ばれるJavaScriptまで評価の対象になるということである。
* 用途がすぐにわからないプロジェクトは評価のしようがない。言い換えれば、用途を含めた企画力まで評価の対象になる。用途を説明するデモをプロジェクトに含めておくことは高い評価を得るために必要である。

SpawnFest 2018の結果を見ると、受賞したプロジェクトは、どれも目的が明確で、検証しやすく、審査員に訴えかけるものが明確であることがわかる。私も最優秀の作品には "Fully running code, fun to use, looks practical." (全体が完全に動き、使っていて楽しく、実用的。)という評価をした。

…ここまで審査員の立場で書いたが、私自身が参加者の立場になったら、48時間で上記の基本的な要素をすべて揃えられるかどうかは全く自信がない。そう考えると、今回のプログラミングコンテストはとてもレベルの高いものであったといえるだろう。運営側として私に声をかけてくれたBrujo Benavides他運営の皆さん、審査員の皆さん、そして参加者の皆さん全員に敬意を表したい。そして来年はぜひ日本からも参加して欲しい

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

皆様からいただいたサポートは、個人事業の研究開発活動で使わせていただきます。

ありがとうございます。励みになります!
5

力武 健次 / りきたけ けんじ

力武健次技術士事務所 所長。ペパボ研究所 客員研究員。ソフトウェアエンジニア。https://github.com/jj1bdx https://www.instagram.com/jj1bdx 事務所Webページ: https://rikitake.jp

写真を使っていただいた記事

シェアした写真を使っていただいた記事をまとめています。