Design Doc

概要

• プロジェクトの導入資料的な位置付け

・プロジェクトの目的・背景

・おおまかな設計

・依存しているライブラリとバージョン

・考察事項，todo，今後の課題など

項目

• 背景、目的 (Why?)
• 検討した別の方法 (alternatives considered)
• トレードオフ (Why not?: なぜ別の方法にしなかったのか？)
• 設計、アーキテクチャ (How?)
• メンバー (担当者やレビュワー) (Who?)
• セキュリティやプライバシーについての考察など
• 他プロジェクトとの関連性
• テスト，モニタプランなど

参考資料

• 「Design Doc」って何なのか？
• デザインドックで学ぶデザインドック | フライウィール
• デザインドック(Design Doc)について - snowlongの日記
• Googleのデザインドックのマークダウンサンプルらしい
• 残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） - ＠IT
• Google の Design Doc について - Please Sleep
• 良いDesign Docs(Software Design Document)を書くためのリソース集
• Design Docs の逡巡- Message Passing

Appendix-1 項目

1. 目的と背景

- 機能の目的と背景を記述する
- 背景は自明なら省略してもよい
- 外部システムや既存システムの都合などで特別な配慮が必要である場合は背景にその旨を記述する

2. スコープ

- システムや機能提供する範囲を記述
- 範囲外の事項についても記述する
- GoalとNon-Goalみたいなもの

3. 全体像

- 機能の全体像（構造、アーキテクチャ）を記述する
- 関連コンポーネント同士のつながりが把握できる図があればよい

4. インターフェイス

- 機能やシステムを呼び出す際のインターフェイス
- WEB APIならエンドポイント、コマンドラインアプリケーションならコマンドライン引数などになる

5. 入出力

- システムや機能の入出力を記述する

6. データ構造

- システムや機能が使用するデータとその構造
- 例えば、JSONを受信して処理を行う機能であればJSONの定義や仕様が記述される

7. 処理フロー

- 処理の流れを説明する
- シーケンス図と補足説明程度であれば十分（コードと1:1である必要はない）
- 特筆すべきビジネスルールがあれば記述する
- エラー時の振る舞いも記述する

8. 備考

- その他特筆すべき事項があれば記述する

関連資料

- 要件定義書や発端となったやりとりなど、関連のある資料へのポインタ