2 月の Developers Summit 2005 の講演のため来日されたスコット・アンブラー（ Scott Ambler ）さんにインタビューを実施しました。
インタビューから今回の公開まで半年も期間が空いてしまいましたが、なんとか記事にすることができました。お待たせしてしまいすみませんでした。
オブジェクトの広場では、これまでも何度かスコット・アンブラーさんにインタビューしています。そこで、今回はスコット・アンブラーさんが提唱しているプロセスの 1 つである EUP 1) に焦点を当ててインタビューしました。その様子を、前編・後編に分けてお届けします。
スコット・アンブラーさんは、カナダのトロント在住のコンサルタントで Ronin International というコンサルティング会社の経営者です。同時に、Java プログラミング, EJB , オブジェクト指向方法論、オブジェクト指向開発プロセス等の分野でのコンサルティングや書籍の執筆を行ったりするなど広範な活動を展開されている方です。
今回のインタビューで伺った内容は、以下の内容です。
1) オージス総研では、 EUP 日本語リソースサイトを公開しています。
EUP とは
–まず最初に、EUP について簡単に説明していただけないでしょうか。EUP とは何ですか？
EUP は Enterprise Unified Process の略で、 RUP ( Rational Unified Process ) [3] を拡張したプロセスです。RUP はよくできたソフトウェア開発プロセスですが、単なる開発プロセスにすぎません。今日、ソフトウェアがシステムとして成功するためには、開発だけでなく、ライフサイクル全体を考慮する必要があります。例えば、ソフトウェアがユーザに使われるている稼動 ( Production ) フェーズでは、運用が必要です。また、最終的にシステムをリプレイスしたり、廃棄したりする引退 ( Retirement ) フェーズについても考慮する必要があります。したがって、これらのためにライフサイクルを拡張する必要があるのです。そして、もう一つ我々が認識しておかなければならないのは、ほとんどの組織はたくさんのシステムを抱えているということです。IT を成功させるためには、単一のシステムではなく、それらのシステムについても考慮する必要があります。したがって、エンタープライズアーキテクチャ ( Enterprise Architecture )、ポートフォリオ管理 ( Portfolio Management )、戦略的再利用 ( Strategic Reuse ) などが必要になるのです。
–EUP は、スコットさんがひとりで作成されたのですか？
最初は、私ひとりではじめました。そして、私のソフトウェア開発の経験が反映されたものにすぎませんでした。その後、Ronin International で作業をはじめ、クライアントのところでやったことを反映させています。今は数人でやっています。
–これは私の想像なんですが、スコットさんは他のプロセスには何か問題があると考えられているんですよね？
ええ、その通りです。EUP をはじめたのは、RUP には欠けているものがあるということがわかったからなのです。
以前、"Process Patterns" と “More Process Patterns” という本を書いたのですが、これらは以前、働いていた会社で使っていたプロセスや、私がクライアントのところで使っていたプロセスについての本でした。
その後に、RUP が発表され、私も RUP を使うようになりました。RUP にはソフトウェア開発に関する多くのものが含まれていますし、私の仕事とも重なる部分も多いのです。しかし、RUP と私がやってきた仕事と比較すると、私は RUP の範囲よりもっと多くのことをやっていました。つまり、RUP には私の仕事と比べて、欠けているものがあったのです。
そして、クライアントのところで RUP の導入を助けるうちに、その欠けているものが何か分かりました。彼らは IT のライフサイクルの全体像をとらえたいと思っていたのです。
–何社くらい、EUP を実装されましたか？
私達が実装したのは、たぶん、10 社から 15 社程度です。しかし、私達だけでなく、他の会社も実装していると思いますよ。EUP メーリングリストには、700 人ぐらい購読者がいますからね。メーリングリストはそれほどアクティブではないので、アナウンスを待っていたり、情報収集のために購読している人が多いのでしょう。
EUP を導入するには
–EUP を必要とするクライアントにどのようなサービスを提供しているのでしょうか？
私達の Web サイトやホワイトペーパを見たクライアントが、助けをもとめて私達にコンタクトしてきます。時にはちょっとした仕事、トレーニングやメンタリングをおこなうだけのこともありますが、そういう場合は一人でおこないます。もし、仕事の規模が大きければ、クライアントのニーズにあわせて、RUP の専門家やエンタープライズアーキテクチャの専門家などを探すのです。
–企業が EUP を導入したい場合、まず何から始めればよいでしょうか？
EUP の前に、まず RUP の導入を成功させることから始める必要があると思います。なぜなら、RUP は小さいですし、ソフトウェア開発のためのプロセスだからです。
ソフトウェアの開発に成功したら、その後で運用及びサポート ( Operations & Support ) を試してみるとよいでしょう。EUP を適用するにせよ、しないにせよ、運用及びサポートは必要なことですからね。
また、ひとつのシステムで、EUP の全てをおこなうことはできないでしょうから、多くのシステムのマネジメント、つまりエンタープライズマネジメントを試してみるとよいでしょう。
RUP を導入して、それがうまくいってから EUP に戻ってくるのと良いのですが、そういうやり方を好まない顧客もいます。私たちを呼んで RUP と EUP を導入して欲しいというのです。そういう場合は、まずちょっと試してから、EUPの一部分を試してみて、残りはまた将来といったやり方をとります。
一度にやりすぎないことが重要です。まず小さい範囲で試して、それから大きく広げていくといいでしょう。これが私のアドバイスです。
– RUP は小さいと言われましたが、私は RUP は大きいと思いますよ。
比較の問題です(笑)。RUP は非常に大きいのですが、EUP よりは小さいですよね。EUP の対象とする範囲を見ればわかると思いますが、EUP の大きさは RUP とは桁外れです。EUP がサポートしているのは、IT ライフサイクル全体で、単に開発だけではありませんからね。
–もし、EUP の導入を考えている組織が、XP、アジャイル、あるいはウォータフォールといった開発プロセスを持っている場合、それらの開発プロセスを EUP 導入の最初のステップとみなしても問題ないのでしょうか？
ある顧客のところで、そういう状況に直面したことがあります。非常に大きい組織で、組織内に RUP、XP、そして古典的なウォーターフォール開発プロセスを使ったプロジェクトをいくつも抱えていました。
EUP からみると、開発プロセスが RUP であるかどうかは、それほど大きな大きな問題ではありません。ただ、現実的な話として、RUP は非常によくできた開発プロセスです。もし、ソフトウェア開発プロセスを探しているのであれば、RUP を導入することをお勧めします。
組織が、きちんと定義されたソフトウェア開発プロセス、エンタープライズマネジメント、運用やサポートすべてを必要としているということはよくあります。私たちにコンタクトしてくるのは、そういう組織が多いのです。
実のところ、そのような場合、RUP は主要な選択肢なのです。RUP だけを導入したり、EUP と RUP を導入したりします。
– EUP を使っている人たちは、どのようなツール、例えば Rational Rose のようなツール、を使っておられるのでしょうか？
ツールは大きな問題ではありません。中身が重要なのです。私達の本の中では、ツールを使うことを勧めてはいますが、POPKIN の System Architect を使えとはいっていません。よい選択肢のひとつではありますけど。私たちは、柔軟性が重要だと考えているので、特定のツールに固執はしません。
RUP について言えば、IBM Rational のツールを使わなければならないというわけではありません。RUP をうまく導入するために、IBM Rational のツールを使うことはできますが、必須というわけではありません。これは、みんなが理解しておくべき重要なことです。
–現在の EUP を拡張する具体的な計画はありますか？
今のところはありません。これまで EUP を適用する度に、多くのことを学び、試し、EUP を改善してきましたから。それに、今は新たに EUP を導入しようとしている顧客がいませんからね。
拡張することがあるとすれば、より詳細にすることだと思いますよ。EUP は、私たちの長い間のリサーチの結果なので、欠けているものはないでしょう。本を見てもらえればわかると思いますが、大変長い参考文献のリストがのっているはずです。ほとんどの基本的なものをカバーしています。
EUP とアジャイルモデリング
–アジャイルモデリングを EUP と一緒に使うことはできますか？
もちろん、可能です。実際のプロジェクトで行うアジャイルモデリングの作業や作成する成果物は RUP の一部分であることが多いでしょう。アジャイルモデリングの中で、非常に大きなセクションを設けて、まさに、この事について説明しています。
ビジネスプロセスモデリング、エンタープライズアーキテクチャモデリングなどをアジャイルに行えない理由はありません。私は、最高のエンタープライズアーキテクトはアジャイルに行動していると思います。彼らは常に顧客やビジネスピープル、プロジェクトチームの人々の近くにいます。無駄な書類仕事に時間を費やすかわりに、モデリングしたり、人々とコミュニケートしたり、書類を書いたり、プロジェクトチームの人々と会話し、彼らを助けます。
–エンタープライズアプリケーションを開発する場合、たくさんのドキュメントを作る必要があります。それでもアジャイルと言えるのでしょうか？
ドキュメントを書くことは悪いことではありません。アジャイルモデリングの中で書いているように、アジャイルドキュメントは、辛うじて十分役に立つ 2) 程度のものでなければなりません。したがって、アジャイルといえるかどうかは状況に依存します。
2) “Barely Good Enough” の訳。スコット・アンブラーさんの考えを理解する上でとても重要なキーワード。
ある場合にはホワイトボードのスケッチが辛うじて十分でしょうし、別の場合にはぶ厚いドキュメントや、手の込んだドキュメントが必要な場合もあるでしょう。私が言いたいのは、仕事を完成させるのに十分なドキュメントを書くだけでよいということです。旧来の多くの開発者は、このような考え方に賛同しないだろうとは思いますが。
アジャイルドキュメント、あるいはアジャイルモデルはもっとも効果的なモデル／ドキュメントでなければなりません。もしモデルがまだ辛うじて十分役に立つものでなければ、まだ作業を続けなければなりません。もし、モデルが、辛うじて十分というにはやりすぎた場合は、時間をかけ過ぎたということです。定義によれば、アジャイルモデルは、できる限り最も効果的かつ、最も費用対効果のあるモデルでなければなりません。
難しいのは、辛うじて十分役に立つ程度か判断することです。理想としてはそのようにありたいのですが、現実には少しやりすぎるということが多いでしょうね。
–辛うじて十分役に立つポイントを探すのは難しいので、保守的なマネジャー達はアジャイルを好まないと思うのですけど？
そうですね。しかし、そうやって諦めることは、効率的に仕事ができないということであり、愚かであるといってもよいでしょう。彼らは、そうやってお金を浪費しつづけているのです。私にいえるのは、アジャイルモデリングのすべての原則やプラクティスを理解すれば、彼らもアジャイルモデリングすることが可能だろうということです。
辛うじて十分役に立つモデルを作るには、なぜモデルを作っているのか、誰のためにモデルを作っているのかなどを理解しておく必要があります。モデルを作る理由や誰のためのモデルかを理解しながらモデリングして、経験やスキルを身につけていけば、辛うじて十分役に立つモデルを作ることができるようになります。
近頃、多くの企業は、十分役に立つモデルを求めてもがいています。なぜなら、彼らはなぜモデルを作っているのか、誰のためのモデルなのかを理解していないのです。だから、なにもかもドキュメント化しようとしてしまうのです。
北米のプロセス事情
–前回のインタビューで、アジャイルプロセスが注目され、RUP のようなフォーマルなプロセスの人気が低下していると言われていましたが、この傾向は現在も変わらないのでしょうか？
そう思います。数年前、XP が登場する前は RUP が非常に注目されていました。誰もが RUP を使いたがりました。しかし、アジャイル革命がおこってから、大きく状況はかわり始めました。
面白いのは、今では IBM Rational のマーケティング部門に長くいる人々がアジャイルについて話したがっていることです。彼らもアジャイルが次のブームであることを認識しているのでしょう。
一般に、マネジメント層はきちんと定義されたプロセスを好みます。しかし、開発者はアジャイルを好みます。組織においては、マネジメント層と開発者が一緒に働く必要がありますから、そのような人たちのためにアジャイル RUP ができたのです。これはよくある話で、いくつかの顧客のところではアジャイル RUP を適用しています。一見無理な組み合わせのように思えるかもしれませんが、実際には可能なのです。
RUP は、長い間、大きなマーケットシェアをもっていました。しかし、アジャイルの伸び方は非常に早いのです。
RUP はしばしばトップダウンです。マネジメント層が RUP の導入を決めて、開発者に使わせたがります。それとは対照的に、アジャイルはボトムアップです。開発者がアジャイルプロセスをマネジメント層に持ち込みます。
数年前は、マネジメント層が開発者に対して、ソフトウェア開発プロセスが必要だと言っていたにもかかわらず、開発者がそれを拒絶していました。ところが今は、開発者は「 XP がやりたい、アジャイルモデリングがやりたい、アジャイルデータベースがやりたい」と言いますが、マネジメント層は、「駄目だよ、駄目、駄目。XP はやりたくない、アジャイルモデリングはやりたくない」と言うのです。おかしな話ですよね。開発者は、まさにマネジメント層が求めていたものをマネジメント層のところに持ち込んでいるというのに。開発者は、テストファースト開発をやりたい、高品質のソフトウェアを作りたい、もっと生産性を高めたいと望んでいるのに、アジャイルを理解していない、マネジメント層はそれを嫌うのです。本当に奇妙な話です。多くの組織がアジャイルになるには、きっと 10 年ぐらいはかかるでしょうね。
–なぜ、このような変化がおこったと思われますか？
いまはテクノロジーが成熟し、発展が低調な時期だからではないでしょうか。ソフトウェアの例でいうと、5 月で Java は 10 歳になります 3) 。それ以外では、C# 以外には何も新しいものはありません。とはいっても、C# も基本的には Java と同じようなものです。Web サービスや XML も、別に新しいものではありません。テクノロジーは成熟しており、まったく新しい面白いものはありません。したがって、人々はテクノロジー以外の何か別のものを求めているのではないでしょうか。
3) 2005 年 5 月の話です。
開発者はコンピュータテクノロジーについては長い間学んできました。多くの開発者は何か新しいことを学ぶのが好きです。だから、テクノロジーからメソドロジーに興味が移ってきたのでしょう。それが、XP がポピュラーになった理由だと思います。
開発者が成長し、テクノロジーよりもメソドロジーのほうが重要であることを認識しはじめたのでしょうね。まだ、長い長い時間が必要ですが、これは正しい方向だと思います。
後編は・・・
以上がスコット・アンブラーさんとのインタビューの前編です。
後編では、モデラーに求められるスキルや、プロセスパターンについて、Ronin International の名前の由来など、様々な質問を行っていますので、乞うご期待。
お知らせ
2005 年 9 月 15 日、16 日に、大手町サンケイプラザで Modeling Forum 2005 が開催されます。16 日には、弊社の藤井拓が「エンタープライズ統一プロセス入門」について講演しますので、EUP に興味がわいた方は是非ご参加ください。
参考文献
本インタビュー記事をまとめるにあたり、以下の文献を参考にしました。
- [1] スコット・アンブラー: アジャイルモデリング-XPとUPを補完するプラクティス, 翔泳社, 2003
- [2] スコット・アンブラー: オブジェクト開発の神髄～UML 2.0を使ったアジャイルモデル駆動開発のすべて, 日経BP出版センター, 2005
- [3] フィリップ・クルーシュテン: ラショナル統一プロセス入門(第 3 版), 株式会社アスキー, 2004
- [4] Scott Ambler : John Nalbone, Michael J. Vizdos: Enterprise Unified Process : Extending The Rational Unified Process, Prentice Hall, 2005
- [5] Scott Ambler : Agile Database Techniques : Effective Strategies for the Agile Software Developer, John Wiley & Sons, 2003
- [6] EUP 日本語リソース (https://www.ogis-ri.co.jp/otc/swec/process/eup-res/eup/)
- [7] AM 日本語リソース (https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/)
- [8] Enterprise Unified Process (EUP) Home Page (https://www.enterpriseunifiedprocess.com/)
- [9] Agile Modeling (AM) Home Page (https://www.agilemodeling.com/)
- [10] Agile Data Home Page (https://www.agiledata.org/)