目まぐるしく変化するIT業界。その中でもオープンソース開発によるソフトウェアが、今注目を浴びている。「Ruby」の開発者まつもとゆきひろ氏とGoogleの鵜飼文敏氏にオープンソースを生み出す環境について、話を聞いた。

（取材・文／OFFICE-SANGA　総研スタッフ／山田モーキン）作成日：07.02.20

世界中のプログラマに愛用されているオブジェクト指向のスクリプト言語「Ruby」の開発者まつもとゆきひろ氏とGoogleの鵜飼文敏氏。オープンソース界のトップエンジニアである両者が、2007年１月20日、「リクルート　エンジニア適職フェア」のイベントにて、オープンソースとの運命的な出会いや理想のソフトウェア開発現場について、熱いトークを繰り広げた。当日の会場では立ち見となる方もいて、盛況のうちに終了したが、その一部始終をレポートしたい。

　今から13、14年前くらいに、まだフリーソフトが主流だったころ、386BSDやLinuxをNEC PC98に移植したのが、ソフトウェア開発に携わった始まりです。言語もＣやPerlがちょうどはやり出したときでした。この業界に携わって、最初に感動したのは、今までソフトが存在しなかったために制御できなかったことが、実際に自分が組んだプログラムによって作動させることができたときですね。そして、その自分の制作したソフトが、PC98の晩年期だったにもかかわらず、たくさんのユーザーに使ってもらえたのはうれしかったです。「ないものを自分で作り出す喜び」をこのときに味わったのです。

　オープンソースが広まる以前から、フリーソフトという形では開発していました。フリーソフトやオープンソースは、一から自分で作るのではなく、他人が作ったものを改善できるのが、大きな特徴ではないでしょうか。またDebian Projectに参加したことも、オープンソースに携わる機会を与えてくれました。今は30個くらいのパッケージを担当してメンテナンスを行い、バグを見つけては改善しています。また、日本におけるDebian配布のためのインフラの管理なども行っています。

　子供のころにポケコンと呼ばれる携帯型コンピュータを、父から奪い取って遊んでいました。そのポケコンをあれこれといじっていると、自分の動かそうと思ったとおりに操作できたのです。それまでに感じたことのない面白さが、そこにはありましたね。そして、大学生だった1989年ごろ、オープンソースというものに初めて出合いました。インプットメソッドのSKKが気に入らなくて、Wnnをネットから入手してコンパイルしたり、自分の気に入るメールリーダーが欲しくてEmacs上で動くcmailというメールリーダーを作ったりしていました。

　そして1995年にRubyをフリーソフトとしてリリースしました。空き時間で作った、業務とはまったく関係のないものでしたが、フリーソフトとして配布したからこそ、今でもRubyがたくさんの人に使ってもらえているのでしょうね。もし公開していなかったら、この場でこうして対談なんてしていなかったかもしれません（笑）。

　オープンソース開発の特徴としては、スケジュールよりも、クオリティが重視されます。いつまでに作るのではなく、それを作り上げることが大事なのです。また、開発者がやりたいものを自発的に制作するので、完成させるためには勉強や実験といった努力も惜しまないのです。そして、無駄を気にしないというのも特徴のひとつです。普通の企業の業務なら、分散して効率よく作業するのが普通でしょうが、オープンソース開発では皆が同じ作業をしていることもよくあります。やりたいことをやって、出来のよいほうを採用するというスタンスなのです。

　しかし、オープンソースにもメリットとデメリットはあります。メリットとしては、ソフトウェアの出来が最優先されるということ、開発者が自分で作業の方向性を決められるということ、作りたいものを勝手に開発できること、などが挙げられます。その半面、開発者が必要性を感じないものは出来が悪かったりします。また、きちんとしたロードマップやスケジュールの作成が難しいため、人材を無駄なく動かせることができないのも問題ですね。

　オープンソース開発は参加強制力がなく、金銭的な利害も発生しません。それでもあえて開発に携わるということは、やる気があるということ。このように、自発的な心構えの優秀なメンバーが集まりますから、一般的なソフトライターとは異なる集合知に近い感じ、つまり今でいうWeb2.0に近い動きで仕事を進めることができます。ですから、出来上がるソフトウェアも必然的に質の高いものが多くなるのでしょう。

