形だけの検収は覆される
ご覧の通り、裁判所は、ある意味あっさりとベンダに費用の返金を求める判決を出しました。“形式的な検収"には意味がないと断じたわけです。裁判所というところは、案外と仕事の中身を見て判断するところで、形だけの検収書を盲信したりはしません。
実際にシステムを見たり、プロジェクト管理帳票を吟味して、実際のところがどうなのかを見てから判断します。少なくともITの専門家を裁判や調停の席に同席させて意見を求めている東京地裁では、そうした傾向が強いようです。
もっとも、この連載はどうしたら裁判に勝てるのかを論じることを主旨としているわけではなく、こういう事例を反面教師にして、ITプロジェクトを円滑に進める為にはどうしたら良いのかを考えてみようという内容です。
その視点で考えると、今回はユーザの勝利となったこの結果も決してユーザ側の行動が正しかったということを意味するものではありません。IT訴訟に勝者はいません。こんなことになるまで膨大なエネルギーと資源を費やした上、何も得るものがなかったユーザ、働いた分の費用を貰えず丸々赤字になってしまったベンダ、どちらもが敗者です。
では、この判決から得られる知見はなんでしょうか。どうしたら、こんな憂き目を見ずに済むのでしょうか。もちろん本当に最後の最後まで検収を行わなければ、こうした争いはおきないでしょう。しかし、それでは冒頭述べたように、ベンダの資金繰りに問題が出るかもしれませんし、ユーザ側も経理処理上の不都合があるかもしれません。
推奨される”実態をともなう”多段階検収
この場合問題だったのは、中間で検収を行ったこと自体ではなく、その検収が現実と乖離していたことです。たとえばプロジェクトをもっと細かく区切って、要件定義、基本設計、詳細設計といった局面が終わるごとに、本当の意味での検収をおこなったり、実際に動く機能を少しずつリリースする度に検収するという方法はどうでしょうか。
小さな単位での検収と支払いは、事務経費が増えてスタッフには敬遠されるかもしれませんが、危険を分割するという意味合いもあります。たとえばベンダの側からすれば、もちろん資金繰りが助かります。
そして、ユーザ側からしても検収単位の区切り方に気をつければ、プロジェクトが破綻しても、なんらかの意味があるモノが手元に残ります。部分的でも動作するソフトウェアや、ある部分までまとまっている設計書は、最悪の場合、他のベンダに依頼して引き継いでもらうことができるからです。
もちろん、こうしたやり方は引き継いだ側のベンダも勉強時間が必要だったり、他人の作ったものから新しいものを作るという意味ではやりにくいものです。費用だって余計にかかるでしょう。しかし、それでも最悪の時には、ユーザ側もすべてを捨ててしまうよりはマシですし、お互いに被害を最小限に抑えることはできます。
こうした多段階検収は情報処理推進機構などでも以前から推奨していることでもありますので、いざというときのリスク分散としてユーザ、ベンダともその可能性を考えてみてはいかがでしょうか（了）。
