- FizzBuzz問題が採用面接の定番になった直接のきっかけは、2007年に公開された2本の技術ブログ記事だ。
- 体系的に設計された適性試験ではなく、個人の観測から広まった業界慣習である点が、この問題の性格を決めている。
- 出典で確認できた事実と、対策が出回った現在も残る理由の見立てを、順を追って整理する。
2007年1月24日と、その1か月後の2007年2月26日。この2つの日付が、FizzBuzz問題という言葉の運命をほぼ決めています。
転職活動中のエンジニアも、採用側で選考フローを設計する立場の人も、一度はFizzBuzzという単語を目にしたはずです。プログラマの基礎的な実装力をふるいにかけるテスト、という説明が広く流通しています。
私が引っかかったのは、その説明の出どころでした。学会が定めた適性試験でも、業界団体が策定した標準でもない。調べていくと、たった2本のブログ記事から広がった慣習だったことが分かります。この記事では、確認できた一次情報だけを並べたうえで、慣習が今も残っている理由を考えます。
この4コマで描いたのは、IT現場で実際に起こりうる典型的なすれ違いです。出題側は基礎的な実装力を確かめたつもりでも、受験側にとっては事前に何度も反復した既知の問題になっている。同じ設問を挟んで、両者が見ている景色が違う状態です。
選抜のための設問は、公開された瞬間から解答例が蓄積していきます。FizzBuzzは特に単純で、記事にも書籍にも載りやすい。結果として、初見の反応を見る道具としての切れ味は落ちていきます。これは出題者の怠慢ではなく、公開情報を前提にした選考が構造的に抱える性質だと私は見ています。
しかし面接から消えないのは、短い時間で共通の話題を作れるという別の効用があるからではないでしょうか。答えの正誤よりも、書き方や説明の仕方に会話の糸口が生まれる。4コマの結びは、そのあたりの実感を一言にまとめたものです。
FizzBuzz問題とは何を書かせる問題なのか?
FizzBuzz問題とは、1から100までの数を順に出力し、3の倍数ではFizz、5の倍数ではBuzz、3と5の両方の倍数ではFizzBuzzに置き換えて出力するプログラムを書かせる課題です。出題文の原型は、2007年1月24日にImran Ghory氏が自身のブログで示したものが確認できます。
原文の課題文は、1から100までの数を出力すること、3の倍数ではFizzに、5の倍数ではBuzzに置き換えること、3と5の両方の倍数ではFizzBuzzに置き換えることを求めています。追加の条件は一切ありません。
実際の出力は、次のように始まります。
1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz
必要な知識は、繰り返し処理、条件分岐、剰余の計算の3つだけです。特殊なライブラリもデータ構造も要りません。だからこそ、入門者向けの練習問題としても、選考用の設問としても扱いやすい形をしています。
元は子供の言葉遊びなのか
FizzBuzzという名前の由来については、英語圏の子供が割り算を学ぶための言葉遊びが元になっているとされます。英語版Wikipediaも、Fizz buzzを割り算を教えるための子供向けの言葉遊びとして説明しています。
ただし、その遊びがいつどこで生まれたのかを示す一次資料は、私が調べた範囲では確認できませんでした。Wikipediaが挙げている年代付きの参考文献は、2002年刊行の数遊びの指導書1冊のみです。つまり、遊び自体は2000年代初頭には存在していたと言えても、起源の年代を断定できる材料はありません。
FizzBuzzはなぜ採用面接に広まったのか?
FizzBuzzが採用面接に広まったきっかけは、2007年に相次いで公開された2本のブログ記事です。書いたのは、業界団体でも大学でもなく、現場で採用に関わっていた個人の技術者でした。
1本目は、2007年1月24日のImran Ghory氏の記事です。プログラマの選考で極端に簡単な問題を使う意義を説き、その具体例としてFizzBuzzを提示しました。2本目は、その1か月後の2007年2月26日にJeff Atwood氏がCoding Horrorに書いた記事で、Ghory氏の主張を紹介しながら、応募者の基礎的な実装力を事前に確認すべきだと論じています。
| 比較観点 | Imran Ghory氏の記事 | Jeff Atwood氏の記事 |
|---|---|---|
| 公開日 | 2007年1月24日 | 2007年2月26日 |
| 記事の役割 | FizzBuzzを選考に使う発想と課題文を提示 | その発想を紹介し、広い読者層へ拡散 |
| 主張の根拠 | 自身の面接経験に基づく観測 | 複数の技術者の採用経験の引用 |
| 示された数値 | 上級者を名乗る人でも10〜15分以上かかる例がある | 引用として、200人に199人という表現が登場 |
ここで押さえておきたいのは、どちらの記事も統計調査の報告ではないという点です。Ghory氏の記述は自身が面接で見てきた範囲の話であり、Atwood氏の記事も他の技術者の採用経験を引く形を取っています。標本数も抽出方法も示されていません。
その後、FizzBuzzは面接対策の書籍にも取り込まれていきます。英語版Wikipediaが面接での利用例として挙げている参考文献には、2014年刊行のJava面接対策書や、2016年のForbes掲載記事が含まれています。個人のブログから始まった話題が、10年ほどで参考文献に載る位置まで移動したことになります。
業界標準というより、よくバズった提案がそのまま定着した、という順序ですね。
出典をたどると、意外と地面が薄い慣習は他にもあります。
FizzBuzzが解けない人が多いという話は、どこまで裏が取れるのか?
FizzBuzzが解けない応募者が大量にいるという有名な主張は、統計的な調査ではなく、個々の技術者が採用の現場で見た印象を述べたものです。ここを混同すると、話が一気に乱暴になります。
Ghory氏は自身の記事で、情報科学の学位を持つ卒業生の多数がFizzBuzzを書けないという趣旨を述べ、上級者を名乗る人でも10〜15分以上かかる例を見たと書いています。いずれも面接での見聞であり、母集団の定義も回答率の集計も示されていません。
Atwood氏の記事に登場する、200人に199人は書けないという強い表現も、他の技術者の言葉として引用されたものです。修辞として読むのが妥当な数字であり、測定値として扱えるものではないと考えます。
同じ時期に採用の現場を語った文章として、C/C++の技術者を多数採用した経験を持つDan Kegel氏の解説もあります。そこでは、修士や博士の学位を持つ応募者を含めて、基本的なプログラミング課題で行き詰まる人の割合が驚くほど大きいと述べられています。これも本人が数百人を面接した経験からの記述であり、調査報告ではありません。
私が調べた限りでは、FizzBuzzの正答率を体系的に測った公開調査は見つかりませんでした。同様に、現在どれだけの企業がFizzBuzzを出題しているかを示す定量データも確認できていません。この点は正直に、裏が取れなかったと書いておきます。
対策が出回ったFizzBuzzは、今も選別の道具として機能するのか?
対策が広く出回った現在のFizzBuzzは、初見の実装力を測る道具としては、公開当初ほどの働きをしていないと私は見ています。テストは、答えが出回った瞬間からテストではなくなっていくからです。
この見立ての根拠は単純です。2007年の時点でFizzBuzzを知らずに面接に臨んだ人と、解答例が無数に検索できる状態で臨む人とでは、同じ設問が測っているものが違います。前者では初見の思考が見え、後者では反復した記憶が見えます。
FizzBuzzがどれほど共通の話題になったかを示す例として、GitHubにFizzBuzz Enterprise Editionというパロディのリポジトリがあります。企業向けソフトウェアの設計パターンを大げさに適用してFizzBuzzを実装するという冗談で、23,000件を超えるスターが付いています。ネタとして成立するのは、読み手の側に前提知識が共有されているからです。




