【ITニュース解説】業務にそぐわないパッケージソフトウェアを導入したから訴えます。選んだのは私ですが

今回のニュースは、企業が新しいシステムを導入する際によくある問題点を浮き彫りにしている。あるユーザー企業が、自社の業務を効率化するためにパッケージソフトウェアを選び、その導入作業をITベンダーに依頼した。しかし、システムが実際に稼働した後、ユーザー企業は「このソフトウェアは私たちの業務に合っていない」と主張し、導入を担当したベンダーを訴訟に踏み切ったという内容である。これに対し、ベンダー側は「その業務要件については聞いていなかった」と反論している状況だ。

システム導入プロジェクトは、一般的に、企業が抱える課題をITの力で解決し、業務をより良くするための取り組みである。まず、企業は「何をしたいのか」「どんな問題を解決したいのか」を明確にする必要がある。これが「要件定義」と呼ばれる工程だ。例えば、「顧客情報を一元管理して営業効率を上げたい」「在庫管理を自動化してロスを減らしたい」といった具体的な目標を設定する。この要件に基づいて、システムをゼロから開発する「スクラッチ開発」か、既に市場にある製品を利用する「パッケージソフトウェア導入」か、といった導入方式が検討される。

パッケージソフトウェアは、特定の業務機能（会計、人事、生産管理など）を汎用的に提供するために作られた既成のソフトウェアである。導入コストや開発期間を抑えやすいというメリットがある一方で、自社の独自の業務プロセスに完璧にフィットしない場合があるというデメリットも持つ。そのため、パッケージソフトウェアを導入する際には、自社の業務内容とパッケージの標準機能との間にどれくらいの「適合（フィット）」があり、どこに「ずれ（ギャップ）」があるのかを詳細に分析する作業が不可欠になる。これを「フィット＆ギャップ分析」と呼ぶ。ギャップが大きい場合、業務プロセスの方をパッケージに合わせて変更するか、パッケージを自社向けにカスタマイズ（改修）するか、といった判断が必要となる。

今回のニュースでは、この「フィット＆ギャップ分析」が十分に、あるいは適切に行われなかった可能性が高い。ユーザー企業が自らパッケージソフトウェアを選定したということは、選定段階で自社の業務との適合性を評価したはずである。しかし、導入後に「業務に適合しなかった」と訴えるということは、選定時の評価が甘かったか、または選定後の詳細な要件定義フェーズで、ベンダー側に必要な情報が十分に伝わらなかったかのどちらか、あるいは両方が考えられる。

システム開発や導入プロジェクトにおいて、ユーザー企業とベンダーはそれぞれ異なる役割と責任を負う。ユーザー企業は、自社の業務を最もよく理解している立場として、何をしたいのか、どのような課題を解決したいのか、そのためにどのような機能が必要なのかといった、具体的な「業務要件」を明確に提示する責任がある。また、選定したパッケージソフトウェアが自社の業務に合うかどうかの最終的な判断を下すのもユーザー企業である。一方、ベンダーは、ユーザー企業から提示された要件を正確に理解し、その要件に基づいて最適なシステム設計を提案し、合意された範囲内でシステムを導入・構築する責任がある。パッケージソフトウェアの導入であれば、その設定、必要なカスタマイズ、そしてシステムが安定して稼働するための技術的なサポートが主な役割となる。

今回のケースでベンダーが「そんな要件、聞いてないよ！」と反論している点から、ユーザー企業が訴えている「業務に適合しなかった」という内容は、ベンダーが事前に把握していた導入範囲や提供サービスに含まれていなかった可能性が示唆される。つまり、ベンダーは契約に基づき、選定されたパッケージソフトウェアを指定された通りに導入し、設定を行ったが、そのソフトウェアがユーザー企業の「特定の、しかしベンダーには伝えられていなかった要件」を満たさなかったために問題が発生した、という見方ができる。

このような事態を防ぐためには、プロジェクトの初期段階から、ユーザー企業とベンダーの双方が密接にコミュニケーションを取り、相互理解を深めることが極めて重要だ。特に、要件定義の工程では、ユーザー企業は自社の現状の業務プロセス、理想とする将来の業務プロセス、そしてシステムに求める機能を具体的に、かつ詳細にベンダーに伝える必要がある。ベンダーは、それらの要件を技術的な視点から精査し、パッケージソフトウェアで実現できることとできないこと、カスタマイズの必要性やその影響、費用などを明確に説明し、双方で合意形成を図らなければならない。この合意内容は、後で認識の齟齬が生じないよう、必ず書面（要件定義書、基本設計書など）で残しておくことが不可欠である。

システムエンジニアを目指す者として、このニュースから学ぶべきことは多い。一つは、ユーザー企業の「言葉」の裏にある「本当のニーズ」を深く掘り下げて理解する能力の重要性だ。単に言われた通りのシステムを作るだけでなく、それがユーザーの業務に真に貢献するかどうかを常に考え、疑問があれば積極的に問いかけ、提案する姿勢が求められる。もう一つは、プロジェクトの各フェーズにおいて、どのようなリスクが存在するかを予測し、そのリスクをユーザー企業と共有し、早期に解決策を合意形成する重要性である。そして何よりも、プロジェクトの進行に関する重要な合意事項は、必ず文書として記録し、両者の間で確認し合うという徹底した文書化の習慣が必要である。曖昧なままプロジェクトを進めることは、最終的に今回のような大きなトラブルに発展する可能性を秘めている。