SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Data Tech 2024

2024年11月21日(木)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

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

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年秋号(EnterpriseZine Press 2024 Autumn)特集「生成AI時代に考える“真のDX人材育成”──『スキル策定』『実践』2つの観点で紐解く」

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

システム開発の検収におけるユーザの債務

 前回は東京高等裁判所における平成27年6月11日判決を例に、システムの要件定義で、ユーザがつい使ってしまいがちなNGワードをご紹介しました。「既存システムの機能の通り」「既存システムの機能を網羅・踏襲すること」…こうした言葉は結局、システムの要件を曖昧にして開発ベンダとの間に意識の齟齬を生んでしまいます。いくら優秀なベンダでも、他人の作ったシステム (同じ会社の違う担当者も含みます。) の機能や性能等の特徴を全て正確に把握してくれる確率はそう高くありません。どんなに丹念に調べても、その詳細な動作や使い勝手については理解しきれないことも多く、また、ユーザ自身も誤解している部分もあったりして、結局、前のシステムからのデグレードを起こしてしまう危険もあります。こうしたことを防ぐためには、要件を定義するとき、既存システムが持つ機能についても要件として明確に記述する必要があります。前回はそんなお話だったと思います。

ユーザが検収を拒否した事例

 今回は、同じ判例を元に「システム開発の検収におけるユーザの債務」について考えてみたいと思います。前回のお話とは別の観点ですが、同じ判決文を取り上げたものなので連続モノとして扱うことにしました。

 システム開発の最終段階において実施する "検収"。ベンダの作ったものが契約通りのものであるかを最終的に確認し、お金を払うのかを決定する検収行為がベンダはもちろんユーザにとっても非常に重要なものであることには異論はないと思います。ベンダには契約で約束した期限通りにシステム開発を完了させ、ユーザが検収行為を行う為の準備も万端に整えておく義務があります。

 一方で、ユーザは、ベンダに検収をして欲しいと依頼されれば、しかるべき時期までに受入検査を実施して、問題がなければ検収行為を行う債務があります。今回は、その辺りについてこの判決が触れた部分について見ていきたいと思います。まずは、前回と同じですが事件の概要を判決文から抜粋した部分からご覧ください。

(東京高等裁判所 平成27年6月11日判決より抜粋して要約)

 あるユーザ企業が自社の販売管理システム開発をベンダに委託し、要件定義,設計,構築,運用準備・移行サービスを内容とする開発基本契約を締結した。

 ベンダはこの契約に従ってこのシステムを開発し、ほぼ自社の作業が終わった時点で出来上がったシステムをユーザに見せながら内容の説明を行ったが、ユーザからは複数の不具合が指摘された。

 ユーザとベンダはこの指摘への対応について話し合い、結局、ユーザが追加費用を支払って開発を継続することで合意したが、追加作業を行った後もユーザは満足せずシステムが検収と費用の支払いを拒んだためベンダが訴訟を提起した。

 ユーザが費用支払と検収を拒んだ理由は主に①システムに多数の不具合が存在すること、②既存のシステムにある機能を新しいシステムが網羅していないことだったが、ベンダは①については、システム開発である以上多少の不具合混入は不可避であり、これは債務不履行ではなく瑕疵担保責任として対応すべきものであること、②については、既存システムの機能は満たしていると主張した。

 ご覧の通りこの紛争ではユーザが検収を拒否した理由が妥当であるかが問題になりました。ユーザは 「システムには不具合が多く残存しており未完成だから検収しない」 と言っています。一方でベンダは 「不具合は完成したシステムに含まれる瑕疵に過ぎず修補可能なものなのだから検収をしないユーザはシステム開発発注における責任を果たしていない」と訴えています。

次のページ
システム完成の条件とは?

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
紛争事例に学ぶ、ITユーザの心得連載記事一覧

もっと読む

この記事の著者

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

ITプロセスコンサルタント東京地方裁判所 民事調停委員 IT専門委員1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より20...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/10184 2017/12/21 06:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング