インタビュー記事

interview

第14回 柴田淳 氏

shibata_main

今回は、小山哲志さんのご紹介で、ウェブコアの代表取締役「柴田淳」さんにお話をお聞きしました。柴田さんは、「Python」のユーザー会の理事、PostgreSQLユーザー会の理事も勤めるOSSコミュニティで活躍する横顔もお持ちです。取材会場は、環状8号線、砧の東名インター近くのスターバックスです。

※取材日は、2007年11月です。所属や役職などは当時のまま掲載しております。

<「Webエンジニアの武勇伝」について>
川井 本日は「Webエンジニアの武勇伝」ということでよろしくお願いいたします。
柴田 こちらこそ、よろしくお願いいたします。これまでの記事は全部、拝見しましたけど、面白いですね。
川井 そうですか! ありがとうございます!
柴田 技術的な話はどこでもありますけど、生き様とか生い立ちとか、そういうインタビューって飲み会でもないとなかなかないので、とても興味深いですね。
川井 確かにそう思って、ちょっと視点を変えている部分はありますね。それにトップエンジニアの方って今となっては雲の上の人みたいな感じもありますが、そもそもパソコンを始めた頃とかは、それほど変わらない世界の方だったと思うんですよね。スタートは一緒だよっていうことを共有して、自分も努力次第で近づけるのではという気持ちを持ってもらいたいという狙いもあるんです。
柴田 なるほど。そうですね。根底に流れるものは有名な人もそうじゃない人もあまり変わらないような気がします。
川井 話を聞いていると、本当に共通項がいっぱいあるなと思いますね。

PCとの出会いは
川井 それでは、お決まりの(笑)PCとの出会いについて教えてください。
柴田 私が、一番初めにパソコンを始めたのは、中学校2年生のときですね。その頃はまだマイコンって呼ばれていた時代で、いわゆる8ビット機ですね。PC8001とか、シャープのMZとかそういうのが、ちょっと技術の興味のある子供たちの間で流行っていましたね。どういう理由かは分からないんですが、そういうのに興味をもって、親に頼んで買ってもらったのが最初です。
川井 興味を持ったきっかけっていつも気になっているんですけどね。お父さんの影響という方が多い感じもしますが、そういうこともないんですか?
柴田 私は、親の影響はあんまりなくて、昔から工作とかものを作るのが好きで、自分でプログラムっていうものが組めてそれが自由になるってところに興味を感じたんです。ちょうど、当時だとゲームセンターとかでパックマンとかが結構流行っていて、ひょっとしたらそういうものも作れるんじゃないかという妄想もありましたね。
川井 パックマンっていうと、もしかすると同じ年代ですね。おいくつですか?
柴田 38歳です。昭和44年生まれですね。
川井 私は45年の早生まれなので、同じ学年ですね!
柴田 私がパソコンを買ったのはゲームが作りたいっていう志向性があったからなんです。当時って、パソコンの雑誌がいくつかあって、「I/O」とか「ASCII」とか電波新聞社が出していた「月間マイコン」とか「マイコンBASICマガジン」みたいなやつなんですが、そういう雑誌に何か作って投稿すると載せてもらえるんですね。それを目指して頑張ろうかと思っていたんです。それで、一番最初に作ったゲームを投稿したら、たまたまそれが載っかってしまったんです。
川井 それはすごいですね。
柴田 それでまた何を血迷ったか、五反田にある電波新聞社の編集部に遊びに行ってみようかと思って、当時の自宅のあった多摩から1時間くらいかけて1人で行ってみたんです。それで遊びにいったらそこでまた原稿を頼まれるようになったり、中学、高校のときはそんなことばかりしていました。
川井 いやあ、中学・高校でそういうことをしている人はあまりいないですよね。
柴田 なんでしょうね、物好きだったんだと思いますね。
川井 いやいや。
柴田 当時は、雑誌って印刷代とか紙代は広告費で賄って、実際に売れた部分が儲けっていうモデルだったんですが、パソコン雑誌ではそれこそパソコンの広告をとるってことが至上命題だったらしいんですが、そのためには、そのパソコンで作ったものが出ていないと駄目らしいんですね。
川井 なるほど。それはそうですね。
柴田 それで、「MS-Xっていうパソコンが出るから、機械貸すんでゲーム作ってよ」とかそんなことを頼まれたりしていたんです。だから家にMS-Xの試作機とかをもって帰ってきたんです。木の板にボードが乗っかっていて、キーボードが貼り付けてあって、コンポジット端子がついていてテレビに映せるみたいなやつでしたね。渡されたマニュアルも英語で全然分からない中でやっていましたね。
川井 天才少年みたいですね。
柴田 いや、単に、物好きで、怖いもの知らずなだけだったんだと思いますよ。
川井 いやあ、なかなかいないと思います。
柴田 まあ、確かに(笑) そういうところなので、なかなかすごい人が集まってきていたので、すごく刺激を受けましたね。原稿を書いている人たちとか、東大のマイコン部とかコミュニティがあったんですよね。そういう人たちが編集部にたむろっていたので、いろいろ話をしたりして刺激を受けましたね。
川井 他の事には目もくれずに、パソコンのことっていう感じだったんでしょうか?
柴田 そうですね。人並みには勉強もしましたけど、やはりパソコン中心でしたね。
川井 そうすると、このまま業界一直線って感じですよね。
柴田 そうですね。大学に入ると、今度はX68000の雑誌である「Oh!X」というのがあって、そこでライターをやったりしました。で、ライターの稼ぎがそこそこあったので、就職しないで、そのまま専業のライターになっちゃったんですよ。
川井 すごいですね。それだけで食っていけたってことですよね。主にはどんなものを書いていたんですか?
柴田 自分でプログラムの記事を書いたり、ゲームを作って、そのことを書いたりしていました。ライターってやってみて分かったんですけど、本当に生活できるまで稼ごうと思うと、薄利多売でないとやっていられないんですよね。それが段々と辛くなってきたんです。人によっては、それがそういう仕事が合っているという人もいるとは思うんですけど、自分にとっては、薄利多売にするとクオリティを落とさなきゃいけないしと思うと、辛いものになってきてしまったんです。
川井 なるほど。
柴田 Webが出てきたこともあって、そろそろライターも潮時かなあって思い始めたんです。少なくともこのまま一生続けていく仕事ではないなって。そこで専業のプログラマに転進しようと思ったんです。

