ステークホルダー管理とは｜発注者が押さえる洗い出しから合意形成まで

社内の複数部門が関わるシステム開発プロジェクトを推進する立場になったとき、開発会社のキックオフ会議で「ステークホルダーのマネジメントをお願いします」と言われ、困った経験はありませんか。「ステークホルダーって誰のこと？」「管理するとはどういうことをすればいいの？」という疑問が頭に浮かぶのは、珍しいことではありません。

プロジェクトマネジメントの専門家でなくても、発注者側の担当者としてステークホルダー管理に取り組む必要はあります。しかし、体系的な研修を受けたことがなければ、「誰を管理すればよいか」「どうやって社内の承認を取りつけるか」「開発会社とどう連携すればよいか」の答えを見つけるのは容易ではありません。

実際、システム開発プロジェクトの失敗原因の多くは技術的な問題ではなく、関係者の調整不足や認識のズレにあります。ステークホルダー管理を適切に進めることができれば、プロジェクトの成功確率は大きく高まります。

本記事では、システム開発に不慣れな発注者側の担当者が「今日から実践できる」ステークホルダー管理の手順を、洗い出し・分析・社内合意形成・開発会社との連携まで一貫して解説します。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

ステークホルダーとは何か——システム開発における定義

利害関係者＝プロジェクトに影響を与える・受けるすべての人

ステークホルダー（Stakeholder）とは、直訳すると「利害関係者」を意味する英語です。プロジェクト管理の文脈では、「そのプロジェクトに何らかの影響を与える、あるいは影響を受けるすべての人・組織」を指します。

似た言葉に「ストックホルダー（Stockholder）」や「シェアホルダー（Shareholder）」がありますが、これらは主に株主を指す言葉です。ステークホルダーはより広い概念で、株主だけでなく、顧客・従業員・取引先・地域社会など多様な関係者を含みます。

プロジェクト管理の国際標準であるPMBOK（プロジェクトマネジメント知識体系ガイド）では、ステークホルダーを「プロジェクトに直接または間接的に影響を与える人、グループ、または組織」と定義しています。

システム開発で関わる主なステークホルダーの種類

システム開発プロジェクトには、想像以上に多くのステークホルダーが存在します。大きく「社内」と「社外」、そして「直接的な関与者」と「間接的な関与者」に分類できます。

社内の主なステークホルダー:

• 経営層: 予算の最終承認権限を持つ取締役・部長など。プロジェクトの方向性やROI（投資対効果）に関心がある
• 情報システム部門: システムの技術的要件・セキュリティ・インフラ基盤を担当する
• 業務部門（システムの利用部門）: 実際にシステムを日常業務で使うことになる現場担当者・管理者
• 人事・総務部門: 導入に伴う教育訓練・業務プロセス変更の調整が必要な場合に関与する
• コンプライアンス・法務部門: 個人情報や法令遵守に関わる場合に関与する

社外の主なステークホルダー:

• 開発会社（ベンダー）: システムの設計・開発・保守を担当する外部パートナー
• 連携先システムのベンダー: 新システムと既存システムをAPI等で連携させる場合に関与する
• エンドユーザー（顧客・消費者）: B2Cシステムの場合、最終的に利用する顧客も重要なステークホルダー

これだけ多くの関係者がいると、「全員に同じ対応をするのは非効率」と感じるのは自然なことです。だからこそ、ステークホルダーを「管理する」ことが必要になります。

なぜステークホルダー管理が必要なのか——管理不足が招く失敗パターン

よくある失敗パターン3選

システム開発プロジェクトの多くが予定より時間もコストもかかって終わる、あるいは途中で中断されるという現実があります。その原因の多くは、技術的な問題ではなく関係者の調整不足です。

失敗パターン1: 要件定義後に経営層から方針変更が入る

要件定義を進めていたところ、完成間近になって経営層から「この機能は不要」「方向性を変えたい」という指摘が入ったという事例は珍しくありません。経営層を早期に巻き込まず、情報共有も不十分なまま進めた結果、設計段階まで戻ることになります。場合によっては数千万円規模のコスト増とスケジュール遅延が生じます（出典: Re-grit Partners「システム開発を成功に導くためのステークホルダーとの関わり方」）。

失敗パターン2: 影響を受ける部門の担当者が突然反対する

実際にシステムを使う現場部門を関与させないまま開発を進めると、リリース直前に「現場の業務フローに合わない」「使いにくい」という反発が起きます。導入後の変更対応や追加開発が必要になり、コストと時間が余分にかかります。

失敗パターン3: 開発会社との間で要件の認識がずれたまま進む

発注者側が明確にしていなかったステークホルダーの要件が、開発途中で追加として浮上することがあります。外部システムとの連携要件や非機能要件（セキュリティ・パフォーマンスなど）が後から追加されると、再見積もりによって数千万規模のコスト増・スケジュール見直しが発生するケースもあります。

ステークホルダー管理不足が引き起こすコストとリスク

ステークホルダー管理が不十分だと、以下のような連鎖が起きます。

1. 必要な情報が集まらない → 要件の抜け漏れが生じる
2. 関係者間で認識がずれる → 手戻りが発生する
3. 反対派の巻き込みが遅れる → 終盤で反発を受ける
4. 意思決定が遅れる → スケジュールが遅延する

プロジェクト開始時のステークホルダー特定と関係構築に時間を使うことは、後工程の手戻りや追加対応を防ぐ「先行投資」といえます。

システム開発のステークホルダーを洗い出す方法

4象限（社内×直接、社内×間接、社外×直接、社外×間接）で分類する

ステークホルダーの洗い出しに迷ったら、まず4象限の軸で考えると整理しやすくなります。

この4象限に当てはめながら、「誰がいるか」を書き出すことがスタートです。次の問いかけがステークホルダー洗い出しのヒントになります。

• 誰がこのプロジェクトの最終承認権限を持つか？
• 誰がこのシステムを日常的に使うことになるか？
• 誰がこのプロジェクトに反対する可能性があるか？
• 誰の業務がこのシステムの導入で変わるか？
• 誰がこのシステムと関連するシステムを持っているか？

システム開発プロジェクト別のステークホルダーチェックリスト

プロジェクトの種類によって、見落としがちなステークホルダーが異なります。

基幹システム刷新の場合

• 経営層（最終承認権限者）
• 情報システム部門（技術的要件・セキュリティ担当）
• 全関係部門の部門長・担当者
• 現場のヘビーユーザー（操作頻度が高い担当者）
• 連携先システムの担当者（会計・人事・生産管理など）
• 外部監査・コンプライアンス担当

新規業務システム導入の場合

• 経営層（導入を判断した意思決定者）
• 導入部門の管理者・担当者
• 情報システム部門（インフラ・セキュリティ）
• 既存システムとの連携先担当者
• 開発会社の担当者（プロジェクトマネージャー・担当エンジニア）

既存システムの改修・機能追加の場合

• 現在のシステム運用担当者
• 機能変更に関係する業務部門の担当者
• 開発会社（現行システムの担当者）
• 変更による影響を受ける下流業務の担当者

洗い出し後にすべき「ステークホルダー一覧表」の作成

洗い出したステークホルダーを一覧表に整理しておくことで、「誰に・何を・いつ」伝えるかの管理が格段に楽になります。

この一覧表はプロジェクト開始時に作成し、プロジェクトの進行に合わせて定期的に更新します。

影響度と関心度でステークホルダーを分析する（マトリクス活用法）

影響度×関心度マトリクスの使い方

すべてのステークホルダーに同じ時間と労力をかけることは非現実的です。そこで活用できるのが「影響度×関心度マトリクス」です。

