第14回　柴田淳氏　ウェブコア株式会社　代表取締役社長

「Webエンジニアの武勇伝」について

柴田こちらこそ、よろしくお願いいたします。これまでの記事は全部、拝見しましたけど、面白いですね。

柴田技術的な話はどこでもありますけど、生き様とか生い立ちとか、そういうインタビューって飲み会でもないとなかなかないので、とても興味深いですね。

柴田なるほど。そうですね。根底に流れるものは有名な人もそうじゃない人もあまり変わらないような気がします。

PCとの出会いは？

柴田私が、一番初めにパソコンを始めたのは、中学校２年生のときですね。その頃はまだマイコンって呼ばれていた時代で、いわゆる8ビット機ですね。PC8001 とか、シャープのMZとかそういうのが、ちょっと技術の興味のある子供たちの間で流行っていましたね。どういう理由かは分からないんですが、そういうのに興味をもって、親に頼んで買ってもらったのが最初です。

柴田私は、親の影響はあんまりなくて、昔から工作とかものを作るのが好きで、自分でプログラムっていうものが組めてそれが自由になるってところに興味を感じたんです。ちょうど、当時だとゲームセンターとかでパックマンとかが結構流行っていて、ひょっとしたらそういうものも作れるんじゃないかという妄想もありましたね。

柴田38歳です。昭和44年生まれですね。

柴田私がパソコンを買ったのはゲームが作りたいっていう志向性があったからなんです。当時って、パソコンの雑誌がいくつかあって、「I／O」とか「ASCII」とか電波新聞社が出していた「月間マイコン」とか「マイコンBASICマガジン」みたいなやつなんですが、そういう雑誌に何か作って投稿すると載せてもらえるんですね。それを目指して頑張ろうかと思っていたんです。それで、一番最初に作ったゲームを投稿したら、たまたまそれが載っかってしまったんです。

柴田それでまた何を血迷ったか、五反田にある電波新聞社の編集部に遊びに行ってみようかと思って、当時の自宅のあった多摩から１時間くらいかけて１人で行ってみたんです。それで遊びにいったらそこでまた原稿を頼まれるようになったり、中学、高校のときはそんなことばかりしていました。

柴田なんでしょうね、物好きだったんだと思いますね。

柴田当時は、雑誌って印刷代とか紙代は広告費で賄って、実際に売れた部分が儲けっていうモデルだったんですが、パソコン雑誌ではそれこそパソコンの広告をとるってことが至上命題だったらしいんですよ。そのためには、そのパソコンで作ったものが出ていないと駄目らしいんですね。

柴田それで、「MSXっていうパソコンが出るんで、機械を貸すから、ゲームを作ってよ」とかそんなことを頼まれたりしていたんです。だから家にMS-Xの試作機とかをもって帰ってきたんです。木の板にボードが乗っかっていて、キーボードが貼り付けてあって、コンポジット端子がついていてテレビに映せるみたいなやつでしたね。渡されたマニュアルも英語で全然分からない中でやっていましたね。

柴田いや、単に、物好きで、怖いもの知らずなだけだったんだと思いますよ。

柴田まあ、確かに（笑）　そういうところなので、なかなかすごい人が集まってきていたので、すごく刺激を受けましたね。原稿を書いている人たちとか、東大のマイコン部とかコミュニティがあったんですよね。そういう人たちが編集部にたむろっていたので、いろいろ話をしたりして刺激を受けましたね。

柴田そうですね。人並みには勉強もしましたけど、やはりパソコン中心でしたね。

柴田そうですね。大学に入ると、今度はX68000の雑誌である「Oh！X」というのがあって、そこでライターをやったりしました。で、ライターの稼ぎがそこそこあったので、就職しないで、そのまま専業のライターになっちゃったんですよ。

柴田自分でプログラムの記事を書いたり、ゲームを作って、そのことを書いたりしていました。ライターってやってみて分かったんですけど、本当に生活できるまで稼ごうと思うと、薄利多売でないとやっていられないんですよね。それが段々と辛くなってきたんです。人によっては、それがそういう仕事が合っているという人もいるとは思うんですけど、自分にとっては、薄利多売にするとクオリティを落とさなきゃいけないしと思うと、辛いものになってきてしまったんです。

柴田Webが出てきたこともあって、そろそろライターも潮時かなあって思い始めたんです。少なくともこのまま一生続けていく仕事ではないなって。そこで専業のプログラマに転進しようと思ったんです。

プログラマのスキルについて

柴田いえ、大学は英語をやってましたんで、完全に文系プログラマです。文系でそんなに忙しくなかっから、ライターの仕事ができたんですよ。

