EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

「開発の目的」をどこに記載してますか?システム開発の契約に潜む落とし穴

edited by DB Online   2020/12/23 09:00

 システム開発において、皆さんは“開発の目的”をどこに記載していますか? 今回は“開発の目的”の記述に関連する、思わぬ落とし穴について紹介します。

要件に勝るシステム「開発の目的」の重要性

 この連載で以前にも取り上げましたが、システム開発や導入においては要件よりも、目的に資するモノを作ったのか? のほうが大切という判断を裁判ではよく見られます。

 たとえばユーザーが「営業力を強化して顧客に対する提案数を2倍とし、売上を30%上げること」を目的に、営業支援データベースの構築をベンダーに依頼したとします。ところがベンダーは、納期までに必要な機能を作り上げることができませんでした。

 それでも、なんとか使うことはできるからとユーザーに費用を請求したが、機能不全を理由に、ユーザーが支払いを拒んだとします。その場合、実装できなかった機能がたとえばシステムの運用管理に関わる部分で、営業支援の機能自体は実装されているようなケース、あるいは営業支援のメイン画面がユーザーの想定とは異なり使いにくいと感じるが、それでも使うことはできるというようなケースは、どう判断されるのでしょうか。

 裁判所は約束した機能が過不足なく実現できているかというよりも、ベンダーの作ったものがユーザーの目的である提案数2倍、売上30%増に役立ちそうなものであれば、システムの完成を認めて、ユーザーに支払いを命じる場合が多いように思えます。

 この場合、もちろんまだできあがっていない機能については“追完”つまり、納品後に完成させる必要はありますが、とにかく債務不履行による契約解除となり、お金を一銭も貰えないということにはなりにくいと言ってよいでしょう(※)。

※少し補足すると、この場合、実際にユーザーの目的である提案数2倍、売上30%増が達成できたかが、問題なのではありません。そうするために必要な機能が実装されていれば、ベンダーの責任はそこまでです。

 また、これとはまったく逆に、要件として定義されていない機能であっても契約の目的を考えれば、これは当然実装すべき機能であると裁判所が判断して、システムの完成が認められなかったという例もあります。

 こうした事例を見ていると、IT開発プロジェクトにおいて要件定義は、必ずしも完全なものではなくどうしても抜け漏れや誤りが避けられないものであることを、裁判所はある程度理解しているとも思えるわけです。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心にITベンダ及びITユーザ企業に対するプロセス改善コンサルティング業務を行なう。現在は、東京地方裁判所でIT開発に係わる法的紛争の解決を支援する傍ら、それらに関する著述も行なっている。 おもな著書に、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』 日本実業出版社、『IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』。

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

All contents copyright © 2007-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5