［インタビュー］

IBM Rational Software Development Conference 2004 の基調講演のため Grady Booch 氏が来日。カンファレンスを主催している日本アイ・ビー・エム株式会社のラショナル事業部の方々のご厚意により、Booch 氏とオージス総研のメンバとで会談する機会が得られました。この記事は、そのときの会談をオブジェクトの広場読者用に記事としてまとめたものです。以前、Booch 氏に突撃インタビューをしてから、6 年が経過しますが、今回は、技術的な内容を中心に Booch 氏の最近の活動についてお話を伺いました。

アーキテクチャハンドブックについて

-- まず、現在執筆中の本であるアーキテクチャハンドブックのことをお聞きしたいんですが、何故、アーキテクチャハンドブックを書こうと思ったのか、どういう読者を対象としているのかについてお聞かせください。

二種類の異なる読者が対象になっています。一つ目はソフトウェアアーキテクトの方々です。業界の中でソフトウェアアーキテクチャが重要視されているのですが、ソフトウェアアーキテクトが学ぶべき知識の内容がきちんと定義されていません。

二つ目として、ソフトウェアの開発者コミニティ全体が対象になります。先ほどの講演^*1の中でも話しましたが、世界中で 1 年当り、330 億行ものプログラムコードが書かれています。しかし、プログラムを書いている方のほとんどが、特定の領域についてだけを学び、それ以外のシステムについてはきちんと理解していないところがあります。そこで、ちょっと奇妙に聞こえるかもしれませんが、現存するソフトウェアの美について伝えたいと思い、この本を書いているのです。つまり、きちんと構築されたソフトウェアシステムは、ソフトウェアについて学ぶための非常に良いモデルになりえるからです。

^*1 IBM Rational Software Development Conference 2004 の 10 月 7 日の午前中に行われた「ソフトウェア開発の未来」と題した基調講演のこと

例えば、土木工学の領域においては、もう何千年にもわたる経験があるので、達人の作品について今でもきちんと学習することができます。しかしながら、ソフトウェア工学の分野の中にはそういった達人の作品がない、あっても学ぶことができない状況にあります。従って、アメリカに存在する１００のシステムを選んで、そのソフトウェア工学の広さを示すとともに、その重要性を探っています。

-- アーキテクチャハンドブックを執筆する作業は、ソフトウェア博物館の作業とは何か関係してますか。

このハンドブックの作業とソフトウェア博物館の作業とは密接な関係があります。博物館の方は過去のシステムを扱い、ハンドブックの方は現在のシステムを扱います。そういえば、MacPaint についてはハンドブックで扱う予定なのですが、Ralph Johnson ^*2に言ったら、これは博物館にいれるものじゃないのか、今だったら Photo Shop をいれるべきだろう、というメールのやりとりもありました。

^*2 Design Patterns の書籍の執筆者の一人

-- ソフトウェア業界でも、先人の努力を学び、それらをさらに改良する努力が必要ですよね。

そうですね。それから、それとは別に、ソフトウェア博物館には、ソースコードを保存するという目的もあります。ソースコードを保存することによって、特許関連の問題を解決することができます。特に、Tim O'Reilly がその点に非常に興味をもっています。ソースコードを収集することによって、例えば、新しく申請された特許が、これはもう昔からある先行技術だという主張ができるようになります。

-- 先ほどからソフトウェア工学と土木工学と比較されていますね。両者の最も類似しているところと、異なるところはどこでしょうか。

最も大きな類似点は、両方のエンジニアリングにおいて、フォースを解決することが目的だということです。土木工学においては、明確ないくつかのフォースが存在し、それらは数学的技術を応用して解決されます。ソフトウェア工学においては、フォースはもっと複雑で特徴づけにくいものです。全てのソフトウェア開発作業にはフォースが存在するのです。

それから、もっとも異なるところですが、土木工学は物理の法則に従います。しかし、ソフトウェア開発においては、自分自身で法則を作って、それに従います。例えると、新しい材料を作って、それをもとにものを作り上げるようなものです。しかも、その材料というのは非常に流動性があって、どんなものにも変化します。