パロディが23,000スターを集める時点で、もう共通言語の側に回っているんですよね。
現代のコーディングテストとは何が違うのか
実際の選考現場では、FizzBuzz級の設問だけで判断を完結させる形からは離れてきているようです。公式に選考内容を説明している例として、LINEヤフーの公式採用noteが2024年11月7日に公開した記事があります。同社は選考の初期段階でコーディングテストを実施し、正しいアルゴリズムを導けるか、計算量が効率的か、可読性や保守性に配慮できているかを見ていると説明しています。
正解にたどり着いたかどうかだけでなく、どうアプローチしたかを重視する、という趣旨も同記事で述べられています。これは、単純な足切り用の設問とは設計思想が異なる考え方です。
| 比較観点 | FizzBuzz型の設問 | 現代のコーディングテスト |
|---|---|---|
| 主な目的 | 基礎的な実装ができるかの足切り | 設計・効率・思考プロセスの評価 |
| 所要時間の目安 | 数分程度で書き切れる分量 | 数十分から数時間の課題も含む |
| 評価の焦点 | 動くコードが書けたかどうか | 計算量、可読性、保守性、進め方 |
| 対策の影響 | 解答例が出回り、初見性が失われやすい | 問題が長く複雑なぶん、丸暗記が効きにくい |
それでも消えないのはなぜかという見立て
ここからは事実ではなく、私の見立てです。あくまで外から公開情報を追ってきた立場からの推測として読んでください。
FizzBuzzが今も面接の話題に上るのは、能力を測る道具から、共通言語としての合図へ役割を変えたからではないかと考えています。この単語を出せば、出題側も受験側も何が起きようとしているかを即座に理解できる。説明のコストがほぼゼロで済むわけです。
道具として見た場合、選抜の精度は落ちました。それでも、会話の入り口を作る短い儀式としては、まだ機能している。習慣として定着したものは、当初の目的が薄れても形だけ残ることがあります。サービスの世界でも、機能で選ばれたものが習慣で生き残る例は珍しくありません。FizzBuzzもその一例に見えます。
生成AIの時代にFizzBuzzのような設問は何を測れるのか?
生成AIが即座に解けてしまう設問で何を測るのか、という問いは、FizzBuzzに限らず選考全体に投げかけられています。答えを出す速さではなく、答えに至る過程をどう見るかが論点になりつつある、というのが現状の整理です。
採用側の意識の変化を示す公開データとして、レバテック株式会社のレバテックIT人材白書2025があります。IT人材の採用に関わる担当者1,000人と、20〜59歳のIT人材3,000人を対象に、2024年11月22日から29日にかけて実施された調査です。この中で、生成AIの出現によりエンジニアに求めるスキルが変化したと回答した採用担当者は約4割にのぼりました。
ただし、この調査はFizzBuzzのような設問の是非を扱ったものではありません。求めるスキルの重点が動いているという事実と、個別の設問が有効かどうかは別の話です。ここを飛び越えて結論を出すことはしません。




