Development Style Round Table Talking
第3回 オープンソースとエンジニアの決意
浅海智晴×平鍋健児×原田洋子×村田真

構成 谷古宇浩司（編集局）
2003/12/26

---

オープンソース・ムーヴメントは果たして、才能あるエンジニアを“食わせる”ムーヴメントといえるのだろうか。今後の若手エンジニアへのエールを含め、現在のソフトウェア開発業界に活を入れる。Development Style Round Table Talking 最終回。　→第1回 オブジェクト指向の弱点、第2回 日本発の独自技術を開発する

---

◆ 既存の開発プロセスが持つ矛盾を解消する

浅海　私が行っているプロジェクトの成果物の1つとして考えているのは、「Relaxerサービス・フレームワーク」と名付けたシステム構築の枠組みの作成です。「Relaxer」を含めた既存のオープンソースのプロダクトを組み合わせて作成していきます。もう1つは、「Relaxerプロセス」とでも呼ぶべき開発プロセスを作成することです。

原田　私は「Relaxerサービス・フレームワーク」におけるユーザーインターフェース（UI）を担当しています。フレームワークにはJavaServer Faces （JSF）を使おうと考えていまして、その上に載るWeb UIをRelaxerで作ろうとしているところです。Relaxerを利用した一種のテンプレート・エンジンを想定しています。

平鍋　僕の場合は、できるかどうかは別にして、プロセス・ガイドラインの作成にかかわっていきたい、と思っています。僕がいま、一番力を入れているのはきちんとした開発プロセスを作るということなんですね。その絡みもあり、オブジェクト指向プロセス、特にXP（eXtreme Programming）に注目しています。XPというのは、どちらかというと、ヒューマン・スキル系あるいはコミュニケーション・スケル系という枠組みで語られるプロセスで、例えば、会議の仕方、チーム・ビルディングの方法などに力点が置かれています。

　ただ、日本国内でXPのようなヒューマン・スキル系の開発プロセスが開発現場に浸透するかというと結構厳しいと思うんです。緩やかなガイドラインの下で柔軟に対応するというのは意外と難しいんですね。一方で、ある程度固いガイドラインを設定してしまう開発プロセスというのもある。今回のRelaxerプロジェクトに対する僕の取り組みというのはどちらかというと、後者の開発プロセスに属するものを作っていこうというものなんですね、XPの利点を積極的に吸収しながら。つまり、労力と時間をかけてひたすら人海戦術を展開していたことが、あるツールによってボタン一発で解決するのなら、それはそれでいいじゃない、と。頑張るべきところと頑張らなくてもいいところが最初から分離できていて、頑張るところをもっと頑張ろうよ、というプロセスができたらいいなと思っているんです。

浅海　オブジェクト指向開発プロセスを考える場合、モデル体系の話とプロジェクト管理の話は直交した概念だと思います。しかし、伝統的には、この2つの要素を開発プロセスという枠組みの中で同時に論じていたわけですね。それこそがプロセスだと。

　だから、「このモデルをあのモデルにこうやって変換する」という議論と「どういうふうにコミュニケーションして開発作業を進めるか」というような議論を一緒に論じていたんだけれど、どうも一緒くたにするのはよくないのではないか、と気が付き始めた。モデルの話とは別に、目的に応じてコミュニケーションの仕方を変えましょう、とかね。その結果、後者に焦点を当てたのがたぶんアジャイルというアプローチじゃないかと思います。

平鍋　うまくいくかどうかまだ、感触さえも分からないんですけど。でも、現場に入ると、どうしても型どおりのことをわざわざ仕様書を起こしてやっている場面がたくさんあるんですよ。それが全作業量の3割とかを占めている場合があって、それがなくなれば、それはそれでうれしいわけです。ただ、無駄な作業を省くためには、分析プロセスに手を入れなければいけないんですよ。

