2002年11月号掲載よしだともこのルート訪問記第73回

2002年11月号掲載よしだともこのルート訪問記

第73回 UNIXにどっぷりはまった経験を新たな展開へ
～藤田昭人さん～

今回は、2002年の年明けより会社員から独立して活動されている藤田昭人（ふじたあきと）さんの横浜市のオフィスを訪ねました。ここ20年近く、UNIXの世界にどっぷりはまってこられた藤田さんから、現在の活動や体験談を中心にお話を伺いました。

藤田昭人さん
筆者のUNIXの師（いわゆる「よしだともこブレイン」）の1人ともいえる人物

■普段の作業環境は？

よしだ（以下Y）：お久しぶりです。このたびは訪問をお受けいただきありがとうございます。まずは、藤田さん自身の背景を、UNIXとのかかわりを中心に紹介してくださいませんか。

藤田さん（以下F）：僕のコンピュータに関するキャリアは、1984年に独立系ソフトウェアハウスに就職してはじまりましたが、その当時、UNIXはコンピュータサイエンスの分野での先進技術の1つでしたので、自然とファンになりました。1990年にオムロンに移ってワークステーション開発に携わるようになりましたので、以降しばらくはUNIXが「飯のタネ」でした。エンジニアとしてUNIXカーネルが専門分野になりましたので、どっぷりはまる状態が続きました。
　現在はというと、20代からハマり込んでしまっているので、いまさらUNIXから抜け出せないというのが正直なところです。

Y：藤田さんのオフィスのネットワークを紹介していただけますか？

F：ハブが1つだけで、ネットワークといえるほどのものはありませんが……。

Y：外部との線は、ADSLですね。

F：はい。イー・アクセス/BIGLOBEのADSL（8Mbps）に加入しています。ADSLルーター経由でPCを何台かぶら下げて使っています。ADSLというと実際の通信速度を気にされる方が多いようですが、僕はあまり気にしていません。かつて64Kbpsの回線でFTPなどを利用していたからでしょうか。正直1.5Mbpsもでれば十分だと思っています。

Y：ADSLルーターにぶら下がっているPCの設定を、簡単に教えてください。

F：いまはADSLルーターが全部やってくれるので、ほとんどデフォルトの設定のままです。ADSLルーターはイー・アクセスから購入しましたが、8Mbpsで申し込んだのでTE4121C注1がきました。このルーターもWebインタフェースが備わっているので、普通のWebブラウザで設定ができます。ルーター側はデフォルトのNATルーターモードをそのまま使っていて、アカウント情報以外はデフォルトのままです。
　PC側はというと、基本的にプライベートネットワークでの設定をすればOKでした。デフォルトルートはADSLルーターに向けています。DNSサーバーはBIGLOBEのネームサーバーのアドレスをそのまま設定しました。メーラーにはEmacs＋Mewを使っていますが、POP/
SMTPのサーバーもBIGLOBEのものをそのまま使っています。要はプロバイダが提供するサービスにそのままぶら下がっている格好です。
　唯一の例外は、ルーターの下でApacheを動かしていることです。といっても外部に公開しているわけではなくて、ホームページの作成・デバッグのときにHTTP経由でコンテンツを確認するためだけに動かしています。デバッグが終われば、FTPで所定のWebサーバーにコンテンツをコピーしています。

■エンジニアであり続けるということ

Y：独立された理由と、独立後のお仕事、将来構想について教えていただけますか。

F：独立はいろんな背景があって決心したことですので、いろんな説明ができるのですが、エンジニアとしての観点でいえば「今後もエンジニアを続けますか？　マネージャに転身しますか？」という選択において「エンジニアを続ける」を選択したといえます。これは中年プログラマのだれもが選択を迫られるテーマだと思います。実際、この5年でプログラミングの能力はかなり低下したように実感していますが、その理由は単に年をとったということだけではなく、プログラムを書くことが減ったのが一番大きな原因です。ソフトウェア開発の現場でもそれなりに年をとると、当人の望む、望まないにかかわらず、プログラミング以外の仕事が増えてきます。顧客折衝であるとか、社内折衝であるとか、とにかく人間を相手にする機会が圧倒的に増えてきて、相対的にコンピュータやプログラムを相手にする時間が減ってきます。それに部下ができるとやっぱり面倒なことは人任せにしてしまうので、結果的に「どんどんバカになっていた」といまは思っています。若いころには「年をとれば現場から離れるのは自然なことだ」と考えていたのですが、最近の社会的な状況を目にしてくると「それじゃマズいんじゃない？」と思いはじめたもので、とりあえず一般的な他者に対しての個人的なアドバンテージである、「プログラミング能力」を手放すのはやめることにしました。
　独立後の仕事は、いまのところフリーランスのプログラマです。将来構想ですが、個人的に教育関連に興味を持っていまして、これまで培ったコンピュータに関する知識・経験をこの分野に生かせないかと考えています。かつて（いまも）BSDオタクだったこともあって、オープンソース的なアプローチが好きでして、最終的には非営利団体の設立と運営という形で成果を結実したいと思っています。

