ソースがドキュメントだ。バグも完全に記述されている。

――まつもとゆきひろ（注1）

注1）

『オブジェクト指向スクリプト言語Ruby』（まつもとゆきひろ／石塚圭樹（著），アスキー）p.563

はじめに

本連載ではアジャイル開発を「アジャイルに開発する人たち（アジャイル開発者）が開発するからアジャイル開発」と考え，アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。

これまでの3回を費して紹介した「フィードバックを重視する」「仕組みを育てる」「スケール間に連続性を築く」といった習慣は，チームによるシステム開発の現場でアジャイルにプログラムを書くことを重視したものでした。

しかし，これでは開発対象となるシステムを構成する2つの要素のうち主に1つしか説明していません。2つの要素とは，プログラムとドキュメントです。今回は，これまであまり触れてこなかった，2つの要素のうちの1つであるドキュメントに関する習慣を紹介します。

そのためにまず，アジャイル開発者にとってのドキュメントの位置づけを説明します。それから，アジャイル開発に限らないドキュメントについての考え方を紹介します。そして，ドキュメントを大切にするためにアジャイル開発者が身につけている習慣を紹介します。

“アジャイルだからドキュメントを書かない”

アジャイル開発にまつわる代表的な誤解が「アジャイルだからドキュメントを書かない」というものです（注2）。

この誤解は根強いものですが，その原因はアジャイル開発を推進している側にもあります。具体的には，最初によく知られることになったアジャイル開発手法の名前が「エクストリームプログラミング（極端プログラミング）」であることや，「アジャイルソフトウェア開発宣言」と訳されることもあるアジャイルマニフェストに「包括的なドキュメントよりも，動作するソフトウェアを」という項目があることがすぐに思い当たります。

しかし，それ以上に誤解を根強くしている原因は，開発対象のシステムとその構成要素（プログラムとドキュメント）の認識にあります。

注2）

アジャイル開発に関してよく誤解されているものはほかにも何点かあります。そのうちの代表的な誤解を「アジャイル勘違い集」で簡単にまとめています。

システムとドキュメント

経験からも言えることですが，開発対象システムのとらえ方としてよく見られるのは「システムとはプログラムであり，ドキュメントはシステムとは別物である」という認識です（図1）。心の持ち方として，開発を進めるうえでドキュメント作成とシステム構築とを完全に別物として考えていることはありませんか？ システム（プログラム）をこの構図でとらえている人が「動作するソフトウェアを重視する」と聞くと，「じゃあドキュメントを軽視するんだな」と考えてしまいがちです。私もかつてはそうでした。

ドキュメントはシステムの本質的な構成要素

ところが実際にはアジャイル開発者はドキュメントを大切にします。これは私が周囲のアジャイル開発者との交流から学んだことの中でも二番目に重要なことです（注3）。

アジャイル関連の著作が多いScott Amblerも，『オブジェクト開発の神髄』（注4）の中で「どんなシステムにもドキュメントは本質的な部分として含まれます。アジャイルソフトウェア開発手法で作られたシステムでも同じです」と宣言しています。つまり，アジャイル開発者のシステムとその構成要素に対する認識は図2のようになっているのです。

注3）

一番重要なことは「テスト駆動開発者は本当にテストを先に書くこと」です。

注4）

『オブジェクト開発の神髄 ― UML 2.0を使ったアジャイルモデル駆動開発のすべて』（Scott W.Ambler（著），越智 典子（訳），オージス総研（監訳），日経BP出版センター）

ドキュメントとコードは同じぐらい大切

ちなみに図2では「ドキュメント」の四角が「プログラム」の四角に重なっていますが，これは作図ミスではありません。アジャイル開発者にとってドキュメントにはプログラムも含まれます。これについては後述します。

アジャイル開発者にとってドキュメントはシステムの本質的な一部ですから，プログラムとして書くコードと同じように大切なものです。ということは，アジャイル開発者にとってドキュメントはコードと同じようにビジネス価値を提供しなければなりません。

ソフトウェアに対する要求を動作するソフトウェアとして早めに実現し，こまめに提供し続けることがアジャイル開発の核心です。連載の第1回（本誌Vol.39）で説明したように，ソフトウェアの価値は「価値の大きさ×価値を生み続けている時間」です。よって，システムのビジネス価値の提供に結びつかないドキュメントはムダであり，削減の対象となります。