Design Docはじめました
こんにちは，Caratの斎藤( @saitoxu )です．
少し前からバックエンドの開発チームでDesign Docを導入しました．
今回は導入の背景と，チームでの使い方やテンプレートの紹介，導入してみての良し悪しなんかについて書きたいと思います．
Design Docとは？
Software Design Documentのことで，実装前に書くソフトウェアデザインに関する文書です．
仕様書やPRD（Product Requirements Document）のようにしっかり書くものというよりは，どちらかというと抽象的なレベルでのソフトウェアデザインの認識合わせや，関係者と合意を取るためにラフに書くもののようです．
初出から10年くらいは経っていてそこそこ枯れた文書の種類なので，まとめ記事があったり，メリット/デメリット，要る要らない，など様々に議論されています（参考↓）．
導入の背景
GLITの開発チームでは，チケット単位で見ると大まかには
①要件定義 → ②工数見積もり → ③実装 → ④コードレビュー → ⑤QA → ⑥リリース
という流れで開発が進められています．
GLITのバックエンドのシステムもそれなりに大きく複雑になってきたため，バックエンドの要件定義をしっかりして，それをロスなくエンジニアに伝達するというのがなかなか難しく，後のプロセスで手戻りが発覚ということがしばしばありました．
※アプリやフロントエンドとは異なりバックエンドは，目に見えるものがないのと，デザイン・プロトタイピングツールによるサポートもないので，そもそも意思疎通が難しいという事情もあると思います．
なるべく後戻りをなくすようにとチームで考えた結果，実装前にDesign Docを書いて認識を揃えると良いのでは？となり，今回導入してみることになりました．
使い方やテンプレートなど
運用ルール
「②工数見積もり」の段階で，一定以上の時間がかかりそうなチケットのときはDesign Docも書くというルールにしています．
それほど実装に時間がかからなそうな細かいチケットまで書くと，書くのにもレビューするのにも時間がかかり費用対効果が悪そうと思い，今はこういう運用にしています．
レビュー
必須で読んでほしい人(must)と，できたら読んでほしい人(want)をレビュワーに指定できるようにしています．
レビュワーとのディスカッションを通して，ソフトウェアデザインを改善したりチケットに関連する不明点などを解消していきます．
テンプレート
最初はどういう構造が良いか分からないというのと，書く敷居を下げたいという考えから，かなり緩めなテンプレートを使っています．
## 概要
ドキュメントの概要を書く
### 参考情報
チケットのURLや要件ページのURLなど，ドキュメントを読む上で前提となるような参考情報を載せる
### このドキュメントの役割
ドキュメントの役割を書く．このドキュメントを読んでもらって何を達成したいのか
## 内容
自由記述
## 確認事項
明示的に確認したいことを書く
## LGTM
この記事を読んでほしい人のmustにいる方は記事をレビューして問題なければ，下記のようにチェックボックス + 自分の名前を追加してチェックをお願いします．
- [x] @Carat Taro導入してみて
期待したとおり，実装前に大まかな方針の認識合わせや，方針の改善ができるようになり，手戻りが発生しにくいフローになったように思います．
Design Docを検討した結果，そもそも今やるべきではないのでは？というチケットもあったりして，開発の効率性を高める意味でも役立っていると思います．
今のところ特にデメリットと感じるようなところはないのですが，これから運用を続けてみて何かあればまた改めて記事にしたいと思います．
おわりに
今回はDesign Docの導入についてでした．
今後も開発プロセスの改善にトライした事例を紹介していければと思います．
最後に，弊社では日本の仕事探しにおける負を一緒に解決してくれる仲間を募集しています．
下記の募集ポジションまたは，その他少しでも興味を持たれた方は斎藤のTwitterまでお気軽にご連絡ください．
この記事が気に入ったらサポートをしてみませんか？