オーバーヘッドに掛かる工数は、それだけではない。
ソフトの振る舞いに関しても、同じ機能に何度も修正リクエストが入ることがある。
これにより、設計、実装、テストを、何度もやることになる。
これも何か勿体無い気もするが、全部完成してしまってから修正が入ることを考えたら、開発中に対応することが、一番影響が少ないことに気付く。
こういった、リスクの対応を前倒し前倒しで進めていくことで、工数が余計にかかっている気持ちになるが、そこを納得できるかがマネジメントのポイントだと思う。
ただし、オーバーヘッドにかける工数には限りが必要。
例えば、保険を考えたときに、保険を描けておいたほうが良いが、それにより毎月の生活や娯楽を圧迫してしまうのでは、もともこもない。
余裕のある範囲で保険はかけるもの。
つまり、どんな規模のプロジェクトにも有効かと言うわけではない。ウォーターフォールでサクッと作ったほうが早い場合もある。
プロジェクトへの適応は、慎重に考えなければならない。
最初のオーバーヘッドを許容できる覚悟が、マネジメントにあるかどうか。
