“ソフトウェア開発を成功させるためのモデリング、 開発プロセス、ツール支援”Keyman Interview

 Development Styleコーナーでは、今回米ラショナルソフトウェアに籍を置き、ソフトウェアエンジニアリングの世界をリードする著名な3名にインタビューする機会を得た。RUP(Rational Unified Process)の創設者であるヴァイスプレジデント&ジェネラルマネージャ ウォーカー・ロイス(Walker Royce)氏、Rational Roseのエバンジェリスト テリー・クアトラニ(Terry Quatrani)氏、米ラショナルソフトウェアのフェロー ジェームズ・ランボー(James Rumbaugh)氏の3名だ。

» 2002年12月18日 12時00分 公開
[宮下 知起,@IT]

“プロセスを成功させる秘訣はRUPのスピリットにある”

ALT Walker Royce 米ラショナルソフトウェア ヴァイスプレジデント&ジェネラルマネージャ

RUPを活用するにはスピリットが重要

――RUPはどのように誕生したのか?

 ウォーターフォールモデルにもともとイテレーティブ(繰り返し型)な要素があった。RUPは過去30年間のウォーターフォールモデルのプロジェクトの経験から誕生したものだ。ウォーターフォールモデルのプロセスには、顧客に見える部分のプロセスと、開発者サイドのプロセスの2つが存在していた。ここから、イテレーティブな進め方という発想が生まれてきたのだ。

 10のうち9までのウォーターフォールプロセスは失敗してきたが、そのうち1つの成功例ではたいていイテレーティブな要素が取り込まれていた。それに、もともと私の父も、大規模なプロジェクトについてはウォーターフォールにイテレーティブなアプローチを取り入れることを推奨していたのだ。

――RUPは正しく使われているか?

 RUPが現場で正しく理解され、実行されている割合は6割程度だと思う。4割の人たちはRUPの用語を使ってはいるものの、そのスピリットを受け継いではいない。

 RUPのスピリットとは、スコープを継続的に管理するということであり、不確かさの中でユーザーが何を望んでいるか、このデザインで何ができるかということを考えながら、うまくプロジェクトを動かしていくということだ。

(編集注:スコープとは、繰り返し型の開発の各フェイズにおけるリリースの範囲(システムの機能範囲)のことである。つまり、RUPでは、繰り返しの各回に明確なゴールを設定しプロダクトのリリースを行うが、そのたびに目標と成果を評価し、次のサイクルの計画にフィードバックすることが重要だということだ)

――ところで、スコープの大きさはどのように決めるべきなのか?

 決まった答えはない。例えば、あるITシステムではトランザクションが重要であるとか、航空電子工学の飛行プログラムでは計算のためのバス幅の設定が重要であるというように、そのシステムで何が重要なのかに注目し、まずは重要なものから全体の約2割の機能を洗い出すことだ。

大規模プロジェクトにも適用できる

――メインフレームをプラットフォームとした大規模なウォーターフォール型プロジェクトが、特にメインフレーマーと呼ばれたベンダが主導となって現在も進められている。しかも、そこには独自のプロセスが確立されていて、RUPなどの新しいプロセスが入り込む余地などないようにも見える。

 いや、そこにもRUPが導入される可能性はある。独自のプロセスを維持し、そのプロセス用に人を訓練し、ツールを作るには莫大なコストがかかる。それに対して、多くの会社が投資している商用のプロセスやツールを使い、人を訓練する方がコストがかからないのは明白だ。

――日本の旧メインフレーマーは、採算が悪化するSI事業を立て直すために、プロジェクト管理の見直しに必死だ。CMMやPMBOKを重視し、社内教育に取り入れる企業も増えている。

 CMMやPMBOKは古いウォーターフォールモデルに基づいたものであり、イテレーティブな開発と一緒に使うには多くの摩擦がある。PMBOKはもともと橋や道路を造ったりというような建設プロジェクト、つまり結果がとても分かりやすいプロジェクト用に作られたものだ。それを、結果が予測しづらく、不確実性の高いソフトウェアプロジェクトに応用するには無理がある。

優秀なプロジェクトマネージャはどうやって生まれるか?≫

