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
Grady Booch(以下GB) Rationalでは、何年も前からモダンな反復ソフトウェアプロセスを推奨してきました。反復開発は今日の主流になったと思われますか。
Mike Devlin(以下MD) 一般に、今日では反復開発は業界で最も優れた手法として認知されています。反復開発の実現を目標に掲げることに異議を唱える顧客はほとんどいないと思います。新しいシステム開発に対する堅実なアプローチだけでなく、既存のソフトウェアシステムを徐々に改善するためのプロセスまでもが、チームに提供されるからです。しかし実際には、本当の意味での反復開発を実践している顧客はわずか約3分の1にすぎません。これまでの20年間は、顧客が開発プロセスを変更し、反復/資産ベースの開発のような一段とモダンな手法を導入するのを支援することが、われわれの価値命題の大部分を占めてきました。
GB Rationalはソフトウェアプロセスの世界にどのような影響を与えましたか? RUPがツールの統合を具体化したのですか、それとも逆だったのですか?
MD Rationalは、最初期のころから考え方をリードし、ソフトウェアエンジニアリングの方向性に影響を与えてきました。1980年代前半から半ばにかけては、航空宇宙や防衛産業が顧客の多くを占めていました。あらゆる文化的変容を考慮すると、反復開発の投入は難題でした。その当時、反復開発は米連邦調達規定(FAR)や、ライフサイクルのウォーターフォールモデルを大々的に謳(うた)うFAAやDoDの両標準(これらは機能分割を大々的に謳い、データの抽象化、情報の隠ぺい、カプセル化、そして現代のOOPといったアイデアの適用は難しかった)の外に出てきました。われわれは重要な顧客との協力を進めていくうちに、反復開発とモダンアーキテクチャを実際に推奨するよう標準を変えることができたのです。
同様に、OOAD(Object Oriented Analysis and Design)の初期のころは、表記や標準同士がコンフリクトを起こすという分裂した市場がありました。われわれは力を合わせて1つの業界標準を実現し、これがUML仕様の1つになりました。最初のステップでは、「三銃士」のような形の思想的リーダー(そして市場リーダーにもなる)をRationalに招き入れる必要がありました。(当初からRationalにいた)君と、Jim Rumbaugh、そしてIvar Jacobsonの3人だ。さらに大変だったのが、業界で重要な役割を果たすベンダ(マイクロソフト、IBM、HPなど)からの支持の獲得だった。UMLが1つの方向性でまとまり、市場でリーダーシップを確立したら、正式なOMG標準も確立できるようになった。
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業界に影響を与える可能性も高くなります。また、当然ながら金銭的な見返りもあるでしょう。しかし、個人として、そして専門家としての成長も同様に重要です。価値が長く残るものを生み出すことほどやりがいのあるものはありません。
Copyright © ITmedia, Inc. All Rights Reserved.