納期と予算はプロジェクト外で決定される。仕様はプロジェクト内で決定できる。

ソフトウェア開発プロジェクトの初期段階は、情報量が圧倒的に少ない中で仕事を進めていかなければならない。これから作り始めるものについての情報は、プロジェクト参加者のそれぞれの頭の中にあるが、全員の共通認識が出来ていることはまずありえない。

最悪なのは、誰の頭の中にも完成イメージがなく、「誰かが考えているだろう」と全員が思っているという場合だ。こういう場合は、あの人が大丈夫だと言っているからなんとかなるだろう、という甘い考えの元、わかりやすいところから作り始めて後で泣くという、典型的なアンチパターンである。

顧客側が持っているイメージを、開発側に過不足なく伝えるのは難しい。多く伝えすぎると見積もり段階でコストがあがりすぎ、少なく伝えると本当にやりたかったことが出来ない状態で納品される。なので、イメージを紙に最初に落としこめないのであれば、予算ありきでプロジェクトを開始するしかないのである。

顧客は予算をどこからともなく捻り出す際に、納期も設定してしまう。投資した予算をいつぐらいまでに回収できるかという目標を立てて、それに伴いプロジェクトスケジュールを決めるからである。納期は予算に紐づいていて、その時点でプロジェクトのライフタイムが決定する。

そのような事情から、プロジェクト開始時点では、予算と納期は顧客側により決定されてしまっている。どちらもそれより短く、安くする方向にしか力は働かない。プロジェクトにアサインされた人がコントロールできるのは仕様だけである。プロジェクトの目的は提示されているが、それをどう解釈するかはプロジェクト内部でコントロールできなければおかしい。要求仕様はあくまでも仮のもので、その裏にある真の目的を見定める必要がある。

表に出てきている要求仕様をそのまま形にするのではなくて、最終的にどうしたいのかから逆提案して、そっちの方がより目的に適っている、と顧客に納得してもらえれば、すぐに仕様は変わるのである。開発側の特徴というかノウハウというのはその部分である。

インターネットに公開されている技術要素を知っているだけでは、顧客になんの影響も与えない。開発コスト削減だけでは顧客は反応しない。顧客の中に入っていって、技術と目的を結びつけて始めて顧客が反応するのである。

予算や納期がコントロールできないと嘆くのではなくて、仕様をコントロールすることで予算内、納期内になんとかするのが、プロジェクトマネージメントであると思う。