≪――よいプロジェクトマネージャ(以下プロマネ)はよい建築家のようなものであり、ほとんどの会社ではプロマネが不足している。しかも、訓練すればだれもがよいプロマネになれるというものでもない。

 そのとおりだと思う。重要なのは、プロマネとして素質のある人間を見つけ出し、教育することだ。よい人を探すには、成功したプロジェクトを見て、誰が実質的なマネジメントをしていたかを見極めることが大切だ。しかし、統計的に、4つのうち1つのソフトウェアプロジェクトしか成功しないとされていることから考えると、本当に腕のいいプロマネは全体の25%しかいないという計算になる。その中からよい人を探すことになる。

――素質ある人をどのように教育したらよいのか?

 よい教育方法は、「師匠と一緒に働いて学ぶこと」だ。私自身、自分がよいプロマネになれたのは、よいプロマネと一緒に仕事をして、その人の上手な方法を学んでいったからだ。

 ラショナルでは、「よい師匠と一緒に働いて学ぶ」ことをメンタリングというサービスで提供している。トレーニングコースで学ぶよりも、成功するプロジェクトに参加し、プロマネがどういう手法を取ったのかを見て、そのまねをすることの方が有効だ。

XPやアジャイルはRUPのコンペティタなのか?

――XPやアジャイルといったライトウェイトな開発方法論も誕生している。開発プロセスの世界は混とんとしているようにも見えるが、将来的にはこの状況は収束するのか? それとも、いろいろな考え方が、プロジェクトに応じて適用されていくことになるのか?

 アジャイルやXPは小規模、RUPは大規模向けと分けて考える向きがあるが、これは間違った見方だ。アジャイルのコミュニティの人たちもRUPをコンペティタと考えているようだが、私たちはそう思っていない。

 RUPとアジャイルのスピリットはとてもよく似ている。多くの企業でRUPを使って失敗している原因は、間違ったプロセスを多く実行しているからであり、一方、XPやアジャイルで失敗しているのは、実行するプロセスが少なすぎるからだ。重要なのは、スピリットであり、そのスピリットを受け継いでいないために、失敗する。

 よくいわれるのは百科事典のような(複雑なプロセスである)RUPを、全部やろうとすると失敗するということだ。われわれは、RUPをスーパーセットとして、大規模から小規模開発にまで対応できるようにしている。実際ラショナルは、RUPにアジャイル開発やXPを実現するプラグインを用意している。RUPはアジャイルやXPのスーパーセットであると考えている。

 大きなプロジェクトを成功させるためには、できる限りアジャイル(迅速)でなくてはならないのは事実だ。だからスケールの大きさに関係なく、必要なスピリットは同じである。その意味で、アジャイルのコミュニティは正しいことをいっていると思っている。アジャイルのコミュニティはわれわれにアジャイルな方法でRUPを使うようにと勧めているが、これは大切なことだ。

プロセスの未来

――J2EEや.NET、Webサービスの登場によって、アプリケーションの疎結合モデル、コンポーネント資源の再利用など、新しいトピックが登場している。プロセスはこれらの影響を受けるのか?

 J2EEや.NET、Webサービスなどの普及によって、RUPのスピリットはより生かされるだろう。昔は、すべてをカスタマイズして開発しなければならなかったため、ユーザーが必要としている機能をどう実装するかという部分で開発が左右されてしまっていた。しかし、フレームワークやコンポーネントをベースとした開発では、問題領域とソリューション領域のギャップを埋めるためにどのようなフレームワークやコンポーネントを選ぶかという点に注力することになる。つまり、より目に見えるステップを繰り返すことができるようになるわけで、これこそがRUPのスピリットなのだ。

“モデルとコードをより近づける試み「Rational XDE」”

ALT Terry Quatrani 米ラショナルソフトウェア Rational Roseエバンジェリスト

――仕様書をかっちり書いても、結局は実装と異なってしまうことはよくある。同様に、UMLでモデリングをしっかり行っても、それがうまく実装に反映されないというケースも発生するような気がする。

 それについてはイエスともノーともいえる。まずいっておきたいのは、私たちはモデルとコードを近づける努力をしている。

 整理してみよう。まず、モデルはコードを組み立てる援助をするものだが、プログラミング言語ではない。家を建てる場合と同じで、設計図は家のレイアウトは教えてくれるが、大工にどこに釘を打てばよいかまでは教えてくれない。コードでも同じことだ。モデルは抽象概念で、開発者に構想を伝えるが、開発者自身がコードをインプリメントしなくてはいけない。

 モデルとコードを完全に1対1で結ぶことは非現実的だ。なぜなら、よい例としてはシーケンス図がある。よく、シーケンス図からコードを生成すればよいのでは? という質問を受けるが、シーケンス図からコードを生成するとなると、図の中に恐ろしいほどの詳細な事項を書き込むことになってしまう。そうなると、コードを書いた方が簡単ということになってしまう。

