アジャイル開発/スクラム開発のステークホルダーとその役割について解説

このページでは、アジャイル開発（スクラム開発）におけるステークホルダーについて解説します。

アジャイル開発のひとつの手法として、「スクラム開発」があります。

スクラム開発の関係者のうち、開発に直接関わらない利害関係者のことを、特に「ステークホルダー」といいます。

「スクラム開発におけるステークホルダーにはどんな立場の人がいるのか、またそれぞれの立場の人達はどんな役割を担っているのかよくわからない」ということも多いのではないでしょうか。

それもそのはずで、スクラム開発の他の関係者とは異なり、ステークホルダーは、開発するシステム・アプリによって変わるため、具体的に想像しづらいからです。

このページでは、こうしたアジャイル開発（スクラム開発）におけるステークホルダーとその役割について詳しく解説していきます。

スクラム開発におけるステークホルダーとは？

ステークホルダー＝発注者側の利害関係者

一般的なビジネス用語としてのステークホルダーは、利害関係者のことをいいます。

これに対し、アジャイル開発、特にスクラム開発におけるステークホルダーは、「発注者側」の利害関係者のことを指します。

ステークホルダーの具体例とは？

スクラム開発におけるステークホルダーの具体例は、以下のとおりです。

なお、これらの具体例は、あくまで一例に過ぎません。

開発するアプリやシステムによって、ステークホルダーの種類、範囲、関与のしかたは異なってきます。

ステークホルダーは間接的にスクラム開発に関与する

ステークホルダーは開発チーム（スクラムチーム）のメンバーではない

ステークホルダーは、スクラム開発における開発チームであるスクラムチームには、直接関与しません。

スクラムチームとは？役割・構成・人数・運営のポイントを解説

スクラムチームは、主にプロダクトオーナー（発注側責任者）、スクラムマスター（開発側責任者・管理者）、開発メンバーによって構成されています。

よって、ステークホルダーは、スクラムチームの構成員ではありません。

ステークホルダーはプロダクトオーナーが取りまとめる

このため、ステークホルダーの意見や意向、意思決定などは、直接スクラムチームに反映されるわけではありません。

実際には、ステークホルダーの意見・意向・意思決定などは、発注者側の責任者であるプロダクトオーナーが取りまとめて、スクラムチームに反映することとなります。

プロダクトオーナーとは？主な役割や必要なスキルを解説

このため、ステークホルダーとスクラムチームをつなぐプロダクトオーナーの役割は、極めて重要であるといえます。

発注者としては、こうしたステークホルダーとスクラムチームとの連携ができる人物をプロダクトオーナーとして選任する必要があります。

ステークホルダーが関与する7つの開発工程・フェーズ

ステークホルダーが関与する開発工程・フェーズは、主に次の7つとなります。

以下、それぞれの開発工程・フェーズごとに、関与するステークホルダーとその役割について、詳しく見ていきましょう。

1.プロジェクトの立ち上げ

プロジェクトの立ち上げでは最も多くのステークホルダーが関与する

アプリやシステム開発の最初の段階は、プロジェクトの立ち上げです。

プロジェクトの立ち上げの際には、プロジェクト全体の方向性を決定することとなります。

このため、程度の差こそあれ、プロジェクトの立ち上げの段階では、ほとんどの社内のステークホルダーが直接関与することとなります。

また、場合によっては、社外のステークホルダー（競合他社、監督官庁等）も、何らかの影響を与えられる可能性があります。

このように、プロジェクトの立ち上げのフェーズでは、最も多くのステークホルダーが関与することとなります。

最初にステークホルダーを特定する

このため、プロジェクトの立ち上げ段階では、プロジェクトの責任者が、まずはステークホルダーの種類、範囲を特定することが重要となります。

そのうえで、どの程度プロジェクトに関与させるのかを検討します。

なお、プロジェクトの責任者は、プロダクトオーナーとは別の場合と兼任する場合があります。

大規模なプロジェクトでは、ステークホルダーの特定がプロジェクト責任者の大きな負担となることもあります。

このため、大規模なプロジェクトでは、プロジェクト責任者とプロダクトオーナーを別にすることが望ましいです。

