COBOLをシートに手書きしていた頃。80～90年代、OSS普及前の開発風景に学ぶこと

瀧田佐登子さん：大学卒業後、国内大手メーカーでCAD開発に携わるエンジニアとしてキャリアをスタートさせる。Unixへの傾倒を経て、1996年、日本ネットスケープコミュニケーションズに入社し、ブラウザの国際化・日本語化を担当。その後、2004年にMozilla Japanを設立し、Firefoxの開発、普及に尽力する。2006年に代表就任。2017年には同法人は「一般社団法人WebDINO Japan」に改称され、Webとオープンソースを軸に、オープンイノベーションの拡大に注力する。

──1986年に大手メーカーに入社され、エンジニアとしてのキャリアが始まったと聞いています。当時のプログラミング環境はどのようなものだったのでしょうか。

瀧田　私はもともとソフトウェア畑ではなく、大学では化学を学んでいたんですね。社会に出るまでは、実はコンピューターというものを触ったこともなかったんです。

そんな私が社会人1年目にやったのは、コーディングシートにCOBOLのコードを書くことでした。スクリプト言語やHTMLを今はエディタに打ち込むじゃないですか。でも、当時は紙にコードを書いていたんです。イメージできますか（笑）。コーディングシートというのは原稿用紙のような紙で言語別に売っていて、それにコードを手で書いていくんです。コンピュータといえば大型汎用機の時代でしたから、個人がパソコンを持っている、なんてことはありません。

そして、コーディングシートに書いたプログラムを、今度はパンチカードと呼ばれる紙にパンチしていくんです。当時はパンチャーと呼ばれる、パンチ作業専門のスタッフもいたんですよ。

上はパンチカードの参考画像。画像出典：Wikimedia Commons

そのパンチカードの束を、まるで銀行のお札を数える機械のように、パソコンに読み込ませていって、一つのプログラムになります。だから開発スタイルというのはまずは机に向かって紙に書く、という方式でしたね。

──紙に書いてたとは今では信じられませんが、ほんの30年前と考えると技術の進歩の速さを感じますね……。 当時はインターネットもまだ発達していないと思うのですが、どうやってプログラミングの勉強をしていたのでしょうか。

瀧田　当時は本を読むか、人のコードを読むかしかなかったですね。先輩が書いたコードを読むのですが、さっき説明したコーディングシートが綴じられた、分厚いファイルから目当ての情報を探して読むわけです。当時の先輩が書くコードって綺麗だったのですごく勉強になった記憶がありますね。今はインターネットで情報が探せて、コピペもできるのでラクですよね（笑）。

──その後、転職されC言語やJavaを学んだそうですが、そのときには勉強方法は変わっていたのでしょうか。

瀧田　富士ゼロックスの関連会社にいたときのことですね。当時サン・マイクロシステムズ（後にオラクルに吸収合併される）のマシンを使ってC言語を触っていたのですが、私は開発業務に加えてC言語のトレーニング講師もしていたので、人に教えることで勉強したと感じています。90年代前半だったのですが、まだインターネットに情報が溢れている、という状況ではありませんでした。なので、やっぱり本から勉強したり、同僚に聞きに行ったりしていましたよ。当時はよくポインターで手詰まりになってアドレス計算で落ちてましたね（笑）。

──徐々にインターネットの存在が一般化してきたのでしょうか。

瀧田　インターネットというものに世の中が価値を見出し始めたのは90年代のことです。商用インターネットが始まったのが1991～1992年頃でした。ただ、1995年頃までは、まだインターネットは常時接続もしていない状況で、そもそも接続するにも複雑な経路をたどる必要があったんです。

また、商用化が始まって間もない頃はインターネットは高価なものでした。メールも「何文字を送ったらいくら」のように、いまで言う従量課金制です。さらにメールはコマンドベースで打っていたので、ある程度の技術がないと送信すらできません（笑）。

肌で知る80～90年台のオープンソース前史

──オープンソースという概念は、そういったインターネットが発達していないときにはあったのでしょうか。

瀧田　「オープンソース」という名前がない状況でしたが、研究者や技術者は大学で集まって技術情報を共有していたりして、決して情報が完全に閉鎖されている印象ではなかったと思います。

