# 【アジャイルソフトウェア開発宣言】「包括的なドキュメントよりも動くソフトウェアを」編 > アジャイルソフトウェア開発における「包括的なドキュメントよりも動くソフトウェアを」という価値観を探求し、実践的なアプローチやアンチパターン、改善策についてまとめた記事です。 - 公開日: 2025-02-27 - 著者: 青木 陸 - タグ: プロジェクトマネジメント, アジャイル開発 - URL: https://tech.anycloud.co.jp/articles/agile-manifesto-2 --- Anycloud PdMの青木です。 前回、アジャイルソフトウェア開発宣言における「プロセスやツールよりも個人と対話を」について考えました。
【アジャイルソフトウェア開発宣言】「プロセスやツールよりも個人と対話を」編アジャイル開発における「プロセスやツールよりも個人と対話を」という価値について考察し、アジャイルソフトウェア開発宣言の背景やその意義を探る内容。tech.anycloud.co.jp
今回は、[アジャイルマニフェスト](https://agilemanifesto.org/iso/ja/manifesto.html)における「包括的なドキュメントよりも動くソフトウェアを」について、自分の失敗談も踏まえてまとめてみました。 ## 実際に動かしながら、仮説検証を繰り返す 最終的な目標は、ユーザーにソフトウェアを提供すること。 ドキュメントで議論するよりも、動くソフトウェアを早期に提供して、フィードバックを活用して改善を繰り返し、プロダクトを進化させること。 ## ドキュメントは手段の一つに過ぎない 「ドキュメントが重要でない」ではなく、「ドキュメントを作成すること自体が目的にならず、動作するソフトウェアを届けることを最優先すべき」という価値観。 実際に動くソフトウェアを早く届けるために、プロジェクトによって必要なドキュメントは変わってくる。「誰のため、何のため（目的）に、ドキュメントを作成するのか」を意識して、必要最低限のものに留めること。 ## **アンチパターン** ### **必要なドキュメントすら作成しない** - チーム間の共通理解がないまま開発を進め、要件や仕様が曖昧なままになってしまう。不明瞭な指示や認識のズレにより、後から大幅な修正が必要になる。 - ドキュメントを一切作成せず、要件や設計を口頭で説明し続ける。記録がないため、メンバーが変わると知識が失われたり、後から確認ができなくなる。 - 動くソフトウェアを優先するあまり、品質を無視する。テストを省略して急いでリリースした結果、信頼性の低いソフトウェアを提供してしまい、ユーザー体験が損なわれる。 **↓改善案** - ユーザーストーリーを使って、要件を箇条書きする - ロジックツリーを使って、コアな機能のテストシナリオを整理する - [Amazon.co.jp](http://Amazon.co.jp)[**\[改訂新版\]マインドマップから始めるソフトウェアテスト**](https://www.amazon.co.jp/o/ASIN/4297105063)​ ### **不要なドキュメントを作成に時間をかけ、その後管理（更新）しない** - 詳細な設計書を作成して議論に多くの時間を費やし、動くソフトウェアが完成しない。、計画と現実が乖離する。 - 初期段階でドキュメントを作成したが、開発中に更新されず、現状と乖離する。ドキュメントが古くなり、チーム内で混乱を引き起こす。 **↓改善案** - ソフトウェア考古学できるように、議論したログ（背景、Why）を残す - ソースコードから自動生成させる（例: Swagger） - スプリントのたびにバックログを見直し、新しいフィードバックを元に優先順位を調整する（例：スプリント計画） ### **ドキュメントを通じて、進捗を確認する** - タスク管理シートのみで、ステークホルダーに進捗報告する。ただ実際のソフトウェアは認識齟齬や漏れ（バグ）があり、ドキュメントにおける進捗と乖離してしまう。 **↓改善案** - スプリントごとに完成した機能をデモし、実際に動くソフトウェアで進捗確認する。（例：スプリントレビュー） ## まとめ 無意識にドキュメントに対して必要以上にこだわったり、依存したりしてしまって、本来の目的を見失いがちです。過剰に詳細な設計書を作成してしまったり、進捗共有をタスク管理シートのみで行なってしまったりと…。 **動くソフトウェアが最も価値のある情報源**として、最優先していきましょう。