【基本的な考え方】
システム開発に関わるステークホルダが増えてきています。
システムの対象となる範囲が広がった結果、システム開発に関係する部門も増え、利用者がマーケットに広がったことで稼働してからのサービス担当もステークホルダに加わりました。
また、企業間接続によるサービスの提供進展により、相手企業のシステム部門もまたステークホルダとして担当営業などとともにコミュニケーションの対象となりました。システムの運用をアウトソースしている場合は、アウトソーサもステークホルダに入るでしょう。
プロジェクトを起こした業務企画担当者は、プロジェクト責任者として、これらステークホルダの方針、意見、課題などについて、漏れなく綿密に把握し、できることとできないことをＩＴ担当者、ベンダとともに切り分け、業務要件として取りまとめていく責任を果たす必要があります。
ステークホルダもまた、システムの供給側に立つ場合は、積極的にシステム開発要件の策定に参画し、利用者ニーズを確実に把握して、正確にシステム機能に反映していくことが必要です。したがって、ステークホルダの果たす役割は、きわめて重要なものになっています。
【行動規範】
・発注者は、ステークホルダーの合意確認を自らの仕事と心得る。
・受注者は、合意を得ないまま開発に入ると、要件定義自体がひっくり返るおそれがあることと心得る。
・受注者は、合意確認の作業支援はできるが請負（責任）はできないことを明示する。
・双方は、ステークホルダが誰か、漏れはないかを確認する。