デザインドック(Design Doc)について

rebuild.fm

rebuild.fm でデザインドックという耳慣れない単語が出てきたので調べてみました。
エピソード内では書くのが大変、会議が進まない、生産的でないなどわりと否定的なトーン。
なんでも、デザインドックと銘打つと噛み付いてくる人たちが一定数いるそうです。
そのため、ゲストの @omo2009 さんはDesign Doc ではなく、Note と呼ぶようにして彼らを寄せ付けないようにしているらしい。

というわけで以下にデザインドックに調べたことを簡単にまとめる。

デザインドックとは

デザインドック(Design Doc)とは、Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです。

一般的にDesign Documentというと、設計仕様書のことをさすようです。設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです。一方でGoogleのDesign Docは、あるソフトウエアについて、何を・なぜ・どのように作るかを記したものです。

Google の Design Doc について - Please Sleep

プロジェクト立ち上げ時の 1～2週間をかけて書く。ある程度ポイントが書けたら、もうコーディングへ。

コードを書いていると解離していくので、できるだけ解離しないようにアップデート。

Google のソフトウェア・エンジニアリング

デザインドックの内容

プロジェクトの背景、目的
- おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
- プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
- セキュリティやプライバシーについての考察(問題と対処方法)
- テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
- レポジトリ上の位置やサーバのアドレスなど

実際にGoogle社内で書かれたWebKit WebSocket のデザインドック
http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh

Dagger 2.0 のデザインドック
https://docs.google.com/document/d/1fwg-NsMKYtYxeEWe82rISIHjNrtdqonfiHgp8-PQ7m8/edit#

テンプレ
[O] Design Doc 的な何か用の Wiki 記法によるテンプレ

感想

いまやっている比較的小さなプロジェクトで試しに書いてみた。
rebuild でネガティブなトーンだったが個人的にはそんなことはなくて（ミーティングで使わなかったから？）書く意味は十分にあると思う。
走り出すために、事前に情報を集約させておいて走り出したらデザインドックはもう更新しないというやり方がいいと思う。
きちんとしたドキュメントを残すなら、デザインドックではなくて別に仕様書という形で残したほうが楽だし効率的と感じた。あくまでも自分たちがやることの目的や意味合いや実装を確認する準備運動的な意味合いとして捉えて、なにがなんでもメンテナンスするぞというのは現実的でない気がする。

「作るべきものの形をみる」ようにするためのものという認識でチーム内に浸透すればいい結果を生むのではなかろうか。