　ただ労働集約型の開発など、オープンソースが向かないものもあります。また、オープンソースをよく知らない人との溝が深く、そのよさを理解してもらうことの大変さがありますが、最近ではオープンソース開発をビジネスで取り入れる企業も出てきたので、啓蒙活動次第で解消することは可能だと思います。

　「いかに開発すること自体を楽しめるか」が、クリエーティブな開発現場には欠かせないと思います。開発者がやりたいことをやらせてもらえる、命令を受けた業務から自分なりに面白さを見いだして取り組むなど、楽しみ方は人それぞれでしょう。オープンソースはどこまでも追求して開発していくことができます。ビジネス的な制約があまりなく、深追いできるような現場が理想的ですね。

　また、社内における開発の仕方がどの程度整備されているかも重要な条件です。内部で情報を共有化して開発者同士の意識合わせを図っているか、Code review などを行って、複数の人間がコードをきちんとチェック・評価するような体制かどうかです。さらに、機能、優先度などをTODO list に明記してロードマップ的なものを作成できている、工夫された環境であれば、より充実した開発が進められるでしょう。

　ちなみに、Googleの開発環境をご紹介すると、エンジニア主導でIdeaから実装まで行います。業務時間の20％をやりたい開発に自由に充てられる時間が設けられているのも特徴的ですね。また、社内ではフィードバックや改善を徹底して繰り返しますし、GFSやMapReduceといった必要なテクノロジーは随時開発されています。情報共有が行き届いていて、プロジェクト間に壁はありません。

　こうした経験を踏まえて、仕事上で心がけていることが何点かあります。まずは、優れた開発者と仕事をすることです。初めは知識面や技術面でついていけない部分もあるでしょうが、そばで仕事をしているうちに徐々に近づいていけるものです。二点目はわからないことをそのままにしないということです。不足している部分は書籍などから情報を収集し、空いた時間に勉強することが大切です。自分で身につけたことはドキュメントに書いたり、ブログに公開したりして、他人に教えてみると、知識が定着しているかどうかがわかります。

　ソフトウェアを開発するために理想的な現場に必要な条件は、「自由」というひと言につきるのではないでしょうか。しかし自由は、周りから十分に理解してもらえない状況では成り立ちません。いかに上司をはじめとする人々にわかってもらえるか、ということにかかってきます。自由の余地がない現場ならば、転職して環境を一新してみるのもひとつの手段でしょうね。

　また、不合理な制約に異議を申し出る自由があるかもキーポイントです。クライアント相手の仕事だと、時には無理難題を押し付けられることもあります。相手を説得して交渉するチャンスがきちんと与えられている現場がオススメです。私はワーキングスタイルの自由度も気にするほうなんです。普通の企業なら定時制が一般的なのでしょうが、好きなときにちょっと寝坊できるような融通の利く環境のほうが性に合っているみたいです（笑）。

　自由は同時に私にとって仕事上のポリシーでもあります。自由を得るためには、まず脳から汁が出そうなくらい考え抜いて知識や技術を身につけ、周りから信頼されるに足り得る人物となることです。経験豊富な人物は、周りの人からわからないことがあれば質問されるなどして、一目置かれる存在となり、組織内でもある程度自由の利くポジションに就くことができます。

　また、身の回りの環境整備も重要です。どんなデスクトップ、OS、ツールを使っているかは、優秀な人ほどこだわるもの。ちょっとした点でも変えてみると、今までよりもっと仕事が楽になることだってあるはずです。与えられた環境で満足しているようでは、いつまでたっても状況は変わりません。どうすればもっと効率的に仕事が進められるかを考えて、自分からどんどん工夫していってください。

　IT業界は常に速いスピードで進化していますが、基礎の部分は変わりません。表面的な知識ならネットで調べればなんとかなります。しかし、自らの血や肉となるような根本的な部分が、本当の意味で生涯使える能力となるはずです。そして、その姿勢をずっと続けてください。この業界で同じことを10年も続けていると、変人と言われるか、成功者と呼ばれるかどちらかですが、できれば後者で認められるようになってください（笑）。

　業界における自分のポジションを確立するには、ブランドを築くことです。オープンソースをリリースしたり、codeについてブログを書いたりして、知名度を高めてください。また、自分が根本的に触われないテクノロジーには依存しないでください。深追いできる技術に軸足を置くことが大切です。そして最後に、とにかく楽しんでください。楽しんで仕事をするコツは、今のレベルより少し難易度の高い課題にチャレンジしていくことです。