柴田そうでしたか。大学教育ってプログラマの能力っていう点でいうとあんまり関係ない気がしますね。高々４年ですから、小さい頃からパソコンに触れられたとか10代の頃の環境の方が大切な気がします。

柴田20 歳ちょっと過ぎくらいの未踏のスーパープログラマと言われている方たちとたまに話す機会があるんですけど、そういう人たちに聞いてみると、お父さんが開発をしていて、昔からパソコンが自由に使えたって言っていて、割とそれは共通していますね。教育がまったく無力だとは言わないですけど、教育で数年間やるよりも、中学生とか高校生とか自分の自由になる時間が本当にたくさんある時期にそういったものに触れられている時間をたくさん持つ、そういう環境があるかないかっていうのが本当に大きいですね。

柴田それが決定づけますね。ただ、それを逆転することもできるんです。そのためには、よい師匠を見つけることですね。そういう中学、高校ぐらいに独学でプログラミングを学んだような人たちってやっぱり躓きながら学んでいるので、効率っていう面でいうとそんなによくないんですよ。そのかわり躓きながら学んでいるのでいろんな枝葉を勉強できるんですね。そもそもコンピュータってどうやって動いているんだとかというところまで勉強できるっていう利点があると思うんですけど、躓きながら学ぶ効率の悪さをよい師匠を見つけることで多少後から始めても同じところまでキャッチアップすることができるんです。

柴田ちゃんと道を示してくれたり、ちゃんとサジェストしてくれる人がいると、若い頃から環境に浸っていなかったっていう人でもかなりのスキルを身につけられると思います。例えば、大学４年間でコンピュータサイエンスを学んで、そのあと会社に入って、よい師匠を見つけて一流の技術者になるというある種の王道があると思います。

柴田そうですね。なので、職業プログラマと比べるともしかしては劣っている面があるかもしれません。でも私は、なんでもできる人でいたいんです。プログラムを作るだけではなくて、ドキュメントを作るとかマニュアルを作るとかいうことも必要だと思うんですが、そういうときにはライターをしていたときの経験はすごく生きていますね。純粋にプログラマとしてみると、なんていうんでしょうか、普通のというか第一線の人と比べると劣っている部分があるというのが自己分析なんです。

柴田そうなんです。ですけど、総合力で見ると、そこそこいいところにいっているというのは自分にとっては幸せなことですね。これは人によって違うとは思いますけどね。開発だけをばりばりやるのが幸せな人もいれば、マネジメントや商品開発もするのがいい人もいますので。

柴田日本の会社の仕組みが変わってきていて、年功序列とか終身雇用とかは崩れてきているとはいっても、人生のライフステージっていうのはあるじゃないですか。年齢がいくと結婚したり、子供を作ったりとか、奥さんにそそのかされて家を買っちゃったりとか、それなりに、身入りが必要ですよね。やっぱり年齢がいくとそれだけ、その人が生活を維持するためのコストがあがっていくんで、そのコストを満たすためにどうしなきゃいけないかってことだと思うんですね。

柴田人によっては、開発がすごく得意で、一般的な開発者より100倍の生産性があるのであれば、開発に特化していけばいいし、そうでもないのであれば、もうちょっと商品開発か何かに特化をしてポテンシャルを上げるというか、自分のアウトプットが稼ぐお金を最大化するようにしなきゃいけないってことですよね。

柴田そうですね。一番不幸なのは、嫌なことをやり続けなきゃならないってことですからね。まず自分が何をやりたいかっていうのを見つけて、それをやり続けることのできる環境を作ることじゃないですかね。

最初の本格的な開発

柴田プログラマになって結構いろんな開発をしたんですけど、自分の転機になったと思うのは、Macintoshでメールクライアントを開発する仕事ですね。３年もある長い仕事だったんですが、それが割と良い経験になりましたね。その当時、2000年の初頭にかけてだったんですが、ソフトウェアのパッケージ販売って結構リスキーで、まず店頭に置いても売れないし、在庫を抱えて赤字になっちゃうこともあるし、「店頭販売はしません」ということを決めたんですね。そうなるとネットワーク上の露出であるとか、メーリングリストがあって、そこでサポートが受けられるかどうかということが重要だったんですね。今だとそういうことって当たり前ですけど、当時のそのプロジェクトはそういうモデルの先がけだったんです。

柴田そのプロジェクトに関わって、開発もするけど、たまにメーリングリストで発言をしたりとか、ただの開発じゃない形で仕事をさせていただいていて、それが開発者としての転機になったかなという感じがしましたね。あと、割と小さなチームだったので、よく言うと少数精鋭で自分の意見が通りやすかったですね。例えば仕様が降りてきて、それを実装するためにはってことだけではなくて、「こういう機能を追加したら面白そうじゃないですか」っていうことを認めてもらいながら作っていけたというのが面白い部分だったような気がします。

