製造工程に入ってるけど、やっぱこの機能も追加してくださーい

1

2021年09月29日 07:02  @IT

  • 限定公開( 1 )

  • チェックする
  • つぶやく
  • 日記を書く

@IT

写真写真

 IT開発を巡る裁判では、システムの要件――ベンダーがどのような機能をどこまで作るのか――についての争いの割合がかなり高い。本連載でも、そうした裁判の例を幾つも解説してきた。



【その他の画像】



 ユーザー企業の「この機能を作ってくれるはずではなかったのか」というクレームに、ベンダーが「そんなことは約束していない」と反論をする。まさにIT訴訟の定番ともいうべきケースだ。アジャイル開発の割合が増えて開発中でもユーザーの要望を取り入れやすくなったといわれる今でも、こうした争いは後を絶たない。



 今回取り上げるのも、「システムの要件の範囲」あるいは「契約の範囲」を巡る裁判だ。



 簡単に説明すると、要件定義から開発までの全てを単一のベンダーが請負契約で行った。詳細設計中に要件の変更が入り、要件定義書を作り直した(新要件定義書)が、そこには想定されていなかった機能が含まれていた。



 このプロジェクトは最終的には頓挫し、ベンダーは「失敗の原因は、新要件定義書に追加された契約外の機能実装を強要されたためだ」と主張している。対するユーザー企業は、「機能追加も当初契約の内であり、ベンダーが追加費用なしで対応するべき」と主張している。



 通常であれば、ユーザー企業が要件を追加してスケジュールを乱したのが頓挫の原因と考えるところだが、このプロジェクトでは要件定義もベンダーが請負で行っている。



 途中で変更された要件に無償で対応することは、ベンダーの責務なのだろうか。



●要件定義まで請負契約にしてしまったプロジェクト



 事件の概要から見ていただこう。



ーーー



東京地方裁判所 平成31年3月26日判決から



神奈川県と静岡県にデータセンターを置くISP事業者が、両者を統合した新サービスを企図して、2つのデータセンターを統合した新しいISPシステムの開発をITベンダーに依頼した。



依頼内容は新システムの要件定義・基本設計、詳細設計・構築を請負契約で行うというもので、要件定義・基本設計まではスケジュール通りに進んでいたものの、要件定義書・基本設計書には詳細設計以降に検討を先送りしたものが含まれていた上、定義した要件についてもISP事業者とITベンダーの間に理解の齟齬(そご)がありプロジェクトは混乱した。



両者は話し合いを続けたが、結局、ISP事業者は、完成の見込みはないとして契約を解除し、ITベンダーを相手に損害賠償を求める訴訟を提起した。



この裁判の中でITベンダーは、プロジェクト混乱の一因にはISP事業者が当初要件になかった「統計・カスタマーツール」機能の取り込みという「契約外作業」を強要したためと主張したが、ISP事業者側は、当該機能は、プロジェクト実施中に変更された要件定義書(新要件定義書)で定義されており、契約外作業ではないと反論した。



---



 少し補足すると、契約の範囲内で追加機能の要件の再定義や開発は進められ、契約変更は行われなかった。また、このプロジェクトは要件定義以降全ての工程を単一のベンダーが請け負ったが、それ以前のRFP(Request for Proposal:提案依頼書)の作成にも同じベンダーが参加していた。追加機能はRFPには記載されていなかったが、旧システムには存在した機能だった。



