アジャイル開発が導入される条件とは何か
|
開発対象システムの複雑化、短納期など、開発をめぐる環境は日増しに厳しくなる一方です。そうした現場を改善するために、変更に強く、品質や効率の高い開発を目指して考え出されたアジャイル開発でしたが、実際のプロジェクトで導入されたケースは日本国内においては決して多くありません。今回はアジャイル開発をテーマに、なぜ普及が遅いのか、なぜ導入に反対する者がいるのか、またどうしたら賛成を得られるのかといった現状と課題を考えます。
アジャイルでもドキュメントは重要
アジャイル開発にまつわる誤解として、「アジャイル開発ではドキュメントを書かない」というものもあります。もし、仮に（あり得ないでしょうが）あなたが採用しようとしている方法論が、「ドキュメントなど一切書くな！すべてはソースコードが語ってくれる！」と説いているとしたら、そんなことは無視して、プロジェクトに必要なドキュメントは何かを真剣に考えてください。アジャイル開発が戒めているのは、手続きや形式の上で必要なドキュメントを実際に動くプログラム以上に重視することや、ドキュメントが膨大で修正手続きも煩雑になり、システムの変更に追随できなくなることだけです。アジャイル開発においても、必要なドキュメントはやはり必要なのです。問題はどう書くかにあります（図 7）。
図7 各種ドキュメントの内容と注意点
ドキュメントを書く目的は、読み手に対象システムを理解してもらうこと以外にありません。そのため、ドキュメントの構成を考える際は、どのような読者がどのような目的でシステムを理解したいと思うかに配慮することが必要です。例えば、設計の誤りを見つけ出すレビューや、改修や機能追加を行なう保守などの場面でドキュメントが必要となるでしょう。いずれの場面でもドキュメントによって対象物の理解を深めることが重要となり、ドキュメントの出来が作業に大きく影響します。
レビューでは、特に複雑な箇所を詳細に検証したいでしょうから、ドキュメントは複雑な箇所に重点を置いて書きます。複雑なロジックを持つモジュールと、名前を見れば内容が自明になるようなモジュールを、同じ粒度／詳細度で書く意味はまったくありません。また、システムの外部仕様や、その元となるビジネスルールの理解についてのレビューが必要となることもあるでしょうが、アジャイル開発では、そうしたレビューは短いサイクルで行なわれる実システムでの検証によって代替されます。実際にプログラムを組む前に、口頭で行なう理解内容の確認の補足資料を作る程度でまかなえることがほとんどでしょう。
また、将来保守や改修を行なう、あるいは途中からプロジェクトに参加するメンバーは、システムの全体像を理解することから始めますが、最終的には手を入れるべきソースコードを読みます。ドキュメントですべてを説明しなくても、ソースコードを読んでみて初めて細かいところが分かるという形 で良いのです。今は開発ツールが、ソースコードのブラウズを助けてくれます。
それに、アジャイル開発であれば、自動テストのテストケースがモジュールの仕様を最もよく表わしているでしょうから、テストケースと別にモジュール仕様書を書く必要は少ないと思います。個別のメソッドを見ても分かりづらい複雑な状態遷移などは、別に ドキュメントを起こす価値があるかもしれません。
保守などの場面では、ソースコードを読み込めば分かる詳細よりも、システムが実現している業務／ビジネス上の価値を理解することや、システム全体の構成やサブシステム／モジュールの役割分担をざっくりつかむことができる「システムの詳細にたどり着くための地図」のほうが、何よりの助けになります。そうしたドキュメントは、大部になることも少ないですから、手間と見返りを考えても積極的に書く価値があると思われます。
また、そのような概要資料には、網羅性があります。網羅性を何より重視する人がいますが、詳細なドキュメントで網羅性を保とうというのは愚かしい試みです。抜けや漏れがないことを防ぐ必要はありますが、ドキュメントでは大きな粒度で抜け／漏れを防ぎ、後はいずれにせよ網羅性を持たねばならないソースコードとテストケースで確認していけば良いでしょう。
逆に、詳細に見ていけばいくほど、「あれ？どうしてここはこんな風になっているんだろう？」という疑問が生じることがよくあります。詳細だけを見ていては分からない、もっと大きな粒度での設計判断かもしれませんし、実装上の制約回避のためのクイックハック(注4)かもしれません。クイックハックを行なうことの是非はさておき、どうしてそのような設計上／実装上の判断が下されたのかを知ることが、改修や機能追加を行なう上では大変重要になります。そうしたポイントについては、設計資料やソースコード中のコメントとしてでも、確実に残していくことが必要でしょう。
そうした各種のドキュメントをいつ書くかというのも問題になります。官僚的な進め方をするのであれば、工程ごとに成果物を定め、成果物の完成をもって工程の完了とし次工程に進むということになりますが、変化し続けるシステムを扱っている以上、完成ということはありません。システムとともにドキュメントも常に改修され続けることになり、結構なコストになります。
であれば、システム概要などの重要な資料については、メンテナンスし続けることが可能な程度にボリュームを抑えつつ作成し、そうでないものは適宜メモとして残しておいて(注5)、開発の大きな区切り目にまとめて文書化するのが得策と言えます。
どのようなドキュメントが必要で、どのように更新していくかは、プロジェクトの体制と扱うシステムの特性によって異なります。さらに、そのシステムの特性も、どんどん変化していきます。プロジェクトで公式に作成するドキュメントについては、メンバー間で議論した上で、作るべきものを決定していくのが良いでしょう。
おわりに
システム開発におけるアジリティ（agility：俊敏性、機敏さ）の獲得は、顧客にとっても開発者にとっても急務であることは間違いありません。しかし、現場におけるアジャイル開発の適用状況を見るに、その必要性とは相変わらず大きなギャップがあるように見えます。
アジャイル開発の適用とは、大仰に言えば、システム開発を行なう組織を「管理者の命令によって動く制御型組織から、現場での判断に基づいて動く自律型組織」へ変革することにほかなりません。その実現には、個々人の働き方や価値観を大きく変えることになります。権限の委譲が求められる管理者層や、指示に従う慣習が染み付いた現場から抵抗があって当然です。どのようにして、そうした抵抗感を取り除いていくかが大変重要になってきます。また、急激な変化を起こそうとすれば、慣れないやり方を押し付けることとなり、慣れないが故のミスやリスクの見落としなど、トラブルを引き起こすこともあります。
アジャイル宣言のうたう価値と原則は、システム開発とシステムを利用するビジネスにとって大きな意味を持っています。ただ、それらはまだ効果がうまく出ていないように思われてなりません。本稿に述べたこと以外にも、大規模チームや分散開発への適用可能性、契約面での課題など、論点はまだまだ残っていますし、個々の論点についても、もっと掘り下げて考える必要があります。
しかし、本稿がアジャイル開発の導入をあきらめていた方々がもう一度挑戦してみようと考え直すきっかけとなり、それによってもっと多くの事例が生まれ、日本の環境特有のさまざまなプラクティスが導き出されることにつながれば、筆者にとっては望外の幸せです。
（注4）デビッド・トーマス、アンドリュー・ハント著／長瀬嘉秀、テクノロジックアート訳／アスキー刊／ 2005 年3 月発行／ISBN4-7561-4599-X
（注5）この目的に、印刷可能なホワイトボードは大変有用です。
石川智久（いしかわともひさ）
元々はテーブル設計が得意分野だったが、より概念的な方向に興味を持ちはじめ、アナリシスパターン的な世界へ徐々に移行中。一方で、アーキテクトとしてプロジェクトに参加する機会も増え、自分が「アーキテクト」なのか「モデラー」なのか分からなくなっている。中堅SIer を経て、2002 年より現職。
高橋英一郎（たかはしえいいちろう）
Java によるWeb アプリケーション開発一筋で生計を立てている。現職では商用J2EE Webアプリケーションフレームワークの開発に従事。いかにして楽にWebアプリケーションを構築するか、日夜頭を悩ませている。
山本啓二（やまもとけいじ）
関東在住の阪神ファン兼コンサルタント。日本シリーズ観戦成績が、3年越しで4連敗となりました。ロッテの強さは本物ですね。でも、来年4勝して5割に戻す予定です。著書に『プログラマの「本懐」』