言語は業務でよく使うC#かPerlの好きな方を選択。単純なコマンドプロンプト/ターミナル用プログラムが出題されることを理解してもらうために、本番の問題に近い例題とサンプルプログラムを提示。しても他の言語を使いたい場合は要相談。ところが、10人中8人がPerlを選択したので結局全員がPerlで書くことになった。インターネット検索や技術書の利用はOK。標準ライブラリや構文の確認等に限定する。FizzBuzzの解答例を検索するのは禁止。全員がすぐにプログラムを書き始められる状態にしてから、一斉に回答を開始する。全員の前でプログラムの動作確認とロジックの解説を行う。ライトニングトークのように質疑応答はなし、5分で完全に打ち切り。各自がメンバーの中からイケてるプログラマ3人を選出。1位=3ポイント、2位=2ポイント、3位=1ポイント。そのプログラマが良いと思ったのかという理由も記述。投票は投票用紙を使い、無記名で行う。自分で自分に投票しても良い。早く終わった3人にはボーナスで3ポイント加算。合計点が一番多い人が優勝。優勝するとマネージャーから粗品がもらえる(予定)。開票もその場でオープンに実施。「1位xxさん、2位yyさん、3位zzさん、(次の紙)1位aaさん・・・」というように、記入された順位と氏名を順に読み上げていく形式。1位の人から最下位の人まで、全員の順位がその場で明らかになる。評価基準は基本的に個人の自由だが、参考までに以下のような評価ポイントを提示しておいた。回答者としてプログラムを書く。出題者なので評価対象にはしない(順位はつかない)。元プログラマだが、プログラムは書かない。当日の参加人数プログラマは自分を含めて10人。当日は都合により出席でないメンバーが3人いた。*11から順番に数をコマンドプロンプト/ターミナルに表示する。両方で割り切れるなら"FizzBuzz"と表示する。16実際にはスペースではなく、改行して区切る。5minで、実際にやってみた使い慣れてるC#なら楽勝♪と余裕綽々なおいらでしたが、土壇場でPerlを使うことになり、他のメンバーと同じスタートラインに引き戻された気分でした。あれ?起動時引数はどうやって取得するんだったっけ?ループ処理と条件分岐の書き方は??サブルーチンの定義方法は???と、グーグル先生のお世話になりっぱなしでした。速いメンバーは10分程度で終了しました。それからしばらくして、ぽつぽつと他のメンバーも終了しました。おいらは15分ぐらいで大体ロジックを完成させましたが、すぐに終了せず、細かい部分のリファクタリングを行いました。25分ぐらいで手を止めて、5番目に終了宣言しました。ホワイトボードに書かれた終了宣言済みメンバーの名前を見てみたら・・・あれ?7人しか名前がない。して、できなかった人がいる!?そんなバカなと思いながら、10分間の休憩タイムに入りました。動作確認とプログラム解説は座っている席の順番で回していきました。その結果と感想は・・・。終了宣言をしていない3人は本当に完成していなかった。(!!)うち二人はほとんどロジックらしいロジックが書けていなかった。確かに3人ともPerlを業務でバリバリ使っている人ではなかったが、インターネット検索も許可している条件でこの結果はどうしたものか・・・。みんな大体同じようなロジックになるんじゃないかと思いきや、かなりバラつきがあった。なんか妙にトリッキーだったり、明らかに不要なコードをあえて残しているようなロジックがあった。微妙に仕様をアレンジしてくる人もいた。社内で比較的プログラミング能力が高いと思われている人は、やはりシンプルで分かりやすいロジックを書いていた。全体としてFizzBuzzのようなシンプルな問題でも、プログラムにはその人のキャラクターが現れている気がした。(自分のプログラムも含めて)引数のバリデーション(フォーマットチェックや範囲チェック、引数の個数チェック等)を実装している人はほとんどいなかった。0や-1、abc等を引数に与えたら全く何も起きない、またはPerlデフォルトのエラーメッセージが出るというプログラムが多かった。仕様には書いていなくても、もうちょっと気にする人がいてほしかった。テスト駆動開発で開発する人も皆無だった。おいらはC#だったらNUnitを使うつもりだったんだけど、Perlのテストフレームワークにはほとんどなじみがなくて・・・と言い訳。全員の動作確認とプログラム解説が終わった後に、各自がベストプログラマ3人を投票しました。それからドキドキの開票となったわけですが・・・結果はほとんど全員が同じメンバーを1位、2位、3位に選んでいました。2位と3位は多少バラつきましたが、1位はほぼ全員が同じメンバーに投票していました。みんなシンプルでわかりやすいプログラムを「良いプログラム」と評価するようです。まとめ初めての社内プログラミングコンテストは色々と興味深い発見があり、面白かったです。全員楽勝だろうというおいらの予想は見事に外れました。反対にマネージャーの予想が的中してます。(それは面白いというより困った事態ですが・・・。)メンバー各自はそれぞれ異なるロジックを書いたものの、「良いプログラム」に対する考え方は全員同じベクトルを向いていました。それにしてもFizzBuzz問題を解けなかったメンバーがいたことは結構ショックでした。確かに、彼らはそれほどPerlに使い慣れているわけではありません。事前に似たような例題を示した。してもPerlが苦手であれば、得意な言語を選択することもできた。インターネットや技術書は自由に使えた。全員新人ではなく、それなりの経験年数を持ったプログラマだった。おいらを含めて、Perlがあまり得意ではないメンバーは他にもいたが、なんとか問題を解いた。FizzBuzz問題の仕様は特定の言語に依存するようなロジックを要求しない。等々考えると、あまり弁護の余地がないのでは・・・などとつい考えてしまいます。実際にプログラムを書いてもらうことは、その人のスキルやプログラムのセンスを如実にさらけだすものだと思いました。職務経歴書を読んだり、「Perlができます」「Javaができます」なんて話を聞いたりするより、ずっと確実にその人のスキルが測れます。マネージャーも今回のプログラミングコンテストの成果に満足していたようです。できれば少し問題のレベルと形式を変えて、第2回社内プログラミングコンテストを開催したいと思います。8:45追記)おいらの個人的な推測ではなく、メンバーに実際理由を聞いてみました。その内容は別エントリにまとめてあります。22:15追記)FizzBuzz問題をあえて選んだ理由を詳しく述べると以下のようになります。裏の目的として社内メンバーのプログラミングスキルを社外のプログラマとも比較したかった。そのためにはおいらが独自に考えた問題よりも、すでに良く知られている定番問題の方が相対的な評価がしやすい。その反面、「FizzBuzz問題なら知っている」とか「以前書いてみたことがある」というリスクは十分予測できた。そのリスクはあえて覚悟した上で、FizzBuzz問題を選択した。リスクを軽減させるために、プログラミングコンテストを開催することは全く伏せた上で、メンバーを集めた。事前にアナウンスすると定番のFizzBuzz問題を予習する人が出てくるかもしれないので。「知っている、書いたことがある」メンバーが数多くいたり、そのせいでコンテストの結果に大きな不公平感を残すことになれば、第1回プログラミングコンテストは失敗ケースとして、次回以降の反省材料にするつもりだった。結果としてはそのような問題は今回発生しなかった。少なくとも、おいらの社内においては「FizzBuzzを知らない」もしくは「知っていても解いたことがない」メンバーがほとんどだったと思われる。それはそれでちょっと悲しい話なんですが・・・。23:30追記)反響を見てると、「10分じゃ遅い」とか「バリデーションはやりすぎ」みたいなコメントを時々見かけます。それはそれでいいと思います。今回は速さを競うコンテストにしたわけではありません。速いだけで良いなら、「一番先にバグのないプログラムを書いた人が優勝!」で終わりです。今回のコンテストでは速い人3人に3ポイントは与えるものの、同僚の評価次第では遅くても優勝できる可能性を残しています。速く仕上げたい人は速く仕上げれば良いし、じっくりと仕上げたい人はじっくりと仕上げても良いのです。同僚の中に「速い人ほどスキルが高い」と思う人がいれば、速い人に投票するでしょうし、速さ以外の工夫を評価する人がいれば、遅い人にも投票するわけです。プログラムを書く側も解説タイムの中で「こんなに速く書けたのが自慢です」とか「私は入力値のバリデーションは欠かせないと思っています」とか、プログラマとしての自分のこだわりを自由にアピールできます。3番目に終了したメンバーは投票の結果、6位に終わりました。速さを競うだけなら、彼は「社内第3位のプログラマ」になるはずでした。他のメンバーからの投票は1ポイントも獲得できませんでした。微妙に仕様を変えたり、必要以上に複雑なロジックにしてしまったのが、敗因だったんじゃないかと推測しています。結局、おいらが見たかったのは、ここにいるメンバーがどういうプログラムやどういうプログラマを良いと評価するのか、ということです。それゆえに、プログラムを書く人も、それを評価する人も基本的に考え方は自由ということにしています。コメントを残してくれているあなたがこのコンテストに参加していれば、あなたの投票によって違う人が1位になっていたかもしれません。良いプログラム、良いプログラマの定義は、あなた自身の思想やあなた自身がおかれているコンテキストによって変わってくる、そういうものなんじゃないかとおいらは考えます。参考資料1位の人が書いたプログラム10分ぐらいでさらっと書き上げたプログラムです。"\n";}おいらが書いたプログラムmain関数がないと落ち着かない、サブルーチンを細かく分けたい、入力値のバリデーションをしないと不安・・・という、おいらの性格をよく表していると思います(笑)。}}お遊びで書いたF#版プログラムたぶんみんな似たようなロジックになって面白くないんじゃないかと思い、前日の晩に「できるだけ関数型言語らしく書こう」と思いながら書いたプログラムです。関数型っぽいかどうかはあまり自信がありませんが。22:30追記)社内用なのでかなり適当に作っていますが、何となく当日の雰囲気やノリが伝わるかもしれません。try→このコンテストの後日談です。FizzBuzz問題が解けなかった理由や今後の改善点について考察しています。try→社内勉強会の一環として開催したコードレビューコンテストのお話です。(id:studio-m)→仕様は全く同じなのに、全員が違うプログラムを書いた。これはやはりプログラミングが製造ではなく、設計であることを証明していると思います。プログラマの評価は手を動かしてこそなんぼ、という話は以下の本でも言及されています。見る*1:このサイトを参考にしています。こちらもあわせてどうぞ。AgileTourOsaka2011に行ってきました。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。blog)はてなブログをはじめよう!JunichiItoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。