アジャイル開発ではドキュメントを書かない！？について考える

みなさんこんにちは、ソリューション技術部の中島です。

今回はアジャイル開発におけるドキュメントのあり方について考えてみたいと思います。

はじめに

最近、弊社のシステム開発現場でも「アジャイル」という言葉に触れる機会が多くなってきました。
私自身もその考え方を学び、実践していく中で、最近周りからよく聞き、気になっている言葉があります。
それは、

• アジャイル開発ではドキュメントがない（ドキュメントを書かない）

というもの。

• ドキュメントがないから作った人にしか仕様・意図がわからない
• ドキュメントがないから何が正しいのかわからない
• ドキュメントがないからキャッチアップが大変

などなど、頻繁に耳に入ってきます。

今回この記事で、その誤解を解くとともに、ドキュメントに対する新しい向き合い方を提案し、 システム開発の現場をよりよくするために少しでもお役に立てればと思います。

なぜ「アジャイル開発ではドキュメントを書かない」のか

動くソフトウェアに価値がある？

なぜこのような誤解が生まれるのか、まず最初に思いつくのは、アジャイルソフトウェア開発宣言にある

• 包括的なドキュメントよりも、動くソフトウェアを（価値とする）
  • 原文：Working software over comprehensive documentation

という部分でしょう。
ドキュメントなんていらない、動くソフトウェアがあればいい、という極論（と敢えて言います）はこれを誤って理解することにより発生する部分もあるでしょう。

しかし、この宣言で重要なのは、一方が無価値で、もう一方に偏重するということではなく、

どちらも大事だけど、こちらの方がより大事

という価値観の話だということを前提とする必要があります。

ドキュメントは無駄？

ドキュメントを作るなんて時間の無駄という論調もあります。

Agileの意味を調べると、

1. able to move quickly and easily
2. quick, smart, and clever

と出てきます。（Merriam-Websterより）

日本語にすると、機敏な、素早い、などの言葉に置き換えられますが、素早く開発するために無駄なものは作れない、ドキュメントは無駄だから作らない、ということだと思います。

ここで、果たしてドキュメントは無駄なのか？というところを考える必要があると思います。

今まで役に立たない設計書をたくさん見てきた、という人もいるでしょう。成果物として求められているから無駄だと思いつつ書いた、という人もいるかもしれません。
そのような過去の自身の経験から、

• ドキュメント = 無駄

という図式が出来上がっていることも推測できます。

また、ドキュメントを書くとなると、

• WordなりExcelなり、それ用のツールを使ってきっちり書かなければいけない

とか

• 書き方の標準が細かく決められていて、それに沿って書かなければいけない

とか、めんどくさいと思うこともあるかもしれません。

これも「成果物としての」ドキュメント作成を求められていることに起因しているのかなと思っています。

設計はチームの仕事？

アジャイル開発において、チームは言われたものを作るだけの存在であってはなりません。
設計・実装・テスト・運用・データ分析など、プロダクトバックログを動くソフトウェアに落とし込む作業はすべてチームの責任において行われます。

• 作る人が仕様も考えるんだから、わざわざドキュメントにしなくても大丈夫でしょ（作れるでしょ）

という趣旨の意見も見かけることがありますが、これは果たしてそうなのでしょうか？

システムのライフサイクルを考えると、構築してから全く変更がなく、ずっと同じメンバーが運用するようなシステムというのは現実的でしょうか。
システムの使い方はその時々の状況によって変化していきます。
開発メンバーも状況によって入れ替わることがあるでしょう。

その際に、重要な情報が誰かの頭の中にしかない、という状況はプロジェクトを円滑に進める上でとても危険な状況なのではないでしょうか。

なんのためにドキュメントを書くのか

これらの根底にあるのは、ドキュメントを書く目的、書いてもらう目的を誤っていることから発生しているのではないでしょうか。

私が定義する目的は

• 意図・考え・想いを相手に伝えること
  

です。

ドキュメントはコミュニケーションの手段のひとつです。
伝えたいことがあるからそれを形にするのであって、伝えたいことがないのであればわざわざ書く必要はありません。

相手に伝わりさえすれば、どんな書き方でもいいし、どんなツールを使ってもいいと思っています。

誰も読まないドキュメントは確かに無駄です。

誰に、何を伝えたいのか、ドキュメントについて考えることはただそれだけです。

アジャイル開発におけるドキュメントの意味

ドキュメントの必要性

ではアジャイル開発において、ドキュメントとどのように向き合えばいいでしょうか？

アジャイル開発では、対話や協調を重視します。 それはすなわち、個の限界と、チームの可能性を重視しているのだと思っています。
全員が同じ目的に向かって自分で考え、お互いに意見をぶつけることで、より高い次元に到達できるのだと信じています。

情報をチームの財産として残すためには、ドキュメンテーションは重要な要素だと考えています。

それはきっちりと体裁を整えたドキュメントである必要はありません。
あとで見直したときに、当時の考え方や意見、決定の背景にある事情などが確認できれば、例えばメモ書きでも構わないと思ってます。

もし、お客様やユーザー、アジャイルチームのメンバー、ステークホルダーなど、開発したシステムに関わる人の誰かが「ドキュメントがない（足りない）」という思いを持っているのであれば、それはドキュメンテーションが足りていないということでしょう。

そのような意見が出てきているのであれば、情報共有などの共通理解を促進する仕組みを変えていかなければなりません。

コミュニケーションツールとして、ドキュメントを作ることも「選択肢のひとつ」として考える必要があるでしょう。

伝えるということ

ドキュメントの読者を意識しましょう。

• そのドキュメントは誰に向けて書くのでしょうか？
• その人はどんな媒体を使えば読みやすいでしょうか？
• その人はどんな言葉を使えば理解できそうでしょうか？
• その人にあなたは何を伝えたいのでしょうか？
• どのようにしたらよりうまく伝えられそうでしょうか？

これらを考えた上で、ドキュメントを書きましょう。

変化に対応する

また、ドキュメントが無価値になる理由のひとつに、仕様変更に伴うメンテナンスがなされていない、というものがあります。

システムは生き物です。システムは成長します。
システムの成長に合わせてドキュメントも成長させる必要があります。

メンテナンスのしやすさ、という観点からもドキュメントを考える必要があります。
例えば以下のようなポイントで考えてみましょう。

• 誰でも使えるツールか
• 履歴は簡単に残せるか
• 修正箇所がすぐに見つかるような構成か

とにかく情報を残す という意識を持つ

アジャイル開発の現場では、フェイストゥフェイスで話すことでいろいろ決めることも多いでしょう。

話した後はメモを関係者が誰でもアクセスできる場所に共有しましょう。

ホワイトボードや紙に書いたものは写真に撮って共有します。

口頭で済ませたものは要点を書いて残しましょう。
頭の中にしか残っていない情報と、目に見える形で残した情報、コミュニケーションでより役立つのはどちらでしょうか？

誰かに何かを伝えるための目に見える情報、と考えると、これもドキュメントですよね？

自分の取り組み

現在、私はシステム開発のいわゆる上流工程と言われる部分を担当しています。

私が業務で作成するドキュメントは、仕様に関する情報とスケジュールに関する情報がメインです。

どのようなドキュメントを使ってコミュニケーションを行なっているか、ご紹介します。

GitHubのIssue機能

タスクの詳細情報管理

我々のチームでは、チケット駆動開発を行っています。
プロダクトバックログに相当するものはGitHubのIssueです。
ここにはタスク単位で「目的」「概要」「対応内容詳細」が書き込まれます。

誰が起票してもいいし、誰が編集しても構いません。

ただし、起票・編集したことはSlackで周知します。

スケジュール管理

機能ごとに、いつまでに欲しい、という要求スケジュールがあります。（優先度の低いものにはないですが）

Issueに対しては優先順位付けが必要ですが、GitHubのIssue機能では管理しづらい項目のため、Project機能（カンバン）を併用しています。

ToDoカラム内にIssueを配置する際に、上から優先順となるように並べています。

また、Issueに「リリースタイミング」を示すLabelを貼ることで、いつリリースする予定のタスクなのかが分かるようにしています。

詳細仕様書

チケットに書ききれない複雑なロジックや、画面イメージなどについて説明が必要な場合は、Excelで仕様書を作成します。

このときに、資料を作成するか否かの判断基準は、開発メンバーに伝えたいことが文字情報だけで理解してもらえそうかということです。

自分の頭の中を整理するときに絵や図を描いて俯瞰する必要があるようなものは、文字情報だけで理解してもらうこと（理解できる文章にまとめること）は困難です。
そのようなときには、イメージを形にするために仕様書を作成します。

Wiki

開発ルールや何かを行う際の手順、作業を進めるうえでのTipsなどについては、Wikiに書き留めていくようにしています。
私よりも開発メンバーの方が更新している場所ではありますが、情報を集約するうえではとても便利です。

おわりに

以上、私が考える「アジャイル開発におけるドキュメンテーション」について記載しました。

色々と書き連ねましたが、重要なことは「アジャイル開発だから」という理由でドキュメントを書かないということは思考停止に他ならないということです。

アジャイルだろうがウォーターフォールだろうが関係ありません。

• 何のために開発しているのか
• よりよい開発を行うためにはどうしたら良いのか

これらを考え、プロダクトを、開発現場を、コミュニケーションをより良くしようとすれば、必然的にドキュメントは必要になるはずです。

ドキュメントが必要だと思うのであれば、ドキュメントを残すように行動を変えていく必要があるのだと思います。

アジャイル開発は、「アジャイルな開発」であって、「アジャイル」という何か決まったやり方をするわけではありません。
開発方法をより良くする手段・対応策は、自分たちで考え、実験し、検証し、改善して、実践を重ねていかなければならないのです。

「アジャイル開発だから」という理由でドキュメントを書かないことを受け入れるのではなく、本当にドキュメントが必要ないのかを考え、ドキュメントが必要だと結論付けられたのであれば、まずは自分から始めてみましょう。