設計書のメンテナンスについて
設計書について思うこと
設計書いる？
- 初期開発では必要
- ゼロから作るので設計書がないと作れない
- 設計内容を共有できる
- レビューできる
- 設計者以外が実装できる
- 保守開発でも必要
- 画面設計やテーブル定義など外部設計書は必要
- 知らない機能を触る前に機能を把握できる
- 詳細設計など内部設計書は不要
- コードを見ればいい
- メンテナンスが面倒
- 画面設計やテーブル定義など外部設計書は必要
設計書みる？
- 知っている機能だったらほぼ見ない
- 知らない機能だったら見る
- 見るけど100%は信じない（コードと乖離している場合があるから）
- 最終的にはコードを見る
設計書のメンテいる？
- 外部設計書はメンテが必要
- 内部設計書のメンテは費用対効果が低いから、削除するかアーカイブした方がいい
設計書とコードの乖離
- コード修正→
- 設計書の修正漏れや誤り→
- 設計書とコードの乖離→
- 信頼性の低下→
- メンテされなくなる
- 信頼性の低下→
- 設計書とコードの乖離→
- 設計書の修正漏れや誤り→
- 設計書がメンテしにくい（Excelとか）→
- 設計書の修正漏れや誤り→
- 設計書とコードの乖離→
- 信頼性の低下→
- メンテされなくなる
- 信頼性の低下→
- 設計書とコードの乖離→
- 設計書の修正漏れや誤り→
設計書はどうあるべきか
前提
- 設計書はコンフルエンスなどメンテしやすく、履歴が追えるフォーマットを使う
初期開発
- 今までどおりに設計書を作る
保守開発
- 初期開発の完了時点で設計書をリバイスする（可能であれば）
- Excelなどのメンテしにくい設計書はコンフルエンスなどに移行する（可能であれば）
- メンテナンス対象の設計書を明確にする
- 詳細設計書など役に立たないものは削除するかアーカイブする
- 開発フローに設計書修正を入れて、レビューする
参考文献
- 詳細設計書の必要性
- 設計書のメンテナンス
- 後から設計書を作る
