モデリング

アジャルにモデリングしませんか

ソフトウエア工学センター

藤井　拓

2002年3月28日

アジャル・モデリングとの出会い

久々の登場です。私が現在所属しているソフトウエア工学センターは、２００１年１月オージス総研に設けられた組織であり、先端的なソフトウエアの開発技術、教材及び教育システムの研究開発を行っています。その中で、私が担当している研究分野は、新たな開発方法論や技術の研究調査とソフトウエア開発の評価技術の開発です。

最近、私が開発方法論や技術の分野で注目しているのは、アジャル（機敏）な開発技術です。その中でも、アジャルに開発を行うためにモデリング技術を活用するための価値、原則、プラクティスを提案しているアジャル・モデリング(Agile Modeling)にもっとも興味を持っています。アジャル・モデリング（以降AMと略）の提案者は、カナダ在住のコンサルタントのスコット・アンブラー（Scott Ambler）さんです。

英和辞典でagileという言葉を引くと、「①すばやい,身軽な；機敏な,(頭の回転が)速い(nimble)、②生き生きして活気のある」という意味が記されています[ジーニアス英和・和英辞典株式会社大修館書店]。アジャイルという発音もできるのですが、アジャルという発音の方がきびきびしているので、本記事ではアジャルと呼ぶことにします*注)。

注) 2002年当時、Agile は日本に広く知れ渡っていませんでした。弊社では Agile を現在広まっている「アジャイル」ではなく、「アジャル」と日本語表記していました。アジャイルの歴史的な歩みを残すことも大事であると考え、アジャルという表記をアジャイルに変更しないまま公開しています。(2015年7月, オブジェクトの広場)

私は、昨年７月頃にUML関連の情報収集を行っている際に、偶然AM公式サイトに遭遇しました。その後、いろいろAMについて評価した結果、AMを研究テーマとして取り上げることを上司に提案し、その提案が承諾されました。そこで、その活動の第１歩として昨年１０月にスコット・アンブラーさんを訪問し、AM公式サイトの翻訳や日本への紹介について協力することを提案しました。　これらの提案に、スコット・アンブラーさんは快く承諾して下さり、以降AMの普及活動の一環としてAM日本語サイトの準備にあたっていました。

社内では、今年に入ってから同僚とともにAMを勉強していこうとしている段階です。AMに対する興味のレベルは同僚の間でもバラバラですが、社内では盛り上がりつつある状況です。私個人は、近い将来お客様に対するコンサルティングやSIに適用できることを目指したいと考えています。

本記事では、AMが生まれたきっかけとなったアジャルな開発技術について簡単に紹介し、AMが解決しようとしている課題について簡単に解説します。また、本記事と同時に公開されるAM日本語サイトについても簡単に紹介します。

アジャルな開発技術

XP(eXtreme Programming)の登場に触発されて、ここ数年ソフトウエア開発をアジャル（機敏）に行うための技術や方法論が米国では盛り上がってきています。アジャルなソフトウエア開発プロセス（方法論）としては、XPを最左翼として、Crystal、Scrum、DSDM等々が提案されています。XPほど過激ではない方法論が登場したことにより、アジャルなソフトウエア開発方法論は今後さらに広範に普及していくことが期待できます。

これらアジャルな開発を支持する人々は、２００１年２月に集い、アジャル・アライアンス（Agile Alliance）というグループを結成しています。アジャルなソフトウエア開発技術を名乗るための４つの価値について合意し、共同宣言を作成しました。この共同宣言は、アジャル・マニフェスト（Agile Manifesto）と呼ばれています。

以下が、アジャル・アライアンスが提唱する４つの価値です。

プロセスやツールよりも個人や相互作用を重んずる
分厚いドキュメントよりも動くソフトウェアを重んずる
契約上の駆け引きよりも顧客との協調を重んずる
計画を硬直的に守ることよりも変化に対応することを重んずる

