Joel on Software   このページは"ジョエル・オン・ソフトウェア

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事（日本語）

その他の "Joel on Software" の記事（英語）

著者へのメール（英文のみ）

ときどき何もできないことがある。

確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。

このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。

誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。

それは、基本的に人々は食べるものをコントロールできないためダイエットの試みは短期間で終わり自然な体重に戻るのが常だという、あの研究者たちが言っていることを思わせる。ソフトウェア開発者として私はいつ生産的であるかを自分ではコントロールできず、生産的な時期に非生産的な時期の埋め合わせをして、平均ではクビにならないために十分なコード量になることを期待するしかないのかもしれない。

私は最初の仕事以来、開発者としての自分が生産的にコーディングするのは平均して1日に2、3時間だということを認識していた。私が Microsoftでサマーインターンシップをしていたとき、同僚のインターンは毎日12時から5時までしか実際には仕事していないと言っていた。5時間引くランチ。それでも彼は平均よりずっと多くのことをしていたので、チームは彼のことを気に入っていた。私自身それが真であることを見出した。私は他のみんながいかに熱心に働いているか見るとき、何か罪悪感を感じた。1日に2、3時間集中して仕事するだけで、チームでもっとも生産的なメンバでいることができたからだ。そしておそらくはこれが、ピープルウエアやXPが残業の排除と厳格な週40時間労働にこだわる理由で、そうしてもチームの出力は減らないという知見があるために安心してそうできるのだろう。

しかし私を悩ませるのは2時間しか仕事ができない日々ではない。私がまったく何もできない日々だ。

私はこのことを良く考えてみた。私のキャリアの中でもっとも多くの仕事をしたときのことを思い出そうとしてみた。それは多分Microsoftが私を、飾り窓から花をつけた桜の木でいっぱいの愛らしい中庭を眺められる、美しく豪華な新しいオフィスに移したときだ。すべてがうまくいった。私は何ヵ月もノンストップで働き、Excel Basicの詳細仕様をひねり出し続けた—それは巨大なオブジェクトモデルとプログラミング環境をカバーする驚くべき詳細へと変わっていく記念碑的な紙の山だった。私は文字通り止まらなかった。MacWorldのためにボストンへ行く必要があったときにも、私はラップトップを持って行き、ハーバードビジネススクールの快適なテラスに座りWindowクラスについてのドキュメントを書き続けた。

ひとたびフロー状態になると、それを維持するのは難しくない。私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。

ステップ8とステップ9の間のどこかにバグがあるようだ、私は必ずしもこの溝を飛び越えられないからだ。私にとっては、ただ始めることが唯一困難なことなのだ。静止状態にあるものは、そのまま静止状態に居続けようとする。私の頭の中にはとても重いものがあって、それを加速するのはとんでもなく難しいのだ。しかしひとたびフルスピードで回り始めたなら、それを動かし続けるのに努力は必要ない。それは自給のクロスカントリー自転車旅行の装備をした自転車みたいなものだ—フル装備の自転車に最初乗ったとき、動き出すのにいかに多くの労力がいるかは信じがたいほどだが、しかしひとたび動き始めると、何もつけてない自転車に乗っているのと同じくらい楽に感じられる。

たぶんこれが生産性の鍵なのだ: ただ始めること。ペアプログラミングが機能するときにそれがうまくいく理由は、たぶんペアプログラミング セッションを相棒とスケジュールするときには取りかかるために2人が力を合わせるからだ。

私がイスラエルの落下傘部隊にいたとき、将軍が戦略についての短いスピーチをするために私たちのところに立ち寄った。歩兵戦ではただひとつの戦略がある、と彼は言った: 射撃しつつ前進だ。銃を撃ちながら敵のほうへ進む。射撃によって相手は頭を引っ込めるので、あなたを撃つことができなくなる。(兵士が「援護してくれ」と叫ぶときに彼らが意味しているのはそういうことだ。つまり「敵を撃ってくれ、そうすれば連中は頭を引っ込めなきゃならなくなるので、通りを横切っている私を撃てなくなる。」と言っているのであり、それは機能する。) 前進は敵の領地を攻略し、敵に近づくことを可能にし、あなたの弾が敵に当たる確率を高くする。あなたが動かないなら、敵が主導権を握ることになり、それは良くないことだ。あなたが撃たないなら敵はあなたに向かって撃ち、あなたを釘付けにするだろう。

