オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

突撃インタビュー

スコット・アンブラーさんへのよもやまインタビュー

ソフトウエア工学センター
藤井 拓
2003年11月20日

去る9月17日ボストンで開催された SD Best Practices というカンファレンスで、スコット・アンブラーさんと再会し、最近の北米のIT業界の景気からアジャイルモデリングや UML2.0 に至るまでの雑多な内容を筆者の興味の赴くがままにインタビューしました。

スコット・アンブラーさんは、カナダのトロント在住のコンサルタントで Ronin International というコンサルティング会社の経営者です。同時に、Javaプログラミング, EJB, オブジェクト指向方法論、オブジェクト指向開発プロセス等の分野でのコンサルティングや書籍の執筆を行ったりするなど広範な活動を展開している人です。2002年には、アジャイルモデリング (Agile Modeling)という書籍[1](以下、AM 本と呼ぶ)を世に出して、モデリング技術の新たな方向性を提案しようとしています。

今回のインタビューで伺った内容は、以下の内容です。

北米のIT業界の景気とオフショア開発の影響

–北米のIT業界の最近の状況は如何でしょうか?景気は上向いてきていますか?

開始されるプロジェクト数や投じられる予算が増えていることより、確実に北米でのIT業界のビジネス状況は改善していることが感じられます。去年から今年の第1四半期までは、IT関係の予算がほとんど削られてしまったのですが、現在は景気がかなり好転しています。Webサービスやサービス指向アーキテクチャが普及し始め、新たに開始されるプロジェクト数も増えてきており、カンファレンスやトレーニングの集客状況も改善してきており、景気は好転してきています。

–最近、北米でのソフトウエア開発業務がインドや中国に移ってきており、北米のソフトウエア開発者が失業するというようなことが報じられていますが、そのようなkことは実際に起きているのでしょうか?

(アジャイルではない)従来の方法で開発をしている開発者にとっては、そのような状況はかなり深刻な問題だと思います。Software Development 誌の10月号でも、仕事の流出を抑えるために労働組合を結成すべきかという記事が掲載されました。インドの開発組織は、CMM (能力成熟度モデル:Capability Matuiry Model) 2)や6σのような高い成熟度で従来型の開発を行うことを得意としており、単価も安いし、競合しうる能力を持っており、長期間に渡って開発経験を積んできました。その結果、インドの開発組織は北米で従来型の開発を行う開発組織に対抗しうるぐらい力をつけています。

2)米国カーネギーメロン大学の SEI (Software Engineering Institute)が提案するソフトウエア開発組織の成熟度を分類するモデル。開発の進め方がどれぐらいきちんと定められ、守られているかなどを監査して認定される。

北米で従来型の開発を行ってきた開発者は自分の将来を真剣に考える必要に迫られています。すなわち、プロジェクト管理者、業務分析者などになるために新たなスキルを身に付け従来型の開発に留まるか、自分自身の開発効率や力を上げてアジャイルな開発者になるかを迫られています。例えば、XP (エクストリーム・プログラミング)[2]や FDD (ユーザ機能駆動型開発:Feature Drive Development)[3]を実践する 5-10 名の開発チームは、従来方式に従う 50 名の開発チームに伍する開発内容を達成できます。そのため、XPなどを実践するアジャイルな開発チームは非常に費用対効果が高いのです3)。それに対して、CMMなどのレベルを上げて大きなチームで開発した方が売上高を高くなるため、オフショア開発の業者は5名の開発チームで効率を高めることを志向しないのです。

3) 当然の事ながら、比較対照する開発チームのスキル、開発分野、利用技術などの要因も生産性に大きく影響するので、アジャイルだったら生産性が 5-10 倍向上するとあまり短絡的に理解しない方が良いでしょう。

北米のソフトウエア開発業界は明らかに変わりつつありますが、よい方向に変わりつつあると思います。それでも、今後 10 年間は多くの開発者、特に従来型の開発者にとって厳しいものになるでしょう。10 年経てば分かるでしょうが、10 年後には北米の開発者数、特に従来型の開発者の数は減り、アジャイルな開発者の数が増えていることでしょう。IT 業界で生き残るための選択肢はそう多くはないと思います。