技術的な観点では、XP、Crystal、Scrum、DSDM等のアジャルな開発方法論はすべて反復型開発プロセスの１種としてみることができます。アジャルな開発方法論独自のテーマは、比較的小規模な開発チームにおいて臨機応変に開発を行うことです。そのような開発を目指した場合、ワークフローを細かく決めたり、中間成果物をいろいろ作るようなオーバヘッドを極力減らした身軽な開発プロセスに行き着きます。さらに、方法論の中身はいろいろな相違点があると思いますが、臨機応変に開発を追求するためには、目的意識を明確に持ち、臨機応変な個人とチームが必要だという結論において一致したのがアジャル・アライアンスを生んだ原動力になったのでしょう。

このようなアジャルな開発方法論の重要性が高まっているのは、以下のようなトレンド（＝筆者の感覚）が背景にあります。

開発の小規模化と短納期化
システム開発の技術や形態の多様化

ここ１０年間を考えても、大型の開発案件というのはだんだん減少し、小規模案件が増大し、開発期間もどんどん短くなって来ています。また、新しい開発技術がどんどん出現し、システムの実現形態の選択肢も増えてきています。そのような状況が進むにつれて、“言われるがままに作れば良い”あるいは“お仕着せのものを提供する”だけでは、付加価値を認めてもらうことはますます困難になるでしょう。結局、小規模、短納期の開発プロジェクトにおいて費用対効果という観点で“値打ちのある”システムを提供することが厳しく問われるようになってきているのではないでしょうか。

アジャルな開発方法論とは、技術力を背景にして、小規模、短納期の開発プロジェクトにおいて値打ちのあるシステムを提供するための方法論だと言えるでしょう。また、要求が不明確な開発案件や技術的な難易度の高い開発プロジェクトにも、アジャルな開発方法論が有効だと考えられます。

このようなアジャル・アライアンスの価値に共鳴し、このような価値に基づくモデリング技術の活用方法として考案されたのがAMです。

なぜアジャル・モデリングか

AMとは、モデリング作業を効果的に実行するための価値、原則、プラクティスを集めたものです。AMの価値は、XPの４つの価値に“謙虚さ”を加えたものです。原則やプラクティスのレベルでは、AMの独自性がより強く感じられます。AMは, モデリング作業だけに特化したものであり、他のアジャルな方法論をモデリング作業という観点で補完するためのものです。AM自身は、開発プロセスに対しては中立的であり、統一プロセス系統の開発プロセスに対して適用することもできると述べられています。

AMの大きなテーマは、モデリング作業と機敏な開発をどのように両立させるかということです。すなわち、モデルを作成するオーバヘッドを減らすことや共同作業を効率化させる手段としてどのようにモデリングを行うべきかということが問われています。そのことに対するAMの回答の一つは、“モデル”の位置付けを変えるということです。

従来、モデルは“詳細、正確、きれい”であるべきだという固定観念がつき物だったのに対して、AMは“詳細、正確、きれい”であることに拘らないことに第１の特徴があります。その理由は、２点あります。

“詳細、正確、きれい”にすることの意義が少ない
モデルを“発想や対話の手段”として利用する

モデリング作業者と実装作業者が分業を行っているプロジェクトでは、モデルを“詳細、正確、きれい”にする意義があるでしょう。しかし、そうではないプロジェクトでは“詳細、正確、きれい”に拘ることは、オーバヘッドに比べて得るところが少ないというのが１）の主張です。この考えをさらに推し進めると、“モデルは基本的には開発成果物ではない”という考えに行き着きます。すなわち、開発成果物であれば、種々の変更の度ごとにこまめに保守を行う必要がありますが、モデルを一律にそのような開発成果物として扱う必要はないということです。結局、AMはモデリング作業において必要以上に労力を費やすことを戒めることで、モデリング作業のオーバヘッドを軽減しようとしているのです。

ここで、注意しなければならないのはUMLモデリングツールの位置付けです。AMは、モデリングツール自身を使うことがオーバヘッドにならなければ、モデリングツールの利用は推奨しています。その一方で、コード生成を行うことが最終目的でなければモデリングツールを使う必然性は低いとし、白板、インデックスカード、デジカメ等々の簡単な道具を用いてモデリングを行えば良いという立場です。