影響力が大きいステークホルダーには早めに話を通す

予算規模が大きい場合は出資・融資・助成金・補助金を検討する

また、影響力が大きいステークホルダーには、早めにプロジェクトについて話しておくことが重要となります。

特に規模の大きなアプリやシステムの開発の場合、予算の規模の大きくなり、経営者や役員の決済が必要となる場合があります。

それだけでなく、予算規模によっては、株主・出資者・銀行・政府・地方自治体等からの出資・融資や、補助金・助成金が必要となる場合もあります。

こうした資金調達を前提としたプロジェクトでは、関連するステークホルダーには、早めに話を通しておくべきです。

バックオフィスには初期の段階で話を通しておく

また、規模が大きい場合は当然ですが、規模が小さい場合であっても、早い段階から法務・会計・総務部門等のバックオフィスや、関連する外部の専門家にも話を通しておくことが重要となります。

こうしたバックオフィスや専門家に対し、ある程度開発が進んでからプロジェクトについて相談した場合、法律違反や会計処理・税務処理の問題点を指摘されることがあります。

特に、法規制がある場合は、監督官庁等にも確認をしておかないと、後で法律違反の指摘をされる可能性もあります。

こうした場合、途中で大きな仕様変更を余儀なくされたり、最悪の場合は開発が頓挫してしまいます。

2.現状の分析と要求事項の検討

現状の分析と要求事項の検討段階では主に社内のステークホルダーが関与する

続いて、プロジェクトの立ち上げと同時に、現状の分析とアプリ・システムについての要求事項を検討します。

この段階では、特に発注者の社内のステークホルダーが関与することとなります。

また、プロダクトオーナー、プロジェクトマネージャー、担当役員等の管理者・責任者による社内での調整が重要となります。

主にアプリ・システムに直接関わる社内の当事者が関与する

アプリ・システムの仕様にもよりますが、これらの分析・検討の業務は、主に業務担当者・マーケティング担当者や要件定義書を作成する者が担当します。

例えば、既存のシステムやアプリがある場合は、これらの機能の効果を見て、現時点での業務プロセスや要件に関する情報を集めます。

時には実際に業務を行っている現場などを訪れて問題点や改善点などを洗い出すことも有効です。

この場合は、社内のエンドユーザーもステークホルダーといえます。

この他、アプリ・システム開発の企画につきましては、詳しくは、次のページをご参照ください。

アプリ開発の企画の考え方は？企画書の書き方は？5W2Hでわかりやすく解説

3.アプリ・システム開発会社の選定

アプリ・システム開発会社に関係する対外的なステークホルダーが関与する

プロジェクトを立ち上げ、ある程度現状の分析と要求事項を検討し、企画が決まった段階で、アプリ・システムの開発会社を選定します（開発を内製化している場合はこの段階はスキップします）。

アプリ・システムの開発会社を選定する段階では、これらの会社と直接的・間接的に関わるステークホルダーが関与します。

この際、開発に関する業務に直接関わるステークホルダーは、当然この段階で関与することとなります。

また、他の段階ではあまり関与することはありませんが、開発形態や契約内容によっては、法務・経理・総務・人事等のバックオフィスの部門が関与することもあります。

アプリ・システム開発会社との契約交渉を始める前に、こうしたバックオフィスの部門にも、一言声をかけておいたほうがいいでしょう。

アプリ・システム開発会社の選定に必要な準備とは

実際にシステム開発を依頼する会社を選定する際には、以下のことを準備してます。

アプリ・システム開発会社の選定に関しては、発注者側のプロジェクト責任者や技術担当者などが担当することが一般的です。

また、最終的な決裁担当者は、そのプロジェクト責任者や技術担当者の上司であることが多いでが、開発規模によっては担当役員や代表取締役である場合もあります。

アプリ・システムの目的・予算・納期を明確にする

まずアプリ・システムの開発を依頼する目的・納期・予算の3つをはっきりさせておくべきです。

この3つは最低でも決まっていないと、アプリ・システム開発会社も完成イメージがしにくいです。