–北米でウォータフォール型開発プロセスは減り、絶滅しそうな状況なのでしょうか?

絶滅しないでしょう。それどころか、オフショア開発4)にはウォータフォール型開発プロセス5)が適しているので、増えてさえいます。従来ウォータフォール型開発プロセスを行ってきた会社がオフショア開発に切り替わりつつあるのです。そのため、従来型の開発者の数は北米で減少する傾向にあります。

4)インドや中国など海外会社に開発作業を委託すること。
5) 一般的には、要求、分析、設計、実装、統合、テストなどの作業を順番に1回ずつ行うことにより、開発を行う開発方式。アジャイルな方法論や統一プロセス (UP: Unified Process)は、これらの作業を複数回繰り返す点でウォータフォール型ではない。作業を複数回繰り返しながら、開発を進める方式を反復的な開発アプローチと呼ぶ。

AM 本とロン・ジェフリーズ

–Amazon.com の AM 本のページではロン・ジェフリーズが共著者として名を連ねているのですが、どうしてでしょうか?

ロン・ジェフリーズ6)は AM 本の前書きを書いています。Amazon は、実際の著者以外に前書きを書いた人も著者リストに入れることがあるようです。ロンはXP関連の主要な著者であり、Amazon としてもロンの本と AM 本を関連づけたかったのでしょう。ロンはすばらしい前書きを書いてくれましたし、内容のレビューもして、すばらしいフィードバックをくれましたが、AM 本への関与はそれだけです。

6) ケント・ベックやワード・カニングハムと並ぶXP陣営の中心人物の1人

–AM のメーリングリストを時々見ているのですが、ロン・ジェフリーズは結構発言していますよね。

そうです。ロンは、すごく聡明で知識も豊富だし、人々の意見に耳を傾けることを心がけので、AM のメーリングリストにも参加しているのだと思います。結果として、AM のメーリングリストがアジャイル関係でもかなり質が良いのはロンの貢献によるところも大きいと思います。ロンはもちろんXPのメーリングリストでも積極的に発言しています。

インタビュー風景

– AM 本の第4部と第5部は各々 AM を XP プロジェクトと UP プロジェクトで実践するという事例を示しているのですが、ページ数が限られているためか XP や UPそ のものの説明はほとんど省かれていると思います。この2部は、XP や UP の前提知識がないと理解するのが難しいのではないでしょうか。

XP を実践している人は少なくともケント・ベックの XP 本[2]を読んでいるだろうと考えて第4部を執筆しました。その仮定が正しければ、第4部の説明で十分だと思います。同様に、第5部はフィリップ・クルーシュテンの本[4]を読んでいることを前提に執筆しました。確かに、第4部にはXPを一から説明する内容はありませんし、第5部には UP を一から説明する内容はありません。

–XP や UP と AM を併用する事例は AM の実践をイメージするために非常に有効だと思いますが、やはり前提となる知識をもう少し補足した方がよいのではないでしょうか。

そうですね。 AM 本を「 AM 入門」、「 AM と XP 」、「 AM と UP 」の3分冊に分けるべきだったかもしれませんね。今後検討します。

AM に対するXP, UP 実践者からのフィードバック

–AM について、XP の実践者からのフィードバックはなかったのでしょうか?

XPの実践者が、知らずに AM を実践しているということも多いと思います。AM の原則やプラクティスの多くは XP から取り入れられているので、それらの原則やプラクティスが意識せずに実践されていても不思議ではないでしょう。例えば、モデルをフリーハンドで描いたり、ある作業に行き詰まったら他の作業に移って小さなモデルを作ったり、モデルをシンプルに描いたり、一時的なモデルを捨てたりというようなことを意識せずに行っているでしょう。また、ユーザストーリを作ったり、CRC カード7)を作ったり、フリーハンドでモデルを書いたり、様々なモデルを作っているでしょう。

7) ユーザストーリやCRCカードは、AM で推奨するモデリング手法に含まれています。これら手法の簡単な説明はアジャイルモデルのエッセンスに掲載されています。

–AM は様々なモデリング手法を使うことを強調する点で、ベーシックな XP とは違うことを推奨していると思うのですが、そのことについての肯定的なフィードバックはないのでしょうか。

