◆仕様変更か欠陥か
まずは、かならず争点となるのがこれだ。発注側が「欠陥」であると主張するのに対し、業者は、それは仕様に書いていなかったので「仕様変更」であると反論される。主張が通らなければ、是正の費用を負担することになるので、どちらも簡単には譲らない。ここで、問題となるのが要求仕様の明確さである。要求仕様書に記述されている条件が明確であれば、それが欠陥であるかどうかは、即座に判明する。
例えば、ある計算を行う条件が、１０００以上の場合に、９００で計算が実行されれば、明らかに欠陥である。ところが、問題になる場合は、このように要求仕様が明確に記述されていない場合が多い。条件を数値ではなく、業務用語で記述してあったりする。発注側からすれば、その業務用語で表現しておけば、細かい条件を数値で一々記述しなくても分かるはずという「思い込み」がある。
また、要求事項には正常なケースに対する処理を記述すれば、当然、例外処理や異常処理は、業者が考えて作りこんでくれるものと思っている。業者側も、自らの業務知識や経験を売りにして、顧客に「そこまで書かなくても分かります」といった感じで、要求分析が進められることが少なくない。日本独特の、一から十まで言わせない、聞かないというところである。かくしてシステム構築は、「麗しき誤解」の上に作業が進められ、最後の最後になって紛争が勃発するのである。
そして、この紛争を解決する慣習が、先に述べた２：４：２：３である。つまり、当初、２の要求に対し、最後に４であったことが判明する。しかし、予算は２の見積もりで確保されているので、折衷案として、発注側は要求事項を１取り下げ、業者は、１無償で追加開発することで、３に落ち着くというものだ。結局、双方が痛み分けとなり手打ちとなる。まさしく、ＩＴ業界の悪しき商慣行である。
著者の立場は、仕様書に書いていないことや、書いてあっても不明確であり、いかようにも解釈できることは、欠陥ではないとする。誰が読んでも、一意に解釈できないということは、業者の業務知識なり経験を信頼して「お任せ」したのであるから、それを一概に「欠陥」と決めつけるのはどうかと思う。一方で、仕様書に記載されているにもかかわらず、読解不足で意図しない結果となるのであれば、それは「欠陥」である。
読みやすいか、読みにくいかは、問題ではない。専門家としての注意義務がある。よく読めば、確かに記述されているにもかかわらず、読みにくいので気が付きませんでした、というのでは通らないと思う。さらに、専門家として注意を払い、要求事項に不明確なヶ所がある場合、適切な質問なりして要求分析段階で、明確にしておく努力を怠り、勝手に解釈してプログラムを作っておきながら、後で「仕様書が不明確」であることを理由に、過失責任を逃れようとすることは、法律でも認められていない。
仕様変更か、欠陥か、双方が利己的な主張をする前に、自らの「甘え」を自省すべきであると思う。発注側は要求仕様書が明確に書かれているか、業者はあいまいな要求仕様を明確化する努力を怠っていないか、勝手に作り手側だけの理論で解釈しなかったか。まずは、それぞれが各自の非を認めるところから始めなければ泥沼の水掛け論にはまり込むだけで、なんの利得もない。例え法的に争って勝ったとしても、金銭的に解決が図られるだけで、システムは完成しない。争議によって失った時間を取り戻すことはできないのである。
コメント