ステークホルダーの分析｜開発前に決める5項目

プロジェクトの初回会議には、部門長、現場担当、情シス、開発会社が集まっていた。参加者は十分に見える。ところが仕様レビューになると、「その判断は別部署です」「運用担当には聞いていません」が次々と出てくる。

人数が足りないのではない。誰が何を決めるかが曖昧なのだ。

関係者分析は、名前を並べる名簿作りではない。システム開発では、決裁、業務判断、例外処理、データ、運用の責任者を特定し、要件と承認経路をつなぐ作業になる。ここを外すと、会議の出席者が多くても合意は進まない。

ステークホルダーの分析とは何か

ステークホルダーとは、プロジェクトに影響を与える人と、プロジェクトから影響を受ける人を指す。経営層や発注責任者だけではない。実際に操作する現場担当、例外対応を担う管理者、データ連携先の担当者、セキュリティ部門、保守会社、取引先も含まれる。

一般的な関係者分析では、人や組織を洗い出し、影響力と関心度で分類する。この方法は、誰へ重点的に説明するかを決めるのに役立つ。

ただし、システム開発ではもう一段掘る必要がある。「関心が高い人」と分かっても、その人が価格を決めるのか、業務ルールを決めるのか、リリースを承認するのかは分からないからだ。

IPAの設計・検証技術の適用事例でも、経営者、業務部門、情シス、運用・保守、ベンダー、利用者では関心事が異なると整理されている。要件を引き出すには、関係者ごとの役割と判断対象を分けて捉える必要がある。

なぜ関係者一覧だけでは足りないのか

たとえば経費申請システムを刷新するとしよう。部門長は「承認を早くしたい」と話す。経理は証憑の保存と締め処理を気にする。現場はスマートフォンから申請したい。監査担当は変更履歴を残したい。

どれも正しい。しかし、そのままでは要件にならない。

「承認を早くする」と「不正な申請を止める」が衝突したとき、誰が優先順位を決めるのか。締め日を過ぎた申請を誰が例外承認するのか。保存期間を決める根拠は何か。ここまで決めて、初めて設計とテストに渡せる。

ステークホルダーマップに名前だけを置くと、次の問題が残る。

• 意見を聞く人と、最終決定する人が混ざる
• 通常業務の担当者だけを見て、例外対応者が漏れる
• データの入力者は分かるが、品質責任者が分からない
• 開発時の責任者はいるが、稼働後の運用責任者がいない
• 合意した要件を誰が受け入れテストで確認するか決まらない

注意したいのは、こうした漏れが「技術課題」に見えて後から現れることだ。権限設計のやり直し、データ移行の差し戻し、テストケースの不足。その根は、関係者と判断責任の対応が切れていることにある。

開発前に決める5項目

実務では、ステークホルダーごとに次の5項目を確認する。影響力と関心度のマップに、この5列を足すイメージだ。

1. 投資と優先順位を決める人

最初に特定するのは、予算を承認する人だけではない。目的、対象範囲、優先順位を最終決定する人である。

「全社で使えるようにしたい」と「3か月で開始したい」は、しばしば両立しない。対象部門を絞るのか、機能を段階導入するのか。この判断を開発会社へ預けてはいけない。事業側の決裁者が決める。

確認する質問はシンプルだ。

• 何が達成できれば投資成功と判断するか
• 納期、対象範囲、品質が衝突したとき何を優先するか
• 追加費用や延期を誰が承認するか
• 中止または縮小を判断する条件は何か

決裁者がレビューに毎回出られない場合は、代理判断できる範囲と、本人へ戻す条件を決めておく。

2. 業務ルールを決める人

現場担当者は業務を詳しく知っている。だが、現行手順を知る人と、将来の業務ルールを決める人は同じとは限らない。

ヒアリングでは、事実と判断を分ける。

• 現在どう処理しているか
• なぜその手順になっているか
• どのルールは法令・契約上の制約か
• どのルールは慣習で、変更できるか
• 新しいルールを誰が承認するか

ここを分けないと、古い運用をそのままシステム化してしまう。現状把握は必要だ。しかし「今そうしている」は「新システムでもそうすべき」の根拠にはならない。

3. 例外と停止を判断する人

要件定義では通常フローが先に描かれる。ところが運用を止めるのは例外だ。

申請額が上限を超えた。連携先が応答しない。本人確認に失敗した。必須データが欠けている。こうした場面で、自動継続するのか、人へ渡すのか、処理を止めるのかを決める。

例外ごとに、次の4点を置く。

1. 検知条件
2. システムの動作
3. 判断する役割
4. 復旧後の再開方法

「管理者が対応する」では粗い。業務管理者、システム管理者、セキュリティ責任者のどれかを明記する。夜間や休日に発生した場合の連絡先も必要だ。

4. データの意味と品質を決める人

データには、入力者、利用者、管理者がいる。さらに「この値を正しいとみなす人」が必要になる。

顧客名が二つのシステムで異なる場合、どちらを正とするのか。退職者の履歴をいつまで保持するのか。集計値の定義を誰が変更できるのか。これらはデータベースの技術だけでは決まらない。

