Design Docをビジネス職で応用する
想定読者
データアナリストや〇〇Ops、企画職などプロジェクトのマネジメントに関わる方
プロジェクトマネージャーの元でプロジェクト推進を行う方
(エンジニアの方)
Design Doc とは
2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると、Design Docは「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものらしい。
Design Docとは一般的に設計書のことを指し、開発組織で多く活用されるものだが、プロジェクトの成功確度を高める観点で、ビジネス職でも十分に活用できるものであると考える。
弊社では情報共有ツールとしてKibelaを導入しており、私自身、アナリティクスやOpsを始めとするプロジェクトマネジメントに携わる中で、ドキュメントの重要性は日々痛感している。
自分の理解の整理につながる
プロジェクトに関連する事象について網羅的に考察する機会を得る
文章化することで、複雑、曖昧な部分が明確になる
早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得る
プロジェクトの目的から解決策、実行に至るまでの合意形成
新しいメンバーがプロジェクトを理解する手助けになる
etc...
ドキュメントのお作法？としてよく知られるDesign Docだが、まずはイメージしやすいようにいくつかの実例を上げた上で、作成において気をつけることなどを記述していく。
Design Docの実例
典型的な記述項目
記述項目のテンプレートとしては上記がわかりやすく、参考になりそうだったが、プロジェクトによって考慮事項や解決策の複雑性に変化が大きいため、項目を一般化して運用するものとは言えないだろう。
プロジェクトにMECEで柔軟な選択を持たせることで成功確度を高めることがDesign Docの価値の一つでもあるため、形式張らないドキュメントでプロジェクトにとって最も意味のある形で記述することが求められるようだ。(むずい)
①Design Doc作成の事前準備
Design Docでは、目的(Goal)と要素や環境(Facts)がセットになった状態での目的達成への手段の明確化と、それらすべてに対し、それらが適切である根拠が常に明示されている状態が最低限求められる。
それにより、プロジェクトに関連する事象について網羅的に考察することや解決策に対しクリティカルな視点が入るなど、プロジェクトの成功確度の向上につながる。
そのため、事前にプロジェクトの関係者や有識者を交えながら、GoalとFactsを適切に定義していく必要がある。
したがって、Design Docというものはいきなり書き始めず、まずは 「目的(Goalとnon Goals)の理解」 とそれに 「必要な要素や環境(Facts)の理解」 を言語化していく。
目的(Goalとnon Goals)の理解
当然だが、関係者間で目的を明確かつ簡潔に言語化することで、プロジェクトの共通理解を常に持ち続けることが重要。
また、目的(Goal)と混合されやすいようなものを、意図的に目的(Goal)から除外するもの(non Goals) としてリストにしておくことも非常に重要。
これにより、ときにはGoalに立ち戻って意思決定を行ったり、プロジェクトの迷走を防ぐことができる。
必要な要素や環境(Facts)の理解
目的達成のための手段が適切であるかを確認する。
とくに、開発の場合には使用する技術や手法、アルゴリズムが要求仕様(目的)を実現し得るか確認する必要が出てくる。
ビジネス面では、たとえば普段取り扱わないようなダッシュボードや分析結果をアウトプットするために使用するツールやデータなどが、目的の要件を満たしているか確認する必要があるだろう。
詳細は後述するが、作成するDesign Docの価値を高めていくには、
使用するツールやデータが明確な場合には、なぜそれが目的達成のために適切であるのか、
また、適切なツールやデータが社内には整備されておらず、そのための準備が必要な場合には、さらにブレイクダウンしていき、理由や背景を明確化しながら整理していく必要がある。
とくに、データアナリストやOps職の方は、データアーキテクトやデータマネジメントもプロジェクトでカバーしなければいけない領域の一つになることが多いのではと思う。
そこで、下記のシステムコンテキスト図のように、アウトプットに必要なデータやツールの関係性などを可視化しておくのが吉だろう。
②Design Docの作成
①での整理をベースに、以下を中止ながら項目を立て明確に言語化し作成していく。
結論だけでなく、理由や背景(Bacground)を記載
まずは、プロジェクトが発足するにあたった背景(Bacground)を簡潔に記述すること。必要に応じて、理解をサポートするための資料も添付する。
これらはあくまでも主観に基づく内容ではなく、客観的事実をベースに共有しながら、以降の内容を素早く適切に理解するためのサポートを行う。
そして、先述した「Goalを達成するため---手段が適切である根拠が常に明示されている状態」を目指すために、各論にて5W1Hを意識したBacgroundを記載していく。
それにより、一つひとつの意思決定の背景が汲み取れるため、レビューや振り返りが非常に有用でかつ効率的なものになる。
メンバーから「なぜ？」「どうやって？」などの質問が出るたびに、テキストとして記述していくと、ドキュメントの価値は上がっていくだろう。
プロジェクトメンバーやFactsに関して知見の深いメンバーと常に共有する
現場感や整理事項に知見の深いメンバーからの質問や提案などを通じ、ドキュメントがもつプロジェクトの解像度を上げていくことで、その価値は高まっていく。
とくにプロジェクトメンバーへの共有では、ただ閲覧権限を付与して共有することではなく、意図的に見てもらう機会を与え、議論は常にドキュメントを通じて行うということに注意したい。
Design Docのもつ大きな価値の一つには、このコミュニケーションの活性化、円滑化も含まれていることは忘れてはいけない。
また、専門の知見をもつメンバーに対しては、きちんとレビューを貰う機会を作ることが重要。
有識者からのレビューほど偉大なものはなく、
組織全体の共通資産となる
セキュリティ、プライバシーなどの横断的な懸念事項の考慮によるリスクマネジメント
プロジェクトの手戻りや変更点の減少(レビューのタイミングが早ければ早いほど良い)
と、プロジェクトの成否を分けるような事象にクリティカルにアプローチすることが期待できる。
Design Docに適したツール
Design Docを作成するのに最も代表的なツールがGoogleドキュメントだろう。
Googleドキュメントの良い点は、レビューによるコメントや共有範囲が簡単に設定でき、リアルタイムでの同時編集が可能な点だろう。
開発組織では、GitHub + Markdownによる管理もあるようだが、エンジニア以外の活用ハードルの高さはありそう。
Design Docを書くべきではないとき
ここまでを読むと、Design Doc(ドキュメント)は大事かもしれないけど作成するのめっちゃ大変じゃんと思う方が大半ではないだろうか。
もちろん、Design Docもプロジェクト完遂のための一つの手段であり、労力とトレードオフの関係である。そのため、これにかかる労力が、設計、文書化、上級職によるレビューなどに関する組織的な合意形成のメリットを上回る場合はDesign Docを書くべきではないだろう。
一見複雑で難儀な意思決定に思えるかもしれないが、考慮事項は非常にシンプルで、いずれかの解決策が曖昧であるかどうか、つまり問題の複雑さが原因なのか、解決策の複雑さが原因なのか、あるいはその両方なのかということ。
プロジェクトが複数回にわたり実行されており、再度の実行における懸念が上がらない場合は言わずもがな、社内の事例をアナロジーとして転用できそうなものなどは、わざわざDesign Docに労力を割くのは適切な意思決定とは言えないだろう。
反対に、考えられる解決策が複数上がったり、意思決定に係る要素が多岐にわたる、複雑である場合などにはDesign Docを起こすのが賢明と感じる。
しかし、そもそもプロジェクトというものは都度ドキュメントに残すことで、ナレッジの蓄積や課題の顕在化、コミュニケーションを円滑にするなど多くのメリットをもたらしてくれる。あくまで、Design Docの粒度でドキュメントを作成するかの選択の問題であると思う。
そのため、素早く人を巻き込み、要件を抑えたドキュメントを適切な粒度で作成しながら、プロジェクトやコミュニケーションを円滑に進められるということは、プロジェクトをマネジメントする上で最も重要なスキルの一つであると認識している。