  |
はてなキーワード: FizzBuzzとは
返事全部読ませてもらった。すごく丁寧に説明してくれてるのはありがたいし、そこは本当に感謝してる。ただ、ここまでやりとりして感じたのは、結局、議論のすれ違いが大きいなってことだったので、最後に自分の立場をまとめておく。
元々指摘したかったのは、冒頭の文章が流れとして読みやすいか、論点が自然に展開されてるかって点だった。でも返事では、記事全体の主題とかスコープの話にフォーカスされていて、「読者にとってどう受け取られるか」の部分には正面から答えてもらえなかった印象がある。
また、今回のやりとり全体で感じたのは、こちらの指摘に対して繰り返し「そういう意図ではなかった」という形で読み手の読解力に対する応答に終始していたことだ。
たとえば：
これらはそれぞれ表現について「意図の説明」はされているものの、「どう伝わったか」「どのようにズレが起きているか」にきちんと向き合う回答ではなかったと感じている。おそらく無意識的なものだとは思うけど、こちらの指摘がまず誤っているという立場に立った読解があったんじゃないかと思う。
個々の指摘については、返信を見る限りこちらの意図を説明する意味はないと思うので、受け取った通りでいい。
ただ、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週間かかってもできないという人が大勢いるのだ。
「サボってたのでは？」「不合格になりたかったのでは？」とかではなく
「辺境のド田舎なのでは？」「超絶ブラック求人なのでは？」と、
裏があるんじゃないかと考えるもしれないが、そのような救いはない。
