よく業務要件とかシステム要件という用語が使われます。この「要件」という言葉は、曖昧過ぎるので私は使いませんが、本ブログではこれを解説します。

一般的な定義によれば、

1.業務要件とは、対象業務のフローや入出力情報を決めたもの

2.システム要件とは、業務要件を満たすため、ITシステムが持つべき機能要件や非機能要件を定めたもの

私は、この曖昧な定義に非常に疑問を感じます。まず、第一の疑問は、業務要件はITを意識したものであるかどうかです。上記1の業務要件については、進歩が早いITの動向を考慮すれば、ユーザ企業側がITを考慮して、ToBeの業務プロセスを設計するのは無理でしょう。まして、ITのプロセスだけ描いて、業務フローだと言われると、ビックリします。

次に、上記2のシステム要件ですが、多くのITベンダーのSEは、何を開発すればいいかのシステム要件をユーザからヒアリングしようとします。これは「引き出す」というビジネスアナリシスや要求工学の姿勢からすれば全く疑問です。自分がユーザの立場に立てば、ITでやりたい事をすべて言うのは無理なことが分かるしょう。ITのことを知らないのですから。

この2つのギャップから、ITトラブルが発生します。実は、2つの間にITシステムへの要求があるのです。

①ToBe業務プロセスを設計すること(これが業務要件)・・・・Why

②この業務プロセスを強力に支援するためのIT要求・・・・What

③IT要求を効果的に実現するためのIT要求仕様(これがシステム要件)・・・・How

①は、ITを意識しません。①を満たす手段はIT以外にもありますが、②はITによって満たすとして選定されたIT手段の一つ。③は②のIT手段の具体的な仕様。このWhy-What-Howの考え方は、対象を構造化するために、よく利用される方法です(会議での議論のまとめにも使えます)。

ユーザ企業側で上記①②を完全に定義するのは現状からすれば無理です。ビジネスアナリストがいないのですから。一方、ITベンダー側は③だけを早く知りたいでしょうが、②を正確にFIXできなければこれも無理です。また、②から①に立ち戻って、Whatの見直しやWhyによる優先順位付けを行わなければ、開発規模拡大のITトラブル、または投資対効果の低いITシステムが出来上がるだけです。

ビジネスアナリストの役割は、①business requirements、②user requirements、③software requirements、この3つを定義して、適切につなぐことにあります。英語にすれば明確なので、「要件」という日本語はやめて欲しいですね。

あるユーザ企業の現在のITシステムを開発したSI企業が、6カ月間をかけて、ITシステム再構築のために、①業務フローを作成、②IT要求定義を行いましたが、RFPが完成せず、ユーザ企業とトラブルになってしまいました。原因は、自分が想定するITプロセスだけの業務フローを描いて(業務要件もどき)、そこから自分勝手にIT要求(もどき)を定義したことです。いくらその企業への経験や知識があっても、正しいビジネスアナリシス方法論や要求開発プロセスを適用しないとダメの事例です。

 

 

カテゴリ