これは，IPA（情報処理振興事業協会：Information-technology Promotion Agency, Japan）が主催する，情報化人材発掘/育成関連プロジェクト「未踏ソフトウエア創造事業」（以下「未踏＝みとう」）に参加することになった，あるオジサン・プログラマの記録である。「未踏」に参加したプログラマがどのような活動をしているのかといったことは，あまり知られていない。これを機会に，ぜひ「未踏」の世界をのぞいてみてほしい。

写真1●え？ オジサンには見えない？
　まず自己紹介をしよう。わたしは今年44歳の中年プログラマである。ビールが好き，ゴキブリが嫌い。最近は下腹が気になり出している。

　プログラマとしての経歴は，かれこれ20年以上ある。学校を卒業して最初に入った会社は，当時VAXというミニコンピュータを売っていた「日本ディジタル イクイップメント（日本DEC）」である。ここで，ソフトウエア開発のイロハを学んだ。データベース管理システムの日本語化に携わり，漢字コードがどうだとか，日本語入力がどうだとか，同僚や米国本社の技術者，あるいは同業他社の技術者と熱く語りあったのを覚えている。

　その後，外資系データベース・ベンダーに転職し，1990年代中ごろから米国本社（シリコンバレー）へ出向する機会を得た。そして数年後日本に戻ってきて，ひょんなことでLinuxディストリビューションの会社（ミラクル・リナックス）の設立にかかわることになり，今にいたっている。海外赴任経験というと華々しく聞こえるが，見ての通りオジサンである（写真1）。そんなわたしが，なぜ「未踏」にかかわることになったのか？

図1●IPA（情報処理振興事業協会）のWebサイト（http://www.ipa.go.jp/）

「未踏」とは何か

　そもそも「未踏」の存在についてご存知のない方も大勢いると思うので，簡単に説明しておこう。「未踏ソフトウエア創造事業」とは，情報処理振興事業協会（IPA）（図1[拡大表示]）が，経済産業省からの補助を得て2000年度から実施している事業である。目的は，ソフトウエア関連分野で優れた能力を持つ「スーパークリエータ」を発掘支援すること。独創的なソフトウエア開発や事業アイデアを公募し，市場性/研究開発などの観点で優秀な提案に対して費用などの面から開発を支援しようというわけである。例年，春先に公募が始まり，5月には応募が締め切られる。提案された内容が採択されると，7月から翌年2月末までの約8カ月間が開発期間となる。この期間のうちに，自分が提案したソフトウエア開発プロジェクトをゴールさせるわけだ。

　この事業の画期的なところは，個人ないし数名のグループを対象として支援を行う点にある。支援するかどうかの採択は，10人近くいるプロジェクト・マネジャ（PM）それぞれに一任されている。PMは，コンピュータ技術においては国内外を代表する超一流の有識者ばかりである。それぞれの見識，趣味，直感によって，フツーのビジネスや研究では考えられないような，とんがったプロジェクトが採択される可能性があるわけだ。

　PMは，それぞれが募集するテーマ，提案書の記入要領，審査基準を公開する。応募者はそれを見て自分のアイデアが採択されそうなPMを自分で選ぶ。PMごとにテーマも違えば，提案書の様式も異なる。つまり「未踏」では，とことん“個人”にこだわるのである。開発するのも個人。それを採択するのもPMという個人である。

最初の挑戦はあえなく失敗

　わたしが最初に「未踏」の話を聞いたのは，平成12年度（2000年）の公募のころだったと思う。なかなか面白い制度だと思ったが，応募するまでにはいたらなかった。ミラクル・リナックスの立ち上げで正直それどころではなかったからだ。

　しかしその次の年，平成13年度のPMの一覧の中に新部 裕さんの名前を発見したとき，これは応募しなければと思った。新部さんというのは知る人ぞ知るLinuxのカーネル・ハッカーである。「こういう人がPMを務めるなら，オープンソースのプロジェクトを提案すれば採択されるかも」と思ったのだ。ミラクル・リナックスもある程度軌道に乗ったし，技術者として目先の変わった開発をしてみたいという野心もあった。

　そこでLinuxテスト・プロジェクトという提案書をさっそく書いて応募した。オープンソースのプロジェクトは体系的なテストというのが実施されにくい。それを補完するようなプロジェクトを提案すればウケルに違いないと思ったのだ。しかし…，残念ながらわたしの提案は採択されなかった。

　「未踏」では，開発者の情熱や志が強く反映するようなプロジェクトが求められる。しかしテスト・プロジェクトは，やることが決まれば誰でもやれる。落選して当然だった。ちなみにそのときの応募総数は461件。13名のPMの審査によって71件が採択されたという。合格率約15％。狭き門だと痛感した。

ユーザー・グループで「未踏」ネタを思いつく