プログラマのスキルについて
川井 少し遡っちゃうんですが、大学はそういう学部だったんですか?
柴田 いえ、大学は英語をやってましたんで、完全に文系プログラマです。文系でそんなに忙しくなかったんで、ライターの仕事ができたんです。
川井 GREEの藤本さんがやっぱり英文科でしたね。
柴田 そうでしたか。大学教育ってプログラマの能力っていう点でいうとあんまり関係ない気がしますね。高々4年ですから、小さい頃からパソコンに触れられたとか10代の頃の環境の方が大切な気がします。
川井 確かに、このコーナーに登場いただいた皆さんに共通されているのは小さい頃からパソコンに触れている点ですね。
柴田 20歳ちょっと過ぎくらいの未踏のスーパープログラマと言われている方たちとたまに話す機会があるんですけど、そういう人たちに聞いてみると、お父さんが開発をしていて、昔からパソコンが自由に使えたって言っていて、割とそれは共通していますね。教育がまったく無力だとは言わないですけど、教育で数年間やるよりも、中学生とか高校生とか自分の自由になる時間が本当にたくさんある時期にそういったものに触れられている時間をたくさん持つ、そういう環境があるかないかっていうのが本当に大きいですね。
川井 なるほど。
柴田 それが決定づけますね。ただ、それを逆転することもできるんです。それはよい師匠を見つけることですね。そういう中学、高校ぐらいに独学でプログラミングを学んだような人たちってやっぱり躓きながら学んでいるので、効率っていう面でいうとそんなによくないんですよ。そのかわり躓きながら学んでいるのでいろんな枝葉を勉強できるんですね。そもそもコンピュータってどうやって動いているんだとかというところまで勉強できるっていう利点があると思うんですけど、躓きながら学ぶ効率の悪さをよい師匠を見つけることで多少後から始めても同じところまでキャッチアップすることができるんです。
川井 なるほど、なるほど。
柴田 ちゃんと路を示してくれるんです。ちゃんとサジェストしてくれる人がいると、若い頃から環境に浸っていなかったっていう人でもかなりのスキルを身につけられると思います。例えば、大学4年間でコンピュータサイエンスを学んで、そのあと会社に入って、よい師匠を見つけて一流の技術者になるというある種の王道があると思います。
川井 徒弟制ってよくいいますよね。大手のSIなんかでは特にそういう風潮があるみたいですね。そういう点では柴田さんは子供の頃から触れてきている方ですよね。
柴田 そうですね。なので、職業プログラマと比べるともしかしては劣っている面があるかもしれません。でも私は、なんでもできる人でいたいんです。プログラムを作るだけではなくて、ドキュメントを作るとかマニュアルを作るとかいうことも必要だと思うんですが、そういうときにはライターをしていたときの経験はすごく生きていますね。純粋にプログラマとしてみると、なんていうんでしょうか、普通のというか第一線の人と比べると劣っている部分があるというのが自己分析なんです。
川井 そうなんですか?
柴田 そうなんです。ですけど、総合力で見ると、そこそこいいところにいっているというのは自分にとっては幸せなことですね。これは人によって違うとは思いますけどね。開発だけをばりばりやるのが幸せな人もいれば、マネジメントや商品開発もするのがいい人もいますので。
川井 プログラマは、技術の職人なのかビジネスマンなのかっていうことはよくテーマになるところですよね。
柴田 日本の会社の仕組みが変わってきていて、年功序列とか終身雇用とかは崩れてきているとはいっても、人生のライフステージっていうのはあるじゃないですか。年齢がいくと結婚したり、子供を作ったりとか、奥さんにそそのかされて家を買っちゃったりとか、それなりに、身入りが必要ですよね。やっぱり年齢がいくとそれだけ、その人が生活を維持するためのコストがあがっていくんで、そのコストを満たすためにどうしなきゃいけないかってことだと思うんですね。
川井 そうですね。おっしゃるとおりです。
柴田 人によっては、開発がすごく得意で、一般的な開発者より100倍の生産性があるのであれば、開発に特化していけばいいし、そうでもないのであれば、もうちょっと商品開発か何かに特化をしてポテンシャルを上げるというか、自分のアウトプットが稼ぐお金を最大化するようにしなきゃいけないってことですよね。
川井 そうですね。ただ反対に一般的な開発者だとしても、奥さんや子供に対して、「稼げないけど開発の仕事が好きだからすっと開発だけをやりたい」って言って、許可さえもらえればそれでいいんじゃないかとも思いますし、そう指導していますね。
柴田 そうですね。一番不幸なのは、嫌なことをやり続けなきゃならないってことですからね。まず自分が何をやりたいかっていうのを見つけて、それをやり続けることのできる環境を作ることじゃないですかね。

