 |
[2006 年 7 月号] |
|
[2006 年 7 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、株式会社 電通国際情報サービス (ISID) の 比嘉 康雄 さんです。 比嘉さんは、DI コンテナフレームワーク Seasar2 を中心とした、日本発オープンソースプロジェクト Seasar ファウンデーション の チーフコミッターとしてご活躍されていらっしゃいます。今回はその Seasar プロジェクトや、開発手法に関する考え方などについて、お話をうかがわせていただきました。
|
|
-- まず最初に、現在の業務についてお話していただけますか？
弊社でこの 4 月より「Seasar2 技術推進グループ」が新しくできました。そこで主に、弊社の中での Seasar2 を使ったプロジェクトへの支援や、商用サポートなどをやっています。 あるいは、ちょっと会社の仕事には関係ないんですけど、Seasar プロダクトの強化もやっています。
-- 基本的には技術的なリーダーをされているのでしょうか？それともマネジメントが中心ですか？
時と場合によりけりで、会社ではマネジメントとして判断することがほとんどです。 Seasar ファウンデーションではチーフコミッターとしての役割がありますので、 技術的な立場の方が大きいかもしれないですね。
-- では、Seasar についておうかがいします。はじめに、なぜ Seasar を作ろうと思われたのでしょうか？
2000 年頃から最近まで、社内フレームワークの開発に関わっていたんです。が、社内で作るフレームワークには、やはり結構限界がある。使ってくださるユーザーの数も オープンソースに比べると少なく、あまり思い切って意見を言ってくれなかったりする。そういう意味で、オープンソースというものについて興味があったんですね。
あと、友人の羽生さん *1 にオープンソースのアプリケーションサーバ Enhydra や JBoss などについて教えてもらって、「面白そう、じゃあ作ってみようかな」と思ったのが、 一番最初のバージョン Seasar0 (S0) なんですね。S0 は面白半分で作って、最初はそれで終わっていたんです。その後半年ほど経ったときに、羽生さんから「J2EE サーバや、 まして EJB のような重いのはいらない。コネクションプーリングやトランザクション管理ぐらいができる、ライトウェイトなアプリケーションサーバが欲しいんだ」と言われて、 その案件に S0 が使われたんですね。
このときは、この案件だけの「クローズドソース」でした。が、案件そのものがうまくいったので、だったらオープンソースとして公開しようということで公開したのが Seasar1 (S1) というバージョンですね。その後、S1 を大きく作り変えるきっかけがあって、そのころ一番面白そうだったのが DI だったんで、じゃあ DI コンテナを作ってみようかと思ったのが Seasar2 (S2) の始まりになります。*2
-- S1 より以前に、何かオープンソースの活動に関わっておられたのでしょうか？
1998 年か 99 年頃、AWT や Swing とデータベースを連動するための JDBC のコンポーネントを作りました。
こちらについては、
『詳説JDBCコンポーネントプログラミング』という本も書いています。
それをオープンソースとして公開したのが最初ですね。
まだ オープンソースも Java もそれ程メジャーではなかった頃です。*3
-- Seasar2 は、オープンソースプロジェクトとして成功していると思われますか？
成功してるかどうかというと、わかりませんというのが素直な意見です。ただ、Seasar2 のコミッターは 50 〜 60 人ほどいて、 オープンソースプロジェクトの中では世界有数のプロジェクトですね。
-- Seasar2 はプロダクトごとに個人の範囲がきっちりと決まっていて、他のプロダクトに対してあまり手を出すことが無いように感じられるのですが。
私はそれぞれの人が自分の自信のある範囲でやればいいと思っています。オープンソースにはジェネラリストではなくスペシャリストが求められているので、各分野の プロフェッショナルがその分野をやる。浅く広くやってもらうよりは、スペシャルでこの機能だったら俺は世界に負けないよというプロダクトを出してもらったほうが、 私としてはうれしいし、世の中はそういう人を求めているでしょう。どこにでもあるようなオープンソースのプロダクトがあっても、あまりうれしくない。それよりは、 DI だったら他の誰にも負けない、Web フレームワークだったらどこにも負けないというものがあった方がいいと思っています。
-- 比嘉さんご自身は Seasar2 のそれぞれのプロダクトをどれほど把握されているのでしょうか？
基本的にはプロダクトのリーダに任せています。そのリーダが各プロダクトを知っていればよく、私がすべてのプロダクトの進行状況を把握する必要はないと思っています。
-- プロダクト間の依存関係はないのですか？
基本的にないです。依存関係があるとしたら、Seasar2 の DI コンテナにはみんなが依存してるところがあるので、DI コンテナとのリレーションはきっちりとりますけども、 それ以外のプロダクト同士にはほとんどないですね。
-- Seasar2 は今、どのようなプロジェクトや業務で適用されているのでしょうか？
たぶん、好きな人が好きなように使うのがオープンソースの特性なのでユーザがどのように使っているかはわかりません。私が聞いてる限りでは、Web アプリケーションで 使ってる人がほとんどですね。中には Swing やコマンドラインで使っているというのも聞きます。業務でいえば、最近は金融機関が多いですね。
-- Seasar2 が使われている Web アプリケーションは、やはり軽めなものが多いのでしょうか？
そうだと思います。軽く簡単に作りたいという案件の方が多いですね。サーバや接続先が多いとか、超ミッションクリティカルなシステムでは、そもそも Java が適切なのかという問題も ありますし、DI やフレームワークが使用されているケースは少ないのではないでしょうか。
-- ミッションクリティカルなシステムでは一部でようやく J2EE が使い始められたぐらいのレベルだと思うので、確かにそうかもしれないですね。
*1 羽生 章洋 氏：株式会社スターロジック 代表取締役兼 CEO。現在Seasarファウンデーションの理事を務める。
*2 Seasar 誕生については、WEB+DB PRESS vol31 号 「Seasar2 徹底攻略 第 1 章 Seasar ファウンデーションの概要」(羽生氏) に詳しい
*3 オープンソースの普及に重大な影響を与えた論文 「伽藍とバザール」 の発表から 2 年ほど経て、国内ではオープンソースがリスクを承知で使用され始めた頃である。
-- Seasar2 は金融系業務で使われることが多いということなのですが、やはりデータベース中心のシステムが多いのでしょうか？
一般的にはそうなんじゃないかなと思います。最近は計算が多いシステムでも使われ始めているようですが。
-- 比嘉さんは、ビジネスロジックはステートレスで作る方がいいよ、とよくおっしゃっていると思います*4。これは、データ中心型のシステムだと 悪くないアーキテクチャだと思うのですが、計算中心の場合は、振る舞いとデータの両方を持つ、古典的な OO スタイルの方がいいのかなとも思えるのですが。ステートレスがいいと思っていらっしゃるのはなぜでしょうか？
メモリ上にしか存在しないオブジェクトだったら、多分、データと振る舞いが一緒の方がいいと思うんですが、オブジェクトの状態がデータベースに格納されているような場合については、 データと振る舞いを分けたほうがいいんですよ。なぜかと言うと、そういう場合のデータと振る舞いは開発のライフサイクルが違うから。データベースはそれほど変わらないけど、 業務ロジックは変わっていきますよね。そういった開発のライフサイクルや変更のタイミングが違うようなものは、目的が違う。逆に言うと、メモリ上のオブジェクトなら、 データが変わるときとロジックが変わるときは、ほぼ同じタイミングでライフサイクルも一緒、変更のタイミングも一緒なのでそれは多分一緒に管理すべきもの。それだけの違いだと思うんですよね。
-- なるほど。あと、Seasar ではよく DTO (Data Transfer Object) が使用されますが、これはプレゼンテーション層とサービス層を別々のチームで開発す べきだと考えられているのでしょうか？
昔はそうだったのですが、今は考え方は違っています。基本的にはチームを機能ごとに分けて、 最初から最後まで同じ少人数のチームで、3 人ほどで全部を一緒に開発したほうがいいと思っています。
-- では、プレゼンテーション層だけをオフショアで開発する、ということは無いのでしょうか？
今はオフショアに出すよりも、全部自分たちで開発したほうが開発効率はいいと思ってます。私が目指してるのは「セル型生産」*5で、上流・最初の工程からテストまでを 全部 1 チームでやった方がいい。途中をどこかに出すと、コミュニケーションロスによって変なものが出来上がってきて、そこでまたやり直しがあって。そういうことを考えると、全部を少人数で 開発することはできないですけど、ある程度機能を切り出して機能ごとに少人数で開発していく方が、オフショアよりも開発効率がいいんじゃないのかなという風に思っていて、今そのための 準備をやっています。
-- その場合は、ユースケース単位でチームが分かれるのでしょうか？
そうですね。あるチームが複数のユースケースを抱えるということはもちろんあると思いますが。ユースケースの中で分業するのはきっと効率が良くないでしょう。
*4 この文脈では、プロパティを持たないクラスにビジネスロジックを記述することを示している。
*5 セル生産システム。一人または少人数のグループが ひとつの製品をすべて製作する方式。主に製造業で使用される用語である。
-- ではちょっとお話を変えまして、オブジェクト指向との出会いについてお話していただけますでしょうか？
実はあまりオブジェクト指向は好きではないんですね。別に嫌いでもなく、何がオブジェクト指向なのかというのがよくわからないというのがあります。さっき、データと振る舞いを分けるかという 話がありましたが、何でもデータと振る舞いを一緒にするのがオブジェクト指向だと思っている人もいる。それは私はきっと間違いだと思っています。より目的に応じた、 できる限り単機能で、より単一の目的のものが集まって、協調しながら 1 つの大きなことをするということがいいと思っています。
できる限り機能がシンプルであればいい。そういう意味で言うと、ケントベックの XP の基本 *6 の、できる限りテストをしやすくするとか、 クラス数をできる限りシンプルにするなどの考え方は大好きなんです。
-- そうなんですか。では、好き嫌いはともかく、初めてオブジェクト指向技術やオブジェクト指向の考え方に出会ったのはいつ頃ですか？
Delphi が最初だと思います。
90年代はクラサバ (クライアント・サーバ型システム) の時代でした。4GL の登場後に、クラサバの VB などがあって。 その後、Delphi を使うようになって、そこでコンポーネントって何？ということを学んだという感じですね。
-- ビジネス系のクラサバから始まって、その後 J2EE へ、という流れでサーバーサイドの仕事をされてきたのですね。そうです。
-- 比嘉さんにとって XP との出会いは結構大きかったですか？
はい、大きかったですね。
-- 私が初めて比嘉さんにお会いしたのは、XP ユーザグループのイベントで講演されたときだったのですが、 やはりかなり早い頃から注目されていたのでしょうか？
XP は、平鍋さん*7が執筆された JavaWorld の XP 特集 が一番最初ですね。これを見て「おもしろそう。プロジェクトでやってみようか」と思ってやってみたんですよ。
-- いきなり大規模なプロジェクトで使用されたんでしょうか？
どれほどの規模を大規模というかは微妙ですが、100 人月ほどですね。
-- XP は、やはりシンプルなところに惹かれたんですか？
シンプルさだけだと仕事にどうやって生かせるかどうかが微妙で、個人の価値観によっても変わってくるんですが、「テストをしっかりやってる」という点にも惹かれましたね。 テストをしっかりやると、結合テストなどでエラーが起きにくくなる。そもそもデグレードが起きにくくなる。
私の経験として、前はテストが通ったのに今テストをやってみると通らない、ということが良くあったんです。少なくともそういうことがなくなれば、プロジェクトの開発効率というか テストフェーズでの大変さが無くなると思っています。それはぜひやってみたい。テストをきっちりすることだけでも、すごくビジネス的にはメリットがあるなあというのが、私の XP に対する考え方ですね。
*7 平鍋 健児 氏。ＯＯエンジニアの輪！ 〜 第６回 平鍋健児さんの巻 〜 に登場いただいている。
-- XP のテストファーストに出会って、設計の方法は変わりましたか？
ユーザと仕様を決めているところが外部設計、そのあと自分たちの中で持って帰って設計するのが内部設計という風にすると、 お客さんと仕様を詰める外部設計のところはそんなに変わらないかな。
-- 内部設計については変化したのでしょうか？
内部設計は変わってますね。今は、割と始めに動くコードを書いてることが多いような気がします。
昔は、まずはテスト仕様書が入ってくるんですよ。テスト仕様書があって、内部設計書があって、それをもとに実装していく。XP を取り入れた後の場合は、そもそもテスト仕様書を書かなくって、 JUnit でテストコードを書いて、JUnit のコードがテスト仕様書でしょう、という進め方になってきたんですね。そうすると設計書が割と軽くなるというか、同じようなことを書いてもしょうがないので、 JUnit のコードが大きな比重を占めている、というのがあると思いますね。
-- 例えばオブジェクト指向言語で開発するのであれば、テストを先に書くことで、より使いやすいインターフェースを設計できるようになる、という変化があると思います。 クラス設計そのものが変わったなどの変化を感じられたことはありますか？
そういう意味で言うと、やはりクラスがちっちゃくなるんじゃないですかね。たくさん書いてテストするというか。テストするときにたくさん書くのが大変だから、できるかぎりクラスを ちっちゃくして、機能単位にばらす。
そういう意味ではクラスの設計の仕方もちょっと変わってるんでしょうけど、そもそも「クラスを設計する」という意識がないんです。最も単純なユースケースから書いていって、 ばらしながら最終的に出来上がっているという感じなんですね。どうやって設計するかということを最初に考えてないから、そういう意味では発想の仕方がぜんぜん違うのではないでしょうかね。 クラス図などを考えたことがありませんし。
-- そうなんですか。まったく考えないんですか？
まったく考えない。XP が出てから、というわけではなく、昔からクラス図などは基本的には気にしません。
-- 例えば、クラス図をツールで描くのは嫌だとという人はたくさんいると思うのですが、全く描かないというのは珍しいですね。
設計ができないっていうのが正しいのかな。ソースを書かないとわからないんですよね。ソースを書きながら考えています。書く前に考えてもどうせきっと外れるでしょうって思っているので、 ソースを書く前は考えないようにしています。
-- コードを書く途中ではどうですか？
イメージはありますね。ソースを書いてる時、一番最初はわかんなくって、自分が一番わかっていそうな機能からとりあえず書いてみる。で、少しずつできてくると、「あっこういうふうに 使えばいいんだな」と思えてくる。ある程度できあがってくるにつれて、大体こんな感じっていうのがわかってくる。完成の半分くらいまでは少しずつ機能を積み重ねていって、半分くらいまで ソースが書けた後はだいたいわかるようになります。
-- 比嘉さんのそのスタイルだと、仕様書ありきの開発プロセスではかなり辛いのではないでしょうか？
そういう意味で言うと、仕事として、仕様書を書いてから何かをやるということは、ほとんどやったことがないですね（笑）。 仕様書のレビューなどはやっていましたが。
-- 頭の中に、こういう感じかなあという、ぼんやりとした設計のイメージはあるんでしょうか？
基本はインターフェースで分離します。Seasar2 もコード自体がそういう考え方でできているので、私の感覚に近いですね。以前はインターフェースもどうでもよく、機能はできるだけシンプルで わかりやすければいい、という考え方でした。Seasar2 のコードを書くようになってからは、コード量はある程度増えても疎結合してテストをしやすくする、という感じで書いているんですよ。
-- チーム開発という観点では、これまで例えばどのような方法で設計を行われてきましたか？
1998 年頃に行った、クラサバのサーバサイドの業務ロジックを組み立てるという仕事では、私が思いつきでパラパラと話したのを、みんなでレビューしながら洗練させていくというスタイルで開発を 行っていました。そういう意味で言うと仕様書を先に書いているんですが、この頃はホワイトボードを使って、最初にインターフェースを書いて、ここはこんな感じで処理するという機能分割を最初に決めていました。ただ 1 度でで決まることはなくて、何度もレビューしながら都度変わっていきましたけどね。
-- 比嘉さんご自身の仕事上の大きな転換点は何でしたか？
一番最初の転換点は、クラサバ案件でオラクルに触れたことですね。それまではホスト系の AS/400 *8 の案件などをやっていたのですが、何がなんだかわからなかったんですよ。 何となく書いたら動いてる。過去に作られたものを真似すれば動くんですが、最終的にどのように動いてるかわからないし、本当に動かなくなったときにどうすればいいのかがわからない。テクノロジ的にはそれほど 強くなかったのが、私の若い頃なんですね。それは嫌だったんですけど、情報を得ようと思っても世の中に存在しなかったので、勉強のしようがなかったんです。
1996 年頃、オラクルを使用した開発をしたのですが、マニュアルなどからまとまった必要な情報が手に入るのがうれしかったですね。「クラサバのサーバサイドってこうやって開発するんだ」って。 ここで技術を吸収して、技術者っぽくなりました。
-- 最初はテクノロジに強くなかったという点がすごく意外です。その頃はどちらかというとビジネス寄りだったのでしょうか？
そもそも技術は好きじゃなかったんですよ。最初は経営コンサルになりたかった。企業の問題を解決することをやりたくて、企業の問題を解決するためにはシステムをわかってないといけないので、 最初に業務 SE という仕事をとりあえずやってみようかと思ったんですね。お客様がしたいことに対して、最も適切なソリューションを考えていく。これは非常にやりたかったことで、 できればいいかなと考えて入ったんです。本当は業務 SE よりももうちょっと上流に入りたいと思っていましたけどね。
-- その後、技術志向になったきっかけがオラクルの案件だったのでしょうか？
技術志向、というわけではなかったのですが、その頃、周りには結構技術に強い人がいて、その人たちによく負けてたんですね。「動かない」「どれどれ見せてごらん」という感じで、直してもらっていたのが悔しかった。 技術が好きではなかったんですけど、負けず嫌いなところがあったからですね。あと、いつも人に頼らないと仕事ができないのでは良くないなという気持ちもありました。 技術的なところも人に頼らずにできるようになるまではやりたいと思って、勉強したのがオラクルの案件でしたね。
-- 今は、チャンスがあれば経営コンサルタントなどのもう少しビジネス寄りのお仕事に踏み込んでいきたいなと思われているんですか？
今も昔もそれほど変わらず、ユーザのニーズを叶えたいんです。解決の方法はいろいろあると思うんですよ。技術的なものでもいいし、業務的なものでもいいし、何も作らなくても組織の仕組みを 考えたりするなどしてもいいし。その中の 1 つとして、少なくとも今はシステムのことで何か解決するのであれば得意になりつつあるので、そういうのももちろんやりたいです。それ以外のことについても ソリューションの提供として出来るようになりたい。どれがどれっていうことではなく、要は解決すればいいぐらいの感じですね。手段はいろいろあると思います。
-- そのように「人が抱えてる問題を解決したい」という思いを抱くようになったきっかけは何ですか？
私はすごく推理小説が好きで、子供の頃から少年探偵団やホームズやルパンなどを読んでいました。最初に謎があって、途中途中に謎を解くための鍵がいくつかあって、それをうまく見つけて エンディングを探し出す。そういうことがすごく好きだったんですね。
システム開発のお客様のニーズは、ある意味「謎」というか、解かなければいけない問題ですね。いろんなヒアリングをしながら、そこに謎を解くためのキーが隠されている。それをうまく結びつけて、 最終的な答えを導き出す。これは多分、子供の頃好きだった、推理小説を読んでるのと同じような感覚です。
-- パズルのような感覚でしょうか？
そうですね。そういう感覚がすごく好きだったので。特に分野にはこだわらないですね。
*8 ホスト系システムの代表的なサーバ製品。IBM 社製の現 iSeries の旧名称。
-- 休日の過ごし方をお聞かせいただけますか？
休日は仕事をしてるというか、オープンソースの活動ですね。家にパソコンが無いので、休日出勤するなと言われると困ったりするんですよ（笑）。じゃあどうやって Seasar の開発しようかということになりますから。
-- 趣味をお聞かせください。
趣味はワインと、今だったら英語ですね。
-- なぜ英語なのでしょうか？
オープンソースで特に感じてるのは、やはり関わる人、知り合える人が多ければ多いほどより多くのアイデアが出ることですね。コミュニケーションが多ければ多いほどいい。今だと日本だけの範囲ですが、 それを世界に広げるためには英語が必要になるでしょうと思いまして。で、必要だと思うんだったら、楽しんでやる方がいいから、本当に趣味だと思ってるかは別にして、 自分には趣味だというふうに言い聞かせてるわけですよ（笑）。
-- 楽しいですか？（笑）
楽しいですよ。そういうふうに思い込んでるので（笑）。
-- ワインについてはどうでしょうか？
ワインもパズルを解くのといっしょなんですよ。私は大学生の頃、ワイン学校に通っていたんです。そこでの勉強の仕方としては、まず前半は知識を得るために、あるテーマをもとに教えてもらいます。 後半は、そのテーマを元に実際にテイスティングをするんですが、そのときにブラインドテイスティングをするんですよ。容器に何が入っているかわからないものを出されて、これに対するコメントをして、 最終的にあなたはこのワインは何だと思いますか？と聞かれる、クイズのようなものです。
何かわからないものを最初に出されますが、そこにいろんな鍵が隠されているんですよ。色だったり、香りだったり、味だったり。例えば色が濃ければ、なんで色が濃いのかというと、お日様をいっぱい浴びると 皮に色がどんどんついてくるんで、そこから作るワインの色も濃くなるんですね。色が濃いとすごくお日様が当たるような地域でつくられたワインなんだなっていうのが、最初見たときにわかったりします。 そういう感じでいろんなヒントを得て、最終的に過去の自分の経験に照らし合わせて、「じゃあこれは何？」というのを当てる、そういうクイズというかパズルが非常に面白い。
ソムリエにどういう人が向いてるかはわかりますか？
-- わかりません。
多分一般的には、すごく味覚が優れた人がソムリエに向いてるという風に思われている、と思うんです。私も答えを知っているわけではないんですけど、私の経験から言うと、自分の感覚を言葉にすることが できて、その言葉をもう一回再現できる能力が高い人がソムリエに向いてると思うんですよ。たとえば、この手元のグラスだと紅茶の香りがするんですが、こういう香りは紅茶の香りだと頭の中で覚えて 言葉で表現できないと、後から思い出せないんですよ。香りや味など、記憶をできる限り引き出せる人がソムリエには向いてる、と思います。
実はオブジェクト指向などの世界でも同じようなことが言えます。例えば、デザインパターンは、こういう風にするとうまくいきますというパターンに名前を付けているからこそ、それを引き出せる。 ワインのテイスティングについても全く一緒で、名前を付けています。自分で言葉にできてそれを記憶から引き出せるから、何度も何度も再現できる。 そういう意味で、いろんなものに対して、自分の周りにある現象をきっちりと自分の言葉で話すことができて、話したことについては記憶することができるといいのかな、と思います。
-- Seasar2 の名前についてはどうですか？ 「2」というとバージョン名にも感じられますが。
Seasar2 はもうあのバージョン固定で、あとどれくらい経っても Seasar は 2 ですよ。世の中の人の頭の中に Seasar2 が叩き込まれていて、そのように認識されているので、変えるつもりはないです。
-- もうバージョン番号ではなく固有名詞の一部のようなものでしょうか？
そうですね。それでいいんじゃないですかね。Seasar2 の名前について私自身がこれでいいというのではなくて、みんなに「これでいいよ」って思ってもらえるんだったら、それでいいと思っています。
-- 最後に、若手エンジニア・学生へのアドバイスをお願いします。
昨日、「ビューティフルマインド」という映画を見ていたのですが、この主人公が一番最初にすごく苦悩しているんですね。 誰にも負けないオリジナリティを持つにはどうすればいいかと、学生時代に非常に悩んでるわけです。そういう感じで、まずは人と違う何かを常に考えることが重要なんじゃないのかなと思っています。 ただし、最初からオリジナルの何かを思いつける人はきっといないと思うので、最初は世の中の良いものといわれているもの片っ端から真似して、覚えていくのが重要だと思います。
そういう意味で言うと、今の世の中は、オープンソースがかなり普及していて、手本になるものがいっぱいあると思うので、それを若いうちにたくさん見たらいい。いろんなものを大量に見ていると、 ある一定のパターンが大体見えてくる。そこである程度積み上げていくと、あとはどこかで自分なりのオリジナリティがいつの日かひらめくんじゃないかな。私もできてないところがたくさん あるんですけど、私を含めてそういうふうになりたいなと思います。
-- 比嘉さん自身は若い頃そういうことを意識されていましたか？
私が若い頃には、そもそもオープンソースが一般的ではなかった。 勉強したかったけど勉強しようがなかった、そういう時代でした。インターネットも普及していなかったし、情報も少ない時代だったので。 今は情報はいっぱい手に入る時代で、その中でさらに真似すべきこと、参考にすべきこともいっぱいあるので。私の頃はできなかったんですけど、今はそういうことができるようになっているので、 やってほしいなと思いますね。
| ©2006 OGIS-RI Co., Ltd. |
|
