
The Rational Edge
ソフトウェア開発の「いま」と「近未来」の話
Grady Booch
IBM Fellow, Rational software
2005/8/10
1ページ目|2ページ目|次のページ
The Rational Edgeより:Rationalブランドを率いるゼネラルマネージャがMike Devlin氏からDanny Sabbah氏に交替したことを受け、Grady Boochが新旧両方のリーダーへソフトウェア開発分野の目標、業績、そしてビジョンについて話を聞いた。以下のインタビューは、IBMのソフトウェア開発ブランドであるRationalの歴史と未来を理解するうえでの手掛かりとなるだろう。
IT業界に反復ソフトウェア開発手法を持ち込んだ組織のトップを24年間務めたMike Devlin氏は、IBM Rationalソフトウェア事業部ゼネラルマネージャの座を後進に譲ろうとしている。代わってRational事業部のGMに就任するのが、WebSphereブランドの元開発担当バイスプレジデントで、つい先ごろまでIBM Software Groupで戦略担当のトップを務めていたDanny Sabbah氏だ。
Mike Devlin氏は、Paul Levy氏とともに1981年にRational Software Corporationの立ち上げにかかわった創業者の1人。同社は、ソフトウェア開発関連プロセスを改善する市販環境の構築に着手し、そこから、Unified Modeling Language(UML)、Rational Unified Process(RUP)、そして今日一般に認められた最良のソフトウェアエンジニアリング手法を円滑にする多数のツールが生まれた。Rationalはその成功の印として、2003年にIBMに買収され、現在ではIBM Software Groupの5大ブランドの1つになっている。
Danny Sabbah氏は1974年にIBMに入社し、1981年にコンピュータサイエンスの博士号を修得している。IBM Software Groupには、アーキテクチャ/ツール開発担当バイスプレジデントとして参加したが、以前は通信、人工知能、プログラミング言語、およびソフトウェア技術の分野で活躍してきた。同氏は1990年代後半、WebSphereを扱うチームのトップに就任した。そして、WebSphereブランドの開発担当バイスプレジデントとして、IBMのWebや業務統合ソフトウェアに加え、IBMアプリケーション開発ツールのアーキテクチャや戦略にも関与した。
Rationalトップの座が、いずれもソフトウェア開発分野のビジョナリーだと見なされるMike Devlin氏からDanny Sabbah氏へ移ることは、IBMのソフトウェア開発ブランドのトップを務める新旧2人のリーダーにインタビューを行える歴史的なチャンスだということになる。しかも、Mikeとは米空軍士官学校時代からの友人であり、DannyのことはIBMでの輝かしい経歴が始まるころから知るGrady Boochなら、今回のインタビューに最適である。
Gradyによる以下のインタビューは、2人のリーダーの個性だけでなく、複雑なソフトウェア開発でRationalが相変わらず先導的役割を果たしている部分についても明らかにしている。Rationalソフトウェアの将来だけでなく、これまでの歴史を振り返る部分についても喜んでいただけると思う。
Mike Perrow
◆ IBM Software GroupのRationalソフトウェア担当ゼネラルマネージャを退任するMike Devlin氏に対する質問
Grady Booch(以下GB):Rationalでは、何年も前からモダンな反復ソフトウェアプロセスを推奨してきました。反復開発は今日の主流になったと思われますか。
Mike Devlin(以下MD):一般に、今日では反復開発は業界で最も優れた手法として認知されています。反復開発の実現を目標に掲げることに異議を唱える顧客はほとんどいないと思います。新しいシステム開発に対する堅実なアプローチだけでなく、既存のソフトウェアシステムを徐々に改善するためのプロセスまでもが、チームに提供されるからです。しかし実際には、本当の意味での反復開発を実践している顧客はわずか約3分の1にすぎません。これまでの20年間は、顧客が開発プロセスを変更し、反復/資産ベースの開発のような一段とモダンな手法を導入するのを支援することが、われわれの価値命題の大部分を占めてきました。
GB:Rationalはソフトウェアプロセスの世界にどのような影響を与えましたか? RUPがツールの統合を具体化したのですか、それとも逆だったのですか?
MD:Rationalは、最初期のころから考え方をリードし、ソフトウェアエンジニアリングの方向性に影響を与えてきました。1980年代前半から半ばにかけては、航空宇宙や防衛産業が顧客の多くを占めていました。あらゆる文化的変容を考慮すると、反復開発の投入は難題でした。その当時、反復開発は米連邦調達規定(FAR)や、ライフサイクルのウォーターフォールモデルを大々的に謳(うた)うFAAやDoDの両標準(これらは機能分割を大々的に謳い、データの抽象化、情報の隠ぺい、カプセル化、そして現代のOOPといったアイデアの適用は難しかった)の外に出てきました。われわれは重要な顧客との協力を進めていくうちに、反復開発とモダンアーキテクチャを実際に推奨するよう標準を変えることができたのです。
- - PR -
RUPは、われわれのすべての経験とベスト プラクティスを獲得するためのフレー ムワークを提供する。そして、RUPをツールでサポートすることにより、顧客はこれらの最優良事例を実装できるようになる。RUPは間違いなくわれわれのツールに影響を与えたが、利用可能なツール技術を実際に考慮したこともRUPに影響を与えたという。
GB:Rationalはこれまで複数のプラットフォームをサポートしてきましたが、IBMのどこに引かれたのですか?
MD:顧客の要求を受け、Rationalは(マイクロソフトやIBMをはじめ)複数のプラットフォームをサポートするようになりました。しかし、開発コストを削減し、市場参入を急速に進めるために、われわれは1つの技術アーキテクチャへと移行する必要がありました。複数のプラットフォームをサポートし、開発を加速させられるオープンな技術アーキテクチャを提供していたのはIBMだけだったのです。従って、選択に迷うことはありませんでした。IBMへの移行は、われわれの顧客にとっても、われわれのビジネスにとっても正しいことでした。
GB:なによりも重要な販売モデルの理念に「顧客の成功」を掲げた理由は何ですか。このテーマと自社の文化をどのように結び付けたのですか。
MD:Rational設立当初、顧客の成功がわれわれのビジネスの核であることは明白でした。根本的な整合性の問題に近いものだったのです。顧客が技術をうまく使いさえすれば、われわれの技術はソフトウェア経済にとてつもなく大きな影響を与えられると考えました。
顧客の成功を約束することは、われわれ自身の利益でもありました。初期のころは、航空宇宙防衛関連の大手請負業者や通信機器関連の大企業が顧客でした。どちらも競争の非常に激しい市場で、ビジネスの履行に遅滞などがあれば、すぐに業界中にうわさが広がります。顧客の成功を約束することは、規模の小さい会社にとって死活問題で、それがわれわれの企業文化やビジネス手法の最重要項目になるのは自然なことです。
初期のころは、自分たちが成功する(そして購入の継続を判断する)には人材や専門知識がツール自体と少なくとも同程度重要な役割を果たす、との指摘が顧客から頻繁にあったため、この姿勢にはますます拍車がかかりました。これにより、営業担当1人に付き3人の技術者(現在ラボサービスと呼ばれているものも含む)を現場に送り込むモデルが確立しました。成功した顧客の方が低コストで大きなビジネスにつながることは、どのマネージャも理解しました。繰り返しになりますが、顧客の成功は、われわれの会社の成功と連動しているのです。
これを慣行化するため、われわれはまず(簡単な)現場評価システムを構築し、顧客の成功を(5つのうちの)最初の評価指標にしました。これはマネージャによる主観的な評価でしたが、大半のアカウントと近い距離にいるのが現場のマネージャであるため、彼らはダイレクトなフィードバックを簡単に得ることができました。
次にわれわれは、現場の組織と顧客を成功に導くことが自分たちの仕事であることをマーケティングとエンジニアリングの部隊に確実に理解させました。そして、ほかのすべての部隊(人事や経理など)が、顧客に対応するこれらの部隊(フィールドサービス、マーケティング、エンジニアリング)に従いました。そして、顧客と顧客の役に立つことができたチームを全社に公表しました。
GB:Rationalは初期のころ、「中間表現を永続的に維持する」ことをソフトウェア開発環境の技術概念にしていました。これが、バージョンコントロールなどの各種概念はライフサイクルの補助的部分にすぎない、とRationalが考えるようになるきっかけだったのですか?
MD:リッチな中間表現(IR)に取り組んだ初期の経験から、われわれはツール内における真の意味的統合の価値を確信しました。IRを持つことで、かなり高いレベルでの統合が可能になり、自動化が大幅に進むようになりました。いまは、これをEclipse EMFによって実現しています。
この経験からは、アーキテクチャ、構成管理、ツール、プロセスの重要な相互作用も学びました。意味的統合が、構成管理やバージョンコントロールに影響する意味的一貫性の概念を持ち込むことは明らかです。しかし、アプリケーションのアーキテクチャやツールのサポートに関しては、もっと不可解な問題があります。われわれは、自分たちのツールが適切に構築された(コンポーネント化された)アプリケーションアーキテクチャを促進およびサポートできることを発見しました。しかし、適切に設計されていないアプリケーションは、コンフィギュレーションの大きな管理問題を引き起こし、自分たちのツールの力がフルに活用できないことも発見したのです。
GB:あなたは何十年もの間、国際的に活躍されてきましたが、ソフトウェアの重要性がどのように高まり、ソフトウェア開発プロセスがどのように変化したかについて意見を聞かせてください。
MD:Rational設立時には、高度成長分野を中心に経済界全体がソフトウェアへの依存をますます高めるだろうとのビジョンがありました。従って、脱工業化の新しい情報経済においてはソフトウェア開発が最も重要な技術分野でした。
世界の今日の現実は、われわれが初めに持ったビジョンが正しかったことを証明しています。今日の大半の製品(電話、カメラ、ステレオ、自動車、飛行機、医療機器など)の内部でソフトウェアが占める割合はますます増加し、設計や製造にもソフトウェアシステムが利用されています。大半のサービス(金融サービス、流通/ロジスティックス、小売、エンターテインメントなど)もソフトウェアが基本です。
高度成長、高生産性、そして参加労働力の増加は、(少なくとも米国では)ソフトウェア(そしてIT業界)の功績だとされています。ソフトウェアは世界中で国際化を加速させ、それが先進国だけでなく、開発途上国のさらなる繁栄につながっているのです。
いまではソフトウェアの重要性が幅広く認知されましたが、開発プロセスは期待するほどは進化していません。開発プロセスの改善、自動化推進、コラボレーションの拡大、国際的な人材確保、共通標準、共通アーキテクチャ、オープンソースなどの進展は、ソフトウェアの経済性を大きく向上させました。これにより、経済全体にソフトウェアが普及したのです。
しかし、多くのプロジェクトでスケジュールが遅れ、予算がオーバーし、ソフトウェアの品質低下があるなど、ソフトウェア開発の大半がいまも課題を抱えていることは周知の事実です。われわれは業界として、さらなる品質と生産性の向上に努めていく必要があります。すべての技術(すべて標準ベースのツール、プロセス、アーキテクチャ)にオープンなフレームワークを提供し、顧客、パートナー、業界組織、学界、オープンソースコミュニティなどとのコラボレーションを円滑にできるのがIBMだけであることを考えると、IBMはそれが可能な最高の位置にいるのです。
GB:Rationalを成功させるのに最も難しかったのはどこでしたか? 技術自体でしたか、開発の問題でしたか、それとも現場や納入時の課題でしたか?
MD:全体から1つだけ抜き出して「一番大変だった」と指摘するのは難しいです。私にはすべてが成功に欠かせない重要な要因に思えました。技術はかなり重要でした。予想よりリスクが高く、開発時間も長くなり、最初のバージョンを出すのはほかのバージョンより大変でした。われわれの顧客ベースが拡大し、技術が進化する中、以降の各バージョンにも難問がありました。技術知識が豊富で、顧客を成功させることに最大の努力を払い、常に業績を上げられる現場組織を整えることもかなり難しかったです。
われわれがこれらの分野で成功を収めたときにカギとなったのがチームと企業文化でした。われわれは、このミッションに高い品質と意気込みを持ち込むことができ、チームと顧客を優先するという構築中の文化に溶け込める人材だけを慎重に選択しました。適切なチームさえ編成してしまえば、後は何でも可能になりました。
GB:Rational在籍中で最も楽しかったのはどの時期でしたか。
MD:最も楽しく、自分が最も誇りに思っているのがチーム自体であることに疑いはありません。われわれは、個人よりもチームの重要性を本当に理解する素晴らしい組織を作り出しました。顧客を確実に成功させるという使命を本当に信じ、ビジネスのどの分野でも個人が責任を持つチームだったのです。結果を出すことができたのは、チームとして適切な文化を確立し、それを維持できたことが大きな要因です。
GB:最後に、ソフトウェア業界での仕事について高校や大学生などにアドバイスをお願いします。
MD:アドバイスですか? 夢は見ないことです。一生懸命仕事をし、無謀とも思える目標を掲げ、自分の主義を貫き、顧客に成果を提供するのです。もし常にこのようなことができれば、いろいろな意味で見返りが得られるでしょう。仲間にも組織にも影響を与えることができ、IT業界に影響を与える可能性も高くなります。また、当然ながら金銭的な見返りもあるでしょう。しかし、個人として、そして専門家としての成長も同様に重要です。価値が長く残るものを生み出すことほどやりがいのあるものはありません。
|
1/2 |
|
INDEX |
||
| The Rational Edge ソフトウェア開発の「いま」と「近未来」の話 |
||
| Page1 ◆ IBM Software GroupのRationalソフトウェア担当ゼネラルマネージャを退任するMike Devlin氏に対する質問 |
||
| Page2 ◆ 新しくIBM Software GroupのRational Software担当ゼネラルマネージャに 就任するDanny Sabbah氏へのインタビュー |
||
|
本記事は「The Rational Edge」に掲載された「Mike Devlin and Danny Sabbah: Rational leaders share their vision」をアットマーク・アイティが翻訳したものです。 |
| IT Architect 連載記事一覧 |
The Rational Edge
米ラショナルソフトウェアがWeb上で毎月更新するオブジェクト指向開発のための論文集「The Rational Edge」を@ITが厳選して翻訳
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|

