紛争勃発に備えよ！──受け入れ検査時のトラブル対策：企業システム戦略の基礎知識（10）（1/2 ページ）

システムの納品・検収の際に発生しやすいのが、「欠陥か、仕様変更か」をめぐるトラブルだ。こうした“紛争”を丸く収める方法を伝授する。

　受け入れ検査において、明らかに「欠陥」であると判定できる場合は問題ないが、発注側では欠陥だと思って指摘しても、業者からは「それは欠陥ではなく、仕様書に書いてなかったので仕様変更である」と反論されることが少なくない。これは、業務という抽象的なものを対象としているうえに、要求仕様が日本語特有のあいまいな表現で記述され、発注側の意図が業者に正しく伝わっていないことが要因である。

　こうした“見解の相違”は、欠陥であれば業者が無償で是正することになり、仕様変更であれば発注側が追加費用を負担する──つまり両者の利害は対立しているので、容易に紛争へと発展する。そうなった場合に、できるだけ禍根を残さずに両者が納得できるような形で解決するには、どうすればよいか考えてみたい。

仕様変更か、欠陥か──それが問題だ

　まずは必ず争点となるのが「仕様変更か、欠陥か」だ。発注側も業者側も主張が通らなければ費用の負担が発生するので、簡単には譲れない。ここでポイントとなるのが、要求仕様の明確さだ。　要求仕様書の記述が明確であれば、それが欠陥であるかどうかは即座に判明する。例えば、仕様ではある計算を行う条件が「1000以上」となっているのに、実際のシステムでは900で計算が実行されているのであれば、明らかに欠陥である。

　問題になるのは、このような明確な要求仕様がない場合が多い。発注側には、細かい条件をいちいち記述しなくても分かるはずという“思い込み”と“希望的観測”がある。正常処理のみが記述され、例外処理や異常処理が記述されていないという例も多い。そのため、業者側は自身の業務知識や経験を頼りに、仕様書の行間を埋めていくことになる。かくてシステム構築は“麗しき誤解”のうえに作業が進められ、最後の最後になって紛争が勃発するのである。

　原則的には、仕様書に書いていないこと、もしくは書いてあっても不明確でいかようにも解釈できることは、欠陥ではなく「仕様書の不備」である。誰が読んでも一意に解釈できない場合、業者の解釈が欠陥であるとは、必ずしもいえない。

　他方で、仕様書に記述されているにもかかわらず、読解力不足で意図しない結果となったのであれば、それは「欠陥」である。付け加えるならば、要求事項に不明な点があるとき、それを明確化するのが専門家としての責任であろう。その努力を怠り、勝手に解釈しておきながら、問題が起きてから仕様が不明確であると指摘するのはどうかと思う。

　仕様変更か、欠陥か、双方が利己的な主張をする前に、自らの「甘え」を自省すべきであると思う。発注側は要求仕様書が明確に書かれているか、業者側はあいまいな要求仕様を明確化する努力を怠っていないか、勝手に作り手側だけの論理で解釈しなかったか。まずは、それぞれが各自の非を認めるところから始めなければ泥沼の水掛け論にはまり込むだけで紛争は解決しない。たとえ法廷で争って勝ったとしても、金銭的に解決が図られるだけで、システムは完成しない。争議によって失った時間を取り戻すことはできないのである。

常識と非常識のボーダーライン

　「仕様書に書いてなくても、機能として盛り込むのが常識だ」という主張がなされる場合がある。こうしたときは、その“常識”が本当に常識的なものであるかどうかが争点となる。ところが、この常識というのが非常にあいまいであり、どこまでを常識というのかがはっきりしない。　確かに業界標準となっている業務プロセスや業務用語などは、その業界に精通しているものにとっては、常識である。しかし業者は、果たしてどれくらいその業界に精通しているものなのだろうか。そもそも業界常識に精通している業者だけが、その業界のシステム開発を受注しているという常識は成り立たないであろう。たとえ、精通していたとしても業界の標準的な業務についての知識であって、あなたの会社の業務を“常識”として知っている可能性は低い。すなわち、「わたしの常識は、あなたの非常識」が真理であって、暗黙の了解に依存すれば、麗しき誤解を生むだけだ。

　仕様書に書いてなくても、常識であると主張できるほど、業界標準にのっとった業務プロセスになっているといえるかどうか、はなはだ疑問である。自社内だけで通用する常識を振りかざして、「そんな機能は当然、盛り込んでいないのは欠陥だ！」と声を張り上げるのは、かなり乱暴だと思う。

　業者は自社業界の専門家ではなく、コンピュータ業界の専門家であるということを前提に仕様書をまとめれば、暗黙の了解や大前提の省略による誤解も少なくなる。

　一方でコンピュータ利用における常識は、事細かに記述する必要はない。例えば、システムが障害を起こした場合にデータベースなどを障害前に回復し、安全にシステムを再起動できるような機能を備えることは、仕様書に明記していないとしても、システム構築の専門家として常識的に盛り込んでいなければならない。こうしたことを“提案”できない業者は考え直した方がよいであろう。