これまでの観測によると, 北大構成員の大半は HINES という偉大なインター ネットサービスプロバイダのもと善良なる利用者をやっておればそれで良い, という幸せな状況にあるようなのだ. 北大キャンパスネットワークの管理運用 側, 特に, 接続等に関係する末端の状況 (単なる事務的手順ではなくて) をそ れなり知っている御近所の人が非常に少ない. しかるに, 筆者らの他大学での 経験では, 善良なる利用者をやっておればそれで良いなんていう幸せな状況が 国立大学で得られるわけは無いはずなのだ. だから, きっとどっかが変なはず だと思っていたりするわけであり, 実際このような文章を書くことになってい たりもするわけでもある.
拠点大学と言えども, 私学とは違って総定員が決まっているので, 全学をサポー トするネットワーク担当研究者・ネットワーク担当職員の数はたかだか数名で あるはずだ. しかもその多くはさまざまな通常行政実務(予算要求・執行, そ の他庶務事項)に追われていたりするので, 現場をケアできる実働人員はほん とに数える程であったりする. よほど学内的に意識が高く流用定員をたくさん 認めているのでなければ, 末端までのプロバイダ的サービスを行なうだけの要 員確保は不可能であるはずなのだ. 維持管理等の実務作業を外注化して実定員 を稼ごうとしても, 外注先企業側の優秀な技術者を確保するのは外注担当者が よほど厳しくケアをしていなければ難しく, かつ, コストもかかる. 外注した はずなのに外注仕事の管理にかえって手間がかかって数少ない有効実働定員が 減ってしまう, なんてこともよく聞く話である. そもそもこのインターネット 爆発時代, あらゆる業界でネットワーク技術者は取り合いであり, 大学(に限 らず官公庁)の運用当局が機敏に立ち回ってその競争に勝ち残り, 当該企業の 優秀な技術者を現場担当者として回してもらうのは極めて困難である. そもそ も世間との競争に勝って, 常勤スタッフ陣に優秀な研究者・技術者を確保する こと自体が困難であるのが各地での現実であるはずなのだ. しかるに, 構成員 が何も知らない利用者に徹しているような大学ではネットワーク運営の裏方に 必要なコストは理解されにくいから, 流用定員など人的措置や諸々の予算的措 置がされにくいのが普通であり, まして, 企業から優秀な技術者を引っ張って 来るような難しいことはやりにくい. そのような状況下で無理に良いサービス (利用者を甘やかす?ようなサービス)を提供すると, 人々はそれらを空気のよ うに当り前に思うので, ますます日々のコスト支援が得られにくくなるという 悪循環に陥る.
ネットワークをはじめとする計算情報環境の維持管理運営に対する, 筆者らの 偏見はかくの如きものである. ところが驚いたことに北大では, HINES はキャ ンパスネットワークの基幹的な IP (Internet Protocol) レベルでの接続性を 確保, 維持管理更新してくれるだけの組織の名称ではなかった. たとえば, 理 学研究科の建物内部の末端の HUB まで HINES が展開してくれている (HINES から降って来る?). 理学研究科では自前で DNS (Domein Name Service, IP ア ドレスとホスト名やドメイン名を対応づけるサーバー) を上げなくて良いし, したがってインターネット上での IP アドレスの実質的管理もしなくて良 い. POP サービスもあるから自前でメールサーバーを上げなくてもよい. 情報 メディア教育研究総合センターのような全学サービス組織とは別途に, それと 同様のアプリケーション層のサービスまでやっているのだからたいしたものだ. HINES は全学的に展開されている計算情報環境の総称名称であったわけである.
ほとんど余計なお世話なのかも知れないが, このようなアプリケーションレベ ルにまで及ぶ総合インターネットサービスプロバイダのようなサービスを, 小 人数のスタッフと限られた予算しかないはずなのに, いったいぜんたいどうやっ ているのだろうか, このままやっていって大丈夫なのかしら, という不安にと らわれているのが筆者らなのである. 筆者らが知っていたキャンパスネットワー ク (東大の UTnet や京大の kuins) は, TCP/IP レベルでの接続を建物の入口 (ルーター) まで確保してくれるだけであった. そこから先の建物の中の配線 や IP アドレスの管理, サブドメイン名やホスト名の管理は各部局/学科等の 責務であった. そのかわりルーターの設定は各部局/学科の要請に応じてわり と細かく対応してくれていた. MIT やスタンフォード大学でもそうであった (1994 年の状況は知っているが, 今の状況は確認してない). 責任分担は非常 に明解, かつ, 排他的ではなく階層協力的であって, しかも, それでもなお全 学のネットワーク運営当局の負荷は大変なものであると聞いている. スタン フォード大学では 1994 年当時で全学のネットワーク運営スタッフの数が 25 人程度であったし, アプリケーションレベルの維持管理にも別途 25 人程がお り, さらに, さまざまなレベルでの院生アルバイトが膨大な数活躍してい た. 東大ではこの 4 月から全学の情報サービス関係組織が統合され, 従来の 大型計算機センター, 教育用計算機センター, そして, 図書館の一部が合体し て, 情報基盤センターというものに代わった (http://www.itc.u-tokyo.ac.jp/). 構成はわかりやすい 4 部門に再編され, キャンパスネットワーク(UTnet)の基 幹を統括するキャンパスネットワーキング部門, 伝統的な大型計算機の末裔を サービスするスーパーコンピューティング部門, 全学の全ての構成員(学部生・ 院生は全員交付)にアプリケーション環境を提供する情報メディア部門, そし て, コンテンツが関係する図書館電子化部門からなる. そのような統合が進ん でいるところならまだしも, 北大の場合は情報メディア教育研究総合センター は学部学生のアプリケーション環境の面倒を見てくれるだけであり, 関係サー ビス組織のパワーは分散されたままである. 良い意味での競争が行なわれるの であれば文字通り良いのだが, 大学の少ない定員でやりくりしなければならな いのだから, 学内で競争している余裕は本来ないのではなかろうか. 聞くとこ ろによると文部省の学術国際局と高等教育局の縦割の反映であるとの説もある らしいのだが, お上の方の詳細は私は良く知らない. 現在の日本の行政組織 では大学と大学院, 教育と研究には管轄局がわかれているのだそうだ. その通 りの分割に真面目にしたがっていると北大等で実現しているような形になって しまう.
それはさておき, 結局現場レベルにおいて, 北大ではどのようにしてつじつま があっているかと言うと, HINES の想定する標準的利用者からはみ出した活動 を行なおうとする者は圧倒的な不利益を被る, ということになっているような のである. 責任分担の切り分けは明瞭ではあるが, 排他的であって協力的では ない. 末端利用者に対して親和的であるが, サブネット管理者にとって親和的 ではない. 一旦サブネットを立ち上げると完全なる自立を要請されるようであ る. HINES の枠からはみ出たとたんに概算要求から日常運営までの一切のサポー トが打ち切られるようなのである. 今時あたり前な DHCP サーバー (Dynamic Host Configuration Protocol, IP アドレスを自動割り付けするためのサービ ス, 学生や客人がノートPC を持って来るのは今や当り前でありそれらを IP 接続するためには, いちいち IP アドレス申請しているわけにはいかず, した がって, 必須なサービスである)を上げようとするとサブネット化を要請され る. 速度の早い接続を維持しようとすればルーター(あるいは第 3 層スイッチ) という高価なネットワーク接続装置を自前で持って来なければならな い. HINES のノード装置の設定をきめ細かく対応してもらえばいい(必要なら 現場が拡張ボード等を購入, 維持管理更新をお願いする)だけのはずなのだが それは HINES の想定を越えるので難しい(確かに手間だ).
北大キャンパスネットワークは, そのあらゆる階層やあらゆる物理的領域が HINES 実務運営担当組織の直轄的責任領域として維持管理されているし, 管理 せざるをえないようになっている. 意識はあるが技術レベルがそこそこなグ ループや組織がネットワーク管理な活動を展開し技術を磨いて行くことを支援 する体制(全学のボランティアグループでいいと思うのだが)が無い. 自前で立 ち上がるためのハードルが非常に高く設定されている. 予算的技術的に完全に 独立できなければならないが, それは通常不可能である. 現場(部局なり学科 なり研究室なり個々人なり)の自主的努力・実験はあまり歓迎しない, と言っ ているのとおなじことになっている. 自立的なグループが存在しないので, 結 局, 一元管理する世界に全体が収縮してしまわざるをえない. 協力的に分散 管理されている世界では, それぞれの責任において自立することを奨励し, し たがって, それぞれの責任の範囲において活動の自由度が確保できるし, いろ いろなレベルでの運営情報交換が可能であるが, 一元管理する世界ではそのよ うな自由度は存在しないし必要もない.
自立的な北大構成員数が非常に少なく, 圧倒的多数が HINES に完全に依存的 に生活している現状では, キャンパスネットワークに対する責任分担意識, 当 事者意識, インターネット的な危機管理意識が非常に低いのは当然である. かくして, たとえば, メールサーバーを上げておきながら SPAM (= UCE, Unsolicited Commercial Email, なぜ SPAM と言うかは http://www.cybernothing.org/faqs/net-abuse-faq.html 参照) 対策もで きないという状況が野放しにされていて, やっているほうも周囲も恥ずかしく もないらしい.
そのような問題はさておき, 筆者らの関係者は上記両項目に引っかかるメール交 信を, 多くは無かったけど, 行なっていたので「障害」が発生し, どうやらそ ういう措置がなされたのではないかと結論するに至ったわけである.
昨今は, 行政当局事務方も平気で(?)巨大な添付ファイルを付けて送ってくれ るので便利になったんだか, ディスクがすぐにいっぱいになって困ったもんだ か, とにかく 1MB 上限では届かない. 論文のレビューもしかりで巨大なファ イル(絵だの表だのたくさんはいっている何十MBものやつ)をこれまた平気でメー ルで送ってくる御時勢になった. 古くからの Unix 使い, メールサーバーがバ ケツリレー的にメールを送っていた時代を知る「古老」(この世界では 5 年前 はほとんど明治維新ぐらい遠い過去であるようだ)には驚異的なサイズのメー ルを昨今の Windows/Mac 使いは全く平気で送る. 動画も入っているし, そも そもファイルの大きさなんてまったく気にしてない. このような御時勢にどう して 1MB の上限なんてのがついてしまったのかはまったく理解に苦しむ. す くなくとも実用上支障を来すであろう設定であることは明白である.
メールサイズ問題については, 同様なトラブルを被った人がさすがに近傍にも 少々いたのですぐに話題にはなった. しかし, 近所では誤解している人も多かっ たのには驚かされた. 少なくない人達が, メール配送の上限は最初っから 1MB だと思っていたのである (なぜだろう? HINES の POP サーバーサービスの設 定かしらん?). 配送可能なメールのサイズは送信受信に携わるメールサーバー の能力に応じて上限があるだろう. しかし, それは当該サーバーたちの運用管 理の問題であって途中の TCP/IP な通行路(通行路としてのインターネット)の 管理の問題ではない. 昨今のメール配送システムは宛先のサーバー名を DNS に問い合わせて IP アドレスを取得するや, あとは, 直接当該 IP アドレスのサーバーにメールを投げるだけだからである. ftp や http で巨大なファイル転送が許されているのにメールで許されない理由は TCP/IP レベルでの経路管理上からは存在しない. TCP/IP なレベルでのトラ フィック上の問題(交通量が多すぎる)があるとするならば, 問題をメールに限 定すべきでもない. その場合は, 多分, http なトラフィックがもっとも大き いのではないだろうか?
別名問題は多少説明が必要かも知れない. ホスト名 hoge なるマシンが北大内 にあったとしよう. hoge の IP アドレスとドメイン名はたとえば次のような 感じであるとする.
133.87.28.1 hoge.ees.hokudai.ac.jpIP アドレスとドメイン名との対応づけをやってくれるのが DNS である. DNS システムは階層構造をなしていて, hokudai.ac.jpを管理するのが HINES の DNS サーバー, ees.hokudai.ac.jp を管理するのが HINES の DNS サーバーに 登録された地球環境科学研究科の DNS サーバーである. 地球環境科学研究科 の DNS サーバーは HINES の DNS サーバーに子どもの DNS サーバーとして認 定されていて HINES の DNS サーバから ees.hokudai.ac.jp というサブドメ イン上での IP アドレスとドメイン名との対応づけを行なうことを任されてい る.
一方, hoge というマシンは全く別の名前を持つこともできる.
133.87.28.1 hoge.gakkai.or.jpgakkai.or.jp というドメインを統括する DNS サーバーは, 北大の内にあるか 外にあるかとはまったく関係なく, 上部の or.jp を管理する組織の DNS サー バーに認定されれば別途立ち上げることができる. その gakkai.or.jp という サブドメインを統括する DNS サーバ上に IP アドレスとドメイン名との上記 対応づけを記しておけば別名として機能することになるのである. IP アドレ ス 133.87.28.1 は北大の持ちものであるので, 勝手に本名にすることはでき ない. しかし, 133.87.28.1 は本名が hoge.ees.hokudai.ac.jp, 別名(の一 つ)が hogehoge.gakkai.or.jp とすることはたやすい.
このような別名を持つことのご利益は, さまざまな形態での横断的な組織によ る活動や仮想的組織による活動の支援にある. 産官学の, あるいは, それ以 外の諸々の組織間/個々人による共同研究/活動が増えて来ている. インターネッ トがポピュラーになったおかげでドメイン名は組織の顔(アイデンティティー, CI)になってしまった. そのような組織横断的な個々人あるいは複数組織の集 合活動では特定の組織に依存するドメイン名を出したくない. 当該活動固有の ドメイン名が欲しくなる. http サーバーからの情報取得のほうがポピュラー になると仮想組織の存在にとって固有ドメイン名を持つことはむしろ優先され るべき問題となる.
あるいは, 昨今のように時限的流動的な組織が増えてくると, 予算的裏付けが あるが時限的にしか存在しないような組織に依存したネットワークドメイン名 を持っているのではかえって不便である. 研究活動は組織の消長とはかかわり 無く場所を変えて続けられることが多いからである. 同様に, 人も流動的になっ て来ているので, 所属がかわれば変更しなければならないような所属組織固有 のアドレスを用いたくはない. 多くの大学人のような, 本来, 個人的内在的欲 求に端を発して行なう研究活動の従事する者たちは, 自分がどこの組織に属し ていようがその研究活動は自分の筋にしたがって継続していきたいものである. 情報発信を http サーバーという形で行なうようになると, 発信元のアドレス は変えたくはないし, 連絡先のメールアドレスも変えたくはないのである.
別名をもつことにより, とある組織横断的活動の情報発信サーバーはその物理 的実体がどの実体組織に設置されているものであれ, たとえば,
http://www.gakkai.or.jp/という不変なアドレスを持つ仮想装置としてインターネット上で参照すること が可能となる. 当該活動グループの情報発信担当者の所属組織が代わり, サー バーのおき場所が代わっても, 当該 DNS 上の情報さえきちんと書き直してお けば, 不変な参照の仕方ができるわけである. 同様にして
tantou@hogehoge.gakkai.or.jpというメールアドレスでもって, 担当者のメールアドレスを不変に保つことが できる. しかるに, 現在の HINES の措置により
tantou@hogehoge.hokudai.ac.jpへはメールが送れるものの, 別名を使った不変な送り方
tantou@hogehoge.gakkai.or.jpは, 当該資源の実体が北大内のそれである限り, 不可能になってしまった (申 請すれば認められるらしい).
現在 HINES がとっているファイアーウォール的な措置(SMTP 検閲)は, 企業内 部のいわゆるイントラネットというわれる世界に対しては当り前のものである. だからこそ, 逆に, 大学のようなオープンな空間の「売り」とそれに対する期 待があるわけだ. 拠点大学というものが, 諸々の教育研究活動を支援して行く ものであるとするのならば, このような, 組織横断的な活動や流動的な活動も 支援できるようであってもらいたいと思う. すでにエスタブリッシュし財源も 豊富になってしまった活動ならばわざわざ学内にサーバーをおかずとも民間サー ビスプロバイダが提供する諸サービスを利用すれば良いのかも知れない. しか し, さまざまな萌芽的研究教育活動に対してもそのような排他的措置を要求す るというの酷である. 逆に, そのような活動にネットワーク空間上での場を提 供する, ということが拠点大学といわれる空間の持つ大きな仕事の一つである のではなかろうか. まして, 公的な計算機センター等の資源を有機的に活用す るような仮想(ネットワーク上に展開する)研究教育活動に関しては民間サービ スプロバイダに全部を依存することは原理的に不可能である.
広報チャネルとしては hu-admin というメーリングリストがあるそうなのだが, その位置づけがよくわからない. これは HINES の広報チャネルとしてのメー リングリストなのか, それとも, 北大で計算機やネットワーク管理にたずさわ る諸々の人達のための情報交換のためなのか. ちなみに筆者の一人(林)はその メーリングリストに参加させてもらう方法も分からないので(存在は近所から 聞いているが)情報を取得しようもない. 着任時に HINES 関係のどこかに hu-admin の登録をお願いするメールを書いたはずなのだが, 当時は北大内の メールアドレスを持っていなかったので自動的にジャンクとして処理されてし まっていたかも知れない. HINES スタッフの日々の業務を想像すれば不思議で はない. いずれにせよ, 緊急処置は WWW に(セキュリティーの確保の範囲内で) 広報して欲しいものであるし, 全学の諸々の計算情報環境管理者が気楽に参加 し, 情報交換できるメールリストがあって欲しいものだと思う. また, 恒久的 な措置と対応する救済措置に関してはネットワーク以外の通常の全学の諸々の 措置と同様きちんとしたオフィシャルパスで全学の構成員に通知されるべく流 れを整えてもらいたいものである(あるいは我々自身が各部局なりでなんなり でやることかしらん?) 現状では, 少なくとも新参者には, どこで誰がどうい う権限で政策判断をやっているのかが見えない. 見えないうちに次々と重要な 選択が決定されて行っているように見える. 現象的には, ほとんど hu-admin で HINES 運用担当者がサクサク決断しているようにさえ見える. これは, 緊 急対策においては保証されねばならないことであろうが, 恒久対策においては 必ずしも真であってはならないと思う.
しかしながら困ったことに, このような措置では, まっとうに SPAM 対策を行 ない, まっとうにインターネットを利用していたはずの利用者が不利益を被り, 利用はするけれども管理コストはかけない, そういう連中が(管理コストをか けないという)利益を得ることになる. モラルハザードな世界である. できる だけ低いコストで生産に集中し, その活動がネットワーク環境破壊活動になっ てしまっていることを無視するか, あるいは, 下手をすると気づかないでいる. そのような人々に対して何らのコスト負担フィードバックもかからない. 苦労 するのは HINES 運用担当者(筆者らから文句を言われる)と SPAM 対策をまと もにやっていた人々だけである(SPAM なんてわけのわからんものを勉強し, 対 策する時間だってただじゃぁない). このような措置が恒久的対策として取ら れるのはどう考えたっておかしい. 公平なコスト分担ではありえない.
ネットワーク技術の進歩著しく, 一方で, インターネットクラッカーの活躍も 著しい. 研究教育活動の片手間に計算機管理を行なっているのだから, 24 時 間破壊活動にいそしんでいるインターネットクラッカーにたちうちするのは本 来困難である. 鍵をかけていてもプロのドロボーにはたちうちはできない. だ からといって, 鍵をかけないで放置した車が盗まれて交通事故を起こされ, そ の被害者にさせられたのではたまったもんではない. 現状の北大のネットワー ク空間は無免許のドライバーが運転する車や整備不良の車, あるいは, 暴走す る盗難車が走り回っているとんでもない状況であるといえよう.
つい先頃(8 月末)も, 学内の SMTP サーバーを中継に使ったメール爆弾被害が 発生した. 同じメールが大量に送られて来て, メールスプールがあふれる. 次々 と学内中継サーバーを変更して来るのでゲシュニンがよくわからない. すくな くとも学内でいったい何が起こっていたのか関係管理者はきちんとトレースし 全学に対して報告する義務があると思う. 徹底的に経路を追跡しゲシュニン (誰の車が整備不良なのか, あるいは, プロによる巧妙な犯罪で市民には防ぎ ようがなかったのか, などなど)を突き止めてもらいたいものだ. 整備不良車 は即刻廃棄するか修理するかしてもらわないと迷惑のみならず危険このうえな い. この手の問題を追求することは自分たちの問題ではない/自分たちは計算 機管理の専門家でないから関係ない, と思っている教官や学生が多いようだが, いわば, 危険な重金属の処理方法がわからないけど自分たちは産業廃棄物処理 業者ではないし取りあえず忙しいからいいや, といって通常の下水にそのまま 廃棄していて平気でいるようなものである. 安易に問題にふたをするような解 決方法では形を変えた同様な問題が再発必至である.
SMTP 検閲は北大という組織内の欠陥車の影響が外界のインターネット社会全 体に波及しないようにするための防波堤としてしかたなく導入されたのだ, と 想像されるのだが, 要すれば, そのような防波堤が無ければインターネット社 会に対して顔向けできないような恥ずかしい状態にあるわけだ. 無免許ドライ バーや整備不良車や暴走車は一刻もはやく学内ネットワーク上から駆逐し治安 の回復につとめなけらばならないだろう. 必要なコスト(時間や手間や文字通 りお金や, あるいは, ポジション)をかけて勉強するなり専門家を処遇するな どして, 部局, 学科, 研究室, 個々人など, いろいろなレベルでそれぞれがで きる対策を至急取って行くべきである.
大学のネットワーク環境の整備が公的に行なわれるようになってから, まだた かだか 10 年程しかたっていない. TCP/IP が文部省に認知(?)されたのはもっ と最近のことであろう. N1net という大型計算機をつなぐ閉鎖的でおそろしく 値段の高い今にして思えば不思議な計算機ネットワークが 80 年代の日本では 推進されていた. TCP/IP なんてのは米国国防省がやっているあまたのいかが わしいものの一つという認識でしかなかったのだろうし, 計算機科学を専門と しない我々のような連中は聞いたこともないものであった.
日本におけるインターネットの御開祖, ネットワーク実装実験プロジェクト WIDE がスタートしたのは 1988 年 (村井純, インターネット, インターネッ ト 2, 岩波新書), 初の学術応用 (計算機科学的だけでない利用を目的とした) TCP/IP ネットワークとして太平洋を渡ったのは TISN (東京大学国際理学ネッ トワーク) である. TISN ってのは名前はかっこよいのだが出発時の実体はも のすごくお粗末であった. 当時バブル景気でライジングサンだった日本の科学 技術(の今後の方向の)情報を欲しがった米国が, 太平洋回線(ハワイ-東京間) の回線使用料の半額を出すから IP コネクションを張らないか, と言ってきた ものである. これは文字通り渡りに船(黒船?)な話であったのだが, あとの半 額が高くて払えない. 結局, 高エネルギー物理学の人達が主体となって走り回 り KDD に特価で回線をわけてもらうためのいいわけ(?)としてかなり無理して 作った母体が TISN である. 理学ネットワークといっても, まともな 10BaseT が張られていたのは高エネルギー物理, 天文・地物, 情報科学だけで, しかも, バラバラだったのでそれらとさらに周辺の研究所等々とを無理矢理電 話回線でつないで作った急ごしらえのシロモノである. ちなみに東大工学部に は TCP/IP なネットワークがスタートしていて工学部 LAN と呼ばれてい た. 要するに, 必要な人なりグループなりが雨後の竹のこのように立ち上がり つつあったのが 10 年前である.
当時のインターネット社会は使う人がすなわち作る人であった. インターネッ トなんてまだどこにもなんにもなかったわけであるから, 欲しい人が自分で作 らなければ仕方がない. これはまた「正しい」Unix の精神にのっとった発展 形態でもあった. TCP/IP の発達は国防省指揮下の開発研究過程において Unix (バークレー版) に組み込まれたことに端を発している. そもそも, 無保証で あって何が起こっても知らんよ, というのがその基本精神である. そのかわり, 自分で自分の環境を好きに構築できる, というものであった. 問題があれば 各自が対処し, 逆にそれぞれが作ってきた道具類, 対処してきたノウハウが製 造元にも提供されて結局リリースした方もされた方も利益が上がる, 全体とし てグットな環境が構築されていく, という性善説な形で発展してきた. ボラン ティア精神と自分のことは自分でやる精神, まさにアメリカな精神とでもいう べきものでできている. 現在でも, フリーウェアと呼ばれる諸々はそのような 精神で開発がすすめられており, (そのような意味で原理主義的な?) GNU 活動 は言うに及ばず, OS の Linux や WWW サーバーソフトの Apache などはその なかでも良く知られている.
インターネットのハードウェア部分に関して言えば, それを利用すれば人の作っ た経路と環境を経由してコネクションを確保するので, 逆に人のトラフィック も通してあげなければならない. まだ, インターネットプロバイダが無かった 時代である. 筆者自身, 天井裏や共同溝にもぐって同軸ケーブルや光ファイバ をひきまわしたものであり, WCRP (国際気候研究プロジェクト) などの事業費 を「運用」した光ファイバが WIDE のバックボーンの一つになった時期もあっ た. インターネットは, そのような諸々の活動によってできたネットワークセ グメントをツギハギして全世界的接続を確保してきたものなのだ. 自分たちが 作ったネットワークセグメントを全然関係ない TCP/IP パケットが通って行く のが当り前. インターネットサービスプロバイダが成立する(1992 年)以前, そして, それが活性化する以前(1994 年ぐらいまでかな?) の状況はこんな感 じであったのである.
想像するに, 北大におけるキャンパスネットワークの発達においては, このよ うな黎明期の熟成が無かったのではないだろうか? 北大のキャンパスネットワー クに予算がついたのは東大のそれよりもはやい. したがって, 現場の必要が高 まり自序努力な活動が雨後の竹の子のようにあらわれる以前に, キャンパスネッ トワークはすでにお上から与えられるものとして登場していたのではなかろう か? ネットワークへの必要性や愛着や技術やらが蓄積する時間がほとんど与え られなかたったのではないだろうか. 全学にみなぎる「使えと言うから使って やってるんだ」という雰囲気からは, そのような歴史的状況が想像される. 運 用側は(人々に頼まれもせんのに)予算取って来て(勝手に)作ったのだから当然 そのように宣伝するだろう. 利用者の数が少なかった時代には, こんなにいい ものを用意しましたので使ってください, でもまわっていたのかも知れな い. しかしインターネットが爆発した今日的状況においてはそのようなスタン スをささえきれる人的・財政的バックアップが用意できるのだろうか?
拠点国立大学のキャンパスネットワークのマンパワーは, 全学にボランティア なたくさんの活動があることを前提として, なんとかぎりぎり回るような数で しかなかった, というのが筆者らの経験による実感である. Unix と インター ネットがもともとそのような歴史をしょって発達してきたからである. 少なか らざる大学ではキャンパスネットワークは部局や学科等のレベルで分散分割管 理されているが, それは, 雨後の竹の子が竹になったのに過ぎない. と同時に, 実質的にキャンパスネットワークの運営へ人的・財政的支援を各部局や学科等 のレベルが行なっていることになる. 北大ではそのような Unix 文化な発達, 相互扶助的ボランティア的活動を飛ばして, いきなり全学ネットワークになっ ているのであろう.
我々が新参者であるせいなのか, あるいは, 所属部局や専攻の問題であるのか, とにかく, HINES 運営現場, HINES 運営に責任ある各種委員会, 各部局や学科 あるいは研究室やさらには北大構成員個々人などなどのいろいろなレベル間で の, HINES と計算情報環境の諸問題に関するコミュニケーションチャネルが不 明瞭・未確立であるような気がする. 技術的問題, 行政的問題, などなど, 新 しい問題が次々に発生して行くに違いない. いろいろなレベルでの知恵の出し 合い, 相互援助しあえるような人材の育成と環境の整備が必要なのではないだ ろうか.
しかしながら厄介なことに, 10 年ぐらいでは人的なサポートはまったく追い 付かない. 情報ネットワークは急速にあたり前のものになったので, もはや, ボランティアが相互扶助的に維持するものではなくなってしまった. 使う人が 作る人であった時代はあっと言う間に終り, ほとんど全ての人がいわゆるユー ザー, 茶碗と箸を持って待っている人が大多数になってしまった. 多くの研究 大学では大学院生レベルがその運営維持にかかわって来たのであるが, 裏方の コストは非常に大きいのにそのコストが一般利用者には全く見えない. 使う人 が作る人の時代なら「お互い様」ですんでいたことでも, 作る人と食べる人が 分化して来ると「ばかばかしくてやってられない」になってしまう. さらに, Windows や Mac のおかげで運営事務処理も計算機やネットワークで行なうよ うになって来た. そのような用途の計算機やネットワークの維持管理を当然院 生にまかせるわけにはいかない.
公的にサポートされるようになったキャンパスネットワークの運営パワーとい えども, それはこのような大衆化したインターネットを想定したものではない から, 当然, 部局/学科レベルで専任スタッフが必要となるはずである. セキュ リティー問題が難しくなってきた今日ではなおさらである. 研究室レベルのサー バー管理の主力はあいかわらず院生レベルの人達であるとしても, 難しいセキュ リティー問題などに対するコンサルタントができるスタッフが必要である. し かるに, 昨今の定員削減状況においては, 新しい仕事のための定員を確保する ことはなかなか困難であり, さらに, 先にも述べたように, たとえポストがあっ ても十分な能力の人材を持ってくることは難しい.
一方, 状況の進化があまりに速かったので, その間頑張って追従を試みた人達 でさえもその経験が次々に古くなって役に立たなくなってしまう. 教官がその 経験を学生に教える, という通常の授業形態がなかなか成り立たない. インター ネットが当り前になった結果の問題点は, 多くの人々がそれはもはや電話のよ うな枯れた技術である, と勘違いしてしまっている点にある. 昔なら Unix の 修行をそこそこつんでいないとそもそもネットワークに接続することすらでき なかったが, 今や Windows マシンをそこいらの HUB に差し込めばなんだか知 らないけれど動いちゃったりする. ネットマスクやブロードキャストアドレス も知らない無免許ドライバーの大量発生である.
筆者らは, はこのような状況に対応するべく専攻内, あるいは, 関連する有志 において, ネットワーク技術を勉強し実装訓練を行なう活動を行なってきた. 計算機実習を行なうのであるが, キャッチフレーズは自力更生である. 教官は 頼りにならないことを事実として認識し無理しない. 教官はその必要性と場を 提供するだけである. あとは TA と参加学生が主体となってほぼ自主的に運営 する. 研究室や学科レベルのサーバー管理ができるような人材をある確率で生 産し, かつ, 彼らが TA 等となって後継者の養成と, 真っ当な利用者 (要する に管理者に迷惑をかけないようにする) の養成を行なうようにするわけである. 少なくとも, 最低限の知識をもった利用者として,
このような活動を行なう本当の意味はもうちょっと先の方にある. 将来的には ひょっとすると, 全学が用意する情報環境がどんどんよくなって, 研究室レベ ルや学科レベルではシステム構築のための技術教育をする必要が無くなるのか も知れない. が, 当分そのきざしは見えない. それどころか, 情報を発信する 側に立つならば, 技術の進歩に追従できる次の世代を生産していってしかるべ きである. 要は, 情報発信を行なうのに必要となる技術, それは時代とともに かわって行くのだろうが, の習得が目的であるわけなのだ.
情報化時代と言われて久しいが, 言葉の真の意味において情報化を始めている 人達はまだ少ない. 情報化とは, いわゆる情報科学科なり情報工学科なりで進 めてくれる問題ではない. 彼らはそれのための一般的道具や哲学を作ることを 本筋の目的としている. 森羅万象を扱う諸分野において, これまで積み重ねら れて来た知見をどうインテーグレーションし, 計算機に覚え込ませ, ネットワー クで結合して行くか, という具体的な処方箋を与えてくれるわけではない. 各々の分野において各々の体系に応じた情報化のための試行錯誤を試みて行か ねばならないし, さらに, 学際的なすりあわせをやっていかなければならない. 情報化の推進のためには, とある領域に関する専門知識とそれを計算機上にイ ンテグレーションしていくための情報技術との双方において深い知識が必要と なる. 問題は単純な技術的課題にとどまらない. 一度ネットワーク接続された 計算機上に知識が公開されると, インターネットを介してあらゆる組織の壁を 貫いた相互作用が発生する(村井純, インターネット 2, 岩波新書 参照). 当 然既存の枠組では対応できない問題が次から次へと発生するだろう. それを無 理矢理既存の枠組でとらえておったのでは健全なる情報化社会の発展, インター ネット社会と発展は望めない. 当該分野の情報科において, あらまほしき制度 の改革まで踏み込んだ展開を検討主張していくのが研究大学の責務として担わ ねばならないことのひとつなのではないか, というわけである. そのためには, しっかりとした当該分野の知識を持っていることは当然として, 同時に計算機 科学の展開を理解できるだけの知識をも持っていることが必要となるわけであ る. それを計算機科学の専門でない分野だけで行なうのは困難である(筆者ら も, 全国の関係業界有志でもって地球流体電脳倶楽部 http://www.gfd-dennou.org/ なんての試みたが遅々として迫力が出ない). しかしながら, 先に述べたように計算機科学の専門分野では他の分野における 実装の面倒までは見てくれない. そのような展開を担えるハイブリットな若手 をあるパーセント育てるためには, それぞれの分野がそれぞれの分野において きちんと対応していかなければならない問題であると考える.