すぐに作りはじめるな

時間がないからと言って、「早くコーディングをはじめなければ」とあせってはいけません。じっくりと落ち着いて作戦を練るのです。

問題：
全部で12部屋あるアパートを6ヶ月で建てる計画だとすると、作り始めてから2ヶ月後には何部屋完成しているでしょうか？

もちろん正解は、「1部屋も完成していない」です（4部屋と答えたくなったでしょうか？）。アパートを建てるには、少なくとも次の手順が必要でしょう：

1. どんな建物にするか考える
2. 設計図をつくる
3. 建物の土台をつくる
4. 骨組みをつくる
5. 外壁や床をつくる
6. 内装をつくる

「毎月2部屋ずつ、6ヶ月で12部屋」という作戦は、どう考えても無理があります。しかしソフトウェア開発の現場では、こういう無理のある作戦をたててしまう場合が多いようです。

横軸に時間、縦軸に完成度をとって、開発工程のグラフを書いてみましょう。「毎月2部屋」作戦では、目標工程は一直線になります。しかし実際の開発はそれより遅れます。多くの場合、遅れの原因は次のようなものでしょう：

• 設計不在によるシステムの複雑化：
  時間の経過とともに複雑さが増していく。また、時間の経過とともに複雑化の速度も増していく。これは開発規模が大きいほど深刻な問題となる。
• 準備不足による非効率性：
  開発環境や試験環境の構築、各種ツール類の作成などに割く時間を惜しむあまり、かえって効率が悪くなる。

開発が遅れれば、出荷を遅らせるか、または未完成のまま期限通りに出荷するかという苦しい選択をしなければなりません。

私の観察によれば、良い工程は図の青いグラフのようなものです。ゆっくりとはじまり、中盤で加速し、仕上げはまたゆっくりになります。そしてオブジェクト指向はこれを可能にします。

前半がゆっくりなのは、時間をかけて設計を行うためです。設計の目的は、「システムの明確な表現形を見つけること」と「今後の作業量を減らすこと」です。

中盤の加速が可能になるかどうかは、前半の設計の品質にかかっています。設計方針が明確であれば、どの機能をどのクラスで実装すれば良いのかが明らかなので、コーディングに迷うことはありません。もし仕様追加があったとしても、その機能をどこに追加すれば良いのかが明らかなので、やはり問題になりません。それに、時間が経過しても複雑化はそれほど進行しません。

うまくいけば後半は時間が余るので、十分テストすることができます。

あなたが開発者なら、はやく作りはじめたいという衝動と闘わなければなりません。もしあなたが管理者なら、「開発者はいつもコーディングに従事しているべきだ」という思いこみを捨てる必要があります。目に見えるものをつくっていないときが、実は最も生産的であるという可能性があります！

しかし、もし中盤の加速が実現できなかったら・・・。そう考えると恐怖ですね。確実に良い設計がなされているのか、それともただゆっくりしているだけなのかを見極めなければならないわけです。

そんなリスクは負えない？でも考えてみてください。「毎月2部屋」作戦は、確実に遅れるんですよ！