アジャイルモデリング(AM)の原則

基本原則

• 簡潔さを心がけよう：開発時には、もっとも簡単な解決策がもっともよい解決策であると考える必要があります。ソフトウェアを作りこみすぎてはいけません。AMでは、今日必要でない機能をモデルに加えてはいけません。今日、システムを必要以上にモデリングすることはありません。今日存在する要求にもとづいてモデリングを行い、今後要求が変化したらシステムをリファクタリングしようという勇気を持ってください。モデルは可能な限り簡単にしておくことです。
• 変化を受け入れよう：時が経てば要求は変化します。時とともに要求に対する理解も変化します。プロジェクトが進むにつれて、プロジェクトの利害関係者も変わる可能性があります。新たな人が参加したり、もとからいる人が離れていったりするためです。利害関係者の視点が変わって、その結果、作業の目的や成功かどうかの判断基準が変わる可能性もあります。これはつまり、作業がすすむにつれてプロジェクトをとりまく環境が変化し、結果として現実に合わせて開発方法を変えなければならないということです。
• 次への備えが第2のゴール：ユーザに動くシステムを納品したとしても、プロジェクトが失敗とみなされることがあります。プロジェクトの利害関係者のニーズを満たすことには、システムが堅牢であり、後になっての拡張も可能であると保証することも含まれます。 Alistair Cockburnがよく言うように、ソフトウェア開発ゲームでは、第2のゴールは次のゲームへの備えなのです。 次の作業とは、システムの次のメジャーリリースの開発かもしれませんし、単に現在開発中のバージョンの運用およびサポートであるかもしれません。 その準備として、質の高いソフトウェアを開発するだけでなく、人々が次のゲームを効果的に行えるだけのドキュメントと参考資料を作成する必要があるでしょう。 考慮すべき要因には、今のチームメンバーが次の作業に参加するかどうか、次回の作業自体の性質、組織にとっての次の作業の重要性などがあります。 簡単に言うと、システムの作業をするときには、将来に目を向けておく必要があるのです。  
• 少しずつ変更：モデリングに関して理解しておかなければならない重要な概念は、初めから正しいものを作る必要はないし、実際、作ろうとしても作れるものではない、ということです。また、モデルの細かいところまでひとつひとつ表現する必要はなく、その時点で必要なだけ作成すれば十分です。初めにすべてのモデルを作成しようとするような無駄はやめて、小さなモデル、あるいは大まかなモデルを作成して足場を固め、その後インクリメンタルにそれを発展させる(あるいは必要でなくなれば廃棄する)とよいでしょう。
• 利害関係者の投資を最大限に生かそう：プロジェクトの利害関係者は、ニーズに合ったソフトウェアを開発するために、時間やお金、設備などの資源を投じます。利害関係者にはその資源をできる限り有効に活かす権利があり、開発チームが資源を浪費してはなりません。さらに利害関係者は、その資源をどう使うか、あるいは使わないかについて、最初的な決断権があります。 自分の資源に置き換えて考えてみると、そうするのが当然だと思いませんか。 
• 目的を持ってモデリングしよう：開発者の多くは、モデルやソースコード、文書といった成果物が、十分詳しいか、あるいは詳細すぎないか、また同様に十分正確であるかを気にかけています。そのような開発者に欠けているのは、一歩下がって、そもそもなぜその成果物を作成しているのか、誰のために作成しているのかを考えることです。モデリングの場合なら、ソフトウェアのある側面をよりよく理解するためかもしれませんし、自分の方針を上司に説明してプロジェクトを正当化するためかもしれません。今後運用や保守に携わる人に対してシステムを説明する文書を作成するためかもしれません。モデルの利用者が分からないのであれば、どうしてわざわざ作成するのでしょうか。最初にモデルを作成する確かな目的とモデルの利用者を確認し、それにもとづいて十分正確で十分詳細になるまでモデルを作成する必要があります。モデルの目的が達成されたら、いったんその作業は終了し、コードを書いてそのモデルがうまく動くことを示すなどの別の作業に移ります。この原則は、既存モデルの変更にも適用されます。たとえば既知のパターンを適用するなど、変更を行う場合には、その変更を行うだけの正当な理由が必要です(新しい要求を満たすため、リファクタリングを行ってよりすっきりしたものにするため、など)。この原則で意図している重要なことは、利用者を知る必要があるということです(自分自身が利用者である場合も含みます)。たとえば保守担当者のためにモデルを作成している場合、彼らに実際に必要なものは何でしょうか。500ページの広範囲な文書が必要なのでしょうか、10ページのシステムの動きの概要で十分なのでしょうか。分からないなら、出向いていって尋ねることです。
• 複数のモデル：ソフトウェアを開発するためには複数のモデルが必要なこともあります。それは各モデルがソフトウェアの1つの側面を表すものだからです。「今日のビジネスアプリケーションを構築するにはどんなモデルが必要なのだろう」。最近のソフトウェアが複雑であることを考えると、効果的に開発するためには、モデリングの道具箱の中に広範な手法を含めておく必要があるでしょう(手始めとしてModeling Artifacts for AMを参照してください)。 重要なのは、どんなシステムにもこれらのモデルすべてを作成する必要はなく、開発するソフトウェアの性格にびったり合うように、少なくともそのモデルのいくつかを作成するのだということです。システムが異なれば、作成するモデルの種類も変わります。家でちょっと修理をするのに道具箱の中の道具がすべて必要ではなくても、さまざまな修理を行っていく上でいずれそれぞれの道具が必要になるのと同じです。他のものよりよく使う道具があるのと同じように、いくつかの種類のモデルは他のモデルよりよく利用することでしょう。Be Realistic About the UMLのエッセイで述べたUMLの成果物の他、利用できるモデリング成果物の種類について詳しくはThe Object Primer -- An Introduction to Techniques for Agile Modelingのホワイトペーパーを参照してください。
• 質の高い仕事をしよう：いいかげんな仕事を好きな人はいません。開発する人がそれを気に入らないのは、誇りに思えない仕事だからであり、後から(どんな理由であれ)リファクタリングしに来た人が気に入らないのは、理解しにくく更新しにくいからであり、エンドユーザが気に入らないのは、問題が起きやすかったり望んだものでなかったりするからです。
• 素早いフィードバック：作業とそれに対するフィードバックとの間にかかる時間は非常に重要です。他の人と一緒にモデリングをしている場合、特にホワイトボードやCRCカード、付箋などのモデリングの基本的な道具といった、共有できるモデリング手段を用いている場合は、自分のアイデアに対するフィードバックをほとんど即時に得ることができます。顧客の近くで協力しながら要求を理解したり、分析したり、あるいはニーズに合ったユーザインターフェースを開発したりすることで、早くフィードバックを得られる可能性が高くなります。
• ソフトウェアが第1のゴール：ソフトウェア開発のゴールは、プロジェクトの利害関係者のニーズを満たすソフトウェアを効果的に構築することです。第1のゴールは、無関係の文書でも、無関係の管理成果物でも、モデルでさえもありません。この目的に直接役立たない作業は、本当に必要かどうかを検討し、必要でなければ避けなければなりません。
• 身軽な旅：作成し、維持することにした成果物はすべて、引き続き保守する必要があります。7つのモデルを残した場合、何かが変わるたびに(要求の追加や変更、チームの仕事の取り組み方の変更、新しい技術の採用など)、それが7つそれぞれのモデルにどのように影響するかを検討し、それに応じて対応しなければなりません。残したモデルが3つだけであれば、7つの場合よりも明らかに少ない作業で同じ変更に対応でき、身軽な旅をしているためにアジャイル（機敏）になります。同様に、モデルが複雑であったり詳しかったりすればするほど、変更が困難になります(個々のモデルが「重く」なり、保守が重荷になります)。モデルを残そうと決めるたびに、チームが抽象的な情報を利用できる(つまり、チーム内およびプロジェクトの利害関係者とのコミュニケーションが向上する可能性がある)という便利さとひきかえに、アジャイルであることを犠牲にしているのです。この犠牲を軽視しないでください。砂漠を旅する人にとって、一枚の地図と帽子、しっかりした靴と水筒に入った水は役に立つでしょう。しかし、何百ガロンもの水と、考え得る限りのサバイバル用品を詰め込んだリュック、砂漠に関する何冊もの本を抱えて旅をすることはできないでしょう。同じように、詳細な要求文書や一連の詳細な分析モデル、一連の詳細なアーキテクチャモデル、一連の詳細な設計モデルを作成し、保守することに決めた開発チームが、ほとんどの時間をソースコードを書くのではなく文書の更新にあてていることに気付くのに、長い時間はかかりません。

