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

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

テーマ別に探す

いい加減なRFPや認識のズレから裁判沙汰へ 悲劇を生まないためにIT部門が身につけるべき巻き込み力

edited by DB Online   2021/07/30 09:00

 今回は、曖昧な要件定義が招くトラブルについて紹介します。ユーザー企業側とベンダー側の認識のズレはどこから生まれるのでしょうか。判例をもとに見ていきましょう。

曖昧な要件定義は裁判沙汰の定番

 曖昧な要件がシステム開発のトラブルを生むという事例は、もはや裁判の定番と言ってよいくらい数多く見られます。ユーザー企業側で、システム開発の企画と開発ベンダーへの発注を担当する部門は、要件定義か、あるいはそれよりも前の提案依頼書(RFP)の段階からエンドユーザー部門によくヒアリングして、本当に業務に役立つシステムを作っていく必要があります。

業務に役立つシステム開発の第一歩はヒアリング」
業務に役立つシステム開発の第一歩は、よいヒアリングからはじまる

 しかし実際にはそれをやりきれず、中途半端な要件定義がエンドユーザーやシステム部門、それに開発ベンダーの理解不足を招き、トラブルを引き起こすことが現実に数多く起きています。

 今回取り上げるのは、まさにそうした事件です。曖昧な要件を提示したユーザー企業と、それを勝手に理解したつもりの開発ベンダー。この争いの顛末を通して、システムのユーザー、特にシステムを発注する部門の責任について考えてみたいと思います。まずは事件の概要から見てみましょう。

(東京高等裁判所 令和 2年 1月16日判決より)

 あるインターネット・サービス・プロバイダ事業者(ISP)が、自社の基幹システムの開発に関する提案依頼書(RFP)をソフトウェア開発ベンダー(開発ベンダー)に交付し、開発ベンダーは、これに対する提案書を提示して両者の間にシステム開発請負契約が成立した。開発ベンダーが請負ったのは、新システムの要件定義から設計、製造、テスト工程までのすべての工程だった。

 作業はRFPと提案書の内容を確認しながら開発ベンダーが要件定義書をまとめることから始まり、その後、基本設計、詳細設計と進んだが、その後、双方の要件の理解に齟齬があることが発覚して、プロジェクトは混乱し、結局、システムが完成しないまま請負契約は解された。

 要件定義上の問題点は数多くあったが、その中にはエンドユーザー部門であるカスタマー部門で使用する「統計・カスタマーツール」機能に関する認識齟齬もあった。

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


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


著者プロフィール

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

    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