浅海　そこはまさに僕がRelaxerというツールを利用して改善できるところではないかと思っている点です。Relaxerを活用することを前提に考えると「要求分析」「システム分析」という作業領域に大きく手を入れることができるのではないかと思っているんですね。ただ、僕が1人でやると必ず抜けが出てくるので、専門家の方に一緒にやっていただければ、と思い、平鍋さんにお願いしたんです。

平鍋　専門家じゃないですけどね。現場の空気を入れたいな、と。

◆ 境界線をどこに引くか

平鍋　ところで、いま『Balancing Agility&Decipline』（Barry W. Boehm／Richard Turner、Addison-Wesley）という本を読んでいます。プラン・ドリブンなカッチリした方法（プロセス）とアジャイル・プロセスの損益分岐点はどこだ、みたいな話で。筆者は具体的に5つの分岐点を挙げて、それによって、自分自身にとっての「スイート・スポット」を見つけなさい、といっているんですね。まあ、とても常識的なことなんですが。

浅海　僕の問題意識も、たぶん、その本に書いてあることと同じなんだと思います。落としどころをきっちりと考えましょう、ということですね。僕が以前、開発現場で働いていてつくづく思ったのは、社内には一応、建前としてきちっとした開発方法論があり、その方法論に基づいて開発をしていることになっているんですが、実際の現場はいわゆるアジャイルみたいな感じなんですよ。しかも、制御されていないアジャイル。この辺の矛盾を仕切り直して、きちんとやっていくのは大事だと思うんですけどね。

平鍋　現在、開発現場がうまく回っていくかどうかは、デキル人がいるかどうかにかかっていますからね。

浅海　結局、優秀な人に負荷が掛かって、その結果、（その人が）病気になってしまったり。

平鍋　ある日突然、開発現場のキーマンが辞めても、仕事がうまく回っていくようにするためには、1つはXPのようなコミュニケーションとチーム・ビルディングの方法論を確立しておくことが重要なんです。もう1つは何かというと、機械化なんですよ。人がやらなくてもいいことはやらない、と。

浅海　本当のピュアな分析モデルから、ボタンを1つ押したらうまくいくというのが理想なのですが、残念ながら現実はそこまで行っていない。しかし、Relaxerのようなツールを使えば、ある種の分析モデルからは実装を生成することができます。問題は、現実の開発の流れの中でどこが機械化できて、どこができないか、という境界線を明確にすることですよね。

平鍋　そう。そこを見定め、線を引きましょうというのが、今回のプロジェクトの僕のビューなんですけどね。

浅海　だから、僕は「バリュー」という価値を認めて、「ここは自動化できますよ」「ここはできませんよ」というのを決めてしまいたいんです。

村田　バリューの復権というのは、なかなかいいメッセージですね。

◆ オープンソースとの関係

浅海　先日、IBMの米持さんが書いたオープンソースの本（『オープンソースがビジネスになる理由―勝ち組企業は何をしたか』米持幸寿著、日経BP社）を読んだんですよ。IBMはオープンソースにこんなに力を入れていて、こんなにうまくいっている、ということが書いてあるんですが、一般のエンジニアがオープンソースでどう得をするかということについては、現時点では解決されていない問題なのかなと思いましたね。

　つまり、利用者が無料で使えるというのは確実にいいことなんですが、無料で提供した人が得をするかというと、現状では得をしないんですよね。IBMのように大きな枠組みを構築できる企業は得をするかもしれません。しかも、もしもの場合は別のところでもうけて損失を補填する体力がある。しかし、オープンソースの中核を担う、あるいは担ってほしい人たち（多くの場合個人）は得をしないモデルなんですよね、いまのオープンソースというのは。この辺、どうすればいいのかなと考えてしまうんですが。

原田　日本のエンジニアは、ほとんど企業の中でプログラムを書いていますよね。営業が受注してくる案件（ソフト）を次々に書いていく。時間に迫られているし、優秀な人は、人に教えながらやらなくてはいけないし、もう手いっぱいだと思いますよ。