ロン・ジェフリーズは XP の陣営の中でモデリングを使うことに肯定的な人の代表例です。ロンは、AM の達人ですが、他の人と同様にAM を自ら実践していることを意識していません。他の例としては、昨年12月にブラジルで開催された XP のカンファレンスで Extreme Hour という XP を実演するセッションがあったのですが、そこで行われたことはまさに AM Hour でした。チームごとに、モデルを書き、それについて話し合い、コードを書き、テストコードを書くというに作業が行われました。それらは、モデルです。参加者は、自分達の成し遂げたことに非常に喜んでいました。そのうち一つのチームは、ケント・ベックが指導していたのですが、ケントに“どう思う”と聞かれて、“すばらしいね。でも、これは XP というよりは AM だね”と私は答えました。ケントは、笑いましたが…。

私は XP 陣営の人から自分達の開発の方法を見てくれと言われることも多いのですが、そこでよく気がつくのは“モデル=ドキュメント”だという大きな誤解です。おかしいぐらい巨大な成果物だけがモデルではありません。ちっぽけな手書きの図もモデルです。そのようにモデルを捉えれば、モデルをずっと維持する必要はなく、捨てても良いことに気づくでしょう。モデルをフリーハンドで書いたり、CRC カードでモデルを作ったりして数時間モデリングしたら、数時間から数日間実装し、次の段階でもう一度モデルを作るというように開発を行えばよいのです。大切なのは、少しモデリングして、その後いっぱい実装するということです。

そのような AM に基づくソフトウエア開発方法を、アジャイルモデルのエッセンスや AMDD (アジャイルモデリング駆動開発:Agile Modeling Driven Development)のページで提案しています。数分のモデリングが、実装時間を数時間削減するのです。

–今年の UML フォーラムでモデルには一時的なモデル、大局的なモデル、詳細なモデルの3種類があるという講演を行ったのですが、XPはどちらかというと一時的なモデルを中心としており、大局的なモデルが足りないように感じます。その点は、どうでしょうか?

XP では、大局的なモデルとしてはメタファー(喩え)を使うことを勧めていますが、メタファーでつまずく人も多いようです。AMDD の論文では、開発期間の最初のリリースでは当初の開発範囲を設定し、当初の要求を獲得するとともに、アーキテクチャを考えることを推奨しています。XP では最初にメタファーを考えるということになると思いますが、AM ではその部分でまずアーキテクチャの図を書くことを推奨します。図は開発の途中でどんどん変化していくでしょう。まず図を書いて、その後メタファーを考えればよいのではないでしょうか。このような大局的にソフトウエアの仕組みを鳥瞰する図は、小さいチームでは必要ないかもしれませんが、チーム規模が大きくなるに重要になります。

–AM について、UP の実践者からのフィードバックはありましたでしょうか?

RUPを実践する人で、ドキュメントをたくさん作ることを指向する人は、アジャイルは嫌いなようです。また、AM も嫌うようです。その一方、アジャイルやアジャイルに近い開発方式を好み、ラショナル統一プロセス(以下、RUP と略)8)を効率化したいと考えている人は AM を好むようです。後者の人たちには、AM がアジャイルさを高めるために役立っているようです。そのように、RUP の実践者はそこそこアジャイルな人から、まるっきりアジャイルではない人まで広い範囲に及びます。まるっきりアジャイルではない人は、AM が大嫌いです。

8) ユースケース駆動、アーキテクチャ中心の反復的開発プロセスのフレームワークである UP (Unified Process)をラショナル社(現在は IBM 社)製品化したもの。

RUP, UML, アジャイルに対する北米での関心の度合い

–昨日ラリー・コンスタンティンさんの講演に参加した時、コンスタンティンさんは RUP や UML に対する関心が最近低下してきていると発言していました。そのような見方には賛成でしょうか?

