情報化戦略の策定が終了して、システム化にむけた要件をまとめる作業を実施しシステム化の手順に準じて淡々と作業をこなしていて、いざ運用段階になると想定していた機能がないとか、通常業務が複雑でまわらない、あるいは、想定以上の費用がかかってしまって、予定していた費用対効果がえられないなどのトラブルをよく耳にします。
ＩＰＡ（情報処理推進機構）のアンケート調査によると、プロジェクトの進め方の問題点のなかで、「顧客要求が不明確のまま進めている」が１位となっています。また、アンケートに答えた企業の７０％が、システム開発で失敗あるいは後悔した原因が要求定義にあったとしています。
ここでいう要求定義とは、ビジネスやシステムの課題を明らかにし、あるべき姿（要求仕様）を列挙すること定義します。
顧客要求の問題点としては、以下のようなものが想定されます。
(1)２４時間３６５日稼動とか、全社データを種々の切口で一覧として即座に参照できるなどの、過剰な要求。
(2)たくさんのデータを活用したいが、データ量は少なくて性能をあげたいという相反する要求。
(3)１年前にも同じようなことがあったという例外処理と通常処理の区別のない要求。
(4)自分が業務で使用している機能がなくなるとこまる場合にだされる局所的な要求。
(5)現行システムがある場合、現行の機能は同じで、新規で開発してほしいものしかださない要求。
このように、顧客からの要求は、戦略策定からシステム化への手順を実施した場合の全体最適でなく、部分最適であることが多いものです。
ここで、業務の現場がかかえている問題を解決するのはどうしたらいいのかは、顧客自体にもわからない場合が多いと思われます。要求定義は、それをシステム化にあたって定義する工程とした場合、上記の問題点を解消するための手立てが必要になります。
いままでの、経験や過去の事例などにより、以下のような試みが有効と思われます。
過剰な要求に対しては、
(1)システム化するための工数とシステム化による効果を課題について、要求事項として一覧にし、関連のあるものは集約して、優先度を見極める。
(2)処理の発生頻度を確認して例外処理は省くようにする。
(3)内部統制の強化がテーマのものに対して、承認処理の簡素化などの相反する要求などは優先度をさげる。
(4)システムを実装する期間が長くなるようなものは、期間、コストに影響があることによる先送り。
誤った要求に対しては、要求定義で使用される「ＤＦＤ」などで、以下のような点を確認します。
(1)データがいろいろな機能で作成されているのにそれを参照するところがないか。
(2)機能名称が一般的なものでその目的が明確になっていないか。
また、企業によって言葉の意味が微妙に違う場合、用語集を作成して意思統一をはかります。たとえば、出荷と出庫の違いや、売上の計上は、どのタイミングでするとかがあげられます。
要求に漏れがないかどうかは、前述の「ＤＦＤ」や「業務フロー」、「ＥＲ図」などで、過去の実績のある類似システムと比較して、漏れがないかどうかを確認します。
このような対応で、顧客に対して、いままで見えづらかったシステム化の上位工程の作業をできるだけ見えるようにすることが可能になります。このことは、すなわち、要求定義の品質をあげることにつながるのです。
■執筆者プロフィール
西田 則夫（Nishida Norio)
情報処理プロジェクトマネージャー、ＩＴコーディネータ
マネジメントの経験を顧客満足の向上に役立てたいと思います。
Norio.Nishida@csk.com
