「ユーザのための要件定義ガイド」101～103ページと200～202ページに「ステークホルダー」について書かれています。
しかし残念ながら、ここでもビジネスアナリシスの観点が取り入れられていないためにステークホルダーをどのように捕捉するのか？要求をどのように引き出すのか？・・・について極めてアナログな説明となっています。
まず、ビジネス要求（要件）の引き出しについてですが・・・（以下、ガイド本文から引用）
ビジネス要求定義は、各ステークホルダから問題、ニーズ、課題が混在して提示され、そこから解決すべき課題を見極め、施策(ビジネスプロセス改善要求やシステム化要求)を検討するというのが大きな流れである。提示されてくる問題や課題認識は要件定義の出発点になる。しかし、ステークホルダから問題、課題が大量に提示されてきて収拾がつかないとか、本当の問題や課題が出てこないといった問題がこの段階で発生する。ここでは、それらを解決するための勘どころを説明する。
⑴ 適切な問題•課題の抽出・分析を行うために、ステークホルダの特性を理解する
【解決したい問題】
•ステークホルダを見誤り、必要な要求が抽出されない
•詳細な問題・課題がたくさん出てきて収拾がつかない
•真の問題・課題が出てこない
•問題・課題の抽出に漏れがある
問題、課題が適切に抽出されないことがある。例えばシステムの利用者から問題・課題を収集したら操作性改善の要求が大量に出てきて収拾がつかなくなった、などである。機能改善が目的であればまだしも、経営への貢献や業務プロセスの改革などがテーマの場合、本当の問題、課題が出てきていないことになる。ステークホルダの特性を理解し、問題・課題を抽出するのに適切なステークホルダを見極めることが重要である。
問題・課題の違いは、(2)を参照していただきたい。
冒頭、このような書き出しで始まるのですが、これは要件定義担当者に予備知識が無い、あるいは不十分であること、つまり要求の引き出しを行うのがＩＴベンダーのＳＥであることが前提になっているように筆者には感じられます。
組織に問題・課題が発生システム開発の必要性が発生した際には、まず対象業務に関わるビジネスアナリシスを行い、真の問題・課題の構造を把握し論理的にステークホルダーを特定して、要件定義工程では、要求・ニーズの引き出しに際して組織階層レベルに従った「粒度」を意識した上で「とにかく、いろいろな人から手当たり次第に引き出しを行う。」に陥らないように留意することでこの指摘は回避することが出来ます。
ガイドの200ページに一般的なステークホルダー候補のリストが記載されています。
勘どころ① 必要なステークホルダを漏れなく抽出する
ステークホルダを洗い出す際、目の前にある対象とする業務やシステムに関係する直接的なステークホルダのみに関心が向き、視野が狭くなってしまうことが多い。端緒としては良いが、対象業務やシステムとの間で間接的に影響を受ける/影響を与える関係者もステークホルダとして抽出する必要がある。
また、現場の業務担当者だけでは組織としてのゴールや経営課題が見えていない可能性があり、表面的な意見や個人的な意見が混じる可能性がある。そのため、経営層もステークホルダとして識別する必要がある。
以下に抽出の観点を示す。
•直接的な関わりを持つ関係者
・対象業務の運用者
・対象システムの運用者
・対象業務とシステムの最終利用者 (お客様やエンドユーザなど)
・業務の結果で評価される人(経営層など)
•間接的な関わりを持つ関係者
•対象業務と関連する顧客、取引業者
•対象業務と関連する業務の運用者
•対象業務と関連する業務の結果で評価される人(経営層など)
•対象システムと関連する外部システムの運用者
•対象業務の主管部門以外の組織の人
•対象システムの外部システム
上記はあくまで一例であるため、プロジェクト関係者へのインタビューやブレーンストーミングなどを使用して、漏れなくステークホルダを抽出する必要がある。
ステークホルダーの洗い出しと特定作業は、まず、組織規程、分掌規程、業務手順書、マニュアルなどから調査を始めます。その中で注目すべきは「報告」です。実体的な業務におけるステークホルダーは、ビジネスアナリシス（業務プロセス分析）により洗い出すことが出来ますが、問題は「間接的」なステークホルダーです。
内部的には監査部門や対外的（対官庁や地方公共団体など）に何かの「報告」を提出している部門がありますし、外部的には対官庁や地方公共団体ですが、外郭団体が事務を担っているケースもあり、社内有識者を幅広くインタビューする必要があります。（これもビジネスアナリシスの一環です。）
また、システムの変更により思わぬ影響が他のシステムに出ることも十分に留意しておく必要があります。
次に、「問題、課題が適切に抽出されないことがある。例えばシステムの利用者から問題・課題を収集したら操作性改善の要求が大量に出てきて収拾がつかなくなった、などである。」と言うガイドにおける指摘ですが、これはプロジェクトをビジネスアナリシスから着手することで調整します。
ビジネスアナリシスを行うときは常にプロセス階層レベルとテーマの粒度に配慮します。
図１
原則として、検討はトップダウンでレベル０～１から下に向かって構造化（細分化）して行きます。しかし、現実問題として分析の対象となる業務のレベルに明確な線引きが出来るわけではないので下記に表のようにざっくりと３＋１段階に分けて分析した上で要求を引き出します。
|
区分 |
プロセス階層 対象レベル |
内容 |
|
経営レベル |
レベル０~1、２ |
売り上げ・コスト・利益の改善や事業の継続、 顧客評価などにつながる要求 |
|
業務レベル |
レベル３～４ |
業務の品質・生産性・スピードの改善等業務効率につながる要求 |
|
仕組みレベル |
レベル４～５ |
業務レベルの要求を実現するために必要な仕組みに関する要求 |
|
システムレベル |
上記以下 |
仕組みレベルの要求を実現するためのシステム要求 |
図２
ビジネスアナリシス（業務分析）は以下の手順で進めます。
1. 業務の現状（AsIs）可視化と分析
2. 現状の問題・課題の把握
3. 問題・課題への対応策の策定
4. 目指すあり方（ToBe）の策定と可視化および要求の抽出
5. 上位要求の下位のプロセスへの反映
6. 下位プロセスの目指すあり方（ToBe）の策定と可視化および要求の抽出