また、オープンソースに近しいものが存在しなかったというわけではなく、インターネットの歴史をたどると、RFC（Request for Comments）のようなリクワイアメントを言いたいだけ言って、意見を出しあい開発を進めていく文化は、現在のオープンソースのはしりであったと思います。

「オープンソース」とちゃんと認識され始めたのは、私がいたネットスケープ社が1998年にNetscape Communicatorのソースコードを公開した頃でしょうか。その少し前にLinuxが出てきて、そのくらいの時期に「フリーソフトウェア」と呼ばれるソフトウェアが注目されるようになった印象もありますね。

──OSSが一般化される以前は、開発に不自由を感じることはありましたか。

瀧田　私は企業に所属していたので開発環境は会社が用意してくれていたのでよかったのですが、コンパイラのライセンスだけで30万円はする時代でした。OSがバージョンアップしてそのコンパイラが動かなくなったりすると、またアップデートのための料金がかかったりするんですよね（笑）。

でも、こうした世界観でソフトウェア産業は成り立っていました。「ソフトは買うもの」という認識を前提にビジネスモデルがあり、「買うソフト＝信頼性が高いソフト」という安心感があったと思います。

ただ、会社に自分のマシンがあるといろんな環境を作りたくなります。そうするとプロプライエタリだけでは環境が充実しなくなってくるんです。そのときに救いだったのがGNUのフリーソフトウェアだったんです。

GNUの開発は84年に始まった。

ただ、その当時はネットワークがまだまだ一般にないので、簡単に入手する術がなかったんですね。なので誰かにCD-ROMに焼いてもらったり、雑誌の付録で手に入れるしかないという状況です。フリーソフトウェアと言いつつ、入手は気軽ではなかった印象があります。

こうして手に入れたGNUのソフトはあくまで趣味で使うもので、信用性は低いと見られていて、商用ベースでは使用しにくい風潮があったんです。

──プロプライエタリだからこそ価値がある、と考えられていたわけですね。そうした状況が変わり、フリーソフトウェアやOSSが認知されだしたと感じられる瞬間はあったのでしょうか。

瀧田　面白いな、と感じるのは開発に使うソフトウェアがだんだんと変化していくのですが、その背後にあるインターネットの普及や回線が太くなっていく流れとリンクしていることです。ネットスケープ社でもLinuxが出始めた頃から、フリーソフトウェアのGCC（GNU Compiler Collection）を使う流れが出てきました。

そして、2004年頃からインターネットが常時接続のブロードバンド化していき、価格も一般に普及しやすいものになり、同時期にフリーソフトウェアやOSSが市民権を得たように思います。

「オープンソース化」が技術継承をもたらした

──インターネットの可能性にひかれ、Netscape製品に関わるようになったそうですが、最初はどのような業務を担っていたのでしょうか。

瀧田　当時は東芝でインターネット事業の企画推進担当として、Netscape製品の買い付けやライセンス契約をしていたのですが、「これ日本語で使えないじゃん！」と思うわけです。日本のエンジニアとして、多言語を意識しないソフトウェアづくりが当たり前になっていることが許せなかったんです（笑）。

しばらくはライセンスを買う側としてバグのフィードバックなどをネットスケープ社にしていたのですが、ある日、声がかかってそのまま日本法人の日本ネットスケープ・コミュニケーションズ社に入社することになったんです。その後は米国の開発現場に飛んで、国際化担当エンジニアとして製品の開発に携わることになりました。

──いわゆる「中の人」として1998年のNetscape Communicatorのソースコード公開に立ち会われています。当時、瀧田さんはこの出来事をどう思われましたか。

瀧田　「やめてよ！」とは思いました。バイナリになってしまえば、周囲からは自分が書いたコードとは分からないからいいんですが、人にコードを見られてみんな恥ずかしくないのかなっていうことは思いました（笑）。

もちろん、驚きはしましたが、オープンソース化に対して喜びや怒りなど感情的なものは全然なかったですね。ある日、カフェテリアに社員全員集められて「ソースコードを公開する記念すべき日だ」って急に言われて、みんなポカーンだったんです。「これからどうなるのかな」という感じでしたね。

──ソースコードを公開したことが、将来的に良い方向に向かいそうな予感はあったのでしょうか。