最初の本格的な開発
川井 その後、プログラマになられて、どんな風にスキルを磨かれていったんですか?
柴田 プログラマになって結構いろんな開発をしたんですけど、自分の転機になったと思うのが、Macintoshでメールクライアントを開発する仕事をいただいたことがあって、3年もある長い仕事だったんですが、それが割と良い経験になりましたね。その当時、2000年の初頭にかけてだったんですが、ソフトウェアのパッケージ販売って結構リスキーで、まず店頭に置いても売れないし、在庫を抱えて赤字になっちゃうこともあるし、「店頭販売はしません」ということを決めたんですね。そうなるとネットワーク上の露出であるとか、メーリングリストがあって、そこでサポートが受けられるとかそういうことが重要だったんですね。今だとそういうことって当たり前ですけど、当時のそのプロジェクトはそういうモデルの先がけだったんです。
川井 なるほど。
柴田 そのプロジェクトに関わって、開発もするんだけど、たまにメーリングリストで発言をしたりとか、ただの開発じゃない形で仕事をさえていただいていて、それが開発者としての転機になったかなという感じがしましたね。あと、割と小さなチームだったので、よく言うと少数精鋭で自分の意見が通りやすかったですね。例えば仕様が降りてきて、それを実装するためにはってことだけではなくて、こういう機能を追加したら面白そうじゃないですかっていうことを認めてもらいながら作っていけたというのが面白い部分だったような気がします。
川井 それは確かに面白いでしょうね。
柴田 あとインターネットというものの面白さもありましたね。
川井 開発環境は?
柴田 当時は、Macintosh用の環境のCodeWarrior、いわゆるクラスライブラリを使って、実装の言語はC++でした。当時は4人のチームだったんです。その中で実装の切り分けをして、UI担当の人がいたりとか、ネットワーク処理の担当の人がいたりとかしましたが、私はナットワーク処理とかファイル処理の担当をしていました。アプリケーションの開発なので、それだけではすまなくて、多少、UIのこともわかりながら開発をしなくちゃいけなかったのが面白かったですね。それに当時は、Macintoshも今のように成熟していなかったので、OSのバグっていうのがあったんですよ。
川井 え?
柴田 そりゃ、びっくりしましたね(笑) マルチスレッドでアプリケーションを稼動すると、ある特定のタイミングで落ちたりするんですよ。それが3ヶ月くらい原因が分からなくて、あるとききっかけがつかめて、デバッカーでOSのコードとかを追っていたら、ここだっていうのを見つけて・・・ただOSのバグなので直せないんですよ。直してくれとも言えないし。なので、それを回避するコードを考えなくちゃいけないんです。なかなか面白かったですね。
川井 なるほど。それは面白いでしょうね。
柴田 私がパソコンを始めた頃は、IOコードにパルスを出して、音を鳴らすとかすごくローレベルのプログラミングができたんですけど、そのプロジェクトがローレベルにタッチできる最後のプロジェクトだったと思います。それから先になると、例えば、CPUとかもディスクチップになってきてしまっていてマシンコードを追うことがほぼ不可能になってしまったんですね。ディスクチップっていうのは、例えばプログラムカウンターが進むことで命令を実行していくんですけど、きりのいいところでプログラムカウンターが進んでいくと処理速度が変わるんですよ。そのために、「ノップ」っていうんですが、プログラムのマシンコードは短いものと長いものがあるんですが、短いものがずっと重なるとその分、処理速度がその分遅くなってしまうんで、ゼロで埋めたりするんですよ。そういうマシンコードを追ってデバックするのはほぼ不可能ですよね。大抵、そういうコードって言うのはコンパイラーが入ったりとか機械的に生成されているコードなので、最適化をはかったりするんですよ。それを追ってデバックするのは相当大変だと思いますよ。今の人たちでドライバなんかを書いている人たちはどんな風にやっているのか興味がありますね。ちょっと私の能力では手に負えない感じなんですよ。そういうのもローレベルの開発が、そろそろ潮時かなって思ったトピックでしたね。
川井 なるほど。低レベルっていうのはどういう風に理解をすればいいですか?
柴田 そうですね。例えばスクリプト言語だと手続きを書くだけでいいじゃないです。でも低レベルだと割り込みのことを気にしなくちゃいけないとか、メモリ空間やレジスタのことも気にしなきゃいけないとかいう感じになるんです。
川井 なるほど。
柴田 私がパソコンを始めた頃は、少し早い処理をしようとするとマシン語を書かなくちゃいけなかったんですね。BASICはすごく遅かったので。今だとインターネットで動画がダウンロードできちゃいますけど、昔は雑誌に、打ち込むとアニメが表示されるようなプログラムのコードが載っていたんですけど、やっぱり早く書けた方がいいじゃないですか。もともとBASICが持っているライン文っていうのはポイントとポイントを指定してその間を線分で結ぶっていう命令なんですけど、遅いので、それ以上に早くしようとすると、自分でマシン語でまったく同じ処理をするサブルーチンを書かなくちゃいけないんですよ。
川井 そんなことが必要なんですか。
柴田 そういうことを中学・高校の時代に延々とやっていたんですが、面白いですよ。CPUの同じ命令でもオルタナティブがあるんですよ。オルタナティブの方が20%くらい早かったりするんですよ。それを入れ替えて使ったりしていました。その仕組みって、CPUの内部の仕組みを見ると、処理の過程がそっちの方が短かったりだとか、あとは同じ処理をするんだけど、マシンコードの長さが短かったりとか。このコードの長さが短いと、CPUがコードを読む時間が短いんで、処理が早くなるんです。ジェット80とかそういうマシン語をやったことがある人は分かると思うんですけど、アキュムレーターっていう計算をするのが強いレジスターがあって、それをゼロクリアしたいときに、やり方が何種類かあるんですよ。普通のやり方だとアキュムレーターってレジスタにゼロを代入するんです。だけれども、もっと早くゼロクリアする方法があって、結構びっくりするんですけれど、「XOR」って言うんですが、排他的論理和をとるんですね。排他的論理和をとると、同じレジスタ同士なので、立ってるビットと立ってるビットが合わさってゼロになってゼロクリアと同じ働きをするんです。ゼロをロードするって命令は、まずロードしますって命令があって、さらにゼロをロードしますって命令があるので、マシンコードは2つなんです。だけど、アキュムレーター同士で排他的論理和をとるっていうのは1つなんですよ。だから30%くらい早いんです。そういう裏技を駆使してちょっとずつ早くするっていうそういうことばっかりやっていました。
川井 それは力がつきそうですね。
柴田 今のパソコンってボードにBIOSが乗っていて、BIOSにスタートアップするためだけのプログラムが書いてあって、あとその先のOSとかライブラリはハードディスクに依存しているんですね。昔、私が持っていたシャープのクリーンマシーンってパソコンもそれとすごい近い構成になっていて、BASICも一度、テープから読み込むんですよ。だからマシン語でプログラムを書いていて、変なことをしちゃうと変なところにプログラムカウンターが行ってしまって固まったり暴走するんです。固まったりすると、リセットボタンを押して、でまたBASICを読み込んでって3分くらいやらないといけないんですよ。だから一度、失敗をしてしまうとリカバリーがすごく大変なんです。何回もトライアンドエラーをしないとプログラムってよくならないんですけど、一度、間違いを犯してしまうと、リカバリーの時間がかかるんで、何か試そうとする前にすごく試行実験をするんですよ。じゃないとやってられないんですよね。実際にちょっとやってみて、間違って3分待ってっていうことを繰り返すよりも、まず、ちゃんと試行実験をしてみてからっていう方が効率がいいんです。そういうことを学べたというのは貴重でしたね。
川井 なるほど、いろいろ学べる機会ってあるものなんですね。
柴田 そうですね。これは開発をする上でとても重要で、ちょっと仕事の遅い人とかを見ていると、あまり効率を考えないで、すごく使いづらそうな開発環境を使って書いているんですね。できる人は、自分がやらなきゃいけないことを効率的にこなすために、キーボードとかエディタとか開発環境にこだわりますよね。トライをしたあとのリカバリーの時間を最短にするのもそういうこだわりなんですよ。勿論、方法は人それぞれだと思うんですけどね。
川井 なるほど。
柴田 そのプロジェクトでメーラーの開発をして、Webの開発に移ったんです。Webの開発って、私が子供の頃やっていた低レベルの開発に比べると、ハイレベルじゃないですか。ほとんど文字列処理だけですし。でも、ハイレベルなんだけども根底に流れている「リカバリーの時間を最短にする」って言うのは変わらないですよね。パラダイムが変わってもそれだけは変わらないと思いますね。よい師匠はそこを教えてくれるんですよ。変に我慢強い人だと、やれっていわれると1日中それを繰り返したりしているんですけど、有能なプログラマとしてはそれはあまりよいことではないですよね。
川井 なるほど。ちなみに柴田さんにとって師匠と呼べる人っているんですか?
柴田 ライターを長くやっていたこともあって、有能な開発者の人たちとの交流はあったので、間接的に学ぶことは多かったんですが、誰か1人、師匠と呼べる人がいるかと聞かれると思い当たらないですね。私がプログラムを始めた頃はBASICマガジンとかいろんな雑誌があって、それにソースコードが載っていてそれで学べるんですよ。実際に自分で打ち込みも改造もしましたし。私、常々思うんですが、BASICマガジンみたいな雑誌って、オープンソースなんですよね。ソースをひらいているじゃないですか。そういう意味ではオープンソースって開発のプリミティブな形態なのかなって思いますね。
川井 確かにそういう見方もできますね。
柴田 プログラムが文化だとすると、それがないと前に進んでいかないんですよ。テクニックも流通しないし。
川井 そうですね。放っておくと盗めないし、好んで教える人も少ないですからね。