パターンに対する考え

-- ソフトウェアアーキテクチャをパターンを使って表現することについてはどう思いますか？

それはまさに私がやっているところです。

私は、アーキテクチャに対する視点に関して、Kruchten ^*3から大きな影響を受けています。アーキテクチャを 4 プラス 1 ビューで見るところです。だから、アーキテクチャをさまざまな観点から見て、そこに共通の問題が存在しないか、解決法の体系化ができないかと考えます。これはまさにパターンを使うのに最適な状況です。

^*3 「ラショナル統一プロセス入門」の著者である Philippe Kruchten のこと

アーキテクチャハンドバックのサイトにも掲載していますが、対象のアーキテクチャをドキュメント化をするだけではなくて、さらに共通のパターンというものをそこから抽出しています。おそらく、新しいパターンは 20 か 30 程度、抽出できるのではないかと思っています。

-- 4 プラス 1 ビューの一つである論理ビューに関しては、パターンを使って表現するのは良いと私も思います。しかし、他のビューではパターンを使って表現するのは難しいんではないでしょうか？

私の経験では難しくはありません。

最近、Grant ^*4が、配置ビューと実装ビューの分野でパターン化することを試みて、同じ構造が何回も反復して現れることを体験しています。したがって、このアイデアは別のビューにも同じように当てはまると思います。

^*4 Grant Larsen のこと。J2EE や.NET プラットフォーム上におけるソフトウェア部品再利用に関する研究を行っている。

-- パターンには解決すべき問題が存在します。アーキテクチャパターンの場合であれば、非機能要求、つまり信頼性やユーザビリティに対する解決策を提供するはずです。このような方法で (アーキテクチャ) パターンを記述しようとされているのでしょうか？

パターンは、それぞれ異なった特徴やフォースを持っています。 したがって、私は、パターンを記述するために Hillside グループ^*5が使っている古典的な形式を使っています。これには、フォースや解決策、バリエーションなどが含まれています。つまり、あなたがいったようなものは、私のアーキテクチャパターンに含まれているということです。

^*5 パターンコミュニティの総本山。パターン全般についての詳しい情報が得られる。

-- 何故、パターンという形式を選ばれたのですか？ それがやっぱり一番ふさわしい形式なんでしょうか？

もちろん他のアプローチもあると思います。しかし、私の経験では、パターンよりもいい形で表現できたことがありません。もちろん有効な代替手法というのは、何十かあるかとは思います。

おそらく、こういう質問をお聞きになるということは、パターンに対して何か懐疑的なお考えがあるかと思うんですが、他にいいアイデアというのがあるんでしょうか？

-- いえ、パターンが一番良い方法だろうなと思っていますが、もしかすると他にもっとよい表現形式があるのでないかと思いまして。

非常にすばらしいインタビュアーです(笑)。

-- 数学では微分方程式の解法などはパターンで体系化されているのに対して、代数学のように定義、公理、定理のような原理で体系化されているアプローチもあり、ソフトウエアアーキテクチャなどの場合もこれら両方のアプローチがあっても良いのではないでしょうか。

ごもっともです。

実は、タイムリーな話題があります。全米科学財団 （NSF: National Science Foundation) という様々な分野の長期的な研究に対して資金提供を行う団体があるのですが、ここで Greenspan 氏の主導のもとにデザインの科学 (Science of Design) というものを創設しています。この団体のコンセプトは、私自身もそう思っていますが、デザインの中には、確立すべき基礎的な科学が存在する、というものです。それゆえ、彼らはデザインの形式的な側面を検証するプロジェクトを立ち上げています。私はここへ来る直前、あなたの言うような問題に取り組む様々なプロセスの提案を検証してきました。これは、これから活発に議論すべき問題です。

-- アーキテクチャの美という側面についてはどう思われますか？

Dick Gabriel^*6、CLOS の発明者の一人ですが、彼はプログラムの美についての興味深い記事を書いています。また、Donald Knuth も、文芸的プログラミング^*7についてたくさん書いていますが、同時に美についても触れています。ところで、美とはなんでしょうか。私達は、ソフトウェアにおける美というものを正しく理解できていません。