納期や予算については、数字の話になるため、比較的決めやすいものです。

これに対し、目的については、数字ではなく定性的な話になるうえ、ステークホルダーが多いと、しばしば目的が一致しないこともあります。

このため、特に社内のステークホルダーとアプリ・システムの目的について十分に検討し、見解を統一したうえで、アプリ・システム開発会社と共有します。

運用・保守を視野に入れて開発する

次に、アプリやシステムは完成しただけでは終わりません。

よほど機能や使用期間が特定・限定されていない限り、アプリ・システムの規模の大小を問わず、人の手による運用・保守が必要となってきます。

特に、大規模な基幹システムの場合は、開発と同じくらい、運用・保守の工程が重要となります。

このため、引き続き運用・保守のための管理に必要な事項や、予算も必要です。

こうした長期的な視点でも、ステークホルダーとの調整が重要となります。

RFP（提案依頼書）を作成する

そしてこれらを具体的にまとめた資料が「RFP（提案依頼書）」となります。

RFP（提案依頼書）は、開発会社側から見積もりやアプリ・システムの提案をもらうために必要な書類です。

正確で分かりやすいRFP（提案依頼書）を作成するためには、社内のステークホルダーとの調整が必須となります。

このため、プロダクトオーナーが関連するステークホルダーとの調整をしつつ、RFP（提案依頼書）の作成担当者をサポートすることが重要となります。

この他、アプリ・システム開発の開発会社の選定につきましては、詳しくは、以下のページをご参照ください。

見積りを取るアプリ開発業者の選定基準・選び方のポイントは？

4.要件定義の決定・作成

要件定義はアプリ・システム開発の根幹にかかわる重要な作業

開発会社が決まり、契約を締結した後（または契約締結前に）で、「要件定義」を行います。

要件定義はアプリ・システムそのものの仕様を決める作業であることから、アプリ・システムの開発工程において最も重要な工程です。

このため、アプリ・システムの開発が成功するかどうかは、要件定義にかかわるステークホルダーにかかっているといえます。

なお、スクラム開発の場合、ウォーターフォール開発とは異なり、あえて要件定義を完全に固めずに柔軟性を持たせて開発に着手します。

要件定義の当事者やエンドユーザーに近いステークホルダーが関与する

要件定義の工程は、主に業務担当者や要件定義のために特別に編成したチームなどが担当することが多いです。

また、実際にアプリ・システムを使用するエンドユーザーも、間接的に関与する場合もあります。

例えば、業務アプリ・業務システムの場合は、現場で実際に使う担当者が要件定義について意見やフィードバックをすることがあります。

さらに、社内に開発技術に詳しい担当者がいない場合は、技術的な点について、開発会社側とミーティングなどを行いながら要件定義を作り上げることもあります。

なお、作成するアプリ・システムが経営に与える影響が大きい場合は、最終的な要件定義は、経営者や担当役員が決定する場合もあります。

5.開発・実装フェーズ

開発・実装フェーズでもステークホルダーは関与する

要件定義がある程度固まると、いよいよ開発・実装フェーズに移行します。

このフェーズに移行した場合、主に開発会社により開発・実装が進められます。

ウォーターフォール開発の場合は、開発・実装のフェーズに移行すると、発注者側はあまり関与しません。

これに対し、スクラム開発の場合は、開発・実装のフェーズであっても、発注者側のステークホルダーは、何らかの形で関与することとなります。

特にスプリントレビューでのフィードバックが重要

開発・実装のフェーズにおいて、ステークホルダーの関与が特に需要となるのが、いわゆる「スプリントレビュー」でのフィードバックです。

スプリントレビューとは？やり方、参加者、レトロスペクティブとの違いは？

このスプリントレビューでは、ステークホルダーは、開発中のアプリ・システムを評価し、今後の開発の改善・効率化につなげるためのフィードバックを実施します。

こうしたフィードバックは、主にプロジェクトマネージャーや品質管理担当者・テスト担当者などが担当します。

この他、開発・実装のフェーズは、開発中のシステムと既存のシステムとの連携作業をおこなったり、システムを利用してみて、業務改善を進めていく段階になります。

