【アジャイルソフトウェア開発宣言】「包括的なドキュメントよりも動くソフトウェアを」編

Anycloud PdMの青木です。

前回、アジャイルソフトウェア開発宣言における「プロセスやツールよりも個人と対話を」について考えました。

今回は、アジャイルマニフェストにおける「包括的なドキュメントよりも動くソフトウェアを」について、自分の失敗談も踏まえてまとめてみました。

実際に動かしながら、仮説検証を繰り返す

最終的な目標は、ユーザーにソフトウェアを提供すること。

ドキュメントで議論するよりも、動くソフトウェアを早期に提供して、フィードバックを活用して改善を繰り返し、プロダクトを進化させること。

ドキュメントは手段の一つに過ぎない

「ドキュメントが重要でない」ではなく、「ドキュメントを作成すること自体が目的にならず、動作するソフトウェアを届けることを最優先すべき」という価値観。

実際に動くソフトウェアを早く届けるために、プロジェクトによって必要なドキュメントは変わってくる。「誰のため、何のため（目的）に、ドキュメントを作成するのか」を意識して、必要最低限のものに留めること。

アンチパターン

必要なドキュメントすら作成しない

• チーム間の共通理解がないまま開発を進め、要件や仕様が曖昧なままになってしまう。不明瞭な指示や認識のズレにより、後から大幅な修正が必要になる。
• ドキュメントを一切作成せず、要件や設計を口頭で説明し続ける。記録がないため、メンバーが変わると知識が失われたり、後から確認ができなくなる。
• 動くソフトウェアを優先するあまり、品質を無視する。テストを省略して急いでリリースした結果、信頼性の低いソフトウェアを提供してしまい、ユーザー体験が損なわれる。

↓改善案

• ユーザーストーリーを使って、要件を箇条書きする
• ロジックツリーを使って、コアな機能のテストシナリオを整理する
  • Amazon.co.jp[改訂新版]マインドマップから始めるソフトウェアテスト​

不要なドキュメントを作成に時間をかけ、その後管理（更新）しない

• 詳細な設計書を作成して議論に多くの時間を費やし、動くソフトウェアが完成しない。、計画と現実が乖離する。
• 初期段階でドキュメントを作成したが、開発中に更新されず、現状と乖離する。ドキュメントが古くなり、チーム内で混乱を引き起こす。

↓改善案

• ソフトウェア考古学できるように、議論したログ（背景、Why）を残す
• ソースコードから自動生成させる（例: Swagger）
• スプリントのたびにバックログを見直し、新しいフィードバックを元に優先順位を調整する（例：スプリント計画）

ドキュメントを通じて、進捗を確認する

• タスク管理シートのみで、ステークホルダーに進捗報告する。ただ実際のソフトウェアは認識齟齬や漏れ（バグ）があり、ドキュメントにおける進捗と乖離してしまう。

↓改善案

• スプリントごとに完成した機能をデモし、実際に動くソフトウェアで進捗確認する。（例：スプリントレビュー）

まとめ

無意識にドキュメントに対して必要以上にこだわったり、依存したりしてしまって、本来の目的を見失いがちです。過剰に詳細な設計書を作成してしまったり、進捗共有をタスク管理シートのみで行なってしまったりと…。

動くソフトウェアが最も価値のある情報源として、最優先していきましょう。