【楽々デブドックを書こう!】手法別開発ドキュメントの書き方
第4回:アジャイルにおけるドキュメント作成ポイント
著者:ウルシステムズ 深谷 勇次
公開日:2008/02/28(木)
アジャイルモデルはプログラマに高いスキルを要求する
アジャイルモデルにおけるプログラミングの大きな特徴は、ソースコードを継続的に改善する点にあります。アジャイルモデルが開発ドキュメントを極力作らないことを推奨しているのは、適切なソースコードは大量に書かれた設計書よりもわかりやすいという前提に基づいているからです。
適切なソースコードを実現するために、ペアプログラミングや頻繁なレビュー、リファクタリングといった手法が推奨されており、スキルの高いプログラマ(以下、チーフプログラマ)によってその効果が発揮されます。「プログラムをどのように作ればよいか」は、そのような活動を通じて各プログラマに周知徹底されていきます。チーフプログラマ以外のプログラマにも、ソースコードからさまざまな情報を読み取る能力と、チーフプログラマが発する言葉を理解できる能力が必要なため、アジャイルモデルはプログラマに高い能力を求める開発モデルであるといえます。
しかし、現実にはそのようなプログラマを集めることは難しく、チーフプログラマを1人確保するのがやっとです。小さな開発であればそれでもよいのですが、規模が大きくなるとチーフプログラマがペアプログラミングやレビューの面倒をすべて見るのは不可能でしょう。ここでは、そのような状況でもアジャイルモデルによる開発を実現する方法として「サンプルアプリケーション+使い方のメモ」を紹介します。
「サンプルアプリケーション+使い方のメモ」という開発ドキュメント
ウォーターフォールモデルでは、プログラミングがはじまる前に詳細設計書などを作成し、プログラムをどのように作ればよいかをプログラマに周知します。多数の人に情報を伝達する場合に、ドキュメントはもっとも有効な道具です。アジャイルモデルの誤解の1つに「ドキュメントを作らない」というものがあります。しかし、実際は情報の伝達が必要な場面において、もっとも有効かつ効率のよい手段がドキュメントなのであれば、その使用を制限するような記述はありません。少ないチーフプログラマで、多数のプログラマに情報を伝達しなければならない場合に、開発ドキュメントを利用するのは自然な流れといえるでしょう。
とはいえ、単純にアジャイルモデルでウォーターフォールモデルと同様の開発ドキュメントを作成してしまっては、アジャイルモデルの利点が失われてしまいます。ここでは、「サンプルアプリケーション+使い方のメモ」という開発ドキュメントをご紹介します。
チーフプログラマは顧客と議論を重ねている間に頭の中で具体的なソフトウェアをイメージしています。そのイメージは具体的な作り方を伴っており、それがプロジェクトで徹底されるべきプログラムの作り方です。チーフプログラマはイメージに基づき、実際に動くサンプルアプリケーションを作ります。チーフプログラマにとっては、重厚な開発ドキュメントを作るよりもサンプルアプリケーションを作る方が簡単です。また、プログラマに対しても実際に動作するソースコードの方が開発ドキュメントよりも情報は伝わります。
ただ、文書でしか伝えられない情報は必ず残りますし、使い方について複数のプログラマから似たような質問を受けることがよくあります。そのような情報は「メモ」程度であることがほとんどであり、重厚な開発ドキュメントに残すほどのものではありませんので、Wikiなどに記録するとよいでしょう。筆者はWikiを実際のプロジェクトで利用した経験がありますが、プログラマはWordやExcelの開発ドキュメントよりも上手に利用してくれました。
「サンプルアプリケーション+使い方のメモ」が開発ドキュメントである、という説明には抵抗感があるかもしれません。しかし、「情報を伝える」ことが目的なのは重厚な開発ドキュメントと何ら変わりがありません。アジャイルモデルにおいては、WordやExcelで作成したものだけでなく、サンプルアプリケーションやWikiのメモも、開発ドキュメントとしてよいのではないでしょうか。 次のページ