●請負契約にすると追加機能にも無償で対応しなければならないのか



 私は、もともとITベンダーのエンジニアだったので、判決文の冒頭を読んだときにはベンダーと同じ考えを持った。要件が追加されれば機能が増えて、作業工数や費用を追加するのは当然だと思ったのだ。ただ、このプロジェクトは要件定義から構築までの全てをベンダーが請負で契約している。それを考えると、少し話が違ってくる。



 まず、要件定義を請け負っているということは、要件定義書に不備があれば、それはベンダーの責任ということになる。「統計・カスタマーツール」機能の欠落を要件定義書の不備と考えるかどうかによって結論は違ってくる。



 さらに大きな問題は、ベンダーが「全てを」請け負っている点だ。



 要件定義を含む全工程を請け負うということは、顧客から言われた要件を満たせばいいものではなく、顧客がシステム開発によって実現したい目的自体にも一定の責任を負うことになる。



 本件の場合は、「2つのデータセンターを統合して、これまでと同等かそれ以上のインターネットサービスを提供でき、かつ安定的に運用できるシステムが出来上がること」全体に責任を持つということだ。単に定義された機能要件、非機能要件を実現すればいいものではないし、システム化の目的のために行われる機能の追加、変更も契約の範囲内(契約上の費用と納期)で行う義務がベンダーにあったと考えることもできるのだ。



 しかし要件定義は顧客の要望を基に行っているものであり、後から気まぐれに要望を追加されても追加費用なしで対応しろというのは、酷な気もする。



 読者はどのようにお考えだろうか。判決の続きを見てみることにしよう。



---



東京地方裁判所 平成31年3月26日判決から(つづき)



(本件システム開発はウオーターフォール型であるので)作業の範囲は、直前の工程の成果物により定められることになり、(中略)詳細設計以降の工程については、新要件定義書(中略)に基づいて実施され(中略)不完全な旧要件定義書などに基づいて締結された個別契約によって開発の範囲が画されるものでないのはいうまでもない。



(中略)



被告は、要件定義など請負契約において、これらの業務を定額の代金で一括して請け負ったものである以上、その範囲内にある作業を実施する限度においては、それが当初の想定を上回るものであるとしても、直ちに契約の範囲外のものということはできず、これについて追加代金が発生することにはならないと解する。



---



 裁判所は要件の追加とそれに伴う作業は契約範囲「内」であると判断し、ユーザー企業の主張が認められた。



 この裁判には他にも多数の論点があり、全体としてはどちらかの主張が全面的に認められたものとはならなかった。ただ、この点についてだけは裁判所もかなりハッキリとベンダーの言い分を退けている。



●要件定義を請け負うことは、全てを請け負うこと



 本件は、要件定義から構築までの作業を一括で、請負で契約してしまったところに問題がある。



 前述した通り、全てを請け負ったら、目的達成のために必要なことは、たとえ後付けで加えられたとしも契約の中で行わなければならない。追加費用も取れない可能性が高いし、それが原因でプロジェクトが遅延しても責任を持つのはベンダーの方だということになってしまう。



 もちろん、だからといって、ユーザー企業が何を言っても対応しなければならないというものではない。システム化の目的(契約の目的)と無関係なものに対応する必要はないだろうし、ベンダーという業態から考えて非常識というものもある。また、仮に本来行うべきものであっても、あまりに過度な負担を強いるなら、ベンダーが断れたり、別契約としたりできることもあるかもしれない。この辺りは個別判断になると思われる。



 ただ、一括で請負契約を結んでしまうと、こうした危険があるということを、本判決は示している。



 被告ベンダーは大手企業であり、どちらかといえば契約についても開発についても慎重の上にも慎重を期すタイプの会社だ。そうした会社をして、なぜ、このような契約を結ばざるを得なかったのか。顧客との何らかの力関係があったからか、インターネットサービスプロバイダーという事業にそれなりの自信があったのか、判決文からはそこまでは読み取れない。



 実は、プロジェクトの終盤になって「要件定義部分を準委任契約に変更してほしい」との申し入れも行ったようだが、残念ながら全ては後の祭りだった。



 いずれにせよ、こうした例を見ると、要件定義工程までを請負で契約してしまうことはお勧めできない。



 「請負契約は全ての責任を負うもの」と考え、その上でリスクテイクを十分に行うのでなければ、恐ろしくてとてもではないができかねる、というのが私の実感だ。



 この裁判で争われたのは合計で数十億円という金額だ。会社の規模によっては経営を揺るがしかねないほどの金額を支払う羽目になるかどうかが、契約が請負か準委任かによって左右されるのである。この辺りの判断は会社全体で慎重に行うべきだと思うが、いかがだろうか。



●細川義洋



ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わった


    ランキングIT・インターネット

    前日のランキングへ

    ニュース設定