RUP の人気は確かに低下しています。その代わりに、XPが注目されているのです。ラショナル社は、RUP に関して根本的な間違いをしたと思います。ラショナル社は、RUP を自社のツールをマーケティングするための道具として利用し、マーケティングを大きな目的として設定してしまいました。そのため、RUP を導入した人からは、どの範囲がRUP で、どの範囲がツールであるか分からないという意見も出ています。また、導入後にツールを使いこなそうとして苦労したり、RUP 自身につまずいてツールを使えないこともあるようです。さらに、RUP を購入すれば、そのまま使えるものだと誤解している人もいます。ラショナル社は、RUP がそのままで使えるものではないことをはっきりと言っているにも関わらず、誤解する人は多いようです。そのような誤解のすえに、悲惨な結果に陥ったケースもあるようです。RUP は、使い方が適切であれば良いものだと思いますが、誤解をして失敗した人は非を RUP のせいにしがちです。そのような状況に RUP は苦しんでおり、不幸なことだと思います。

UML については、開発者の基本スキルとして定着したので、それほど目新しいものではなくなったのだと思います。そのような状況は、Java と似ています。Java が、目新しくなくなり、誰でも使う基本的な技術になったのと同じです。その点で、UML2.0 は目新しいのですが、新たに追加された仕様は開発者が日常的に使う基本的な内容ではないと思います。それでも、UML2.0 は正式にリリースされていないので、今後変わりうる余地はあると思います。

–日本では UML の現在の普及率はおそらく全開発者の 10 %以下だと思います。日本人は相対的に米国人に比べて方法論や図が好きな傾向にあると思われるのですが、その割りに普及率が低いように感じられるのですが。

興味深いですね。私は、少なくとも UML は開発者が備えるべき基本スキルや知識だと考えていますし、UML 以外にもいろいろ身につけるべきことが数多くあると思います。AM は、その UML 以外の部分を補うことを狙っています。私は、コードを書く前に、手書きでも良いからモデルを書くべきだと信じているので、UML の普及率が低い状況が大いに不満です。学校ももっとUMLを教育すべきだし、Java や VisualBasic の入門書も UML について言及すべきだと思います。また、開発者も修得に努力すべきだし、会社も UML の修得を支援すべきだと思います。

–SD Best Practices に参加してセッションを見た限りでは、XPに対する関心は横ばいで、スクラム[5]やリーン・プログラミング[6]への関心が非常に高まっていると感じたのですが、そのような見方は正しいでしょうか?

XP の普及度は、他のアジャイルな方法論をはるかに先行し、成熟してきていると思います。 XP は、それぞれの人が実践するか否かと判断する段階に来ています。リーン・プログラミングが比較的新しいので関心を集めていますし、スクラムの方は以前からあるのですが、XP ほど名前がカッコ良くないのであまり注目されてきませんでした。XP の効果を目にしながらも、XP 自身を行うことについて抵抗を持つ人たちが、XP に替わるアジャイル方法論の選択肢を探しているというのが現在の状況ではないでしょうか。

おもしろいのは、開発プロセスのマーケットの中で従来型の開発プロセスを比重が大幅に低下し、アジャイルの比重が高まっていることです。従来型の開発プロセスの話をする人は減っているのですが、そのような話をする人は自分達の開発プロセスをアジャイルにすることも可能だと言い訳をしながら話をしているような状況になってきています。従来型開発プロセスの信奉者が尊敬しているバリー・ベームやラリー・コンスタンティンのような権威者も、アジャイルな開発に肩入れしてきています。

–スクラムは XP よりかなり単純だし、スクラムもリーン・プログラミングもどちらかといえばプロジェクト管理に焦点があたっている点が受けているのではないでしょうか。

スクラムもリーン・プログラミングはプロジェクト管理を中心とし、AM はモデリングを中心とした特化した方法論であり、XP や RUP などと併用することができるのが特長です。特に、スクラムとXPの組み合わせが多く用いられているようです。

–スクラムの場合には、実践すべき原則やプラクティスも少ないので、XP と比べて受け入れやすいという面もあるのではないでしょうか。

スクラムは既に何らかの開発プロセスが使われていることが前提になり、スクラムはスプリントの中ではどのように開発が進むかについては言及していません。その点が非常に面白いと思います。

AM の今後の方向性

インタビュー風景

–AM の質問ですが、AM について近い将来の構想をお聞かせいただけないでしょうか?

