読了。やっぱり、どこの会社もシステムの設計ドキュメントの課題はあるのか。課題がない方が怪しい。
開発の運用上、少しずつ仕様が変わっていくところには、ADR（Architecture Decision Records アーキテクチャ意思決定記録）は、良さそう。どうしてその仕様にしたのかを記録し、OK/NG判定で残るので、シンプルでいい。もとのExcelとかの設計を直すよりもいいのかも。テキスト形式で行うので、Gitで管理、Pull requestでワークフロー化して、承認フローにしていく運用をしているところが多いようなので、管理もやりやすそうだ。関係者が多かったり、大きいプロジェクトでも使えそうなのがいいのかも。改修要望のチケット管理に参照を貼るのも良さそうだし。
あとは、そもそも設計書を作らずパターンもあるのか。コードの冒頭に設計を書いてしまうパターン。改修後の状態を記録していくならば、もしかしてこれが一番楽かも。どうせドキュメントの修正が頻繁に行われないのであれば、詳細設計にあたるような部分は、ソース上に書いてしまい、抽出するか、直接参照したほうが早そう。ソースの肥大化につながるがテキストならば、そこまで大きくないし、PC側のパワーが解決してくれるだろうし。関係者が多くなければ、手っ取り早い手法で良さそうだ。
それから、設計でつかうツールも多種多様。企画段階はMiro、画面系はFigmaでツールの切り替えが行われていくところが多いのか。それぞれのシーンでの専用ツールも。その工程の生産性をたかめるためだとは思うけれど、使い勝手のよい万能ツールはなさそうだ。あとは、オーソドックスなWord、Excel。
いろいろと参考になった。読んでよかった。
Amazon: https://amzn.to/4gMZd17