ステークホルダーとは？要件定義での洗い出し方を解説
ステークホルダーとは、開発の依頼者、実際にシステムを使う利用者、業務の承認者、リリース後に運用・保守を行う担当者など、そのシステムに関わりを持つすべての関係者のことです。
依頼者だけと話すと起きること
たとえば経費精算の申請・承認システムを総務部長の依頼で作る場合、依頼者と要件を詰めるだけでは、申請する社員が外出先のスマホで領収書を撮影したいこと、承認する課長が出張中でも承認を止めたくないこと、経理が月末に仕訳用のデータを取り出したいことが見えてきません。これらはリリース後に「使いにくい」「月末の作業が増えた」という形で表面化し、作り直しの原因になります。
洗い出しの観点
「誰がデータを入力するか（利用者）」「誰が承認・確認するか（承認者）」「誰が依頼・予算判断をするか（依頼者）」「誰が日々の運用・問い合わせ対応をするか（運用者）」の4つの役割で洗い出すと、抜け漏れが減ります。先の例では、経理はデータを受け取る側、情報システム担当はアカウント管理を担う運用者にあたります。1人が複数の役割を兼ねることも珍しくありません。
よくある質問
すべてのステークホルダーに個別ヒアリングが必要？
必須ではありません。規模が小さい場合は、依頼者や現場リーダーに他の役割の声も含めて確認してもらう形でも進められます。ただし、利用者と承認者の視点は依頼者の想定から外れやすいため、少なくとも各1名には直接確認することをおすすめします。
ステークホルダー間で要望が対立したらどうする？
「承認は必ず2段階にしたい（経理）」「承認に時間がかかるので1段階にしたい（営業）」のような対立は、業務上の影響（どちらの作業が止まると損失が大きいか）を基準に、依頼者を交えて判断します。判断の基準と結論を要件定義書に残しておくと、後工程で同じ議論が再燃するのを防げます。