浅海　もったいないですよね。なので、このプロジェクトのまた別の意義としては、企業とは離れたところで集まり、プロジェクトを推進していくという形があってもいいんじゃないかという提案も含まれているんです。企業のためではなくて、純粋に個人のために開発する、あるいは開発できる環境が必要だと思うんですよ。そしてそういう環境から生まれる技術が必要であると。いまは、オープンソース・プロジェクトの成果が全部法人に還元されてしまうじゃないですか。作った人はほとんどもうかっていない、一部の例外を除いて。また、優秀なエンジニアを個人として社会的に引き上げるシステムが絶対必要なんですが、いまはそういうシステムがないでしょう。

平鍋　オープンソースとしてのソフトウェアについて、僕はアートという存在を強く意識しているんです。もちろん、インダストリとしてのソフトウェアは必要なんですが、一方で、純粋にアートとして、いいものを作りたいという意識もあるな、と。売る目的ではなくてね、ゴッホが絵を描く動機みたいな。

浅海　しかし、そういう動機だけでは普及していかないんですよ。

平鍋　確かにそうですけどね。だから、普及させていくための「モデル」が必要なんでしょう。彼ら（オープンソース・ソフトウェアのエンジニア）を食わせるというのも変ですけど。

浅海　たぶん何年かしたら、僕はオープンソースの波が来るんじゃないかと思っていてね。XMLの次は、オープンソースの波が来るのではないかと。だいぶ兆しが出始めてきた感じがします。そうするとまあ、面白い展開になるんじゃないかな、と思って。具体的にどういうメカニズムで波が起きるかは分からないけれど、波が来たときにこういうこと（Relaxerプロジェクト）をしていると、何か面白いことができるんじゃないか、と思っているんです。失敗しても、まあ、趣味でやっているからいいか、っていう感じで。

　ところで、コラボレーティブなコミュニティを作るときに、オープンにするかクローズにするかという境目を見極めるのはすごく難しい気がしますね。もちろんソースはオープンでいいんですけど、人的リソースの問題やその配置やらを考えると、完全にオープンな体制でいいのかどうか、と。現在、このプロジェクトは完全にオープンな体制にはしていないんですよ。難しいですよね、プロジェクトの作り方というのは。プロジェクトの成否について僕は、意外と「配牌」で決まる部分が大きいんじゃないかと思っていまして。「配牌」がよくないと、いくら「ツモ」（開発にまつわるさまざまなイベントのこと）が良くても結果的には難しいかなと。ただ、一度立ち上がってしまえば、うまく回っていくこともあると思うので、このプロジェクトの成果を基に、本当にオープンなプロジェクトを作るという手もありますが。
　
　そういう意味では、Relaxerの技術をいきなり世界に持っていくと、中途半端にぐちゃぐちゃになってしまうという危惧（きぐ）を持っています。例えばサポート問題。結局、日本国内である程度仕様を固めてしまってから、世界に公開していくというプロジェクト・モデルの方が安全なのではないか、と思っています。

原田　確かに、FAQは日本国内で開発をやっているだけでもたくさん出てきますもんね。海外に出す前に大枠は固めておいた方がいいかもしれません。

村田　しかし、国内で固めたものを海外にそのまま受け入れさせるという発想は、これまで失敗例が多々あるんです。やはり，国際の場で戦わないことには国際の場での成功は覚束きませんよ。

◆ 企業の決意、エンジニアの決意

編集　Relaxerプロジェクトが企業の援助を受ける可能性はあるんでしょうか。

浅海　結局、日本のソフトウェア産業が将来、外国とどうやって戦っていくつもりなのか、という決意が企業側にないと駄目なんですよね。つまり、例えば、外国で作ったものを販売代理店として契約して売っていて、「自分たちが発掘した」といって自慢している人たちが多過ぎると思うんですよ、自分たちで作ったわけではないのに。そういう人たちに、オープンソースコミュニティに貢献してほしいといっても難しいのではないかと思います。地盤から変えていくしかない。いまは地道にやっていくしかないかなぁと。日本のソフトウェアベンダ、ソフトウェアハウスを含めて、周りの状況がどう変わっていくかによるのかもしれませんが。つまり、アメリカからの輸入だけでいいと思っているのか、あるいは、そうじゃない部分が必要だと思い始めている人たちが増えてきているのか、それはいまの段階ではちょっと分からないですけど。

