6．十分な時間を取る
「You want it bad -- you got it bad」（本当に必要なものは、ひどい状態で手に入る）というフレーズを初めて聞いたのは、Hughes Aircraft Companyにいた時のことだった。あまり頻繁に起こることではなかったが、起こった時には必ず、本当に必要とされ、急いで作り、そして納品されてみるとテストがうまくいかないという時のベンダー側のこととして話されていた。プロジェクトの各段階に十分な時間を取ることができないと、要件を満たせなかったり、分析が不十分だったり、設計が悪かったり、プログラミングが大急ぎで行われたり、テストが不十分だったり、文書化が不完全だったりといったことが起こる。その結果、システムは期待を満たすことができず、1つ以上の重要な部分で問題を生じるかもしれない。
プロジェクトの各段階を終えるのに必要な時間を見積もるのは難しい。私が上司と話し合いながら、プロジェクト計画中の主なタスクについて割り当てる時間を決めた際には、最善の結果を出すことができた。その際、私は見積もりは楽観的過ぎるものだった。上司は自分の見積もりについて、ずっと現実的だったが、正しいのは上司の方だった。私の経験則では、最初に見積もった時間を倍にしたものが、実際に必要な時間に近い。この情報は、プロジェクト計画のスケジュールを決める際に役に立った。
あなたも、完成までにかかる時間を正確に見積もることができるようになるまでは、同様の経験則を持っておく必要があるかもしれない。理想的には、プロジェクトの各段階は予定通りに終わるべきであり、そのためのもっともよい方法は、正しく率直に見積もりを行うことだ。この記事に、現実的なスケジュールを立てるためのヒント（英語）が紹介されている。
7．実績のあるコードを再利用する
もしあなたが経験豊かな開発者なら、長年の間に巨大なコードベースを築き上げているはずだ。そのコードを可能な限り再利用すべきだ。おそらく新たな要件に合わせてコードを修正しなくてはならないだろうが、実績のあるコードは、よい基盤になるはずだ。新たなバグを導入してしまうリスクを減らすことができるだけでなく、似たようなコードを再び書くのにかかる時間と、それに続くテストに必要な時間を省くことができる。
自分のコードを他のメンバーとも共有し、他の人もその一部を再利用できるようにした方がいいだろう。実績のあるコードは、プラグインやライブラリの形で共有することもできる。インターネット上には、無料あるいは安い利用料で合法的に利用できる良質なコードもある。
8．チェックリストを使う
旅客機が離陸する際、操縦士と副操縦士は長く詳細なチェックリストをチェックするのに手間をかける。チェックリストは、プロジェクト運営のさまざまな段階で利用できる。大規模なシステムに取り組んでいる場合や、1人の人が複数の作業を担当しているような場合、チェックリストは特に役に立つ。
例えば、システムを起動するのに必要な手順を詳しく書いたリストがあれば、手順を間違えたり、飛ばしたりするミスを防ぐのに役立つ。最終テストや文書化などで忙しいときに、開発者がシステムアクセスのような重要な項目を見落としてしまうというのはよくあることだ。
チェックリストを使うことの詳しい利点については、「Leverage checklists to improve efficiency and client satisfaction」（効率と顧客満足向上のためにチェックリストを利用する）という記事を参照して欲しい。
9．テスト、テスト、テスト・・・そして注意深い見直し
エラーのないものを作り上げるためには、適度に偏執的になる必要がある。できる限り多く、できる限り早くテストをした方がいい。コード中のエラーが発見された場合の修正にかかるコストは、開発プロセスの終わりに近くなるほど大きくなるのが普通だ。最終的なリリース日間際になって、何カ月も前に発見されているべきバグが見つかることだけは避けたいだろう。
注意深く、徹底したテストを行えば、ユーザーよりも先にミスを発見することができる。自分の作業をダブルチェック、あるいはトリプルチェックすべきだ。テストデータを作成し、月末処理や年次報告などの特定の時期に行われる作業についてのテストを計画しよう。すべての機能と、すべてのあり得るシナリオを徹底的にテストすべきだ。また、この場面ではチェックリストが役に立つだろう。
