「DACINって何?」JADEの仕事を加速させている独自フレームワークとは(実践編)

「誰がやるの?」「誰に確認すればいい?」そんな曖昧さをなくすために、JADEが現場で使い続けているDACINフレームワーク。導入の背景から実務での使い方まで、座談会形式でお届けします。

「この仕事、誰がやるの?」

「これって誰に確認すればいいんだっけ?」

「あのタスク、結局どうなったの?」

こんな会話、職場で耳にしたことはないでしょうか。JADEでは、こうした問題が生まれないためのフレームワーク「DACIN」を導入し、業務の進め方を整えてから数年が経ちました。

【DACINについての過去の記事はこちら】

blog.ja.dev

blog.ja.dev

導入から数年を経て、JADEではどのように日々の業務を進めているか、どのようにDACINフレームワークが機能をしているか、を先日配信しました。YouTubeはこちらです。

youtu.be

【出演】

  • 長山一石(JADE ファウンダーCSO)
  • 篠原 誠(JADE シニア・コンサルタント)
  • 松尾直樹(JADE ジュニア・コンサルタント)

この記事では動画の内容からピックアップしてお届けしたいと思います。

 

DACINフレームワークとは何か

長山 DACINとは、JADEが主に現場で使っている意思決定と責任明確化の仕組みです。これを導入することで、タスクが決めやすくなり、宙に浮いたまま誰も手をつけない状態が大幅に減りました。

DACINの各文字が担う役割は次のとおりです。

  • DはDriver(ドライバー)でジョブを最後まで完了させる責任者
  • AはApprover(アプルーバー)でレビューし承認し結果に責任を持つ人
  • CはContributor(コントリビューター)でドライバーと共にジョブに貢献する人
  • IはInformed(インフォームド)で推移や結果を共有される人
  • NはNext Actionでジョブを終わらせるための次の一手

DACINの中心概念は「ジョブ」です。明確な成果物や目標があるタスクやプロジェクトを総称していて、1日で終わる小さなものから、複数タスクが重なる数週間規模のものまであります。「なんとなくやっておいて」ではなく、何をいつまでに完成させるかを具体化して、そのドライバーを決める。それがポイントです。

 

実務でどう活用しているのか

長山 篠原さん、普段DACINをどのように使っていますか?

篠原 案件でリーダーを担当しているときに使っています。誰かに仕事をお願いするとき、「こういうジョブがある」と伝えて、自分がアプルーバーになる場合、誰がドライバーになるのかをきちんと決めた上で、タスクとして入れて「この日まで」と期限を設定します。

長山 松尾さんはどうですか?

松尾 僕はドライバーとしての立ち位置が多いかもしれません。基本的に案件を進めるときはすべてDACINフレームワークにのっとって作業を進めていく感じです。

 

DACINフレームワークの導入効果

長山 実は私がこれを導入したとき、「こんな当たり前のことをフレームワーク化して意味あるのかな」と正直思っていたんです。でも、あるとないとでは違いますか?

篠原 全然違いますよ。大きなプロジェクトがあったとき、「これをやりたいね」となって、誰も進めずそのままの状態で半年進んでしまうということはよくあると思うんです。きちんと「誰がやる、誰が承認する」という最低限の枠組みを作ることで、物事が決まりやすくなります。

松尾 以前の会社ではこういったフレームワークはなかったので、上司が口頭で「こんな感じで」と言って、ふわっと進んでいました。曖昧な仕事が宙に浮いたまま止まることもあって、「そういえば、これどうなったんだっけ?」で全然進んでいなかったということはありました。

宙に浮いた無数のタスク

 

DACINの現場での具体的な使い方

篠原 例えば、「Weekly Ranking Update」というプロジェクト全体のドライバーをやっています。誰に仕事を振って、誰が承認するのかを明確にしておかないと、「あとでやったほうがいいよね」がいっぱいできて、そのまま何もしない状態が絶対に出てくるんです。

【Weekly Ranking Updateについてはこちら】

blog.ja.dev

松尾 広告運用がメインの仕事なので、毎日の入札管理タスクが発生します。そこでI(インフォームド)をよく使いますね。プロジェクトに参加している広告以外の人にも情報共有しますし、クライアントさんにも常に情報を伝えています。

長山 JADEのコンサルティングプロジェクトは基本的にチームで運用するから、SEOにせよ広告にせよアナリティクスメインのプロジェクトにせよ、チームで参画している誰かがいます。そのチームでプロジェクトを進めていく際に、このタスクのドライバーが誰で、チームの中で誰が特に知っておく必要があるのかを明確化するのはベストプラクティスです。

 

初めてDACINを使う時の注意点

長山 DACINフレームワークに慣れるまで大変だったことはありますか?

篠原 僕はシンプルだと思いました。最低限DとAを決めて進められるというのがあるので、特に戸惑ったことはないですね。

松尾 僕もそんなに困ったわけではないですが、ドライバーとしての責任を持つという意識が最初は少し慣れが必要でした。自分がドライバーという意識が薄いと、アプルーバーの人にドライバー的な役割を求めてしまったり、インフォームドの人に貢献を期待してしまったりすることがありました。

 