6.受入テスト・システム移行

受入テストはステークホルダーが中心におこなう

アプリ・システムの開発が完了し、納入された後では、受入テストがおこなわれます。

また、既存のアプリ・システムがある場合は、受入テストに合格した後に、アプリ・システムの移行作業があります。

受入テスト・システム移行では、開発されたアプリやシステムが、要件を満たしているか、品質基準をクリアしているか等、また、システムの移行がある場合は移行後のアプリ・システムが正常に稼働するか等の検査・確認をおこないます。

当然ながら、これらの受入テスト・システム移行の作業は、ステークホルダーが中心となっておこなわれます。

多方面のステークホルダーからの「最終チェック」を受ける

受入テスト・システム移行後の確認は、主に発注者側の品質管理担当者・テスト担当者・業務担当者などのステークホルダーが担当します。

また、場合によっては、アプリ・システムのテスト・検査を専門としてる外部の事業者に対し、一部のテスト・検査を委託することもあります。

なお、受入テスト・システム移行後の確認は、いわゆる「最終チェック」となります。

ですので、完成したシステム・アプリに直接関わるステークホルダーだけでなく、バックオフィスなどの間接的に関わるステークホルダーも含め、一通り確認をしてもらうべきです。

特に、最低限、要件定義に関わったステークホルダーには、要件定義どおりに開発されているかどうか、確認してもらうべきでしょう。

多様で多くのステークホルダーによる確認が重要

受入テスト・システム移行後の確認では、予定されている検査基準・検査項目をクリアできるかどうかが主な確認事項となります。

ただ、通常の使い方とは異なる、イレギュラーや想定外の使い方をした場合の挙動を確認することも、場合によっては必要となります。

この際、アプリ・システムの開発に関わっていた者では思いもよらない使い方をしてもらうことが、問題点の発見や、バグフィックスにつながります。

このため、なるべく多様で多くのステークホルダーにアプリ・システムを使ってもらい、いろいろと試してもらうことが重要となります。

7.運用・保守

稼働後も運用・保守・継続開発の工程が続く

新しいシステム・アプリが無事稼働した場合、運用の工程に移行します。

また、システム・アプリの運用の妨げにならないよう、定期・不定期の保守・点検・メンテナンスをおこないます。

場合によっては、システム・アプリの稼働後であっても、継続的なアップデートのために、開発が継続されることもあります。

これらの工程では、すでにシステム・アプリが完成しているため、関与するステークホルダーは限定的となります。

システム・アプリに直接関わる限られたステークホルダーが関与

この工程では、主に発注者側のシステム管理者、業務担当者、利用者サポート担当者等が担当します。

また、アップデート等の継続開発がおこなわれる場合は、特に社内ユーザー・エンドユーザーからの要望の聴取が重要となります。

こうした要望への対応を通じて、追加機能の改修・アップデートなど、システム・アプリの安定稼働と利用者のニーズに対応します。

なお、アプリ・システムが稼働した場合は、ステークホルダーに対応するプロダクトオーナーは、引き続き留任する場合もありますが、稼働後の工程では、交代する場合もあります。

これは、開発の工程と運用・保守・継続開発の工程では、プロダクトオーナーの役割が大きく異なることもあるからです。

アジャイル開発・スクラム開発のステークホルダーに関するよくある質問

スクラム開発におけるステークホルダーとは何ですか？

アプリ・システムの開発におけるステークホルダーは、発注者・受注者双方の上司・営業部門・事業部門・経営者・株主・顧客など、アプリ・システムに関わる「利害関係者」のことを指します。
ただし、アジャイル開発のうち、特にスクラム開発におけるステークホルダーは、こうした利害関係者のうち、発注者側のものを意味します。

スクラム開発におけるステークホルダーの役割は何ですか？

アプリ・システムの開発におけるステークホルダーは、それぞれの立場と開発工程・開発フェーズによって、その役割が異なります。いずれも、開発されるアプリ・システムがより良いものとなり、または悪いものとならないよう、意見やフィードバックを提示したり、実際に作業をしたりすることなどが、主な役割となります。