ユーザーより1歩先に行くための業務分析ノウハウ～業務スキルでユーザーと勝負しても勝てない！ ユーザーをリードするためのモデル化の手法
コラム内容に現場観を与えるため、今回からサブタイトルを「ユーザーより1歩先に行くための業務分析ノウハウ」に変えてみました。
今回は「要求分析」の2回目です。次の図は、要求分析の作業ステップの概要を示したものです。
この中に登場するものは、以下の4種類です。
- 関与者利害関連表
システムに対する要求は、責任部門として事業部門から出します。システム要求を出す側は、自らの責任範囲（主に組織)内における要求を主張することが多いと言えます。ところが、分析者サイドとしては対象範囲全体を見ないといけないということと、要求を出す側にも他者との関係や位置づけを知り、さらに建設的な意見を出してもらう必要があります。よくいわれるブレーンストーミングのための素材として、これを使用します。結果として関係者の共通認識を促し、より具体的で現実的な要求を引き出すことができます。
要求分析のアウトプットである要求モデルを組み立てるための素材をここで十分に集めることが重要です。
- 要求モデル
ユーザー要求をロジックツリー法の目的／手段の関係で階層化したもので、要求分析の最終成果物になります。目的から手段を洗い出すトップダウン型と、これは何のためにという考えでＫＪ法などを使ってポトムアップ型の両方でまとめていきます。
- WHYツリー
どうしても要求モデルを下位展開できない場合、つまり原因がわからないので対処法も浮かばない、という場合に結果から原因を導き出すＷＨＹツリーを利用すると便利です。これは、要求モデルの完成度を上げるための手法です。
- 流れとつなぎ図
この手法も、原因を突き止めて要求モデルの会展開を促すものですが、どちらかというと組織間のプロセス上での問題を突き止めるために使用します。
要求分析の実質的な作業の開始は、「関与者利害関連表」を作成するところからになります。
■関与者利害関連表
関与者利害関連表とは、漠然と述べられた問題（対象）、および関与者から提起された要求（要望、問題）をもとに、問題（対象）に関連する部署（関与者）で）要求を整理したものです。
作成の目的としては、次の4点となります。
- 要求項目の抽出を促進させる
要求項目の抽出が十分でない部分がビジュアルに示される。（部署・業務機能という形で）他部署での問題、要望の中で、自分に関連するものが容易に認識され、それをきっかけに新たな要求項目の抽出が促される。
- 検討すべき問題（対象）の範囲を明確化する
関与者から提起された問題、要望を関与者（部署）－業務機能マトリックスに埋めこむことにより、問題の範囲が明確な形で示される。
- 他部署における問題に対する認識、理解を促進させる
自分が関連している業務機能（活動）に関して、他部署でどういう問題、要望があるか容易に認識できる。
- 関与者間での利害関係を浮彫りにし、相手の立場に関して理解を深めさせる
さらに、実施内容のと狙いをまとめると次のようになります。
- 関与者から抽出した、要求（要望・問題）を関与者利害関連表を用い、関与者（部門）－業務機能（活動）という枠組の中にあてはめ、整理する
- このときに、出された要求が、要求表現（～を～する)になっているか確認する
(上記の事例は、要求が出された初期のもので、一部問題の指摘のみになっているものもあり、要求表現に変えていく必要があります)
- 追加要求項目がないか検討する
- 議論から関与者利害関連表の枠組みに問題ないかを見直す（具体的には、横軸の組織、および縦軸の過不足や粒度など）
- この整理を通して、問題（対象）の範囲が浮彫りにされ、関与者間で問題範囲に関して共通の認識がなされると共に、相互に問題の理解が促進される。また、不足項目の創出が促進される
要求分析で最も重要なことは、システムの利用者である事業部門を参加させることです。
情シス部門とだけ進めても、ろくな結果になりません。システム分析担当者は、いかに現場の真意をつかみモデル化しておくかが、後工程に大きく影響します。
この場面で考えられるのが、情シス部門の担当者が立ちはだかって、事業部門と話をさせないケースです。
いいシステムを構築することより、自分の仕事をとられ存在価値が問われることを心配しているのです。
今後のチーム状況にも影響するので、強引に進めず部門長など責任者と話し合い、主旨を理解してもらったうえで解決してもらうことが一番いい方法です。コネクションなども最大活用する機会です。
しかしながら直接交渉できる場合とできない場合があるので、どうしても譲らないかたくなな担当者と、一戦交えなくてはいけないケースもあります。その場合は、下手な小細工をすると墓穴を掘ります。あくまでロジックで攻める必要があります。
わたしの場合、この手法そのものを教え込むことで、担当者に実作業を課します。すべて方法と成果物ベースで話し、満足にできていなければ、徹底的にできるまで妥協しません。
その担当が優秀ならば、キャッチアップしてアシスタント的に動いてくれますし、そうでなけばできないので助けを求めてきます。その場合は現場に出ることができるのです。
手法をよく理解して使いこなすコンサルタント的位置づけと、相手に理解させ信頼を得ていること、というのが前提です。
次に、事業部の方々にも参加してもらって要求分析を進める場合、最も大変なのが
「現場で作業している事業部門の方々には、業務スキルでは勝てない」
ということです。
分析は進めないといけない、しかし業務内容、プロセスを聞いていっても、コンサルタントとしての技能に疑問を持たれます。
では優位に立ちながら、システム分析を進めるにはどうすればいいのでしょうか？
～つづく～
コメント
インドリ
票の説明だけではなくて、実際に起こりうることを踏まえて書かれていましたので、非常に参考になりました。
続きを楽しみにしています。
高橋秀典
インドリさん、
高橋秀典です。コメントありがとうございます。
一度に書けないので、内容がどうしてもブツ切りになってしまいます。
技術力のあるエンジニアがモデリングの考え方をマスターできれば、かなりいいセンを目指せると思います、
このエリアが、自分の守備範囲で無いと決め付けてしまったり、興味が無いと一刀両断してしまうのは、余りにももったいないですね。
情報システムは、企業のビジネスを最大化するためにあるので、これを本当に理解したエンジニアが多くなれば、地位向上も現実的になると思います。
IT戦略の中心にいるのはITエンジニアです。戦略とは競合相手を葬り去るためにあり、ITエンジニアは重要な役割を果すと信じています。
ビガー
ビガーです。
>わたしの場合、この手法そのものを教え込むことで、担当者に実作業を課します。
いろいろな人がいるので手法に興味を持ってもらえるまでが結構大変ですよね。
私は担当者が理解しやすい形にカスタマイズして、「担当者主導」で仕事を進めるよう
注力しています。
何事もそうですが、自分でやってみないと本当の意味で理解なんてできないので
信頼関係も本当の意味で築けないと思います。
>「現場で作業している事業部門の方々には、業務スキルでは勝てない
これも重要ですね。ダメなコンサルは自分の弱みを見せないようにしたがるので
たまに虚勢を張る方も見受けられます。
わからないところはわからない、ただし、影のキャッチアップは常にしつづけるのは当然必須。
私は、未知の業界でも1ヶ月以内に事業部門のコアスキルをキャッチアップできるよう
工夫しています。まぁ、いろいろな業界の業務を抽象化できていれば3日とかでも
可能なんでしょうけど、私は経験不足なので。
※せっかくいい素材を発信されているのに多忙で自身コラムが便乗できず、遺憾です。
高橋秀典
ビガーさん、
コメントありがとうございます。
確かにメソッドの有効性を理解してもらうのは、難しい面があると思います。
以前言われていたキーマンを見つけるというのも、このことに通じますね。
私の場合は、目星をつけて手法だけではなく成果物の実例を使いながら説明します。そうすると、初めは斜めに見たり批判的だった方でも、自分が苦労してきたこととの同化や、解の一端を見つけてぐっとのめり込んできます。
言われるように、自分でやってみないとわからないことですが、まずはこれならできそうだとやる気にさせることが大切だと思います。
過去にそれなりの経験を積んで、基本的にやる気がある方を見つける大変さもありますが、うまく行った場合は、かなりの達成感を味わえますね。
もう1つ、自らを高める努力が必要なのも同感です。
一番大変だったのは、コンサルファームの土日の1年間のトレーニングコースを3種類同時に受けて、休みが全く無かった時ですね。財務と経営とプロジェクト管理で、宿題も山盛りで大変でした。その上に、仕事で英語が必要だったので、ベルリッツに通い・・・。
今思えば、自分ながらよくやったと感心していますが、やはり基礎的知識など武器を持たずして現場に出るのは、今でも怖いです。適当にごまかすことは、私にはできません。
こういう話は、今迄あまり口に出したことは無かったのですが、経験者同士の相互コミュニケーションの場のなせる技でしょうか。