アジャイル文書化の３つのポイント

アジャイルにおける文書化ルールはこの３つだ。

①　文書化以外に方法がないか問う
②　「作るため」の文書化はしない。「使うため」に文書化する
③　継続的に文書化する

順番に説明しよう。

①　文書化以外に方法がないか問う

書くのは時間がかかる。
話せば数秒のことでも、メールにすると数分かかる。パワーポイントに纏めると1時間はかかる。

アジャイルの基本は対話である。話せばいい。地理的に分散していてもスカイプや電話もある。現代において、文書化しないといけないものはどんどん減っている。
今までしてきたからという理由で文書化するのはやめよう。

②　「作るため」の文書化はしない。「使うため」に文書化する

アジャイルでは会話しながら、アイデアをカタチにしていく。作り方をモデリングしたり、タスクに切り出したりはするが、公式な仕様書を作成してサインオフしたりしない。なぜなら、話す度に仕様がどんどん進化していくから。
文書は書いた瞬間から劣化していく。作り始める前にもう古い情報なのだ。だから、アジャイルでは作ってから、運用保守の為に設計書を書く。開発から運用にオーナーシップが移る時に、受け手が困らないように文書化する。

③　継続的に文書化する
プロダクトインクリメントは進化していく。だから、最初からガッツリ書いても無駄になる。概要から初めて、確度の高いものから書いていく。詳細はプロダクトが安定してから、ジャストインタイムで書くのがいい。
スプリントやリリース終盤にまとめて文書化すと、タイムボックスに収まらないリスクが高くなる。
それに、インクリメンタルに作る方が品質は高くなる。
プロジェクト終盤まで、溜めてからテストすると不具合が多くなるのと同じだ。インクリメンタルに徐々に洗練していくのがいい。
パワーポイントの資料でも、作ってすぐ提出せず、一日寝かせて、翌日レビューしてから提出するとクオリティーが上がるのと同じだ。

基本ルールは3つだが、注意点も3つのある。
①　プロダクトの開発も保守も同じチームが行う場合
オーナーシップが変わる前提で、運用保守チームが困らないよう文書化する。もし同じチームが引き続き保守対応するなら、文書化は最小限でいいだろう。多くのナレッジと経験が既にチームにある。
仮に、保守から関わるメンバーがいても、ソースコードを見てわかるものは文書化しない。コードでのコミュニケーションを心がけよう。

ちなみに、プロダクトの立上げからメンテナンスまで一気通貫で同じチームが関わっていくのはとてもよいことだ。開発チームは、運用・保守フェーズも含めて、プロダクト・ライフサイクル全体視点でソリューションを作るから、手入れしやすい安定したプロダクトを創造できる。

②　なぜ継続的にするかというと、人は忘れっぽいからだ。当初の設計根拠を忘れてしまう。プロダクトができてから文書化しようとすると、なぜそのような設計にしたのか忘れてしまうのだ。だから、設計の根拠は決めた時に記しておく。詳細設計の文書化はプロダクトが安定してからでいい。

③　取扱説明書はプロダクト利用者に安心感を与える
運用保守を開発と同じチームが受け持つとしても、利用者には説明書が必要だ。本のような分厚いマニュアルはいらないが、見開き1～2枚程度のスターターキットはあった方が安心だ。
たとえプロダクトが直感的に操作できても、本体だけだと不安になってしまう。利用者には、カンタンな取扱説明書を用意すべきだ。「使うため」の文書化は、プロダクトインクリメントの一部として用意しよう。

アジャイルの文書化で重要なのは、常に文書化以外に方法がないのか問うことである。
会話が基本だ。だから話して済むなら文書化しない。

アジャイルのスピードを享受するには、作るための文書化は最小限にする。文書作成中は会話が途切れるからブレーキがかかる。その間に、状況が変わり、文書が急激に劣化する。
描画ツールで整形作業を始めるとあっという間に時間が経ってしまうから要注意だ。その間の対話は減るし、作るための文書はどんなにキレイに描いても顧客に価値をもたらさない。顧客のメリットを最大化する作業にエネルギーを注ごう。

プロダクトマネジメントの要諦は、作るための文書化は必要最小限に留め、文書化は顧客にとって価値のあるものだけにすることである。