どのようなモデルがアジャイルか?

1. （アジャイルなモデルは）目的を満たしている。  上司に作業範囲を伝える必要があるなど、伝えるためにモデリングをすることもあれば、一連のJavaクラスを実装するための設計方針を決定する必要があるなど、理解するためにモデリングをすることもあるでしょう。  アジャイルなモデルが十分であるためには、それが作成された目的を満たしていることが明らかに必要です。

2. （アジャイルなモデルは）理解できる。アジャイルなモデルは、意図した読者にとって理解できるものです。  要求モデルはユーザが理解できるビジネスの用語で書かれるでしょうし、技術アーキテクチャモデルでは開発者が使い慣れた技術用語が使われるでしょう。  モデルの表記法は、理解できるかどうかを左右します。たとえば、その表記法が何を表しているかを知らなければ、UMLのユースケース図はユーザにとって価値がありません。  この場合、別の方法を取るか、ユーザにモデリング手法を教えることになります。   線の交差を避けるといった記述スタイルの問題も、理解しやすさに影響するでしょう。煩雑なダイアグラムはきちんと整えられたものより読みにくいものです。 また、以下で述べますが、モデルの詳しさも理解しやすさに影響します。詳しいモデルは、あまり詳しくないモデルより理解が困難です。 同様に、後で述べる簡潔さも、影響を及ぼす要因になります。

3.（アジャイルなモデルは）そこそこ正確である。  モデルは多くの場合、100パーセント正確である必要はなく、そこそこ正確であればよいだけです。  たとえば、街路地図に通りが1つ抜けていたり、地図では通れるはずの道が工事中で通行止めだった場合に、地図を投げ捨ててやみくもに町中を走りはじめるでしょうか。 おそらくそんなことはしないはずです。 地図を最新のものにしようと考えてペンで記入したり、近くの店で最新版(それでも古くなっているかもしれませんが)を購入したりするかもしれませんし、自分の目的に対して十分であれば、完璧ではないことを承知した上でその地図を使い続けるかもしれません。町の通りの多くが正確に描かれていれば、それを使って動き回れるのですから。 間違いを発見したからといってすぐに街路地図を捨てない理由は、地図が完璧だと期待もしていなければ、完璧である必要もないからです。 同じように、要求モデルやデータモデルに問題を見つけた場合、その時点でモデルを更新するか、そのままの状態、つまり十分であるが完璧ではない状態を受け入れるかのどちらかになります。  不正確で構わないプロジェクトチームもあれば、不正確ではダメなチームもあるでしょう。これは、プロジェクトの性格や、チームメンバー個人の性格、組織の性格によって決まります。  どこまで正確にすれば十分かは、モデルの利用者と対象とする開発内容との両方に依存します。

私は十代の頃、レストランで働いていました。皿洗いから始めて、夜間勤務のマネージャまで出世しました。  夜間マネージャとして、私は営業終了時の一連の仕事を教わりましたが、その中でもっとも重要だったのは、一日の最後にレジを閉めることでした。  私にこれを教えてくれたマネージャはレジの中の金額が正確でないと気がすまない人で、その日の売り上げの合計が合わなければ、数えなおさなければなりませんでした。  このためには紙幣だけでなく硬貨も数えなければならず、そのために毎日平均して20分ほどもかかっていました。  数ヵ月後、そのマネージャは別の店に移り、別のマネージャがやってきました。  ある夜、一緒に店を閉めたとき、彼は私が硬貨を数えているのを見て、時間をかけてひとつひとつ数えるなど信じられないという顔をしました。  そして、彼の数え方を教えてくれたのです。それは硬貨の金種ごとに手にとり、それを見て合計を推測し、誤差が2、3ドルであればよしとして次に移る、というものでした。  計算が完全に正確でなくても近ければいいと彼が悟っていたため、20分の仕事が5分にまで短縮されました。  彼は、15分早く家路につくことができ、それが週に6日、年に50週積み重なって、30年の勤めで年に75時間ずつ節約できたのです。

4. （アジャイルなモデルは）そこそこ一貫性がある。  アジャイルなモデルが役に立つためには、それ自体、あるいは別の成果物と完全に一貫性を保っている必要はありません。  あるユースケースがステップの1つで別のユースケースを呼び出している場合、対応するユースケース図では、UMLのステレオタイプ<<Include>>のタグがついた関係を2つのユースケース間に引いて、それを示すべきです。  しかし、ダイアグラムにはそれが描かれていません。  なんということでしょう、ユースケースとダイアグラムが一致していません。  危険です、ウィル・ロビンソン、危険です！  緊急非常事態！  至急避難してください！  ちょっと待ってください。ユースケースモデルは確かに矛盾していますが、だからといって世界の終わりが来たわけではないのです。  もちろん、理想世界では成果物はすべて完全に一貫したものになっているでしょうが、実際にはそうはならない場合も多いのです。   ちょっとしたビジネスアプリケーションを構築するときには、多少の不整合は許容することができます。  もちろん、不整合を許容できない場合もあります。その例がNASAの宇宙探査機が1999年に火星に墜落した事故で、メートル法と英本国法定の標準の度量衡制度に関して高い授業料を払うことになりました。  重要なのは、アジャイルなモデルはそこそこ一貫性があり、それ以上ではないということです。役に立つためには完璧なモデルは必要ないことが多いのです。

