  |
はてなキーワード: fizzbuzzとは
具体的には、Xでちょっと話題になってた若手育成方法なんだけど、今は特にムリ（時代にそぐわない）かなあというやつ。
（特にITエンジニア界隈に限った話でも無くて、回路設計なんかでも昔は良く見た）
以下の手法なんだけど、これ昔は良く見たし、今もまあまあ見るんだけど、周りのフォローが無いともう結構厳しい。
・ベテランが2,3時間くらいで終わるタスクを3日設定でアサインする
・タスクの説明をする時に細かところまで話さない。大枠と、完了条件の詳細だけ伝える。その過程で仕様が曖昧な時に自然に聞けるスキルを鍛える。
・20分自分で考えてわからなかったら聞きにこい。その時は「今何に悩んでて」「どういうアプローチで解決させようとしてるのか」を 両方説明せよ、と伝える。目的と取るべき手段を相談できる癖を叩き込む。
・変な実装し始めてたら、「そもそもこのタスクは何をするんだっけ？」と伝えて、セルフで脱線を検知できるような感覚を身につけさせる。
え！こんなのスゴイ優しいじゃん、良い教育方法じゃんって思うかもしれないんだけど、コレ第三者目線だとそうかもだけど、若手目線だと地獄なんだよね。
これ、「3の倍数はFizz、５の倍数はBuzzって出すようなの作っといて。３時間くらいで」みたいな感じの指示になるんだよね。
で、ぼちぼち実装してたら「あー、そこはそういう関数にするんだ、このタスクの目的ってなんだっけ？」みたいな口出ししてくんだよね。
最悪だよね。
指示出し側にはおそらく正解があるんだけど教えてもらえなくて、自分のやり方で実装してると口出ししてくんの。
さらに、仕様が曖昧で、聞くとそこしか答えてくれない（書いてないけど、教育目的だと先回りして詳細を補足したりしないと思うので）
それで「悩んでること」と「どう解決しようとしてるか」をセットで聞きに来いって、ほぼ完成形で聞きにこさせんだよね。
例えば、「３の倍数かつ５の倍数の場合の仕様に悩んでまして」「FizzBuzzと出すつもりです」みたいな。
若手が効きたいのは「指示された以外の詳細で決まっていることはありますか？」なんだよね。
例えば、「１～１００までの間で出力するようにしとくか」みたいな若手が実装してたら、たぶん「あー、依頼したタスクの目的はなんだっけ？」とか割り込んでくるんでしょ。
なら最初から「任意の数に対して対応可能な形で実装しておくように、整数以外が入る可能性あり」みたいな条件付けて出しとけや。
みんな余裕があったから。
「あ、それ教育目的だからガンガン聞きに行って良いんだよ、期待されてるってことだよ」みたいなフォローを入れる同僚とか上司が必ずいた。
あと、そもそも同期がわりと数が居て、昼めし食いながら愚痴を言いあったりすることで、あーどっこもそんな感じなのね、という納得感があったから。
今はどっちもない。
若手をバカにしない。
前述の、ベテランと若手を明確に区別した上で、能力をバカにしてないとできない手法なんだよね。
明確に「これは教育です」「勉強会です」という時間を設けてやるのであれば、パワハラにはならない。
勉強会で、クイズです正解は何でしょう？なら別に問題無いから。
例えば「俺がこの仕様を実装するときに、例えばこんな感じで実装進めるんだけど、タスクの目的から乖離してきたなと思った段階で指摘してみて」みたいなやつ。
権力勾配がある状態で、権力のある側が無い側に対して目的と情報を伏せるから。
「そういう常駐先が多いので、その訓練をします」と宣言して実施しててもご時世的にキツイのに、おそらくそういう宣言すらしてないでしょ。
UNIQLOで冬服選んできてって言われて、外出用、全部で２万以下ねって言われてる感じね。
で、じゃあアウターでも買うか、ヒートテックもいるかなーって選んでたら「あー、そういう色選ぶんだ？」みたいに言われるヤツね。
え？なんか指定ありましたっけ？って聞くと、いやいや外出用だよ？目的考えてみてよ？みたいな正解言わないヤツね。超ウザいでしょ。
教育目的として、これを明確に宣言して結果に差が出ること無いよ。
勉強なのでベテランと違う進め方してるし、クイズだから正解伏せてるって、ちゃんと説明できるから。
ベテランと違って俺は嫌がらせを受けているっていうのがハラスメントだと感じる理由なんだから、嫌がらせじゃなくて目的が明確にあると伝えるだけでずいぶん違うよ。
（ちなみに、コストをかけて勉強会を開催するのが一番イージーです。IT業界じゃないけどウチは余裕が無いからこそ完全教育目的の時間を取ってる）
ただまあ、採用コストかけて雇った若手エンジニアが辞めるというフィードバックを受けてなお手法変えないんだから信念があるんだろうし、それで辞めない若手が入ってくると良いね。
https://twitter.com/fumokmm/status/1703977187903426995
「むしろこれが正解」「速度を出すときにはこういうことをする」「作ろうとする姿勢が大事」
とか逆張りで褒めてるやつが多いけど、普通にこんなんダメだから
何がダメって、FizzBuzzを教えるタイミングって100%がfor文とif文を教えた直後なんよ
まずfor文を教えて「1から100までの数字を出力してみましょう」っていう問題が出されるわけ
そのときにfor文を使いこなせなくてSystem.out.printlnで書くやつはいっぱいいるけど問題無い
ちゃんと教える側が「for文を使えば簡単かつ正確に書けますよ」って形でfor文を教える
その次に「if文を使って偶数のときだけ出力しましょう」とかを教える
そうすることでfor文の中でif文を使えば繰り返し処理を制御できるってことを教える
「FizzBuzzっていう英語圏で遊ばれるゲームがあるんだよ」
っていう形で出題するわけ
ユーザーに数字を入力させてFizzBuzzを判定させる、とかのゲームを作らせるのがいいんだけど
「まずは単純にFizzBuzzの正解を表示させてみましょう」
っていうコンテキストで出題されるわけ
そのときの回答としてSystem.out.printlnを大量に書くようなやつがいたら、もう一回for文からやり直せっていうのが正解
この回答が合っている要素なんて一ミリも無い
https://qiita.com/app_js/items/a78e0605af702b155efc
この記事読んだ。
Paizaの対応の良し悪しやこの人の考えや不満については今回は触れない。
一人のITエンジニア採用担当者、また同時に一人のITエンジニアとして生成系AIに対してどう触れるべきか書いておく。
まず、業務で生成系AIを利用するのは会社のルールの範囲で好きにやれば良いと思う。
問題は転職のフェーズであり、ここでは能力をチェックされているわけだから、生成系AIの回答でコーディングテスト通過です、となるわけがない。
ソフトウェア開発は複雑であり、AIは間違った回答や遠回りな回答もするわけだから、生成系AIを使うにしても結局真偽を確かめられる能力は必要だよね。
コーディングテストで生成系AIを使うというのは「私はそのような最低限の考える力も有りません」と言っているようなものなので、企業側がほしい人材とは言えない。
最近のコーディングテストサービスでは入力内容を記録しているのでコピペしたかどうかは分かる。
なので生成系AIで回答しているような場合は企業側はある程度検知できる。
もちろん誤検知もありえる。サービス(Web)上ではなくIDEなどで回答を作って貼り付けることもあるだろう。
そのため、企業はコーディングテスト通過後の面接で回答に対して深掘りすることが多い。
生成系AI回答で何も考えていない人はここで脱落する。
企業によってはコーディングテストサービスではなくホワイトボードなどでライブコーディングさせる場合もあり、そもそも生成系AIが使えないこともある。
ワイ：
#include<stdio.h> int main(){ for(int i = 1;i <= 100;i++){ if(i%15 == 0){ printf("FizzBuzz\n"); }else if(i%3 == 0){ printf("Fizz\n"); }else if(i%5 == 0){ printf("Buzz\n"); }else{ printf("%d\n",i); } } return 0; }
ワイ：考えるのが面倒くさいから
Boi：ここまとめられるでしょ
#include<stdio.h> int main(){ for(int i = 1;i <= 100;i++){ if(i%3 == 0)printf("Fizz"); if(i%5 == 0)printf("Buzz"); if(i%3 != 0 || i%5 != 0)printf("%d",i); printf("\n"); } return 0; }
Boi：ああっ
ワイ：ww
FizzBuzzってアメリカのIT企業の採用試験で、応募者がコンピューターサイエンスの学部をでてたり、上級プログラマーの肩書きなのに簡単なコードも書けないってエッセイが元だったね。
FizzBuzzプログラムが書けないプログラマがいる、という話がされるとき
ソラで紙に書けることを想定されているらしく、「できる必要がない」とか「できるべきだ」とか言われる。
プロジェクト作成済み、ソースファイル作成済み、Visual Studio起動済み、実行ボタンをクリックするだけでビルドができる状態、
という状態で1週間かかってもできないという人が大勢いるのだ。
「サボってたのでは？」「不合格になりたかったのでは？」とかではなく
「辺境のド田舎なのでは？」「超絶ブラック求人なのでは？」と、
裏があるんじゃないかと考えるもしれないが、そのような救いはない。
てほしい。
プログラミングを理解できない人はいます。いい加減この事実を認めて下さい。
こういう話になると、やれ「教え方が悪い」だとか、やれ「順序立てて学べば誰でも理解できる」などという輩が出てきますが、それは事実に反します。
まず、プログラミングは手順さえ覚えれば誰でもできるようになると言うものではありません。プログラミングを理解するには、一定レベルの論理的思考能力を要します。それが身に付いていない人には無理です。また、どんなレベルの人でも、プログラミングで分からないことは出てきます。プログラミングができる人は、そういう時に、
といったことをして解決する力があります。そういう試行錯誤をしない人や、複雑だったり抽象的な概念を突き詰めて考えることをしない人に、プログラミングを理解するのは不可能です。
たとえば、再帰関数が分からないとしましょう。具体的に何が分からないのかは人によって異なります。たとえば、
など。これらを解決するには、自分で仕組みを突き詰めて考えたり、コードを書いてデバッグしてみたり、調べたり人に聴いたりするしかありません。講師が気の聞いた喩え話などをすれば、たちまち疑問が氷解するなどということはあり得ません。
また、一口に「プログラミングを理解する」と言っても、そのレベルは様々です。
最初の2〜3程度が「自分の思うプログラミングの全て」な人が、軽々しく「プログラミングは誰でも理解できる」などと思わないでいただきたいのです。それは実用上は全然足りていません。サンプルコードをググりながら、やっとこさVBAで複数のエクセルファイルを集計できる程度の人が「プログラミングできる」気になっていては困るのです。
上記の大部分は、自分のプログラムを他人に見せるつもりのある人なら十分に習得しておく必要があります。ましてや、プログラミングで飯食おうと言う人間が、FizzBuzzに毛の生えたようなコードを読み書きするのに精一杯で、効率や保守性に気を配れないのは論外です。
上記の特に後半に書いたようなことは、誰にでもできることではありません。ちょっとしたコツや方針を守れば機械的にこなせるというものではなく、技術力の高い人でも熟考を要することです。彼らは、そうした高度なことを正しく考える力があるから、技術力が高いのです。そういう力は、誰かに用意してもらったカリキュラムを受動的にこなすだけではまず身に付きません。