Pythonとの出会い
川井 その後の流れはどんな感じだったんでしょうか?
柴田 最初のプロジェクトのリーダーと「これからはWebですかね」という話もしていて、一緒にWebの開発に移ったんですが、最初に教わったのが、Zopeだったんです。Pythonで書かれたWebアプリケーションフレームワークですね。
川井 そうですか。しかし、この時代からPythonなんですね。
柴田 そうですね。当時は、Pythonの最新バージョンが1.5とかそんなもんでした。今は2.5かな。
川井 しかしWebの開発に移っていきなりPythonだったんですね。
柴田 そうですね。当時、Webの開発をしようということになって、日経BPのWebサイトを運営するためのシステムをつくるって仕事をオファーされて、面白そうだからやってみようと思ったんです。今で言うCMSですね。ZopeってCMSの構築には向いていて、Pythonってあまり聞かないけど面白そうだからってことで取り組み始めたんです。私は最初にやった尾パソコンもマイナーでずっと裏街道を歩いてきた人間なんで、ちょっと他の人が使わないようなものに惹かれるんですね。それでヒットしたのもありますけどね(笑)
川井 なんか分かる気もします。
柴田 メジャーじゃないところを狙うといいのは、競争相手が少ないんですよ。より少ない努力で目立つことができるじゃないですか。
川井 それは経営戦略でもありますからね。
柴田 まあ、ニッチは流れが速いので大変ですけどね。特にWebなんかはさらに大変ですね。それにニッチな世界での開発だと、情報が流れてくるのが海外からなんですよ。だから英語を少なくとも読めないとまずいですよね。書ければなおいいし、話せれば楽しいと思います。英語ができると他の人がリーチするより早い段階でリーチできるんですよ。
川井 明らかに情報は海外が早いですからね。
柴田 特にオープンソースの世界は、関わっている人も多いし、才能のある人もかなりいるので、全部、自分でやろうとしない方がいいですね。流れを読んで、うまく流れに乗って、全体の1%でも自分で何か生産的なことができればいいくらいじゃないですか。それぐらいの気構えでいかないと疲れちゃいますよ。
川井 個人知じゃなくて集合知ですからね。
柴田 逆に利用しようというくらいの方がいいかもしれませんね。
柴田 Zopeの仕事を始めて、当時は日本語の文献どころかアメリカの文献もなかったので、もうソースコードを読むしかなかったんですね。ただZopeはよくできていて、今でこそ、皆さんは、Ruby on 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ってそういう意味で、すごく重要な意味を占めていて、ちょっと一昔前に騒がれたんですけど、Paul Graham の「Pythonのパラドックス」って説があるんです。例えば、「Javaの仕事の求人をするときに、必ずPythonのスキルを求めなさい」ってことなんですけど、Javaの技術者のスキルってピンきりじゃないですか。でもできれば優秀な技術者が欲しい。そういうときにPythonみたいにマイナーだけど技術的に研ぎ澄まされているそういうスキルを要求すると、Javaができる人の中でもすごくアンテナを張っていて、最新技術を習得する意欲のある人が集まってくるっていう意味なんです。
http://practical-scheme.net/trans/pypar-j.html
川井 なるほど。
柴田 最近は「Pythonのパラドックス」ではなくて、「Rubyのパラドックス」とか言われるみたいですけどね。
川井 確かに、我々もRailsで募集をかけると、Javaの技術が高い技術者の方が応募してきますね。
柴田 当時は特にまだ「Pythonのパラドックス」がすごく効いていた時代で、Pythonの持っている素養を見抜く人は、もう1990年代の終わりの頃からオブジェクト指向のWeb開発をしていて、自分たちでオープンソースのオブジェクトデータベースを作って、それを仕事に使っちゃうようなすごい人が集まっていたんですよ。今、思い返すとそれはすごく象徴的なことだと思います。
川井 それから、Python一筋できているんですよね?
柴田 そうですね。Pythonは要素技術なので、PostgreSQLみたいなリレーショナルデータベースも使うことがありますけど、仕事をする上ではPythonですね。たまにブリッジを書いてくれといわれてJavaとかPHPを扱ったりもしますけどね。Pythonがフロントエンドになっていて、ビジネスエンドとかバックエンドがPHPとかPerlとかJavaになっていてちょっとだけ書くようなケースですね。
川井 それでも、書けちゃうんですよね。結構なんでも書けちゃう方ですか?
柴田 なんでもというわけでもないですけど、比較的好き嫌いなく、メジャーな言語は大体大丈夫ですね。元は同じなので、あまり変わらないですよ。
川井 Pythonを始めたときは、どこかの会社にはいってやっていたんですか?
柴田 その時は、仲間と別の会社を立てて、そこで仕事をしていました。
川井 共同経営みたいな感じですか?
柴田 そうですね。
川井 受託系の会社ですか?
柴田 その会社は面白い会社で、たまに書籍の出版をしたり、英訳もしていましたね。ただ、しばらく続けていくうちに、やっている内容がはっきりと分かれてくるようになったので、私だけ別の会社を作ったという流れです。
川井 これが4年前ですね?
柴田 そうですね。
川井 何か、問題でもあったのですか?
柴田 会社って家みたいなものだと思うんですけど、あまり家の中で違うことをやっている人たちがいるってあまりよくないことだなって思って、あまりシナジーのあることでもないし、分けた方がいいよねって感じでしたね。
川井 独立すると仕事を自分でとってこないといけないと思うんですが、そのあたりは人脈とかでいけたんですか?
柴田 そうですね。私、あまり営業をしないんですよ。というのは営業してしまうと開発の時間が取れないんですね。なので営業しないんです。ただ、日々の仕事というかすでにお付き合いをいただいているお客さんがいるので、そこから追加で仕事をいただいたりとかしていますね。ニッチなところでやっていると、ただWebサイトを持っているだけで、お話をいただいたりすることもすごく多いですね。
川井 キーワード検索であたりますもんね。
柴田 そうですね。今、柱になっているのはプローンっていうZopeの上に作られたフレームワークがあって、これもCMSを作るためのものなんですが、XOOPSに近いような感じですね。そのプローンを使った案件が一番多いですね。
川井 本になってましたっけ? 確かPython×・・・って本があったかと思いますが。
柴田 技術評論社のやつですね。あれは私の本なんですが、「TurboGears×Python」っていう本で、平たく言ってしまうとPython版のRuby on Railsみたいなものですね。そう言うとPythonの人は嫌がるんですよね(笑) 昔はO’Reillyの翻訳本しかなかったんですが、最近はPythonの書籍がたくさん出てますね。
川井 確かに。よくみますよね。
柴田 ニッチなところで仕事をしていくって上で、雑誌の露出とか書籍の露出ってとても大きくて、私も、昨年「みんなのPython」っていう書籍を書かせていただいたんですけど、お陰さまで好評なんです。実は私、Pythonのコミュニティに関わって長いんですけど、自分で書籍を書くなんてことはまったく想像していなくて、誰か他の人が日本で始めての入門書を書くんだろうなあって思っていたんですけど、たまたま、出会いがあってお話しをいただいて、大変なのは分かっていたんですが、ライター経験もあったしブランディングにもなるし、やってみようかなって思って始めたんです。
川井 分かります。とても影響が大きいですよね。
柴田 この本は440ページくらいあるんですけど、すべての仕事をストップして、かかりっきりになって2ヶ月くらいかかったんです。辛かったけど、苦労した甲斐があったってすごく思いますね。この本を読んでいただいて、お声をかけていただくことが多くなりましたからね。
川井 なるほど。
柴田 比較的、簡易なことから書いているんですよ。私は基本的に人を信用しないところがあって、ずべての前提知識がないものと思って書いたんです。
川井 レベル的には、Webアプリケーション開発をやっていないと読めない感じですか?
柴田 いえ、まったくプログラミングをやっていなくても大丈夫だと思います。変数に代入するとどうなってというところから全部書いています。
川井 よく「素人のための」というような本があっても、読んでみると素人じゃ分からないことが結構あるなんてケースが多いんですけど、そのあたりはいかがですか?
柴田 やっぱり技術者の目線だと暗黙知のレベルが高くなっちゃうんじゃないですかね。私はライターをやっていたこともあって、そのあたりは、未経験の方でも分かるように書けたという思いがありますね。なんでワープロでプログラムを書いちゃ駄目なのかとか、本当はそういうところから説明した方がいいかもしれないですからね。
川井 何より、未経験だと分からないのが、このプログラムがどうしたら動くのかっていうのを実感していなんですよね。なので、何をどう組み合わせて、どういう条件や環境があると動くのかが分からないんです。
柴田 昔は、プログラムとコンピュータが近いところになったので、こうすればこう動くっていうのがすごく分かりやすかったんですよ。例えば、「Hello world」ってあるじゃないですか。昔は、「Hello world」が表示されると「あ! 表示された!」ってすごく嬉しかったんですよね。今って、Javaで「Hello world」を書いて、コンパイルして走らせてみましょうって言って表示されても誰も喜ばないと思うんですよ。それってすごく重要で、何か学ぶってことは、学ぶために投入したエネルギーのリターンが必要なんですよ。そのサイクルがないと学ぶことを続けていけないんですよ。そのサイクルをうまく作りながらちょっとずつ進めていくのが学ぶって過程だと思います。でも今は、リターンを得るためのハードルがすごく高くなってしまっていて、昔だったら記号を組み合わせて人間の形をつくるダスキーアートみたいなもので、うまくパラパラ漫画みたいに入れ替えて、表示すると走っているように見えるっていうところでもみんな喜んだんですよ。今はだれもそんなんじゃ喜ばないですよね。だってインターネットで動画とかバンバン入ってくる時代ですからね。
川井 確かにそうですね。
柴田 昔は本当にコンピュータで音を出すだけでも喜べたんですけどね。今はハードルが高すぎて学ことのためのリターンを得るのがすごく難しくなっていますよね。だからプログラミングを始める人たちは、最初の段階では、プログラミングをした結果が目に見えやすい形でリターンとして帰ってくるようなものを使った方が続けていきやすいかもしれないですね。
川井 掲示板でもいいから作ってしまった方がいいっていわれますね。
柴田 ええ、動くものを作らないとリターンが得られないですよね。
川井 車に乗っているとしたら、マニュアルじゃなくてオートマですよね。ひょっとしたらゴーカートに近い感覚なのかもしれません。
柴田 そうかもしれませんね。ペダルとブレーキ踏んでいるだけで、たまにハンドルを動かすくらいのことかもしれませんね。

