旭川医大が仕様凍結後も要件の追加・変更を繰り返したことに対して、ＮＴＴ東日本が「もう、これ以上の変更は受け付けられない」と警告して仕様凍結をしたことが、「ベンダーのプロジェクト管理義務」にあたります。ＮＴＴ東日本は、義務を果たしていると考えられます。
一方、ＮＴＴ東日本の警告を無視して要求を出し続けた旭川医大は、警告を受けて次善策をベンダーと一緒に検討するという「発注者の協力義務」を果たしていない。だから旭川医大に責任がある、という判決なのです。
もしも、ＮＴＴ東日本が旭川医大の要望に警告を出していなかった場合、あるいは旭川医大が警告に聞く耳を持って、一緒になって話し合う姿勢を見せていた場合、裁判の結果はまるで違った可能性があるわけです。
「ワガママ」が悪なのではない
「警告に耳を貸さない」ことが問題
発注者企業のシステム担当者や経営者は、この事件を見て、「要件についてワガママを言ってはいけないのか……」と絶望してはいけません。自分たちの望む、本当に会社を幸せにするシステムを作るために必要な要件を正確に定義することは、簡単なことではありません。
押さえておかなければいけないのは、自分たちの要望に対して、ベンダーが警告をしてきたり計画変更を申し出てきたときに、それを真剣に検討し、双方が受け入れられる策をベンダーと共に考える姿勢を持てるかどうかが、大きな分かれ道になるということです。
『システムを「外注」するときに読む本』において、私は、「システム開発における発注者とは、“お客様”ではなく、明確な役割と責任を持った“プロジェクトメンバー”である」と書きました。
大切なことは、会社にとって、そこで働く社員にとって、そして社会にとって本当に役に立つシステムを目指して、ワガママを言い合いながらも互いの協力関係と信頼関係を築くことです。その関係が築けなかったり、関係が破綻した先にあるのが、今回の旭川医大事件のような悲劇なのです。
ＩＴ紛争の定番とも言える今回の事件は、こうしたＩＴシステムプロジェクトを成功させるために最も大切なことを再認識させてくれる事件だと言えますが、こうしたことは、とりわけ発注者企業が事前に認識しておくことが難しいものでもあります。
システム開発における発注者側のテキストとして6月に上梓した『システムを「外注」するときに読む本』は、そうした誰も教えてくれない「発注者の役割」と「プロジェクトを成功させる方法」を、無数のＩＴ紛争をベースにしたストーリー形式でお伝えする本です。
ぜひ本書を使い倒すとともに、今回の旭川医大事件を教訓としていただきながら、御社のＩＴプロジェクトを成功に導かれることを切に願っています。
