ピーター・コードが語る開発プロセスの選び方

編集局 谷古宇浩司
2003/1/15

---

トゥゲザーソフト コーポレーション（以下トゥゲザー）会長兼創設者であり、アジャイルソフトウェア開発思想の1つのアプローチ「FDD（Feature Driven Development）」の提唱者、開発方法論の論客として著名なピーター･コード氏が来日した。IBMによるラショナルソフトウェアの買収、トゥゲザー自身のボーランドによる買収。開発ツールベンダ業界はいま、激動の渦中にある。2003年、まさに新たな年を迎えるトゥゲザーの行方は、そしてコード氏の胸中に去来するものとは何だろうか

---

　1つの質問に対し、質問者の理解度と対応する適切な回答を熟考した後にようやく口を開く。「ピーター・コードは沈思黙考を常とする学者肌の人物」との印象を初対面で受けた。鋭い目は質問者を凝視する。まずは大局をとらえる質問を切り出してみる。

――現在、ソフトウェアの開発環境が大きく変貌しています。日本ではいまだ、ウォーターフォール型の開発手法が主流となっていますが、それでも多くのプロジェクトでは、オブジェクト指向開発のさまざまな手法を実験的に取り入れ、生産性の向上を図ろうとする動きが活発化しています。あなたは、オブジェクト指向開発に関する膨大な経験と知識をお持ちですが、現在のこのような状況をどう見ているのでしょうか。

「開発プロセスというのはいわばレシピです」

コード氏　多くのオブジェクト指向開発プロセスが提案されているのは事実です。確かにプロセスは、ソフトウェア開発という作業にはとても重要なものですよ。しかし、これほどの多くの開発プロセスが提案されていても、それぞれのプロセスの自動化を支援するツールがなくては何の意味もないと考えています。そもそも、多種多様な開発プロセスが生まれ始めた時期、このようなプロセスを自動化しようとする考え方自体が存在しなかったのです。現在では、少しずつですが、プロセスの自動化に対応するツールが出始めてきました。

　開発プロセスに関する私の考えをお教えしましょう。開発プロセスというのはいわばレシピです。現在、多くの企業が展開するビジネスはITにその多くを依存しています。企業が持つ潜在的な競争力はITに大きく依存しているということです。では、潜在的な競争力を強化するために必要なITシステムはどのようなもので、いかに構築すべきでしょう。そこに開発のプロセスというものが存在するわけです。他社に勝つためには、各社独自のITシステムが必要であるのと同じように、各社独自の開発プロセスがなくてはなりません。他社と同じことをしていて、競争力を確保しようとしてもできるものではないですよね。では、独自の開発プロセスがあればいいのか、といえばもちろんそれで十分ではありません。開発作業の効率化を支援するツールは必要不可欠でしょう。レシピをサポートする道具が絶対に必要となるのです。

　コード氏は、レシピ（開発プロセス）と道具（開発支援ツール）がそろい始めたことで、多くの企業がようやく自らのビジネスに競争力を持たせる各社独自のITシステムを構築する下地が整い始めた、という。もちろん、周知のとおり、日本国内に限らず、世界各地でITは企業活動の原動力となっている。「ITシステムの構築トレンドがようやく“黎明期“に入った」とする文字どおりの意味ではもちろんない。日々進化し続けるITの技術トレンドをどん欲に吸収し続けることは、企業が競争力を確保し続けることに必要な要素となりつつある。新たな開発プロセス群と開発支援ツール群をいかに取捨選択していくのか、コード氏は自身の考えを披露する。

コード氏　ラショナルソフトウェアはRational Unified Process（RUP）を開発しました。ソフトウェアの開発方法論に関する膨大な体系です。これはこれで重要な方法論として存在していますが、標準的な方法論を各社が採用することで果たして競争力が生じるのでしょうか。エクストリーム・プログラミング（XP）、あるいは（コード氏が提唱する）Feature Driven Development（FDD）など開発アプローチは山のようにありますが、これらはすべて良いレシピを作り出すためのスターティング・ポイントでしかあり得ない、ということを認識することが重要です。つまり、企業の規模やビジネス内容といったさまざまな要素に従って、選ぶべき開発プロセスは違ってきます。さらに、選択した開発プロセスは、各社が独自にカスタマイズする必要もあるのです。そうしなければ、意味がありません。そして、重要になってくるのは、どのような開発プロセスを選択したとしても、開発を支援する自動化ツールは対応している必要があるということです。ある開発プロセスにだけ対応して、ほかのプロセスには対応できない開発支援ツールでは、柔軟な開発体制を維持することは不可能でしょう。

――あなたはFDDを提唱しています。RUPなどのほかの開発プロセスには満足できなかったからこそ、FDDというプロセスを提唱したと思います。例えば多少語弊はありますが、重厚長大型の代表としてのRUPや軽量型の代表格ともいえるXPとFDDとの最大の違いはどこにあるのでしょうか。また、企業あるいはITベンダが開発プロセスを採用する際の選択ポイントはどこにあるのでしょうか。先ほど、あなたは標準的な開発プロセスを各社が一様に採用したとしても、競争力は生まれないと指摘されましたが、そこに答えがあるような気がします。

コード氏　FDDというのはいわば「必要十分な開発プロセス」だと認識しています。膨大な体系を持っているわけではありませんが、かといって軽すぎもしない。RUPとXPの中間に位置すると考えるのがいいのかもしれません。とはいえ、私はさまざまな開発プロセスをそれぞれが対立するものとはとらえていません。その誤解を解いておかなくてはいけませんね。宗教戦争ではないのですから、どれでも好きなプロセスを選択すればよいのです。そもそも1つのプロセスに拘泥することこそが愚かしいことだと私は考えています。企業のビジネスはさまざまなスケールを持っていますし、多種多様な側面を備えています。さまざまな開発プロセスが登場するのは当然ではないでしょうか。

コード氏は、XPとRUP、FDDの相違点を図解した（クリックすると拡大）

　そして、コード氏は図を描き始めた。左端にRUP、右端にXPと記述し、その中間地点にFDDと書き込んだ。

コード氏　計画が綿密に立てられ、完璧な仕様書も作成できるプロジェクトにおいて、RUPは威力を発揮するでしょうね。開発作業を通じて、何をなすべきかが完全に把握できている状況、しかもある程度の規模を伴うプロジェクトにおいては。一方、XPは開発作業全体の計画がない、あるいは必要ないプロジェクトで有効に作用します。まったく未知の分野におけるシステム開発で構築しようとしているシステムのユーザー機能が明確に把握されていないようなプロジェクトです。これはまさに“探検”ですね。では、FDDはどうでしょうか。RUPほど完全な仕様書の必要性がなく、かといってXPほど漠然とした未知の領域に踏み込む必要のない開発案件、つまり、システムのユーザー機能は把握している状態です。これは、探検に乗り出すときの“地図”くらいに考えてください。このような案件ではFDDが効力を発揮するでしょう。FDDは、「期間」とシステムの「ユーザー機能」が明確な場合に採用すればいい。規模としては、60〜100人の規模というところでしょうか。少なくとも、トゥゲザー社内の開発陣はその程度の規模で活用しています。RUP、XPにしても必要な条件の下で活用するのが最も望ましいということです。

　開発プロセスのカスタマイズについて話しましょう。実際に開発プロセスを採用してみれば、そのままの形では使えないということに気が付くと思います。例えばRUPですが、その膨大な体系をすべて使用することはほとんどないと思います。すべてがそろっている中で、何が自社に必要な“部品”なのかを選択し、使いやすいように再構築する必要が出てくるでしょう。

　開発プロセスというのは、考案者の人格が反映されるものです。考案者が物事をどのようにとらえているかに左右されるのではないでしょうか。XPの提唱者ケント・ベック氏はすべてを事前に確定させるよりも流動的にそして柔軟に対応することを好む性格だと思います。私は開発作業の期間となすべきこと（ユーザー機能）を一応確定させ、簡略的なマップを作成することで、開発作業を短期間（FDDの場合は約2週間）で繰り返しながら、完成まで導くのが適切だと考える性格です。大規模なものは好まないし、かといって簡略的過ぎるのもまた敬遠するのです。考案者の性格は千差万別です。開発プロセスが多様な性質を持つのは当然といえるでしょう。だからこそ、選択の余地はあるし、自分の使いやすいように作り替える必要もあるということです。そのためには、開発の規模と期間、構築しようとするシステムの性格を把握すること、開発の各段階においても、プロセスを変更させる柔軟性を持つことが重要でしょうね。

――なるほど。それが、トゥゲザーの開発ツールはさまざまな開発プロセスに対応しているという話につながるわけですか。

「新生ボーランドでは、代表的な開発プロセスの指導的な立場にいる人物をスカウトしています」

コード氏　ええ。トゥゲザー、というよりは “新生ボーランド”として進めていることですが、代表的な開発プロセスの指導的な立場にいる人物をスカウトしています。具体的な例を挙げましょう。XPではもちろんケント・ベック氏が最も有名なのですが、XP関連の書籍の売り上げでベック氏に次ぐ著名人ランディ・ミラー氏はすでにボーランドに迎えています。RUPにしても同様です。

　また、トゥゲザーの製品は、現状でもいろいろな開発プロセスに対応していますが、今後リリースする予定の（新生ボーランドの）新製品として、先に述べたレシピを支援する自動化ツール（プロジェクトの開発工程マネジメント）があります。過去3年間かけてトゥゲザー社内で開発が進められてきており、ボーランドをけん引する製品になると確信しています。

――最後にボーランドによるトゥゲザーの買収についてお伺いします。2003年1月には買収が完了する予定ということですが、そもそもボーランドがトゥゲザーを買収することで何を狙っていたのでしょうか。

コード氏　私は常々ボーランドのマネジメント陣の実力には尊敬の念を抱いてきました。現在ボーランドは10期連続の黒字を継続する優良企業です。一方、トゥゲザーには明確なビジョンとビジョンに基づく技術的な優位性、そして開発ツール市場で強烈な存在感を持つ製品群があります。ボーランドの強力なマネジメント力とトゥゲザーの開発力・技術力が融合することで、ほかに例を見ないツールベンダが登場することになります。私は、チーフ・エグゼクティブ・ストラテジストに就任し、社長兼CEOのデール・L・フラー氏を支える5人の幹部の1人としてボーランドの経営に参加することになるでしょう。

　この後、コード氏に「マイクロソフトがボーランドを買収する可能性がある、との米国の調査会社のレポートがあるが、そのことについてどう思うか」との質問を蛇足ながらぶつけてみた。コード氏は「小さい魚を大きな魚が飲み込むことを繰り返せば、結局、大魚数匹だけが残るだけだ」とコメントした。これはつまり、ソフトウェア開発ツール市場がIBMとマイクロソフトの独占市場となることを意味する。だが、果たしてそれが市場、そして顧客にとって良い結果をもたらすかどうか。コード氏は「現実的ではない」と一笑に付した。

[関連リンク]
トゥゲザーソフト コーポレーション
【Keyman Interview】ソフトウェア開発のスタイルは変革期を迎えている
【Keyman Interview】ソフトウェア部品の再利用は夢なのか？

IT Architect 連載記事一覧