Pythonのユーザー会について
川井 Pythonのコミュニティはどんな経緯で入られたんですか?
柴田 コミュニティはもともとそういうのが好きだったという感じなんですが、Pythonのコミュニティに最初に関わったのは、PyJUG(Pythonジャパンユーザーグループ)っていうコミュニティがあって、その結成会のOFF会があったのがきっかけです。PyJUGの命名には実はいわくがあって、本当はJPUG(ジャパンPythonユーザーグループ)がよかったんですけど、日本PostgreSQLユーザー会がすでにJPUGと命名されていたんで、それでPyJUGにしたんです。今、私は両方に関わっているんですけど、なんか変ですよね(笑)
川井 笑
柴田 コミュニティは6年くらいですかね。当時は、今以上にPythonっていうのはマイナーで、そこに集まってくる人たちはすごかったですね。当時Pythonを知っている人っていうのは前提条件として英語が読めて、技術者としても第一線でもそこそこ活躍している。そしてアンテナも立っている人ばかりでしたね。面白い話があるんです。昔、Pythonのメーリングリストで発言した人のところにヘッドハンティングの電話が順番にかかってきたことがあったんです。狙い目とはいいと思いましたね。
川井 今は、どんな感じなんですか?
柴田 かなりゆるい組織なので、会長もいませんし、決まりもないんです。PyJUGっていう組織があって、メーリングリストがあって、たまにイベントをやります、以上みたいな感じです。
川井 PHPユーザー会の雰囲気に似ている感じですかね。
柴田 コミュニティって有機的なものだと思うんですよ。その有機的なものを安定的にしていこうと思うと、まず人が集まって、そして新陳代謝がないと駄目なんですよね。なので、なるべく私から仕掛けて、外に出るイベントをたくさんやっていきたいなって思っています。
川井 なるほど。
柴田 これを話すとびっくりされるんですけど、2006年の4月に勉強会の拡大版をやったんですけど、場所はどこだと思います? 新宿の某所なんですけど。
川井 いやあ、どこでしょう? 見当もつきませんね。
柴田 マイクロソフトでやったんですよ。マイクロソフトがオープンソースの勉強会に会場を貸してくれるって意外ですよね。GPLは駄目らしいんですけど、PythonはBSDライセンスに近いので、そのあたりでOKだったらしいんです。
川井 そうなんですか。
柴田 最近は、.NETで動くアイアンPythonっていうPythonの実装系があって、開発者はマイクロソフトの社員なんですよ。Jim Huguninっていうんですけどね。なので、まったく縁がないわけじゃないんですけどね。
川井 マイクロソフトさんは、オープンソースにイベントに行くと必ずいらしてますし、力を入れているんじゃないでしょうかね。
柴田 その一環かもしれませんね。
川井 ですね。
柴田 去年はマイクロソフトで、今年は、東京大学の駒場キャンパスでやったんです。
川井 そうなんですか。
柴田 講演も、マイクロソフトのMVPの新井さんにお願いしてアイアンPythonについて話していただいて、それが縁で、新井さんはアイアンPythonの本も出されたんです。
川井 いろんなつながりがあって面白いですね。
柴田 リアルなところに出て行くと、いろんな人とつながりあえますね。新陳代謝っていう観点でいうと、新しいヒーローが現れてこないと、コミュニティって大きくなっていかないし、続いていかないと思うんですよ。なのでイベントでそういう人に話す機会を与えたり、話すことで注目を浴びたりということもあるので、イベントは定期的にやっていきたいと思いますね。
川井 なるほど。これから楽しみですね。