――モデルとコードを近づける努力とは?

 Rational Rose(以下Rose)のユーザーの製品への改善要求で一番多かったものに、Roseのモデルとコードの同期をよくしてほしいということがあった。例えばRoseはマイクロソフトのVisual Studio 6(VS6)をサポートしているが、VS6とRoseの間でコードとモデルの同期を取るのは大変な作業だった。結局、2つの開発環境を使っているのと同じことだった。

 そこで、Rational XDE(以下XDE)を開発した。XDEは統合する相手のツールのシェルと完全に1つになって動作するツールだ。そのため単体では動かない。開発者は、使い慣れたIDEにXDEを統合し、ボタン1つでコードとモデルを同期できる。

――コードとモデルの同期が楽になったという点以外に特徴は?

 XDEのもう1つの目標は、開発者がコードをインプリメントする際の支援をすることだった。XDEには強力なパターンエンジンとコードテンプレートが用意されている。生成されたクラス図に対して、パターンとテンプレートが適用されることで、Roseで行っていたよりも、はるかに多くのコード(最終的な実装に近いコード)を自動生成できるようになった。

――サポートしているパターンにはどのようなものがあるのか?

 J2EEと.NET。そしてGoF(注)などだ。J2EEのパターンは、ラショナルが開発者向けに提供しているサイトRational Developer Network(RDN)らダウンロードして使うことになる。さらには、パターンをそのまま使うだけではなく、ユーザーが自分でパターンをカスタマイズすることも可能にしている。これはパターンエンジンの効果だ。

(編集注:GoFとは、Erich Gamma, Richard Helm, Ralph Johnson, John Vilissidesらが考案したデザインパターンのこと。通称、Gang of Four-GoFと呼ばれている。彼らの共著書『Design Pattern』がベストセラーとなり普及した。「生成」「構造」「振る舞い」という分類で23のパターンが理路整然とカタログ化されており、オブジェクト指向開発を助ける有効なパターンとして高い評価を受けている)

――XDEは、モデリングから入るのではなく、まずリバースだけをやってみるといった使い方をしてよいのか?

 そうだ。コードから始めてもよいし、モデリングから始めてもよい。モデルを変更したり、コードを変更したりして、ボタンを押して同期させてみてほしい。開発者のニーズに合わせて自由度の高い使い方ができる。これがこのツールを作るときの目標でもあった。

――そういう点では、いままでUMLを現場に取り入れてなかったデベロッパにとって、UMLに入っていくきっかけになるツールといえるのか?

 そうだ。私もいろんな人に、XDEを使うとすぐにUMLが習得できるといっている。「インスタントUML」というのが可能になる。コードを書いてボタンを押せば、そのコードのUMLが出てくる。これはデベロッパにとってとても魅力的なことだと思う。

――XDEは、WebSphere Studioや.NETに対応していると聞いている。

 Javaと.NETの両方に対応している。Javaに対応したものとしては、1つ目にWebSphere Studio Application Developer(WSAD)に統合して利用するバージョンが用意されている。2つ目には、WSADを持っていない人のために、XDE本体にWebSphere Studio WorkbenchというEclipseのサブセットを組み込んだバージョンが用意されている。.NETに対応したものは、Visual Studio .NETに統合して利用するバージョンが用意されている。

