SHOEISHA iD

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

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

最新イベントはこちら!

Security Online Day 2025 春の陣(開催予定)

2025年3月18日(火)オンライン開催

Enterprise IT Women's Forum

2025年1月31日(金)17:00~20:30 ホテル雅叙園東京にて開催

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

お申し込み受付中!

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

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

『EnterpriseZine Press』

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

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

カスタマイズ要件で定義されない機能は現行通り?

 昨今は、ソフトウェアを一から作るスクラッチ開発はすっかり影を潜め、ベンダが提供するパッケージソフトウェアやクラウド上で提供されるアプリケーションあるいはサービスを自分達向けにカスタマイズ、変更して自社のITを構築することが、すっかり定番となった感があります。こうしたやり方は、一般にITコストが抑えられ、品質もある程度担保されることから、ユーザ企業にとっては、メリットも大きいのですが、一方では、もともとパッケージやクラウドサービスが持っている機能と、自社がこれまでのシステムで使ってきた機能が違うことで、問題になるケースもあります。

 これは、私が時々、取り上げる例ですが、私の知るある企業で、生産管理のパッケージソフトを導入しようとしたとき、その機能が、ある意味便利すぎて問題になったことがあります。そのパッケージソフトは、製品の開発に遅延が生じたとき、スケジュールを遵守するために、開発に参加しているメンバーへの仕事の配分を勝手に調整してくれます。Aさんの作業が3日遅れているなら、作業が進んでいるBさんにAさんを手伝わせて、全体のスケジュールを守るように人員計画を作ってくれるのです。

 ところがその会社では、常日頃から自社の生産性を計測して業務改善に役立てようとしていましたので、遅れたものは遅れたものとして管理し数値化しなければなりませんし、事実、それまで使っていたシステムでは、勝手に要員を入れ替えてスケジュールを守る計画を立てさせるようなことをしていませんでした。新しいパッケージソフトでは、そうした悪い数字を取り込めないので、業務改善に必要なデータを得ることができないのです。

 この会社ではシステムの開発中に、このことに気づき、パッケージソフトを自分達の昔の姿に近いように改造することで対応ができました。しかし、世の中を見てみると、このようにパッケージの機能と自分達の今までのやり方が違い、しかもそのことを要件定義時に気づかずにモノづくりをしてしまった結果、こんなはずではなかったとエンドユーザからクレームの絶えないシステムになってしまうという例が、かなり多くあります。今回は、そんな例について、お話ししましょう。

カスタマイズ要件に記されなかった要件への対応を巡る争い

 (東京高等裁判所 平成27年6月11日判決より)

 あるユーザ企業が、自社の販売管理システムの刷新をベンダに依頼し、ベンダは、あるパッケージソフトウェアをカスタマイズして構築することを提案して、ユーザもこれに同意し、開発が開始された。システムは、パッケージソフトウェアの改造点をとりまとめた「カスタマイズ機能一覧」を要件として開発をしたが、それは全ての要件を網羅したものではなかった。一方で、契約前にベンダが示した提案書には、新システムにおいても「現状の機能を網羅すること」という記述があった。

 販売管理システムというのは、顧客からの注文を受け付けてその商品の在庫を調べるとともに代金を請求する。顧客から入金があったら、その情報を管理するとともに出荷を指示するというものです。これを機能として羅列すると、「注文受付」「在庫管理」「請求」「入金管理」「出荷管理」といった具合でしょうか。このくらいの粒度であれば、新しいパッケージソフトもユーザが元々使っていたシステムにも同じようなものがあったでしょうから、ベンダが提案書で言っていた「現行機能の網羅」というのも実現できることになります。

 しかし、ITの導入における要件定義というのは、これらをもっと細かくブレークダウンして行われます。注文受付にはどんな画面を作るのか、在庫管理の単位は個々の商品毎の他にそれを組み合わせたセット商品があるかないか、請求に分割払いはあるか、支払い方法は現金・クレジットカードの他に何があるのか。そういう細かいところになると、新しいパッケージソフトウェアと既存のシステムの間には、多々の違いがあり、パッケージソフトウェアの方を改造する必要が出てくるわけです。その改造点を取りまとめたものが「カスタマイズ機能一覧」と言うことになり、開発(改造)は、これを元に行われます。

 とはいえ実際に開発を進めていくと、当初作ったカスタマイズ機能一覧にはない部分で、ベンダがどう作れば良いのか迷う部分もたくさん出てきます。「入金管理」と言うけれども、銀行やクレジットカード会社には、どのようなタイミングでお金が支払われていることを確認するのか、出荷管理には戻入(一度、出荷したが、なんらかの事情で帰ってきてしまった商品)の管理が必要かなど、当初は気づかなかった問題が出てきます。これは、システム開発を人間が行っている以上、どうしても避けられないことです。

 このシステムでも、どうやらそうしたことが沢山あったらしく、事件の概要は以下のように続きます。

  (東京高等裁判所 平成27年6月11日判決より)

 ベンダは,本件システムを構築した後、ユーザに対して、システムの説明会を行ったが,ユーザからは機能の不足等が複数指摘され、ベンダはこれに対応する為、追加カスタマイズ契約を結んで、これに対応したが、ユーザはそれにも納得せず検収を行わなかった。

 ベンダは、ユーザに支払いを求めて訴訟を提起したが、ユーザ側は、ベンダが約束した機能を実現しなかった(債務不履行)として、損害賠償請求の反訴を提起した。

次のページ
要件として定義されないものは「現行通り」か「パッケージに従う」か

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

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

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/10622 2018/04/27 06:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング