関連ブログ:IT要求定義における本質的な問題点は何か において、下記の2つの問題点を取り上げました。

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

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

  大手システムインテグレーターの大幅減益での決算報告では、不採算案件が原因で問題はすべてテスト工程で発覚したとあったそうです。そして、これを防止するために、社長直轄のプロジェクト管理体制を作ると。本当に、これで防止できるのでしょうか? 

  同様に、7年前に大手ITベンダーの役員が、「要求トラブルで、3年間で1,000億円の損失だった。テスト工程で出てきた8割の要求は例外処理で、残りの2割は暗黙的な業務ルールだった」と講演で述べていました。

  IT要求に関する課題は相変わらず、変わっていないなと感じた次第です。すなわち、上記Bの業務を理解していないユーザに要求をヒアリングしているからで、要求を「引き出して」いないからです。おまけに、ヒアリングによって、要求でない要求を拾ってしまうので、業務上で役立たない機能を一生懸命に開発して、上記Aのばかな結果となってしまうのです。

       要求はヒアリングするものでなく、引き出すものなのです。本ブログではIT要求の一般的な引き出し方法、およびGUTSY-4のWBSにおいて、これら複数をどう組み合わせて利用しているかを説明します。

1.IT要求の一般的な引き出しの方法

      BABOK2.0の第9章テクニックには、「IT要求の引き出し」において利用できるものがいくつか、その長所と短所と共に説明されています(V3ではさらに追加)。

9.1 受入基準と評価基準の定義・・・・要求の優先順位付けが必要  

9.4 ビジネスルール分析・・・・ルール自体の妥当性、ルール間の矛盾がないことの検証

9.7 データモデリング

9.9 文書分析

9.13 インタフェース分析

9.14 インタビュー・・・・ヒアリングでなく質問するためには、インタビューアに質問スキルが必要

9.18 観察

9.21 プロセスモデリング・・・・プロセスが詳細過ぎると問題や課題が識別しにくい

9.22 プロトタイピング・・・・ユーザインタフェース以外の要求は得られない

9.23 要求ワークショプ・・・・参加ユーザに高い業務スキルが必要、アナリストは的確な質問ができること

9.26 シナリオとユースケース・・・・ユーザに業務スキルが必要

9.31 調査とアンケート

 

2.GUTSY-4での多元的な引き出し方法

  上記のテクニックにおいて、一つだけで十分なものはありません。したがって、GUTSY-4では、下記のように5つのテクニックを組み合わせています。

①ビジネスプロセス、ルール記述等⇒適切なプロセス階層レベルを設定して、上記9.219.4を実施

  ここでは、業務参照モデルの利用によって、業務スキルは最低限で済みます。

②要求の引き出し⇒ビジネスアナリストは要求ワークショプ9.23において、的確な質問9.14を実施

  ここでは、質問項目は上記①のプロセス記述を元にして、2次元要求インタビューシートから

  自動生成しますので、質問スキルは不要となります。

③要求の受入適合基準 ⇒9.1 受入基準を満たします。

④要求の優先順位付け ⇒9.1 評価基準を満たします。 

  ビジネスプロセスからIT要求を引き出すと、IT要求が安定したり、IT要求スコープが縮小することが既に事例で明らかになっています。それに加えて、GUTSY-4は、5つのテクニックを組み合わせることで、効果的にIT要求を引き出せるだけでなく、たとえば、ビジネスアナリストに質問スキルが必要などの各テクニックが持つ欠点や前提条件をクリアしています。

  もう、ユーザにIT要求だけをヒアリングすることは止めませんか! ヒアリングは、ビジネスプロセスの中に省力化・効率化の余地が沢山、残っていた時代の遺物です。

 

カテゴリ