シュラバマン・バスター

　仕事が終わる気配を見せない。
　締め切りまであと一ヶ月なのだけど、GWを全部潰して、休日出勤して終わるか終わらないか微妙なところだ。コーディングが順調に進めば終わるはずだが、過去、順調に進んだ試しなどないのだ。つまり、かなり危険な状況だ。
　もはや後戻りができない状態なので、このまま突っ切るのが一番安全なのではあるが、しかしもっと前の時点でどーにかできなかったのか？ という反省はしておきたい。
　実際のところ、半年前にこの状況はうすうす予想されていた。「これ間に合わないな」「ないな」という言葉は多く出ていた。
　この『うすうす』というのが厄介なもので、ここをハッキリさせることができていれば、「いや、絶対間に合いませんからソレ」と堂々と反論できていたであろうし、別の回避策もとれたはずなのだ。上意下達の会社というわけじゃないから、マトモな代替案なら話は通じる。口では「間に合わない」といっておきながら、「だがちょっと待って欲しい。ほんとうに間に合わないのだろうか？」と呑気に構えていたからこうなってしまったのだ。
　間に合わないのがハッキリしているなら、ハッキリした対応が取れる。取らざるをえなくなる。
　必要だったのは、ハッキリした予想だ。
　ではハッキリと予想するためにはどうすればいいのか。それは、ハッキリとした見積を出すしかない。
　ハッキリした見積を出すためには、全体の作業を、細かく分けていって、見積可能な単位にまで落とし込むしかない。つまりUMLを起す程度まで仕様を決めるしかない。そうすれば作業の見通しがかなり明るい。
　だがしかし、そういった仕様が決まったのはここ数週間の話だ。いや、まだ決まりかねている部分すらある。これではスケジュールなど笑い話だ。だけど、イチから仕様を決めているのなら、そういった混乱は仕方ない。そういうものなのだと思う。なかばスクラッチから書き起こしているような状態で、スケジュールを守るのは不可能だ。僕らは神様でも天才でもないから、決めては戻り、決めては戻りを繰り返すしかない。NetScapeだって、ConnectPlayerだって、スクラッチから作り直したものは全てスケジュール破綻、品質はクソったれになることは歴史が証明している。
　どうすればいいのだろう。
　今回の敗因は『一度に変えようとしたせいで見積ができなかったこと』にある。ならば、『一度に変える』をやめればいい。
　コードは漸進的な変化をするべきだ。
　コードは漸進的な変化を前提として書かれるべきだ。
　そのために抽象化というものはあり、その方法論としてTDDなりXPなりアジャイルなどがあるのだと、今回の失敗でしみじみと考えさせられた。やるべきことを細切れにして、初めて作業量の見積が可能になる。
　せめて、今書いているコードだけは、将来、細かく交換可能なように設計しよう。テストを書こう。
　やってやる。僕はまだ諦めねーぞ。元気に立派に、やり遂げてやるんだ。