コミュニケーションの明確化

長山 最近気づいたのは、入社したばかりの方から「確認してください」というリプライをもらうことがあるんですが、それだとアプルーバーの役割を期待されているのか、コントリビューターなのか、インフォームドなのかが分からなくなります。承認してほしいのか、単に共有で認識していればいいのか、不安なところがあればツッコミが欲しいのか、どの程度関わればいいのかが「確認してください」だけでは分からないので、明確にしてほしいとお願いすることがあります。また、自分がアプルーバーでない場合、ファウンダーという肩書きで意見を出し過ぎると、ドライバーとアプルーバーがコンセンサスを取れているのに私の意見で左右してしまうのは申し訳ないなと思うことがあります。「ここの部分についてコントリビュートしてください」と明確にあれば意見を言いやすいですね。

 

C(コントリビューター)とI(インフォームド)の使い方

篠原 僕はDとAの最低限、あとはN(Next Action)の範囲で使うことが多いですが、CとIをどういうときに使うべきかをあらためて知りたいです。

長山 僕はインフォームドになることが多いですね。「こういうプロジェクトが発生していることは知っておいてほしい」という感じです。例えば、渋谷の撮影ブースを作るというプロジェクトでも基本的にはインフォームドとして参加して、ドライバーの方とアプルーバーの方が進めている中で、定期的に共有会をしてもらっています。結果として、私も出演するかもしれないので、後から文句を言わないよう先にインフォームドとして設定して定期的に情報を共有しておくんです。コントリビューターは、プロジェクトを進めるメンバーとして関わっている人たちです。プロジェクト全体から見るとコントリビューターでも、特定のタスクではドライバーになるケースが多いですね。

 

なぜDACINフレームワークが効果的なのか

長山 JADEの文化の中で「言葉の裏を読まない」というのがありますが、DACINフレームワークがなければ言葉の裏を読みがちな状況が起きると思います。例えば「やったほうがいいよね」的なことがディスカッションで出てきたとき、誰かがやるよという雰囲気になりますよね。言い出した人がやるのか、別の人がやるのか分かりませんが、空気を読んで「これは誰々さん、やってくださいよ」という雰囲気になりがち。でもJADEではそういうことはありません。言葉の裏を読まないという文化があり、DACINフレームワークはそれを仕組みとして体現できているので、そういった曖昧さがなくなっています。

【JADEのカルチャーがよく分かる記事はこちら】

blog.ja.dev

DACINが生まれた背景

松尾 このDACINフレームワーク、どこから来たものなんですか?

長山 これは私がTwitterで働いていたときに使われていたフレームワークです。元々よく知られているRACIというフレームワークがあって、ドライバーの部分が「Responsible(責任者)」だったんです。でも、ドライバーという言い方のほうが「このプロジェクトを前に進めていく人」ということがより明確になるんですよね。責任者というと「責任を負わないといけない」という感じになりますが、ドライバーという言い方のほうが良いかなと。プラスNext Actionがあるのも重要です。ディスカッションをして「今クォーター何やろうか」と進めていくとき、「このジョブのNext Actionは何ですか?」というのが意外と明確になっていないことがあります。それを言語化できるのは良いですね。

 

DACINの導入で変わった仕事のあり方

アプルーバーは明確な状態

フレームワークのない職場では、複数人に確認を取るといった曖昧な状況が生まれやすいと松尾は言います。

松尾 アプルーバーが明確じゃないと、「一応篠原さんに送っておいて、その前にちょっと長山さんにも確認取っておこうかな」みたいなことがありました。DACINなら篠原さんに確認すればいいというのが明確で、そういう点ではやりやすいです。

長山 逆に、アプルーバーが1人誰なのか決まっていることで、「あなたはアプルーバーじゃないよね」ということも分かります。アプルーバーじゃない人に「これはダメだ」と言われても、「いや、アプルーバーがいいって言ってるので」で終わっちゃうこともある。ドライバーにとっては、誰のコンセンサスを得ておけばこの仕事が終わるのかが見えているのはいいことかもしれませんね。

他の会社にいた方々からすると、こういうフレームワークがない中で仕事をするのは大変ではないですか?

篠原 雰囲気でやってますよ、多分。

長山 雰囲気でうまくいってるのって逆にすごいですよね。

 

JADEでの業務進行について、少しイメージしていただけたのではと思います。仕事の明確化と効率化を図るDACINフレームワークは、JADEの日常業務の根底です。「誰が」「何を」「いつまでに」という基本情報に加え、承認者や共有すべき人まで明確にすることで、タスクが宙に浮いたまま止まる状態を防ぎ、スムーズなプロジェクト進行を実現しています。タスクの責任者や承認者が曖昧になりがちな職場でも、DACINのような枠組みがあれば、そういった問題は大きく減ると思います。

DACINフレームワークやJADEでの業務に興味を持たれた方は、ぜひこちらものぞいてみてくださいね。

ja.dev