柴田あとインターネットというものの面白さもありましたね。

柴田当時は、Macintosh用の環境のCodeWarrior、いわゆるクラスライブラリを使って、実装の言語はC++でした。当時は４人のチームだったんです。その中で実装の切り分けをして、UI担当の人がいたりとか、ネットワーク処理の担当の人がいたりとかしましたが、私はネットワーク処理とかファイル処理の担当をしていました。アプリケーションの開発なので、それだけではすまなくて、多少、UIのこともわかりながら開発をしなくちゃいけなかったのが面白かったですね。それに当時は、Macintoshも今のように成熟していなかったので、OSのバグっていうのがあったんですよ。

柴田そりゃ、びっくりしましたね（笑）　マルチスレッドでアプリケーションを稼動すると、ある特定のタイミングで落ちたりするんですよ。それが３ヶ月くらい原因が分からなくて、あるとききっかけがつかめて、デバッカーでOSのコードとかを追っていたら、ここだっていうのを見つけて・・・ただOSのバグなので直せないんですよ。直してくれとも言えないし。なので、それを回避するコードを考えなくちゃいけないんです。なかなか面白かったですね。

柴田私がパソコンを始めた頃は、IOコードにパルスを出して、音を鳴らすとかすごくローレベルのプログラミングができたんですけど、そのプロジェクトがローレベルにタッチできる最後のプロジェクトだったと思います。それから先になると、例えば、CPUとかもRISCチップになってきてしまっていてマシンコードを追うことがほぼ不可能になってしまったんですね。RISCチップっていうのは、プログラムカウンターが進むことで命令を実行していくんですけど、きりのいいところでプログラムカウンターが進んでいかないと処理速度が変わって遅くなるんですよ。プログラムのマシンコードは短いものと長いものがあるんですが、短いものがずっと重なるとその分、処理速度がその分遅くなってしまうんで、「ノップ」っていうんですが、ゼロで埋めたりするんです。今は、そういう風にマシンコードを追ってデバックするのはほぼ不可能ですよね。大抵、そういうコードって言うのはコンパイラーが入ったりとか機械的に生成されているコードなので、最適化をはかったりするんです。それを追ってデバックするのは相当大変だと思いますよ。今の人たちでドライバなんかを書いている人たちはどんな風にやっているのか興味がありますね。ちょっと私の能力では手に負えない感じなんですよ。そういうのもローレベルの開発が、そろそろ潮時かなって思ったトピックでしたね。

柴田そうですね。例えばスクリプト言語だと手続きを書くだけでいいじゃないです。でも低レベルだと割り込みのことを気にしなくちゃいけないとか、メモリ空間やレジスタのことも気にしなきゃいけないとかいう感じになるんです。

柴田私がパソコンを始めた頃は、BASICがすごく遅かったので、少し早い処理をしようとするとマシン語を書かなくちゃいけなかったんです。今だとインターネットで動画がダウンロードできちゃいますけど、昔は雑誌に、打ち込むとアニメが表示されるようなプログラムのコードが載っていたんですけど、もともと BASICが持っているライン文っていうのはポイントとポイントを指定してその間を線分で結ぶっていう命令なんですけど、遅いので、それ以上に早くしようとすると、自分でマシン語でまったく同じ処理をするサブルーチンを書かなくちゃいけないんですよ。

柴田そういうことを中学・高校の時代に延々とやっていたんですが、面白いですよ。CPUの同じ命令でもオルタナティブがあるんですよ。オルタナティブの方が 20％くらい早かったりするんですよ。それを入れ替えて使ったりしていました。その仕組みって、CPUの内部の仕組みを見ると、処理の過程がそっちの方が短かったりだとか、あとは同じ処理をするんだけど、マシンコードの長さが短かったりとか。このコードの長さが短いと、CPUがコードを読む時間が短いんで、処理が早くなるんです。マシン語をやったことがある人は分かると思うんですけど、アキュムレーターっていう計算をするのが強いレジスターがあって、それをゼロクリアしたいときに、やり方が何種類かあるんですよ。普通のやり方だとアキュムレーターってレジスタにゼロを代入するんです。だけれども、もっと早くゼロクリアする方法があって、結構びっくりするんですけれど、「XOR」って言うんですが、排他的論理和をとるんですね。排他的論理和をとると、同じレジスタ同士なので、立ってるビットと立ってるビットが合わさってゼロになってゼロクリアと同じ働きをするんです。ゼロをロードするって命令は、まずロードしますって命令があって、さらにゼロをロードしますって命令があるので、マシンコードは２つなんです。だけど、アキュムレーター同士で排他的論理和をとるっていうのは１つなんですよ。だから30％くらい早いんです。そういう裏技を駆使してちょっとずつ早くするっていうそういうことばっかりやっていました。

