結論だけ、書く。
要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。そして知らないから。
さて、まずはこの問題解こうか。制限時間5分。
タイトル: Ants
問題文: 長さL cmの竿の上をn匹のアリが毎秒1cmのスピードで歩いています。アリが竿の端に到達すると竿の下に落ちていきます。また、竿の上は狭くてすれ違えないので、二匹のアリが出会うと、それぞれ反対を向いて戻っていきます。各アリについて、現在の竿の左端からの距離xiはわかりますが、どちらの方向を向いているのかはわかりません。すべてのアリが竿から落ちるまでにかかる最小の時間と最大の時間をそれぞれ求めなさい。
制約: 1≦L≦106 1≦n≦106 0≦xi≦L
出典: プログラミングコンテストチャレンジブック(p.23) / 元はPOJ No.1852
「え、なにこれ。探索幅発散するの早すぎて無理じゃね?」って思ってるうちにタイムアップ、って人も結構居るんじゃないかなー。
知ってれば一瞬、知らなければ問題の得体知れなさに惑わされず筋道立てて思考し、きちんとコードへ落とすのが重要。程度の差はあるんだけど、FizzBuzzと似た性質を持つ問題だと思う。
「FizzBuzz書けない奴m9(^Д^)ﾌﾟｷﾞｬｰ」と考える背景にある憂いの感覚はもちろん分かる。プログラミング出来ずにシステム開発に携わるよりは、プログラミング出来たほうがいい。問題のモデル化、開発、運用の全てにおいて精度が高まるし、例えばマネージャなど相談相手と考えると同じ思考回路を共有出来る人のほうが話通じるだろうから※1。
けど、(意識的にか否か別にせよ)知識問題としてFizzBuzzを扱ってるなら、そこに大した意味はないと思う。
私はこれまで、いきなり人前でホワイトボード上にコードを書くよう求められ、その場でフリーズする人をそれなりに見てきた。日常的に(割と)優れたコードを書いてると私が知ってる人でも、そういう場合があった。とりわけ、いきなり問題を突きつけると「恥ずかしい間違い方をしちゃうかもしれないから白紙で出そう」って思う人が一定居るかも、とも思う。そこのストレス耐性を見たければ、他のやり方がいくらでもあろう。
だから、突発出題スタイルにはもうちょい工夫が必要なんだろうと思ってる。
より具体的には、以下の3小問に分割するとか。
- 問題が求めているものを把握し、自身の言葉で説明出来るか(モデル化の入力部分)
- 問題をプログラムで表現するのにはどのようなコードを書けば良いか分かりやすく説明出来るか(モデル化の出力部分。自然言語的認識からプログラムに落とす際にフィットさせなければならない箇所を考えられるか)
- 実際のコードを正しく書けるか(実装力。言語のシンタックスや設計思想に基いて適切なものを書けるか。場合によっては組み込み関数や標準クラスライブラリを適切に利用出来るか)
前置きが長くなった。「仕事で書くのが、アルゴリズムを考えずに書けるプログラムばっかで」と嘆くのもいいんだけど、アルゴリズム試験をやってみて結果が芳しくなかったとしてその理由や背景をどう捉えるかという話が本題なのでそろそろ書いてみる。
= 要らないんだよ
普通の職業プログラマなら、「優れたアルゴリズムを実装したプログラム」と「お金になるプログラム」が違うってことは分かってるはず。
もちろん「優れた作りでお金になるプログラム」も一定は存在する。継続性を重視する多くの企業において、こういったものが生まれるチャンスは平均レベルの底上げによるものか、さもなくばごく一握りのスタープログラマによる(当然属人性が高い)。
もうちょい丁寧に書いとこう。
平均的レベルのプログラマが開発し保守していく上で、主に問題解決の方法は「プログラムの効率を高めて解決」と「ハードウェア性能や数でゴリ押して解決」の二つある。
ハードウェアにお金をかけるか、プログラム(そしてプログラマ)にお金をかけるか。プログラムにかけるにしても、内製するか外部のものを利用するかという選択肢がある。
ここに関して、多くの企業の意思決定としては「なるべくハードウェアを並べて解決。それで解決出来ない部分は一部のスタープログラマにより高性能なものを作るか、外部の安定したものを利用する」というのが経済的に合理解となるので、そのように運営される(こうならないのは最初から社員に対して高い平均プログラミング能力を求めるように設計されている企業か、かなり広いチャレンジの幅を設けている企業ぐらい)。そしてスタープログラマでさえバランスとアベレージを求められる(そうでないと見積りが立たない)。
だから多くの職業プログラマはプログラムを実際に書けることよりも、問題をモデル化しシステム設計へ落とし品質を管理するタスクへ注力することになる。使わない力は衰えるので、仕事で使うごく一部のコード以外をどんどん書けなくなっていく。使わないビジフォンの転送方法を忘れることと大差ない。
企業から見ると「創意工夫の余地」は多くの場合実装差を生み運用上のリスク源となるため、単純に考えれば存在しないほうが良い。以前やったことをなるべく変更せず、多少いじる程度で新たな機能を実現出来るならそれに越したことはない。つーかぶっちゃけコードなんて書かずに済んで誰でもメンテ出来るならそのほうがいい。
だから職場であなたの周りには凄いプログラマがほとんど居ない。twitterのTL上にいっぱい居る。そりゃそうだ。あなたがそういうクラスタをフォローしてるからだ。
= FizzBuzz書けない人がいっぱい居る職場だと分かったら
職場の多くの人がFizzBuzzを書けないことに愕然としたなら、次に取るべき行動は「他人を変えるか、自分を変えるか選ぶ」ことだよね。
とにかく、自分の環境が"アルゴリズムをあまり考えない環境"なんだと気付いてそれが問題だと思ったら、"アルゴリズムを考え続ける"ような機会を自ら作るしかない。そうしないと衰える一方。そしてこれは必ずしも会社でやる必要はなくて、個人のプログラミングの中でだって十分出来る。
他の人に対して「必要無いからやらないなんて、そんな低レベルじゃどうせ必要になってもロクに出来ない」と強く感じたら、それを変えるための努力をするのも良い。会社のありかたを変えようというのだから一筋縄では行かないだろうけど、そのチャレンジ自体を無視されない会社ならば何かしら得られるものがあるはず。ひとまず社内でアルゴリズムに関する勉強会を始めるのも良いかもしれない。
そこまでするモチベーションが無いなら、とりあえず職場では口をつぐみtwitterで愚痴っとくのも良いかも。ただ、忘れちゃいけないのは多くの場合、彼らがFizzBuzzを書けないのは、おそらく彼ら自身が社会的価値を生む上で必要ないからであって彼らが無能だからではないということ。この程度で「アルゴリズム考えられる俺SUGEEE」とミサワ化してしまったら、多分あなたの人生にとって損だ。
それよりは状況を単純に事実として受け止めつつ、会社以外で優れたアルゴリズムに触れる機会を作るのが良いかもしれない。特に現代では勉強の材料になるコードが、読み尽くせないほど溢れてる。
もっとも、この状況を本気でムリと思うなら転職というのも一手。自身が所属する組織自体を変えるにはかなりのパワーがかかる。きっと自分ひとりで出来るものじゃなくて、周囲や上長と問題意識を共有するところから地道な努力をしていかなきゃいけない。自分がそこまでする理由があるか、価値を感じられるか、自問してやっぱり無理だったら他の環境でやったほうがいいのかもしれない。
例えば会社に所属するプログラマがプログラミング自体を割と好きで、個人的な時間にコードを書いているような会社へ。世の中、この点であなたにマッチする企業は結構ある。Dな会社とかGな会社とかCな会社とかZな会社とか。あ、ウチもだと思います #ステマ
このへんの会社には、コードを書きたくてSIerから移ってきたという人も結構居て、バックグラウンドがかなり幅広くカオスなので面白い。
一方、少数精鋭で本当に困難な問題をアルゴリズムによって解決することをビジネスとする会社も存在する(ﾋﾟｰ社とかはそういう感じかな)し、自分でそういった会社を作ってしまうというのも手だろうし。
= 知らないんだよ
ちなみに、HelloWorld終えてすぐさま自分の書きたいプログラムを書き始める人々は、一生FizzBuzzに出会わなくても不思議じゃない。
私が初めてFizzBuzzに出会ったのは2年前の7月。虎ノ門で行われたLL TigerってLLイベントの小飼弾氏によるPerl6の紹介中でだった。
「Perl6でもFizzBuzz書けるよ!」(会場笑)
「実行に3秒かかるけどね!」(会場爆笑)
ってノリを見て、「ああ、そういうものなんだ」と思った覚えがある。
思えばプログラミングに触れ始めてから16年(ぐらい)、FizzBuzzと無縁に生きてた。
= ということで
要らないし知らないから、職業プログラマがFizzBuzz書けなくても不思議じゃないね。
= あ。
冒頭の問題の解答は、プログラミングコンテストチャレンジブックをお買い求めの上確認下さい。普段の仕事では使わないけれども考えて面白い、そんなアルゴリズムと問題解法が詰まった良い本です。
-- 脚注
※1: ちなみに私自身は、技術分からないマネージャの下で働くぐらいなら余程のことが無い限り会社やめます。
0 件のコメント:
コメントを投稿