• 影響度（Power）: そのステークホルダーがプロジェクトに与える影響の大きさ（予算承認権限・意思決定権など）
• 関心度（Interest）: そのステークホルダーがプロジェクトへの関与・関心の度合い

この2軸で各ステークホルダーを位置づけ、対応の優先順位を決定します。

4つの象限別・コミュニケーション戦略

実際の記入例とテンプレートの活用

実際にマトリクスを使う際は、ステークホルダー一覧表に「影響度」と「関心度」の列を追加し、高/中/低で評価していきます。評価は1人でするのではなく、プロジェクトメンバー（情報システム部門の担当者や業務部門のキーパーソン）と一緒に確認することで、見落としや主観的な評価を防げます。

また、「現在の立場（支持/中立/懐疑/反対）」も記録しておくと、合意形成のアプローチを決める際に役立ちます。

社内ステークホルダーへの合意形成の進め方

経営層への承認を取り付ける3つのアプローチ

社内で最も難しいのが、経営層への承認取得です。経営層は時間的な制約があり、プロジェクトの詳細より「なぜ必要か」「いくらかかるか」「どんなリターンが見込めるか」を重視します。

アプローチ1: 事業インパクトを中心に説明する

技術的な詳細よりも「このシステムを導入することで、どんな業務課題が解決されるか」「コスト削減・売上向上・リスク低減にどう貢献するか」を明確にします。数値で語れるものは具体的な数値で示します。

アプローチ2: リスクを説明してリスク回避の判断を促す

現在の課題を「このまま放置するとどうなるか」という観点で説明します。「現行システムのサポート終了が○年後に迫っている」「手作業によるミスが月○件発生している」など、放置コストが見えると判断が早まります。

アプローチ3: 段階的な承認を求める

一度にすべての承認を求めるのではなく、「まず要件定義フェーズの着手承認をいただきたい」「次に開発フェーズの予算承認をいただきたい」と段階的に説明・承認を求めると、経営層も判断しやすくなります。

なお、経営層への承認取得の前に、自部門の上司や関係部門の担当者との事前調整（いわゆる「根回し」）を済ませておくことが重要です。会議の場で初めて情報を提示するのではなく、事前に個別でコミュニケーションを取り、反対意見や懸念事項をあらかじめ把握・対処しておきます。

反対派・懐疑派への対処——「巻き込み」から始める

プロジェクトに反対または懐疑的なステークホルダーの存在は、多くのプロジェクトでみられます。「現場の業務を知らない人たちが決めたことを押しつけられる」と感じているケースも少なくありません。

反対派への対処の基本は、「反対を押し切る」ではなく「理解を得る」ことです。

有効な対処法:

1. 個別ヒアリングで懸念を引き出す: 会議の場ではなく1対1で「どんな懸念があるか」を聞く機会を作ります。懸念を表明できる場を設けることで、不満が蓄積するのを防ぎます
2. 懸念を要件に反映させる: 可能な範囲で反対派の懸念を要件に取り込みます。「自分たちの意見が反映された」と感じてもらえると、反対から中立・支持に変わりやすくなります
3. 協力者を介して関係を構築する: 直接のコミュニケーションが難しい場合、その人と良好な関係にある別のステークホルダーに協力者になってもらう方法も有効です（出典: Re-grit Partners「システム開発を成功に導くためのステークホルダーとの関わり方」）

ステークホルダー別コミュニケーション計画の作り方（頻度・手段・内容の設計）

誰に・何を・いつ・どのように伝えるかを事前に設計しておくことを「コミュニケーション計画」といいます。これを作っておくことで、情報共有の漏れや報告タイミングのズレを防げます。

重要なのは「報告の頻度と手段」をステークホルダーごとに合わせることです。経営層に毎週詳細報告をしても負担になるだけですし、現場担当者に月1回しか情報共有しないと不安が生じます。

外部ステークホルダー（開発会社）との効果的な連携方法

発注者が担うべき役割と開発会社が担う役割の区分け

