アジャイル開発におけるドキュメンテーションの実際(2) ―― ドキュメントの「必要最低限」の見つけ方

本連載では，アジャイル開発とウォータ・フォール開発の両方を経験している筆者が，アジャイル開発におけるドキュメントの位置づけや作成方法について解説する．今回は，開発において作成するべき「必要最低限のドキュメント」について考える．（編集部）

技術解説・連載「アジャイル開発におけるドキュメンテーションの実際」 バック・ナンバ
第1回　本当に必要ですか？ そのドキュメント

　前回は，アジャイル開発におけるドキュメンテーションの考え方として以下の点を説明しました．

• アジャイル開発では必要最低限のドキュメントを作成する．
• 必要最低限を決めるために，それぞれのドキュメントについて「いつ」，「誰が」，「何のために」利用するのかをよく考える．
• Face To Faceがもっとも強力なコミュニケーション手段であり，ドキュメントはそれを支援する目的で用いられることが多い．

　そうは言っても，「何が必要最低限なのか分からない」，「ドキュメントがないと何が正しいのかが分からないから，きちんと開発できない」という声が聞こえてきそうです．今回は，「必要最低限のドキュメント」とはどういうものなのかをもう少し深掘りします．

　いったい，どの程度のドキュメントを書けば必要最低限なのでしょうか？ 結論を言うと，絶対的な答えはありません．何が必要最低限なのかは，皆さんが携わるプロジェクトごとに決める必要があります．ここでは，何が必要最低限なのかを検討するための考え方を説明します．

●開発チームが獲得する情報と生み出す情報を考える

　まず必要なことは，開発チームがどのような情報を獲得したり，生み出すのかについて考えることです．開発チームにかかわる情報から機能実装にかかわる情報まで，代表的な例をいくつか挙げてみます．

A．機能の目的
B．機能の振る舞い
C．画面イメージ
D．必要な性能
E．ソフトウェアの構造
F．ソフトウェアの内部処理

　これらの情報一つ一つについて，以下のような問いかけをしてみましょう．

• その情報を使うのは人がチームの外の人？ 中の人？ あるいはその両方？
• その情報を受け取ったそれぞれの人が，いつ，何のために使うのか？

　上に挙げた情報を，この基準に基づいて表1のように分類してみました．同じ情報でも皆さんのプロジェクトの事情によって分類は異なります．プロジェクト特有のステーク・ホルダや，情報を利用する目的が存在すると思います．このように，同じ情報が同じ人にとって複数の目的のために使われたり，異なる人によって使われることが分かります．表1を見ながら，それぞれの情報に対して，いつどのような内容を形式化するべきなのかを考えます．

表1　機能実装にかかわる情報を「誰が」と「何のために」で分類する

（1）「チーム内で」×「実装のため」の情報

　まず，チーム内で実装（設計，実装，テスト）のために必要な情報について考えてみましょう．ウォータ・フォール・プロセスのように一つ一つのフェーズにかける時間を長く取る場合は，「どんなものを作ればよいか」，「どうやって作ればよいか」についてチームの全員が共有して覚えておくことが難しいため，その手段として形式化（ドキュメント化）を利用します．逆に，要求分析から設計，実装，テストを小さい単位で短時間で行う場合は，ドキュメント化するよりも，Face To Faceのコミュニケーションを中心に理解を共有し，忘れないうちに動くソフトウェアとして具現化するほうが効率が良くなります．ドキュメント化しなくてもソフトウェアを作れるのであれば，少なくとも「チーム内で設計，実装，テストを行うための情報」については，形式化を行う必要がないと判断できます．

（2）「保守のため」の情報

　次に保守のための情報について考えます．保守のための情報を必要とするのは未来の担当者なので，もしかすると「チーム外で」と分類した方が適切かもしれません．どちらにせよ，今，必要な情報ではなく，保守を行うときになって必要になる情報だといえます．また，保守を行う時点での最新の情報が記載されていることが必須です．

　XPの提唱者であるKent Beckは『XP入門』^（1）の中でこの保守用の情報を作る行為を「ロゼッタ・ストーンを作成する」と表現しています．時を超えて再び開発が動き出したときに，チームが以前と同じように開発するために必要な情報を，プロジェクトの停止直前に整備するのです．

（3）「合意形成のため」の情報

　最後に「合意形成のため（あるいは，合意内容を共有するため）の情報」について考えましょう．合意内容を共有する目的の一つは，間違ったものを作ってしまうことによる手戻りの回避です．要求の合意から動作するソフトウェアによる確認までの時間が長い場合は，間違ったときの手戻りが大きくなるため，ドキュメントにより形式化することが重要になります．一方，アジャイル開発では，要求を共有したら動くソフトウェアによって動作を確認してもらい，フィードバックを受けるという一連の流れにより，「何を作ればよいか」について信頼性の高い合意形成を行っています．ある意味，動作するソフトウェアを作ることそのものが情報の形式化だといえます．

　合意形成にはこのほか，契約，長期契約，投資価値判断などさまざまな目的があります．その目的によって，開発チームとの関係も異なります．その合意を形成することが開発にとって必須であり，そのために必要なドキュメントなのであれば，ためらわず作成した方がよいでしょう．