柴田今のパソコンってボードにBIOSが乗っていて、BIOSにスタートアップするためだけのプログラムが書いてあって、あとその先のOSとかライブラリはハードディスクに依存しているんですね。昔、私が持っていたシャープのクリーンマシーンってパソコンもそれとすごい近い構成になっていて、BASICも一度、テープから読み込むんですよ。だからマシン語でプログラムを書いていて、変なことをしちゃうと変なところにプログラムカウンターが行ってしまって固まったり暴走するんです。固まったりすると、リセットボタンを押して、でまたBASICを読み込んでって３分くらいやらないといけないんですよ。だから一度、失敗をしてしまうとリカバリーがすごく大変なんです。何回もトライアンドエラーをしないとプログラムってよくならないんですけど、一度、間違いを犯してしまうと、リカバリーの時間がかかるんで、何か試そうとする前にすごく思考実験をするんですよ。じゃないとやってられないんですよね。実際にちょっとやってみて、間違って３分待ってっていうことを繰り返すよりも、まず、ちゃんと思考実験をしてみてからっていう方が効率がいいんです。そういうことを学べたというのは貴重でしたね。

柴田そうですね。これは開発をする上でとても重要で、ちょっと仕事の遅い人とかを見ていると、あまり効率を考えないで、すごく使いづらそうな開発環境を使って書いているんですね。できる人は、自分がやらなきゃいけないことを効率的にこなすために、キーボードとかエディタとか開発環境にこだわりますよね。トライをしたあとのリカバリーの時間を最短にするのもそういうこだわりなんですよ。勿論、方法は人それぞれだと思うんですけどね。

柴田そのプロジェクトでメーラーの開発をして、Webの開発に移ったんです。Webの開発って、私が子供の頃やっていた低レベルの開発に比べると、ハイレベルじゃないですか。ほとんど文字列処理だけですし。でも、ハイレベルなんだけども根底に流れている「リカバリーの時間を最短にする」って言うのは変わらないですよね。パラダイムが変わってもそれだけは変わらないと思いますね。よい師匠はそこを教えてくれるんですよ。変に我慢強い人だと、やれっていわれると１日中それを繰り返したりしているんですけど、有能なプログラマとしてはそれはあまりよいことではないですよね。

柴田ライターを長くやっていたこともあって、有能な開発者の人たちとの交流はあったので、間接的に学ぶことは多かったんですが、誰か１人、師匠と呼べる人がいるかと聞かれると思い当たらないですね。私がプログラムを始めた頃はBASICマガジンとかいろんな雑誌があって、それにソースコードが載っていてそれで学べたんですよ。実際に自分で打ち込みも改造もしましたし。私、常々思うんですが、BASICマガジンみたいな雑誌って、オープンソースなんですよね。ソースをひらいているじゃないですか。そういう意味ではオープンソースって開発のプリミティブな形態なのかなって思いますね。

柴田プログラムが文化だとすると、それがないと前に進んでいかないんですよ。テクニックも流通しないし。

Pythonとの出会い

柴田最初のプロジェクトのリーダーと「これからはWebですかね」という話もしていて、一緒にWebの開発に移ったんですが、最初に教わったのが、Zopeだったんです。Pythonで書かれたWebアプリケーションフレームワークですね。

柴田そうですね。当時は、Pythonの最新バージョンが1.5とかそんなもんでした。今は2.5かな。

柴田そうですね。当時、Webの開発をしようということになって、日経BPのWebサイトを運営するためのシステムをつくるって仕事をオファーされて、面白そうだからやってみようと思ったんです。今で言うCMSですね。ZopeってCMSの構築には向いていて、Pythonってあまり聞かないけど面白そうだからってことで取り組み始めたんです。私は最初にやったパソコンもマイナーでずっと裏街道を歩いてきた人間なんで、ちょっと他の人が使わないようなものに惹かれるんですね。それでヒットしたのもありますけどね（笑）

柴田メジャーじゃないところを狙うといいのは、競争相手が少ないんですよ。より少ない努力で目立つことができるじゃないですか。

