ユーザーより1歩先に行くための業務分析ノウハウ～業務スキルでユーザーと勝負しても勝てない！ ユーザーをリードするためのモデル化の手法

スキル

» 2009/07/21

　コラム内容に現場観を与えるため、今回からサブタイトルを「ユーザーより1歩先に行くための業務分析ノウハウ」に変えてみました。

　今回は「要求分析」の2回目です。次の図は、要求分析の作業ステップの概要を示したものです。

　この中に登場するものは、以下の4種類です。

• 関与者利害関連表

　システムに対する要求は、責任部門として事業部門から出します。システム要求を出す側は、自らの責任範囲（主に組織)内における要求を主張することが多いと言えます。ところが、分析者サイドとしては対象範囲全体を見ないといけないということと、要求を出す側にも他者との関係や位置づけを知り、さらに建設的な意見を出してもらう必要があります。よくいわれるブレーンストーミングのための素材として、これを使用します。結果として関係者の共通認識を促し、より具体的で現実的な要求を引き出すことができます。

　要求分析のアウトプットである要求モデルを組み立てるための素材をここで十分に集めることが重要です。

• 要求モデル

　ユーザー要求をロジックツリー法の目的／手段の関係で階層化したもので、要求分析の最終成果物になります。目的から手段を洗い出すトップダウン型と、これは何のためにという考えでＫＪ法などを使ってポトムアップ型の両方でまとめていきます。

• WHYツリー

　どうしても要求モデルを下位展開できない場合、つまり原因がわからないので対処法も浮かばない、という場合に結果から原因を導き出すＷＨＹツリーを利用すると便利です。これは、要求モデルの完成度を上げるための手法です。

• 流れとつなぎ図

　この手法も、原因を突き止めて要求モデルの会展開を促すものですが、どちらかというと組織間のプロセス上での問題を突き止めるために使用します。

　要求分析の実質的な作業の開始は、「関与者利害関連表」を作成するところからになります。

■関与者利害関連表

　関与者利害関連表とは、漠然と述べられた問題（対象）、および関与者から提起された要求（要望、問題）をもとに、問題（対象）に関連する部署（関与者）で）要求を整理したものです。

　作成の目的としては、次の4点となります。

• 要求項目の抽出を促進させる

　要求項目の抽出が十分でない部分がビジュアルに示される。（部署・業務機能という形で）他部署での問題、要望の中で、自分に関連するものが容易に認識され、それをきっかけに新たな要求項目の抽出が促される。

• 検討すべき問題（対象）の範囲を明確化する

　関与者から提起された問題、要望を関与者（部署）－業務機能マトリックスに埋めこむことにより、問題の範囲が明確な形で示される。

• 他部署における問題に対する認識、理解を促進させる

　自分が関連している業務機能（活動）に関して、他部署でどういう問題、要望があるか容易に認識できる。

• 関与者間での利害関係を浮彫りにし、相手の立場に関して理解を深めさせる

　さらに、実施内容のと狙いをまとめると次のようになります。

• 関与者から抽出した、要求（要望・問題）を関与者利害関連表を用い、関与者（部門）－業務機能（活動）という枠組の中にあてはめ、整理する

• このときに、出された要求が、要求表現（～を～する)になっているか確認する

　(上記の事例は、要求が出された初期のもので、一部問題の指摘のみになっているものもあり、要求表現に変えていく必要があります)

• 追加要求項目がないか検討する

• 議論から関与者利害関連表の枠組みに問題ないかを見直す（具体的には、横軸の組織、および縦軸の過不足や粒度など）

• この整理を通して、問題（対象）の範囲が浮彫りにされ、関与者間で問題範囲に関して共通の認識がなされると共に、相互に問題の理解が促進される。また、不足項目の創出が促進される

　要求分析で最も重要なことは、システムの利用者である事業部門を参加させることです。
情シス部門とだけ進めても、ろくな結果になりません。システム分析担当者は、いかに現場の真意をつかみモデル化しておくかが、後工程に大きく影響します。

　この場面で考えられるのが、情シス部門の担当者が立ちはだかって、事業部門と話をさせないケースです。

　いいシステムを構築することより、自分の仕事をとられ存在価値が問われることを心配しているのです。

　今後のチーム状況にも影響するので、強引に進めず部門長など責任者と話し合い、主旨を理解してもらったうえで解決してもらうことが一番いい方法です。コネクションなども最大活用する機会です。

　しかしながら直接交渉できる場合とできない場合があるので、どうしても譲らないかたくなな担当者と、一戦交えなくてはいけないケースもあります。その場合は、下手な小細工をすると墓穴を掘ります。あくまでロジックで攻める必要があります。

　わたしの場合、この手法そのものを教え込むことで、担当者に実作業を課します。すべて方法と成果物ベースで話し、満足にできていなければ、徹底的にできるまで妥協しません。

　その担当が優秀ならば、キャッチアップしてアシスタント的に動いてくれますし、そうでなけばできないので助けを求めてきます。その場合は現場に出ることができるのです。

　手法をよく理解して使いこなすコンサルタント的位置づけと、相手に理解させ信頼を得ていること、というのが前提です。

　次に、事業部の方々にも参加してもらって要求分析を進める場合、最も大変なのが

　「現場で作業している事業部門の方々には、業務スキルでは勝てない」

ということです。

　分析は進めないといけない、しかし業務内容、プロセスを聞いていっても、コンサルタントとしての技能に疑問を持たれます。

　では優位に立ちながら、システム分析を進めるにはどうすればいいのでしょうか？

　　～つづく～