追加原則

• 見栄えより中身：どんなモデルでも、何種類かの手段で表現することができます。たとえばUI仕様であれば、大きな紙にポストイットを貼り付けて作ることもできれば(本質的であまり厳密でないプロトタイプ)、紙またはホワイトボードに描いた下絵や、プロトタイピングツールまたはプログラミング言語で構築した「従来の」プロトタイプとして作ることもでき、あるいは図とテキストでの説明の両方を含む正式な文書として作成することもできます。ここで興味深いのは、モデルが開発ドキュメントである必要はないということです。CASEツールを使って作成した一連の複雑なダイアグラムでさえ、開発ドキュメントには含められないことがあります。別の成果物、おそらくはソースコードのための情報源として使われるだけで、正式な開発ドキュメントとしては承認されません。要するに、開発ドキュメントとして作成し、保守するためのコストをかけなくても、モデルの利点を享受できるということです。
• 誰しも他人から学べる：何かを完全に習得するということはあり得ません。さらに詳しく学んだり、知識を広げることが必ずできるはずです。機会をとらえて、他人と一緒に仕事をして何かを学んだり、新しい方法を試したり、何がうまく行って何がうまく行かないかをよく考えたりしてみてください。技術の変化は激しく、Javaなどの既存の技術はすさまじい勢いで進化し、C#や.NETといった新しい技術がひっきりなしに登場してきています。既存の開発技法の進化はやや緩やかではありますが、それでも進化は続いています。たとえば、私たちは業界としてテストの基本についてかなり長い間考えてきていますが、調査と実践を通じてその理解は常に改善されつづけています。忘れてはならないのは、私たちの業界では変化するのがあたりまえであり、トレーニングや教育、指導、書籍、同僚との仕事など、あらゆる機会をとらえて、ものごとを行う新しい方法を習得しなければならないということです。
• モデルを知ろう：適用可能な「複数のモデル」があるため、効果的に利用するにはその長所と短所を知っておく必要があります。
• 道具を知ろう：描画ツールやモデリングツールなどのソフトウェアは、さまざまな機能を持っています。モデリングツールを使うのであれば、その機能を理解し、いつ使うべきか、そしていつ使うべきでないかを知っておく必要があります。
• 実状に合わせよう：ソフトウェアを開発する方法は、組織の性格やプロジェクトの利害関係者の性格、プロジェクト自体の性格などといった与えられた環境に合わせて変えなければなりません。環境によって変えるべき事柄としては、適用するモデリング手法(ユーザが、初期の下絵や本質プロトタイプではなく、具体的なユーザインターフェースを示すよう要求するかもしれません)、使用する道具(デジタルカメラを購入する予算がないかもしれませんし、既存のモデリングツールのライセンスがすでにあるかもしれません)、適用するソフトウェアプロセス(組織でXPやRUP、あるいは独自のプロセスを使うことが決まっているかもしれません)といったものがあります。これらの方法は、プロジェクトレベルだけでなく個人毎の違いにも適合させることになります。たとえば、開発者によって使う道具が異なることがあります。また、ある開発者があまりモデリングをせずにコーディングに集中するのに対して、もっとモデリングに時間を割く開発者もいるでしょう。
• オープンで正直なコミュニケーション：人が提案をするには、自由であり、また自由であることを認識している必要があります。その提案は、1つあるいは複数のモデルに関係したアイデアのこともあるでしょう。もしかしたら誰かがある部分を設計するのに新しい方法を考えついたのかもしれませんし、要求に関して何かに気付いたのかもしれません。あるいは、スケジュールが遅れているという悪い知らせの場合もあります。単に現在の仕事の状況を知らせてきただけのこともあるでしょう。オープンで正直なコミュニケーションを行うことで、より正確な情報が得られ、それにもとづいてよりよい判断を下すことができます。
• 直観に従って開発しよう：何かがうまく動かない、少し矛盾がある、あるいは何かが「変なような気がする」と感じたときには、そのような直感が当たっている可能性が十分あります。ソフトウェア開発の経験を積むにつれ、直観はだんだんと冴えてきて、おぼろげに感じたことがモデリングのための重要な情報源になることが多くなります。要求が意味をなさない、あるいは完全でないと直観的に感じたら、ユーザと一緒に調査してみてください。アーキテクチャの一部がニーズに合わないと感じたら、システムとして実行できる簡単な技術プロトタイプを作成してその理論を実際に確かめてください。設計案Aの方が案Bより良いと感じ、どちらかに決めなければならない理由がなければ、さしあたり案Aを採用しましょう。直観が間違っていたと後で気がついたらそれから改善することができるのだと、勇気という価値を持って考えることが重要です。