アジャイルの文書化ルール

アジャイルの文書化について考えてみよう。

はじめに、アジャイルの文書化について明文化されたルールはない。

では、「アジャイルソフトウェア開発宣言」から見てみよう（以下抜粋）。

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

「包括的なドキュメントよりも動くソフトウェアを」が、文書化に関連するが、ここではガッツリ文書化するよりも、動くコード（プロダクト）を重要視するとだけ説いている。

次に、「アジャイル宣言の背後にある原則」について（以下抜粋）。

私たちは以下の原則に従う:

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

12の原則の中でも、文書化について具体的に明文化している原則はない。

明文化されたルールはないので、私たちが自律して判断すればいい。

多くのアジャイリストの間で共通なのは、「必要最小限の文書化」であろう。1番重要なのは、「動作するプロダクト」である。

「必要最小限の文書」は、製品、サービス、そして組織によって異なる。そして、同じ製品・サービスでも、対象とする顧客セグメントによっても異なるだろう。

だから、標準的に定義することは難しい。プロダクト毎に、プロダクトオーナーが中心になって、サービス利用者のニーズをヒアリングして、文書化ニーズを特定するしかない。

1番いいのは、「顧客に選んでもらう」ことだ。

理由はこうだ。

機能であれ、文書であれ、作るのは開発チームである。
開発チームのキャパシティーは決まっているから、機能を多くすれば、その分、文書化は減る。文書化を増やせば、その分、実装できる機能は減る。

機能を追加するか、文書化するか「顧客に選んでもらう」。

いくつか例を出そう。

ある店で、生ビールを500円で売っているとしよう。
あと、300円払うとビッグサイズにできる。
または、同じ料金で、サイズは同じだが、味気ないコップではなく、冷えた味のある器で提供してくれる。

あなたは、どちらを選ぶだろうか？

お祝いに現金を包む場合はどうだろう。
結婚祝いを茶封筒に入れて出す人はいないだろう。ちゃんと祝儀袋に入れて贈る。

同様に、なにかのお祝いに、商品を剥き出し渡すのと、綺麗にラッピングして渡すのでは、もらう方の感激度は違うだろう。商品は同じでも、印象は相当違う。

機能と違って、文書は常時使われるものではない。
だが、コンテキストによって文書化が必要となる状況がある。

ユーザーストーリーを通して、機能を使うシーンを捉えよう。そして、文書化が必要かどうか聞いてみよう。文書化が必要なら、それを受入基準に含めて実装する。

聞く際、重要なポイントは、「機能と比較する」ことだ。
単独で、文書が必要か尋ねると、大抵「必要」と言われる。
だから、機能追加するか、文書化するか、好きな方を選んでもらうのだ。

もう一度まとめよう。

アジャイルの文書化ルールは「必要最小限」である。
「必要最小限」は、製品・サービスにより異なるから、プロダクト毎に定義する。
作るのは開発チームだ。
だから、機能追加を横に置いてでも、優先して文書化する必要があるか、プロダクトオーナー（顧客）に総合的に判断してもらう。
文書化が必要なら、プロダクトインクリメントの一部として実装計画に含めて作り込む。

文書化はギフトラッピングみたいなものだ。サービス利用者が欲しいなら、必要である。