「アジャイルだから設計書は不要？」その誤解が招く保守不能と最低限必要なドキュメント
「『アジャイルだから設計書は不要』って若手に言われたけど、本当に大丈夫？」
「ドキュメントを全く残さないと、将来の引き継ぎや保守で炎上しそうで不安…」
現場で若手エンジニアからそう言われ、一抹の不安を覚えたことはありませんか？
「顧客と揉めないだろうか」「担当者が異動や退職をしたら、誰が引き継ぐんだ？」 その不安は、残念ながら的中します。過去の事例を見ても、ドキュメントを一切残さずに進めたプロジェクトは、開発者本人が去った後、誰も手が出せない巨大なブラックボックス（内部が分からない状態）と化してしまいます。
「包括的なドキュメントよりも動くソフトウェアを」というアジャイルソフトウェア開発宣言の言葉は、「ドキュメントをゼロにしていい」という意味ではありません。
本記事を読めば、「何を残すべきか」と「どう運用すれば形骸化しないか」が具体的に分かります。
アジャイル開発で「設計書不要」は誤解｜ドキュメント軽視の危険性
なお、スクラム開発においても透明性と共有理解は重要であり、ドキュメントや情報の可視化は不可欠です。
なぜ「設計書を書かない」若手が生まれるのか？
現場で「ドキュメントは不要」と主張するメンバーが現れる背景には、以下の3つの要因が絡んでいます。
- アジャイルの誤解（価値観の切り取り）
「動くソフトウェアを最優先する」という言葉だけが独り歩きし、都合よく解釈されている状態です。本来は「無駄なドキュメントを作らない」だけであり、必要なものまで捨てるわけではありません。 - ドキュメントが評価されない文化
コードを書くこと（＝機能が動くこと）が絶対の正義とされ、設計書を書いても「進捗」として見なされにくい現場の評価軸に問題があるケースです。 - スピード至上主義
目の前のリリース速度を優先するあまり、将来の保守や引き継ぎのための時間を削ってしまっています。
ドキュメントなしで開発を進めたシステムの末路
ドキュメントを残さず、口頭のやり取りとソースコードだけで進めたシステムは、初期リリースこそ早いかもしれません。しかし、数年後に開発担当者が異動・退職した瞬間、「誰にも触れないシステム（ブラックボックス）」が完成します。 少しの仕様変更でどこに影響が出るか分からず、障害発生時の復旧にも膨大な時間がかかるため、結果的に顧客からの信用を大きく失うことになります。実際には「1つの修正に数日かかる」「怖くて誰も触れない」といった状態に陥るケースも珍しくありません。
アジャイルでも絶対に省略してはいけない3つのドキュメント
ウォーターフォールのように何百ページもの詳細設計書は不要ですが、アジャイルでも以下の3つは「最低限の成果物」として残すべきです。
1. プロダクトバックログ（要求事項と受け入れ条件）
「システムが何を実現すべきか」をまとめたリストです。ここには、ユーザーストーリーだけでなく、「どうなっていれば完了（テスト合格）とするか」という受け入れ条件を必ず明記します。これが顧客との「言った・言わない」を防ぐ強力な防波堤になります。
2. システムアーキテクチャ図・ER図（全体像の把握）
コードをいくら読んでも、システム全体の構造やデータの流れは直感的に把握できません。また、「なぜその構成を採用したのか」という設計意図は、コードだけでは把握できません。
- システムアーキテクチャ図： サーバー構成、外部システムとの連携状況
- ER図（エンティティ・リレーションシップ図）： データベースのテーブル構造と関係性
新しくチームに入ったメンバーが、全体像を最速で理解するための「地図」として必須です。
3. 環境構築手順と運用マニュアル（属人化の排除）
「特定の担当者のPCでしかビルドできない」「本番反映の手順が担当者の頭の中にしかない」という事態を防ぎます。READMEファイルなどで構わないので、誰が読んでもローカル環境を立ち上げられ、安全にデプロイできる手順を残します。
注意：プロジェクト特性に応じた補足ドキュメントも必要
上記の3つだけであらゆるプロジェクトが回るわけではありません。扱うシステムの特性によっては、セキュリティ要件、非機能要件（性能・可用性）、外部公開向けのAPI仕様書など、適宜ドキュメントを追加して合意形成を図る必要があります。
スピードを落とさない！現場で回るドキュメント運用術
WordやExcelから脱却し、Wikiで一元管理する
アジャイルのスピード感を維持するためには、ファイルサーバーの奥深くに眠るWordやExcelは不向きです。 ConfluenceやNotion、BacklogのWiki機能などを活用し、「いつでも誰でも検索して編集できる」状態を作ります。変更履歴が自動で残る点も、アジャイルと相性が良い理由です。
コードは「How」しか語らない。「Why（背景）」と「制約」を残す工夫
「ソースコードがドキュメントだ」という主張の最大の弱点は、「なぜその実装にしたのか（Why）」と「どんな制約があったのか」がコードからは読み取れない点です。
情報は「コードに残るもの」と「ドキュメントでしか残らないもの」に分かれます。
| 記録する媒体 | 残る情報（役割） | 具体例 |
|---|---|---|
| ソースコード | What / How（何を作ったか、どう実装したか） | 変数名、ロジック、クラス構造 |
| ドキュメント | Why / 制約（なぜそうしたか、背景の意思決定） | 「A案ではなくB案を採用した理由」「APIの制限によりこの処理順にした」 |
後任者が過去のコードを修正する際、この「Why」が残っていないと、デグレード（機能劣化）を引き起こす原因になります。
「完了の定義（DoD）」にドキュメント更新を組み込む
ドキュメントが後回しになるのを防ぐ最善の策は、スプリントの「完了の定義（Definition of Done）」にドキュメントの更新を含めることです。 「コードを書いてテストを通す」だけでなく、「Wikiの仕様を最新化し、アーキテクチャ図を修正する」まで終わって初めて、そのタスクは「完了」であるとチーム内でルール化します。
まとめ：目的は「動くソフトウェア」、ドキュメントはそのための「手段」
アジャイルにおけるドキュメント管理の最適解は、「ゼロにする」ことでも「ウォーターフォールのように全て書く」ことでもありません。
目的はあくまで「価値あるソフトウェアを持続的に提供し続けること」です。ドキュメントは、その目的を阻害する属人化や認識ズレを防ぐための「強力な手段」に過ぎません。
現場のスピードを殺さず、かつ将来の保守性も担保する。このバランス感覚こそが、これからのPMやリーダーに求められるスキルと言えるでしょう。
まずは「プロダクトバックログに受け入れ条件を書く」ことから始めてみてください。
