意思決定フレームワークDACIの具体例と、直面した課題
今所属している会社が意思決定フレームワークとしてDACIというもの多様してます。
今の会社に入るまで知らなかったフレームワークだったので、新鮮で、今まで意思決定プロセスに比べ早くて、いいなーと。
しかし、使っているうちにハマった問題や課題もチラホラとでてくるようになってきました。
そもそも、自分が上手く使いこなせていない問題なのかもしれませんが、自分なりにDACIの概要と例、直面した問題をメモしていこうかと。
意思決定フレームワーク：DACIとは？
毎日のように行われる組織の意思決定を、Driver（発案者・推進者）、Approver（承認者）、Contributor（貢献者）、Informed（報告者）にきちんと役割分担して行うフレームワークです。
て、調べてみたら、自分より１００倍しっかりご説明されている方もいらっしゃいましたので、細かい定義はこちらをご参考したほうがいいと思います。
自社では特に、新企画のやるやら、新サービスの立ち上げやるやら、外部からデータなどを活用するビジネスモデルなので、どれをインテグレーションするしないなどの意思決定にやってました。
実際に行ったDACI具体例
下記私が実際におこなったDACIの例をご紹介します。この例では、私はDriverですね。Contributorはそれぞれの関係者（Head of 〜）、ApproverはVP of Product、InformedはCFOとか役員です。
このDACIは実際にある企業と共同で事業実験的な事を企画し、具体的には新しいシステム・機械学習モデルの開発と販促を行うというものでした。
-- 流れはこんな感じです。
１．推進したプロジェクトをまとめたDACIシート（Google Docとか、AtlassianのConfluenceなどを使ってました）をContributorの意見を聞きながら作成
↓
２．毎週木曜日に行われるDACI会議で上記使ってプレゼン・質疑応答、その場でContributorによるVoicing（※Voteではない。決議権はなし。意見だけ交換）
↓
３．Approverによる決議 OR 残課題があれば来週へ再決議（実際、Web Mtgですが、BIZTERAというシステムを使って全プロセスを記録・承認してました。）
↓
４．承認されればInform、上記のBIZTERAを使ったり、普通にメールで通知したり。
※余談ですが、この承認プロセスソフトウェアBIZTERA、従業員が遠隔に散らばってるような企業には結構便利ですよ。無料版もありますし、高くもないし。デモサイトの動画で大体どんなものなのかわかりま。
-- 実際のDACIシートには下記のような構成でした。
DACIメンバー：それぞれのメンバーを記入（メンションとか飛ばしておくと、通知が行って便利です。）
Action Summary：簡潔に具体的に「何をやるか」のサマリー
Risk Summary：上記をやる時に想定されるリスクのサマリー
Values：これを行うことの意義・理由・得られる結果的な物を数個に分けて説明します。それぞれに説明と、それぞれのリスクを記入。（私は表を使ってました。ココに一番時間使ってましたね。）
Background：このプロジェクトの背景について
Goals：このプロジェクトのゴールを具体的に説明
Process：このプロジェクトのステップ、Todoなどを時系列で説明
Resources：このプロジェクトにかかる、金銭的・人的リソースの見積もり。エンジニアの工数なども見積もります。
質疑応答欄：DACI当日までの細かい質問とか上のメンション飛ばされた人が書いてきます。Confluenceとかなら、コメント欄で質問とか解答ができますね。
個人的にDACIのポイントは意思決定の「スピード」「質」「実行」を担保
意思決定プロセスに特に大事なのはその「スピード」「質」「実行」だと思ってます。
遅ければ出遅れますし、質が悪ければ失敗に終わりますし、そして実行できなければ意思決定した意味がありません。
この３つにDACIは、それぞれ担当者を明確にしてよく機能してるのかなーと。
DriverはとりあえずSpeedを意識してすすめるよう言われてました。とりあえずSpeed、質はApproverやContributorで上げてくものだと。
上で紹介した例でもありますが、ポイントはこういったContributor決して承認権限はない事。Informedもないこと。（※ここが後々の課題に。。。）
そういう意味で、とても良く出来て、上手く行っているものだと思います。日々大量の意思決定を下し、「これ誰が決めるの？誰がやるの？〇〇さんはやめなと言ってるよ。」的な会話が多い企業にとっては特に。
直面したDACIの限界
さて、ここから自分がハマったところです。
DACIとても良いと思うんですが、下記のような時に結構上手く行かない時が多いです。
プロジェクトが組織的に複雑で、Contributorが多く複雑・変化が多い場合。
わかりにくいですが、例えば、上のDACIでContributorはエンジニアのヘッドだったり、開発のトップだったりするんですが、実際あたらしいシステムを作るとなると、手を動かすのは各担当者で、その他様々な部署や機能へエイ影響があります。
承認がおりてGOになったはいいものの、いざエンジニアのヘッドが要件をメンバーに下ろしてみると、「え、聞いてないしできないよ？」とか「いやこの仕様、他の案件と合わないから。」や、関連する部署も「そんな事こんな期間にできません、きいてません」みたいな感じで、なんか雰囲気も悪くなるんですよね。
じゃあ、DriverがDACIを上げる際に、それらContributorを全員巻き込むべきかというと、それもそれで大変で、それぞれにまるでContributorにプチ承認をとりにくような感じに。しかもスピードが大事なのに、この社内調整が一番時間かかったりして。
え、誰がApproverでだれがContributorなの？という感じに。しかも、決議が決まった後InformedがいきなりContributorになったり、Approverになったりする時も。その逆も然り。
案件にもよりますが、とっても複雑でContributorが複雑で多い、かつ変化の可能性が多いDACIは、なんだか無理やりトップダウン意思決定みたいになっちゃう事がありました。
そうゆう意思決定には、ステコミみたいな運営がいいのかもしれませんね。個人的には時間かかりすぎ＋根回しばっかりであまりファンではないですが。
でもチームの雰囲気も大切だと思います。超トップダウンではなく、自分の意見を聞いてもらえるって誰でも嬉しいですもん。
DACIは、もっと単純で、できればDriverが実際のプロジェクトを自分で遂行できる、＋Contributorが少なく単純なものにはいいのかもしれませんね。
この記事が気に入ったらサポートをしてみませんか？