/note/tech
- システム開発では諸々のドキュメントが書かれるわけだが、その多くは一過性のものになりがちでは？
- 例えば、初期に書かれた設計書（的なドキュメント）は、メンテナンスや機能追加のタイミングで記述される内容とは解像度とでも言うべきものが異なるためか修正を重ねるごとに歪な内容になりがちである
- それを思うと、そもそも設計書なるものをメンテナンスし続ける意味はあるのだろうか？
- 要件や仕様の変更は都度個別に仕様化すればよいのでは？
- それではベースとなる仕様は何で確認するのかという話になるが、それは操作マニュアルという体裁で事後に作成すればよいのでは
- 次回開発は操作マニュアルの挙動を基に行われるというサイクル
- 機能の設計ドキュメントはチケットなりに残すが、あくまで一過性の情報として扱い、ドキュメントという体裁で記録はしない
- 先述した通り、要件定義書やら外部設計書やらをメンテナンスし続けても胡乱なドキュメントが増殖していくだけなのではないかという問題意識がある
- 勿論、APIや外部システムI/Fは事前に定義されなければならないが、機能要求とその詳細に関してはユースケースシナリオやユーザーストーリーレベルの解像度で十分なのではないだろうか
- そこから逆算すると開発前に詳細に定義されるべき情報は、概ね以下のイメージだろうか
- DB定義
- データ定義（フラグ値やステータス値など）
- 外部システムI/F
- ビジネスルール
- 用語集（DDDにおけるユビキタス言語）
- つまり、変化しない/させづらいものということになるだろうか
- 逆にUIや機能要求は割と変化しやすいし、むしろそうであるべき
- したがって、それら（UIや機能要求）の情報は開発が一段落した後にリバースエンジニアリング的にまとめる方が合理的であるはず
- 操作マニュアルとは言ったが、対象とする読者は利用者だけでなく運用チームも含まれるので、データの状態遷移などの情報も必ず記載されるべきである
(2018/09/24)