　とはいえ，一度の失敗でメゲるほど，わたしもウブではない。オジサンはしつこいのだ。2002年になって，平成14年度「未踏」にも応募するつもりだった。しかし問題は「独創的なアイデア」をどうするかである。そのアイデアは意外な場所で見つかった。プライベートで所属しているLinuxのユーザー・グループ「横浜Linux Users' Group（YLUG：http://www.ylug.org/）」の会合である。

　YLUGでわたしは，不定期にLinuxカーネルの読書会というのをやっている。Linuxをさかなにあれやこれや雑談に興じるというインフォーマルな会である。カーネルというとビビる人もいるが，そんなことはないお気楽な会合である。

　その読書会で2002年の初め，インテルのプロセサのTSC（Time Stamp Counter）の機能について紹介があった。1サイクルごとに一つずつ増加していく64ビットのレジスタがプロセサに備わっていて，そのレジスタから値を読む方法を教わったのである。いろいろ聞いてみると，クロックだけではなく各種ハードウエア・イベントも取得することが可能だという。また，CPUとメイン・メモリーの間には高速/小容量のメモリー（キャッシュ）があるが，キャッシュにアクセスしても要求したデータが見つからない，いわゆる「キャッシュ・ミス」の回数なども計測できると教わった。なかなかすごいと思った。

　調べてみると，確かにx86として知られるプロセサには性能モニタリング機能というのが付いていて，キャッシュ・ミスを測定できるという。キャッシュ・ミスの回数がわかるなら，そこからカーネル性能のボトルネックを発見できるかもしれない――やがてわたしの興味はカーネルの性能向上に移った（別掲記事「なぜ性能向上に興味を持ったのか」）。そしてあるとき，カーネル・チューニング用のメモリー・プロファイリング（データ収集）ツールを開発したらどうかと思いついたのだ。――うん，これなら格好いいし「未踏」にふさわしい。これだ！と思った。

表1●平成14年度「未踏」のPMとそれぞれの公募対象プロジェクト

PMに狙いを定める

　問題はどのPMに提案書を出すかという点だった。キャッシュ・ミスがどうだとかメモリー・レイテンシ（遅延時間）がどうだとかいう非常にニッチな狭い分野のツールである。そんな話題に興味をもってくれるPMがいるだろうか――。

　と思っていたら平成14年度のPMが発表された。パーソナル・コンピュータの父とでも言うべきAlan Kayをはじめとして11人の有識者がそろっていた（表1[拡大表示]）。

　その中にわたしは，東京大学生産技術研究所の喜連川（きつれがわ）教授の名前を見つけた。データベース・システムの世界的権威である。喜連川PMの公募対象プロジェクトは「新しいデータベース処理技術に関する開発」。これなら，ツール開発というテーマも喜連川PMの琴線に触れるかもしれない。「わたしの作ったツールでデータベース・エンジンのボトルネックを発見し，ばりばりチューニングしたらどうです？ そういうツールがほしくはありませんか？」そんなプレゼンテーションも想像してみた。――よし，これならいけそうだ…。

写真2●「未踏」の採択決定通知。これが届いたときは，さすがに感動した
　そこでアイデアをまとめ，応募締め切り直前の5月，「OLTP性能向上を目的としたメモリー・プロファイリング・ツール」というタイトルで提案書を提出した。プロジェクトに必要な予算の見積もりも行った（予算について詳しくは次号で説明する）。OLTP（OnLine Transaction Processing：オンライン処理）を題材に選んだのは，昔とったきねづかというか，自分のバックグラウンドがデータベース・エンジン開発者で土地勘があったからである。

　喜連川PMによる面接を経て，やがて7月中旬。何の前触れもなく内定通知が届いた！（写真2[拡大表示]）。ちなみに平成14年度「未踏」では，応募総数が523件。このうち74件プロジェクトが採択された。合格率は約14％だから我ながら運がいい。採択者のプロフィールを見ると，学生/大学院生が全体の40％，企業従事者が34％，大学/研究機関従事者が20％。平均年齢は31.1歳。「未踏」でもわたしはオジサンであることに変わりなかったようだ…。

なぜ性能向上に興味を持ったのか

　米国でデータベースの開発をやっていたときのことである。性能評価を専門とするエンジニアが米Sun MicrosystemsのSolarisのエンジニアと共同で，パフォーマンスに関するテクニックをデータベース開発者全員にメールしたことがあった。それはC言語で書かれた例外処理マクロの定義に関するものだった。

　データベース・エンジンが何らかのシグナルを発行する場合，マクロ処理フローのif文の条件部では，then側に例外処理，else側に通常処理を記述していた。これを逆にするだけで実行時間が10数％向上するというのだ。例外が発生するのはまれなので，その処理をelse側に記述しておいたほうが性能向上に役に立つというわけである。

　一つのファイルの一つのマクロ定義を変更するだけで，実行時間を向上できる――まさにハック（hack）と呼ぶべきものだった。わたしがキャッシュ・レベルの性能向上に興味を持つようになったのはこのころからである。