最近、AM に関する説明をさらに整理してより簡潔にしようとしています。いくつかのプラクティスは冗長で、必要以上に複雑になってしまったように思います。XP でケント・ベックが行ったように、AM をまず詳しく説明した方がよいと考えたのは間違いでした。モデリングを指向する人たちは、プログラミングを指向する人より成熟している傾向があります。そのため、モデリングを指向している人はそれほど詳しい説明を必要としていなかったのです。そのため、AM の基本となるプラクティスをもう一度整理しています。実際には、基本となる少数のプラクティスを実践しているうちに、他のプラクティスも意識せずに実践するようになることが多いようです。また、AM を既に長い間実践していたことに気づいたというフィードバックも多く寄せられています。私は、そのようなモデリング作業の様子を書き留めただけだと思っています。

最近提案しているアジャイルデータ(AD: Agile Data)[7]は、AMを データモデリングの分野に応用したものです。今後、AM のプラクティスを1つ,2つ減らす可能性がありますが、AM 自身の基本的な考え方そのものはそれほど変わらないと思います。

–AM と AD とエンタープライズ統一プロセス(以下、EUP と略)9)を一人で発展させていくのは非常に大変だ(笑い)と思うのですが、そのようなことがどうしたら可能になるのでしょうか?

9) スコット・アンブラーさんが提案する統一プロセスをベースにしたプロセスフレームワーク。

複数の人格を備えているからです。(笑い)私が行っていることは非常にシンプルです。いろいろな人に、何がうまくいき、何がうまくいかず、それはなぜかを問い掛けているだけです。経験が異なればそれらの説明も異なり、組織により説明が異なり、注目している範囲により説明が異なります。AM はモデリングを効果的に行うテクニックに関するものであり、AD はデータ中心の作業をアジャイルに行うものです。それらは適用範囲が異なるので、内容的にも異なっています。EUP は、エンタープライズレベルの開発活動、複数のプロジェクト、ライフサイクルを考えて、UP を拡張したものです。これらは、異なる質問に対する異なる回答として発展してきました。

私達の会社は、XP が絶対だとか RUP が絶対だとかいう立場ではなく、それらから少し距離を置いた立場を取っています。すなわち、アリスター・コバーンが言うように複数の開発方法論を持つべきで、仕事の性質に応じて適切なものを適用すればよいという立場です。そのことを信じています。その結果として、私達の会社は幅広いお客様からコンサルティングの依頼を受け、幅広い回答を提供しています。アジャイルのみならず、CMM関連のコンサルティングも行っています。EUP とアジャイルは、相容れないように思えるかもしれませんが、それぞれ適切な状況があり、整合させることが可能です。要するに、異なる種類のスキルを修得し、状況に応じてもっとも適切なスキルを使えばよいということです。一つで万事は賄えません。

■ UML2.0

–昨日、UML2.0 について否定的なコメントを述べられたと思いますが、他の人の UML2.0 に対する意見はどうなのでしょうか。

SD Best Practices と同じホテルで開催されている組み込みカンファレンスに参加しているスティーブ・メラーと会いましたが、UML2.0 に非常に肯定的でした。彼の会社は、UML2.0 をサポートするツールを持ってますからね。

–スティーブ・メラーさんはモデル駆動型アーキテクチャ(以下、MDA と略)10)の中心的な推進者の一人ですよね。

10) UML の仕様を策定しているOMG (Object Management Group)が推進する UML モデルを中心にすえた開発方式。UML のモデルでソフトウエアを実現するプラットホームに依存しないモデルを定義し、そのモデルからプラットホームに依存した実行用のソフトウエアを生成しようとするなどの構想が盛り込まれている。

そうです。MDA 推進派なので当然です。その一方で、ロバート・マーティンさんやその他のUMLを現場で使っている人たちは UML2.0 のリリースを重視しておらず、様々な仕様の拡張内容をほとんど気にとめていません。自ら進んで苦しんでも仕方がないですからね。