^*6 有名な lisp ハッカー。Unix や C 言語と Common Lisp や Scheme の設計思想の違いについて述べた「Worth is Better」を書いたことで知られる。

^*7 プログラムの作成とその文書化を同時に行なう手法。「文芸的プログラミング」というタイトルの Donald Knuth の書籍もある。

-- Hillside グループの話が出たので、ちょっとお話を聞かせてください。最近でも、Hillside グループの活動に活発に加わっておられるのですか？

設立当初からのボードメンバーだったのですが、次回の選挙には出ないことにしました。したがって、名誉ボードメンバーのような立場で、ボートミーティングには出るんですが、投票権はないというかたちで活動にかかわるつもりです。

-- 最近のソフトウェアパターンの広がりはどのように思っておられますか？例えば、セキュリティパターンとか、テストパターンだとか、非常に幅広い分野に広がってきつつあると思うんですが。

中にはパターンという言葉だけを使って、実質は伴わないものもあるかと思います。ただ大体においてパターンというものは、ソフトウェア開発以外にも使われ始めていると思います。アンチパターンやプロセスパターンもその領域に入ると思いますし、そういったことは非常に良いことだと歓迎しています。これからは、いろいろな領域におきましてパターン化する機会があると思います。

-- そういえば、数年前に Rational Software が ACBD (Automated Component Based Development) においてコンポーネントという用語を使っていたと思いますが、最近は Rational からコンポーネント開発という言葉を聞きませんね。コンセプトを変更されたのでしょうか？

これ自体がちょっとマーケティングが作ったような用語でして、私自身が使った記憶はありません。最近は、モデル駆動型開発ということがよく言われています。モデル駆動型開発の基本的なアイデアは、UML を実際の開発言語として使い、それを変換して開発をおこなっていくというものです。モデル駆動型開発において、私にとって最も興味深いのは、パターンと共に UMLでモデリングをすることです。もし、一般的なソリューションを体系化したパターンがあって、その適用を自動化できるのあれば、さらに抽象化のレベルを上げることができます。

これからの開発環境に求められるもの

-- 5, 6 年前にあなたの講演で聴いたことを思い出しました。たしか、コンポーネントの正しいバージョンの組み合わせをランタイムに検証する仕組みについて話されていたと思います。これはある種のソフトウェアの品質の問題だと思いますが、なにか、ソフトウェアの品質を劇的に向上させる意見や予想をお持ちでしょうか？

ソフトウェアの品質について、劇的に向上させるというものは全く思いつきません(笑)。ソフトウエアは作ることすら難しいので、その中でさらに品質を高めるための魔法のような方法はありえないと思います。これから起こり得る変化としては、よりチーム活動が主体になってくると思います。だから、開発者が利用するツールというものは、個々の能力を高めるだけではなく、チーム内の開発者が一緒に作業ができる、よりフレキシブルな開発ができるようになるものが求められると思います。

-- 午前中のプレゼンで、近い将来、人々はコラボレーションと分散開発環境におかれるという重要な話に触れられていたと思います。我々は、今それに向かって奮闘しているところです。開発環境の中で最も重要なことは何でしょうか？どんな意見をお持ちですか？現在、我々は、十分な環境をもっていません。たぶん、我々には重要な何かが欠けているのだと思っています。

最も重要なものを一つあげるのは難しいですね。というのは、協調開発環境においては、一つの機能が重要だとか、重要ではないとか言えないからです。何百という機能が組み合わさって、はじめて、開発者がより広い範囲の利用者とコミュニケーションをするための作業空間を創り出すことができるからです。 だから、機能の観点から見れば、それは単体のものではなく、デスクトップ上の開発環境で何百という機能からなる構造体となると思います。

あとは、Rational の研究団体の方にもかかわっているんですが、その中の一つに JAZZ プロジェクトというものがあります。この JAZZ プロジェクトのアイデアには、Eclipse 環境の中でインスタントメッセージをやりとりするようなものがあります。これは、ある一つの単純な協調環境の例として挙げることができると思います。

