アジャイルモデリングが意味をなす（なさない）のはどのようなときか?

目次:

どのようなときにAMが有効であるか?

条件が揃わない場合

どのようなときにAMが有効でないか?

どのようなときにアジャイルモデリングが有効であるか?

アジャイルモデリングは、誰にでも役に立つものではなく、どんな状況にでも効く万能薬ではありません。  また、条件が揃っている場合でも、役に立つことが保証されているわけではありません。組織内でAMを実装するときに間違いをすることもあります。  それでも私の経験では、以下の条件があてはまる場合にAMは効果を発揮する可能性があります。

1.      ソフトウェア開発に対するアジャイルなアプローチを採用している。  AMは完全な方法論ではなく、別のプロセスの範囲内で適用されることを想定して作られています。  AMを用いて成功するには、AMとそのプロセスが概念的に調和している必要があります。そうでなければ、AMの技法のいくつかが自由に使えなくなり、本当にAMを実践しているとはいえなくなります。

2.      反復的かつインクリメンタルに開発を進めている。  AMのプラクティスの2つである効果的なコミュニケーションおよびフィードバックを行うには、反復的かつインクリメンタルな方法でソフトウェア開発を行う必要があります。

3.      要求が不明確で、定まらない。  The New MethodologyのMartin Fowlerは、調査的な性格を持つプロジェクトの場合(多くのプロジェクトがそうですが)には、機敏(agile)な開発方法がもっとも適しているだろうと指摘します。  要求が確定していない場合や頻繁に変わる場合には、それに応じたソフトウェアプロセスを採用する必要があります。  AMは変化を受け入れることで変化する要求に対処します。また、インクリメンタルな方法で開発して、素早いフィードバックを求め、プロジェクトの利害関係者の積極的な参加を促すことで、要求を素早く効果的に調べられるようになっています。

4.      第1のゴールはソフトウェアの開発である。  これはAMの基本原則の1つですが、多くのプロジェクトに必ずしもあてはまるとは限りません。  たとえば、プロジェクトチームの主目的は、顧客から金をもうけることであったり(特にアウトソーシングの場合)、実装担当の別のチームに渡せるようシステムを仕様化することだけだったりします。  さらにひどい場合には、何かを行った証拠が欲しいだけでそれ以上のものを納品するつもりもないのに、政治的な目的だけで開発を行うこともあります。  ソフトウェア開発の目的は、ユーザのニーズを満たすシステムを効果的に作成することであるべきです。そうでなければ、AMを用いる必要はありません。

5.      利害関係者は積極的に援助し、参加する必要がある。  Fowlerは、アジャイル（機敏）なソフトウェア開発を成功させるには、プロジェクトの利害関係者に積極的に援助し、参加してもらう必要があるとも述べています。プロジェクトの利害関係者とは、ソフトウェアプロジェクトの開発や導入によって影響を受ける可能性がある人すべてです。直接/間接のユーザ、マネージャ、課長、上級の管理職、運用担当者、サポート(ヘルプデスク)担当者、テスト担当者、そのシステムと統合/相互作用する他システムの開発者、保守の専門家が含まれます。  AMを使って開発を成功させるには、プロジェクトの利害関係者が誰かを知る必要があります。また、タイミングよく情報を提供し決定を行うことができて、プロジェクトの管理を完全にサポートしてくれるプロジェクトの利害関係者に、毎日接することができなければなりません。

6.      開発チームは己の運命を左右できなければならない。  アジャイルなソフトウェア開発、特にアジャイルモデリングは、ほとんどの組織にとって未経験です。  アジャイルな方法はほとんどの人がきわめて不慣れなため、それを採用することは、多くの組織にとってどのみち大変です。  私の経験からいうと、成功するには、自分自身の責任で成功または失敗する機会をプロジェクトチームに与える必要があります。  プロジェクトチームは、新しい技法を試し、時間を含めたリソースを与えられ、自分自身で進むことができなければなりません。  取り巻く組織からの影響は最低限にしなければなりません。つまり、組織の経営陣や他グループは邪魔にならないようにする必要があります。 

7.      AMの真の擁護者が存在する。  何か新しいものを採用する場合には、必ず難題が持ち上がるものです。  人は変化を好まないため、慣れ親しんだアジャイルでない方法で満足している場合も多くあります。  また、ものの考え方が違うこともあれば、AMで対処しようとしている問題点を認識していないだけのこともあります。  自分のお気に入りの、AMにうまく適合しない開発方法を促進しているのかもしれません。  AMによって組織内の現在の権力構造が変わることを恐れているのかもしれません。  状況にかかわらず、変化に反抗する人々は必ず存在します。  変化の導入を成功させるには、新しい試み、つまりこの場合はAMの採用を擁護する人、進んでプロジェクトの利害関係者の協力を取り付け、組織内に根を張るまでAMの動きを保護し、育ててくれる人が必要です。  変化には時間がかかります。擁護者はその時間を稼いでくれるのです。

