  |
はてなキーワード: パッケージソフトウェアとは
電源機器などの製造販売を業とするユーザー企業が、商品の販売・生産管理を一元管理するシステムの構築をITベンダーに依頼した。開発はITベンダーが提案したパッケージソフトを利用する形で行われ、システムは納品されたものの、稼働後、多数の不具合が発生した。また、このパッケージではユーザー企業がこれまで行ってきた「新規品」「前同品」「修理品」のうち、「前同品」の管理しかできず、開発中からベンダーにカスタマイズ要望を行っていたにもかかわらず、ベンダーがこれに対応しなかった。そうしたこともあり、このシステムは業務に使えないとユーザー企業は判断し、稼働を停止した。
ユーザー企業は、前述の管理部分をITベンダーが開発しなかったことは債務の不履行にあたると訴訟を提起したが、ITベンダーは、この開発の方針はユーザー企業の業務をパッケージソフトウェアの機能に合わせて改善する「フィッティング方式」で行うことで同意されていたはずであり、「新規品」や「修理品」の管理は別の手法で行うはずだったと反論した。
本件における新規品は、まだ市場に投入されていない新製品、前同品は既に売り出して市場に出回っている製品、そして修理品は文字通り修理対象の製品を指す。確かにITベンダーが提案したパッケージソフトウェアでは製品をこのように区別しておらず、結果として「前同品だけ」しか管理できなかった。
ベンダーは当初、パッケージソフトウェアを業務に合わせるカスタマイズ方式を提案したが、ユーザー企業から「パッケージソフトウェアのカスタマイズは行わない」「機能が足りない場合は、業務の方をパッケージソフトウェアに合わせて改善する」という方針を示され、基本的にフィッティング方式で行うことになった。ITベンダーはそれを前提にパッケージソフトウェアを選択し、提案した。だがユーザー企業は途中からカスタマイズ要望を多発し、プロジェクトは実質カスタマイズ方式に変わってしまった。
フィッティング方式とカスタマイズ方式のどちらを採用するかは、その後の要件定義や開発に大きな影響を与える。
カスタマイズ方式の場合、ベンダーは、ユーザー企業の業務をよく把握して要件を定義し、さらに必要と考えられる機能については、仮にユーザー企業から指示されなくても要件と捉えて、開発しなければ債務不履行に問われる可能性が出てくる（必ずとは限らないが）。
フィッティング方式を採るなら、主として汗をかくのはパッケージの機能に合わせて業務を変えるユーザー企業ということになる。パッケージの機能は変えず、設定をどうすればよいのかを決めていけばいいので、ITベンダーの手間は少ない。
当初しなくてもよいと思っていた機能の追加や変更が、ユーザー企業の翻意によって変わってしまう、つまり開発中にフィッティング方式からカスタマイズ方式に変わると、当然、プロジェクトは混乱する。ITベンダーの作業は増えるし、業務知識も補足しなければならない。しかもこうした変更要望はランダムに言われるため、スケジュールもコストも計画から逸脱することになる。
本件の場合、特に大きかったのは「新規品」と「修理品」への対応だ。これらの機能はユーザー企業の既存システムには具備されていた。しかし、パッケージソフトウェアにはこれらに対応する機能がない。
カスタマイズ方式で開発を行うなら、恐らく必ず実装しなければならない機能だっただろう。しかし本件では、ユーザー企業自身が「業務をパッケージソフトに合わせる」と言ってしまっている。であれば、ITベンダーがこれを作らなかったのも致し方のないところだ。
他方で、作ったシステムは結果として業務には使えない。いくらフィッティング方式だからといって、業務が成り立たないほど乖離（かいり）したシステムを納品するのはITの専門家として許されないのではないか――ユーザー企業はそんな思いで裁判に訴えたと想像できる。
ユーザー企業の提示した（中略）提案依頼書には、本件新システム構築の「基本方針」として「1 システム構築には標準パッケージで構築する、2 カスタマイズは行わない、3 標準パッケージで合わないところは業務をパッケージに合わせる 標準パッケージで対応の取れない部分はパッケージに業務を合わせる」などと記載されて（中略）いる（基本方針はフィッティング方式である）。
（中略）
ユーザー企業は、（中略）新規品、修理品の関連業務について（中略）フィットアンドギャップ分析（中略）概要設計（中略）詳細設計および開発を行う義務を負っていたのに、（これらを）行わなかったのは（中略）債務不履行であると主張する。しかし（両者が合意した開発方式がフィッティング方式である以上）、ユーザー企業側の上記主張は採用することができない。