柴田まあ、ニッチは流れが速いので大変ですけどね。特にWebなんかはさらに大変ですね。それにニッチな世界での開発だと、情報が流れてくるのが海外からなんですよ。だから英語を少なくとも読めないとまずいですよね。書ければなおいいし、話せれば楽しいと思います。英語ができると他の人がリーチするより早い段階でリーチできるんですよ。

柴田特にオープンソースの世界は、関わっている人も多いし、才能のある人もかなりいるので、全部、自分でやろうとしない方がいいですね。流れを読んで、うまく流れに乗って、全体の１％でも自分で何か生産的なことができればいいくらいじゃないですか。それぐらいの気構えでいかないと疲れちゃいますよ。

柴田逆に利用しようというくらいの方がいいかもしれませんね。

柴田Zope の仕事を始めて、当時は日本語の文献どころかアメリカの文献もなかったので、もうソースコードを読むしかなかったんですね。ただZopeはよくできていて、今でこそ、皆さんは、Ruby on RailsとかWebアプリケーションフレームワークがあって、Webアプリケーション開発にオブジェクト指向的なものを持ち込んでいますが、Zopeは当時からオブジェクト指向で、こういう風にWebの開発ができるのか、こういう風にすっきりできるのかっていうのを、ソースコードを読みながら学べたんですね。いい経験でした。

柴田2000 年の初め頃ですね。世の中は未だにPerlのCGIですよね。職人が作っているような時代です。そういう時代にZopeっていうのはテンプレートエンジンを持っていて、データベースもオブジェクトデータベースを格納しているんですよ。Pythonのオブジェクトを作ると、それがそのままデータベースに保存されるんですよ。こんなデータベースがあるのかと驚きました。今は、オブジェクトデータベースって例えば、Webの世界で商用として有名なのは２つあるんですが、１つはObjectStoreというやつで、JavaとかC++のオブジェクトを映像化するもので、Amazonで使われていますね。たくさんのメタ情報を扱うのにはオブジェクトデータベースがすごくいいんです。あとCACHE'というのがあって、これは医療系で使われています。医療系のCTスキャンだとかそういうものから吐き出されるデータの標準形式があって、それがXMLらしいんですよ。XMLをリレーショナルデータベースにマッピングするのはたくさんリレーショナルをつけなければいけないので、相当大変なんですけど、そういうものを扱うのにオブジェクトデータベースがすごく向いているんです。

柴田Zopeっていうのは、もともと新聞社のWebサイトをつくるために開発されたフレームワークで、そういうWebサイトのコンテンツを開発するためにはオブジェクトデータベースみたいなものがあった方がいいのではないかとZopeの開発チームが考えたんです。でもZopeの開発が始まったのは1997年なんですけど、その頃から彼らは、オブジェクトデータベースとかオブジェクト指向開発をしていたんですよ。そういうのを聞くと敵わないと思いますよね。

柴田でもWebの開発にオブジェクト指向が使えるとか、Webの開発ってどういうものなのかっていうのは考え方なんですよね。だから、思想っていうのは積み重ね式なので、先端の思想を知るためにはまず歴史を知らなくちゃいけないんですね。もう一つ言えることは、より新しいものを生み出すためには今の先端を知らなくちゃいけないんですよ。たまたま私は目の利く仲間がいて、その人にたまたまZopeっていうのを教わって、よく見てみたらすごいっていうもので、当時からそういうものに触れて役に立つことが多かったですね。

柴田Pythonってそういう意味で、すごく重要な意味を占めていて、ちょっと一昔前に騒がれたんですけど、Paul Graham の「Pythonのパラドックス」って説があるんです。例えば、「Javaの仕事の求人をするときに、必ずPythonのスキルを求めなさい」ってことなんですけど、Javaの技術者のスキルってピンきりじゃないですか。でもできれば優秀な技術者が欲しい。そういうときにPythonみたいにマイナーだけど技術的に研ぎ澄まされているそういうスキルを要求すると、Javaができる人の中でもすごくアンテナを張っていて、最新技術を習得する意欲のある人が集まってくるっていう意味なんです。 http://practical-scheme.net/trans/pypar-j.html

柴田最近は「Pythonのパラドックス」ではなくて、「Rubyのパラドックス」とか言われるみたいですけどね。

柴田当時は特にまだ「Pythonのパラドックス」がすごく効いていた時代で、Pythonの持っている素養を見抜くような人は、もう1990年代の終わりの頃からオブジェクト指向のWeb開発をしていて、自分たちでオープンソースのオブジェクトデータベースを作って、それを仕事に使っちゃうようなすごい人が集まっていたんですよ。今、思い返すとそれはすごく象徴的なことだと思います。

