狐の杯

人はさびしいとおかしくなる
ひっくり返すと、人がおかしなことやってるときは、だいたいさびしい

1. スタードダッシュでできるだけはやくめどをつける

　学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置ですます、などの可能性が減らせる。

　このスタードダッシュ型の仕事スタイルを実現するには、「締め切りに迫られて」ではなく、「自分から進んで」スパートをかける必要がある。以下はそのための手法。

2. 仕事を「タスク」に細分化する

　プログラマーである私にとって、一ヶ月は「気の遠くなるような先」。そんな先を目指していてはすぐに息切れしてしまって走ることができない。そこで、仕事を細分化する。ここでの仕事の一つの単位（便宜上「タスク」と呼ぼう）は半日から三日ぐらいで出来るもの。最初にすべきものほど明確に定義し、後でやるものはある程度曖昧にしておく（どのみち設計変更はするので、あまり先のことまで綿密に計画を立てるのは時間の無駄）。

3. 一日の始めに、「今日やるマイクロタスク」のリストを作る

　これはすなわち、当面取りかかるべきタスクのさらなる細分化（マイクロタスク化）である。大切なことは、各マイクロタスクが独立した作業で、それが達成できたかどうかが（テストプログラムなので）明確に確認でき、かつ、それを一塊のものとして（ソースコードを管理しているサーバーに）チェックインしてもサイド・エフェクトがないこと。大きさとしては、うまく行けば１５分ぐらいで、なかなかうまく行かなくても二時間ぐらいで完成できると思えるぐらいが適切。ちなみに、サイド・エフェクトの考慮は大切。相互に依存するモジュールAとBに同時に変更をかけなければ問題が生じるのであれば、モジュールAへの変更だけを独立したマイクロタスクとして定義することは不可能。

　そんなマイクロタスクを数個から十数個並べたリストを机の上に書いて、それぞれにチェックボックスを添えた上で、例えば「今日は昼飯までには最初の４つ、家に帰るまでには残りの７つを絶対終える。余裕があったら、次の２つもこなす。」と自分で宣言する。

4. それぞれのマイクロタスクは「割り込み禁止状態」でこなす

　大切なことはマイクロタスク一つ一つを「決して他の仕事を間に挟んでは出来ない仕事」と覚悟して、全力疾走でこなすこと。その間はメールのチェックはしないのはもちろん、電話がかかって来ても取らない。トイレにも行かないし、席から立ち上がりもしない。誰かが机に来ても、「今はだめ」という。脳を１００％そのマイクロタスクに集中し、一気に書き上げる。つまり、マイクロタスクを処理している時にコンテキスト・スイッチをしてはいけないのだ（割り込み禁止状態）。

　大切なことは、この「割り込み禁止状態」と「割り込み可能状態」をはっきりと区別して一日を過ごすこと。「割り込み禁止状態」におけるプロダクティビティを最大化できれば、その比率は４：６（つまりプログラミングをしている時間が４割）ぐらいでもものすごく仕事がはかどる。逆に常に割り込み可能状態でプログラムを書くと効率の悪さ故に、残業しても、一日の９０％の時間をプログラミングに費やしても大して仕事がはかどらない。この割り込み禁止状態でマイクロタスクをひとつづつこなすという仕事のスタイルに体が慣れていれば、どうしても仕事量を増やさなければならない時には、その比率を８：２ぐらいまで増やした上で仕事時間を長くすれば良いだけのこと。何日も続けると体が持たないし、周りの人に迷惑をかけるが、２〜３日ぐらいのダッシュなら二週間に一度ぐらいはかけられる。

5. マイクロタスク単位に丁寧にテストした上でチェックインする

　順調に書き上げることができれば、自分なりのテストをして、それが確実に動いていることを確認した上でチェックイン（「１つ書いては動かせ」というやつ）。それから休憩するなり、メールのチェックをする（割り込み可能状態）。チェックインする単位ごとでのテストは手を抜いてはいけない。このレベルでのバグを発見するのは、プログラムを書いた本人の役目。テスターの役目ではない。テスターの役目は、どうしても生じるプログラマーが見つけ損なってしまったバグを見つけること。「たぶん動くだろうけど、バグがあったらテスターが見つけてくれるからいいや」という考えでチェックインするのは犯罪行為。

6. うまく動かないマイクロタスクは、一度最後にチェックインしたところまで戻って書き直す

