システム開発プロジェクトのリスクと「義務づけ」
言うまでもないことですが、システム開発プロジェクトにリスクは付き物です。ＱＣＤを考えるだけでも、品質不良リスク、コスト超過リスク、納期遅延リスクがあります。そればかりでなく、目的不達成のリスクやプロジェクト自体の破綻のリスクまであります。そこで重要となってくるのがコントロール、その手段として出てくるのが契約やプロジェクト計画での「義務づけ」です。
ＱＣＤはもちろんのこと、プロジェクトの目的達成や完遂は当然に契約上の義務となります。これらを支えるベンダのプロジェクトマネジメント義務、ユーザの協力義務も、契約上の義務として認められています。また、プロジェクト計画のレベルでは、双方にさまざまな行動義務が規定されます。しかし、プロジェクトのコントロールがこのような「義務づけ」だけで事足れりとするのは、実にナイーブな考え方と言わざるを得ません。
相手方に義務を課すと一見、自分のリスクが軽減されて利益になるように思えますが、これは大きな誤りです。相手方にリスクを移転しただけのことであれば、プロジェクト全体のリスクは変わらないからです。むしろ、不自然・不合理なリスク配分では、全体のリスクが増大するかも知れません。プロジェクトが失敗してしまえば、その後の損失配分をどうしたところで、失ったものを回復することはできません。
より重大なのは、「義務づけ」しただけでは、その義務が履行される保証がないことです。契約書やプロジェクト計画書に書いただけであれば、借用証一枚で大金を貸し付けるのと大差ありません。ビジネスの世界で担保（あるいは何らかの保証）のない取引は殆どあり得ないことですが、システム開発プロジェクトではなぜか「無担保取引」が横行しています。無担保どころか、初めから返済見込みのない貸付までが行われています。
「義務づけ」の発想は、火災リスクは保険を買ってひとまず終わり、為替リスクはオプションを買ってひとまず終わり、とするようなものです。開発プロジェクトには保険もオプションもありませんが、これはリスク自体が不透明で誰も売り手にならないからです。そして、リスクが不透明なのは、それが買い手の側の行動に全面的に依存するからです。逆に言えば、買い手の側を含めた継続的なコントロールが可能であり、また決定的に重要だということです。