2月の Developers Summit 2005 の講演のため来日されたスコット・アンブラー( Scott Ambler )さんにインタビューを実施しました。本編では、9月号のインタビュー前編に続き、スコット・アンブラーさんへのインタビューの後編をお送りします。
(前編を読まれていない方々のための補足)スコット・アンブラーさんは、カナダのトロント在住のコンサルタントで Ronin International というコンサルティング会社の経営者です。同時に、Java プログラミング, EJB, オブジェクト指向方法論、オブジェクト指向開発プロセス等の分野でのコンサルティングや書籍の執筆を行ったりするなど広範な活動を展開されている方です。
今回のインタビューで伺った内容は、以下の内容です。
モデラーに必要な資質

–モデラーにとって一番重要な資質は何だと思われますか?
うーん、そうですね。まず、構造的な思考にもとづくモデルが作れなければなりません。
それから、一緒に働く他の方々とコミュニケーションができなければなりません。何かをモデリングする時に、相手が何を望んでいるのか理解していれば、相手にとって価値のあるモデルを作ることができます。もし、コミュニケーションスキルが十分でなければ、決して使われることのないモデルを作ってしまうかもしれません。
そして、フレキシブルでなければなりません。また、なぜモデルが必要なのかを知っていなければなりません。
私は、多くのすぐれたデータモデラーが、このような質問に対して「すぐれたデータモデリングのスキル」と答えるのを見てきました。しかし、それは間違いだと思います。例えば、ハンマーの使い方しか知らない大工を考えてみてください。彼はハンマーを使って釘を打たせれば超一流かもしれません。しかし、釘を打つこと以外の大工仕事に関してはひどいものです。こういう人は向いていません。こういうことは、何か専門的な領域に特化した仕事をしている方々に起こりがちなことです。ハンマーで釘を打つのは得意なのかもしれませんが、大工としては三流以下です。良いモデラーは、データモデル、ユースケース、ユーザーストーリー、シーケンスダイアグラム、ユーザーインターフェースダイアグラムなどを作ることができなければなりません。そして、例えばハンマーと釘のような、その仕事にあった道具を使うこともできなければなりません。
多くの組織は、従業員の仕事を極端に専門化しすぎることにより、多くのものを失っています。私は、これは危険な傾向だと思います。仕事が極度に専門化されたとはいえ、開発者は自分の専門分野以外の多くの仕事をこなさなければなりません(*1)。これが、エクストリームプログラマで構成されたチームが、伝統的な開発者の20~30人のチームより、より多くの仕事をこなし、かつ高品質のソフトウェアを作ることができる理由です。
なぜなら、伝統的な開発者達は同じ仕事を重複して行ないます。情報を失うことを恐れるために同じ情報を複数の開発者が別々のドキュメントに記述してしまいがちですし、トレーサビリティやレビューの問題も発生します。
つまり、モデラーは広い範囲のスキルを持つ必要があるということです。いくら何十年もの経験をもつ優れたデータモデラーであっても、プロフェッショナルとして働くためには、データモデリング以外の幅広いスキルを持っていなければ、モデラーとしては失格だと思います。
–どのようにすればそのような幅広く高いスキルを習得することができるのでしょうか?
とにかくやってみることですね。他の人と一緒に学ぶ働くのが一番よい学習方法でしょう。
例えば、あなたがプログラマーだったとします。私が、Javaプログラマーとしてのスキルを向上させたいのであれば、あなたと一緒に働いたり、ペアプログラミングをすればよいのです。私のスキルはすぐに向上するでしょう。
また、もし、あなたがデータモデリングやデータベース関連のことについて学びたいのであれば、私と一緒に働くというのは、たぶん良いアイデアでしょう。データモデリングやデータベースに関する知識がすぐに身につくでしょう。
これは、アジャイルコミュニティがもっともよく理解していることのひとつであると思います。アジャイルになるということは短期間で幅広いスキルを身につけるということでもあるのです。単に本を読んだり、優秀な人々は日常的にたくさん本を読んでいると思いますが、トレーニングのコースを受講したりといった、日常的な学習だけでは十分ではありません。アジャイルチームの中で他人と一緒に学んでいくということも重要です。これは、組織がアジャイルアプローチを採用すべき理由の一つであると思います。
–どのようなモデリングのアプローチをとっておられますか?
状況によりますね。RUP を使ったプロジェクトでは、通常、ユースケースドリブンのアプローチを取りますし、XP を使ったプロジェクトではユーザーストーリーや CRC カードやスケッチなどを使います。もし、データモデルを理解したいのであれば、データモデリングを行なうでしょうし。プロジェクトによりますね。
例えば、あなたの会社がJavaアプリケーションを開発していたとしましょう。あなたのチームは、Java や UML を使っています。また、他のチームはデータウェアハウスをやっているので、データモデリングをおこなっているとします。もし、そのような異なる領域のチームと一緒に仕事をする場合は、自分の得意な方法ではなく、別のアプローチを取らなければならない場合もあるでしょう。
–データモデラーはオブジェクトモデリングができないと言う人たちもいますが、どう思われますか?
個人に依存すると思います。
データモデリングのスキルしかもっていない人はオブジェクトモデラーにはなれません。なぜなら彼らは問題領域の全体を見ないのです。いきなり、データや振る舞いを別々に探してしまい、それらをまったく関係のないものだと見なしてしまいます。
さらに、オブジェクトモデリングを行なうためにはオブジェクトデザイン、デザインパターン、アーキテクチャパターン、アナリシスパターンなどについて理解していなければなりません。
単なるデータモデラーであれば、いくら膨大なスキルをもっていても、たぶん、よくないオブジェクトモデルを作ってしまうでしょうね。
いずれにせよ、一人でモデリングするのはよくないやり方ですね。アジャイルモデリングには、「他の人と一緒にモデリングしよう」というプラクティスがあります。これはペアプログラミングのようにモデリングを行なうというプラクティスです。人間は間違いを犯すものでなので、自分一人でモデリングを行なうべきではありません。2、3人で一緒にモデリングを行なえば、たとえ単なるデータモデラーであってもより良いオブジェクトモデルを作ることができるでしょう。
–J2EEアプリケーション開発者の中には、オブジェクト指向ではなく、データ中心アプローチを使ったほうが良いと考える人たちもいます。おそらく、オブジェクト指向を使いこなせる高いスキルをもった開発者を集めるのは大変なので、データ中心アプローチに逆戻りしたいと考えているのではないかと思うのですが、この傾向についてはどう思われますか?
プロセスではなく、ヒューマンリソースの問題ですね。
COBOLプログラマーには、J2EEの仕事はできないでしょうし。J2EE、.NET あるいは COBOL のプロジェクトであれ、テクノロジーをきちんと理解した人を巻き込む必要があります。そして、できれば、その分野の経験がない方々を教育できるといいんですけどね。
■ プロセスパターンがパターンの先駆け?

