tryプログラミング、リモートワーク、田舎暮らし、音楽、etc.2011-10-13FizzBuzz問題が解けなかった理由を聞いてみた社内勉強会はじめにかなり大きな反響があった第1回社内プログラミングコンテストの後日談です。FizzBuzz問題が解けなかったメンバーに、なぜ解けなかったのか、どうすれば解けていたのかを質問してみました。第1回コンテストの良かった点、悪かった点をふりかえり、次回以降の改善ポイントを考えてみます。tryなぜ解けなかったのか、どうすれば解けていたのか?メンバーの回答から、解けなかった理由をピックアップすると以下のようになります。Perlに慣れていなかった起動時引数の取得やあまりの求め方を調べるのに大半の時間を使ってしまったPerlの業務経験は改造案件が中心で、この種のプログラムをゼロから作ったことがなかったルールを勘違いして、もっと得意な他の言語を選択しなかったPerlでも大丈夫だと思っていたが、実際そうではなかった焦ってしまい、冷静に解けなかった頭の中でロジックを十分構築しないままプログラムを書き始めてしまい、それが結局遅れにつながっただいたいこのようになりました。えーと、手厳しい皆さんであれば「そんなの言い訳にしかならん!」「プロなら30分もあればどんな言語でもFizzBuzzぐらい書ける!」等々言いたくなるであろう気持ちはわかります。実際、Perlがそれほど得意ではなくても30分以内に解答できた、というメンバーはいます。(おいら自身もPerlはどちらかというと苦手)ただ、3人とも「ロジックはだいたい頭の中でできていた」と言っています。すれば解けていたのかというと、Perlを事前にもっと勉強していればできていたもっと時間があればできていた別の言語を選択していればできていたコンテストがあると事前にわかっていれば、冷静に解けていたということになります。本当にロジックが頭の中でできていたのであれば、解けなかった本当の原因は以下のようになると思います。ネットや書籍から必要な情報を探し出すスキルに問題がある新しい言語にすばやく適応するスキルに問題があるフルスクラッチでプログラムを作り上げるスキルに問題があるどんな状況でも問題を冷静に処理するスキルに問題があるどうすればロジック力を公平に評価できるのか?上で挙げた「本当の原因」は確かにプロとして問題があることは間違いないのですが、「FizzBuzzのロジックすら思いつかないダメプログラマ」というネット上の批判(?)とはちょっと異なる気がします。本来であれば、各メンバーがロジックをどのように考え、それをどうプログラム上で表現したのかを評価するコンテストになるはずでした。前回の実施方法ではそれだけでなく、「情報を探し出すスキルがあるのか」「適応力があるのか」といった評価までオマケで付いてきてしまいました。いった評価は本来の目的ではないため、別の方法で評価すべきです。「メンバー全員が知らない言語でFizzBuzz問題を解かせる」といったことをしないと、不公平になります。次回はそういった不公平感をなくし、ロジック力やきれいなコードを書くスキルだけにフォーカスさせる工夫が必要になります。具体的には以下のようなルールに変更する予定です。(文字列関数の一覧やファイル入出力の方法など)時間に余裕を持たせるPerlに不慣れな人に合わせた解答時間を設定をする早く終わった人にはいったん業務に戻ってもらう。別パターンの解法を考えてもらうとにかく頭の中にあるものをアウトプットしてもらう頭の中でロジックはできているのに、どうしてもそれがPerlで解けないのであれば、フローチャートや文章などで頭の中にあるロジックを表現するところで上の変更点の中で「なぜPerlに統一?」と思った方がいるかもしれません。これはできなかった3人にインタビューしたところ、「コンテストなら言語は統一しておいた方が良い」「事前に伝えてもらえれば準備できる」というコメントをもらったためです。最悪、Perlのせいでプログラムとして表現できない場合はフローチャート等でアウトプットしてもらうので、全く評価不能ということにはならないはずです。これで解けなかった理由を言語のせいにはできなくなります。次回はFizzBuzzよりも難しい問題を出そうと思っているので、もしその問題を全員が解けたら「FizzBuzz問題も実は大丈夫だった」という保証(?)にもなるのではないでしょうか。話は変わりますが、コンテストに参加した全員に「FizzBuzz問題を知ってましたか?」という質問をしてみました。