これからの方向性は?
川井 これから先は、どんなことをされる予定ですか?
柴田 5年くらいでWebの次のものを見つけたいですね。そして5年くらい、Webをやる傍らで、その次のものにちょっと投資をして、10年後くらいに完全に移行できるといいですね。自分の人生を振り返ると、まずライターを10年弱くらいやって、Webの開発に移って5年くらいたつんですが、あと5年くらいで、業界というかWeb自体が成長の頂点を迎えると思うんですよね。そこにしがみついていると、仕事も立ち行かなくなってしまうと思うので、それまでに次のものを見つけて移りたいなあと思うんです。ちょっと長期的なビジョンですけどね。それ以上は流れが速すぎて分かりません。
川井 確かに変わりますからね。
柴田 そうですね。変わるってことはすごく重要ですね。その変化に対応するだけの体力をつけていかなければならないと思いますね。でも、ローレベルな開発をしていても、アプリケーションの開発をしていても、Webの開発をしていても根底に流れているものは同じなんですよ。エンジニアとして生きていくなら、まず根底に流れているものをしっかりと自分の体にしみ込ませて、あとは世の中の動きを良く見て、自分がそこにいると幸せだなというところを見つけて、そこにいられるような環境を作ることが大事なのかなって思いますね。
川井 なるほど。
柴田 その前提として、変化するってことは肝に銘じておかないといけないことですね。Zopeみたいなものをやっていてつくづく思うんですけども、Zopeって出た当時はもてはやされて、いたんです。ただ開発にはいくつかのレイヤーがあって、まずOSみたいな低レベルなもの、スクリプト言語みたいなもう少しハイレイヤーなところ、そしてZopeとかRuby on Railsみたいなアプリケーションフレームワークっていう言語の上に乗っかっている要素技術があるんですが、上のレイヤーに行けばいくほど寿命が短いんです。Zopeはもうすでにフレームワークとしてみると老練期に入っていている感じがしていますね。なのでフレームワークの寿命って5年とか10年のような気がしますね。
川井 なるほど。
柴田 例えば、人が大学を出て、60歳くらいで定年を迎えるまで、大体40年くらいなんですが、その40年を5年で割ると、8つですよね。なので仕事をしているうちにフレームワークだけ見ると4つとか5つぐらい変えていかなくちゃいけないってことですよね。
川井 そうなりますね。
柴田 フレームワークの寿命もありますけど、言語の寿命ってのもあって、今、RubyとかPythonとか言われていますけど、あと20年後は全然違うものが出てきているでしょうね。まったく使われないかもしれませんね。COBOLくらいれレガシィになれば別ですけどね。最近はJavaなんかもそんな感じかもしれないですね。でも新しいものほど移り変わるのが早いんでなんとも言えませんけどね。
川井 いずれにしても変わるってことですよね。
柴田 そうです。変化を前提としなくちゃいけませんね。ただ、毎回毎回いちから勉強するのは辛すぎるので、すべてのベースになる基本があるので、それをしっかり身につけて、基本からはずれる部分だけ勉強するようにして新しいものに対応するのが効率的な生き方ですかね。

