mcpField
D
daci-framework

daci-framework

github.com/borghei生産性1.0k48 回インストール5 日前に更新
リポジトリ

daci-framework について

daci-framework は、製品の意思決定において、推進、承認、意見提供、情報共有を担う人を明確にするスキルです。チームが現状の権限分担を整理し、停滞要因を特定して、より明確なガバナンスへの移行を計画できます。

主な機能

  1. 01DACIの意思決定役割の定義
  2. 02現状の意思決定権限の整理
  3. 03意思決定の停滞要因の特定
  4. 04目標とするガバナンスの設計
  5. 0530/60/90日の移行計画

活用シーン

  1. 01新チームの意思決定権限の明確化
  2. 02停滞した製品判断の解消
  3. 03組織再編後の責任範囲の空白への対応
  4. 04リリース失敗後のガバナンス改善

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/borghei/claude-skills --skill daci-framework

インストール後、Claude Code で/daci-frameworkを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

examples/
choosing-payment-processor.md
references/
playbook.md
red-flags.md

詳細

DACI 意思決定フレームワーク

概要

DACI フレームワーク（Driver、Approver、Contributor、Informed）を使用して、意思決定のオーナーシップを明確にし、決定が何度も蒸し返される事態を減らします。タスクの責任に焦点を当てる RACI とは異なり、DACI はプロダクトに関する意思決定に特化しています。つまり、誰が決定を完了まで推進するのか、誰が拒否権を持つのか、誰が意見を提供するのか、誰に知らせる必要があるのかを明確にします。

4 つの役割の概要は次のとおりです。Driver（必ず 1 名。決定の完了まで推進）、Approver（最大 1～2 名。拒否権を持つ）、Contributor（拒否権は持たず、意見を提供）、Informed（相談は受けず、通知を受ける）。現状を整理し、課題を見つけ、目標状態を設計したうえで、30/60/90 日の移行計画を実施して表を作成します。役割のルール、7 ステップの作成手順、健全性指標については、プレイブックを参照してください。

使用する場面

  • 新しいチームの編成 — 新しい部門横断グループで、意思決定における役割を明確にする必要がある場合。
  • 決定の停滞や蒸し返し — 誰に決定権があるのか分からず、意思決定が停滞する場合。
  • チームの拡大 — 成長に伴い、どの決定を誰が担当するのか曖昧になる場合。
  • インシデント後 — リリースの失敗や期限の未達によって、オーナーシップが不明確だったことが明らかになった場合。
  • 組織再編に伴う移行 — 役割の変更によってガバナンスに隙間が生じた場合。
使用しない場面
  • タスクの割り当てやプロジェクトの実行（代わりに RACI を使用してください）。
  • 個人の作業割り当て（スプリント計画を使用してください）。
  • 本当に 1 人だけで行う意思決定（ガバナンスのオーバーヘッドは不要です）。

まず確認すること

DACI 表を作成する前に、次の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

  • 対象とする具体的な意思決定 — 「すべて」ではなく、影響の大きい意思決定を 3～5 件選びます（それぞれが表の 1 行になります。一度に多くをマッピングすることが、最もよくある失敗要因です）。
  • 候補者と実際の権限 — 実際に承認または拒否できるのは誰かを確認します（Driver と Approver の割り当てに関わります。実質的な権限がなければ、表は形だけのものになります）。
  • 現在の課題 — 現在、どこで意思決定が停滞したり、何度も蒸し返されたりしているのかを確認します（現状から目標状態へのギャップと、30/60/90 日の移行計画を策定するために必要です）。

質問のルール：成果物の内容を最も大きく左右する 2～3 項目だけを質問してください。ユーザーが「とにかくドラフトを作って」と言った場合は作成を進め、成果物の冒頭に前提を列挙してください。

参考資料

  • references/playbook.md — DACI 表の作成または運用時に参照してください。役割の定義とルール、7 ステップの作成手順（作業グループ → 役割 → 意思決定 → 現状のマッピング → 課題 → 目標状態 → 移行計画）、ガバナンスの健全性指標、トラブルシューティング、成功基準が記載されています。
  • references/red-flags.md — 表を公開する前、または表に基づいて意思決定を行う前に参照してください。役割のルールに基づく、DACI 表でよくある失敗パターンと良い例・悪い例が記載されています。

対象範囲と制限事項

対象範囲： DACI 表の作成、現状のマッピング、目標状態の設計、移行計画、ガバナンスの健全性指標、課題の特定、意思決定のオーナーシップの明確化。

対象外： タスクの割り当て（RACI を使用）、プロジェクトの実行状況の追跡（スプリント計画を使用）、個人のパフォーマンス管理、意思決定のガバナンスを超える組織設計。

重要な注意事項： DACI は、リーダーシップがフレームワークを尊重すると約束している場合に最も効果を発揮します。経営幹部の賛同がなければ、Driver に意思決定を実際に推進する権限がない可能性があります。一度にすべてをマッピングしようとせず、影響の大きい意思決定を 3～5 件から始めてください。

連携ポイント

連携方向連携する内容
create-prd/提供先DACI の意思決定内容が、PRD の Contacts セクションと意思決定ログに反映されます
identify-assumptions/補完誰が権限を持つかに関する前提を明らかにします
brainstorm-okrs/補完OKR のオーナーシップが、DACI における意思決定のオーナーシップと整合します
summarize-meeting/提供先会議の要約に、DACI に基づく意思決定の結果が記録されます
senior-pm/補完プロジェクト横断の意思決定を対象とする、ポートフォリオレベルの DACI です

さらに詳しく

  • プロダクトチーム向けのProductside DACIガイド
  • Intuitやその他のプロダクト主導型組織で使用されているDACIフレームワークに関するInspiredの解説

コメント

Markdown 対応