■クレイアニメーション作りをLinux上で

Y：教育関連のソフトウェアに興味を持っておられるということですが、きっかけは？

F：フリーランスになって家族と過ごす時間が増えたというのが一番大きな理由なんですが、とくに今年から小学校も完全週休2日制になりましたので、まとまった時間を有益なものにするために、「僕が2人の息子に教えてあげられることとは何だろうか？」と考えはじめたのがきっかけですね。思いついたことを書き留めておくために、ホームページ「子供たちとの土曜日の過ごし方」注2を作りました。で、ホームページに書き留めておいたことをそのつど息子たちと一緒に実験しています。とりあえず一番面白そうだった「クレイアニメーションを作る」注3の実験が息子たちに好評で自分も面白くなったので、いまはそればっかりやっていますけども……。

Y：（できあがった作品と、Linux上での作成手順のデモを見ながら）こんなのが気楽に作れると楽しいですね。しかも、すべての過程をLinux上でというのがいいですね。

F：実験の内容や結果はできるだけホームページに書き留めるようにしていますので、興味のある方はそちらをご覧ください。
　クレイアニメーションの実験をやってみて思ったことなのですが、私自身はビデオという媒体を再評価しつつあります。家庭用のビデオカメラでホームビデオを撮影するというのはずいぶん前から一般的になっていますけれど、個人的には運動会やキャンプなどのイベントを記録するための媒体という意識が強くて、これまではあまり魅力を感じなかったのです。実際、撮りためたビデオテープや写真の整理は大変ですし、そういった整理をマメにやらないとあとで見ることもなかなかなくて、単にたんすならぬ物置の肥やしになるだけでした。
　ところが最近、アニメーションのように「映像を制作する」という意識で臨むとまったく違ったものになるような気がしてきました。手がけたばかりなのでうまく説明できないのですが、「最終的に映像としてまとめる」ことを前提に置くと、家族でのレクリエーションも目的がはっきりしてきてプラスに働くように思えます。たとえば、息子たちをハイキングに連れていっても、ただ歩くだけではすぐにイヤになってしまうことが多いのですが、彼らとしての目的がはっきりしていれば、もっと積極的に行動するようになります。映像制作というのは子どもにとって非常に分かりやすい目的になるように思います。これもビデオ機器がデジタル化され、比較的低価格のパソコンでも映像の編集が可能になった恩恵ってことですね。

Y：子どもが小さい時期というのは、親子が一緒に過ごせる時間が長いので、両方が楽しめる共通のネタがあればすてきですね。親子で一緒に制作した作品を数年後に見て、懐かしい気持ちでいっぱいになるのは、親のほうなのでしょうけど。

F：これまで親が子どもに対して行うべき教育とは「しつけ」とか精神面にかかわるテーマだと私も理解していたのですが、このところ「ほかにも教えられることはあるんじゃないか？」と考えるようになりました。
　私のホームページにある項目を見直してみると、クレイアニメーションだけでなく「何かを作る」テーマが多いです。それを意識してアイデアを考えているわけではないのですが、やはり工学系の私にとって「何かを作ること」を魅力的に感じているのだろうなぁと思います。これは私だけに限らず何かの製作（制作）に携わっている方々、たとえば職人の方や、デザイナー、あるいはコックなどの方に共通する感覚なんじゃないでしょうか？
　これが私の「子どもに教えられること」なんだろうなと思います。また、たとえば営業の方が同じような視点で「子どもに教えられること」を考えられたらどんなアイデアがでてくるか、ぜひ伺ってみたいとも思います。すべての方が自分の好きなことを職業にされているわけではないでしょうが、自分の言葉で明確に説明しなければならないとすれば、それはやはり日々経験を積み重ねているご自身の職業にかかわることになるのだろうと思います。もちろんそれは「教えられること」ですが、同時に「子どもに少しでも理解してほしい」ことでもあり、それが「親が子どもに教えられること」の本質のように思います。こういったいろんな方の「教えられること」を集められるとよいなと考えています。

■アメリカの大学での偉大なソフトウェア誕生の舞台裏