8.      責任感と意欲のある開発者が必要である。  Fowlerは、アジャイルなソフトウェア開発を行うためには、高品質のソフトウェアを協力して開発する訓練を受けた開発者が必要だと指摘しています。つまり、開発を成功させるには、互いに信頼し、助け合うという健全なチーム環境が必要です。アジャイルな開発を中傷する人の多くの主張とは逆に、私の経験では、水上歩行のできるメンバーは必要ありません。仕事をやり終えたいと願い、周りと効果的に協力できる開発者がいればよいのです。

9.      適切な資源が利用可能である。  アジャイルモデリングでは、人々が近くで協力して仕事を進める必要があります。  つまり、一緒にいるための場所が必要になります。たとえば、モデリングを行うための専用の部屋や、モデルを掲示するための壁、さらに理想を言えばペア開発をするための共有ワークステーションなどです。  その他、ホワイトボードやインデックスカード、マーカー、それから必要ならCASEツールなどといったモデリングツールを使えなければなりません。  ちゃんとしたいすや机、飲食物、最高のワークステーションといった基本的な資源がないばかりに、ソフトウェア開発作業が大幅に阻害されるのを見たことがあります。  プロジェクトの予算が死ぬほどけちけちしているのなら、そのプロジェクトが組織にとって重要なのかどうかを問わなければなりません。重要でないなら今すぐキャンセルして、もっと生産的なものに労力をかけるべきでしょう。

条件が揃わない場合

では、これらの条件があてはまらない場合はどうすればよいでしょうか。  状況を変えることです。  AMの擁護者がいないのなら、自分が擁護者になってください。  反復的でインクリメンタルな開発が許されていないなら、上司と交渉してよりよい方法があることを納得させ、それを証明するチャンスをくれるよう頼みます。  適切なリソースがないなら、その重要性をマネージャに伝えてください。  できるだけ状況を変えてみた後で、それでもいくつかの要因が欠けているなら、次の選択肢の中からどれかを選ぶ必要があります。

1.      部分的にAMを取り入れる。  できるだけ多くの原則およびプラクティスを取り入れることができます。忠実にAMを実施していることにはなりませんが、開発はより生産的になるでしょう。  ソフトウェア開発のよりよい方法があることに組織が気付けば、AMを完全に取り入れるために必要な条件を揃えるのにもっと熱心になるかもしれません。  つまり、徐々にアジャイルモデリングを導入するわけです。

2.      組織内へのAMを取り入れるのをあきらめる。  個人的には好きではありませんが、これも十分妥当な選択肢であることは認めなければなりません。  現実に、AMは万人向けのものではなく、単にAMがその組織に向いていないだけかもしれません。

3.      他で職を探す。  ソフトウェア開発ゲームで成功したいと思っている組織、意欲を持ったソフトウェア開発者を喜んで雇おうという組織は他にたくさんあります。 

どのようなときにアジャイルモデリングが有効でないか?

次のような場合には、AMを導入しても問題が発生するのではないかと思います。

1. 上記の条件のうち1つ以上が揃わない。 

2. 組織の文化がよりきっちりと定められたプロセスに適応している。  ソフトウェア開発にアジャイルな方法を持ち込むことに単に興味のない組織はたくさんあります。  これらの組織は現状に満足しており、彼らにはそれでよいのです。  これにはおそらく、行政機関や安定した大企業(銀行、保険会社、電話会社など)、そしてこれらの企業へのサービスに特化したコンサルティング会社などの組織が含まれるでしょう。これらの組織にAMを採用するのは不可能だというつもりはありませんが、そこで成功するには会社から離れて作業を行うなど特別な努力が必要になるかもしれません。 

3. チームが大規模である、あるいは地理的に分散している。  アジャイルモデリングは、同じ作業場所に集まっているチームには大変有効です。開発者が共同の仕事部屋(よく「タイガーチーム」部屋と呼ばれます)にいる場合には特に有効です。  大規模あるいは分散したチームにAMを適用してみることは可能で、私はまさにこの状況についてアーキテクチャモデリングで論じていますが、すぐにコミュニケーションの問題が立ちはだかることでしょう。 

また、航空交通管制システムや医療監視システムといった、生命に関わるシステムの開発にアジャイルモデリングを適用することには私は慎重ですが、それは単に私がそれらのプロジェクトに参加したことがなく、AMがどれだけ効果的か見当がつかないからです。  同様に、私は組込みソフトウェアの経験もないため、AMの技法をその種のプロジェクトに適用したことがありません。  AMは組込みソフトウェア開発にも適用できるだろうと思いますが、それは私の推測でしかありません。  このようなシステムでのみなさんの経験を、アジャイルモデリングメーリングリストで聞けるのを楽しみにしています(詳しくはhttp://www.agilemodeling.com/feedback.htmを参照してください)。

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

参考文献および推奨図書

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