SpecDojo Handbook

日本語

English

日本語

English

Appearance

ステークホルダー登録簿 ​

本書は、SpecDojo プロジェクトに関係するステークホルダーを識別し、期待、懸念、必要な合意、関与方針を整理するための登録簿である。

本プロジェクトは、現時点では個人・小規模プロジェクトとして開始する。そのため、本書では 小規模運用で必要な最小限のステークホルダー のみを管理する。

なお、公開リポジトリに配置する文書であるため、個人名、連絡先、非公開の組織情報、機密性の高い利害関係は記載しない。

1. 基本方針 ​

  • ステークホルダーは、プロジェクトに影響する、または影響を受ける関係者・集団・外部基盤を表す。
  • ステークホルダーは、Schedule / WBS の owner には使用しない。
  • Schedule / WBS の owner は、pm-organization.md で採用した Role code を使用する。
  • ステークホルダーに対応する Role code がある場合は、対応 Role code として明示する。
  • 対応 Role code は、pm-roles.yaml および pm-organization.md で採用した Role code だけを記載する。
  • ステークホルダー登録簿は、利害、期待、懸念、合意対象、関与方針を整理するために使用する。
  • 小規模運用では、影響度/関心度分析、詳細なコミュニケーション計画、RACI との連携は必要最小限に留める。

2. 登録対象 ​

小規模運用では、次のステークホルダーのみを初期登録対象とする。

ID関係者関与区分所属/組織主な関心対応 Role code備考
STH-PROJECT-OWNERプロジェクトオーナースポンサー / 意思決定者 / 実行責任者SpecDojo プロジェクト目的、スコープ、優先順位、公開方針、成果物品質PO小規模運用では複数責務を兼務する
STH-AI-AGENTAI Agent実行支援者利用する生成 AI 環境草案作成、レビュー支援、整合性確認、改善提案PO, BA, ARC, QE人間の判断や責任を代替しない
STH-FUTURE-USER将来の利用者利用者企業、個人、行政、教育機関、地域コミュニティ、OSS プロジェクト等SpecDojo の分かりやすさ、導入しやすさ、継続利用しやすさBA初期段階では想定ステークホルダーとして扱う
STH-FUTURE-CONTRIBUTOR将来の貢献者外部協力者 / 新規貢献者個人、企業、OSS コミュニティ等Issue、Pull Request、提案、レビュー基準、貢献しやすさBA, QEOSS 公開後に関与が本格化する
STH-PUBLICATION-PLATFORM配布・公開基盤外部基盤GitHub 等公開、履歴管理、Issue/PR、ライセンス表示、参照性ARC, PO実体はサービス基盤であり、管理対象ではなく利用前提として扱う

3. 期待・懸念・必要な合意 ​

ID主な期待主な懸念必要な合意・確認責任ロール
STH-PROJECT-OWNERSpecDojo の目的に沿った、実用的で継続更新しやすい文書体系を整備する方向性のぶれ、過剰な複雑化、継続困難化、公開判断の曖昧さ目的、範囲、優先順位、公開方針、成果物構成PO
STH-AI-AGENTルールに基づき、草案作成、レビュー、改善提案を効率的に支援する誤解釈、過剰生成、不整合、根拠のない補完、責任境界の誤認入力情報、制約条件、出力形式、レビュー方針、最終判断者PO
STH-FUTURE-USERSpecDojo が分かりやすく、実務で使いやすく、導入負荷が低い記述ルールが難しい、適用範囲が不明、テンプレートが重い適用範囲、利用手順、最小構成、サンプル、ライセンスBA
STH-FUTURE-CONTRIBUTOR貢献方法が明確で、提案や修正が扱われる参加方法が不明、レビュー基準が不透明、PR が取り込まれない貢献ルール、Issue/PR 方針、レビュー方針BA
STH-PUBLICATION-PLATFORMSpecDojo が参照・取得・改善しやすい形で公開されるリポジトリ構成が分かりにくい、ライセンスが不明、履歴が追いにくいリポジトリ構成、README、LICENSE、公開範囲ARC

4. 関与方針 ​

