IT要求定義を巡っては、現状において2つの大きな本質的問題点が存在しています。

1.定義された64%のITシステム機能が、全く、あるいは、ほとんど利用されていない

  IT要求として定義され、ITシステムに実装された機能のうち、64%の機能が、全く、あるいは、ほとんど利用されていないという、調査結果があります(Chaosレポート2000)。これらの機能は、ITシステムの開発時には、ユーザが必要だと要求した筈なのにです。これは、ユーザが述べる要求の中には、IT要求として取り扱ってはならないものが約2/3も存在することを意味します。

①願望:明確な根拠がないがその機能があれば便利と思った、しかし、いざ実現されたらあまり役立たなかった。

②要望:今、出しておかないと、後ではやってくれないかも知れないと出したものの、実際に利用する機会は「全くなかった」。

③保険:現システムに存在している機能であまり利用していないが、なくなると困りそうと思って出した。しかし、やはり、実際に利用する機会は「ほとんどなかった」。

④金メッキ:業務機能上でそれほど重要ではないが、特定の個人だけが強く主張する高度な機能。その個人がいなくなると誰も使わない、使えない

⑤パワーユーザから:もともと自己アピールから発生、当人がいなくなれば誰も使わない

⑥データ定義やソリューション:、「このデータ項目がほしい」、「メールに添付して送れるようにして欲しい」などとユーザが提示し、開発者が飛びついたもの。しかし、後になって、さらに良い手段があることに気付いた

  「今回、ITシステムを(再)構築しますが、あなたの要求は何ですか」と、ユーザにヒアリングすれば、上記のような業務機能上、重要でないものをたくさん拾い集めてしまいます。その結果が、約2/3の機能が全く、ほんとんど利用されていないという状況をつくり出しています。これは、ヒアリングするという要求定義の方法が誤っているからです。これでは、IT投資対効果が上がる筈はありません。

  したがって、ITシステム開発側はヒアリングとは別の方法によって、ユーザから真のIT要求を引き出さねばなりません。IT要求は、引き出す、elicitationするものなのです。

2.ユーザ自身が自らの業務を理解していない

  これは、日本企業に多い問題ですが、ユーザが自らの業務を理解していないという状況があります。

・ドキュメント軽視の文化から、業務プロセスや業務ルールに関するマニュアルがない、更新されない

・用語がきちんと定義されていない。特に、大企業では、事業部をまたがると同音異義の用語が多く存在している

・IT化が進み、重要な業務ルールがコンピュータのロジックとして自動化されて、次第にブラックボックス化していく

・ドキュメントがないまま次の担当者に業務を引き継ぐため、十分に引き継げない。管理職ですら、自分の部署の担当業務の目的を理解できていないこともある

  こうして、ユーザは、ITシステムのオペレータのようになっていき、現場において業務に精通した人が減っています。したがって、業務を理解していないユーザからヒアリングによって、IT要求を定義しようということは成り立たなくなっています。ヒアリングではなく、業務を観察する、あるいはユーザに質問するという方法があります。しかし、これは、ユーザ側が自らの業務を理解しており、IT要求を定義する側にも業務知識があることを前提とします。  

  では、どうやって自らの業務を理解していなユーザからIT要求を引き出していくか。GUTSY-4が採用したのは、業務参照モデルを利用してビジネスプロセスを正確に記述し、これを改善したビジネスプロセスから生成した質問項目を利用してIT要求を引き出していく方法です。

 

カテゴリ