瀧田　今こうやって振り返れば「衝撃的な出来事だったんだろうな」と思われるかもしれません。しかし、当時そこに居合わせた人達からすると「まあ、企業が財産を公開したよね」という程度で、ショッキングなことではなかったんですよね。それより「これからどうやって会社は儲けていくんだろう」っていう感じでした。

──それは意外ですね。

瀧田　しかし、振り返って感じるのは、もしソースコードを公開していなかったら、今のこのWebの進化というのはなかったかもしれないということです。Web業界はもっと違うものになっていたかもしれないと思いますね。

──それはなぜでしょうか。

瀧田　もし公開していなければ、あらゆる資産が葬り去られてしまったかもしれませんから。弱い企業はすぐに消えていきますし、特にネットスケープ社があったシリコンバレーは競争が激しく淘汰されるのは早いです。オープンソースでなければ、淘汰された企業が抱えこんでいた技術も一緒に死んでしまうことになります。

ネットスケープ社はJavaScriptやRSSの開発も行っていたので、もしオープンソースにしなかったら、それらの技術が死んでいた可能性だってあります。

ソースコード公開は突然の出来事で、当時のNetscapeにはさまざまなサードパーティー由来のコードなども含まれていて、公開できないコードもありました。公開できないコードは省き、いわば歯抜けのような状態でオープンソース化したわけです。が、当然、公開されたソースコードをコンパイルしてもちゃんと動かないということになり、叩かれたこともあります。

こんな経緯があったので、その後、ベースからエンジンを作り直そうという動きにつながるのですが、この時に公開されたソースコードは、必ず誰かのお手本にもなっていたはずです。意味は絶対にあったと思っています。

ソースコード公開後のNetscapeの開発、そして手痛い失敗

──オープンソース化したNetscapeですが、外部からのコントリビューションはどうやってやり取りしていたのでしょうか。

瀧田　ソースコードはCVSやApache Subversionといったバージョン管理システムが使用されていて、後にMercurialに移行していきました。今でもFirefoxの開発おいてはMercurialがメインで使用されています。

Bugzillaというバグトラッキングシステムを使用していて、それでバグのインプットだけでなく、ソースコードのパッチのコントリビュートなども管理しています。Firefoxの開発ではレビューする人がいて、さらにその上にスーパーレビュアーがレビューするという、2段階のレビューを設定して開発が進められていました。

1998年頃からBugzillaなどは社内で使用していて、Netscapeをオープンソース化した際に一緒に公開しています。こういったツールに関するドキュメントも全部公開されているんです。MDN（MDN Web Docsのこと。当時はMozilla Developer Center）にあるドキュメントなどは見たことがある方も多いでしょう。

Home :: Bugzilla :: bugzilla.org

──オープンソース化によって生まれた失敗や苦労はありましたか。

瀧田　ソースコード公開後のNetscapeは、外からはフルオープンなプロジェクトに見えたかもしれません。しかし、プロジェクトの運営という側面では、ネットスケープ社がコントロールしている状況が続いていました。特にマーケティングサイドで開発スケジュールをコントロールする部分などは失敗だったのではないかと思います。

オープンソースの世界に触れている人は分かると思いますが、作業をコントロールされるのは嫌なことでしょう。

オープンソースの開発において、誰かに「こうやりなさい」「ああやりなさい」「いつまでにこれをやってください」という命令は成り立たないはずです。協力してくれる人たちは仕事としてやっていないのですからね。

──いわゆるバザール方式¹の開発になっていなかったということでしょうか。

瀧田　なっていなかったと思います。MicrosoftのInternet Explorer（以下、IE）におされて、Netscapeのシェアが低下していくのは明白だったので、マーケティング的観点からオープンソース化して、すぐに次のバージョンであるNetscape 6.0を出したいという思惑があったはずです。

ソフトウェアのコアなエンジン部分が未熟なまま6.0を出してしまい、しかもバグだらけ。IEにほとんどシェアを奪われていて、Netscapeを使用してくれているのはわずかなユーザーでしたが、そのわずかなユーザーも失望させるものになってしまったのです。

──オープンソースならではの、人をコントロールできないもどかしさがあるんですね。