Y：10年ほど前になりますが、藤田さんは、オムロン株式会社がCMU（カーネギーメロン大学）にLUNA-88K注4を寄贈した当時、CMUに駐在しておられましたよね。

F：はい。1990年6月から1993年10月まで、オムロンの社員としてCMUに駐在しました。CMUでの肩書は、「Visiting Engineer」でした。

Y：CMUにおけるMach開発グループの開発風景を紹介してください。

F：それまでの想像に反して「あまり民主的でない」印象でした。開発系の研究プロジェクトは、ディレクタにより程度の差はあれ「プログラマのお尻をたたく」状況になるそうです。CMU Machの場合は「Releasing Manager」としてMary Thompsonというおばさんがいて、開発者のお尻をたたいていました。
　開発者はいわゆるオタク集団ですので技術的な問題についてのみ「ああだの、こうだの」といっている。その点では日本とそれほど変わらないのですが、口で自分の意見を述べているのと同じくらいのスピードでソースコードを書けるのが決定的な違いですね。彼らにとってコードを書くことは、呼吸をするのと同じように感じました。
　しかし、そういう爆発的な実装能力があっても、それは個人の関心というベクトルでドライブされるので、プロジェクト全体としては非常に散漫になってしまう。そこで開発者をプロジェクトのゴールに向けさせる必要があります。CMU Machの場合は、Maryが開発者一人一人のところへ行って、その時点での成果をCVSにチェックインさせていました。そうしてたまったものを、リリース・エンジニアリングとしてテープに焼いて、これこれの機能が追加されたものをリリースしましたというアナウンスを書くといったコーディネートをするのが、Maryの仕事だったわけです。

Y：そういうのが得意なのは、女性のような気がする……。

F：はっきり相手の意見を聞いて、お尻をたたいて回れる人じゃないと、あの仕事はできませんね。研究プロジェクトというのは、原則としてディレクタが立ち上げるのですが、その運営費は大学からでるわけではないようです。CMUの場合はNASAやDARPA注5からの研究の委託を受けて運営費を賄う例が多かったように思います。プロジェクトを継続するためには、こういったスポンサーに研究委託を継続してもらう必要があるので、成果に対するスポンサーの評価は大変重要です。Machのように成果が一般に公開されるケースでは、成果の第三者的評価、たとえばほかの研究者や事業化の対象として検討してくれる企業での評価というのもスポンサーの評価のファクターとして大きいようです。
　そういう状況があるので、Project Reader（Machの場合は、Rick Rashid氏）は、スポンサーや第三者など、プロジェクト外の人々の相手で大変多忙です。当然、次のリリース時期など対外的にコミットしなければならない状況もでてきます。こういった「対外的な約束を守れるか？」において、Releasing Managerの役割は大変重要で、実際にそういったポジションにいる人はディレクタから個人的に十分信任されている常識人という印象でした。
　女性に適しているかどうかは分かりませんが、少なくともMachではMaryがプロジェクトのおふくろさん的存在であったように思います。それもかなり厳しい……。開発者のヘソを曲げさせず、予定どおり開発を進め、対外的にも収まりよくまとめていくというのは、結局は、ヒューマン・ファクターなんですよね。

Y：なるほど。「偉大なソフトウェアの誕生の陰には、名仕切り屋あり」ということですね。

F：「プログラムを書く」ことと「プロジェクトを運営する」ことは別の次元の問題ってことなんでしょうね。リリース・エンジニアリング注6の概念がみんなに理解されていることにも、注目しました。

Y：藤田さん自身はMachとどのようにかかわっていたのでしょうか？

F：僕がMachの何にかかわったかというと、実は開発にはまったくかかわっていませんでした。英語で議論ができなかったので。では何をやっていたかというと、Distribution Coordinatorです。CMUは早い時期からインターネットによるソースコード配布を手がけていましたが、日本と米国の接続はハワイ経由の64Kbps回線1本。にもかかわらずMachが有名になるにつれて日本からのソースコード配布の要望が増えてしまって、Maryの頭痛のタネになっていました。「日本人の問題は日本人が解決しろ」というわけではないのですが、日本国内にサテライトサーバーを設置・管理する仕事を仰せつかったわけです。仕事自体はあまり楽しいものではなかったのですが、Machのソースコードを好きなときに見られたので、それはそれで満足していました。ちなみにその当時配布に使っていたのが、CMUで開発されたSUPというコマンド、現在のCVSupのSUP部分だけという代物でした。機能的にはFTP Mirrorとかとあまり変わらないのですが、いかんせん64Kbps回線での転送だったので、とにかく時間がかかる。土曜日の夜10時に学校のマシンルームでいつ終わるか分からない転送をボーっと待っているという忌まわしい思い出です。