正確さと一貫性については、明らかにここでもエントロピーの問題を考えなければなりません。 保守したい成果物(私は「保管用」と呼んでいます)があるのなら、時間がたってそれを更新するために労力をつぎ込む必要があります。  そうしなければ、すぐに古くなって事実上役に立たなくなります。 たとえば、通りが1つ2つ抜けている地図は許容できても、町の4分の3もの通りが抜けている地図は使い物になりません。  成果物をそこそこ正確にしておけるよう労力をつぎ込むことと、労力をつぎ込みすぎてプロジェクトの進捗を不必要に遅らせること、そして成果物が役に立つだけの十分な投資をしないことの間には、微妙な境界線があります。

5. （アジャイルなモデルは）そこそこ詳しい。  街路地図には、それぞれの通りの個々の家までは示されていません。  そこまでいくと詳しく書きすぎで、地図は見にくくなってしまいます。しかし、道を作る場合には、その通りの各建物や下水管、電気ボックスなど、役に立つだけの十分な詳細が記入された地図を使うのだろうと思います。 その地図には、歩道の敷石ひとつひとつまでは描かれていません。これも詳しくなりすぎるからです。 どこまでで「そこそこ詳しい」かは、モデルの利用者や目的によって変わります。車を運転する場合には通りを表す地図が必要ですし、道路工事をする場合には土木に関する詳細が描かれた地図が必要です。

アーキテクチャモデルについて考えてみましょう。  状況によっては、ホワイトボードに2、3のダイアグラムを描き、プロジェクトの進行に伴なってそれを更新する方法で十分でしょう。 モデリングツールを使って5、6枚のダイアグラムを描かなければならない場合もあるでしょう。  もしかすると、その図に詳しい文書を付け加える必要があるかもしれません。  プロジェクトによってニーズは異なります。  この3つの例のそれぞれで、そこそこ詳しいアーキテクチャモデルを実際に作成し、保守しています。「そこそこ詳しい」レベルが状況によって異なっているだけです。

6. （アジャイルなモデルは）プラスの価値を提供する。  プロジェクトの成果物の1つの基本的な面は、費用対効果においてプラスの価値を持つべきだということです。 アーキテクチャモデルがプロジェクトにもたらす利益は、それを開発し、(必要なら)保守するためのコストより大きいでしょうか。  アーキテクチャモデルは、プロジェクトチームが目指す構想を固めるのに役立つ、明らかに価値のあるものです。  しかし、そのモデルを作成するコストが利益を上回ったら、プラスの価値はなくなります。  5000ドルをかけてホワイトボードにダイアグラムを描いてもできる仕事に対して、詳細で多くの文書を含むアーキテクチャモデルを作成するのに10万ドルも費やすのは賢明でないでしょう。

7. （アジャイルなモデルは）できるだけ簡潔になっている。  仕事を遂行できる範囲内でできるだけ簡潔なモデルにするよう努力するべきです。 簡潔さは、明らかにモデルの詳しさに影響されますが、適用する表記法の範囲にも影響されます。 たとえば、UMLのクラス図にはオブジェクト制約言語(OCL)など無数のシンボルを含むことができますが、ほとんどのダイアグラムは表記法のほんの一部だけを使って十分表現することが可能です。 多くの場合は使用可能なすべてのシンボルを適用する必要はないので、仕事に支障がない程度の表記法の一部だけを使うよう制限してください。

このようにアジャイルなモデルは、目的を満たすモデルでそれ以上ではない、利用者にとって理解できる、簡潔である、そこそこ正確で一貫性があり詳しく、作成および保守のコストを考慮してプロジェクトにプラスの価値がある、と定義されます。  

よく尋ねられる哲学的な質問に、ソースコードはモデルかどうか、あるいはより重要なことですがアジャイルなモデルかどうか、というものがあります。  この文書の範囲外で尋ねられたのなら、私はYesと答えるでしょう。ソースコードは明らかにソフトウェアを抽象化したものなので、きわめて詳細なものではありますがモデルです。  また、うまく書かれたコードはアジャイルなモデルであるとも主張するでしょう。  いずれにせよ、互いに異なったものとして扱った方が良いという単純な理由で、私はソースコードとアジャイルなモデルを区別します。すなわち、アジャイルなモデルはソースコードの作成に役立つという点です。

アジャイルモデリングとは何か?および When Are(n't) You Agile Modeling?も参照。 

参考文献および推奨図書

参考文献のページ（英語）を参照。