瀧田　コミュニティ形成は非常に難しい要素です。さまざまな要素のバランスをとり、どうすれば人が動いてくれるのかを考えなければなりません。

一方で、オープンソースだからといって100%、バザール方式が適しているかというと、それも考えなくちゃいけない部分だと思っています。バザール方式の中に、少しだけでも伽藍方式のポリシーがあるのが適している場合もあるのかなと思っています。

──コミュニティ内にイニシアチブをとる人がいた方が良い、ということとも考えられますね。両方を経験された瀧田さんならではだと思います。

瀧田　基本的にクローズド環境下でのソフトウェア開発の手法も、オープンなソフトウェア開発の手法も同じだと思っていますが、プロジェクトに参加する古い世代と新しい世代ではマインドが異なる場合もあります。

開発でも、昔ながらのやり方や、現在のアジャイル的なやり方があってどちらも重要だったりします。そうした中での共存がキーになるのだと思います。

Firefoxに引き継がれる、Netscapeの遺伝子

──Netscapeを経てFirefoxの開発が始まり、開発手法が洗練された部分などあるんのでしょうか。

瀧田　ソフトウェア工学的なやり方はNetscapeのときと大きく変わりません。ただオープンソースであるならば、プロジェクトに携わる人から多様な意見を全部言ってもらえるよう皆が意識していました。万人が公平なオープンソースの場では、とにかく意見を言い尽くすことが重要と考えたのだと思います。

そして、多様な意見が出てくるからこそ、ある程度の方向性を定める人は必要なのですが、本当にそのプロジェクトが実現すべきこと、進むべき方向性が急に提示される場合もあるので、当時は最初から一方的にスタンスを決めようとはしませんでした。

──「意見を全部言ってもらう」というのは難しいと思うのですが、どんな施策を行ったのでしょうか。

瀧田　ひとつ挙げるとすると、定期的に行われていたオフラインのミーティングは、やはり貴重な機会だったと思います。活発に参加しているコントリビューター（貢献者）には必ず声がかかり渡航費などもサポートして、実際に集まって話し合う場が設けられていました。

顔が分からないもの同士で開発をするのと、顔が分かってからネットに戻り開発するのとは効果が全然違うんです。日本でもデベロッパーやコミュニティのオフラインミーティングは今でもたまに行われていますしね。

──逆にNetscape時代からFirefoxの開発に引き継いだものもあるのでしょうか。

瀧田　NetscapeはWindows / Mac / Unixという3種のプラットフォームで出していました。その3種は全く違うOSですが、操作性など全て統一しようとしたんです。クロスプラットフォームに“見えるように”作っていたんですね（笑）。Firefoxもこの思想を受け継いでいます。

しかし、ここで困ったのがOSごとのローカライズなんです。例えばMacのメニューの日本語はWindowsと違う。アプリを閉じるとき、Windowsは「閉じる」で、Macは「終了」です。²

当初は「Windowsの日本語」に合わせる予定だったのですが、Macの場合、「Macの日本語」に合わせないと炎上するだろうという意見があったんです。この「閉じる」と「終了」ですごいもめたんですよ（笑）。

人によっては「どっちでもいいじゃん」と思われるかもしれませんが、その当時日本ではMacはギークのユーザーが多くこだわりがある人たちだったので、無視するわけにはいかなかったんです。だからいまだにFirefoxの日本語のUIラベルはMacとWindowsで別のものです。

Firefoxのメニューは瀧田さんの説明の通り、MacとWindowsでいまも文字が微妙に異なる。上の画像はその一例で、Macの場合「ウインドウ」の「イ」は大きく、Windowsのそれは「ィ」と小さい。

──実に面白いエピソードですね！

瀧田　日本人は本当にディテールにこだわります。100%の完成度のものを作るという、こだわりが強い傾向を感じます。だから表面上のほんの小さなバグ、いわゆるコスメティックバグも見逃さない。

ネットスケープ社の国際化部門にいたとき、日本の企業が上げてくれるバグレポートを見ると、「ウインドウの端にある句読点が少し欠けている」という細かいものが多かったんです（笑）。

ただ、そういったバグを直せるだけ直して、それでユーザーから信頼を得ていた部分もありました。こういった背景があったから、Netscapeは英語版に続いて、日本語版のシェアがかなり多かったんです。