データ項目ごとに、少なくとも次を確認する。

• 正とする情報源
• 登録・更新できる役割
• 品質を確認する役割
• 保持期間と削除条件
• 他システムへ渡す範囲

経済産業省のレガシーシステムモダン化委員会総括レポートは、IT資産の可視化や経営との情報共有をモダン化の論点に挙げている。同レポートがデータ責任者を直接定義しているわけではないが、要件定義へ展開するなら、資産の所在だけでなく、データの意味と変更を管理する役割も明記したい。

5. 運用と受け入れを決める人

最後は、完成を誰が判定し、稼働後を誰が支えるかである。

利用部門が操作できるだけでは受け入れ完了とは言えない。情シスは監視やバックアップを確認する。セキュリティ担当は権限とログを見る。業務責任者は例外時にも仕事が続けられるかを確かめる。

受け入れ条件には、確認者をひも付ける。

運用担当をリリース直前に呼ぶと、監視、問い合わせ対応、権限変更の要件が後付けになる。企画段階から参加してもらうほうが、結果的に速い。

ステークホルダーマップの作り方

難しい図から始める必要はない。初回は60分を目安に、次の順で一枚のたたき台を作る。部門やシステムが多い案件は、対象業務ごとに会議を分ける。

手順1：業務の前後から関係者を出す

対象業務の開始前、処理中、完了後をたどる。入力する人、承認する人、例外対応する人、結果を使う人、監査する人を挙げる。社外の取引先や委託先も忘れない。

手順2：個人名ではなく役割で置く

「田中さん」ではなく「営業部長」「請求担当」「セキュリティ責任者」と書く。担当者が替わっても仕様と責任が残るからだ。個人名は連絡先として別列に持つ。

手順3：5項目の判断対象を割り当てる

各役割について、決裁、業務ルール、例外、データ、運用・受け入れのどれを担うか印を付ける。空欄があれば、それは要件の未決定箇所である。

手順4：決定・相談・共有を分ける

RACIのような責任分担表を使ってもよい。ただし記号だけで満足せず、「何を決定するか」を一文で書く。相談先が十人いても、決定者は原則一役割に絞る。

手順5：要件IDと承認者をつなぐ

関係者の整理を会議資料で終わらせない。要件ID、判断者、レビュー日、決定内容、変更理由を結び付ける。仕様変更が起きたとき、誰へ戻すかが分かる。

IPAの要求発展型開発WG報告書には、経営層、業務部門、情シス、元請け、サブベンダなど、役割ごとの要求定義範囲が示されている。組織図を写すのではなく、要求と役割を対応させる発想が参考になる。

完成形は、次のような「判断責任表」にする。

この表を設計レビュー、テスト仕様、変更要求でも共通参照する。責任者の整理が仕様・テスト・変更管理へ連鎖してこそ、手戻りを防ぐ成果物になる。

関係者情報をAIでも読める形にする

会議記録や既存資料をAIで整理すると、関係者候補の抽出は速くなる。発言者、登場する部署、承認語、例外語を拾い、ステークホルダー表の初稿を作れる。

一方で、AIは組織上の正式な決裁権を確定できない。過去の発言が、現在の方針とも限らない。候補抽出はAI、権限と責任の確定は人間。この境界を崩さないことが大切だ。

AIへ渡すデータは、次のように構造化すると扱いやすい。

• 役割ID
• 所属部門
• 影響を受ける業務
• 決定できる項目
• 相談が必要な項目
• 承認する要件ID
• 不在時の代理ルール
• 最終確認日

Kakusillは、会議や資料から要件の骨子を整理し、業務フロー、要求、設計、変更履歴をつなぐためのプロダクトである。関係者の整理も、名前の一覧ではなく「誰がどの仕様を決めたか」という判断履歴として持つと、AIにも人にも読み継ぎやすくなる。

明日から使える確認表

次の質問に一つでも答えられなければ、実装前に確認したい。

• 投資目的と優先順位の最終決定者は誰か
• 業務ルールを変更できる役割は誰か
• 例外時に続行・停止を判断するのは誰か
• データの正しさと保持方針を決めるのは誰か
• 受け入れテストと本番移行を承認するのは誰か
• 各要件の相談先と決定者が分かれているか
• 担当者交代後も役割と判断履歴が残るか

関係者分析の成果は、きれいな四象限ではない。判断の空白を見つけ、要件へ責任者を結び付けることだ。関係者が多いほど、会議を増やす前に「誰が何を決めるか」を一枚にする。その一枚が、設計・開発・テストの手戻りを減らす土台になる。

システム開発の関係者整理から要件・受け入れ条件までつなげたい場合は、Atsumellへ相談してほしい。業務判断をAIが読める仕様へ整えるところから支援している。

関連記事

• AIに要件定義を任せると何が壊れるか
• 要件定義から設計・開発までをAIで回す3つの箱
• データフロー図の書き方｜5ステップで要件にする