–スコットさんはプロセスパターン[4]についての本を書かれていますが、なぜもっと一般的な設計に関するパターンではなく、プロセスに関するパターンを書こうと思われたのですか?
プロセス本についてですね。プロセスについての面白い話は、パターンコミュニティはデザインパターンよりも前にプロセスパターンに取り組んでいたことです(*2)。
最初にデザインパターンが成功して、パターンはポピュラーになりました。そう、たしか1995年にGoFのデザインパターンが出版されてからです。そのため、デザインパターン、アーキテクチャパターンプログラミング、イディオムなどのテクノロジーに関するパターンの方に人々の関心が集中してしまいました。
しかし、歴史をひもとけば、オリジナルのパターングループにいた Ward Cunningham (*3) や Norm Kerth (*4)、Jim Coplien (*5) のような人々はプロセスパターンに注目していたのです。例えば、Jim Coplien は組織パターンを書いていますよね。
私は、プロセスにかかわる仕事をしていたので、プロセスについてパターン形式で書こうと思ったのです。
(*4) 訳注: Norm Kerth 氏は、アジャイルの文脈で有名な retrospective の著者。
(*5) 訳注: Jim Coplien 氏は 「C++プログラミングの筋と定石」や「マルチパラダイムデザイン」などで有名。
–そういう歴史があるとは知りませんでした。
私たちの業界は歴史を語ることに、それほど熱心ではありませんからね。
–北米では、プロセスパターンはポピュラーなのでしょうか?
残念ながら、そうでもありません。
しかし、中国ではこの本は大変ポピュラーなのです。二、三年前に翻訳され、今では他にもプロセスパターンに関する本があるはずです。理由はよくわかりませんね。なんとも不思議な話です。
Jim Coplien は、プロセスパターンや組織パターンの作業をおこなっていますが、まだ、成功したとは言えませんね。
– 日本でも状況は同じです。Jim Coplien の組織パターンや Ward Cunningham の Episode などが、一部の人に注目されているだけです。
Linda Rising (*6) も、この分野でよい仕事をしていますね。
■ Ronin International とプライベート

