UMLを考案した三人のうちの一人であるIvar Jacobson氏 （画像のクリックで拡大）
「ソフトウエア開発者はみな，プロセスの話題が嫌いなはずだ。重いプロセスでは，開発者が押しつぶされてしまうことがある。もうプロセスの話題はたくさんだ」――。UMLを考案した，いわゆる「Three Amigos」の一人であるIvar Jacobson（イヴァー・ヤコブソン）氏は今，こう語る。
Jacobson氏は，いわずと知れたソフトウエア・エンジニアリング分野の重鎮だ。スウェーデンEricsson社のソフトウエア技術者時代に「ユースケース」の概念を着想したほか，シーケンス図やコラボレーション図を考案。その後，Ericsson社を退社して独立，スウェーデンObjectory ABを創業し，ユースケースを基にしたソフトウエア開発方法論「OOSE（Object-Oriented Software Engineering）」をまとめ上げ，提唱したことで知られる。Objectory社はその後，米Rational Software社に買収され，そこでJames Rumbaugh氏やGrady Booch氏らとともに，ソフトウエア・モデルの表記法「UML」を開発した。また，Objectory社時代に考案した開発プロセス「Objectory Process」を基にして，Rational社時代には「RUP（rational unified process）」の開発に関わった。
ソフトウエア・エンジニアリング分野を牽引してきた同氏は今，自身が創業したコンサルティング会社，スイスIvar Jacobson International社のChairmanおよびCTOとして，世界中のソフトウエア開発現場を飛び回る。講演に合わせて来日した同氏に，現在の活動とソフトウエア・エンジニアリング分野の展望を聞いた。（聞き手＝進藤 智則）
――「RUPのような巨大なプロセスはもう必要ない」と主張されていますね。
Jacobson氏 私がRational社に入社したとき，我々はObjectory Processというプロセスを持っていました。Objectory Processは，RUPよりシンプルです。そういう意味では，RUPは最終的にヘビーになりすぎたといえるでしょう。
1990年代に我々はRational社でRUPを開発しました。そして，このプロセスを製品として企業に販売していました。1500ページもある分厚い本を，2万2000米ドルもの値段で売っていたのです。世界一高い本といえるでしょう。それでも合計600冊も売ることができました。販売目標は1000冊でしたが…。
しかし，人々は分厚い本というのは隅々まで読まないものです。特にそれがプロセスに関する本であればなおさらでしょう。結局，みんな本を読んでくれないので，自らが世界中を飛び回って説明することになります。例えば，インドではCMMIを使ったプロセス改善が盛んですが，そんなインド企業ですら，実際に訪問して確認してみると，プロセスが好きな技術者というのはいませんでした。RUPは決して悪いものではないのですが，あまりにも膨大すぎました。
――今の会社で，より軽量でシンプルなプロセス「EssUP（essential unified process）」を作られたのはそういう経緯ですね。
Jacobson氏 そうです。2003年にIvar Jacobson International社を設立した後，よりシンプルなプロセスであるEssUPを開発しました。EssUPは，有償のRUPと違って，無償で利用できます。Ericsson社時代に私が着想したアプローチが発展して，Objectory Processが生まれ，それが「UP（unified process）」になった。そして，それがさらにRUPになった。最後に，このEssUPが出てきたというわけです。
EssUPが登場するまでの流れ。Ivar Jacobson氏の講演資料。 （画像のクリックで拡大）
ソフトウエア開発では，まったく新しい概念というのはそれほど多くはありません。重要なのは，いかにシンプルにするかです。プロセスに関しては，開発作業の何もかもを記述するのではなく，エッセンスこそが重要なのです。
EssUPを作成した時，人々が分厚い本を読まないということは十分に分かっていました。そこでEssUPでは，より親しみやすくプロセスを習得できるよう，解説本ではなくカードを使うことにしました。EssUPでは，技術的なプラクティスとして「アーキテクチャ」「反復」「ユースケース」「コンポーネント」「プロダクト」の五つを，技術トピック以外の横断的なプラクティスとして「プロセス」「チーム」「モデリング」の三つを用意しています。ソフトウエアの開発において必要なこれらのプラクティスの勘所を，5インチ×3インチの大きさのカードに短く簡潔にまとめてあります。各プラクティスは必要なものだけ使えばいいですし，自分で追加するのもいいでしょう。
EssUPにおけるプラクティス。Ivar Jacobson氏の講演資料。 （画像のクリックで拡大）
ただし，こうしたカードは，講演やワークショップの場などでは特に有用ですが，実際のソフトウエア開発では紛失してしまうなどの問題もあります。そこでIvar Jacobson International社では，EssUPへの取り組みを支援するフレームワークとして「EssWork」というツールも用意しています。これも無償で使うことができ，日本の大手企業でも利用実績があります。
――「重いプロセスは必要ない」と気づいたのは，いつころだったのでしょうか。
Jacobson氏 プロセスはもはや本質ではありません。さまざまなプラクティスが複合的に絡み合った結果，二次的に出てくるものだと捉えるべきです。プラクティスというのは，ソフトウエア開発上のさまざまな問題を解決したり，アプローチしたりするための方法，工夫のことです。例えば，反復型開発，ユースケース駆動開発，ペアプログラミング，ワークショップのようなチーム・プラクティスなど。これらはすべてプラクティスといえます。
こうしたプラクティスは，ソフトウエアを開発している組織には自然に存在しているものです。しかし，これまでそうした工夫や方法を分かりやすく精緻に表現したものはありませんでした。2000年ころにXPのようなアジャイル方法論が認知され始めたことで，「複数のプラクティスを組み合わせ，複合的に利用すると良い」という考え方がようやく認知されるようになった。EssUPで採用している「カードを用いる」というアプローチも，XPの「ストーリー・カード」から来たものです。
私はアジャイル方法論から大きな影響を受けています。1999年にXPが登場した当初，多くの人々が「XPなど重要ではない。単にペアプログラミングとか，そういったたぐいのものだ」と言っていました。私は当時から「XPはRUPに対する大きな脅威になる」と周囲に公言していたのですが，あまり理解されませんでした。
私自身がアジャイル方法論に強い興味を抱くようになったのは，IBM社を出て，Ivar Jacobson International社を設立した2003年のことです。この年の8月，米国のニューオリンズで「XP/Agile Universe 2003」というカンファレンスが開催され，私は初めて出席しました。
アジャイル方法論には，XPやScrumを始めとしてさまざまな流派がありますね。「軽量なプロセスを採用している」，「社会工学（social engineering）に焦点を当てている」などの共通点や，いくつかの違いがありますが，すべての流派に完全に共通しているのは，「アジャイル方法論者は皆，おしなべてRUPが嫌い」という点です。
――EssUPの中で，エージェント技術の「WayPointer」は，どのような位置付けなのでしょうか。
Jacobson氏 ソフトウエア開発の8割は，あまり頭脳を使わない作業でしょう。何らかの形で以前，やったことがあるなと…。 こうした場面で，コンピュータ上のエージェントがソフトウエア開発を支援するのがWayPointerの目的です。
EssUPでは，各プラクティスは，カード以外にも数ページの「ガイドライン」によって補足説明がなされていますが，WayPointerは開発のフェーズに応じてさらに開発者をガイドします。インドのTata Consultancy Services社では，WayPointerを使うことで，分析フェーズで20％の生産性向上が見られました。WayPointerは有償であり，EssUPを実践する上で必須ではありませんが，より効率的にプロセスを定着させたい場合に有効です。WayPointerは，私が創業したJaczone社で開発した技術ですが，2007年4月にはこのJaczone社を，Ivar Jacobson International社に吸収合併しました。
――ユースケース駆動開発を発展させて，ユースケース駆動によるアスペクト指向開発を提唱されています（参考文献）。日本での事例はありますか。
Jacobson氏 何社かありますが，公開できる事例としてソニーのカーナビ向け組み込みソフトウエア開発が挙げられます。アスペクト指向というと，アスペクト指向プログラミング言語（AOP）の「AspectJ」が有名なようですが，アスペクト指向は何も実装フェーズに限らず，分析や設計のフェーズにおいても非常に有効です。
アスペクト指向に基づいた設計をコードに落とし込んでいく際，AspectJのようなアスペクト指向プログラミング言語（AOP）があれば確かに有用ではありますが，必須ではありません。実際，ソニーのカーナビの事例では，プログラミング言語は従来型のものを利用しています。
ソフトウエア開発では，セキュリティなど数多くの「横断的関心事（cross-cutting concern）」がありますが，これらを「アスペクト」として分離して実装することは，非常に大きなメリットがあります。オブジェクトそのものは一切変更せずに，その振る舞いを「フック（hook）」して変えられるからです。AOPの父であるGregor Kiczales氏が取り上げたのは，数あるアスペクトのごく一部に過ぎません。
私はOOSEの中で，既存のユースケースを変更せずに拡張する「拡張ユースケース（extension use case）」という概念について述べましたが，この拡張ユースケースは，まさにアスペクト指向におけるアスペクトと非常に似ています。
――Ivar Jacobson International社の日本オフィスを設立予定とか。
Jacobson氏 2008年の設立に向けて，準備を進めています。日本は，企業のマネジャー層が伝統的なプロセスや手法にこだわる傾向が強く，非常に難しいマーケットだと認識しています。ソニーのカーナビ開発部隊ような日本の当社の顧客には，現在はシンガポールやカナダなど世界各地の支社（Ivar Jacobson Consulting（IJC）社）からコンサルタントを派遣して対応しています。
