あおい
選択肢を全員が理解していても、リリースの議論が進まないことがあります。プロダクト担当は公開したい、サポート担当は準備時間がほしい、開発担当は対象を絞りたい。最終的に誰が決めるのか分からなければ、次の会議でも同じ意見が繰り返されるかもしれません。
DACIは、その意思決定に必要な役割を明確にします。チームで共有するオンラインホワイトボードに、決めたい問い、関係者、判断材料を選択肢と並べて置きます。目的は全員一致ではありません。権限を持つ人が必要な情報に基づいて決め、影響を受けるチームが意味を理解できるようにすることです。
DACIの四つの役割
Atlassian Team PlaybookのDACIガイドでは、次の四つの役割を区別しています。
- Driver（推進役）：判断を前に進める人です。必要な情報を集め、意見の提出を調整し、合意した決定日を共有します。
- Approver（決定者）：今回の意思決定を行う一人です。別の場所で決まった結果に形式的に承認を与えるだけの人ではありません。
- Contributors（助言者）：選択肢の評価に必要な知識を提供する人たちです。意見は判断材料になりますが、一人ずつ投票権を持つという意味ではありません。
- Informed（共有先）：今回の判断には参加しなくても、仕事に影響があるため結果を知る必要がある人たちです。
全部署を一つの欄に並べず、担当者を明記します。「プロダクトと開発」では決定者を特定できません。また、この枠組みが本人にない権限を新たに与えるわけでもありません。組織で定められた責任の範囲で、誰がその問いを決められるのか確認します。
公開範囲について一つの問いを立てる
新しいファイル共有機能を開発する架空のチームを考えます。対象を限定して公開できる段階ですが、公開方法は未決定です。問いは、「希望者による試験利用にするか、一般公開するか、それともサポートの準備が整うまで公開を延期するか」です。
決めるのは公開範囲であり、必須のセキュリティ確認を省いてよいか、アクセス方針を変更してよいかではありません。決定者がその権限を既に持っていない限り、こうした制約は裁量の外にあります。選択肢を論じる前に境界を明記します。
顧客への案内日程を組む前に、チームは答えを必要としています。この実際の依存関係を決定日のそばに記します。根拠のない締め切りは早すぎる判断を招きますが、実際の作業に結び付いた日付なら、何が待っているかを説明できます。
例の役割を割り当てる
| 役割 | 担当例 | 今回の判断で行うこと |
|---|---|---|
| Driver | プロダクトマネージャー | 選択肢の説明を集め、不足する根拠を求め、判断の議論を準備します。 |
| Approver | 公開権限を持つプロダクト責任者 | 合意したリリース条件の範囲で公開対象を選びます。 |
| Contributors | 開発責任者、サポート責任者、リサーチャー | 公開の制御方法、サポートの準備状況、利用について観察したことを説明します。 |
| Informed | 顧客対応チームとドキュメント担当者 | 決定した範囲、時期、自分たちの仕事で必要になる変更を受け取ります。 |
同じ人でも、ある判断では助言し、別の判断では共有を受けるだけという場合があります。分かりにくい権限変更の説明が公開の前提なら、ドキュメント担当者は助言者になります。肩書きで役割を固定せず、問いに合わせて割り当てましょう。
同じ問いで選択肢を比較する
各案で何が可能になり、どのようなリスクがあり、実行には何が必要かを問います。期待する利点と、それが実現する根拠を分けておきます。
| 選択肢 | 検討する理由 | 未解決の条件 |
|---|---|---|
| 希望者による試験利用 | 対象者を明確に限定して、新しい体験の利用状況を観察できます。 | 参加者を特定して支援し、必要なら以前の体験へ戻せますか。 |
| 一般公開 | 利用者のグループごとに異なる体験を維持せずに済みます。 | 対象者全員に向けたサポート資料と公開制御の準備はできていますか。 |
| 公開延期 | 不足する準備を終える時間を確保できます。 | どの作業が懸念を解消し、誰が担当しますか。 |
「開発は試験利用を希望している」は意見です。「特定のアカウントに限定できるが、サポートは新しいエラーメッセージを未確認だ」は決定者が使える情報です。その主張を最もよく知る助言者に、根拠と分かっていない範囲を説明してもらいます。
試験利用を安全に元へ戻せるか分からないなら、担当者付きの質問として残します。「たぶんできる」を確認済みの条件に変えてはいけません。推進役が次に行うべきことは、広い議論の会議を増やすことではなく、その答えを得ることかもしれません。
異論を隠さずに決める
追加確認により、限定した試験利用が可能で、サポートも選んだ対象者に対応できると分かったとします。決定者は希望者による試験利用を選び、サポート資料が完成するまで一般公開は行わないと決めます。決定を一文で残します。
「指定したリリース確認が完了したら、対象を限定した希望者向け試験利用を開始する。サポートの準備状況を確認するまでは公開対象を広げない。」
理由も同じくらい重要です。試験利用なら、現時点の支援体制に合わせながら利用状況を観察できます。サポート責任者の懸念、検討した根拠、対象を広げる条件を記録します。不確実性がすべてなくなったと言わなくても、決定は明確にできます。
必須確認を満たせなければ、その決定は実行の許可にはなりません。試験利用を止めるのか、別案に変えるのか、別の権限者の判断が必要なのかを記します。「決定者がよいと言った」を、最初に記録した制約の代わりにしてはいけません。
Boardmixに読み取れる判断記録を残す
Boardmixのキャンバス上部に問いと対象範囲を置き、その隣に小さなDACIの役割欄を作ります。下には三つの選択肢を並べ、理由、懸念、根拠、未解決の質問を同じ項目で記します。案と決定済みの計画を混同しないよう、最終決定は別の場所に残します。
議論中に分かった事実は、対応する質問の隣に加えます。未確認の主張は未解決と分かる状態にします。決定後は、内容、理由、次の作業の担当者、共有先を記します。これは判断のための視覚的な記録であり、承認を自動化したり、製品公開の権限を付与したりする機能ではありません。
意思決定ログには、議論後の結果を残せます。コメントをすべて複製せず、関連する作業ボードへリンクします。共有先には説明のない会議のスクリーンショットだけでなく、決定内容、自分たちに必要な変更、理由を確認できる場所を伝えます。
Boardmixのボードを開き、何度も議論に戻ってしまう次の判断を整理してみましょう。最初に問いを書き、決定者を一人決めます。そのどちらにも合意できなければ、次の選択肢を比較する前に解決します。
