前回に続いてアプリケーション・パッケージの採用を前提としたシステム構築の話題である。

　今回は「業務の学習に2カ月も付き合ってはいられない。パッケージを採用したわけだから，我々は可能な限り，業務をパッケージ合わせるつもりである。そのためには，当社がどうであるかにかかわらず，まずベンダーとしてのベストプラクティスを提案して説明してほしい」というのがユーザーの言い分であるという第2のケースである。

　このケースの問題に立ち入る前に，パッケージ・ソフトのジレンマについて考えてみたい。

　今からさかのぼること二十数年前の1980年代，パッケージ・ソフトは基本的に信用されていなかった。パッケージ・ソフトを売り込みに行くと，「我が社の業務はそんなパッケージがごときにカバーできるほど簡単ではない」とことごとくあしらわれたものである。パッケージ・ソフトは様々な企業の様々なケースに対応してくることで鍛えられてきたから，むしろ業務のやり方をパッケージ・ソフトに合わせた方が賢明である，と言ってもまず相手にされなかった。今思えば，仮に半分くらいはそうだと思ったとしても，断り文句という意味合いもあったのかもしれない。

　それがどうだろう，1990年代にはいると「業務をパッケージソフトに合わせる派」の方が多くなってしまった。それはそれで間違いではないのだが，ものごとすべて程々のバランスであれば長所となっても，度が過ぎるとたちまち短所になる。宣伝する側は，おそらく気持ちを込めて実態よりも少し良く見せるようなことを言う。ところが，顧客側はそれ以上に期待を込めて購入してしまうらしい。パッケージ・ソフトのパッケージとしての良いところと，一般に認知されているパッケージ導入のメリットや売り文句との間にギャップがある。

　ERPパッケージをはじめとするアプリケーション・パッケージ導入では，よく「フィット＆ギャップ」という言い方でパッケージソフトのどこをどういうふうにカスタマイズするか検討するプロセスが行なわれるが，だからといって上流工程である要求定義をしなくて良くなったわけではない。

　一部の例外を除いて，多くの企業ではERPパッケージではカバーできない種類の業務のやり方や独自のプロセスを持っている。そしてそれが，企業のアイデンティティとなり，また業界における優位性の源泉となっている。アイデンティティがはっきりした強みを持っている企業ほど，業務をパッケージに合わせれば合わせるほど業務の特徴や強みは失われてゆく。標準化というのは，標準以下の人々にとってはメリットが大きいが，標準以上のレベルを持っている人々にとっては時としてレベルダウンになってしまう。

　要求定義を行う側として注意しなければならないのは，ユーザー側が言った言葉を真に受けてはいけないということである。特に「業務をパッケージ合わせるつもりである」というこの言葉を100％信じてはいけない。実際にパッケージのベースとなる基本テンプレートを見せたら，必ずいくつもの受け入れ難い食い違いに遭遇するということである。このケースでも「業務をパッケージ合わせるつもりなんじゃなかったでしたっけ」と言ったところで「まさかそんなやり方だとは思っていませんでした。当社の考え方とは違うのでちょっとそれは譲れませんね」となるのは見えていた。

　根源にあるのは，その企業の経営に対する考え方や長年つちかってきた企業文化と，パッケージが成長してきた背景にある設計思想や経営に対する考え方の間に存在するギャップであり，このギャップは容易に越えることはできない。だから，ギャップが浅いことが確認できているならばユーザーの要望どおり自信を持ってベストプラクティスを語ったらいいだろう。しかし，それが見えていないのであれば，ベストプラクティスを提案するのはリスクが大きい。ユーザー側の期待がトーンダウンしてしまったり，難しい機能要求になってベンダー側が逃げ腰になってしまうかもしれない。

　そこで，ようやく今回のケースの話にはいるわけだが，まずアプリケーション・パッケージを採用し非常にうまくいっているモデル企業をユーザーと一緒に訪問することから始めることにした。ユーザー訪問というのは現実にはなかなかタイミング良く手配できるものではないが，単なる売込み目的のユーザー訪問ではなく，導入を成功させるための学習目的だということでモデル企業側も快諾してくれた。

　リスクが高いベンダーによるプレゼンテーションを回避し，比較的素直に話が聞けるユーザー訪問という形式にすり替えたわけでずるい手だと言われても仕方がない。しかし，生々しいユーザー事例を見ることによって，ユーザーにアプリケーション・パッケージをよく理解してもらい，同時に自社の特殊性について気づいてもらえたので結果は満足すべきものだった。

　ユーザー訪問から戻った最初のミーティングで「パッケージのことは大体わかりました。このパッケージをうまく生かすポイントも少し見えました。一から説明していただくよりも，当社のやり方とパッケージの考え方の違いに焦点を絞ってどうすればいいか方向性を決めませんか」という発言が飛び出した。

　なんとか，第一のケースと同じスタートラインに立つことができたようである。

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