https://atmarkit.itmedia.co.jp/ait/articles/1606/21/news016.html
IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。
連載1回の「ドキュメントは最強のコミュニケーションツールである——Joelの機能仕様書入門」、第2回の「サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック」では、「ユーザー視点」で要求仕様を表現する「Joelの機能仕様書」について説明しました。第3回目となる今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。
なお、主に想定している読者は、「プログラミング経験はある程度あるが、設計書をあまり書いたことのない初級〜中級のエンジニア」です。
Design Docは、グーグルに代表される最先端の技術企業で取り入れられている設計ドキュメントのスタイルです。単にドキュメントの書式だけを指すのではなく、書いた後の使い方までを含めた『開発のやり方』につながっているドキュメント方式です。アジャイルなどの現代的なソフトウェア開発スタイルにフィットしているため、シリコンバレーのスタートアップ企業などで広く受け入れられているようですが、筆者の実感としては日本ではいまひとつ普及していないように思えます。
Design Docは、エンジニアがこれから開発しようとするソフトウェア設計の基本的な要点——何を（What）・何のために（Why）・どのように（How）作るのか？——を説明するために書くドキュメントです。要点だけを書いて、それ以上詳細なことは『書き過ぎない』ことが重要です。現代の開発スタイルでは、詳細な情報を得るには『ソースコードを見た方が早い』からです。
Design Docには、誰でも読める自然言語（日本語や英語）の文章で書くことが必要です。図やチャートを使ってもよいですが、それらは文章を補助するものという位置付けです。読者の皆さんも経験があると思いますが、図やイラストだけの資料だと、しばらく時間がたってから見ると正確な意味が分からなくなってしまうことがあります。情報の正確さや再現性の高さでは文章が一番です。
Design Docの最初の読者は設計者自身です。他のドキュメントと同様に関係者に公開して情報共有に使う役割もありますが、設計しているエンジニア自身の「思考の道具」としても価値が大きいものです。
システム設計は時間のかかる複雑な作業です。関連するさまざまな要素について検討し、課題を解決し、それぞれの仕様を決定していかなければなりません。人間の脳は、そうした複雑な問題全体を一度に考察するのは苦手ですので、何らかの形で分解して、途中経過を記録しながら作業を行う必要があります。
そのための手段としてもDesign Docはうってつけです。Design Docは常に変化し、生きているドキュメントです。試行錯誤の途中のアイデアでもよいので、どんどん書き出してみて、何度も修正しながら仕上げることができます。
アジャイル方式などの繰り返し型開発や、メンバー全員が1カ所に集まらない分散型のチーム運営など、今どきの開発スタイルを使うチームに導入してもDesign Docは効果を発揮します。
具体的なDesign Docの実例を見てみましょう。日本語でDesign Docを公開されている事例が少ないため、英語版のものを引用してみます。英語が苦手な人も、項目タイトルだけ辞書で意味を確認してみれば雰囲気が分かると思います。
実例を見ると分かるように、Design Docに決まったフォーマットはありませんが、記述される項目はだいたい似ており、およそ下表に示すようなものとなっています。