|
[2007 年 5 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、株式会社グルージェント代表取締役の栗原傑享さんです。 栗原さんは、DIコンテナ Seasar2 で有名なオープンソースコミュニティ Seasarプロジェクトの 運営支援を行うNPOの代表理事でもあり、 公私にわたり2つの組織を運営されています。さらに、IPA未踏ソフトウェア創造事業にも採択されたWEBテンプレートエンジン Mayaa の開発をはじめ、 第一線のJavaエンジニアとしても知られています。経営者、エンジニアとしての人とのつながりの大切さから、SI企業、オープンソースコミュニティが今後とるべき戦略についてまで、自由に語っていただきました。
 |
|
-- 最初に現在のお仕事、活動についてお聞かせください。
私の日常業務は会社経営であり、その一方、ボランティア活動としてオープンソースコミュニティに関わっています。 会社全体としての日常業務はソフトウェア受託開発なのですが、私は会社の非日常業務である、経営全般が仕事です。多くは問題解決と意思決定で、 幸いに会社が順調だと、私自身は結構自由な時間が取れることが多いのですよ。 そこで残りの時間を使って、NPOであるSeasarファウンデーションを運営したり、オープンソースソフトウェアの開発をしたりしています。
-- Seasarファウンデーションでは、どういうことをされているのでしょうか？
色々と歴史的な経緯はあるんですが、現在の状況を話しますと、SeasarファウンデーションはNPO法人です。このNPOは、誤解を恐れずに言うと、コミュニティそのものではなくコミュニティに対する持ち株会社のようになっているんですよ。 つまりコミュニティの「運営」ではなくて「支援」、さらには知的財産権の管理に目的をシフトさせています。その中で、私は法人の代表者（代表理事）をつとめさせていただいてます。具体的な役割としては、これまでは組織の設立でした。 2005年12月に内閣府管轄でNPOの設立を認証していただけたので、以降は組織経営が役割です。
コミュニティのほうは、まずSeasarプロジェクトという、法人格はもたないボランティア組織があります。同じようにして、 The Ashikunep Kotan、NTTデータイントラマートさんより寄贈いただいたim-OSSC、 それから近日に立ち上がる予定で準備を進めているescafe.orgがあります。
NPOの狙いはつい最近に明らかにしてきたことで、以前はNPOがソフトウェアを開発する主体と位置づけていました。そのため、組織運営だけでなくソフトウェア開発についても意思決定しているような、 立場が明確でないようなところがありました。現在コミュニティであるSeasarプロジェクトのほうはチーフコミッタのひがやすをさん に頂上の意思決定者となっていただいて、私の方はSeasarプロジェクトを支援する仕組みの提供と知的財産権の管理に徹しています。
-- グルージェント創業とSeasarファウンデーションの代表就任、それぞれの時期的な位置づけを教えていただけますか。
グルージェントは1999年創業です。Seasarに関わる活動自体は、2004年春頃からやっていましたけど、Seasarファウンデーションの代表になったのは、NPO設立準備時期である2004年の11月頃ですね。 創業から2、3年というのは何かとバタバタしていましたが、会社が少し落ち着いてきて、さてこれからどうしようかな、というときにたまたまファウンデーション代表理事をやる機会があったわけです。
-- どういった経緯で、Seasarファウンデーション代表をされることになったのでしょうか？
Seasarそのものの歴史は結構長く、ひがさんが2000年頃から開発していました。Seasar0、Seasar1というものがずっとあって、今のDI×AOPフレームワークであるSeasar2に生まれ変わったのが2004年の正月くらいです。 私はSeasar2の開発の最初から1ユーザーとして期待していたのですが、Seasarが時流に乗り、周囲にもS2Daoのようなキラーフレームワークが登場するようになって、 コミュニティが大きくなりだしました。イベントなどでも常時100人以上の規模になってしまいましたし、ソフトウェアも企業の中核システム構築に採用されるようになってきました。
そんな中、無策にボランティア組織運営していくのも、その継続性や透明性に将来問題が生じることが予想されてきたわけです。少なからずお金も動く中で、法人格が必要であると考えるようになりました。ボランティア組織の法人として、 NPOが良いのではないかというアイディアと共に、微力を尽くしてみましょう、ということで代表をやることになりました。
-- 栗原さんは最初は1ユーザとしてSeasarコミュニティに参加された訳ですか？
もっというと、当時からコミュニティの中心メンバーだったひがさん、羽生さん*1とは10年来の付き合いでした。そういう意味では、コミュニティにはSeasar以前からそうと気がつかずに関わっていたこともあったかもしれません。
しかし、記憶してるのは、そのとき予定している案件で、当時IoC（Inversion of Control）コンテナと言っていた*2ようなものが欲しいなと思っていたんです。たまたま羽生さんとお酒を飲んでいて、 「最近IoCコンテナというのが気になっていてね〜」なんて話していたら、羽生さんから「あれ？ この前ひがさんが同じようなこと言っていた気がする」というような話になったのです。 後日、羽生さんに確認してもらったら、まさにひがさんがSeasar2を作ろうとしていたところでした。すぐに「欲しかったのはそれ！ あ〜、ひがさん久しぶり」みたいな（笑）。
それからひがさんが昼夜となくSeasar2を開発してくださって、それを私はML上で多くの人たちといっしょに叩いて試し、フィードバックし、こういう機能が欲しいな、 というようなことを1ユーザとして好き勝手に言っていった。そのようにSeasar2が出来上がっていく中で、私はコミュニティの空気を堪能していたのでした。
*1 株式会社スターロジック代表取締役の羽生章洋氏。 最初期からのSeasar立役者であり、Seasarファウンデーション理事（現在は退任）。
*2 軽量コンテナは当初IoCコンテナと呼ばれていたが、マーチン・ファウラー氏の批判（ 『Inversion of ControlコンテナとDependency Injectionパターン』）によりDIコンテナと改名された。
-- 栗原さんは元々文系だったそうですが、どういったきっかけでプログラミングのお仕事をされるようになったのですか？
私は大学では商学部で、会計学の専攻でした。大学4年生の夏には金融機関への内定が決まってほっとした後、それまでアルバイトをしたことがありませんでしたので、ひと夏の出会いでも求めようかとアルバイトをすることにしたのです（笑）。 しかし、本命のハンバーガーショップ等は当時思った以上に時給が低く、高額なアルバイトとして目についたのがプログラマでした。その中でも就業経験が無くても会計の知識があればOKという求人があったので、 応募した。それがビジネストラストという会社で、当時は立ち上がり早々の社員2〜3人という会社でした。
就職活動をする前までは公認会計士になる夢を持ち、TACという会計資格の学校に少しの間、通っていました。すごい偶然なのですが、ビジネストラストの社長が、 そのTACでの私の先生だったんです。面接のときに「はじめまして」と言いながら、実は知っていますよと（笑）。そういう顔見知りの安心感もあって、がんばってやってみようという気持ちになりました。
-- どういったお仕事だったんですか？
アルバイトの内容は、Visual Basicを使って連結会計のパッケージを作るというものでした。やってみると、面白い。書いたものが動くっていう楽しさですよ。また動くものが出来上がってくれば、周りからも期待されていく。 興味が広がっていく中でソフトウェア開発を仕事にしたいなっていう思いが強くなり、内定辞退して、もう一年大学に残りつつアルバイトを続けることにしたのです。 大学は計画的な留年で週に1時間行くだけでしたから、概ねずっとプログラミングをしている生活です。
そうやってアルバイトをしているときに、Delphiに出会いました。ちょうどWindows 95が出たころでしたから、インターネットではなくパソコン通信な頃です。Delphiの情報はニフティサーブにしかなく、 Borland公式運営のフォーラムに接続しては、一生懸命情報収集していました。しかし、当時のBorlandのフォーラムにはDelphiの会議室が1つ2つしかなく、一方でDelphiは大人気になりつつありました。 会議室のログ流量がとても多く、雑多に整理されない状態となってしまったので、会議室の中では専門のフォーラムがあるといいというような期待も出てきました。 そんな中、中途半端な学生でとにかく暇だった私が自然と発起人になり、Delphi専門のフォーラムを立ち上げました。 実は今のSeasarの古参メンバーにはDelphiユーザもいらっしゃって、ひがさんや羽生さんとはこの頃からニフティサーブにてお付き合いが始まっています。
特に羽生さんとは、Delphiのちょうど1年後に、いっしょにBorlandのJavaIDEであるJBuilderのフォーラムを設立した時に密に連絡を取り合っていて、大阪在住の彼と、東京に住む私の間で、 毎週のように何時間も電話で相談したりしていました。
-- その辺のご経験が、のちのSeasarファウンデーション設立へと繋がっているのですね。
それはあると思います。フォーラム設立というのは、成功体験としてちょっと威張って言いたくなるようなものでしたから。
-- Delphiに興味をもたれたというのは、やはりオブジェクト指向に魅力を感じられたからですか？
オブジェクト指向というのは後付け的なところがあります。Delphiのクラスライブラリ（Visual Component Library）は、非常によく出来てるなぁと思いました。 先にVisualBasicを触ったときには、ポトペタでこんなことができるんだ、という衝撃がありました。しかし半年ほどVisualBasicを書いていると、なんか物足りないなと思うようになった。 自分が書いたコードを見直してみるとどうも美しくないなと、何度も作り直したくなってくる訳です。そうやっていろいろ追求してみる中、どっかで限界にぶつかって、VisualBasicというツールの問題に気づいたんですよ。
専門誌などでVisualBasicの対抗軸のように取り上げられていたのがDelphiでした。最初にDelphiに触ってみたときは、簡単なことはできても少しでも複雑なことをしたいときにはどう書いていいのか全く分からない。 ところが触っていくうちに、知れば知るほどオブジェクト指向というものが背後にあることが分かってくる。これは良く出来てるなぁと。そういった状況をとても面白く感じていました。 振り返ってみると、自分のプログラミング知識が深まっていくのと、Delphiという新しい言語製品を取り巻く環境が目の前で萌芽し徐々に広がっていくのとが、まったくペースが同じでした。 このタイミングでプログラミングにのめりこめたのは、とても幸運でした。 ニフティサーブで知り合う新しい人的チャネルも含め、ものすごく刺激的な毎日でした。
-- 会社の創業期について、お聞かせいただけますか？
先ほどTACという会計資格の学校が出てきましたが、グルージェント創業の一番初めのお客さんがTACで、そこのPOSレジの刷新という仕事をやらせてもらいました。お客さんは当時上場を前提に社内システムの刷新を検討されていて、 「どうせ大手に頼んでも、あなたみたいな方がやるんだろうから」という考えの担当の方で、以前生徒として授業を聴いていたりその後のビジネストラスト経由の縁もあった私にやらせてもらえることになりました。 大変なご厚意をいただいて、計画していた会社設立に時期に仕事をあわせてもらえました。そうした流れで、会社のスタートアップは結構スムーズできました。
-- それはDelphiベースで？
そうですね、Windowsが採用されたOLE-POSレジ上にDelphiでソフトを作るというものです。その時に人数が足りないので、Delphiユーザフォーラムのつながりで、 古川正寿さんにお願いして一緒にやってもらいました。彼は著書*3も多い方ですが、フルネスという会社を経営しています。 私はそこの非常勤取締役ですが、同様に古川さんにも創業期にグルージェントの取締役に就任いただきました。
それからこれは脱線なのですが、アルバイトをしていたビジネストラストですが、こちらは今はグルージェントの親会社になっています。
-- ほぅ、そうなんですか。
2004年春、SeasarにのめりこんでEclipseプラグインを作ったりしている時に、市況がとても調子悪かったんですよ。要はITバブルが崩壊して、いよいよ仕事がないねっていう時期がありました。 それまでなんとか黒字ではやれていても、バブル期にあったような夢物語が怪しく、我々のようなソフトウェア受託開発では事業が倍々に拡大していくっていうような楽観的な未来もないというのが見えていた時期でした。 ビジネストラストの社長とご飯を食べている時にそんな話をしたら、「それならうちが増資するよ」と。それで親会社になってもらった訳です。結果としてそれまでの零細な規模とは違って、そう簡単にはつぶれない会社になりました。
-- なるほど、そうですか。色々なご縁が繋がって、現在まで至ってらっしゃるという印象ですね。
そうですね。学生時代、ニフティサーブ、グルージェント設立、そしてSeasarまで、一連の人脈っていうのはすごく被っています。今の私の周辺というのは、およそ10年くらい前のところに根っこがある。 今のグルージェントのメンバーというのも、ほぼ大半がDelphiかSeasarのコミュニティで出会った人間関係です。そういう意味で、私の今できていることは最初からコミュニティベースのものであり、 その中で周囲に期待されての行動結果によるところが大きいですね。
*3 『独習オブジェクト指向開発』、 『Java 開発の実用問答集』ほか書籍多数。
-- エンジニアの中には、自ら新しいものを作って自分をアピールするのが好きな方もいれば、反対に誰かが作った良いものを見出して、 それを広めて支援していこうという方もいます。栗原さんはどちらかというと後者の方ですか？
そうですね、大体はそうかと思いますが、そうでもない事もあります。私も自分のアイデアで信じることができるものがあれば、独自にやっています。たとえば、未踏プロジェクトで採択されたMayaaとかです。 これは、ひがさんがS2JSFというプロダクトの最初のアイデアをブログで書いていた時、 いくらかの議論の後に、そのアイデアとはちょっと違う方向もあるんじゃないか、と思った訳です。S2JSFはそんな中すでに開発着手されていましたから、別行動でちょっと追究してみようと思い作ったのがMayaaでした。
-- なるほど。確かにMayaaを開発されていますものね。
アイデアがあれば、自分の手でそれをやるのはいいと思いますよ。でも、プログラミングはできるけどアイデアがない、ということの方が多い。オープンソースコミュニティの中でも、実際にオープンソースで作りたいものがある人はそんなにいない。 やはり自分の時間を費やしてもいいと思えるような、そういう思いつきはなかなかない。ましてや、思いつきで作ってみようとしたけれども、実際にバージョン0.1が出来上がるものはほとんどない。1,000や10,000のアイデアがある中の、 1つ2つの世界だと思うんですよ。
そうした中で、たまたまアイデアを思いついて、加えてそれをやり遂げる手段があればやってみたい反面、私は運営とか支援とかいう、そちらのほうが自分の本質だとも思います。 ですから先ほどのご質問ですが、新しいものを作る人なのか、それを支え広める人なのかというのは、私の場合は、自分にアイディアがあるか、他に素晴らしいアイディアがあるかという状況に応じてのことなのだと思います。
それから、私の持論があるのですが・・・
-- ぜひお聞かせください。
人間の能力って、足したらみんな100だと思っているんですよ。これは何度も、色々なところで語っていることなんですが。人間の能力を レーダーチャートみたいなもので表したら、 それぞれが色々な形になるでしょう。ただ、それらのスペック数値を全部足したら誰でも100になる、と私は思うようにしています。どんな人と接するときも、そういう前提で接するようにしているんです。
たとえばNYヤンキースの松井でも、サッカーの天才ロナウジーニョでも、様々な能力を足し算していったら今ここにいる私たちと同じ数値になるとする。能力が野球やサッカーに向けられているのか、 プログラミングの能力なのか、家庭を円満に築く能力なのか、あるいは容姿なのか。そういった違いでしかないと信じ込むことにします。
そういう中で、先ほどの話に戻りますと、プログラマにして初発のアイデアをゼロイチで形にするのが得意な人もいれば、コツコツとしたエンジニアリングが得意な人もいるわけです。 だからオープンソースコミュニティでは、みんなそれぞれが得意なこと、もしくはボランティアなのですから、好きなことをやっていって、それを結集していけばいいのではないか、と。
-- なるほど、そういうことですね。
そういう意味では、それぞれの領域で能力の高い人をうまく配置してやっていく、ということが組織では重要になってくると思います。 たとえばMayaaでは、ゼロからイチへの初発のところは私が作ったわけですが、次に、ひまわり証券という証券会社さんへ導入するという案件があったために、今度はものすごい高負荷に耐えるためのハイアベイラビリティ（高可用性）への施策や、 ドキュメントの充実といったことが必要となりました。しかし私のレーダーチャートの中では、パフォーマンスチューニングやドキュメント整備については、特別高い能力数値の部分ではなかった。 そうなると、そういったことをやる能力やモチベーションのある人間に委ねた方がいい訳です。
今、Mayaaの開発リーダーは、須賀さんという人に委ねていますが、とても素晴らしい仕事をしています。メーリングリストでのユーザからの質問にも懇切丁寧に応えてくれていたりして、なかなか私の真似できない能力とメンタリティを持っている。 同じように他の方と私の間にも、それぞれ互いに能力を補完し合う部分というのはあるでしょう。その後、須賀さんはグルージェントに入ってもらいました。そうなると私は彼の生活を保障しなければならないわけです。 そしてそれは私の出来ることでした。
-- 始めの方でも説明いただきましたが、Seasarファウンデーションの下には個性のあるコミュニティがいくつもある訳ですね。
そうなんですよ。ポートフォリオとして見ると、ファウンデーションが持っているコミュニティというのはなかなか面白いですよ。
まず、Seasarプロジェクトというのは、自然発生的に出来上がったフラッグシップのコミュニティですね。これはあまり手がつけられない（笑）。製品は現在70弱あるし、コミッタも一生懸命やっている方が120人以上もいる。 一方でThe Ashikunep Kotanは、ごく限られたコミッタだけの閉ざされた世界です。1.0としてリリースされた製品がまだ1本もないのでユーザーがゼロ人という、コミュニティとも言えないコミュニティがあるわけですね。 もう1つはim-OSSC。イントラマートさんから寄贈いただいた、企業ベースのバックエンドがあるコミュニティですね。そして準備中のescafe.orgです。
最後のescafe.orgというのはですね、前回の染田さん、西岡さんが開発した、 TuigwaaがSeasarプロジェクトから卒業というか、移籍という形でユーザ層のターゲットを再設定しなおして、新しいブランドでやろうとしているコミュニティです。 Seasarプロジェクトを母体としてやっていたものが、成長してスピンアウトし、新しいブランドを立ち上げる。そういったモデルをやってみようとしています。
-- 他ではなかなか見当たらない、ユニークなことをされていますよね。
たとえば、Apacheは違うんですよ。私の知る限りでは、The Apache Software Foundation は大きくひとつのApacheブランドに統合されています。 jakarta.apache.org ならありますけれど、jakarta.org ではないですよね。 一方で、Seasarファウンデーションの場合は、seasar.org、ashikunep.org、intra-mart.org、escafe.org が並列して存在している。その上で、運営のさまざまなことについては、 NPO法人のSeasarファウンデーションが一元的に継続的かつ透明にやっていこうという考えです。
なんでこうした戦略をとっているかというと、利用者は多様だからです。同じオープンソースソフトウェア手法で提供されていても、Seasar2の利用者とTuigwaaの利用者は性格が異なると思います。 システム開発の現場で使われるものと、出来上がりのアプリケーションとして事務職の方につかってもらいたいというようなものでは、丁寧な施策を考えるのであれば別に取り扱ったほうが良いと思っている。 また、沢山プロダクトがあれば、コミッタの中でも色々な考えがあります。基本的に優秀なほど仲が悪いんですよ、みんな。
（一同笑）
自分のアイディアがある方は、自分の思い通りにやりたいということが多いようなのです。ひがさんにはひがさんの考えがあるし、Tuigwaaの2人だって、やっぱり個性がある。 そうした考えや個性を全体にあわせて調整するのもいいのですが、大抵の場合はみんなバラバラにやってもらったほうがすごいことを達成しそうな予感がでてきます。 そのときに本当にバラバラでやっちゃうと、毎回々々それぞれがコミュニティの仕組みなどの雑多なところから立ち上げていかないといけないですよね。 同じファウンデーションの下ではあるけれども、ブランドだけ違うという形にすれば、箱は違うけれどもすぐ立ち上げられます。コミュニティモデルをイチから毎回作るっていうのは、結構しんどいですよ。
それから、Seasarが嫌いな人もいますからね。
-- そういう方もいらっしゃいますか？
おそらくいるでしょう。Seasarっていう名前が自分の美的センスに合わなくて嫌だ、ダサいとか（笑）。コミュニティの雰囲気など感覚的な部分で合わない人もいる訳ですよ。 極端には、とにかく既製のものには馴染めません、という方々がいたとしても、参加してもらいやすい仕組みを模索してみたい。参加者がどんどん増え、コミュニティがどんどん立ち上がり、 いろんな素晴らしいアイディアが1,000も10,000も実現していくという。そうやってオープンソースソフトウェアを取り巻くもの全体が発展して行ければいいと思っています。
-- 組織運営の観点から、非常に参考になりますね。
かなり意識的に実験をやっていると思いますよ。こういった思惑で動いているというような組織は、オープンソースソフトウェア開発コミュニティに限ると、たぶん無いと思います。
-- 最近やられているThe Ashikunep Kotanというのは、どういった試みということになるのでしょうか？
The Ashikunep Kotanについては、ちょっと色々な狙いがあってですね。作ったはじめは「オープンソースコミュニティとはなんぞや？」というところを追究したいと思っていたのです。 オープンソースソフトウェアというものが見切れていない、よく分かっていない部分が沢山あるものですから。 The Ashikunep Kotanでは、コミュニティの最終的な理想形を先に描いてしまってですね、そうした企画立案の中から始めてコミュニティを形成できるものなのか、というのを試してみたかったのです。 つまり、製品が1個もなくコミッタが1人もいない状況で、まずコミュニティの枠だけ作ったらどうなるのか、ということを試したかった。
幸いにして、今でこそSeasarファウンデーションのリソースを使って運営できていますが、最初は全く独立した1プロジェクトとしてスタートしました。 縁のあった法政大学情報科学部さんにお願いしまして、 そちらでサポートいただけるということになりましたので、まず立ち上げてみようと。結果としては、今のところまだ軌道に乗ってはいないのですが（笑）。
-- なるほど。プロダクトありきでのコミュニティではなく、むしろ先にコミュニティから作るという試みだったんですね。
そうです、要は成長手順の実験ですね。だから、コミュニティやソフトウェアそのもののニーズがあってやっている訳ではないんです。
逆に、Seasarは自然発生的にできたプロジェクトです。DIコンテナだけには限りませんが、あるソフトウェアを作るというニーズがあってからやっている訳じゃないですか。 そんな中、コミュニティ運営者としては、ニーズがあってコミュニティが発展したっていのは、実は結構難しい状況なんです。プロダクト群とコミュニティが大きいと、 コミッタ、ユーザーの利害関係が先に出来上がってしまって、運営は後追いになってしまいます。バージョン1.0が世に出ちゃった後では、なかなか手を打てなくなるんですよ。
たとえばライセンスをどうするかとか、コミッタ間で守りたいルールや、その他さまざまな場面での判断基準しかり。Seasarプロジェクトについては、 色々と抜本的な改革を繰り返し試みようとして来たのですが、最後、踏み切れずになかなか手を打てないということが多いのです。
そういうことがあったので、ゼロから組み立てた人工的なコミュニティをやってみたかったんです。私たちの間では、The Ashikunep Kotanは手垢のついていないサイボーグコミュニティだ、なんて言っています。
-- それでは、The Ashikunep Kotanでは具体的にどういったプロダクトを作っていくご予定なのでしょうか？
Seasarとは相対するというか、今のSeasarプロジェクトの流れとは真逆とまではいかなくとも、方向性の違う技術を一生懸命やろうとしています。そこで私が目をつけたのは、コンパイラを中心とする技術です。
ちょうどMayaaのハイアベイラビリティなんかをやっていたときに思いついたのですが、今のJavaのフレームワークってリフレクション全盛なんですね。実行時に計算して、対応するという。DIコンテナしかり、 O/Rマッピングフレームワークしかり。リフレクションというのは、一面柔らかくて便利なんですけれども、その分コストが高いんです。ハイアベイラビリティのチューニングをしたときに、 当然他にもやることは沢山ありましたが、1つのテーマとしてリフレクションを減らしていくということも検討すべき課題となりました。ではリフレクションを限りなくゼロにしていったらどうなるだろうかと。
リフレクションをなくすためにはどうするかといってはじめて、コンパイル時のソリューションを考えました。The Ashikunep Kotanでは、どうせゼロから現在のニーズ無視ではじめるのだから、 今は流行ってないようだけど、このコンパイラ技術の上で一花咲かせてみたい。リフレクションのない世界、というものがあってもいいのではないかと思ったのです。
-- リフレクションについては、お客さんからも結構突っ込まれることが多いんですよね。性能面でのリスクがあるんじゃないのか、という。でも、一方で大規模でもかなり使われているじゃないですか。
方針はそれぞれあると思います。システムの性能よりも、むしろデベロッパの工数削減や、とにかく量を稼ぐことに重点を置きたいのであれば、リフレクションを使ってもいいでしょう。 また、本当にリフレクションをなくすことがパフォーマンスに寄与するかも、よくわかっていない。けれども、私がたまたま関わってきた案件（Mayaaのチューニング）では、 リフレクションを減らすことで結果が出たこともありましたので、まず追求してみるべき、と考えました。
開発メンバーが面白いことを言っていました。「今日やれることはみんな今日やる」。これをプログラミングの世界で徹底したら面白いのではないか。開発時、コンパイル時というのは今日です。 アプリケーションを使うのが明日。リフレクションの場合は、アプリケーションを動かす最後の日になって色々とやる訳ですよ。今日できるだけ仕事しておけば、明日は楽なんじゃないか。 JSR 199*4、 JSR 269*5といった仕様にあるように、 Javaの新しい流れとしても、コンパイラやJVMをもっといじれる方向へ機能が拡張されていってます。もっとコンパイル時にやれることがあるのではないかということです。
別に、コンパイル時にいろいろやるという考えが流行らなくてもいいんですよ（笑）。The Ashikunep Kotanとしては野心を秘めつつも、大いに普及するような成功を収めなくてもいい。 ただし、DNAとして違うものがないと、環境が大きく変化したときに全部ダメになってしまう。環境変化に生き残れるように、技術的な逆張りも用意しておかなければいけないんですよ。 そういった意味で、今のSeasarの逆にわざわざ張ってみたのです。
-- 目的によって、取捨選択すればいい訳ですからね。
そうですね。今芽が出なくても、5年、10年後に芽が出るかもしれない。やはり、「Practice makes Perfect」というように、やり続けることが強みです。
*4 JSR 199: Java Compiler API。Javaプログラム中からJavaコンパイラを呼び出せるようにするためのAPI。
*5 JSR 269: Pluggable Annotation Processing API。コンパイル時にJavaアノテーションを処理する仕組みを提供するためのAPI。
-- Seasarプロジェクトにはコミッタが120人いるとおっしゃっていましたが、中にはフルタイムでオープンソースをやられている方もいるんですか？
ひがさんを含め、120人のうち20人くらいはフルタイムでやっているのではないかと思います。オープンソースソフトウェアの世界で、昼間にやれるというのは強いですよ。 平日は朝から晩まで仕事をしてヘロヘロになって、土日にイベントがあっても仕事で行けるか分かりません、というような状況だとなかなか積極的にはオープンソースに絡めないですから。 平日に仕事でオープンソースをやれる人は、そうでない人に比べて圧倒的な立場の強さがありますよね。
-- しかしオープンソースを昼間にするというのは、現実にはなかなか難しいところがあるんじゃないでしょうか？
そうは思いません。私は、SIは宿命的に暇な時間が多いビジネスだと思っているんですよ。SIは可能な仕事量が頭数に限られますし、それぞれ案件も期間が違いますから、 売り物として難しいんですよね。やれなきゃ無理して案件取ったって仕方ありませんし、だからしゃかりきに営業もしない。1人が一ヶ月だけ手が空いているときに、都合よく 1人で一ヶ月の仕事っていうのはありませんから（笑）。派遣ビジネスだとそこで無理に切り売りされちゃうでしょうが、受託開発に徹するとそうはなりません。 グルージェントでは年間7割くらいの稼働率で、残り3割は暇です。御社もそうではないですか？
-- 私なんかは、まさにそういう立場ですよ（笑）。
その年間何割かの暇な部分というのを、どう有効に使っていくかが重要だと思います。オープンソースに投資していく、というのも1つの手です。 みんな昼間からコードを書け、その代わり夜はちゃんと家帰って、風呂に入って、自分の枕で寝ろ。プログラマにそういう生活をさせてあげれば、 健康も損なわないし、色々な強みが出てくるはずだと思います。
それから、意外と世界は近いですよ。Seasarの世界戦略というような大それた話では全然ないのですが、Seasarコミッタの方が作ったものが、世界の水準から見てもレベルが高いものだったりするんです。 日本では卓抜したアイデアが出ないから、人のアイデアを盗むだけだなんて言う人がいたとしても、それなら丁寧で緻密なものを作ることを一生懸命やればいい。 私は日本にアイディアマンも結構いると思っていますが、どうあれとにかく得意な領域で付加価値の高いものを作りつづけることで、日本のソフトウェア業界が発展してゆけるのではないかと思います。
普通の規模の会社でシステム開発を行うとなると、たいていは系列の大きな仕事の中で一部をやるという形になるのかもしれませんが、そこのギャップを乗り越えて、 やり方を変えてですね、人のできないこと、やりたがらないことをやるようにしていけばいいんです。たとえば、ハイアベイラビリティのチューニングを専門に請け負うとか、 なかなか人の手が挙がらない最先端技術とか、御社だったらオブジェクト指向の教育というのもありますよね。そういう形で、 オープンソースが得意なら十分に仕事にしていけるのではないか。もちろん得意じゃなければダメですよ。
-- エンジニアとしても、また管理職としても非常に勉強になるお話をありがとうございます。
-- 最後になりますが、若手エンジニアへのメッセージをお願いします。
まず1つ目ですが、人間の能力は全部足すと100だ、というお話をしました。その中で人間だれでも自分の得意とする強みをもっています。 これから自分が生きる道を選ぶときに、どうせなら自分の得意な道を選んで欲しいと思います。自分が能力のない道を選んでも上手くいきませんから、 能力を発揮できて花開く道を選んで、そこで社会貢献をして欲しい。そして、そのためにも自分の強みは何なのかを一生懸命探してください。 能力の総和が誰も100なら、誰でも何か強みはあるはずですから。少なくともそう思うようにして欲しいです。 私も組織運営したり、ゼロイチのソフトウェア開発をしたりしていますが、結局その2つのスペックでしか勝負していません。
野球はものすごい好きなんだけど下手だというなら、野球のジャーナリストになる道がありますね。同じように、ソフトウェアは大好きなんだけど、 コードを書くセンスはないというのだったら、それはそれで活躍の場を探してみてはいかがでしょうか。 たとえば、コンピュータが好きじゃなかったり、プログラム書くのが不慣れな人はこの業界は向かないですよ。 無理して出来ないプログラミングをするよりは、もっと創造的な価値の高い仕事はあるはずですから。
私が見ていると、プログラマの皆さんは生きるのが下手な人が多いです。
-- 多いですね。精神的に参ってしまう人もかなり多いそうです。
周りの情報が少ないのか、主体性が足りないのか、どうして勝てないところから抜け出せないのか。損な方向に損な方向に行ってしまっている人を、よく見かけます。 ぜひ自分のスペックの高いところをポートフォリオとして組んで、勝てるところで自分の人生というものを形成してもらいたい。 みんな不慣れなことをやりすぎなのではないでしょうか。
それから最後に、もう1つアドバイスですが、あんまり頑張りすぎちゃダメですよ。
たとえば昼間は仕事でデスマーチに巻き込まれていて、夜や土日は家でオープンソースのコードを書いているというのは、やはり余裕が足りないと思うんですよ。 まず、健康的で衛生的に、楽しく人生を過ごすことの方が大事だと思います。家族など、自分以上に大切なものを持つことも実りあることです。 その上で自分の活躍できる道を見極めて邁進し、日常に余裕を作り、余裕が出来ればぜひボランティア活動をしてもらいたいです。 その活動がオープンソースソフトウェアに関わるものであるかどうかは、ほんの些細なことです。
| ©2007 OGIS-RI Co., Ltd. |
|