柴田そうですね。Pythonは要素技術なので、PostgreSQLみたいなリレーショナルデータベースも使うことがありますけど、仕事をする上では Pythonですね。たまにブリッジを書いてくれといわれてJavaとかPHPを扱ったりもしますけどね。Pythonがフロントエンドになっていて、ビジネスエンドとかバックエンドがPHPとかPerlとかJavaになっていてちょっとだけ書くようなケースですけどね。

柴田なんでもというわけでもないですけど、比較的好き嫌いなく、メジャーな言語は大体大丈夫ですね。元は同じなので、あまり変わらないですよ。

柴田その時は、仲間と別の会社を立てて、そこで仕事をしていました。

柴田そうですね。

柴田その会社は面白い会社で、たまに書籍の出版をしたり、英訳もしていましたね。ただ、しばらく続けていくうちに、やっている内容がはっきりと分かれてくるようになったので、私だけ別の会社を作ったという流れです。

柴田そうですね。

柴田会社って家みたいなものだと思うんですけど、家の中で違うことをやっている人たちがいるってあまりよくないことだなって思って、シナジーのあることでもないし、分けた方がいいよねって感じでしたね。

柴田そうですね。私、あまり営業をしないんですよ。というのは営業してしまうと開発の時間が取れないんですね。なので営業しないんです。ただ、日々の仕事というかすでにお付き合いをいただいているお客さんがいるので、そこから追加で仕事をいただいたりとかしていますね。ニッチなところでやっていると、ただWeb サイトを持っているだけで、お話をいただいたりすることもすごく多いですね。

柴田そうですね。今、柱になっているのはPloneっていうZopeの上に作られたフレームワークがあって、これもCMSを作るためのものなんですが、XOOPSに近いような感じですね。そのPloneを使った案件が一番多いですね。

柴田技術評論社のやつですね。あれは私の本なんですが、Ploneじゃなく、「TurboGears×Python」っていう本で、平たく言ってしまうと Python版のRuby on Railsみたいなものですね。そう言うとPythonの人は嫌がるんですよね（笑）　昔はO'Reillyの翻訳本しかなかったんですが、最近は Pythonの書籍がたくさん出ていますね。

柴田ニッチなところで仕事をしていくって上で、雑誌の露出とか書籍の露出ってとても大きくて、私も、昨年「みんなのPython」っていう書籍を書かせていただいたんですけど、お陰さまで好評なんです。実は私、Pythonのコミュニティに関わって長いんですけど、自分で書籍を書くなんてことはまったく想像していなくて、誰か他の人が日本で始めての入門書を書くんだろうなあって思っていたんですけど、たまたま、出会いがあってお話しをいただいて、大変なのは分かっていたんですが、ライター経験もあったしブランディングにもなるし、やってみようかなって思って始めたんです。

柴田この本は440ページくらいあるんですけど、すべての仕事をストップして、かかりっきりになって２ヶ月くらいかかったんです。辛かったけど、苦労した甲斐があったってすごく思いますね。この本を読んでいただいて、お声をかけていただくことが多くなりましたからね。

柴田比較的、簡易なことから書いているんですよ。私は基本的に人を信用しないところがあって、ずべての前提知識がないものと思って書いたんです。

柴田いえ、まったくプログラミングをやっていなくても大丈夫だと思います。変数に代入するとどうなってというところから全部書いています。

柴田やっぱり技術者の目線だと暗黙知のレベルが高くなっちゃうんじゃないですかね。私はライターをやっていたこともあって、そのあたりは、未経験の方でも分かるように書けたという思いがありますね。なんでワープロでプログラムを書いちゃ駄目なのかとか、本当はそういうところから説明した方がいいかもしれないですからね。

柴田昔は、プログラムとコンピュータが近いところになったので、こうすればこう動くっていうのがすごく分かりやすかったんですよ。例えば、「Hello　 world」ってあるじゃないですか。昔は、「Hello　world」が表示されると「あ！　表示された！」ってすごく嬉しかったんですよね。今って、 Javaで「Hello　world」を書いて、コンパイルして走らせてみましょうって言って表示されても誰も喜ばないと思うんですよ。それってすごく重要で、何か学ぶってことは、学ぶために投入したエネルギーのリターンが必要なんですよ。そのサイクルがないと学ぶことを続けていけないんですよ。そのサイクルをうまく作りながらちょっとずつ進めていくのが学ぶって過程だと思います。でも今は、リターンを得るためのハードルがすごく高くなってしまっていて、昔だったら記号を組み合わせて人間の形をつくるアスキーアートみたいなもので、うまくパラパラ漫画みたいに入れ替えて、表示すると走っているように見えるものでもみんな喜んだんですよ。今はだれもそんなんじゃ喜ばないですよね。だってインターネットで動画とかバンバン入ってくる時代ですからね。