設問が古くなったのではなく、設問に期待する役割のほうが動いた、という順序で見たいところです。
FizzBuzzの定番化から学べることは何か?
FizzBuzzの20年近い歩みが示しているのは、選抜のための設問が公開されると、遅かれ早かれ対策が蓄積し、初見性が失われていくという流れです。この教訓を今のトレンドに重ねるなら、次に同じ道をたどるのは、生成AIの利用を前提にした課題そのものだと予想しています。良い課題ほど早く共有され、良い解答例ほど早く出回るからです。
とはいえ、悲観する必要はないと考えています。過去の慣習がどう摩耗したかを知っている側は、次の設計で同じ穴を避けられます。いま自分の会社で使っている選考課題は、何年前に作られたものでしょうか。その課題が今も見たいものを見られているか、一度だけ確かめてみる価値はあります。
- FizzBuzzは2007年の2本のブログ記事から広まった慣習であり、体系的に設計された適性試験ではない。
- 解けない人が多いという有名な主張は、個人の面接経験に基づく観測であって統計調査ではない。
- 対策が出回った現在は、測定器というより共通言語としての合図に近い役割を担っていると見ている。
次のアクションを1つだけ挙げるなら、選考課題や社内の技術チェックに使っている設問について、出典と作成年をメモに書き出してみてください。地面の厚みが分かると、更新すべき順番も見えてきます。
よくある質問
-
QFizzBuzz問題の正しい出題ルールを教えてください。
-
A
1から100までの数を順に出力し、3の倍数はFizz、5の倍数はBuzz、3と5の両方の倍数はFizzBuzzに置き換えるのが原型です。2007年のImran Ghory氏の記事に示された課題文が、この形をそのまま述べています。追加条件や入力の指定はありません。
-
QFizzBuzzを最初に面接で使ったのは誰ですか?
-
A
最初の利用者を特定できる資料は見つかりませんでした。公開情報として確認できるのは、2007年1月24日にImran Ghory氏が選考への活用を記事にしたこと、その1か月後にJeff Atwood氏が取り上げて広く知られるようになったことまでです。それ以前の利用実態については断定を避けます。
-
QFizzBuzzが解けないエンジニアが多いというのは本当ですか?
-
A
統計的に検証された話ではありません。よく引用される数字は、いずれも個人が採用面接で見た印象を語ったものです。正答率を体系的に測った公開調査は確認できていないため、特定の属性の人が解けないといった評価に使うべきではないと考えます。
-
QFizzBuzzとコーディングテストの違いは何ですか?
-
A
見ようとしている範囲が異なります。FizzBuzzは数分で書き切れる分量で、動くコードが書けるかに焦点があります。現代のコーディングテストは、公式に選考内容を説明している企業の例を見る限り、計算量の効率や可読性、解き進める過程まで評価対象に含めている点が特徴です。
類似のIT考察
| hoge・foo・barとは?サンプルコードで使う理由を解説 | サンプルコードの仮名がなぜ定着したのかを、業界慣習の成り立ちからたどる考察。 |
| なぜパスワードは半角英数字なのか?残る昭和の理由 | 技術的な制約が消えた後も入力ルールが残り続ける理由を掘り下げた記事。 |
| なぜソフトはv0.9のまま1.0にならないのか | バージョン番号の付け方に表れる開発文化と心理を読み解く考察。 |
この記事と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| アルゴリズム | FizzBuzzが最小構成で問うている、正解にたどり着く手順そのもの。 |
| 条件分岐 | 3の倍数か5の倍数かを判定する部分で必ず使う基本の制御構造。 |
| ループ | 1から100まで順に処理を回すために欠かせない繰り返し処理。 |
| アナグラム | FizzBuzzと並んで、エンジニア面接の小問として名前が挙がる題材。 |
| ジェネレーティブAI | この種の設問が何を測れるのかという問いを、あらためて生んでいる技術。 |
【出典】参考URL
https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/ :Imran Ghory氏の記事の公開日、課題文、選考経験に基づく記述の根拠
https://blog.codinghorror.com/why-cant-programmers-program/ :Jeff Atwood氏の記事の公開日、Ghory氏への言及、200人に199人という引用表現の根拠
https://en.wikipedia.org/wiki/Fizz_buzz :子供向けの言葉遊びとしての説明、ルール、面接での利用例に関する参考文献の根拠
https://www.kegel.com/academy/getting-hired.html :Dan Kegel氏による採用経験に基づく記述の根拠
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition :FizzBuzz Enterprise Editionの内容とスター数の根拠
https://note.com/lycorp_recruit/n/n985359237340 :LINEヤフー公式採用noteによるコーディングテストの実施段階と評価観点の根拠
https://levtech.co.jp/research/2383985/ :レバテックIT人材白書2025の調査概要と、求めるスキルが変化したと回答した割合の根拠

コメント