「ステークホルダー管理は開発会社がやってくれるもの」と思っていると、プロジェクトがうまくいきません。開発会社が対応できるのは、あくまでも発注者から提供された情報の範囲内です。

発注者側が担うべき役割:

• 社内ステークホルダーの特定と整理
• 社内承認・合意形成の調整
• 社内からの要件・情報の収集・整理・開発会社への提供
• 変更要求が発生した際の社内意思決定の主導

開発会社が担う役割:

• 技術的な要件の具体化・設計・実装
• 開発会社側の関係者管理（パートナー会社含む）
• プロジェクト管理ツールの運用・進捗管理
• 技術的なリスク管理・品質保証

発注者と開発会社の役割の境界を早期に合意しておかないと、「それは発注者側でやることでは？」「いや、開発会社が対応すべきでは？」という責任の押しつけ合いが起きやすくなります。

開発会社に渡すべき「ステークホルダー情報」とは何か

開発会社がプロジェクトを円滑に進めるには、発注者側のステークホルダー情報が必要です。最低限、以下の情報を開発会社と共有します。

1. ステークホルダー一覧: 誰がどんな立場でプロジェクトに関わっているか
2. 意思決定フロー: 要件変更や追加が発生した場合、誰が承認権限を持つか
3. エスカレーション経路: 問題が発生した場合、誰に・どのように報告すれば良いか
4. コミュニケーションの取り方の制約: 直接連絡してはいけない人がいるか、承認が必要な場面はどんな時か

これらを共有することで、開発会社は適切なタイミングで適切な相手に確認を取れるようになります。

プロジェクト進行中のステークホルダー管理——定例会議・変更管理・エスカレーション経路の設計

ステークホルダー管理は、プロジェクト開始時に1回やれば終わりではありません。プロジェクトが進むにつれて状況は変わり、新しいステークホルダーが浮上したり、関心度・影響度が変化したりします。

定例会議の設計: プロジェクト全体の定例会議（週次）に加えて、主要ステークホルダーとの個別定例（隔週・月次）を設定します。定例会議では進捗報告だけでなく、「次のマイルストーンまでに必要な意思決定・承認」を明示し、先回りして判断を求めます。

変更管理の仕組み: 要件変更や追加が発生した際に、誰が判断するか・どのプロセスで承認を取るかを事前に決めておきます。変更のたびに毎回ゼロから調整していると、プロジェクトが停滞します。

エスカレーション経路の明確化: 問題が発生した際にどのステークホルダーにいつ・どのレベルの情報をエスカレーションするかのルールを決めておきます。エスカレーションが遅れると、小さな問題が大きなリスクに育ちます。

まとめ——ステークホルダー管理は発注者が主導する

システム開発プロジェクトにおけるステークホルダー管理は、プロジェクト管理の専門家だけが行うものではありません。発注者側の担当者こそが、社内の関係者を整理し、合意形成をリードしていく必要があります。

本記事のポイントを整理します。

1. ステークホルダーを洗い出す: 「社内/社外」×「直接/間接」の4象限で考え、チェックリストを使って網羅的に特定する
2. 影響度×関心度で分析する: 全員に同じ時間をかけるのではなく、優先順位をつけてコミュニケーション戦略を決める
3. 社内の合意形成を主導する: 経営層には事業インパクトを中心に、反対派には個別ヒアリングで懸念を引き出す。根回しを恐れずに進める
4. 開発会社と役割分担を明確にする: ステークホルダー情報・意思決定フロー・エスカレーション経路を共有し、連携の土台を作る

ステークホルダー管理に取り組む最初の一歩として、まず「ステークホルダー一覧表」を作成することをお勧めします。プロジェクトに関わりそうな人・組織を書き出し、影響度と関心度を評価するだけで、プロジェクトを俯瞰する視点が生まれます。

システム開発プロジェクトをより円滑に進めるためのノウハウについては、プロジェクト体制の設計やスコープ管理に関する記事も参考にしてください。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード