JiraでDACIを使う：すべての決定に明確な責任者を

Jira課題に長い議論が蓄積しても、決定に近づくとは限りません。開発とサポートの推奨案は異なり、プロダクトオーナーは誰かが選択肢を整理するのを待っています。全員が参加しているのに、誰が決めるのか分かりません。

DACIはこの会話に構造を与えます。誰が前に進め、誰が決め、誰の専門知識が必要で、誰が結果を受け取るかを明示します。このガイドでは架空の顧客ポータルチームで通知配信を決定し、Power Pack for Jiraに役割を記録します。

DACIの4つの役割を理解する

DACIはDriver、Approver、Contributors、Informedの略です。AtlassianのDACIプレイでは、Driverは意思決定の進行をまとめる人、Approverは選択を行う唯一の人とされています。Contributorsは専門知識を提供し、Informedは結果を受け取ります。出典は末尾にあります。

話し合いでは推進者と承認者を区別します。調整役だから自動的に最終決定権を持つわけではありません。同様に、結果を選ぶ人がすべての根拠を自分で集める必要もありません。

決定が必要な問いを選ぶ

架空のポータルでは、顧客がサポート依頼の更新を追跡できます。次のリリースで通常のステータス通知をどう届けるかを決める必要があります。候補は即時メール、日次ダイジェスト、ポータル内の受信箱です。

プロダクトオーナーのMayaは気が散るメールを減らしたいと考えています。エンジニアのLeoは2つ目の通知システムを追加することを心配しています。サポート責任者のSamは顧客が進捗を見逃すことを懸念し、テスターのPriyaはリリース確認の設計前に方針を固めたいと考えています。

関係するJira課題に「ポータル初回リリースでは、通常のサポート依頼の更新をどう届けるか」と書きます。この表現が議論の境界になります。通常の状態変更を対象とし、パスワード再設定、緊急のセキュリティ通知、将来のあらゆる連絡手段まで決めるものではありません。

通常のチーム運用で、課題の説明に決定の目標日を加えます。この例では次の計画会議までに回答が必要です。この日付は調整上の合意であり、マトリクスがリマインダーを送ったり期限を強制したりする約束ではありません。

実際の不明点に合わせて役割を割り当てる

チームはLeoを推進者に選びます。実装の選択肢を整理し、不足する技術的根拠を洗い出せるためです。リリース上の判断は合意されたプロダクト権限に属するため、Mayaが承認者になります。Samは顧客サポートの背景を、Priyaはテスト可能性と失敗シナリオを提供します。顧客向け連絡を準備するElenaは最終結果を受け取ります。

登録前に、各人が役割を果たせるか確認します。Leoには比較する時間が必要です。Mayaは計画前に対応できる必要があります。SamとPriyaには、無期限に意見を求めるのではなく、具体的な質問が必要です。

2人が最終権限を持つと考えている場合は、マトリクスを完成扱いにする前に境界を整理します。プロダクトの選択と別の予算判断が混ざっているのかもしれません。異なる承認者が本当に必要なら決定を分けます。話し合いを避けてAを追加しても、根本の不明点は残ります。

答えられる質問を貢献者に渡す

LeoはSamに、顧客がサポート依頼の更新を誤解した最近の例を3件求めます。Priyaには、更新が短時間に重なると何が起こりうるかを洗い出してもらいます。自分は既存システムに基づく短い技術比較を用意します。

これらは説明用の架空の情報であり、実測された製品結果ではありません。役立つ貢献の姿を示すためのものです。各情報は、その人の専門性を今回の決定に結び付けています。

チームは3つの問いで比較することにします。顧客が有用な進展に気づけるか、現在の体制で運用できるか、リリースを十分に検証できるかです。Jira課題の選択肢のそばに書き、同じ問題を全員で評価します。

