アプリケーション・パッケージの採用を前提としたシステム構築では，ユーザー側（発注側）と設計/導入側（ベンダー側）の間で，作業の進め方や方法で食い違いが生じることがある。今回と次回の2回に分けて，二つのケースを材料にして考えてみたい。

　一つ目は，財務会計システムと受注/原価管理の基幹系業務システムを再構築しようというプラント・メーカーのケースである。このプラント・メーカーのユーザーの意向は，「できるだけパッケージの考え方や機能を受け入れてカスタマイズの範囲を最小にとどめたいが，同業他社とは異なる仕事のやり方もあるので，その部分はしっかり追加機能として実装する」というものだった。

　受注したベンダーは，上流工程で「フィット＆ギャップ分析」を行い，その結果を基に直ちに概要設計をした。程なくアンフィット機能の要件一覧と見積もりが提示された。

　作業はもっぱらベンダー側が用意した質問シートとチェックリストを基に行われたが，一方で「この業務のやり方はぜひこうしたい」といういくつかのポイントについては，ユーザー側から積極的に説明するように努めた。

　このプロジェクトは，ほとんど無理と思えるほどタイトな予算の下で行われたにもかかわらず，パッケージをベースにしつつ個性的なその企業の強みが光るシステムに仕上げることができた。

　成功した理由の一つは，ベンダー側がフィット＆ギャップで使用した業務テンプレートの出来の良さにあったと思う。「本来はこういうふうにデザインしたいのですが，あなた方はどうなの？」という問いかけが質問シートに織り込まれていた。そのため，質問シートに沿ってフィット＆ギャップを進めていくうちに，ユーザー側が教育されるようになっていた。

　理由の二つ目は，ユーザー側が自社の独自性をよく認識していて，ベンダーに伝えようと工夫したことであったと思う。プロジェクト・リーダーは「当社の強みと独自性7項目」というリストを作り，プロジェクト・ルームのよく見えるところに張り出した。

　パッケージ側とユーザー側それぞれに「こうありたい」という意志を明らかにして互いにぶつけ合ったプロセスが，プロジェクトを活性化し，良い結果を生んだのではないかと思う。

　さて，第2のケースは流通業で，第1のケースと業態は異なるが，財務会計システムと仕入れ/販売の基幹系業務の再構築であること，そして基本的な考え方として業務パッケージを生かした導入を行いたいという点で共通している。

　この会社は，物流のやり方や代金回収，債権管理の考え方においてあまり例のない独自性，合理性を持っており，そのことが業界内でのトップブランドの地位の源泉になっていた。

　ベンダー側が提示したスケジュールには2カ月間の業務理解フェーズと3カ月間の要求定義の線が引かれていた。ユーザー側の反応は「業務の学習に2カ月も付き合ってはいられない。パッケージを採用したわけだから，我々は可能な限り，業務をパッケージ合わせるつもりである。そのためには，当社がどうであるかにかかわらず，まずベンダーとしてのベストプラクティスを提案して説明してほしい」というものだった。

　ベンダー側のプロジェクト・リーダーは厳しい顔になった。ユーザーを支援する立場で関わっていた私は頭を抱えてしまった。（次回に続く）

●編集部からのお知らせ 木村哲氏による書籍「本当に使える要求定義」を発売しました。このブログの1回目を執筆中にゲラのチェックをしていると紹介されたものです。要求定義にまつわるエピソードはもちろん，成果物のサンプルやプロセスマップなど実践的なノウハウが満載です。要求定義に苦労している人や自分のやり方が正しいかどうか知りたい人は，是非こちらをご覧ください。