アジャイルモデリング(AM)
公式サイト

プラクティス

アジャイルモデリング(AM)のプラクティス

by Scott W. Ambler, Copyright 2001-2002

アジャイルモデリング(AM)では、AMの原則にもとづいて、一連の基本プラクティス追加プラクティスを定義しています。そのうちのいくつかはエクストリームプログラミング(XP)から採用したもので、Extreme Programming Explainedで詳しく説明されています。AMの原則と同様に、プラクティスはモデリング作業に重点を置いて書かれています。そのため、XPから採用した部分はXPでの説明と少し異なる書き方になっているかもしれません。

基本プラクティス

  • 利害関係者の積極的な参加:これはXPの「オンサイトの顧客」を拡張したものです。「オンサイトの顧客」とは、開発対象のシステムに関する情報を提供したり、要求とその優先度について適切でタイムリーな決断を下すことができる権限と能力を持つユーザに、現場にいてもらう必要性を述べたものです。AMでは、XPのプラクティス「オンサイトの顧客」を拡張して、直接のユーザやその上司や上級の管理職、運用担当者、サポート(ヘルプデスク)担当者といったプロジェクトの利害関係者に、プロジェクトに積極的に参加してもらうことを提唱しています。たとえば、上級の管理職に資源に関してその場で判断してもらったり、上級の管理職にプロジェクトに対する公的/私的な援助をしてもらったり、運用やサポートの担当者に、それぞれの担当職務に関係する要求やモデルの作成に積極的に参加してもらったり、といったことが考えられます。
  • 適切な成果物を使おう:成果物ごとに、それぞれふさわしい適用場所があります。たとえば、UMLのアクティビティ図はビジネスプロセスを記述するのに向いていますが、データベースの静的構造は物理データモデルあるいは永続モデルとして表す方がよいでしょう。ほとんどの場合、ソースコードよりダイアグラムの方が適切です。一枚の絵が千のことばに匹敵するとしたら、適切な場所に適用した1つのモデルは、1024行のコードに匹敵します(Karl WiegerのSoftware Requirementsで述べられていることばです)。というのも、座ってサンプルコードを書くよりも、同僚とホワイトボードに2、3のダイアグラムを描く方が、いろいろな設計案をより効率的に調べられることが多いからです。そのためには、成果物の種類ごとにその長所と短所を理解しておく必要があります。「複数のモデル」を考えると、このような長所、短所の理解は大変ですが。
  • 共同所有:必要であれば、誰もがどのモデルに対しても、実際にはプロジェクトのどんな成果物に対しても、変更を加えることができます。
  • テストできるか考えよう:モデリングを行うときには、「これをどのようにテストするか」を常に考えてください。作っているソフトウェアをテストできないのなら、そもそも作るべきではないからです。最新のソフトウェアプロセスには、プロジェクトのライフサイクル全体を通してテストと品質保証の作業が組み込まれています。そのプロセスのいくつかでは、ソフトウェアを書く前にテストを書くという考え方(これはXPのプラクティスです)を推奨しています。
  • 複数モデルを並行して作ろう:モデルの種類ごとに長所/短所があるため、1つのモデルだけでモデリングのニーズを満たすことは不可能です。たとえば要求を調査しているときには、いくつかの本質ユースケースやユーザストーリー、1つの本質UIプロトタイプ、いくつかのビジネスルールを作成する必要があります。アジャイルモデリングでは、「他の成果物に移ろう」のプラクティスと組み合わせることで、一度に1つのモデルに集中するよりも複数のモデルを並行して作成する方が、ずっと生産性が高くなることがよくあります。
  • 中身はシンプルに作ろう:要求、分析、アーキテクチャ、設計といったモデルの内容は、プロジェクトの利害関係者のニーズを満たせる範囲内で、できるだけ簡単にするべきです。つまり、正当な理由なしにモデルに余分な情報を付け加えるべきではありません。システム監査機能を追加するという要求がなければ、その機能をモデルに追加してはいけません。依頼されたときに(依頼があった場合にだけ)実際にその機能を追加できると信じる勇気を持ってください。
  • モデルはシンプルに描こう:適用しようとするダイアグラム(UMLのダイアグラム、ユーザインターフェース図、データモデルなど)を考えたとき、ほとんどの場合にはそのダイアグラムで利用可能な表記法の一部だけしか必要でないことがすぐに分かるでしょう。理解しようとしている主な機能を表した簡潔なモデル、たとえばクラスの主な責務とクラス間の関係を描いたクラスモデルがあれば、たいていの場合は十分です。 もちろん、あとで補う必要のある主要コードや、コーディング基準で定められたすべてのget/set操作をモデリングすることは可能ですが、それでどんな価値がもたらされるでしょうか。ほとんどないでしょう。
  • モデルを公開しよう:モデルは公開すべきです。多くの場合は、「モデル掲示用の壁」や「不思議の壁」と呼ばれるようなものに掲示します。モデルの掲示によって、隠しごとがなくなり、チームのメンバーやプロジェクトの利害関係者が最新のすべてのモデルをすぐに見ることができます。その結果、チームの「オープンで正直なコミュニケーション」が促進されます。モデル掲示用の壁とは、誰にでも見えるように自分のモデルを掲示する場所で、開発チームやプロジェクトの他の利害関係者からアクセスできるところでなければなりません。モデル掲示用の壁は、アーキテクチャのダイアグラム用に指定されたホワイトボードや、物理データモデルをプリントアウトしてテープで貼り付ける場所のように、物理的なものになる場合もあるでしょう。また、スキャンした画像を載せる内部的なWebページのように、仮想的なものの可能性もあるでしょう。
  • 他の成果物に移ろう:ユースケース、CRCカード、シーケンス図、あるいはソースコードといった、ある開発成果物を作成していて行き詰まったら、当面は別の成果物にとりかかることを検討するべきです。成果物ごとに長所と短所があり、それぞれがある種の仕事に向いています。1つの成果物の作業がうまくいかないとき、たとえばユースケースを作成していてビジネスロジックの記述に苦戦しているのに気がついたら、それは別の成果物に移ったほうがいいというしるしです。たとえば、本質ユースケースを作成している場合には、本質UIプロトタイプやCRCモデル、ビジネスルール、システムユースケース、変更案などに焦点を移して作業を始めることを考慮すればよいわけです。別の成果物に移ることで、すぐに煮詰まった状態から抜け出すことができます。別の成果物の作業が進むからです。さらに、視点を変えることで、最初に行き詰まった原因に対処できることもよくあります。
  • 少しずつモデリングしよう:大規模な仕事を小さな部分に整理して、順に、できれば数週間から1、2か月の間隔でリリースするというインクリメンタルな開発では、ソフトウェアを早くユーザの手に渡すことができるため、アジャイル(機敏)さが向上します。
  • 他の人々と一緒にモデリングしよう:「目的を持ってモデリング」を行っている場合、自分が何かを理解するためにモデリングをしていること、アイデアを他人に伝えるためにモデリングをしていること、あるいはプロジェクトの共通の構想を作り上げようとしていることに気付くことがよくあります。これはグループでの作業であり、複数の人の意見を効果的に組み合わせる必要があります。プロジェクトにとってきわめて重要な一連の中核モデルを作成するためには、開発チーム全体で協力する必要があることに気付くことも多いでしょう。たとえば、システムのメタファ(喩え)やアーキテクチャを構築するには、グループでモデリングをして、皆が合意し、しかもできる限り簡潔である解決策を作り出す必要があります。ほとんどの場合、これを行うためのもっともよい方法は、その問題について徹底的に人と論ずることです。
  • コードで確かめよう:モデルとは考えを抽象的に表現したものであり、開発対象の1つの側面を正確に反映するべきものです。しかし、そのモデルで大丈夫なのでしょうか。それを判断するには、コードを書いてモデルを確かめなければなりません。請求先住所の情報を入力するHTMLページの下絵を書いたとしましょう。それをコーディングして、その結果のユーザインターフェースをユーザに見せ、フィードバックをもらってください。複雑なビジネスルールを実装するロジックを表したUMLのシーケンス図を書いたのであれば、テストコードとビジネスロジックのコードを書き、テストを実行して、正しく動くことを確認してください。多くのプロジェクトで一般的になってきている反復型のアプローチでソフトウェアを開発するときには、モデリングは行わなければならない数多くのタスクの1つでしかないことを忘れないでください。少しモデリングをし、少しコーディングをし、そして(これが特に重要ですが)少しテストをするのです。
  • もっとも簡単な道具を使おう:大多数のモデルは、ホワイトボードや紙や、あるいはナプキンの裏にでも描くことができます。それらのダイアグラムを保存したければ、デジタルカメラで写真を撮ることもできますし、単に紙に書き写すこともできます。これで問題がないのは、ほとんどのダイアグラムが使い捨てだからです。それを描いて問題点をじっくり考えることに本当の価値があるのであって、問題が解決すればそのダイアグラムにはあまり価値がなくなります。そのため、ホワイトボードとマーカーというのが多くの場合にもっとも適したモデルを作る道具になります。重要なプロジェクトの利害関係者に見せるダイアグラムを作成するには描画ツールを使い、コードの生成などプログラミング作業に役立つときにだけモデリングツールを使ってください。次のように考えるとよいでしょう。単純なモデルを作成している場合、その多くは使い捨てです。というのも、「理解するためのモデル」を作成しているなら、問題を理解してしまえばそのモデルをとっておく必要はおそらくないからです。だとしたら、複雑なモデリングツールを利用する必要はありません。

 