私はずっとこれを覚えていた。空中戦から海軍の大規模作戦行動までのあらゆる種類の軍事戦略が、この射撃しつつ前進のアイディアに基づいていることに私は気づいた。この射撃しつつ前進の原理が、人生でものごとを成し遂げるときのやり方でもあることに気づくには、さらに15年かかった。あなたは毎日少しずつ前へ進む必要がある。あなたのコードがまずくてバグだらけで誰もほしがらなくても問題じゃない。あなたが前へ進み続けるなら、コンスタントにコードを書き、バグを直し続けるなら、時があなたの味方となる。あなたの競合があなたに向かって撃ってくるのに気を付けること。彼らはあなたが彼らの一斉射撃への対応に忙しくて前に進めないようにしたいだけなのではないか?

Microsoftから出てきたデータアクセスストラテジーの歴史につい考えてみるといい。ODBC、RDO、DAO、ADO、OLEDB、そして今度はADO.NETだ—すべて新しい! これらは技術的必然だったのだろうか? 毎年データアクセスを再発明する必要があるデザイングループの無能さの結果なのだろうか? (たぶんそうだ。) しかし結果としてそれは援護射撃となった。競合は彼らの時間をすべて費やして移植し、追いつこうとする以外に選択肢がなく、彼らは新しい機能を書くために時間を使うことができない。ソフトウェア業界の状況をよく見てみるといい。うまくやっているのは大企業に依存するところが最小限で、キャッチアップだとか、再実装だとか、あるいはWindows XPでだけ現れるバグの修正だとかで彼らのすべてのサイクルを使わなくてすむ会社だ。つまずいているのはMicrosoftの将来の方向を占うために紅茶の葉を読むのにあまりに多くの時間を使っている会社だ。人々は.NETのことを気にして彼らの全アーキテクチャを.NETに合わせて書き直す。そうしなきゃいけないと考えたために。Microsoftはあなたを撃っており、それは彼らが前へ進み、あなたが前へ進めないようにするための、ただの援護射撃だ。なぜならそれがゲームの進め方なのだから。HailstormやSOAPやRDFをサポートするつもり? あなたがそれをサポートしようとしているのは、顧客がそれを必要とするからなのか、それとも誰かがあなたを撃ってきていて、あなたは応戦しなきゃいけないと思っているからなのか? 大企業のセールス・チームは援護射撃というものを理解している。彼らは顧客に言う、「OK、あなた方は私たちから買う必要はありません。最高のベンダーから買ってください。しかし(XML / SOAP / CDE / J2EE)をサポートしている製品を選んでください。そうしないとトランクに閉じこめられてしまいますから。」そして小さな会社がその顧客に売り込もうとすると、従順なCTOが「J2EEはあるのか?」とオウムのように繰り返すのを聞くことになる。そして彼らはJ2EEで構築するために時間を無駄にしなければならなくなる、たとえそれが実際には売れないとしても、そして彼らに差別化の機会を与えないとしても。それはチェックボックス機能なのだ—あなたがそれを実装するのは、それを持っていると言うチェックボックスが必要だからであり、実際には誰も使わないし必要ともしない。そしてそれは援護射撃なのだ。

私の会社のように小さな会社には、射撃しつつ前進は2つのことを意味する。あなたは時間を味方につける必要があるということ、そして毎日前へ進む必要があるということだ。遅かれ早かれあなたは勝つだろう。昨日私にやれたことといえば、FogBUGZのカラースキームを改良することだけだった。それでOKだ。それは絶えず改善され続ける。毎日私たちのソフトウェアは良くなっていき、より多くの顧客を獲得する。それが重要なすべてだ。私たちがOracleサイズの会社になるまでは、私たちはグランドストラテジーについて考える必要はない。私たちがしなければならないのは、ただ毎朝やってきて、どうにかエディタを立ち上げるということだ。