　そんなマイクロタスクを実行中に、ある部分のソースコードを大きく書き直したくなることがあるが、そこは躊躇せずに思い切ってする。万が一そのためにプログラムがぐちゃぐちゃになってしまったら、ケチケチせずに、最後にチェックインしたところまで一気に戻ってやり直す。マイクロタスクが十分に細分化されていれば、そこで「捨てるコード」に費やした時間は高々１〜２時間。一度ぐちゃぐちゃになったコードを直す方がよっぽど時間がかかる。

　変更した箇所が思った通りに動かない時も同じ。デバッグしてすぐに問題点が見つかるのであれば直せば良いが、なかなかデバッグしてもうまく動かないときは、思い切って変更を切り捨てて、最後にチェックインしたところにまで戻る。特にこれが必要なのが、新しい機能を追加した時に、今まで動いていたものが動かなくなってしまった場合。「なぜ動かなくなったか」を解析している時間と、ゼロからもう一度書き直す時間とどちらが大切なのかを考えると、ゼロから書き直した方が早い場合が多い。これは私の経験だが、動くはずのプログラムが思った通りに動かないときの一番の原因はつまらないケアレスミス。セミコロンの入れそこないだとか、x と y が逆になっていたりとかだ。そんなケアレスミスがなかなか見つからずに煮詰まってしまうことは良くある。そんなときは、躊躇せずに変更を全部捨て、最後にチェックインしたところまで戻って、ゼロから書き直す。

そもそも「努力しろ」と言われて努力するような奴は
「努力しているように見せている」だけに過ぎない
つまり人のためにやってんだなこれ

本気で努力する奴は、周りが邪魔しようが、道具や環境を全部ぶっ壊されようが、
勝手に自分で方法見付け出して努力する
隠れてでも自分で時間とってでもな

いぬ式性格判断究極版

● ウェブ上で性格判断や占いなどたくさんありますが、いぬ式性格判断究極版を発表するバウ。やり方は簡単。ご自分の日記などのページがあったら、その中から「否定的な言葉」「中傷する言葉」など、負の方向に向いていると思えるようなモノだけを列挙するんです。品詞について詳しくないけど、形容詞というのでしょうか、ものごとを装飾する部分の言葉ね。

● カーク船長も「何を善悪とするかがその人の個性になる」と言っています。他人やモノなどに対して、ついつい言ってしまう悪口。それは、その人が常日ごろ心の中で気にしている、自分自身のことなんだバウね。自分自身のその部分が気になっているからこそ、他人のその部分が気になる。「アニメなんか観て子供っぽい」と指摘する人は、実は自分の子供っぽさが人一倍気になっている人なんだバウ。

● この性格判断は、強烈です。なんせ、仕組みを知ってるいぬにでさえ、有効なんだバウ。いぬ日記から列挙してみます。「なさけない」「安定していない」「汎用じゃない」「挙動不審」「うさんくさい」「カッコ悪い」「陳腐」…。どうです、笑えるほど当たってるじゃないですかぁ。当たっていて、しかも気分悪いぞ、この性格判断。

● いつもウェブ占いの結果を、そのまま要約もせず垂れ流しするコシアンなんか、いぬ式性格判断究極版をやってみてはいかかでしょうか。コピーペーストよりずっと面白いバウ。（追記）やってくれないようですね。鬱になるからとか。そうです。きっとなります、鬱に。

● 「何を悪とするか」の話題について、もう少しだけ。いぬが悪と思うこと。それは、他人に「何々は悪だ」と強要すること。教育とか法律も、ばっちりそれに当てはまるバウ。教育やマスメディアで「いのちは大事だ」なんて教え込まれてるけど、真っ赤な嘘。たいてい、いのちの前に「自分の」「自分に近い」とかが入るバウね。「いのちは大事だ」なんて言われたら、誰もがうなずいてなかなか否定できないバウ。殺し文句というヤツですな。

● 最近、ポテトチップスに発ガン物質がなんて騒がれているバウね。いぬ日記初期に永遠に繰り返されたフレーズ。さらに繰り返させていただくバウ。「どんなものを食べても毒なんだろうから、どんなものもおいしく食べたい」人類が科学的に追究するほど、どんな食べ物も毒と判断されるバウ。そんなのはわかってるから、おいしくいただきたいんです。食べる直前に「それ体に悪いんだぞ」なんて言われたら、本当に毒になるんです。食べる直前に、そんな暗示を吹き込む人を、いぬは悪だと思うバウ。「何々は毒だ」というのも、「何々は悪だ」と強要するのと親戚ですね。ちょっと言霊ちっくな電波系になってきたかな。そんなこんなで、ポテトチップス買ってきて食べたバウ。ぱりぽり、うまい。