スクリプト言語だと手続きを書くだけでいいじゃないです。低レベルだと割り込みのことを気にしなくちゃいけないとか、メモリ空間やレジスタのことも気にしなきゃいけないとかいう感じになるんです。私がパソコンを始めた頃は、少し早い処理をしようとするとマシン語を書かなくちゃいけなかったんですね。BASICはすごく遅かったので。今だとインターネットで動画がダウンロードできちゃいますけど、昔は雑誌に、打ち込むとアニメが表示されるようなプログラムのコードが載っていたんですけど、やっぱり早く書けた方がいいじゃないですか。BASICが持っているライン文っていうのはポイントとポイントを指定してその間を線分で結ぶっていう命令なんですけど、遅いので、それ以上に早くしようとすると、自分でマシン語でまったく同じ処理をするサブルーチンを書かなくちゃいけないんですよ。そんなことが必要なんですか。いうことを中学・高校の時代に延々とやっていたんですが、面白いですよ。CPUの同じ命令でもオルタナティブがあるんですよ。オルタナティブの方が20%くらい早かったりするんですよ。それを入れ替えて使ったりしていました。その仕組みって、CPUの内部の仕組みを見ると、処理の過程がそっちの方が短かったりだとか、あとは同じ処理をするんだけど、マシンコードの長さが短かったりとか。このコードの長さが短いと、CPUがコードを読む時間が短いんで、処理が早くなるんです。ジェット80とかそういうマシン語をやったことがある人は分かると思うんですけど、アキュムレーターっていう計算をするのが強いレジスターがあって、それをゼロクリアしたいときに、やり方が何種類かあるんですよ。普通のやり方だとアキュムレーターってレジスタにゼロを代入するんです。早くゼロクリアする方法があって、結構びっくりするんですけれど、「XOR」って言うんですが、排他的論理和をとるんですね。排他的論理和をとると、同じレジスタ同士なので、立ってるビットと立ってるビットが合わさってゼロになってゼロクリアと同じ働きをするんです。ゼロをロードするって命令は、まずロードしますって命令があって、さらにゼロをロードしますって命令があるので、マシンコードは2つなんです。アキュムレーター同士で排他的論理和をとるっていうのは1つなんですよ。30%くらい早いんです。いう裏技を駆使してちょっとずつ早くするっていうそういうことばっかりやっていました。それは力がつきそうですね。今のパソコンってボードにBIOSが乗っていて、BIOSにスタートアップするためだけのプログラムが書いてあって、あとその先のOSとかライブラリはハードディスクに依存しているんですね。昔、私が持っていたシャープのクリーンマシーンってパソコンもそれとすごい近い構成になっていて、BASICも一度、テープから読み込むんですよ。マシン語でプログラムを書いていて、変なことをしちゃうと変なところにプログラムカウンターが行ってしまって固まったり暴走するんです。固まったりすると、リセットボタンを押して、でまたBASICを読み込んでって3分くらいやらないといけないんですよ。一度、失敗をしてしまうとリカバリーがすごく大変なんです。何回もトライアンドエラーをしないとプログラムってよくならないんですけど、一度、間違いを犯してしまうと、リカバリーの時間がかかるんで、何か試そうとする前にすごく試行実験をするんですよ。ないとやってられないんですよね。実際にちょっとやってみて、間違って3分待ってっていうことを繰り返すよりも、まず、ちゃんと試行実験をしてみてからっていう方が効率がいいんです。いうことを学べたというのは貴重でしたね。学べる機会ってあるものなんですね。これは開発をする上でとても重要で、ちょっと仕事の遅い人とかを見ていると、あまり効率を考えないで、すごく使いづらそうな開発環境を使って書いているんですね。できる人は、自分がやらなきゃいけないことを効率的にこなすために、キーボードとかエディタとか開発環境にこだわりますよね。トライをしたあとのリカバリーの時間を最短にするのもそういうこだわりなんですよ。方法は人それぞれだと思うんですけどね。そのプロジェクトでメーラーの開発をして、Webの開発に移ったんです。Webの開発って、私が子供の頃やっていた低レベルの開発に比べると、ハイレベルじゃないですか。ほとんど文字列処理だけですし。ハイレベルなんだけども根底に流れている「リカバリーの時間を最短にする」って言うのは変わらないですよね。パラダイムが変わってもそれだけは変わらないと思いますね。よい師匠はそこを教えてくれるんですよ。変に我慢強い人だと、やれっていわれると1日中それを繰り返したりしているんですけど、有能なプログラマとしてはそれはあまりよいことではないですよね。ライターを長くやっていたこともあって、有能な開発者の人たちとの交流はあったので、間接的に学ぶことは多かったんですが、誰か1人、師匠と呼べる人がいるかと聞かれると思い当たらないですね。私がプログラムを始めた頃はBASICマガジンとかいろんな雑誌があって、それにソースコードが載っていてそれで学べるんですよ。実際に自分で打ち込みも改造もしましたし。私、常々思うんですが、BASICマガジンみたいな雑誌って、オープンソースなんですよね。ソースをひらいているじゃないですか。いう意味ではオープンソースって開発のプリミティブな形態なのかなって思いますね。確かにそういう見方もできますね。プログラムが文化だとすると、それがないと前に進んでいかないんですよ。テクニックも流通しないし。放っておくと盗めないし、好んで教える人も少ないですからね。最初のプロジェクトのリーダーと「これからはWebですかね」という話もしていて、一緒にWebの開発に移ったんですが、最初に教わったのが、Zopeだったんです。Pythonで書かれたWebアプリケーションフレームワークですね。この時代からPythonなんですね。当時は、Pythonの最新バージョンが1.5とかそんなもんでした。Webの開発に移っていきなりPythonだったんですね。当時、Webの開発をしようということになって、日経BPのWebサイトを運営するためのシステムをつくるって仕事をオファーされて、面白そうだからやってみようと思ったんです。今で言うCMSですね。ZopeってCMSの構築には向いていて、Pythonってあまり聞かないけど面白そうだからってことで取り組み始めたんです。私は最初にやった尾パソコンもマイナーでずっと裏街道を歩いてきた人間なんで、ちょっと他の人が使わないようなものに惹かれるんですね。なんか分かる気もします。メジャーじゃないところを狙うといいのは、競争相手が少ないんですよ。少ない努力で目立つことができるじゃないですか。それは経営戦略でもありますからね。ニッチは流れが速いので大変ですけどね。Webなんかはさらに大変ですね。それにニッチな世界での開発だと、情報が流れてくるのが海外からなんですよ。英語を少なくとも読めないとまずいですよね。書ければなおいいし、話せれば楽しいと思います。英語ができると他の人がリーチするより早い段階でリーチできるんですよ。明らかに情報は海外が早いですからね。オープンソースの世界は、関わっている人も多いし、才能のある人もかなりいるので、全部、自分でやろうとしない方がいいですね。流れを読んで、うまく流れに乗って、全体の1%でも自分で何か生産的なことができればいいくらいじゃないですか。それぐらいの気構えでいかないと疲れちゃいますよ。個人知じゃなくて集合知ですからね。逆に利用しようというくらいの方がいいかもしれませんね。Zopeの仕事を始めて、当時は日本語の文献どころかアメリカの文献もなかったので、もうソースコードを読むしかなかったんですね。RailsとかWebアプリケーションフレームワークがあって、Webアプリケーション開発にオブジェクト指向的なものを持ち込んでいますが、Zopeは当時からオブジェクト指向で、こういう風にWebの開発ができるのか、こういう風にすっきりできるのかっていうのを、ソースコードを読みながら学べたんですね。これはいつぐらいですかね。2000年の初め頃ですね。世の中は未だにPerlのCGIですよね。職人が作っているような時代です。いう時代にZopeっていうのはテンプレートエンジンを持っていて、データベースもオブジェクトデータベースを格納しているんですよ。Pythonのオブジェクトを作ると、それがそのままデータベースに保存されるんですよ。こんなデータベースがあるのかと驚きました。今は、オブジェクトデータベースって例えば、Webの世界で商用として有名なのは2つあるんですが、1つはオブジェクトストアというやつで、JavaとかC++のオブジェクトを映像化するもので、Amazonで使われていますね。たくさんのメタ情報を扱うのにはオブジェクトデータベースがすごくいいんです。あとCasheというのがあって、これは医療系で使われています。医療系のCTスキャンだとかそういうものから吐き出されるデータの標準形式があって、それがXMLらしいんですよ。XMLをリレーショナルデータベースにマッピングするのはたくさんリレーショナルをつけなければいけないので、相当大変なんですけど、そういうものを扱うのにオブジェクトデータベースがすごく向いているんです。Zopeっていうのは、もともと新聞社のWebサイトをつくるために開発されたフレームワークで、そういうWebサイトのコンテンツを開発するためにはオブジェクトデータベースみたいなものがあった方がいいのではないかとZopeの開発チームが考えたんです。Zopeの開発が始まったのは1997年なんですけど、その頃から彼らは、オブジェクトデータベースとかオブジェクト指向開発をしていたんですよ。いうのを聞くと敵わないと思いますよね。Webの開発にオブジェクト指向が使えるとか、Webの開発ってどういうものなのかっていうのは考え方なんですよね。思想っていうのは積み重ね式なので、先端の思想を知るためにはまず歴史を知らなくちゃいけないんですね。一つ言えることは、より新しいものを生み出すためには今の先端を知らなくちゃいけないんですよ。私は目の利く仲間がいて、その人にたまたまZopeっていうのを教わって、よく見てみたらすごいっていうもので、当時からそういうものに触れて役に立つことが多かったですね。聞かないお話なので、興味深いですね。「Pythonのパラドックス」って説があるんです。「Javaの仕事の求人をするときに、必ずPythonのスキルを求めなさい」ってことなんですけど、Javaの技術者のスキルってピンきりじゃないですか。できれば優秀な技術者が欲しい。いうときにPythonみたいにマイナーだけど技術的に研ぎ澄まされているそういうスキルを要求すると、Javaができる人の中でもすごくアンテナを張っていて、最新技術を習得する意欲のある人が集まってくるっていう意味なんです。最近は「Pythonのパラドックス」ではなくて、「Rubyのパラドックス」とか言われるみたいですけどね。確かに、我々もRailsで募集をかけると、Javaの技術が高い技術者の方が応募してきますね。当時は特にまだ「Pythonのパラドックス」がすごく効いていた時代で、Pythonの持っている素養を見抜く人は、もう1990年代の終わりの頃からオブジェクト指向のWeb開発をしていて、自分たちでオープンソースのオブジェクトデータベースを作って、それを仕事に使っちゃうようなすごい人が集まっていたんですよ。今、思い返すとそれはすごく象徴的なことだと思います。Pythonは要素技術なので、PostgreSQLみたいなリレーショナルデータベースも使うことがありますけど、仕事をする上ではPythonですね。ブリッジを書いてくれといわれてJavaとかPHPを扱ったりもしますけどね。Pythonがフロントエンドになっていて、ビジネスエンドとかバックエンドがPHPとかPerlとかJavaになっていてちょっとだけ書くようなケースですね。それでも、書けちゃうんですよね。なんでもというわけでもないですけど、比較的好き嫌いなく、メジャーな言語は大体大丈夫ですね。元は同じなので、あまり変わらないですよ。その時は、仲間と別の会社を立てて、そこで仕事をしていました。その会社は面白い会社で、たまに書籍の出版をしたり、英訳もしていましたね。続けていくうちに、やっている内容がはっきりと分かれてくるようになったので、私だけ別の会社を作ったという流れです。会社って家みたいなものだと思うんですけど、あまり家の中で違うことをやっている人たちがいるってあまりよくないことだなって思って、あまりシナジーのあることでもないし、分けた方がいいよねって感じでしたね。私、あまり営業をしないんですよ。いうのは営業してしまうと開発の時間が取れないんですね。日々の仕事というかすでにお付き合いをいただいているお客さんがいるので、そこから追加で仕事をいただいたりとかしていますね。ニッチなところでやっていると、ただWebサイトを持っているだけで、お話をいただいたりすることもすごく多いですね。キーワード検索であたりますもんね。今、柱になっているのはプローンっていうZopeの上に作られたフレームワークがあって、これもCMSを作るためのものなんですが、XOOPSに近いような感じですね。そのプローンを使った案件が一番多いですね。Python×・・・って本があったかと思いますが。技術評論社のやつですね。Railsみたいなものですね。昔はO’Reillyの翻訳本しかなかったんですが、最近はPythonの書籍がたくさん出てますね。