コードに閉じないオープンソース

──Firefox 1.0のリリース前後で、環境の変化は感じましたか。

瀧田　Firefoxをやり始めてからの10年は、ものすごく変化を感じました。Netscapeがオープンソース化し、その後の失敗を経て、2003年にMozilla FoundationというNPOが設立され、Firefoxの開発主体になりましたが、ここで世の中はすごく変わったと感じています。

まず、組織として風通しがよくなり、NPOになったことで利潤追求から脱することができたんです。だからこそ、「自分たちがブラウザ開発で実現したいものはなんだ？」という本質が追求できるようになったのです。

開発の流れは、従来のものを踏襲することはありませんでした。従来のソフトウェア開発は、組織の誰かがリクワイアメント書き、それを技術者が実装する、というものです。しかし、Firefoxの開発では、リクワイアメントをユーザーの声に求めたんです。いわばユーザーとエンジニアが一緒になって製品を作るっていうスタイルです。ある種、理想的な開発スタイルですよね。

──ユーザーはどのようなブラウザを求めたのでしょうか。

瀧田　起動が速い、余計なウインドウが開かない、簡潔なメニュー、といったものです。

──非常にシンプルですね。

瀧田　その通りです。しかし、極めて本質的な要望です。技術者はついつい、「いろいろ作りたくなる」生き物ですが、こうした要望があったからこそ、シンプルで起動とレンダリングが速く、そして余計なウインドウが開かないタブブラウザとしてのFirefoxが生まれたのです。「いろいろ作りたくなる」欲求には、アドオンとして機能追加の余地を残しました。

──瀧田さんにとってオープンソースとはどのようなものでしょうか。

瀧田　コードの世界だけではなく、オープンソースに根ざす精神が大事だと感じます。いわば、利潤のためではなく、「自分が何かを人にやってあげたい」というその精神です。コードにコントリビュートするだけがオープンソースへの貢献ではないと考えています。

──何らかの開発以外にも、オープンソースは有効であると。

オフィスで使用された家具などの設計図は、いまもOPEN SOURCE FURNITUREのTumblrからダウンロード可能だ。

瀧田　そうですね。私は常々、Mozillaで経験したオープンソース理念が持つ可能性は、ソフトウェアの分野に閉じていてはもったいないと考えていて、日本独自の取り組みをこれまで数多く進めてきました。例えば、OPEN SOURCE FURNITUREというプロジェクトに取り組んだことがあって、自分たちのオフィスを設計してもらった際に、その設計図を全部公開したんです。オフィスの家具や机の作り方、使ってる素材など全てです。

オープンソースライセンスとともに公開してるので、ヨーロッパのある家具屋さんはその設計図をもとに家具を作って売っていましたし、山口県のあるオフィスでは実際に設計が使われたそうです。

また、Fabbleというものづくりの手順と記録を共有するサービスを慶應義塾大学SFCソーシャル・ファブリケーション・ラボさんと一緒に作ったこともあります。ここでは、ものづくりの設計図が次々に投稿されていて、いわばファブリケーションのGitHubというわけです。

形にしたものを全部公開すれば、次の人はダウンロードして新しいものにどんどんフォークしていけるわけです。

──コードと同じように、フォークされた先で新たな価値が生まれるということですね。最後になりますが、今後若いエンジニアはどうオープンソースと関わっていけば良いでしょうか。

瀧田　オープンソースのプロジェクトに参加することで学べることはたくさんあります。世界中の素晴らしいエンジニアによるレビューや、自分のコードへのフィードバックを得る機会があると、成長につながります。現に、 Firefoxの国際化のマネージャーはC言語未経験という状態からOSSへのコードの貢献を始め、10年以上経った今ではコードレビューを行うスーパーレビュアーの立場にまで成長しました。

また、オープンソースの世界は、プログラマーだけでなく、ドキュメントの翻訳やテスターといった形での貢献も可能です。さらに、先ほどお伝えしたようにデザインやものづくりの世界にオープンソースの理念を活用するといったこともできると思います。オープンソースは多くの人にとって、いい意味で踏み台になるはずです。成長のために積極的に活用していくと良いのではないでしょうか。

取材：megaya　{$image_11}megayaのブログ