2007年8月 - GLOBALBASEGLOBALBASEは完全自律分散型のGIS。そこに溜め込まれる個々人の地理情報が次第に、無数につながりあい、最後には地球そのもの（Parallel World）になっていくことを目指します。
多くのWeb型地理情報システムはベースマップを自身のサーバに保持し、他から囲い込む仕組みになっています。GLOBALBASEの特徴は、ベースマップをはじめとした一切の地理情報が他のサーバと重ね合わせたりつなぎ合わせたり、連携が可能だと言うことです。情報発信者も自由な地理情報の組み合わせで発信でき、ブラウザ側も自由な組み合わせで地理情報を閲覧することができます。
当プロジェクトではこのような自由な地理情報社会を築くために新しい技術の開発、実装を行っています。
GLOBALBASEというのは地図のウェブのようなものです。WebGISという言葉がありますが、WebGISとは似て非なる概念です。「地図のウェブ」は無数の「地図」がお互いの位置関係でつながり合い、関連づけられているネットワーク（ウェブ）です。この仕組みを利用すると、無数の人や組織が発信した「地図」が、自律的につながり合って一つの地球空間として認識できるようになります。
「GLOBALBASE」と「地図」の関係は「WWW」と「ドキュメント」の関係と全く一緒です。WWW上に発信されたドキュメント群は、ネットワークハイパーテキストとしてつながり合い、一種地球全体に広がった一つの文書のように認識できている訳です。
WebGISはこれらと異なります。たとえば、GoogleMapとマピオンの地図を同一レベルで重ね合わせたりつなぎ合わせたりしてみることは出来ないでしょう。WebGISは言ってみればWWWのドキュメントのひとつの挿絵のようなものです。概念上ハイパーリンクしているのはドキュメントであり挿絵ではありません。（実装上は違うかもしれませんが。）
では概念上も実装上もちゃんと地図がハイパーリンクしている、このアーキテクチャを見てみましょう。次に挙げるのはGLOBALBASEにおける専用ブラウザであるCOSMOSでのぞいた世界です。
図1. COSMOS オープニング画面
(→原寸で表示)
COSMOSをデフォルトで立ち上がると、図1.のようにほかの空間ブラウザにもありがちな、地球が表示されます。この状態からマウスで画面をドラッグしたり、左上にある拡大縮小ボタンを押すと、地球上の好きな場所へ移動することができます。
他の空間プラウザとは一線をかすところは、画面下側のパートで各地図レイヤの状態や検索条件を編集することができ、これを編集すると、いろんな時代、いろんなタイプの地図を表示することができます。たとえば、図2.はたくさんの人類遺跡の図面を検索したところです。地球がまるでパッチワークのようになっています。
図2. 高知工科大学人類遺跡データベースより
(→原寸で表示)
こんどは、国際日本文化研究センターにあるサーバのコンテンツで、京都の江戸時代(1750年頃)の地図を現代の地図と重ねたところです（図3.）。
図3. 国際日本文化研究センター 近世地図
(→原寸で表示)
これらのいろいろなコンテンツはそれぞれの組織のサーバにおさめられていますが、それらは独立して存在するのではなく、全部が位置情報的につながっています。人類遺跡の例もすでに、大阪市立大学の衛星写真と高知工科大学の遺跡データが重なっています。むろん、高知工科大学の人類遺跡データベースと、国際日本文化研究センターの古地図を重ねることも可能です。
「地図のウェブ」はまだまだ続きます。図4.はもうひとつのパッチワークの例です。関西地方の部分ですが、いろんな人がアップした航空写真や衛星写真が位置関係を維持して表示されている様子です。一つ一つは数ギガから数百ギガバイト級の巨大画像です。
図4.無数にアップされている航空写真／衛星写真
(→原寸で表示)
通常のGISでは、参照系とよばれる全世界共通な座標系を用意しています。すべてのデータを参照系に変換することによってデータを重ね合わせたりすることができるようになります。しかしGLOBALBASEはそのような参照系はもっていません。あらゆる座標系をユーザーが定義できてしまいます。座標系同士の相対的な位置関係と拡大率だけをたよりに、膨大な座標系のネットワークをブラウズしていく仕組みです。したがって地図のリンクをどんどん深くしていけば、どんなに小さいものも表示できるようになるのです。たとえば、図5.(1)はある会社の机の上の座標系を定義したものです。犬のぬいぐるみの毛のつやまで見られます。このようにいくらでも小さな座標系が定義できます。図5.(2)ではこの座標系が会社の間取り図という座標系に張り付いていることがわかります。この間取り図が京都の地図に張り付いており....という具合になっています。
図5.(1) ある会社の机の上
(→原寸で表示)
図5.(2) ある会社の間取り図
(→原寸で表示)
このようにすれば集積回路の中身も地球と同じアーキテクチャで扱うことができる訳です。ちなみにこれは、COSMOSで、時代を2000年くらいに合わせ、京都の烏丸御池へズームインすると見ることができます。
私はもともと東京大学の総合研究博物館というところで助手をしていました。1996年から1999年のことです。その最後の年に「ニュースの誕生〜かわら版と新聞錦絵の情報世界」という展覧会を担当しました。そのときに、展示用に災害史研究の先生と一緒に安政大地震（安政2年：1855年）の被害地図を作りました。江戸上屋敷下屋敷の被害地図、町屋の被害地図などを作成し、さらにへ江戸の切り絵図と重ね合わせられるよう、透明なアクリル板に印刷し、それをスライドして重ねられるような仕組みをつくったのです。実にアナログな世界です。
しかしそれはかなり不評でした。もともとIllustratorやVectorWorksで作った画像をなんたることか、アクリル板でスライドさせるなぞ。コンピュータでディスプレイに表示すれば良いではないか。ということだったようです。その酷評がGLOBALBASEを開発研究するきっかけと言えばきっかけです。
その後国際日本文化研究センターのデータベースを作ることがミッションとなり、そこで古地図のデータベースをやってくれということになったのも追い風となりました。やり始めてみるとこれは意外におもしろいかもしれない。まず対象物それ自体がおもしろい。日本にはこんなにもいっぱい古地図があるんだなとおもいました。
これにコンピュータ・サイエンスをアプライすれば、古地図をつなぎ合わせて江戸時代のぐにゃぐにゃな日本列島ができるのではないか。それを全世界に広げれば、ぐにゃぐにゃな地球ができるだろう....。そういった得体のしれない地図をオーバレイ・ネットワークでつなぎ合わせることのできるプロトコルができれば、いろんな人や研究者が参加してこういったぐにゃぐにゃ世界をつくることができるだろう。
さらに考えを拡大すれば手書きマップでもいけるはずだ。手書きマップだったら一般の人もさらに参加できるかもしれない。そういうことになってきたら、とんでもない世界地図が出来上がるのではないだろうか。
1999年の10月でしたか、国際日本文化研究センターでプロジェクトを立ち上げることになり、GLOBALBASEプロジェクトを開始したのです。最初は2、3年で終わるだろうと思っていたのですが、すでに8年目になろうとしていますねえ。
いろんな人に見てもらいたいです。老若男女、専門家、非専門家を問わずです。しかし、やはりひとりひとりが自分の身の回りの地図をアップしてくれて、それがWebのようにつなぎあわさっていって面白い世界が出来上がるので、見るだけではなく、地図をアップしてほしい。しかしこれが、なかなか難しい問題であることがわかってきました。
まず「地図が面白い」という人種と「ネットワークだいすき」という人種はあんまりクロスしていないんですね。地図をアップしたいといってもサーバを立ち上げるにはLinuxの初歩的なコマンドから入らなければならない....。さらに困ったことに、TCP/IPの知識がないと、うまく地図もつなげられない....。現在自律分散型といえどもサーバ・クライアント・アーキテクチャですが、ゆくゆくは完全なP2P型のアーキテクチャを構築していかねばならぬのかなと思っています。
「地図」そのものに対する一般の意識も実はネックであることがわかってきました。「地図」というと、とっても専門的で普通は書くことが出来ないと思っている人が多いようだということもわかってきました。このへんの壁を打破することがこれからの課題かなと思っています。
「地図を見る」だけであればかなりの人がダウンロードして見ているように思います。時々感想メールがきたりします。「動かないぞ」というのもあります。韓国のブログに紹介されていたり、DoD（Department of Defense：米国国防総省）らしきところからのアクセスがあります。そこそこの見せ物としては成果をあげているかなとは思います。
しかし、先のユーザーの話題のとおり、「地図のデータをつくって発信する」ための道具となると、ぜんぜんまだまだのようです。その理由としては、「地図」の持つむずかしいイメージの他に、サーバの扱いにくさ、不十分なマニュアルなど、技術以外の問題についてもまだまだ解決しなければならないことがいっぱいあります。いや、地図を発信したいという人たちは潜在的には大勢いると思います。
「地図を見て楽しんでください」というのがまず一番の使い方ですね。衛星写真などとても面白いですよ。地球にはこんなにおもしろい地形があったのかと感動します。たとえばこんなのもあります。『あしたの地図よ』は子供たちが自由に描いた地図です。音景観には、GLOBALBASEのWebゲートウェイ機能を使って実現したサウンドマップがあります。このように地図というのは難しいものではないということです。
図6.あしたの地図よ
(→原寸で表示)
「あしたの地図よ」を図6.に見てみましょう。子供たちが自由に描いた空想の地図なぞ、通常のGISでは考えられないでしょう。いままで多くの展示会等で測量図からこういった絵地図までが同一レベルであつかうことができるというのは専門家にとっては理解不能だったようです。でもこの事実は、逆に非専門家のほうが躊躇することなくすんなりと受け入れることができるのです。
やはりこれから、サーバを立ち上げ、自分の描いた地図や、手持ちの地図をアップしてくださる人が増えるとうれしい。情報系の学生諸君、キャンパスマップなぞいかがでしょうか。
図7.GLOBALBASE - WWW ゲートウェイ
(→原寸で表示)
また、専用ブラウザでは....と思っていらっしゃる方もいるかもしれません。図7.はGLOBALBASEのコンテンツをWWWにゲートウェイし、ホームページに貼付けて閲覧可能にする技術です。他の人が公開している地図も、自分の地図と重ね合わせてWWWで利用することも可能です。いまいろんなデザインのゲートウェイ・サンプルも用意しようとしています。
チューニングが進んだりバグが取れたときでしょうか。「でっかいミミクソがとれたような気分」とよく奥さんに言っています。ちまい話でごめんなさい。特に去年の秋口、それまで数年間、自律ネットワークに理論上考えられるより重たい負荷がかかり続けており、その理由がどうしてもわからなかったのですが、たった一文字の違いで、
と書くところを
と、大切な他のフラグを全部消去していたことを発見し、これを訂正したところ一気に日本中の負荷が減ったという、実に大事件がありました。
これはある意味、地道な戦いですね。私もかつて目のはれるような感動的なソフトウェアというのを目にしてきました。Mosaicが現れたときもそうでしたね。Linuxもそうでした。水星のごとく現れてくるように思えるかもしれませんが、しかしこれらの多くのソフトウェアの輝きも、言ってみれば骨董品の輝きのように日々絶え間なく磨いていてこそ得られる光沢だということでしょう。
しかし、そういった努力も共感者がいるからやっていけているんだと思います。プロジェクトがうまく行っていると感じれるのは、そういう共感者に出会ったときですね。共感者は顔と顔を会わせて対面しなくとも、ログの中で、サーバセットアップのドキュメントをアクセスしようとしているトラッキングが見つかることも実に感動的です。
話は変わって、早い時期からオープン・ソースコードの考え方を採用したのは成功したと思っています。初期の頃それでは製品にならないと言われたりしたこともありましたが、いまとなっては時代の流れに乗っていることは確かだと思います。私のオープンソースとの出会いは大学生時代1989年のことだったと思いますがNetRelease1をITRON上へ移植したことが始まりでした。NetRelease1がオープンソースかどうかはいろいろあるかと思いますが、あの、バークレイとAT&TのUNIX訴訟のきっかけとなったソースコード（の一部）です。その後ストールマンのフリー・ソフトウェアの概念が徐々に広まっていきました。あのソースコードを夢中になって解読したのを今も覚えています。
いや、コンピュータ・サイエンスを目指す学生諸君には言いたい。最近皆さんソースコードを読まなくなったように感じます。小説を読まない小説家がいないのと同じように、開発者・研究者を目指すならば、ソースコードをむさぼるように読みなさい。良いソースコードとの出会いはよい開発者、研究者の糧です。オープン・ソースコードは人のソースコードを利用できるようになり開発が楽になるという、安易な発想に基づくものではありません。他人の書いたすばらしいソースコードを読めるようになることによって、勉強し成長していく開発者、研究者を増やしていくためのものです。これはストールマンもはっきり言っています。
NetRelease1の移植をきっかけに、TRONプロジェクトに関わっていったのですが、TRONプロジェクトがスーパー302条を盾にアメリカから貿易障壁に挙げられ危機に瀕したとき、オープンソースの考え方の重要性を痛感しました。TRONプロジェクトではオープン・アーキテクチャ、オープン・スペシフィケーションを標榜していましたが、BTRON、CTRONについてはオープン・ソースコードのものがありませんでした。権利を持っている企業は、バッシング対象となることを恐れて、製品の販売のみならずソースコードを封印してしまいました。その後、坂村健氏の再三の交渉によって数年後にやっとのことで製品化したものの、既に時代は移りすぎていたわけです。もし、オープン・ソースコードのBTRONが当時存在したならば、おそらく現在もそのソースコードは生き残っていたかもしれない。そう思う訳です。
そのときの経験から、GLOBALBASEプロジェクトはすべてオープン・ソースコードで行こうと考えました。オープン・ソースコードのプロジェクトは、オープン・アーキテクチャ／スペシフィケーションのプロジェクトに比べれば地味です。しかし周囲から狙いようもないのも事実なのです。
よく最近聞くのは「日本にもGoogle Earthがあったか」という驚きの声。悪気はないと思いますが、私としては「アメリカにもGLOBALBASEがあったか」が正しいと主張したいです。まだGoogle Earthがなかった時代だと思いますが、ある経済学者たちの会合でデモンストレーションをしたときの感想が、「とってもすばらしい技術ですね。こういうのはきっとアメリカの軍事技術から生まれてきたものですね」と言った先生がいました。日本人が作れる訳がないと思い込んでいるらしく、どこまで日本人というのは負け犬根性なんだろうと思った瞬間でした。
ある官公庁のシステムの導入のためにシステムの仕様書を作ったとき、固有名詞は製品を特定することになり競争を阻害するから削除したという報告を受けました。しかしその仕様書にはいたるところ「Windows相当のOS」という言葉が出てくるのですね。これはもろに製品名ではないですか、と指摘すると、外国の製品名なので競争は阻害されないという答えが返ってきました。削除されたのは日本国内の企業や組織が制定した規格や製品名だったのです。日本人の間での奇妙な平等意識、自尊心のかけらもない舶来主義にうんざりすることがあります。
われわれのアーキテクチャではマルチスレッドを多用していますがマルチスレッドまわりでいろいろ苦労しています。
たとえば、Posixのファイルディスクリプタです。情報系であれば最初にならう非常に基本的なアーキテクチャです。しかしこのポリシーは言ってみればスレッドの概念がない時代のポリシーなのであまりスレッドと相性がよくありません。たとえば以下のような場合を考えてみましょう。スレッドA,B,Cという３つのスレッドがあるとします。
1. スレッドAがファイルディスクリプタ1をリードしたとします。
2. スレッドBがファイルディスクリプタ1をクローズしたとします。
3. スレッドCが新しいファイルをオープンしディスクリプタを得たとします。
2.->3.の順番で事象が発生し、1.の事象がそれと平行して起きた場合、ディスクリプタ0が埋まっていたとすると、Posixの仕様では3.のときに割り当てられるディスクリプタが1になる可能性が高く、スレッドAが読みにいったディスクリプタ1がBがクローズしたファイルなのか、Cが新しくオープンしたものなのかの判別が難しい状態になります。
一度解放されたディスクリプタは再度使われにくいようなアーキテクチャになっているべきなのです。これと同じ現象は、malloc - freeや、C++におけるオブジェクトの生成、解放においてもおきます。結局こういったものはロック／ミューテックスなどで守る必要が出てきますが、守り方は結構複雑です。
また、スレッドまわりにOSやライブラリのバグが多いことにも悩まされました。なんかの機能が仕様通り動作しないといった単純なバグは皆無ですが、「connect命令の発行で待ち状態になっているスレッドが存在するときに、別のスレッドでフォークするとプロセス全体がロックしてしまう」といったような組み合わせ攻撃で発現するバグが多く、しかも、確率的な問題、ネットワーク上の揺らぎなどがあり、発生頻度が小さいものが多く、考えものでした。
デバッグ環境も問題です。ある時点でデバッガをストップさせ、どこかのスレッドで呼ばれているはずの関数を、関数名でスタックの中をサーチする機能がないんですね。そういうのがあるデバッガがあったらだれか教えてくれませんか。いちいちスタックを表示して目で確かめていかないとならない。
gdbでは、thread apply all btなどとして、全部のスタックをしばらくかけて表示し、ターミナルの検索機能で関数名をサーチするというやり方ができますが、統合環境ではお手上げの場合が多いです。なまじっかなGUIは考えものです。
コンピュータ技術開発の歴史が向かっている方向には、ある種の桃源郷のようなものがあると思っているんです。「桃源郷」という中国由来のイメージではないかもしれない。Route 66とか、ボストンとか、UCLA、学生運動やヒッピー、ヒッチハイク。こういったキーワードの方がより具体的です。アメリカ流に言うなら「タラの丘」と言ったところでしょうか。残念ながら私はリアルタイムにそういった文化を享受できなかったけれども、そういった中から生まれてくる各種のコンピュータサイエンス的概念は出るべくして出てきたと思います。「フリーソフトウェア」「オープンソース」「分散技術」「公開鍵暗号系」。日本にいると、オーソリティーが作り出している技術のようにもとらえられがちですが、はぐれものの力がなかったらできなかった技術ばかりです。
コンピュータ・サイエンスはアメリカから生まれたかもしれません。しかしその「タラの丘」は暗黙のうちに、世界で共有されているものかもしれません。Linux、WWWといったものは必ずしもアメリカが生み出したものではありません。それらの開発組織の作り方、アーキテクチャのコンセプトが「タラの丘」を目指している。
「現在」というスナップショットをとると、いろんな技術が無意味に出ては消えしているように見えます。技術革新は著しく、コンピュータ技術は猫の目のように変わると言われます。しかしこれはコンピュータ・サイエンスの仮の姿なのです。TCP/IPやPosixといった基本技術をみてみればすぐにわかることです。基本技術は数十年をかけて熟成していきます。「猫の目」と思っている人たちはタラの丘や桃源郷への途上にいないだけなのです。
その道筋は、どこだか集中型をきらい、緩やかに拡散していくエネルギーが常に働いているように思います。そのエネルギーをつねに意識しながらコード化していくことがイニシアチブをとる秘訣ではないでしょうか。
まずは、今年中にver.B.のメジャーリリースを出したいと考えています。その内容は、基本的な地図のブラウズ機能に加え、公開されている地図の地物地名検索機能を実装します。その他データの種類として現在既にサポートされている、ラスタ、ベクタの大規模画像の他に、プロットデータ、標高（DEM）データ、マッピング（座標変換）データの大規模データ（マトリックス）をサポートします。これによりTera Byte級のデータもスムーズにブラウジングできるようになります。
その他、Deigital Earth Technology社との共同研究（図8.）により、ます航空写真や地図の従量制配信システムを来年度中に実用化したいと考えています。これが実現しますとGoogle Earthクラスの画像の最新版が常に供給されるようになります。共同研究のデモンストレーションは9月14日からのイノベーション・ジャパン2007でも行いますので、ぜひわれわれのブースへ足をお運びください。
図8.デジタル・アース・テクノロジー社1mメッシュ航空写真共同研究
(→原寸で表示)
その他、次の節で触れますが、エディタの実用化を考えています。また、そろそろver.C.の開発を立ち上げようと考えており、このバージョンでは、多次元空間のサポートにより3Dが扱えるようになります。
また、GLOBALBASEプロトコル・アーキテクチャの標準化という問題もあります。現在経済産業省がgXMLやPlaceIdentifier（PI）と銘打って様々な分散型の地理情報システムのプロトコルのJIS化、ISO化を試みています（参考：データベース振興センター）。私もこれらの標準化作業に関わっておりますが、しかし現在の段階ではかなりおおざっぱなものであり、GLOBALBASEとしての機能に相当する標準化はこれからでしょう。
最後に普及活動の面について述べます。日本における普及活動もさることながら、これから日本のみならず世界に向けて発信していこうと考えています。そのためにはマニュアルなどの英訳を今年度中を目標に行うつもりです。さらにsourceforge.netへの進出を行いたいと考えています。sf.netへ進出しても基本的に開発はsf.jpでやっていきたいと思っています。
エディタが欲しいという要望はよくでます。また、3Dも扱いたいという要望、いずれもパワーのいる仕事ですね。ただエディタを不用意に作ると、複雑なGISソフトみたいになってしまうのであまりやりたくないです。ブラウザとオーサリングツールをうまく分離する必要があるとおもっています。
3Dについてはいろいろ考えがあります。「地図」というキーワードを「空間」というキーワードへシフトしていけば自然に3Dへと進化し、「空間のウェブ」ということになります。「空間」の認知力は人間には生まれたときから備わっており、最も基本的な概念であると言えます。「言葉」をもつ人間にとっては、ドキュメントを理解する能力は人間らしさの一つでありますが、それは、空間の認知力よりも後に成長してくる能力です。
この意味で私は、WWW（=ドキュメントウェブ）はやがて空間ウェブへとシフトくだろうと考えています。いろいろ技術的、社会的条件が整ってくると、セマンティックウェブよりももっとドラスティックにシフトが起きてくるのではないかと思っています。
3D化したGLOBALBASEは、2Dの時と同様に多種多様な座標系が使えるでしょう。いまでもメビウスの輪とかクラインの壷など2次元の非ユークリッド空間を実現することは可能です。GISでそんなものを実現できるものは他にはないでしょう。3Dでは、ミンコフスキー空間とか非ユークリッド系の空間も対象とできると考えるのは自然です。宇宙空間を光速で移動するとどう見えるかシミュレーションできるわけです。
頭の痛い話としては量子力学的なミクロな座標系ですね。GLOBALBASEで見られる＝観測されたということですから、電子顕微鏡で見える見え方も一つの見え方にしかすぎない。最終的には自然現象をシミュレーションできるというのがGLOBALBASEのゴールですね。じっくり腰をすえて作っていきたいと考えています。（それはいつになることか。）
なんと言っても、インターネットによる空間情報の配信という基盤的な概念を早い時期に実装したこと、また先進的な技術という面においても、現在もなおかつ他に及ぶものがないということでしょう。
自律分散という言葉を使いましたが、現在ではWeb2.0やP2Pと言われる技術に通じるものです。1999年の最初のバージョンを出した当時、ネットワークを通じて地図の間で情報をやり取りし、リンクを維持する機能を実装しました。それは現在で言われるトラックバックの機能です。維持されたリンク上で情報をやり取りし、地図の重ね合わせを解決する機能にはルーティング技術やP2Pの技術が詰まっています。
私が痛感しているのは、やり直しが必要なときには思い切ってやり直すべきだということ。アドホックにつぎたしつぎたししていくとやがては歪みが生じ、あるところから先へは行けなくなってしまうわけです。
数万行書いてみて、全部それを捨てるということはよくあります。また実際に使ってみて初めて問題点がわかってくるのも事実です。コーディングは三度書き直さないと本物にはならないと言えましょう。
基本的に、プロジェクトの内の調整はメーリングリストや個人メールでやりとりしています。まあだいたいお互いに独立性が高いことをやっているので、メーリングリストよりは個人メールでのやり取りが多いです。
CVSの使い方は、個人名の入ったタグを与え別々の枝で作業し、作業がある程度完了したらマージしていくといった方法をとったりしています。Subversionに移行しようかなとも思うのですが、なかなかその暇がなく....。CVSのままです。対面してという原始的な方法もわりととっています。会うと一発の話というのもありますからね。
プロジェクト内の調整で、日本のオープンソースプロジェクトでやはり言語の壁が大きいなというのは感じます。一部マレーシアや中国の開発者もいるのですが、その人と他の日本の開発者の間ではやはりコミュニケーションがダイレクトにできない場合が多いです。結局、日本語のコミュニティーには外国人が加われない、では言語を英語にすればとすると、日本人が引いてしまうという現実があります。実にアナログなところにネックがありますね。
私はこのプロジェクト専属の開発者です。大学の准教授ですが、研究対象がGLOBALBASEです。今までの勤め先の中でGLOBALBASEのアイディアも生まれてきた訳ですし、今の職場もGLOBALBASEを使って研究アーカイブをしてくれというのがミッションだと認識しています。
ちょっと断っておきましょう。現在の所属も大阪市立大学文学部地理学教室ですので、文系の研究者と思われそうですが、私はばりばりの理系です。卒論は「Visunal Dataflow Language for Signal Processing」、修論は「Hardware Description Language for MPU Development」という具合です。信号処理やデータフロー言語、ハードウエア記述言語といったようにハードウエアよりの研究をやっていました。ペーパーマシンという言葉がありましたが、アプリケーションなくしてハードウエアはなりたたぬということを考えると、「これからのアプリケーションは」という考え方が重要だと博士課程から思うようになってきました。
「これからのアプリケーションは」ということに答えるのは非常に難しい。しかし一つ言えることは情報科学の周りの世界のことを熟知していなければおそらくその答えは出てこないということです。情報科学の世界ではどうしてもその外側の世界へでられないでいる研究者がいます。そうなると「『このソフトウェアを売る方法を提供する』ソフトウェア」的な、不毛なリカーシブ状態に入り込んでしまいます。私は、積極的に他の分野のプロジェクトに関わるようになったわけです。ここらへんは当時の師匠の坂村健に学ぶところが多かったんですがね、逆にその研究方針でぶつかってしまって、助手を三年半したところで、一人飛び出すことになってしまったかな。
開発環境は、阪急京都線と御堂筋線、大阪環状線、阪和線、ときどき新幹線に山手線、つくばエクスプレスに東武東上線、または飛行機.....と言ったらしかられますかね。仕事柄、いろいろ移動することが多いです。そのためいつでもどこでも開発できる体制が出来上がってしまいました。このインタビューを書き始めたのも、仕事の帰り道、サントリーのある大山崎の駅を通過したあたりかな。
いつも、17"のMacBook Pro+AirH"Proを抱え歩いています。まわりのお客さんには迷惑かもしれませんが。AirH"でチェックアウトしてデバッグ、コンパイル、コミット。DarwinはBSD系なので、これ一台でPosix系のデバッグがだいたいできます。当然ながらCarbon系のユーザーインタフェースのデバッグも。これでだいたい動いたら、ParallelsのVMを走らせWindowsでのデバッグ。多少のネットワーク系のデバッグもAirH"でできます。最近EMOBILEというのが出てきて、そちらも試してみようと考えています。
大学には、Linux、FreeBSD、Solarisの環境もあり、スタンドアロンでチェックできないコードは、移動していないときに動作チェックします。“ポータビリティー”を重視しています。
仕事上の連絡もほとんどMacBook Proで済ませます。携帯電話はほとんど使いません。MacBook Proでしたら写メールもいけますよ。思い起こせばマックユーザーは大年のモバイラーですからね。かわいいMac Plusを専用キャリングバックにいれて肩から背負ってお出かけというのは何十年前の風景でしたか。そうとう時代遅れのスタイルですかね。
大学にあるマシンはネットワークで常にアクセスすることができ、プロジェクトのみなさんはコンパイルファームなどに利用しています。
貢献のしかたはいろいろあります。まず使っていただくこと自体も貢献です。そこから始めて、例えば、身の回りの地図をいろいろ探してみましょう。中には著作権フリーの地図があります。または、自分でいろいろな地図をもとに自分の身の回りの地図を描いてみましょう。それをGLOBALBASEサーバに載せてみようと思っていただくことが次の進歩です。問題にぶつかったら気兼ねなく問い合わせてください。回答します。
簡単な地図では飽き足らず、巨大な衛星写真とかそういうものを持っている、発信したいという方もぜひご相談ください。
GLOBALBASEの開発は多岐にわたっています。もちろん専門的な知識を持っていないとできない部分もありますが、一方でそれほど専門的な作業ではなくいろいろ貢献できるところもあります。たとえば、出来上がったアプリケーションを動かしてみてレポートするテスターという役割、GLOBALBASEのデータ作成の知識が必要ですが、様々なサンプルデータを作る人などがいます。皆さん特にコンピュータの専門ではない人たちがやっています。また、COSMOSやHTTP-GATEWAYのユーザーインタフェースのデザインをしている人もいます。アイコンデザインなどが得意という人はどうぞ。
この場を借りて過去に貢献した方々を紹介します。長く、学生アルバイトから加わり、就職した現在もボランティアでGUI部分やGPSアダプターを作り続けてきた関山友輝さん。Windows機種依存部分の開発やHTTP-GATEWAYの開発を手がけてきた株式会社ゼータの渡辺央さん、中島智人さん。デザイン、宣伝広報活動を手がけてくださった齋藤事務所の齋藤俊文さん。データ作成やデザインなどに携わった株式会社ウェブマックスの渡辺康一さん、青木久哲さん。地域・研究アシスト事務所の四井恵介さん。その他にも様々な形でこのプロジェクトに貢献してくださっている方々がいます。皆さんにこの場を借りて感謝とお礼を述べます。皆さん専門家もいますが、専門でない方々もそれぞれの知識を持ち寄って、会社の方も半ばボランティアで参加してくださり、本当に助かっています。
プロジェクトへの参加のしかたなどは、GLOBALBASEガイドブックをのぞいてみてください。しかしここに書いていないことでも、私にメールしていただければお答えします。
もし、開発になんらかの形で関わってみたいと思われる方がいらっしゃいましたら、私に連絡ください。一緒にやりましょう。
sf.jpには大変お世話になっています。非常に感謝しています。開発環境の提供および、リリース処理など多くのことが現在sf.jpなくしては成り立ちません。
要望という点で言うならば、最近オープンソースが注目され始めているといえども、なかなか一般素人、コンピュータ初心者には取っ付きにくいものです。GLOBALBASEの外にもsf.jpにはいろいろ面白いソフト、便利なソフトがありますが、一般には知られないで眠っているものも多々あるでしょう。
こういったことを乗り越えるために、一つ一つのプロジェクトが独立してsf.jpを利用するだけでなく、プロジェクト同士も相互に協力してオープンソースの普及していけるような環境を作っていただければなと思います。
特にインストールの壁は初心者には大きいようです。例えばFinkやDarwin Port（どちらもMac OS X用のOSSパッケージ集）、NSUG（日本SunユーザグループのSolaris用OSSパッケージ集）といったようなパッケージがあります。「これ一つ手に入れれば一通りインストールできます」というようなsf.jpのパッケージ集を作るプロジェクトがあったら良いなと思います。かりにsf.jp.portと名付けましょう。
sf.jp.portをさらに発展させるならば、OSメーカーに働きかけ、OSにバンドルしてもらったり、あるいは、PCを買ってきたら、すでにsf.jp.portがインストール済みということも、ハードウエアメーカに働きかけて実現していくなど、どうでしょうか。
(取材日：2007年7月23日)
今月のプロジェクトに戻る
[PageInfo]
LastUpdate: 2007-09-21 13:01:33, ModifiedBy: sugi
[License]
GNU Free Documentation License
[Permissions]
view:all, edit:members, delete/config:members
OSDN Admin
edit