Y：Machのプロジェクト自体はそのころ終わってしまいましたよね？

F：Mach Projectは1985～1994年までの約9年間存続していたようですが注7、これはDARPAとの契約でプロジェクトを潰せなかったからです。実質的にはProject ReaderのRich Rashid氏がマイクロソフトに移った1991年にCMUでの開発は事実上終了したと思います。僕は1990～1993年までCMUにいましたので、ちょうどプロジェクトが解体していくところに立ち会った形です。Rich Rashid氏の移籍をきっかけに、主要メンバーはCMUから離れておおむね4つの組織へ移籍しました。まずRich Rashid氏と一緒にマイクロソフトに移った人。たとえばMach IPCをやっていたRich Draves氏とか。彼らはカイロ（Cairo）プロジェクト注8を立ち上げました。
　それからOSF（現在のThe Open Group）へ移った人。たとえばUNIX ServerをやっていたRandy Dean氏とかです。もともとCMUはOSFとの関係は近かったと思います。1990年に卒業したDavid Black氏がOSFに就職していましたし。
　AppleのDarwin（Mac OS X）へと続くNeXTへ移った人は、結局Avie Tevanian氏一人だったと思います。というのも彼の移籍のからみでCMUとNeXTの関係は非常に悪くなったからです。CMUのお偉いさんにいわせると「スティーブジョブスというのはとんでもない男で、共同で開発を進めましょうといっておきながら、大量のNeXT CUBEを（寄贈せずに）売りつけた挙げ句、断りもなく最も有望な学生（Avie）を引っ込ぬいていった」とおカンムリでした。Darwinの開発はAppleとOSFが主要メンバーでして、学生時代に同じプロジェクトだったメンバーが10年たって再び一緒に組んで開発を手掛けるという意味もあるのかな？　と思ったりしています。
　あとのメンバーは、Rich Rashid氏の後任であるBrain Bershad氏が1993年にワシントン大学へ移った際一緒に移籍したはずです。

■ネットワーク管理者の今昔

Y：ネットワーク管理者の経験がある藤田さんに意見を聞きたいと思っていたのが、最近、大学の理工系研究室でも「自分たちが使うネットワークを自分たちで直そうという意識を持った学生」が、いなくなってきたことに関してです。

F：でも、それは自然なことではないでしょうか？　善しあしはともかく。インターネットブームのおかげでIPネットワークは爆発的に普及していますし、いまの若い世代にはコンピュータネットワークがgivenなものと見えても仕方がないと思います。むしろ僕らの経験が特別だったのかもしれません。
　1980年代の前半はイーサネット自体がニューテクノロジでしたし、その当時学生だった人たちがそのとき「ぜひ使ってみたい」と思うのも自然なことだったと思います。同世代の人たちの多くがIPネットワークにかかわる研究・開発に携わっておられますが、その出発点は単に「使ってみたい」だったと思います。いまやイーサネットやIPネットワークも空気のような存在になっていますし、だとすればいまの学生諸君がかつての僕たちのような関心を注がなくても、それはちっとも不思議なことではないと思います。
　結果として学内のネットワーク環境は人任せになってしまうのは仕方がないところもあるんじゃないでしょうかねぇ。それに業者提案のネットワークでも、以前に比べればズーっとマシになったと思います。もちろん「ネットワークを正しく、あるいは賢く使えているか？」という議論はあるでしょうが……。
　研究としての関心がある方以外は「まぁ、いいや」ってことはありませんか？　業者設計のネットワークだって大筋ではそんなにおかしくないように思いますし……。

Y：業者の設計に、気になる部分があったとしても、それに目をつむれればいいわけですね。

F：僕個人はそう思っています。どうしても気になるところには多少手をだすでしょうが、たとえLANだとしても、ネットワークそのものを全面的に手がけることは避けたいです。というのも、ネットワークの維持ほど手がかかる作業はないと思っているからです。これはかつての自分自身の経験、あるいは同僚の経験から感じることですが、ネットワークというものは、本質的に横方向（規模）にも縦方向（技術レベル）にも無制限に拡大していく性質があって、ネットワークの運用業務を特定の個人が担うと破綻するのは時間の問題であり、そのことが最初から分かっている仕事だと考えています。学校でも会社でも、ライフラインと呼ぶべきインフラの維持・運営について、特定の個人の実名を持ち出さないと説明できないとすると、そのこと自体がそもそも問題だと思います。ですから、維持・運営に関する責任は個人でない存在が負うべきで、もしお金で解決できる状況なら、それ専門の業者に委託するのは賢明な選択だと思います。当然、費用対効果の必然から、構築されるネットワークの規模や技術レベルには妥協せざるを得ないですね。