また、“対話の手段”とは、“何か合意するためにモデリングを行う”ことであり、“発想の手段”というのは“考えを書き表してみることで新たな発想を得る”ことです。筆者もそうですが、モデリングを行う人はとかく“孤独”に作業を行うことを好む傾向があります。そのように孤独にモデリングを行うと、意外とつまらないことで作業が進まなかったり、各自が分担しているモデルが不均一になったりします。そのような孤独なモデリング作業と対照的なのは共同作業を通じたモデリングです。共同作業を通じたモデリングにより、個人作業で悩んでいた点が解決したり、新たな発想が生まれる可能性があります。

うまい喩えかどうか分かりませんが、オーケストラがうまく演奏するためには各パートの正確な楽譜を予め配る必要があり、指揮者が必要ですが、ジャズバンドがアドリブ演奏をするためには何らかのテーマが必要であっても、楽譜や指揮者は必要でないという喩えを考えることができるでしょう。AMとは、究極的にはこのようなアドリブ演奏ができるジャズ演奏者のようなモデリング技術者を目指すものだと言えます。そのためには、一人で孤独にモデリングできるモデリングスキルだけでは不十分であり、顧客や開発者のグループの共同作業を進めるためのグループワークのスキルや組織風土がある程度要求されるでしょう。

もっと現実的なレベルで考えると、AMの共同作業は、“ある程度の完成度に達したモデルのあら捜し”ではなく、“より完成度の低い段階でモデルを持ち寄り共同作業により不明点を詰めていく”イメージに近いかもしれません。一人で孤独にモデリングした方が個人レベルでは効率的かもしれませんが、共同作業を行った方がチームとしての開発はよりうまく進行するのではないでしょうかというのがAMのメッセージです。

また、モデルの情報をプロジェクトメンバーが共有することも重要になります。このような意図で、AMには共同作業を通じたモデリングやモデルの情報の共有を促すプラクティスが組み込まれています。

AMのもう一つの大きな特徴は、“複数のモデリングテクニックの併用を推奨している”点ですが、この点については紙面を改めて紹介しようと思います。AMで推奨するモデリング記法は、UMLだけではありません。UMLは、人間とコンピュータの双方が扱えるという利点がありますが、開発に必要な情報の１部しか表現できなかったり、共同作業を迅速に行うのには適さない点もあります。そのようなUMLの不十分点をどのように克服するかという点でも、AMは注目に値します。

AMの価値、原則、プラクティスの詳細については、本記事と同時に公開されたアジャル・モデリング日本語サイトに記されていますので、そちらをご参照ください。

アジャル・モデリング日本語サイトについて

アジャル・モデリング日本語サイトで今回公開するドキュメントは、以下の８ページです。

アジャル・モデリング(AM)公式サイトのホーム
アジャル・モデリング(AM)の価値
アジャル・モデリング(AM)の原則
アジャル・モデリング(AM)のプラクティス
アジャル・モデリング(AM)とは何か？（エッセイ）
どのようなモデルがアジャルか？（エッセイ）
アジャル・モデリングが意味をなす（なさない）のはどのようなときか？（エッセイ）
AMについて

現段階では、未訳のページが多いのですが、それら未訳のページに対するリンクは本家のAMサイトへのリンクとなっています。その点にご注意くださるようお願いいたします。

今後、AM関連の訳語についてはいろいろな方々からの意見を参考に見直していくつもりです。その点についてご了承くださるようにお願いします。

今後の予定

今後、順次AM日本語サイトの日本語ページを充実させていったり、AM関連の情報をオブジェクトの広場に掲載する予定です。また、来る６月より提供が開始される予定の ObjectDay2002 のストリーミング用コンテンツとしてスコット・アンブラーさんのプレゼン“Introduction to Agile Modeling（アジャル・モデリング入門）”の提供を予定しております。乞うご期待を！

余談

AMは、２００１年２月以前にはXM(eXtreme Modeling)と呼ばれていました。昨年７月頃にAMサイトと遭遇した際に、GoogleでAMやXMに関する日本語の情報を検索してみました。XMで数件ヒットしたのですが、その中の１件がオブジェクトデザイン研究所の河合さんのページでした。なかなか着眼が早いと感心しました。

参考文献

Webサイト

Agile Modeling公式サイト: https://www.agilemodeling.com/
Agile Modeling日本語サイト: https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/