A氏「いやー、まいったまいった。今度のプロジェクトの前のシステムなんだけどさ」
B氏「先輩、どうかしたんっすか？」
A氏「いやもう、ひどいのなんの。アジャイルとかって今流行りのヤツでやっつけたらしいんだけどさ、無いんだよ」
B氏「無いって、コードが？」
A氏「コードはバッチリあったさ。無いのはドキュメント！もうね、客もなにも無いっつーし、ホントに無いんだろうな。おかげでこっちゃ何かにつけてコードと首っ引きさ」
B氏「そりゃキツイっすねー…（ヘタに首つっこまんどこ。くわばらくわばら）」
ウォーター・フォール開発とアジャイル開発の最大の違いは、きちんと設計というフェーズを経ているかどうかだ。これは過去RAD開発というものが出たときも最大の違いとされた点で、スパイラル開発方法論が息を吹き返すたびに繰り返している争点だ。
どうも、よっぽど設計というものが退屈きわまりなく、プログラマという連中はそれをないがしろにしたいらしい。
しかし設計をおろそかにすると、しっぺ返しが必ず返ってくるものだ。
- 設計書をきちんと取り纏めないと、アーキテクチャの統一が疎かになる。
- きちんと設計した設計書なしにプログラマにコードを書かせるのは、無謀に近い冒険だ。
- なにか障害が起こった場合に設計書がないと、それが実装段階で入り込んだものなのか設計から入り込んだ障害なのか、はたまた要件から来ているのか、判別が難しくなる。（そしてそれは契約問題に発展しかねない）
- システムを保守する段階で、また新しく作り直す段階で、設計書はシステムを正しく伝えるドキュメントとして威力を発揮する。
だからこそ、きちんと設計フェーズを設けているウォーター・フォール開発が有効なのだし、根強く人気があるんだ。
しかし、設計とはなんだろう？Agile開発では本当に設計をしないのか？
少なくとも、ウォーター・フォール開発で言われている設計では、2通りの役割が自然に負わされている。
- 実装前に明らかにしておくべき事項を書き記したもの
- 実装後に実装指針や実装内容を伝達するもの
1番目の役割については、Agile開発は何の否定もしていない。そればかりか、Wikiサーバの立ち上げやストーリーカード、壁に模造紙を貼り出して設計内容を共有するなど、こと設計に関してはかなり大胆に様々な方法を試みている。Agile開発で共通しているのはただ一点、「設計書は過渡的なもの」であるという事だ。
その時々の問題領域を解き明かすため、あらゆる手法を使って設計される。が、その設計自体が実情に合わなくなると、あっさりと破棄される。その結果ピンポイントに正しい設計書やメンテナンスしてでも残したい正しい設計書だけが残り、実装と乖離している設計書は残りにくくなる。
またAgile開発では、ごく単純な設計書はソースから自動生成・半自動生成する事が自然に奨励されている。
対するウォーター・フォール開発で行われる設計作業は、経験上ひじょうに流れ作業指向・インスタント指向が強い。設計という作業を誰でも行えるレベルまで落とさないと、総がかりでフェーズを終わらせる事ができないためだ。そのため、ほぼ例外なく同一書式のドキュメントに同一内容・レベルでの記述を強く求められる。
そこで「生産」される設計書の最終段階である詳細設計書は、たいがいの場合「プログラムをただ書くには十分だがプログラムを理解するには不十分」というレベルのものに落ち着きがちだ。
昔話。
まだJavadocが出る前、ソース解析によるドキュメンテーション生成の威力を自分もまだ良く理解していなかった頃、Cのプロジェクトで詳細設計書のフォーマットにモジュールの概説欄を設けたことがある。モジュールの動作思想や使用上の注意点など、プログラマに設計思想を伝えたい目的で設けたのだが、じっさいに使用したのは自分ともう一人だけだった。その他の設計者はせいぜい「（モジュールの名前）をする」程度を書いていればいい方で、大概は空白だった。
2番目について、まず顧客が何をドキュメントとして求めているかが問題になる。Agile開発では自然に顧客第一となるので、顧客が欲するドキュメントは当然納品対象となる。そうなれば、個々の技術者の嗜好はさておき、作成しなければならない。
ついで「製品の規格を現すもの」としてのドキュメントだが、これは細かく突っ込むとじつは2種類あることがわかる。
- 製品が誤動作を起こした（バグが発現した）場合に、どのような動作が正となるかの判断元
- 製品を保守・改良・再開発する場合に、システムを理解するための取っ掛かりになるもの
コード段階で出るバグについては、Agileはもともと最終的なソースこそが唯一の詳細設計書であるとしている為、とても品質が高い。それに付け加えてTDDが定着し環境が急速に整ってきたため、ほぼコード段階でのバグ混入は壊滅状態にある。
この状態にあるコードでは、そもそもバグが発生した場合に「まず設計書とつけ合わせて犯人探し」という発想にはならない。
この点は、UnitTestをおっかなびっくり導入してみてはたいした効果も出せずに、大量のUnitTest嫌いを製造しているようなウォーター・フォール開発にも、ぜひ見習って欲しいものだ。
また、システムの基本を記したアーキテクチャ仕様や基本仕様などの「システムを理解するための仕様書」は、Agileにおいてもきちんと作られ、通常はソース一式（テストコードも含む）と一緒に納品される。また、きちんと対応をしていれば、各種の生きた設計が満載のWikiのログや、様々なやりとりを記した問題管理システムのログ等も一緒に納品されることがほとんどだ。
（まあ、ちょっとした「お遊びのページ」などは削除したうえでになるだろうが）
これらの資料により、定型的に「何か」が同一レベルで「網羅」されている（そしてよくあるのが、決定的事項に限って抜けている…そういう事項ほど決定が後回しであり、反映されにくいから）設計書のキングファイル群よりもずっと効率的にシステムを眺め回すことができる。
そしてなによりも…何度も繰り返しているが…一番決定的なのは、コンパイルでき、動作できるソースが、可読性も高く理解しやすい素直な構造になっている！何の抜けもなく全てが納品されている！テストを見れば個々の基本動作がわかり、テストを動かせば動くことがわかる！
これほどシステムを理解するのに一番適したものがきちんと提供され受け継がれている。素晴らしい事じゃないか。
その他に不足しているものなんて、はたしてあるのか？
さあ、目の前の嘘と省略だらけのキング・ファイルは捨て、もっと確実に・堅実なものをこそ残していこうじゃないか。
