目次:
アジャイルモデリング(AM)は、ソフトウェアに基づくシステムを効果的にモデリングし、文書化するための、プラクティスに基づく方法論です。 簡単に言うと、ソフトウェア開発プロジェクトで適用できる、効果的で手軽にソフトウェアをモデリングするための価値、原則、およびプラクティスを集めたものです。 アジャイル（機敏）なモデルは、目的を達成するうえで「かろうじて使える」だけで十分であり、完璧である必要はないという割り切りのもとで作成されます。その結果、既存のモデルより効率的です。アジャイルモデリングという方法は、要求、分析、アーキテクチャ構築、設計に適用することができます。より詳しくはアジャイルモデリング(AM)とは何か?のエッセイを、今後出版されるアジャイルモデリングに関する書籍についてはこちらを参照してください。
AMは、きっちりと定められたプロセスではありません。つまり、ある種類のモデルを作成するための手順を詳しく定義したものではなく、モデリング担当者として効果的に仕事をするにはどうすればよいかについてのアドバイスなのです。 また、AMは、モデリングの量を減らすためのものではありません。実際、多くの開発者は、AMを導入することで、それまでよりもさらにモデリングを行うことになるでしょう。 AMは実践を通じて会得するものであり、明確で厳重なものではありません。科学(sience)ではなく技能(art)だと考えるとよいかもしれません。
AMでは、Agile Allianceの推進しているアジャイル開発の価値が効果的にモデリングを行うために大事だと考えています。Agile Allianceは、以下のような価値をプロモートしています。
- プロセスやツールよりも個人や相互作用
- 分かりやすいドキュメントよりも動くソフトウェア
- 契約上の駆け引きよりも顧客とのコラボレーション
- 計画を硬直的に守ることよりも変化に対応すること
AMの目的は以下のとおりです。
AMを理解する上で重要なのは、AMが完全なソフトウェアプロセスではないということです。
AMでは効果的なモデリングと文書化に焦点を絞っています。網羅しているのはそれだけです。
コードでモデルを検証するよう主張してはいても、プログラミング作業そのもののプラクティス等は含んでいません。 モデリング時にテスト容易性を考慮するよう推奨してはいても、テスト作業自体のプラクティス等は含まれていません。
さらに、プロジェクト管理やシステムの導入、システムの運用、システムのサポート、あるいはその他の無数の事柄には触れていません。
このように、AMではソフトウェアプロセス全体の一部にしか焦点を当てていないので、AMの目的で述べたように、XPやDSDM、SCRUM、UPといった完全な形のプロセスと併用する必要があります。 図1にこの考え方を示します。
まず、XPやUP、あるいは独自の既存プロセスといった基盤プロセスから始めて、それをAMでカスタマイズし(できればAMのすべてを採用する)、また適切な他の技法を取り込んで、それぞれのニーズに合わせた自分のプロセスを構築します。
図1.
AMによって他のソフトウェアプロセスを補強する
AMの価値は、エクストリームプログラミングの価値を取り入れ、拡張したもので、「コミュニケーション」、「簡潔さ」、「フィードバック」、「勇気」、「謙虚さ」の5つからなります。モデリングを成功させるキーとなるのは、プロジェクトのすべての利害関係者間で効果的なコミュニケーションを行うこと、すべてのニーズを満たす解決策の中でもっとも簡潔なものを開発するよう努力すること、自分の作業に関して頻繁にかつ早期にフィードバックを得ること、決定を下し、それを貫く勇気を持つこと、自分が何でも知っているわけではなく、他のメンバーもプロジェクトに貢献していると認める謙虚さを持つこと、です。
AMはいくつかの原則にもとづいています。たとえば、モデリング時の「簡単なものの採用」、時間の経過とともに実際に要求が変更されたときに「変化を受け入れる」ことなどです。 時間が経つにしたがってシステムに「少しずつ変更」を加えることでアジャイルな開発ができることを認識するべきです。また、プロジェクトの利害関係者のニーズを正しく反映していることを確認するには、作業についての「素早いフィードバック」を得られるよう努力しなければなりません。 「目的を持ってモデリング」を行うことが重要であり、モデリングを行う目的が分からないのなら、そのようなモデリングはするべきではありません。また、効果的に開発を進めるためには、考えるための道具箱の中に「複数のモデル」が必要です。 ここで、モデルは必ずしも開発ドキュメントでなくてもよいという考え方が非常に大事です。これが分かれば、目的を果たした後のモデルのほとんどを捨てて「身軽な旅」をすることができます。 アジャイルなモデル作業者は、「見栄えより中身」であること、同じ概念を多くの方法で、しかもそれぞれ正しくモデリングできることを信じています。効果的にモデリングを行うには、「道具を知る」必要があり、「モデルを知る」必要があります。また、チームのメンバーと効果的に開発を行うには、「誰しも他人から学べる」こと、「直観に従った仕事」をしなければならないこと、「オープンで正直なコミュニケーション」を行うのがたいていは一番有効な方法であることを理解するべきです。 そして、誰もずさんな仕事をしたくはないため「質の高い仕事」を目指すことが大切であり、自分が置かれた環境のニーズに対してAMを正確に「実状に合わせる」ことが重要です。
アジャイルなモデリングをするには、AMのプラクティスを適切に適用しなければなりません。 主要なプラクティスには「複数のモデルを並行して作ろう」、状況に合った「適切な成果物を使おう」、堅実に前進し続けるための「他の成果物に移ろう」があります。 また、アジャイルなモデリングを成功させるためには、「少しずつモデリングしよう」を行い、俗世間から離れて魔法のような「なんでもありのモデル」を作成しようとしないことも重要です。 モデルとはソフトウェアを抽象的に表しただけのものであり、本当に正確に抽象化されているとは限りません。そのため、自分の考えが理論上だけでなく実際にもうまく動くことを、「コードで確かめる」よう努力してください。 モデリング作業を成功させるには「利害関係者の積極的な参加」が不可欠です。というのも、プロジェクトの利害関係者は自分が何を望んでいるかを知っており、開発者に必要なフィードバックを提供することができるためです。 モデルを作成する理由は大きく分けて2つあります。(システムの一部をどう設計するかといった)問題を「理解するためのモデリング」か、チームが何をしているか(あるいはしたか)を「話すためのモデル」のいずれかです。 原則「簡潔さを心がけよう」は、モデリングが必要な側面にだけ焦点を合わせて詳しすぎるモデルは作成しないようにするという「中身はシンプルに作ろう」、単純な表記法だけを使うことによる「モデルをシンプルに描こう」、モデルの作成時の「もっとも簡単な道具を使おう」といったプラクティスによってサポートされています。 「一時的なモデルは捨てよう」や「困ったときだけ更新しよう」ことによって、身軽な旅をすることができます。 部屋の壁あるいは社内のWebサイトへの「モデルを公開しよう」、プロジェクト成果物の「共同所有」、「モデリング標準を使おう」、あるいは「他の人々と一緒にモデリングしよう」によって、コミュニケーションを効果的に行うことができます。 「テストできるか考えよう」、「パターンは控えめに使おう」、「既にある資源を再利用しよう」を行うことで、開発の成果は大きく向上します。 既存データベースやWebベースのシステムなど、他のシステムと統合しなければならないことも多いため、それらのシステムの所有者と「取り決めモデルはきちんと定義しよう」をする必要が生じることもあります。よりよく理解するためにはhow AM's practices fit togetherのエッセイを参照してください。
私が言いたいのは、AMはモデリングに対するアジャイル（機敏）なアプローチであり、その中核部分は経験豊かな多くのソフトウェア開発者が共有する原則や価値を集めただけのものだということです。私の経験では、これらのプラクティスはほとんどのソフトウェア開発プロジェクトに適用することができ、AMで記述した方法を利用するためにアジャイルなソフトウェアプロセス(XPなど)を必ずしも採用する必要はありません。しかし、AMの目的には、XPのアプローチを採用したときにどのようにモデリングをすればよいかを説明することも含まれています。また、AMから利益を得るために、プラクティスや原則、価値をすべて適用する必要はありません(それぞれのプロジェクトが置かれた状況に即したニーズに合わせてソフトウェアプロセスをカスタマイズするべきだと私は固く信じています)。それでも、XPの場合と同様に、AMのすべてを採用した方が成功の確率が高くなるというのが私の持論です。
Scott W. Ambler, Copyright 2001-2003
Senior Consultant, Ronin International, Inc.
|
