機能・仕様に関する紛争の発生原因と予防のためにベンダーがすべきこと

IT・情報セキュリティ
尾城 亮輔弁護士 尾城法律事務所

 当社はベンダーです。システム開発を進めていく中で、ユーザーから仕様変更要望が出されるのですが、仕様書の内容が曖昧なことが多く、当初の費用内で無償対応して欲しいといわれています。仕事を受けている立場上、無償対応を断ることができません。その結果、プロジェクトの工数が増え、収益性が上がらない状況となっています。なぜ、このようなことが起きるのでしょうか。また、そのようなことを防ぐためにはどのような対策をすべきでしょうか。

 システムというのは複雑なものであり、性質上、仕様に曖昧さが残ってしまうのはやむを得ない面がありますが、そのような仕様の曖昧さが紛争の原因となってしまいます。
 このような事態を防ぐためには、合意に至るまでのプロセスを確保することが重要です。ユーザーの関係者をプロジェクトに関与させて、きちんと説明をすること、およびそのことを議事録などの証拠として残すことが紛争予防の対策となります。

解説

目次

  1. 機能・仕様とは何か
  2. 債務内容の明確化は難しい
    1. システムの複雑さ
    2. 関係者の理解不足
  3. ベンダー担当者としてどうすべきか
    1. ユーザーの関係者にプロジェクトに参加するよう要請すること
    2. 仕様の内容やシステム開発のプロセスをよく説明すること
    3. 合意内容とプロセスを証拠として残すこと
  4. まとめ

機能・仕様とは何か

 システム開発プロジェクトでは、「機能」や「仕様」といった単語がよく使われます。

 いずれも明確な定義があるわけではないのですが、「機能」というのは、システムを使って実現・処理される内容のひとまとまりを意味します。たとえば、在庫管理システムであれば、商品が倉庫に届いたときに商品の登録などを行う「入庫受付」や、在庫として登録されている商品の種類や数を表示する「在庫照会」というようなものです。

 「仕様」というのは、そのシステムが備えているべき内容や性能を意味します。標準的なシステム開発プロジェクトでは、機能ごとに仕様書と呼ばれる文書が作成され、その仕様書に記載されている内容が、ベンダーの開発すべき債務内容となります。

機能と仕様の例

債務内容の明確化は難しい

システムの複雑さ

 上記のように、システム開発を法的な観点から見た場合、仕様書に記載された内容が、開発契約でベンダーが負う債務であるということになります。このように設計書(仕様書)が作成され、その内容に基づいて開発が進められるという点は、建物の建築などと大きく異なるわけではありません。

 しかし、情報システムというのは複雑なものであり、仕様書にシステムのすべてを記述するのは極めて困難です。
 たとえば、「5人のオペレーターからの同時入力ができること」という要件があったとします。この場合、6人目のオペレーターが同時に入力をした場合にどのように処理すべきか、以下のように様々な処理方法が考えられます。

  1. 6人目のオペレーターも入力できるが処理速度が遅くなる
  2. 6人目のオペレーターだけが入力できなくなる
  3. 6人全員の入力ができなくなる

 上記の3つの方法のうち、どの方法が一番よいかは客観的に定まるものではありません。ユーザーは①と考えていたのに、ベンダーは②と考えていたというように、ベンダーとユーザーとの間で認識の相違が顕在化したときに、トラブルが生じうるということは容易に想像できると思います。このような、一見単純なように見えることでも、例外時のパターンなどを考えると、非常に複雑なものとなり、すべてを網羅して記述するのは難しいのです。

関係者の理解不足

 上記のようにシステムの内容を確定させるためには、様々な場合を想定して、細かい部分まで検討を重ねていく必要があります。そのためには、ユーザー、特に、そのシステムを実際に利用することになる利用部門に、プロジェクトに関与してもらう必要があります。

 しかし、ユーザーの利用部門の担当者というのはシステムの専門家ではありません。仕様を検討する段階では、紙に印刷された仕様書案がベンダーから示されることが多いのですが、そのような担当者からすると、具体的にプログラムとして動くものを操作してみなければ、どのような画面になり、その画面上でどのような操作をすることになるのか、さらには仕様書案の内容で業務を十分処理できるのかといった点を把握するのは容易ではありません。

 また、ユーザーの担当者が、システム開発のプロセス自体について十分理解していないこともあります。実際、紛争になった場合には、ユーザー担当者から、「仕様書でこのようなシステムになると説明を受けていたが、プログラムとしてできあがった段階で、また修正できると思っていた」と主張されることがあります。

ベンダー担当者としてどうすべきか

ユーザーの関係者にプロジェクトに参加するよう要請すること

 上記のように、システムの仕様には、客観的な正解というものはありませんから、システムの内容を検討し、合意に至ったというプロセスを確保する必要があります。仕様を決めるための会議体を組織し、定期的に打合せを行うことが必要ですが、もし、必要な担当者が打合せに参加をしていないようであれば、参加を促す必要があります。

仕様の内容やシステム開発のプロセスをよく説明すること

 ユーザーが、仕様の内容やシステム開発のプロセスについて十分に理解していないのであれば、ベンダーは、ユーザー側の情報システム部と連携して、十分な説明をするべきです。特に、仕様について合意することを「仕様凍結」といいますが、「仕様凍結」をするにあたっては、仕様が合意され、今後の変更は原則として有償対応となるということを明確に説明し、配付資料等にもそのことを記載しておくことが望ましいといえます。

合意内容とプロセスを証拠として残すこと

 以上のようなことを実践したとしても、そのことを証拠として残さなければ意味がありません。そこで、合意までの経過や合意した内容を議事録などの書面に記録する必要があります。

 その際、議事録には、少なくとも以下のような内容を記載すべきです。

  • 打合せの参加者(しかるべき担当者は参加したか)
  • 打合せの時間、場所(十分な検討時間を取ったか)
  • 打合せにおいて、ベンダーがどのような資料を配付したか。また、ベンダーからどのような説明を行ったのか、主な質疑応答の要旨(ユーザーが十分に検討する機会があったか)
  • その打合せで合意した内容
  • 次回までにユーザーに決めてもらう宿題事項
  • 前回の打合せの宿題事項の結果

 上記のような対策は、現場の個人の努力のみで実現するのは困難です。打合せの機会を確保することや議事録を整備することの必要性を周知し、プロジェクトの進行中に、それらが履行されているかを確認するような体制を、会社として作りあげていくことが必要です。

 また、このような体制作りは、プロジェクトマネジメントの問題として語られることが多いですが、債務の内容をどのように明確化するかという法的な問題でもあるため、法務部と事業部門が連携をすることで、より実効的な対策が実現できると考えられます。

まとめ

 システムの仕様を明確にすることは非常に難しいですが、仕様に残る曖昧さは紛争の原因となります。合意に至るまでのプロセスを確保し、そのようなプロセスを経たことを証拠化するという作業を確実にこなすことが、紛争予防の対策となるのです。

Q&Aでわかる日本版「司法取引」への企業対応 - 新たな協議・合意制度とその対応 -

無料会員にご登録いただくことで、続きをお読みいただけます。

1分で登録完了

この実務Q&Aを見ている人はこちらも見ています

無料会員登録で
リサーチ業務を効率化

1分で登録完了

無料で会員登録する