July 22, 2011
フェイスブックでエンジニアをやっていた方の面白い話があった。
フェイスブックのエンジニアで史上ベスト３に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。
という話
コードの質がフェイスブックの強みであったことはないが、２００７年のフェイスブックのコードはグローバル変数とextract関数にまみれたヒドいものだった。
この「質v.s.スピード」という概念は根本的に間違っていると思う。だって素早く開発をしなくては環境、あるいは自分の環境の理解の変化にソフトウェアがついてこれず、ソフトウェアが解決すべき問題が解決できなくなり、必然的に質が落ちてしまう。逆に、質の高いソフトウェアを書かなくては、なにかある度にインフラが崩壊し、素早く開発をすることができなくなってしまう。インフラの崩壊は、やる気を削ぐので特にたちが悪い。フェイスブックでは「質v.s.スピード」ではなく「質＝スピード」を念頭にソフトウェアを書いてきた。相当たくさんの仕事をフェイスブックではしたし、書いたもののかなりの部分が今でも使われていることを考えると、ぼくの考え方は間違っていなかったと思う。
この記事を読んで開発者の方はどう思いましたか？
はてなブックマークのコメントだけだと、あまりよくわかってないのですが、なんとなく思ったのは、そりゃ、両立しなくてはいけないことをわかってはいても…、という現実に対して、
「やっぱりスピードを求められても質を大事にしよう！」
と思った人が結構いるのでは？
しかし、この記事は、二つの真実を表しています。
「コードが最悪だったとしてもフェイスブックはどエラいサービスになった」
という事実。
そして、
「後から、彼が頑張って直した」
という事実。
「コードが最悪でも成功した」理由は、初期にコードを書いていた人（ザッカーバーグも含めて？）は、素敵な大工さんじゃなかったかもしれないけど、
「想いを実現したいと思った人が書いているから」
・・・なのかなって思いました。
プログラミング能力と、サービスを作る能力は全く別のもの。
素敵なビジュアルのネットショップ vs 楽天ショップの話ってありますよね。
デザインがイケてないのに売れているという話。
ポイントは、ショップオーナーやスタッフが
「自分達で更新するから」
ではないかと。
ネットの制作のプロじゃないけど、商売のプロ。そのセンスがネットに反映される時に、デザインを両立するのは、そりゃ難しいことです。天は二物を与えず。
だから、お店が軌道にのって、ビジネスノウハウが確立してから、直しても遅くない。
そういうことなのではないかと。
じゃぁ、職業プログラマーにとっての正解は？
彼に大賛成で、
「質とスピードの両立」
に他ならない。
ただし、優先されるべきキー値は、
「絶対的に時間」
です。
(僕ここでも書いてるし→「ネットサービス系企業における、積み上げ型タスク管理の危険性」）
プログラマーやデザイナーって、プロ野球選手と同じだと思っています。
「限られたバッターボックスで、如何にヒットを打つか。」
飛んでくるボールの数は有限です。
その中で、如何に打率を上げるか。それが専門職に求められる能力だと思っています。
フェイスブックの例で言うと、
「コードの質にこだわらずに、スピードを優先した」
というのは、
「それでもヒットやホームランを打った」
ので、いろいろ残念だったかもしれないし、後の苦労もあったかもしれないけど正解です。
しかし、その逆は×で、
「コードの質にこだわっていたら、三振した」
というのは最悪です。何も生み出していません。
バッターボックスとは、簡単に言うと、お金のことだと思ってください。
お給料はもちろんのこと、会社全体としては、その時間で得られる売り上げとか、サービス性とか、その先の選択肢とか。先頭バッターが出塁したら選択肢増えるよね、とかに繋がってきます。
つくづく思っていたのは、
「イチローを目指そう」
ということかなって思います。
いついかなる状況下でも、良い感じにヒットを打つ。
そして、後々までメンテするコードだからこそ、そのバッターボックスを大事する。でも、機会は絶対に無駄にしない。
「スピードと質」の両立という言葉をこれほど形容できる人ってなかなかいない。
ぼくのプログラマーとしての成長に一番寄与したのは、「判断力をつける」ということじゃないだろうか。
これはマジで大事。
判断するまでの時間。
判断するための材料の準備。
判断ってのは、「あえて完璧にしない」ということも含めて。
(上記文章にある、as simple as possible but not simpler・・・に近いかな)
これがその先の選択肢に効いてくる。
「とりあえずコード書け」って言葉は、実は判断力の先にある言葉だったりしますね。判断してないとコード書けないし。
コードのスピードが超速いんであれば、間違ってた時に直すのも速いですよね。
そう考えるのもまた判断力。
ただ感覚的には判断力に加えて、決断力、かな。大事なのは。
参考になるかわらないけど、モバツイにメールでつぶやきや写真を送る機能ってのがあって、以前、メールサーバ（postfix）からphpに投げたスクリプトで、twitpicへの送信などを実現していたら、いつしか写真の枚数が増えて、負荷が高くなって、送信遅延が発生しだした。
それを回避するために、「今すぐ解決しなくてはいけないこと」として、メール受信と写真送信を分離するために、確か半日以内でキューシステムを作ったんだけど、オープンソースの素敵なキュー管理システムをいじってる余裕もなかったので、フォルダの移動で管理したんですね。
・写真送信情報の記述したメタデータを、キューフォルダに置く
・別のスクリプトが先頭のメタデータを、となりの実行中フォルダに移動する
・実行中フォルダで、成功したら成功フォルダに移動する。失敗したら失敗フォルダに移動
みたいな感じで。どれぐらい排他処理ができてるのか理解できてないので、多分、本気で負荷かけたらトランザクションのselectの重複みたいな事態が起きてしまうと思うのだけど、こういう仕組みを、以前別業種のシステムで見た事あったこともあって、それなりに大丈夫だと思って作ったんだけど、今のところまだ大丈夫。
ただ、どこかで、ちゃんとしたキュー管理しないとマズイかもね、という状況なので、今後、ちゃんと時間を取って作り直してもらおうと思ってる。
ただ、作り直すって、明らかな問題がある時か、それ以外にやることがない時じゃないとできないので、結局、普通はやる時間が取れないという話になる。
すなわち、やるときは質とスピードが両方ないとできないんです。それをする理由もないのに作り直したら、コードはきれいになったかもしれないけど、バグ出て動かなくなりましただったら、やらない方が良かったじゃんって話になってしまうので。
これも最初の数年で培われた判断力のおかげだ。この「判断力」は、プログラマーにとって非常に重要なのだが、そう簡単に教えられるものでもない。ぼくが知る限り、判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う。
Web2.0以降のSNSの流れで、巨大なサービスを作る会社が増えて、優秀なエンジニアはそっちに流れている中で、当社がエンジニアに提供できるものって、どういう風に言葉にしたら良いのかなって思ってたけど、この「判断力」を培う機会なのかなぁ、と思っている。
システムは、そんなに小さくもなく、大きすぎも無く、一人で上から下まで把握できるサイズの中で、それ相応のトラフィックをさばきながら、
「慎重かつ大胆に、質とスピードを実現する機会」
は提供できるのではないかと思った。