ID現状目標対応方針責任ロール証跡
STH-PROJECT-OWNER主導主導目的、範囲、優先順位、公開方針を継続的に確認し、主要成果物の判断と更新を行うPOプロジェクト概要、憲章、Issue、決定記録
STH-AI-AGENT支援支援入力文書、作成ルール、制約条件を明示し、生成物は人間が確認するPO指示内容、生成結果、レビュー記録
STH-FUTURE-USER未関与支持README、導入手順、最小構成テンプレート、サンプルを整備し、利用しやすさを高めるBAREADME、導入ガイド、テンプレート、サンプル
STH-FUTURE-CONTRIBUTOR未関与協力Issue/PR の導線、貢献ルール、レビュー基準を段階的に整備するBACONTRIBUTING、Issue テンプレート、PR テンプレート
STH-PUBLICATION-PLATFORM利用中活用リポジトリ構成、README、ライセンス、変更履歴を整備し、公開・参照・改善しやすい状態にするARCREADME、LICENSE、Git 履歴、Release notes

5. コミュニケーション要件 ​

小規模運用では、詳細なコミュニケーション計画は必須としない。必要な情報要求と証跡のみを整理する。

ID情報要求主なチャネル合意・報告の必要性証跡要件
STH-PROJECT-OWNER目的、範囲、優先順位、主要判断事項Issue、Pull Request、決定記録方針変更、公開方針、主要成果物の確認決定記録、PR、Issue
STH-AI-AGENT入力文書、作成ルール、制約条件、出力形式指示テンプレート、チャットAI 出力の採否は人間が判断する指示内容、生成結果、レビュー結果
STH-FUTURE-USER目的、適用範囲、利用手順、テンプレート、サンプルREADME、SpecDojo、導入ガイド利用上の不明点や改善要望を Issue 等で収集するIssue、フィードバック、更新 PR
STH-FUTURE-CONTRIBUTOR貢献方法、レビュー基準、Issue/PR ルールGitHub Issue、Pull Request、CONTRIBUTING貢献ルールとレビュー方針を明示するIssue、PR、レビュー記録
STH-PUBLICATION-PLATFORMリポジトリ構成、ライセンス、更新状況GitHub、README、Release notes公開前に README、LICENSE、構成を確認するREADME、LICENSE、Git 履歴

6. ロールとの関係 ​

ステークホルダーとロールは別概念である。

概念意味例
Stakeholder利害、期待、懸念、合意対象を管理する相手STH-FUTURE-USER
Role責務、判断権限、タスク owner を表す論理的な役割BA

例:

  • STH-FUTURE-USER は、SpecDojo を利用する想定ステークホルダーである。
  • BA は、将来利用者の視点を整理するロールである。
  • Schedule / WBS の owner には STH-FUTURE-USER ではなく BA を書く。
  • 対応 Role code は、ステークホルダーの期待、懸念、合意対象を主に扱う Role code を示す。
  • 1 つのステークホルダーに複数の Role code が対応してよい。
  • 対応 Role code がない外部基盤や外部集団は、必要に応じて なし と記載し、無理に Role code を割り当てない。

7. 見直し条件 ​

本書は、次のタイミングで見直す。

更新トリガー見直し内容責任ロール証跡
プロジェクト概要を変更した関係者、期待、懸念、必要な合意の再確認PO変更差分、PR、決定記録
OSS 公開方針を変更した将来利用者、将来貢献者、公開基盤への影響確認POLICENSE、README、決定記録
リポジトリ構成を変更した利用者、貢献者、公開基盤への影響確認ARCPR、Issue
主要ルールブックを追加・変更した利用者、AI Agent への影響確認BAPR、レビュー記録
外部からの Issue / Pull Request 受付を開始した将来貢献者の関与方針、レビュー方針の確認BACONTRIBUTING、Issue、PR
初回公開前個人情報、機密情報、ライセンス、README、導入手順の確認QE公開前チェックリスト、レビュー記録
初回公開後の主要フィードバックを受領した利用者、貢献者、活用プロジェクトの追加確認BAIssue、フィードバック、更新 PR

8. 禁止事項 ​

  • ステークホルダー ID を Schedule / WBS の owner に使うこと。
  • ステークホルダー登録簿で member nickname を管理すること。
  • ステークホルダー登録簿に不要な個人名、連絡先、非公開組織情報を書くこと。
  • AI Agent を最終判断者または承認者として扱うこと。
  • 小規模運用で不要な詳細分析を増やし、文書を過剰に複雑化すること。