Y：技術的には不満があったとしても、任せられる業者があるというのが、昔よりもよいということなんですね。

F：僕自身はそう思っています。1980年代当時は「ネットワーク運用」が仕事と見なされなかったですし、そういう仕事を引き受けてくれる業者というのも存在しませんでした。いまはそういう選択肢も用意されているという意味では「まだマシな」姿だと思います。もちろん理想的な状態にはほど遠いですが……。
　最初の質問に戻りますが、「研究室内のネットワークですら学生は関心を持たなくなっている」という指摘の背景には、ネットワークの運用業務が持つ学習効果を重視する考え方もあると思います。この点について僕はまったく異論はありません。事実、僕自身も運用業務の経験から多くの学習をしました。しかし、現実を考えると、いまの学生諸君にそのまま当てはめるのは無理があるように思います。学習機会を期待するなら、何かほかの方法を考えたほうがよいのではないでしょうか？　いい換えれば、こういった問題が顕在化するほど、「コンピュータネットワーク」は成功し、普及したということでしょうね。

Y：なるほど。とても参考になるお話をありがとうございました。ルート訪問記の再出発にふさわしい内容の取材になったことを感謝しています。また、今回の取材では、藤田さんの奥様の美奈さんにもお世話になり、ありがとうございました。

クレイアニメの製作現場の図

注1住友電気工業（住友電工ネットワークス） MegaBit Gear TE4121C
http://www.megabitgear.com/

注2子供たちとの土曜日の過ごし方
http://roguelife.org/~fujita/COOKIES/

注3クレイアニメーションの作り方
http://roguelife.org/~fujita/COOKIES/CRAY/

注4LUNA-88K
1990年当時、オムロンから販売されていたワークステーション。OSにはCMUの開発したMachを搭載、CPUはRISCチップ（MC88100）を最大4個増設可能で注目を集めた。Machは、4.3BSDをベースに作られたUNIX互換OS。

注5DARPA（Defense Advanced Research Project Agency）。
1958年に設立された米国国防総省の中央研究開発機関。基礎および応用研究開発プロジェクトを管理・監督している。
http://www.darpa.mil/

注6リリース・エンジニアリング
共立出版『bit』1990年9月号「4.3BSDのリリース・エンジニアリング（原題：M.K.McKusick, M.J.Karels,K.Bostic,"The Release Engineering of 4.3BSD"）」において、小人数のグループが巨大なソフトウェアシステムを開発、統合する際に用いる手法として紹介されている。

注7CMUの公式ホームページに記載がある。
http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html

注8カイロプロジェクト
Windows2000開発プロジェクトの前身。思想的には.NETに繋がる分散オブジェクト技術の開発プロジェクトで、Windows95/NT 4.0のGUI、DCOM、Active Directoryなどが成果物といわれる。

私のUNIX #1 ～藤田昭人さんのUNIX～

●OS環境：Red Hat Linux

BSDシンパだったので長年OpenBSDを使っていましたが、ドライバやプラグインのサポート状況のよさから、いまはRed Hat Linuxを使っています（現在は7.2/7.3併用）。映像に関心が移っているのでマルチメディア系のドライバは不可欠なんですが、*BSDだと自分でどうにかしなければならないことが多いので、面倒くさくなって使わなくなりました。

●シェル：tcsh

ラインエディテングができるcsh系シェルのため。コマンドラインでforeachを多用するので、Bシェル系だとイライラが募ってしまいます。実際、1988年当時からずーっとこれで、あまり不足を感じないのでbashもzshも無視しました。

●シェルの設定：デフォルトまま

よけいなエイリアスを使わないのがこだわり。たとえばRed Hat Linuxだと、デフォルトでlsが「ls --color=tty」にエイリアスされますが、こういうのは.cshrcで全部カットしています。rmが「rm -i」にエイリアスされているのも嫌いなので、普段使うときは「/bin/rm」とタイプする癖がついています。このようになった背景には、独立系ソフトウェアハウス育ちのためかヨソさまの環境での作業が多いので、「時間のかかる環境設定をしないとまともに作業ができないようでは困る」と指導されたこともあるのでしょう。viもemacsもデフォルトのキーバインドのままで、行ったり来たりできる妙技が身についています。

Last modified: Mon May 21 13:53:38 JST 2007 by Tomoko Yoshida