ソフトウェア開発計画

　久しぶりの更新。
　最近は新プロジェクトにほぼ毎日取り組み、一応出来上がったモノのクオリティには満足できているものの、なにしろ時間がかかりすぎ。ソフトウェアの開発計画が遅れるのは世界のどんなプロジェクトでも共通しているけど、今回のは半端でないよ（もちろん自慢できることじゃないが）。
　思い起こせば、アイデアの源流は2004年に思いついたもので、当初はサラリーマンを辞めたらこいつに注力しようと思っていたんだよな。記録をもとに変遷をまとめると、現在の開発計画がまとまったのは2005年の8月くらいだ。

● 2005年8月
　11月(もちろん2005年の！)を完成目標とする。
● 2005年9月 先にPoderosaに注力することにしたため、2006年7月に目標延期。
　これは計画自体の変更なので見通しの甘さとは関係ない。が、この時点ではPoderosaは2006年4月までで片付ける気でいた。
● 2006年8月
　Poderosaが予定を大幅にずれこみつつ一段落。計画を練り直し、2007年1月を目標として再出発。
● 2006年9～12月
　微調整を経て、現在は2007年2月がターゲットになっている。

　もっとも、これは誰かに頼まれたものではなく自分の企画なのでどんなに遅れてもどこからも文句は出ない、という安心感が遅延の最大要因ではあるのだが、ここ１年くらいの経験を通して分かった「ソフトウェア開発を遅延させない心得」としてはこんなものがある。

(1) 作業全体を「１日に２～３項目」の単位に分割して計画を立てる。１項目につき１～３時間の作業量になる。もちろんあまり先までは決めるのは無理だが、常に１週間分くらいは計画ができていないとだめだ。単位が大きすぎて「３日でデバッグを終える」みたいな大雑把な見積もりをしていると、数時間を無駄にしても遅延が把握できない。
(2) 人間誰しもやる気の出ない日はある。それは仕方ないが、そのダメな雰囲気を次の日に持ち越さないため、必ず少しは進める。関数１つの実装、テストケース１つの整備、その程度でもよいので前進させておくと精神面がずいぶん違う。なお、やる気の出ない日は無理をせず堂々と映画みたりゲームしたり酒飲んだりするのがよい。
(3) 予定を遅延した場合、その理由を検証する。何に気づいていればより正しい見積もりができたのかを考え、次に反映させる。

　ここまでは世間のプロジェクトマネジメントの本と大して変わらないが、次はけっこう違う。

(4) 当初計画に「予備の時間」を入れるのは誤っている。それがあると単にだらだらする時間の温床になるだけだし、そんなものはあってもなくても必ず予定よりずれる。現在は予定より○日遅れている/進んでいる、という現状を把握していれば十分。どちらにしても、計画にある「１日に２～３項目の仕事」をリストどおりこなしていく。

　もちろん最後のは、デッドラインが決まっているプロジェクトではこの限りではないだろうけれども。

　あと、これは僕だけかもしれないけれども、こんなふうにしている。

(5) 半端な状態で一日の仕事を終えるのは良いこと。再開したときスムーズに入っていける。コンパイルも通らないソース、簡単に再現できるバグ、これらは「半端な状態」を作るのに便利な材料だ。
(6) なんだかんだいっても、本当に集中して仕事できるのは一日に３時間。その時間帯に、一日で一番複雑な作業をするようにする。
(7) 認識しているバグが１つでもあるときは、新機能の追加をしてはならない。既知のバグをつぶすことは何よりも優先する。

　偉そうなことを書いてみたけど、それでもなかなかうまくはいかないものだ。やっぱり気がつくと2chやYouTubeでだらだらしていることもしばしばあるし。まあ、プロジェクトが伸びてもとりあえず相場の収益のおかげで食うには困らない、というのが危機感の欠如に繋がっているんだけど...

　なお、この件は株のトレーディングにからんだソフトウェアです。そのうち人員追加のための人材募集やら、トライアルユーザの募集やらをしていくことになるでしょう。