私がAgile Develop Conferenceの最初に参加したセッションは Scott W.Amblerの「アジャイルモデリングからアジャイルデータテクニックへ」 というとても興味深いセッションでした。 Scott W. Ambler氏はAgile Modelingで有名ですが、EJB使いのMastering EJBなどでも名前を見かけますし、 幅広い守備範囲と現実的なアプローチを持った面白い人だと思って注目しています。 彼自身は「Agile Modeling」「Software Mentoring」 「Object/Component Development Mentoring」のコンサルタントだと答えています。

セッションが始まったときにアンブラー氏にサインをもらいました。 なんと彼のセッションには１０名足らずの出席者しかいなかったので、とても得をした気分になりました。 彼は私が日本からきたことを告げると「Taku（藤井さんのことです)を知っているか？」と聞いてきました。 もちろんだよと答えました。

今回のカンファレンスでは興味深いセッションが目白押しでどのセッションを選ぶかは大変難しいことでした。
さて、セッションの内容ですが、彼の著作に関しての報告がありました。 このセッションの名前にもでてくるとおり、今度の秋に出版される興味深い書籍に 『Agile Database Techinques』 という書籍があります。これは要注目だと思います。 また、私はまだ読んでないので、どんな内容かはわかりませんが 『Object Primer： Agile Modeling-Driven Development With Uml 2.0    3rd Edition』 という本も同時期に発売されるようです。

セッションの内容

• 「ラディカル」なアイデア
• ソフトウェア開発の現実
• アジャイルモデリング
• アジャイルデータ
• それらを実際にうまくやるには
• 成功の秘訣
• アジャイルを続けよう

最初にお断りしておきますが、私の英語力はたいしたことがないので内容に関しては保証いたしかねます :-)

「ラディカル」なアイデア

　このパートでは彼の基本的な考え方に関して説明しています。

モデルとドキュメントは違う

特に印象深い言葉としては「モデルはドキュメントではない」という話です。 彼は設置されていたホワイトボードの紙バージョンのようなボードにユースケースを書いて 「これはモデルだけど、ドキュメントではない」といっていました。 私の英語の理解力はあまりよいとはいえませんので、間違っているかもしれませんが、 モデルとドキュメントの違いはドキュメントは残すものでモデルはそうじゃないというイメージです。 ＃ドキュメントに関しては後述します。

個人的な意見ですが、モデルはプロジェクトの中で定常的に行って、 「ドキュメント」はある意味プロジェクトの完了までにあればいいと思っています。（例外はありますが）

モデルとドキュメントは有効な使い方をしよう

これは説明はいりませんね。それぞれをうまく使いましょうという話です。 アンブラー氏の説明ではモデルとドキュメントのダイアグラムがでてきました。 下の中で○をつけたものが残すもの「ドキュメント」でほかのものはあくまで「テンポラリ」だという話です。 また、AMDD(Agile Modeling Driven Development)のプロセスでは 「初期要求でのモデリング」「初期のアーキテクチャ」モデリングのあとにイテレーティブに 「詳細なモデリング」と「実装とテスト」を行き来するようなイメージで説明していました。 ただし、最初の２つも「初期の・・・」と説明していることから変わらないものとは考えていないようです。

残すものと残さないものを明確に定義してくれているので、かなり参考になりました。 私も自分のプロジェクトで「Business Rules」を残していなかったので、 これは残しておけばよかったと思っていたところです。

IT産業は「専門化」の害を受けている

　

今までの開発の考え方では、たとえば「分析」「設計」「コード」「テスト」と それぞれ専門化が進んでおり、問題はそれらの分野、たとえば分析者はコードのことを知らないということである。 といっていました。 そしてその専門化の間（たとえば分析と設計）でコミュニケーションギャップが起こっているという話をしていました。 ITもいろいろあるけど、とりあえず技術者は継続的にいろいろ勉強するべきという感じです。

データプロフェッショナルはアジャイルになりうる今回の主眼のひとつの「アジャイルデータ」に関することです。

AMDD(Agile Model Driven Development)はTDD(Test Driven Development)はいっしょに使います。

　

AMDDはモデルを書いてコードという感じではなく、お互い行き来するものなので、 アジャイルモデルをしてコードを書くときにはTDDをするのがお勧めと彼は言っていました。

アジャイルデータ

• アジャイルデータはITプロフェッショナルが組織の中で ソフトウエア開発を行うにあたってのデータに関する哲学のセットである。
• アジャイルデータはアジャイルアライアンスの価値のプリンシプルに沿っている
• AMDDアプローチの開発でうまくいくと思われる（すみません。訳があやしい）
  http://www.agilemodeling.com/essays/amdd.htm