柴田昔は本当にコンピュータで音を出すだけでも喜べたんですけどね。今はハードルが高すぎて学ことのためのリターンを得るのがすごく難しくなっていますよね。だからプログラミングを始める人たちは、最初の段階では、プログラミングをした結果が目に見えやすい形でリターンとして帰ってくるようなものを使った方が続けていきやすいかもしれないですね。

柴田ええ、動くものを作らないとリターンが得られないですよね。

柴田そうかもしれませんね。ペダルとブレーキ踏んでいるだけで、たまにハンドルを動かすくらいのことかもしれませんから、まずはやってみることをお勧めしますね。

Pythonのユーザー会について

柴田コミュニティはもともとそういうのが好きだったという感じなんですが、Pythonのコミュニティに最初に関わったのは、PyJUG（Pythonジャパンユーザーグループ）っていうコミュニティがあって、その結成会のOFF会があったのがきっかけです。PyJUGの命名には実はいわくがあって、本当は JPUG（ジャパンPythonユーザーグループ）がよかったんですけど、日本PostgreSQLユーザー会がすでにJPUGと命名されていたんで、それでPyJUGにしたんです。今、私は両方に関わっているんですけど、なんか変ですよね（笑）

柴田コミュニティは６年くらいですかね。当時は、今以上にPythonっていうのはマイナーで、そこに集まってくる人たちはすごかったですね。当時Python を知っている人っていうのは前提条件として英語が読めて、技術者としても第一線でもそこそこ活躍している。そしてアンテナも立っている人ばかりでしたね。面白い話があるんです。昔、Pythonのメーリングリストで発言した人のところにヘッドハンティングの電話が順番にかかってきたことがあったんです。狙い目とはいいと思いましたね。

柴田かなりゆるい組織なので、会長もいませんし、決まりもないんです。PyJUGっていう組織があって、メーリングリストがあって、たまにイベントをやるくらいな感じです。

柴田コミュニティって有機的なものだと思うんですよ。その有機的なものを安定的にしていこうと思うと、まず人が集まって、そして新陳代謝がないと駄目なんですよね。なので、なるべく私から仕掛けて、外に出るイベントをたくさんやっていきたいなって思っています。

柴田これを話すとびっくりされるんですけど、2006年の４月に勉強会の拡大版をやったんですけど、場所はどこだと思います？　新宿の某所なんですけど。

柴田マイクロソフトでやったんですよ。マイクロソフトがオープンソースの勉強会に会場を貸してくれるって意外ですよね。GPLは駄目らしいんですけど、PythonはBSDライセンスに近いので、そのあたりでOKだったらしいんです。

柴田最近は、.NETで動くIronPythonっていうPythonの実装系があって、開発者はマイクロソフトの社員なんですよ。Jim Huguninっていうんですけどね。なので、まったく縁がないわけじゃないんですけどね。

柴田その一環かもしれませんね。

柴田去年はマイクロソフトで、今年は、東京大学の駒場キャンパスでやったんです。

柴田講演も、マイクロソフトのMVPの荒井省三さんにお願いしてIronPythonについて話していただいて、それが縁で、荒井さんはIronPythonの本も出されたんです。

柴田リアルなところに出て行くと、いろんな人とつながりあえますね。新陳代謝っていう観点でいうと、新しいヒーローが現れてこないと、コミュニティって大きくなっていかないし、続いていかないと思うんですよ。なのでイベントでそういう人に話す機会を与えたり、話すことで注目を浴びたりということもあるので、イベントは定期的にやっていきたいと思いますね。

これからの方向性は？

柴田５年くらいでWebの次のものを見つけたいですね。そして５年くらい、Webをやる傍らで、その次のものにちょっと投資をして、10年後くらいに完全に移行できるといいですね。自分の人生を振り返ると、まずライターを10年弱くらいやって、Webの開発に移って5年くらい経つんですが、あと5年くらいで、業界というかWeb自体が成長の頂点を迎えると思うんですよね。そこにしがみついていると、仕事も立ち行かなくなってしまうと思うので、それまでに次のものを見つけて移りたいなあと思うんです。ちょっと長期的なビジョンですけどね。それ以上先のことは流れが速すぎて分かりません。

柴田そうですね。変わるってことはすごく重要ですね。その変化に対応するだけの体力をつけていかなければならないと思いますね。でも、ローレベルな開発をしていても、アプリケーションの開発をしていても、Webの開発をしていても根底に流れているものは同じなんですよ。エンジニアとして生きていくなら、まず根底に流れているものをしっかりと自分の体にしみ込ませて、あとは世の中の動きを良く見て、自分がそこにいると幸せだなというところを見つけて、そこにいられるような環境を作ることが大事なのかなって思いますね。

