プロジェクト管理の権威、トム・デマルコの書籍を買って、電車の中、喫茶店、休み時間などずーっと没頭して読んでいた。面白いし、値段以上の価値があったと思わせる本だ。いや、これまで読んでいなかったことが逆に恥ずかしいと思えるほどだ。
これらは、純粋に「プロジェクト管理」について書かれているものであって、会社の上司をどーするとか、社内政治でどーにもならないケースについての対処方法が書かれているとかいうものではない。割とそのへんは本文中でも「お手上げ」といっており、さらに「知的労働者は職場を移動する権利を有している」といっているあたり、どうにもならないことにエネルギーを割くよりは新天地をさがしたほうがよい、という見解を垣間見ることができる。
トム・デマルコの本をじっくりと読み、分析を行い、自分の行っているソフトウェア開発のプロセスでいくつか試してみようと思えるものがあった。
（１）いきなりコーディングに入らない
仕事でプログラムを組む場合は、きっちり仕様を決めて作るのだが、個人プロジェクトのプログラムは、やおら勢いにまかせてコーディングから始まることが多い。
簡単な試作品を作って、技術的にアイデアの実現が可能であることが実証できたら、既存の機能ライブラリをガンガンつなげていって短時間で完成レベルに持っていく。
それぞれの部分についてコメントはつけておくが、「どーしてこういう処理を付けようと思ったのか」とか「現在このような課題を抱えている」といった大局的な見地からのコメントがなかったりする。
仕様を万全なものにしてから組み出す、というのは悪くはない方法だ。DB上でシミュレーションを行ってからコーディングする、ぐらいの勢いでもよいだろう。
（２）余裕のあるコードを書く
本に書かれていたことではないが、自分が作るコードは「最短距離で目的を達成する」という種類のものが多く、あとから手を加えようとすると、ものすごく苦労させられることが多々ある。
後になって機能の変更や拡張が可能なように、若干余裕をもった設計を行っておくことが重要であるように思える。
通常のScript Editor上で書いている際には問題になりにくいのだが、Xcode上に移してしまうとデバッグ機能の貧弱さから（機能していないに等しい）、問題が発生した時に対応し切れなくなったりする。そうした場合には、Xcode上からAppleScriptをScript Editor用に書き換えて、分解修理を行うことがある（仕事のプログラムはいつでもXcodeのプロジェクトから分離できるように書くことが多い）。
個人プロジェクトでも、いつでも分解修理できるようにしておくことが必要になるだろう。
（３）短期間で大幅な機能アップを行わない
いつも、ものすごく短い期間に大量の機能を実装してしまうのだが、これも善し悪しである。思うに、プログラムによって実現された「機能」には慣性が働いており、短期間のうちに巨大な機能を実装してしまうと、慣性が大きくなってなかなか方向転換などが行いにくいように見受けられる。
短期間のうちに作成した大量の機能は、あとで自分の首をしめることになりかねない。プログラムを進化させるのに適したスピードというのは、自分が実装するよりももう少しゆっくり目ではないかと思うようになった。
とくに、AppleScriptのプログラムは、Objective-Cなどよりも急速にプログラムを高機能化させることが可能な割に、プログラミング環境そのものが貧弱だったりして（とくにXcode上で書き出すと、その貧弱さに泣きたくなるほどだ）、おまけにXcode上で書けるプログラムの行数に制限がある。１つのScriptでだいたい1000行を超えると、いろいろと不具合に直面し……4000行ぐらいも書けば構文確認時に原因不明のエラーやクラッシュなどが頻発する。
AppleScript環境で仕事をしている人間がまず最初にすべきなのは、US Appleにバグの所在などを繰り返し声高に主張することなのかもしれない。