はじめに
これはアジャイル開発に限ったことではないが、必要最低限のドキュメントすら作成していないプロジェクトがちらほらある。
というか、作る文化が全く無いプロジェクトすら。
つまり、作る文化がないので、チームメンバも必要なドキュメントと認識していないのだ 
嘘だと言ってよ⚪︎ーニー！
と嘆いても現実にこういうプロジェクトは結構あるのだから仕方ない。
ドキュメントがあるのは当たり前ではないのだ。
前置きはさておき、、、
この記事ではアジャイル開発において、最低限必要なドキュメントについて記載していく。
※本当に必要最低限のドキュメントしか書いていないから、案件によってはアジャイル開発と言っても必要なドキュメントはこれ以外にも結構あると思うので、適宜必要に応じてドキュメントを作成すべき。
最低限必要なドキュメント
-
ユーザーストーリー（USM）:
サービスが実現したい機能や目的を簡潔に記述したもの。
例えば、「顧客として、商品を検索できるようにしたい」といった形式で記載します。 -
プロダクトバックログ:
ユーザーストーリーを含む、開発すべき機能や要件のリスト。
優先順位付けされており、プロジェクトの進行に応じて更新されます。
→カンバンとかで見ることができ、チームメンバがいつでも確認できる状態になっていればOK -
スプリントバックログ:
各スプリントで実装する機能や作業項目のリスト
→こちらもカンバンとかで見ることができ、チームメンバがいつでも確認できる状態になっていればOK -
要件定義書:
ユーザーストーリーを具体的なシステム要件に落とし込んだ文書。プロジェクトの進行に応じて動的に管理され、定期的に見直されます。 -
システム設計書:
プロジェクトの技術的側面を記述した文書。以下のような要素が含まれます:- ER図: データベースの構造を示す図（テーブル定義書など）
- API仕様書: 外部システムとの連携インターフェースの定義
- システム構成図: システム全体のアーキテクチャを示す図
- データモデル: アプリで使用するデータの構造や関連を示す図
- 環境構築手順書、リリース手順書、開発ルールやチェックリスト、運用/保守作業に関するドキュメント、分析手順書など ... and more!!!
-
テスト計画書:
アプリケーションのテスト方針や範囲を記述したドキュメント。 -
リリースノート:
各リリースの変更点や新機能をまとめたドキュメント。
システム設計書について
コードのxxxクラスにまとまっているからドキュメントはいらないよね？
アプリとサーバAPI開発者が一緒だからAPI仕様書いらないよね？
→絶対そんなことは無い 
↑こんなこと言っている人がいたら、ドキュメントを作らない理由付けのために言っているに過ぎないと思うよ
この辺りの仕様書が無いと100%属人化されていることになるし、新しい人が入った時にコードからがっつり仕様を確認する or リバースエンジニアリングしなきゃいけないことになる。
ハッキリ言って無駄。
また、APIやDBを修正する際にドキュメントがあったら、実際に手を動かす実装者だけでなくマネージャー側も設計に入れるし、レビュアーも確認しやすいでしょ？（もちろん修正されたコードもレビューすることになるが）
設計は実装者一人でするものでは無いので、API仕様書やテーブル定義書くらいは必要かと。
これらのドキュメントは、プロジェクトの進行に合わせて適宜更新し、チーム内での情報共有や意思決定の基盤として活用します。
技術的なドキュメントについて
作成するかどうかの観点は以下だと思う。
・属人化せず、チームメンバに共有されるべきドキュメントか？
・今後別の担当者が触った時に無いと困るドキュメントか？
まとめ
アジャイル開発では、過度に詳細なドキュメントよりも、必要最小限の情報を効果的に共有することが重要です。
また、ソースコードの可読性を高め、重要な決定事項のトレーサビリティを確保することで、ドキュメント作成の負担を軽減しつつ、プロジェクトの透明性を維持することができます。
以上