アジャイルモデリングの哲学

　

データ

　　　

データはソフトウェア開発において重要な要素のうちの一つである

　

Enterprise Issue(企業・組織または複雑な仕事の問題）

　　　

エンタープライズグループは、ほかのチームをサポートしないといけない。 また、エンタープライズグループはアジャイルの作法(agile manner)にのっとっている必要がある。

毎回状況は変わる

　　　

プロジェクトごとに状況が違います。

　

いっしょに働こう

　　　

ITプロフェッショナルはいっしょに働きましょう。
（先ほどの専門化の話にも関連していると思います）

　

スイートスポット

　　　

問題のスイートスポットを見つめましょう「白黒はっきりさせる」
じゃなくて、 あなたの状況にもっともうまくいく「灰色」を見つけよう

アジャイルデータの役割

　アジャイルデータでは、いくつかの役割（ロール）がでてきました。
ほかのチームと連携をとったり、プロジェクトを取りまとめるレベルの

• Enterprise Administrators(Data関連の管理者のとりまとめ）
　
• Enterprise Architects(アプリケーション系のとりまとめ）

また開発チームは

　
• AgileDBAs
• Apprication Developer

のそれぞれがコミュニケーションします。
たとえばDBAはデータ（モデルや制限）に関することをアプリケーション開発者に話しますし、 アプリケーション開発者はDBAにアプリケーションに関するモデルや制限を教えます。 これらの４つのロールがお互いやりとりする感じです。

イテレーティブ＆インクリメンタル

アジャイルデータではデータモデルもEvolutionary（進化的）に開発するという話をしていました。 イテレーティブ＆インクリメンタルに実施するものとしては

　
• オブジェクトモデル
　
• データモデル
　
• オブジェクトからデータモデルのマッピング
　
• 実装
　
• リファクタ
　
• パフォーマンスチューニング

という話をしていました。これらをイテレーティブにインクリメンタルに
実施するという話でした。

アジャイルデータベースのテクニック

・データベースリファクタリング（マーチンファウラーのとは別）
　http://www.agiledata.org/essays/databaseRefactoring.html
このURLは今見れる状況でないのでどんな内容かは興味深いのですが、 １例としては、いろいろなアプリがDBにアクセスするようなケース＃Javaだけではなくて COBOLとかほかの言語が混じってるとか、どうするか？という話もしていました。

　
• マッピングテク
• 継続的なユニットテスト
　
• 変更用のスクリプト

これらはあまり説明はなかったですが、とくに要らないと思います。 上記URLにいろいろ書いてあることが期待されます。

オブジェクト指向とデータの問題

このパートではいろいろなオブジェクト指向とデータの問題が説明されています。

　　
• キャッシング
　　
• 同時実行のコントロール
　　
• データベースのアーキテクチャ
　　
• レガシーのデータ
　　
• Referential Integrity
　　
• Versioning object
• カプセル化
　　
• XML,web services,
　　
• O/R　のインピーダンスミスマッチ
　　
• オブジェクト指向技術者とデータ技術者の文化の違い
　　

UPの２つのフェーズの追加

アジャイルデータやアジャイルモデリングはXPやUPといっしょに使うのですが、 　　　　UPの説明のところでフェーズを追加していました。＃XPは同じでした。

私はUPはよく知らないですが、多分新規のフェーズです。

• Production
• Retirement

普通のUPではプロダクトを作って終わりですが、メンテナンスというか、 ２次の機能追加などに相当するのがProductionで、 さらに、そのプロダクトが引退の時期を迎えたときもいろいろするでしょうが？という話がRetirementでした。 たしかになぜかどこにもRetirementに関しては記述がないですよね。

　成功の秘訣

• チームワーク
  　　
  • ほかのチームもしくは人と近くで働くこと
  　　
  • AMやADやアジャイルであることのよさを会社で話をすること。
    ただし、いわゆる信者にはならないこと
• 考えを改めつづけること
  　　
  • ソフトウェア開発に関する考えを考え直せるようにしておくこと
  　　
  • モデルとドキュメントは意味のあるようにしよう
  　　
  • UMLは完全ではない。十分でもない
  　　
  • 全般的なスペシャリストになろう
　
• 教育
  　　
  • 生涯まなぼう
  　　
  • メンタリングをうけよう
  　　
  • 読書・読書・読書
  　　
  • AM、ADのメーリングリストに入ろう

UMLは完全でないに補足をしておくと、先ほどの残すドキュメントの話でもあるとおり、 UMLですべてを表せるわけではありませんし、それですべてを表せるわけではないということを注意しましょうということです。 すべてを残すのではなく「モデリング」のために有効なときにだけ使うだけのものです。