第4回：アジャイルに対する誤解（1）--設計せずにいきなり作る？文書を書かない？ - (page 3)

　例えば、文書を作成することによって、認識合わせをする時間が削減され、相互理解が早く進み、品質が高まるということであれば、作成する価値は十分にあると言えます。加えて、先述した通り、アジャイル開発では現物で確認ができます。現物で確認できる内容については、文書にすることの意義を関係者と擦り合わせていくことになります。作成する文書が減れば、その文書作成分の労力を開発に注力することが可能になります。

　文書を成果物として定義している場合には、文書に関連する変更管理などの対応も必要になりますので、文書の増減が労力およびコストに影響していることを強く意識することが望まれます。

設計は改善を続ける

　ウォーターフォール方式の場合、初期に策定した設計内容は、余程の場合を除いては基本的に変更しません。一方で、アジャイル開発の場合には、短い周期で開発を進めていくうちに、当初の考えよりも良いアイデアが出れば、可能な限り取り入れて設計にも反映していきます。

　この点は、ウォーターフォール方式との大きな違いになり、アジャイル開発を取り入れる当初は戸惑いがあるかもしれません。ただ、昨今のビジネス環境の変化や技術革新のスピードを考えると、数年前の設計が最善とは言えず、変化に沿って柔軟に取り入れることの方が最善に近づく方法と言えます。

　一方で、設計の変更が高い頻度で発生するのであれば、設計書などの文書の更新も多く発生し、作業負担が増えると思われるかもしれません。この懸念に対しまず考えることとしては、「設計する」ことと「設計書を作成する」ことを別けて考える必要があります。

　「設計する」こと自体は、個人の頭の中で可能です。どのように作るかを考えることが設計で、複数人で検討する場合には、口頭や絵などで表現して共通認識を図りながら進められます。特定の様式に沿った文章でなくても十分に意思疎通は図れます。

　一方で、「設計書を作成する」ことは、設計した内容を記録したり、考えを共有したりすることの手段であると考えられます。このため、読み手が許容できるのであれば、設計書という手段にこだわらず、手書きであっても十分にその役割を果たせます。電子媒体として記録して残したいのであれば、手書きの内容をデジタルカメラなどで撮りためることでも可能なのです。

図3 ドキュメント作成工数の推移（出典：「Document Late: An Agile Core Practice」を基に、著者の許諾のもとKPMGで翻訳）

　少し話を整理すると、アジャイル開発においても、設計をして必要な設計書は作成します。ただし、より良い考えは柔軟に取り入れ、状況の変化に沿って設計も変更が必要になります。このため、変更があることを前提に、初期の設計の段階では、明文化する場合でも手書きなどの簡易的な方法で進めていき、変更に際しての労力を極小化できるように進めていくことも手段として考えられます。

　このような方法の場合でも、最終的に設計内容を文書として残したい場合には、開発期間の後半に当たる、開発内容が安定した段階において、文書を作成する期間を設けるなどして進めていくことで（図3の緑色線の推移相当）、結果として最新の設計内容が反映された設計書が出来上がります。

　繰り返しになりますが、このような方法が取れるのはアジャイル開発では現物で確認できるため、設計書という文書に頼りすぎるという状況が生じないことが要因です。

　ウォーターフォール方式では、本来は初期に策定した設計内容をベースライン化し、やむを得ず変更が必要となった場合は文書の変更管理の手続きに沿って設計書を修正してからプログラム修正を行います。しかしながら、設計の変更の必要性は第2回「ウォーターフォールに対するアンチテーゼとしての反復型開発とアジャイル」で触れたように、プロジェクト終盤のテスト局面で判明するケースが多く、スケジュール上の制約からやむを得ず設計書の修正を後回しにしてプログラム修正を行うことが往々にして発生します。その結果、設計書の内容と実態とに乖離（かいり）が生じ、開発の終盤になると、その乖離を是正するために設計書の修正などの手戻りをよく見かけます。こうした苦行もアジャイル開発によって改善されることになるのです。