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

       一般的な定義によれば、

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

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

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

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

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

①ありたい業務プロセスを設計すること(業務要件)・・「用事」(成すべき事、広辞苑)に該当・・・Why

②業務プロセスを支援するためのIT要求・・・・・・・・・・・・・・「用件」(用事の内容、広辞苑)に該当・・・What

③IT要求を実現するためのIT要求仕様(システム要件)・・「要件」(必要な条件、広辞苑)・・・・・How

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

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

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

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

 

カテゴリ