柴田その前提として、変化するってことは肝に銘じておかないといけないことですね。Zopeみたいなものをやっていてつくづく思うんですけども、Zopeって出た当時はもてはやされていたんです。ただ開発にはいくつかのレイヤーがあって、まずOSみたいな低レベルなもの、スクリプト言語みたいなもう少しハイレイヤーなところ、そしてZopeとかRuby on Railsみたいなアプリケーションフレームワークっていう言語の上に乗っかっている要素技術があるんですが、上のレイヤーに行けばいくほど寿命が短いんです。Zopeはもうすでにフレームワークとしてみると老練期に入っていている感じがしていますね。なのでフレームワークの寿命って５年とか10年のような気がします。

柴田例えば、人が大学を出て、60歳くらいで定年を迎えるまで、大体40年くらいなんですが、その40年を5年で割ると、8つですよね。なので仕事をしているうちにフレームワークだけ見ると4つとか5つぐらい変えていかなくちゃいけないってことですよね。

柴田フレームワークの寿命もありますけど、言語の寿命ってのもあって、今、RubyとかPythonとか言われていますけど、あと20年後は全然違うものが出てきているでしょうね。まったく使われないかもしれませんね。COBOLくらいれレガシィになれば別ですけどね。最近はJavaなんかもそんな感じかもしれないですね。でも新しいものほど移り変わるのが早いんでなんとも言えませんけどね。

柴田そうです。変化を前提としなくちゃいけませんね。ただ、毎回毎回いちから勉強するのは辛すぎるので、すべてのベースになる基本があるので、それをしっかり身につけて、基本からはずれる部分だけ勉強するようにして新しいものに対応するのが効率的な生き方ですかね。

若いエンジニアに向けて

柴田若い人だと自分が言語やフレームワークを変えた経験がないと思うんです。でもそういう可能性があるってことを前提としていれば、日ごろのスキルアップの仕方や対応姿勢がいろいろ変わることがあると思いますね。僕も仕事で使った言語は３つ目ですが、これからも変わっていくと思うので、それを前提に考えていますからね。

柴田一部繰り返しになりますが、楽しむことが重要だと思います。自分にとって楽しいことは何なのかを早く知って、その楽しいことを続けられる環境を作ることですかね。それが重要だと思いますよ。

柴田うーん、やっぱり基本的に仕事をしていて、プロとしてポジティブな方がいいですよね。でもパーソナリティもあるんでね。技術者で難しいのは、すごくネガティブな人の方がスキルフルだったりするケースも多いじゃないですか、だから技術者の場合には、一概にそうは言えないのかもしれないんですけどね（笑）

柴田ネガティブな人のいいところは、最悪の事態を考えながら仕事をするんですよね。それはすごく重要なスキルだったりしますよね。あまり楽天的過ぎるとCPU資源を食い尽くしちゃうプログラムを作ってきたりしちゃうんですよ（笑）そういう意味では楽天的ではない方がいいですけど、でも、やはりポジティブな方がいいと思います。

柴田そうですね。難しいそうですけどね（笑）

柴田私、若い技術者と5分くらい話すと、その人がどのくらいのスキルを持っているかって大体わかるんですよ。どういうところを見るかっていうと、出来る子って観察力が鋭くて、周りのことをよく見ているんですよ。こちらがボーっとしていると気がついて、気を遣ってくれたりとかする子がいますけど、そういう子って出来る子が多いんです。普段からすごく周りのものに気をつけているような人は技術者としてもスキルが高いんです。だから・・・ネガティブになっちゃうっていうのもよく分かる気がしますね。

柴田普段から最悪の事態を想定して生活しているってことですからね。

柴田あ、あと最後に１つ。技術者はやはり技術者なので、会社を興して一旗揚げたいなら、早いうちにいいパートナーを探した方がいいと思います。HONDAが本田宗一郎だけではうまくいかなくて藤沢武夫がパートナーになって上昇気流に乗ったという話は有名ですけど、多くの技術者はファイナンスにことも営業のことも分からないはずですから、パートナーを探すのは本当に重要なことじゃないかと思います。

柴田そうですね。アメリカだとすごくいるんですけどね。MITを出ていて、ハーバードビジネススクールに通っているような人だってごろごろしていますよね。大学の研究室でも後押しをしはじめたりもしていますので、これから日本も変わっていくとは思いますけどね。

柴田こちらこそ、ありがとうございました。