村田　電子政府をやっている人たちとか大学の一部の人たちはそう思っていると思うんだよね。

原田　でも、日本の企業のトップはいまだに横並び意識が抜けないですね。だれかがいいといってくれないと自分では動かない、動けない。お金は日本から集めなくても、世界中から集めればいいんじゃないでしょうか。

浅海　そうすると、わざわざ日本でコミュニティを作り、日本の良さを武器にしたい、という話とは違ってきてしまうんですよね。

原田　オープンソースで生きていくためには、母集団を大きくしないと。でも、日本でいいものが発表されれば、世界の目がパッと日本に集まって、ひょっとして、日本にいいものがあるんじゃないか、ということになるかもしれません。すると、日本のソフトウェア産業自体が活性化するんじゃないでしょうか。

浅海　そのときに、｢ご褒美｣を得ることができるかどうか、というのは最初にかけ金を支払っているかどうか、なんですよね。日本できちんと技術を育てれば、もしブレイクして外国に売り出していく場合、「すでに日本ではこんなにノウハウを蓄積しているんだぜ」というイニシアティブが持てるんじゃないだろうか、ということなんですよ。

（終了）

---

ラウンド・テーブル参加者 プロフィール

◆ 浅海智晴（あさみ ともはる） 　1985年立命館大学電気工学科卒業。同年富士通(株)入社。UNIXワークステーション/サーバのOS、分散基盤、Web基盤の開発に従事。2001年11月より浅海智晴事務所代表。現在はオブジェクト指向、Java、XMLを中心に活動を行っている。著書に「Java Super Tips オブジェクト指向設計編」、「XML/DOM Programming」（秀和システム）、「やさしいUML入門」、「Relaxer - Java/XMLによるWeb開発」、 「XML SmartDoc公式リファレンスマニュアル」（ピアソンエデュケーション）がある。代表作はJava&XMLベースのオープンソース・ソフトウェアであるXML SmartDoc(XML文書処理システム)<http://www.XMLSmartDoc.org>、Relaxer(XML/Javaスキーマコンパイラ)<http://www.relaxer.org>。 ◆ 平鍋健児（ひらなべけんじ） 　1989年東京大学工学部卒業後、3次元CAD、リアルタイムソフト、UMLエディタなどの開発を経て、現在、株式会社永和システムマネジメントでコンサルタントとしてオブジェクト指向開発を研究・実践。XPに関するメーリングリストXP-jpを運営、オブジェクトクラブを主宰。酒と映画と福井を愛する。翻訳書に「XPエクスストリーム・プログラミング 導入編」（ピアソン･エデュケーション）、「マルチパラダイムデザイン」（ピアソン･エデュケーション）がある。 ◆ 原田洋子（はらだようこ） 　1994年9月にWeb サーバ／Proxy サーバを自ドメインに立ち上げて以来、特にWeb サーバやインターネットの世界に興味をもつ。サーバサイドJavaとして後に名を馳せるようになったJava Servlet に巡り合い、Java に目覚める。現在はServlet&JSPを中心とするJavaプログラミングが本業である。著書に『Javaサーバサイドプログラミング』(技術評論社)がある。 ◆ 村田真（むらたまこと） 　1960年生まれ。1982年京都大学理学部卒業。W3C XML WGのメンバとして、XML 1.0の制定に携わる。編著書に「XML入門」（日本経済新聞社）。インターネットコンファレンス 98論文賞。国際会議WWW'99、PODDP 98、EP 98などのプログラム委員。国際ジャーナルMarkup Languagesの編集ボードメンバー。

IT Architect 連載記事一覧