–Ronin International の名前の由来を教えてください。日本文化に関係するのでしょうか?
この名前をつけたのは私のアイデアです。私は、沖縄剛柔空手を学んでいましたから、日本文化に馴染みが深いのです。
実は最初は「Open Kimono」という名前でした。カナダでは、Open Kimono は「正直で信頼に値する」という意味なのです。だから、新しい会社の名前としてふさわしいと思ったのです。
ところが、私たちの最初のお客さんは、米国のバイブルベルトに住む信心深い方々でした。我々は、そのお客さんと一緒に仕事をしたいと思っていたのですが、「Open Kimono」という会社名は望ましくないと言われたのです。彼らは、人前で着物を開いたりする露出狂だと感じるようなのです。
それで名前を変えました。二番目の選択肢が「Ronin」でした。日本以外では、Ronin は、君主につかえず人々を助ける侍というイメージで捉えられています。日本では、無職の人という意味ですけど。当時、アメリカの経済状況は非常に悪くなってきており、今週はここで、翌週は家で仕事をしてということが続いていました。そこで、浪人みたいな生活をしているというちょっとしたユーモアも含めて、Roninという名前をつけたのです。
–あなたは色々な国、ブラジルやオーストラリア、ニュージランドなどで働かれていますが、各国の開発スタイルや文化に違いを感じましたか?
ええ、もちろんです。文化によってまったく異なりますからね。例えば、北米やカナダと比較してヨーロッパでXPを実践するのは少し難しい状況です。北米やカナダと比較すると、ヨーロッパの人々はより個人主義的ですから。彼らには、自分一人で素晴らしい仕事を成し遂げる文化があります。優れた仕事をするのですが、他の人と一緒というのは難しいようです。
アメリカ人は先進的なことを好みますし、カナダ人はもっと保守的です。カナダ人は色々な面で、アメリカ人よりは日本人に近いかもしれませんね。
そうそう、ブラジルでは非常に優秀な人達に会いました。彼らは本当に素晴らしい仕事をしてくれましたよ。
–これが最後の質問です。前回のインタビューと同じ質問なのですが、最近はどのような本や技術に興味を持っておられますか。
本に関していえばプロセスに関する本ですね。技術書以外ではサイエンスフィクションが好きです。
テクノロジーに関して言えば、最近は Microsoft Visual Studio に興味があります。私は Java を長くやってきました。JavaやEclipseは素晴らしいのですが、Eclipseのようなオープンソースソフトウェアの進歩は早すぎますね。追いかけていくのは骨がおれますよ。Microsoft のツールも素晴らしいですね。Java プログラマも .NET プログラマもお互いに相手のやっていることに、もっと興味を持つべきです。
そのほかに関心をもっているのはAOPでしょうか。ずっと関心を持ち続けています。非常に優れた技術ですが、制限もあり、いつ頃から一般的に使われるようになるのか、まだよくわかりません。いずれ、アスペクト指向の本を書くかもしれませんね。
–本日はありがとうございました。
■ 参考文献
本インタビュー記事をまとめるにあたり、以下の文献を参考にしました。
- [1] スコット・アンブラー: アジャイルモデリング-XPとUPを補完するプラクティス, 翔泳社, 2003
- [2] スコット・アンブラー: オブジェクト開発の神髄~UML 2.0を使ったアジャイルモデル駆動開発のすべて, 日経BP出版センター, 2005
- [3] フィリップ・クルーシュテン: ラショナル統一プロセス入門(第 3 版), 株式会社アスキー, 2004
- [4] Scott Ambler, Barbara Hanscome , Barry McGibbon: Process Patterns : Building Large-Scale Systems Using Object Technology, Cambridge University Press, 1998
- [5] Scott Ambler, John Nalbone, Michael J. Vizdos: Enterprise Unified Process : Extending The Rational Unified Process, Prentice Hall, 2005
- [6] Scott Ambler : Agile Database Techniques : Effective Strategies for the Agile Software Developer, John Wiley & Sons, 2003
- [7] EUP 日本語リソース (https://www.ogis-ri.co.jp/otc/swec/process/eup-res/eup/)
- [8] AM 日本語リソース (https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/)
- [9] Enterprise Unified Process (EUP) Home Page (https://www.enterpriseunifiedprocess.com/)
- [10] Agile Modeling (AM) Home Page (https://www.agilemodeling.com/)
- [11] Agile Data Home Page (https://www.agiledata.org/)
アジャイルモデリング~XPと統一プロセスを補完するプラクティス~ 読者プレゼント
Scott Amber さんのサイン入りの『アジャイルモデリング~XPと統一プロセスを補完するプラクティス~ 』抽選で 1名 の方にプレゼントいたします。
ご希望の方は、以下の内容を明記の上、メールの Subject に「アジャイルモデリング プレゼント係」と書いて OOSQUARE-EDITOR@ogis-ri.co.jp 宛にお送りください。
- お名前
- 郵便番号
- ご住所
- 電話番号
- 現在注目している技術や関心のあること
- 「オブジェクトの広場」で読んでみたい記事
締め切りは、2005 年 10 月 31 日まで。当選者の発表はご本人宛にメールにてお知らせいたします。
たくさんのご応募ありがとうございました。
抽選の結果、当選された方には 11/18 までに案内メールをお送りいたします。
(2005/11/01)