すべての要素を正確な点数に還元できるように扱わないでください。表は議論を整理できますが、数学的に正しい答えを生むわけではありません。見積もりが不確かなら、その不確実性を明示し、追加調査が選択を変えるかを判断します。

選択を求める前に比較する

以下はチームの作業用比較です。メール送信がすでに存在し、ポータル内受信箱は新規開発になる、この架空のポータルを前提にしています。

Samの事例から、顧客は依頼の重要な変化を早く知ることを評価していると分かります。Priyaは動作を定義しないと繰り返しの編集で紛らわしい重複通知が出ると指摘します。Leoはこのシステムではダイジェストに追加のスケジュールと集約処理が必要だと説明します。

Mayaは具体的なトレードオフを判断できるようになりました。初回リリースでは意味のある状態変更に即時メールを使い、重複処理は実装チケットに明記すると決めます。小さな内部編集では顧客通知を送信しません。有用な通知でも頻度が高すぎるという顧客の反応が出たら、ダイジェストを再検討します。

この結果は意図的に「メールを使う」より具体的です。開発、テスト、サポートに選択の意味を伝え、再検討する条件も残しています。

Power PackでDACIマトリクスを作る

Jira課題でPower Packを開き、RACI / DACI Matrixを選択します。ModelをDACIに設定すると、使える役割がD、A、C、Iになります。

参加者一覧に決定の関係者を追加します。Power PackではJiraユーザーの検索と外部参加者の登録ができます。外部登録はマトリクスに人を表すためのもので、アカウント作成や課題へのアクセス付与ではありません。

成果物の画面で、決定する問いを1行追加します。画面上の行は成果物という構造ですが、明確な名前の決定もこのDACI例には適しています。関係のない実装作業は最初の行に含めず、役割を読み取りやすくします。

マトリクスでLeoにD、MayaにA、SamとPriyaにC、ElenaにIを設定します。セルをクリックすると役割が切り替わります。フォーカスのあるセルでは、画面に示された役割文字のショートカットも使えます。

行の表示を確認します。Power Packは承認者が不在、複数存在、推進者が必要な行を見つけます。これらは役割の不足を見つける助けになりますが、Mayaに組織上の権限があるか、Leoが十分な根拠を集めたかは判断しません。

課題を離れる前に保存表示を確認します。ローカルまたはオフラインなら、最新版を同僚がすでに利用できるとは考えないでください。人々が見つけ、一緒に話せる版こそが役立つ合意です。

使える結論で議論を閉じる

役割マトリクスに決定全体が入るわけではありません。選んだ方針、理由、重要な影響を課題の説明やPower PackのDecision Logに残します。後から同僚が理解できるよう、真剣に検討した選択肢も記載します。

その後Leoは、通常の連絡手段でElenaに簡潔な結果を伝えます。何をリリースし、どの通知を含み、何が対象外で、実装作業がどこにあるかを説明します。マトリクスでElenaをIにするだけでは、この連絡は送られません。

必要な実装チケットを通常のJiraワークフローで作成または更新します。この例では重要な状態変化の検出、重複処理、検証が対象です。DACIは決定内の役割を記録するもので、Jira担当者や課題状態を自動変更するものではありません。

規模に見合った使い方をする

実際の選択が、参加者や権限の不明確さで止まっているときにDACIを使います。エンジニアがもともと決められる日常的な実装詳細なら、短いメモで十分かもしれません。小さな判断すべてにマトリクスを作ると、維持が難しくなります。

問いが変わったら役割も見直します。後から有料の通知サービスを検討するなら、支出の承認は別の人が必要かもしれません。元のプロダクト決定が、黙って新しい権限まで含むわけではありません。

現在のJira作業から未決の問いを一つ選びます。境界を定め、推進者と1人の承認者を合意し、必要な具体的な意見を洗い出します。Power Packで課題のそばに役割を見える形に置き、決まったら記録して伝えましょう。

• Atlassian Team Playbook：DACI意思決定フレームワーク