読者のために二つの参考になるリソースをお伝えしたいと思います。まず、Marvin V. Zelkowitz が編集した Advances in Computers の第 59 巻に、私が執筆した協調開発環境(Collaborative development environments) という記事があります。また、EclipseCon という Eclipse に関する会議があるんですが、そこのキーノートを私が担当しています。そこで、協調環境に向かって進化する開発環境^*7についての講演をしています。

^*7 Eclipse Con2004 で講演している「From IDE to XDE to CDE」のこと

ドメイン特化言語に対する考え

-- ドメイン特化言語についてはどう考えていますか？

この点については、Microsoft と私とでお互いに意見が違うな、というところで意見が一致しています。Microsoft の方は、依然 UML は重要ではないんだと言っています。それよりもドメイン特化言語の方がいいんだと言っているのですが、それに対しては一つの大きな問題があると思います。一つは、ドメインに特化した言語を記述するということは非常に困難で、もし出来たとしても、それは既に UML の中にあるものをもう一回記述することになってしまうことです。

二つ目として、ドメインというものは非常に小さなものになってしまうということです。あるドメインといっても、いろいろな利害関係者がいるわけで、そこでどのドメイン特化言語を使うかということでかなり違ってきます。それは、どんどん深い暗い穴に入っていくようなものです。つまり、ドメイン特化言語というのは、非常に狭い範囲の言語になってしまいますので、その言語用のツールを作成したりだとか、その言語をサポートしたりだとかする状況に陥ってしまいます。

-- それは、まさにドメインに特化したモデルと同じものですね ？

まったくもって、おっしゃるとおりです。

とはいえ、そのようなドメインに特化したものにも価値はあるわけです。例えば、ドメイン特化アーキテクチャ、ドメイン特化パターンというものを共通の言語、つまり UML を使って記述すればメリットが生まれてきます。そんなところが、Microsoft と私の考えが違うところなんですが。私は、言語の問題ではなく、コンテンツだと思います。これらのコンテンツを共通の言語を使って記述することができることがよいことがだと思います。

若手エンジニアへのメッセージ

-- では、最後に 二つ質問したいと思います。前回質問したことをもう一度お聞きしたいと思います。今の仕事をやって一番よかったと思うことは何ですか？前回は、「まだないのでこれから目指す」ということだったんですが。

今日は一番よかったことを話したいと思います。

IBM の中には非常に多くの頭のいい人々がいるということです。私の方も頭のいい人に囲まれて育ってきたというところがありますから。だからといって Rational に居たときは、バカばっかりだったといっているわけではないですが(笑)。IBM にはノーベル賞を受賞した物理学者とか、化学者とか、バイオ関連の研究者等も揃っていますから。

-- これからオブジェクト指向を取り組もうとしている若いエンジニアに何かアドバイスをいただけないでしょうか？

二つアドバイスをしたいと思います。

まず、一つ目は基本を忘れるなということです。プログラミングとエンジニアリングは違いますよということをはっきりと区別してほしいと思います。また、他の方が行った仕事、業績から多くのものを学ぶということも大事だと思います。

それから二つ目として、最高の開発者というものは、全人というか、全部が揃った人間だということです。つまり、非常にすばらしいプログラマーということだけではなくて、完全に自分の生活全体において良いところをもっているということです。だから、技術的なところだけではなくて、社会的なところ、また、人間的なところも兼ね備えていますし、開発者であることの特権も責任も持っています。

それから、情熱をもって仕事をやってほしいと思います。私が仕事でうまくいったのは、たくさんのメンターに恵まれいたからということがありますが、自分が楽しいと思うことをしてきたからというところもあります。また御社のようにオブジェクト指向のエバンジェリストとして利益を度外視されている活動もあると思いますけれども。お金ということよりは、自分をよりハッピーにするもの、それが正しいやり方だと思います。

-- どうもありがとうございました

取材後

今回、日本アイ・ビー・エム株式会社のラショナル事業部の方々のご厚意により、インタビューをさせて頂く機会を頂きました。本当にありがとうございました。

© 2004 OGIS-RI Co., Ltd.

HOME TOP