色々なプロジェクト（案件）をチームで進める時に、何かしらのドキュメントを書く機会が多い。
プロジェクトの中でも担当するスコープがそれぞれではあるので、内容が変わるところはあれど目的とか共有するべき事があるので、それをまとめている。
まとめているものがちゃんと伝わっているのか、共有できているのか、というのはあるのだけど、、、
プロジェクトの概要をもう少しざっと整理して共有するという意味合いでは Design Doc の考え方を導入するといいのかもしれない、と思った。
- 安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明｜note
https://note.com/omokawa_yasua... - 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
https://tkybpp.hatenablog.com/... - Design Docはじめました｜saitoxu｜note
https://note.com/saitoxu/n/n9b... - Design Docをビジネス職で応用する｜YuMMy｜note
https://note.com/sakkunakasaka...
言葉は知っていたけど、意識して書いた事は無かった。
ドキュメントのフォーマットとかをまとめておきながらブラッシュアップしていこうと思っているところではあるのだけど。
大体最初の扉ページ？見たいなところにこの Design Doc のようなものを置くといいのかもしれない。
要件定義みたいな発注者との認識確認とかに使うのは難しいかもしれないが、、、
とはいえ、堅めの文面モリモリドキュメントとか読んでてつらくないのかしら、、、と思うから、わかりやすい構成になっているドキュメントの方がいいような気が個人的にはする。
それは先日『エンジニアなら知っておきたい システム設計とドキュメント』を読んでいるときも同じような印象を持った。
ウォーターフォールとアジャイルでのドキュメント、設計の話の差異とかあったけど。
進行方法が異なるからドキュメントの意味するところも変わるところとかはあるんだろうけど、そこまで変わるものなのかなぁ、とか。
ノートをどう作って整理していくか？みたいな話にも近そうなきがするが。。。
話がずれたけど、開発・実装に関するドキュメントを整理していく過程で、まずは Design Doc を最初に置いてみるというのがとっかかりやすいのかもしれないと。
開発が終わってプロジェクトが運用フェーズに入っていくと、また目的が変わってくるだろうから、そうなったらその Design Doc の上に運用に関する Design Doc なのか扉ページなのか、なにかができることで見通しが良くなりそうな気がする。
実装設計書と運用設計書みたいな。
ドキュメントも作ったら終わりではなくて開発中も更新が必要だし、フェーズが変わったらそれにあわせて更新・調整していく必要がありそう。
様々な視点が必要だろうから、特定の人だけが作る物ではなくチーム、関係者でアップデート・コメントしていけば、使えるドキュメントが残っていくと思う。