――Roseとのすみ分けはどうなるのか?

 VS6のユーザーはRoseを、Visual Studio .NETのユーザーはXDEを選択することになる。また、JBuilderやVisual CafeのユーザーはRoseを、WSADのユーザーか、IDEを持っていないユーザーはXDEを選択することになる。これが、対応の可否から見たすみ分けだ。

 コードを書かない設計者は、Roseだけを使うことになるだろう。Roseで設計したモデルをXDEに持っていきコード生成することは可能なので、設計者と開発者でツールを使い分けることが可能だ。ただ、XDEにはXDEモデラーというバージョンが用意されている。これはXDEからコード生成の機能を除いたものであり、このXDEモデラーを設計者に使っていただくこともできる。

 XDEとRoseの最も大きな違いは、先も述べたようにXDEはパターンをサポートしていることだ。パターンを使いたいのであれば必然的にXDEを採用することになる。

 もう1つ、XDEには大きな機能がある。それはRUPのサポートだ。Rational Suiteで提供しているRUPは非常に大きなものだが、XDEでは、J2EE、.NETそれぞれにカスタマイズされたRUPがサブセットとして組み込まれている。RUPはプロセスのフレームワークだ。RUPの中には組み込み系の開発や、ビジネスモデリングなど、いろいろなものが入っている。その中で必要なものをコンフィグレーションしてお客さま向けに提供するわけだ。

 例えば、デベロッパは要求管理は必要ない。省いてあるか簡潔な表現に変えている。設計から実装、テストの部分に焦点を当てて、その中で.NETの開発のガイドラインを組み込んだものがRUP Configuration for .NETだ。

――最後に、ソフトウェア開発を成功させる秘けつを教えてほしい。

 アプリケーションを作るためには3つのことが必要。まず言語が必要、それはUMLだ。そして、その言語をサポートするツールが必要、それはRoseとかXDEだ。次に、どうやって作業を進めるかを教えてくれるプロセスが必要だ。それがRUP。この3つをそろえないと、アプリケーションの開発は成功しない。

“UMLが目指した目標は達成された”

ALT James E. Rumbaugh 米ラショナルソフトウェア フェロー

――UML以前は、OMT法やBooch法など、さまざまなモデリング手法があった。UMLに統一しようという動きになった理由は何か?

 当時のビジョンは、たくさんのメソッドがありすぎてユーザーはどれを使っていいのか分からなかったし、ツールもそれぞれにあった。だから1つのメソッドに決めて、みんな同じものを使えるようにしたかったというのが理由だ。例えば、電気技術者はみな同じメソッドを理解していて、世界中同じように仕事ができる。それをソフトウェアエンジニアにも当てはまるようにしたかったのだ。

――UMLが目指した目標は達成されているか?

 ゴールとして考えていたのは、皆が同じモデリング言語を使うということだったので、その点で成功していると思う。OMTやBoochはもう使われていない。UMLは大学でも教えているし、さまざまな論文でも使われている。UMLを使えば誰もが理解できるという状況になったので、今後ますます皆が使うことになっていくだろう。

――今後、UMLはどのように変わる?

 枠組みは同じで、必要なところがあれば変えていく。次のUML 2.0では、3つ大きなものが追加されることになる。1つは、クラスやコンポーネントの内部構造をより詳しく定義できるようになる。もう1つは、メッセージシーケンスチャートに基づいたシーケンス図。通信業界で標準とされているMSC(Message Sequence Chart)が基になっている。これは以前のシーケンス図よりパワフルなもので、構造化されたプログラミングに適している。3つ目としてはアクティビティ図が改良される。ビジネスワークフローをより適切に表現できるようになる。

――J2EEや.NET、Webサービスの登場でUMLはどう変わっていくのか?

 新しいテクノロジは常に検証しているし、UMLとの互換性をチェックしている。UMLが正しく作られているとすれば、新しい技術に基づいて原則の部分を変更する必要はないはずだ。ただ、新しい技術を検証し、UMLを拡張する必要がある場合は行う。

――これからUMLを、モデリングを学ぶ人に対して、ベストな学習法を教えてほしい。

 まずオブジェクト指向のコンセプトを学ぶことだ。それを理解したうえでオブジェクト指向の言語、例えばC++やJavaを勉強する。それが分かったら、簡単なUMLの本を読んでみることだ。最後に実際にツールでUMLを使ってみること。何かを学ぶにはまず使うことが重要だ。

 言語を最初に学ぶ理由だが、言語を知っているということは、すでにUMLのコンセプトを知っていることになるからだ。ただ、自分の知っている言語にフォーカスしすぎると、その言語の一般的でない細かいところにこだわってしまうという危険性もあるので、注意が必要だ。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