FizzBuzz問題が解けなかった理由を聞いてみた

はじめに

かなり大きな反響があった第１回社内プログラミングコンテストの後日談です。
FizzBuzz問題が解けなかったメンバーに、なぜ解けなかったのか、どうすれば解けていたのかを質問してみました。
また、第１回コンテストの良かった点、悪かった点をふりかえり、次回以降の改善ポイントを考えてみます。

何の話かよくわからない方は先にこちらをどうぞ↓

FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try

なぜ解けなかったのか、どうすれば解けていたのか？

メンバーの回答から、解けなかった理由をピックアップすると以下のようになります。

Perlに慣れていなかった
- 起動時引数の取得やあまりの求め方を調べるのに大半の時間を使ってしまった
- Perlの業務経験は改造案件が中心で、この種のプログラムをゼロから作ったことがなかった
- ルールを勘違いして、もっと得意な他の言語を選択しなかった
- Perlでも大丈夫だと思っていたが、実際そうではなかった
焦ってしまい、冷静に解けなかった
- 頭の中でロジックを十分構築しないままプログラムを書き始めてしまい、それが結局遅れにつながった

だいたいこのようになりました。

えーと、手厳しい皆さんであれば「そんなの言い訳にしかならん！」「プロなら30分もあればどんな言語でもFizzBuzzぐらい書ける！」等々言いたくなるであろう気持ちはわかります。
実際、Perlがそれほど得意ではなくても30分以内に解答できた、というメンバーはいます。(おいら自身もPerlはどちらかというと苦手)

ただ、3人とも「ロジックはだいたい頭の中でできていた」と言っています。
なので、どうすれば解けていたのかというと、

Perlを事前にもっと勉強していればできていた
もっと時間があればできていた
別の言語を選択していればできていた
コンテストがあると事前にわかっていれば、冷静に解けていた

ということになります。
本当にロジックが頭の中でできていたのであれば、解けなかった本当の原因は以下のようになると思います。

ネットや書籍から必要な情報を探し出すスキルに問題がある
新しい言語にすばやく適応するスキルに問題がある
フルスクラッチでプログラムを作り上げるスキルに問題がある
どんな状況でも問題を冷静に処理するスキルに問題がある

どうすればロジック力を公平に評価できるのか？

上で挙げた「本当の原因」は確かにプロとして問題があることは間違いないのですが、「FizzBuzzのロジックすら思いつかないダメプログラマ」というネット上の批判(?)とはちょっと異なる気がします。
本来であれば、各メンバーがロジックをどのように考え、それをどうプログラム上で表現したのかを評価するコンテストになるはずでした。

しかし、前回の実施方法ではそれだけでなく、「情報を探し出すスキルがあるのか」「適応力があるのか」といった評価までオマケで付いてきてしまいました。
こういった評価は本来の目的ではないため、別の方法で評価すべきです。
たとえば、「メンバー全員が知らない言語でFizzBuzz問題を解かせる」といったことをしないと、不公平になります。

なので、次回はそういった不公平感をなくし、ロジック力やきれいなコードを書くスキルだけにフォーカスさせる工夫が必要になります。
具体的には以下のようなルールに変更する予定です。

抜き打ちではなく、コンテストの開催を事前に告知する
使用する言語をPerlで統一することを事前に告知する
- Perlが苦手な人には自分で勉強してもらう
- ただし、Perlの達人になる必要はなく、基礎的な知識で解ける問題であることを伝える
- 出題する問題から、必要になりそうな知識をある程度伝えておく (文字列関数の一覧やファイル入出力の方法など)
時間に余裕を持たせる
- Perlに不慣れな人に合わせた解答時間を設定をする
- 早く終わった人にはいったん業務に戻ってもらう。もしくは別パターンの解法を考えてもらう
とにかく頭の中にあるものをアウトプットしてもらう
- 頭の中でロジックはできているのに、どうしてもそれがPerlで解けないのであれば、フローチャートや文章などで頭の中にあるロジックを表現する

ところで上の変更点の中で「なぜPerlに統一？」と思った方がいるかもしれません。
これはできなかった3人にインタビューしたところ、「コンテストなら言語は統一しておいた方が良い」「事前に伝えてもらえれば準備できる」というコメントをもらったためです。
最悪、Perlのせいでプログラムとして表現できない場合はフローチャート等でアウトプットしてもらうので、全く評価不能ということにはならないはずです。

これで解けなかった理由を言語のせいにはできなくなります。
また、次回はFizzBuzzよりも難しい問題を出そうと思っているので、もしその問題を全員が解けたら「FizzBuzz問題も実は大丈夫だった」という保証(?)にもなるのではないでしょうか。

意外と知られていなかったFizzBuzz問題

話は変わりますが、コンテストに参加した全員に「FizzBuzz問題を知ってましたか？」という質問をしてみました。
その結果は・・・

知っていた。以前に解いたこともある → 0人
知っていたが、解いたことはなかった → 2人
知らなかった。今回初めて知った → 8人

となりました。
おいらは「知っていたが、解いたことはなかった」の一人です。
ネット上では「知ってて当然」みたいなコメントもありましたが、これが現実？それともおいらの職場だけでしょうか？？

第１回のふりかえりと第２回社内プログラミングコンテストに向けた改善ポイント

それでは最後に第１回社内プログラミングコンテストをふりかえり、次回の改善ポイントを考えてみたいと思います。

良かった点

メンバー各自のスキルや個性、クセが如実に現れた
全員がシンプルでわかりやすいプログラムを「良いプログラム」と感じることがわかった

悪かった点

抜き打ちで実施したことにより、ロジック力やコーディング力以外のスキル(調べるスキル等)が要求された
言語の得意、不得意が結果に影響してしまった
バリデーション(入力値チェック)は暗に要求する必要はなかった
- バリデーションは別の大きなロジックを持ち込むことになり、フォーカスすべきポイントが絞り込めなくなる恐れがあるため
- ただこれはもともと、与えられた仕様を見てその仕様だけに集中してしまう人と、「あれ？こんな入力がきたらどうするの？」という異常系入力に対しても考慮ができる人の有無を確認したい、という意図があった