追加プラクティス

  • モデリング標準を使おう:このプラクティスは、XPの「コーディング規約」を改名したものです。あるソフトウェアプロジェクトにおける一連のモデリング標準に同意し、それに従って開発を行わなければならないというのが基本的な考え方です。一般的なコーディング慣習に従うことに価値があり、選択したコーディング指針に従った明確なコードは、従っていないコードよりも理解しやすく変更しやすいでしょう。これと同様、一般的なモデリング慣習に従うことにも価値があります。使用可能な一般的なモデリング標準にはさまざまな種類のものがあります。その1つが、Object Management Groupの統一モデリング言語(UML)で、そこには一般的なオブジェクト指向モデルの表記法およびセマンティクスが定義されています。UMLはよい出発点にはなりますが、それだけでは十分でありません。考えられるモデリング成果物のすべてがUMLに含まれているわけではありません。さらにUMLは、見た目の整ったダイアグラムを作成するためのモデリングスタイルガイドには言及していません。スタイルガイドと標準の違いは何でしょうか。コードに関して言えば、標準はattributeNameというフォーマットで属性名をつけることであり、スタイルガイドは制御構造(if文やループなど)内のコードを1段階インデントすることです。モデルに関して言えば、標準はクラス図のクラスをモデリングするときに長方形を使うことであり、スタイルガイドはダイアグラム上でサブクラスをスーパークラスの下に置くことです。
  • パターンは控えめに使おう:有能なモデリング担当者は、一般的なアーキテクチャパターンやデザインパターン、アナリシスパターンを学び、それを自分のモデルに適切に適用します。しかし、Martin FowlerがIs Design Dead?で指摘するように、開発者はパターンの適用に徐々に慣れていき、緩やかに適用するべきです。これは「簡潔さ」の価値を反映したものです。言い換えると、パターンを適用できるのではないかと「疑った」場合でも、今日必要な最低限のことだけを実装します。その場合、パターンを完全に適用するのが実際にもっとも簡潔な方法だと後で分かったときにリファクタリングしやすいように、モデリングするべきです。つまり、モデルを作りこみ過ぎないでください。たとえば、自分の設計の中に、GoFのStrategyパターンを適用できそうな場所を見つけたとします。しかし、現在のところ、実装しなければならないアルゴリズムは2つしかありません。この場合のもっとも簡潔な方法は、各ストラテジーをそれぞれのクラスにカプセル化し、そのいずれかを適切に選択して適切な入力を渡す操作を作ることです。これはStrategyの一部を実装したものなので、もっと多くのアルゴリズムを実装しなければならないときには設計をリファクタリングすることができ、しかも今の段階でStrategyパターンに必要な枠組みをすべて作る必要はありません。この方法で、パターンの適用に徐々に慣れていくことができます。
  • 一時的なモデルを捨てよう:作成したモデルの大部分は、一時的/作業モデルです。つまり、設計の下絵、あまり正確でないプロトタイプ、インデックスカード、アーキテクチャおよび設計の代替案などといったモデルですが、これらはすでに目的を果たしていて、今後価値を持つものではありません。モデルはすぐにコードと一致しなくなりますが、それはあたりまえのことです。そこで、プロジェクトにとって価値があるのならモデルを同期させるか、モデルを更新するための労力に見合うだけの価値がない(費用対効果はマイナス)ためモデルを廃棄するかの判断を迫られることになります。
  • 取り決めモデルはきちんと定義しよう:データベースや既存のアプリケーション、情報サービスといった、システムで必要な情報リソースを外部のグループが管理している場合には、しばしば取り決めモデルが必要になります。取り決めモデルとは、両者がお互いに合意し、時間が経って必要になれば合意の上で変更されるものです。取り決めモデルの例としては、アプリケーションプログラミングインターフェース(API)の詳細ドキュメントや、ファイルレイアウト記述、共有するデータベースを表すXML DTDや物理データモデルなどがあります。法的な契約(contract)と同様、取り決め(contract)モデルにおいても、それが正確かつ十分詳細であることを確かめて契約を行い、維持するには、多くの場合それなりの資源が必要です。ここでの目的は、XPの「身軽な旅」という原則に従って、システムの取り決めモデルの数を最低限にすることです。ほとんどいつでも、取り決めモデルは電子ツールを使って作成した方がいいでしょう。このモデルは時間が経つにつれて保守する必要があるためです。
  • 話すためにモデリングしよう:モデリングを行う第2の目的は、チーム外部の人とコミュニケーションしたり、取り決めモデルを作成したりすることです。いくつかのモデルの利用者はチーム外の人なので、ワードプロセッサやお絵かきツール、あるいは高度なモデリングツールといった電子ツールを使い、時間をかけてモデルをきれいに整える必要があるかもしれません。
  • 理解するためにモデリングしよう:モデルを適用するもっとも重要な目的は、問題空間を検討したり、システムの要求を識別・分析したり、いくつかの設計案を比較して要求を満たす中でどれがもっとも簡潔な解決策になりそうかを判断したりすることです。このプラクティスを実行することで、クラスのライフサイクルや画面間のフロー、目的を果たせば捨ててしまうダイアグラムといった、ソフトウェアの1つの側面に焦点を当てた小さく簡潔なダイアグラムを作成することができます。
  • 既にある資源を再利用しよう:アジャイルなモデリングを行うときに利用できる情報は豊富にあります。 たとえば、いくつかのアナリシスパターンやデザインパターンは、システムに控えめに適用できるでしょう。あるいは、既存の企業レベルの要求モデルやビジネスプロセスモデル、物理データモデル、もしかするとユーザコミュニティ内にシステムが現在どのように配置されているかというモデルまで、利用できるかもしれません。もちろん、多くの組織ではこれらのモデルは存在しなかったり古くなっているかもしれませんが、少し調査をすればそれなりに正確なモデルを見つけ出せることも多いのです。
  • 困ったときだけ更新しよう:モデルの更新は、本当に必要になったとき、モデルを更新する手間より更新しない場合の問題の方が大きいときにだけ行うべきです。この方針を取ることで、以前ほど多くのモデルを更新していないことに気がつくでしょう。実際のところ、モデルが価値を持つためには完璧である必要はないからです。私が持っている自分の町の街路地図は5年以上も前のものです。なぜそれを知っているかといえば、5年少し前にできた私の住んでいる通りがそこには載っていないからですが、それでもその地図は私の役に立っています。もちろん、毎年発行されている新しい地図を買うこともできますが、なぜわざわざ買わなければならないのでしょう。2、3の通りが載っていなくてもそれほど困りはしません。手持ちのもので十分間に合うのに、毎年お金をかけて新しい地図を買う意味がないだけです。モデルや文書とソースコードとの同期を取るために、多くの時間やお金が費やされすぎています。そもそもそれは不可能な仕事であり、その分の時間やお金は新しいソフトウェアを開発するのに使った方が有効なのです。

とても役に立つ考え方

以下のプラクティスはAMを補足するものですが、AMの一部として明示的には含まなかったものです。

  • リファクタリング:これは、新しい要求をサポートしたり設計をできるだけ簡潔にしたりするために、リファクタリングと呼ばれる小さな変更をコードに加えるというコーディングプラクティスです。 AMの視点から言うと、このプラクティスを行うことで、コーディングを進めながら設計をきちんとしたものに保つことができます。リファクタリングはXPの必須部分です。
  • テストファーストデザイン:これは、まずテストケースを考え、それをコーディングしてから、ビジネスコードを書くという開発プラクティスです。AMの視点から言うと、このプラクティスを行うことで、コードを書く前に必ず設計をじっくり考えることになり、詳細設計モデリングが必要なくなります。テストファーストデザインはXPの必須部分です。