私は、UML と MDA をもっと分けた方がよいと思います。私が UML2.0 に大きな不満を抱いているのも、UML2.0 で拡張された仕様のほとんどが MDA のためのものだからです。 MDA は非現実的だし、MDA が求めているようなモデリングスキルを備えた人はごく少数なので、近い将来もMDA ツールはマーケットも限定されたものに留まると思います。他のツールとの統合も難しいと思いますし、過去に同様のことが目指された時と比べて目立つような技術的な進歩も伺えません。私が間違っているかもしれませんが、現場で実際に UML を使っている人も同じ意見の人が多いのではないでしょうか。その一方で、MDA のばら色の夢を単純に信じている人もいるという状況に不満を感じます。もちろん、限定された範囲では MDA が現実的だという場合もあると考えています。

また、世の中でデータベースを利用するソフトウエアを開発するプロジェクトが多いにも関わらず、UML にデータモデルが含まれないという点にも納得できません。ユーザインターフェイスやビジネスプロセスの表現も十分にできません。大多数の開発者がデータモデルやユーザインターフェイスのモデルを必要としているのに、ごく少数の MDA 推進派の意のままに仕様が拡張されるのには納得できません。現在の方向性は間違っていると思いますが、UML の仕様策定メンバーは自分達が間違っていることにすら気づいていないのです。UML を使う人達が立ち上がり、OMG はその人達の意見に耳を傾けるべきです。

■ 最近出会った良書

–これから出版されるご自分の著作である The Agile Database Techniques[7] や The Object Primer 3rd Edition の購入を推奨されると思いますが、自分自身の著作以外で最近出版された本で良いと思った本はありませんでしたか?

クレーグ・ラーマンの新著“Agile and Iterative Development: A Manager’s Guide”[9] です。この本では、アジャイルな開発プロセスの概観しており、XPやスクラムなどを各章で解説しています。私が特に気に入っているのは、反復的でインクリメンタルな開発プロセスの有効性を立証しようとしている章です。ここ数10年間の研究結果、先端的に取り組んでいる人達のインタビューを通じて反復的でインクリメンタルな開発プロセスの有効性の立証を試み、同時に様々な研究成果から従来の(反復的でない)開発プロセスの問題点を立証しようとしています。あらゆる人の必読書だと思います。従来の開発プロセスの問題点の説明に説得力があるので、アジャイルな方法論を取り入れたいのに反対派がいて取り入れられない場合の説得材料として有効です。

また、バリー・ベームの新著である“Balancing Agility and Discipline: A Guide for the Perplexed”[10] もお勧めです。この本は、どちらかといえば従来の開発プロセス寄りなのですが、状況に応じてアジャイルさと秩序のバランスをどのように取るかということについて興味深い議論をしています。結構、アジャイルさと秩序のバランスについて悩む人が多いと思うので、そのような人にはお勧めです。

–長時間に渡るインタビューどうもありがとうございました。

お知らせ

2003 年 8 月にリニューアルした AM 日本語リソースサイトに、AM で推奨するモデリング手法を紹介するアジャイルモデルのエッセンスのページを追加しました。現在のところ、日本語に翻訳した部分は一部(14のモデリング手法)に留まり、手書きの図等未翻訳の部分も残っています。AM 本ではほとんど説明されていない各種モデリング手法を理解されたい方にはお奨めです。ご興味があれば、ぜひ一度覗いてみてください。

参考文献

  • [1] スコット・アンブラー: アジャイルモデリング-XPとUPを補完するプラクティス, 翔泳社, 2003
  • [2] ケント・ベック: XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法, ピアソンエデュケーション, 2000
  • [3] スティーブン・R.パルマー他: アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発, ピアソンエデュケーション, 2003
  • [4] フィリップ・クルーシュテン: ラショナル統一プロセス入門(第2版), ピアソンエデュケーション, 2001
  • [5] ケン・シュエイバー他: アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003
  • [6] Mary Poppendieck, et al.: Lean Software Development: An Agile Toolkit, Addison-Wesley, 2003
  • [7] Scott Ambler: Agile Database Techniques : Effective Strategies for the Agile Software Developer, John Wiley & Sons, 2003
  • [8] Agile Data Home Page(https://www.agiledata.org/)
  • [9] Craig Larman: Agile and Iterative Development: A Manager’s Guide, Prentice Hall, 2003
  • [10] Barry Boehm, et al: Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003