若いエンジニアに向けて
川井 すでに大分、流れが若手へのメッセージになってきているかと思いますが、改めて、若いエンジニアにアドバイスをいただけませんでしょうか。
柴田 若い人だと自分が言語やフレームワークを変えた経験がないと思うんです。でもそういう可能性があるってことを前提としていれば、日ごろのスキルアップの仕方や対応姿勢がいろいろ変わることがあると思いますね。僕も仕事で使った言語は3つ目ですが、これからも変わっていくと思うので、それを前提に考えていますからね。
川井 なるほど。他にはいかがでしょうか?
柴田 一部繰り返しになりますが、楽しむかが重要だと思います。自分にとって楽しいことは何なのかを早く知って、その楽しいことを続けられる環境を作ることですかね。それが重要だと思いますよ。
川井 嫌いじゃないんでしょうけど、辛そうに書いていて、とても好きなことをしているように見えない人もいますよね。
柴田 うーん、やっぱり基本的に仕事をしていて、プロとしてポジティブな方がいいですよね。でもパーソナリティもあるんでね。技術者で難しいのは、すごくネガティブな人の方がスキルフルだったりするケースも多いじゃないですか、だから技術者の場合には、一概にそうは言えないのかもしれないんですけどね(笑)
川井 笑
柴田 ネガティブな人がいいのは、最悪の事態を考えながら仕事をするんですよね。それはすごく重要なスキルだったりしますよね。あまり楽天的過ぎるとCPU資源を食い尽くしちゃうプログラムを作ってきたりしちゃうんですよね(笑)そういう意味では楽天的ではない方がいいですけど、やはりポジティブな方がいいと思います。
川井 発想はポジティブで仕事はネガティブという感じですか?
柴田 そうですね。難しいそうですけどね(笑)
川井 自分の人生はポジティブに生きてきても、技術の仕事をしたらネガティブな感覚が身について、人生までネガティブな発想になっちゃうなんて話も聞くんですが、そんなものなんですかね?
柴田 私、若い技術者と5分くらい話すと、その人がどのくらいのスキルを持っているかって大体わかるんですよ。どういうところを見るかっていうと、出来る子って観察力が鋭くて、周りのことをよく見ているんですよ。こちらがボーっとしていると気がついて、気を遣ってくれたりとかする子がいますけど、そういう子って出来る子が多いんです。それは何かっていうと、普段からすごくものを気をつけている人は技術者としてもスキルが高くて、だから・・・ネガティブになっちゃうっていうのもよく分かる気がしますね。
川井 なるほどなるほど。
柴田 普段から最悪の事態を想定して生活しているってことですからね。
川井 私にはそういうことはできませんね(笑)
柴田 あ、あと最後に1つ。技術者はやはり技術者なので、会社を興して一旗揚げたいなら、早いうちにいいパートナーを探した方がいいと思います。HONDAが本田総一郎だけではうまくいかなくて藤沢がパートナーになって上昇気流に乗ったという話は有名ですけど、多くの技術者はファイナンスにことも営業のことも分からないはずですから、パートナーを探すのは本当に重要なことじゃないかと思います。
川井 日本の技術者でオールラウンドに出来る人って少ないですよね。
柴田 そうですね。アメリカだとすごくいるんですけどな。MITを出ていて、ハーバードビジネススクールみたいな人だってごろごろしていますよね。大学の研究室でも後押しをしはじめたりもしていますので、これから日本も変わっていくとは思いますけどね。
川井 そうなっていくといいですし、我々もそういうエンジニアの活躍を応援していきたいと思います。今日は本当にありがとうございました。
柴田 こちらこそ、ありがとうございました。

LINEで送る
Pocket

TO TOP