Vol.1〜Vol.50

用語集

---

Ｖｏｌ．１　１９９８年７月

社長から突然インターネットの話が持ち上がりました。 突然とは言うものの、実際のところ以前から話には出ていたのですが気に留める事もなく日々を過ごしてきた私にだけ突然だったのかもしれません。 現状のインターネット界がどうなっているかすらも知らない私は、社長と連れ立って、とある会社のネットワーク環境を見せていただく事になりました。 その会社で説明を受けたのですが、インターネット接続は当然のこと、社内メール、掲示板、情報データベースなど、それまでの私にとってはほとんどが？？？のものでした。 説明を聞きながらメモをとり、ところどころでうなずいてはみたものの、内心「掲示板？グループウェア？何？？？？」いったところです。帰りの道中、無口だったのは言うまでも有りません。 それまでコンピュータに関しては多少は自信を持っていたのですが、それをいい事に新しい情報を仕入れる事を怠っていたつけが回ってきた気持ちでした。 その日から私のネットワークに関する猛勉強が始まったわけです。

<<

---

Ｖｏｌ．２　１９９８年８月 勉強編

「イントラネット」。前回のネットワーク環境視察において、頻繁に耳にした言葉です。話の中で、？？？だったものがすべてこれに関係しているようです。そこで、まずはイントラネットについて調べてみる事にしました。 私にとって、調べる事の基本は書籍です。しかも、タイトルに「絵でわかる」「図解」などの文字を見つけると、これさえ読めば・・・と思ってしまいます。 が、例のごとくさっぱりわかりません。ここまでわからないと清々しささえ感じます。数百ページの本を読み、わかった事は下の３つです。 １．イントラネットとはインターネットの技術を使ったローカルなネットワークである。 ２．グループウェアとはグループ単位での作業の共有を支援するシステムである。 ３．導入する目的をはっきりさせるべきである。 たったこれだけの事を理解するのに何時間もかけて本を読んだ事が非常にむなしく感じられたのですが、それはいつもの事で「俺は実戦派だから」と開き直るしかありませんでした。 しかし、私が理解できた数少ない中の「導入する目的をはっきりさせる」ことが、初期の段階ではもっとも大事だと今になって感じています。 なにごとも遠いところばかりみて先走る私には、当時そんな事を知るよしもありませんでした。

<<

---

Ｖｏｌ．３　１９９８年８月 プロジェクト発足

私のネットワークに関する勉強と同時に、導入計画も着々と進みました。 数社から話を聞き、いろいろと検討しました。 サーバーはUNIX系かNTか？外部との接続を専用線にするべきか？クライアントマシンは？とにかく手当たり次第に調べ、わからない言葉を勉強し、目の前にあるものを必死になって処理していきました。 ところが、ある日社長と打ち合せを行い、今までの調査結果を報告しようとノートをみてみると「・・・？、・・・？」。確かにいろいろ調べてはいるのですが、「NTとはどうである」とか「グループウェアソフトは○○○社と×××社などが扱っていて」程度の事しかないのです。まさしく広く浅くの調査をしてしまいました。 こんなことを報告されても社長としては「それで？」としか言いようがありません。私自身も何をするために調査していたのかがわからなくなってしまいました。 一見順調に進行していたかに思われた導入計画は、訳も分からず調査を進めてきた私の手により、ただ細かい事を掘り起こしてとっちらかしただけとなってしまいました。 そこで一度仕切り直しをする必要があると判断し、社長をリーダーとして、以下私も含めて５名による「社内ネットワークシステム整備プロジェクト」が発足しました。 ときに1998年8月19日の事でした。

<<

---

Ｖｏｌ．４　１９９８年８月 プロジェクト始動

プロジェクトとして最初にネットワーク整備の目的を明確にし、アプローチ方法の検討を行いました。 具体的には、社内の連絡体制再構築、社内の情報共有化、社外との情報伝達手法の確立により「当社のスローガン実現を支援するシステムの構築」を目的とし、それを達成するために実際に行う作業とその計画を検討し、整備完了の目標を10月としました。 作業としては、まずコンピュータやネットワーク、ソフトなど情報インフラの整備と、社内の連絡体制再構築を進める事になりました。 この連絡体制再構築も含めた受け入れ体制がしっかりしていないと、いくら情報インフラの整備を行ってもそのシステムは使い物になりません。 そのため、本来ならば受け入れ体制についてはプロジェクトメンバー全員がそれに比重を置いて進めることが望ましいのでしょう。 しかし10月整備完了という急務のため、さしあたっては情報インフラ整備と受け入れ体制整備を分担し、会議でそれぞれの検討結果について話し合うという進め方をとりました。 私はインフラ整備に重点をおき、必要に応じて受け入れ体制整備にも会議前の検討段階から参加するといった立場で作業することになりました。 メインがインフラ整備という、ある程度決まった形がある作業なので、私は安易に考えていました。 しかし当社の環境が実は一般的な事務所とはちょっと違っている事に気づいたのです。

<<

---

Ｖｏｌ．５　１９９８年９月 Windows主流

現在日本に出回っているパソコンのOSはほとんどがWindows主流であり、また各種ネットワーク関連の書籍も、そのほとんどがWindows環境を前提としたものが多く目に付きます。 しかし、当社ではそれまでMacintoshを中心にネットワーク環境を構築しており、情報インフラ整備をするにあたって最初に突き当たった壁とはこのことだったのです。 このままMacによる環境のみの整備とするべきか、それともWindows環境に乗り換えるべきか、この時点で方向性を決める必要性に迫られたのでした。 建設CALSなどの観点では、データの互換性が取れれば、OSがなんであろうとネットワーク上では問題ないといわれます。 しかし実際には、当社が遭遇した社外との互換性の数々のトラブルを考えると、OSの違いという壁は決して小さいものだとは思えません。 そこで、プロジェクトのリーダーと話し合った結果、今後の外部とのデータ交換も考えて新規購入分はWindowsとし、現在のMacもそのまま活用することになったのでした。 Mac・Win共存とした場合、社内での既存データの互換、プリンタ・ファイル共有などについて問題が発生することが予想されたのですが、それぞれ「両環境での同一アプリ使用」、「プリントサーバー導入」、「UNIXサーバー構築」といった手段をとる事で解決するであろうと考えたわけです。 以上により当社の情報インフラ整備のアウトラインを決定し、以降それに沿って整備の検討を行っていくことになったのでした。

<<

---

Ｖｏｌ．６　１９９８年９月 社内の受け入れ体制

一方、受け入れ体制整備のほうは、まず現在の社内での報告体制という基本的な流れを洗い出すことから始めました。 社員に調査用紙を配布して、記入してもらった用紙を回収する方法をとったのですが、やはり簡単にはいきません。こちらの説明不足か、それとも情報化することに批判的なのか、主旨にそぐわない回答が少なからず見られたのでした。 プロジェクトのメンバーから再調査という声も聞かれたのですが、この状況も一つの事実ということでそのままとりまとめることにしました。 社員から回収した内容をカテゴリーごとに分類し、それぞれについて改善案を検討したものの、電子化にこだわりすぎたためかえって勝手が悪いものになるなど、そう簡単に決まるものではありません。 苦心の末、何とか素案を作り、フローチャートにまとめました。 その際に、現状維持の報告体制に関してもフローチャートで表わす事によって、今まで各人の判断に任せて曖昧になっていた部分も明確になりました。いわゆる、ISOの真似事をしていたのです。 しかし、この段階で出来あがったものはあくまでもプロジェクトメンバーから社内への提案でしかないわけで、実際にこの体制を軌道にのせるためには社員全員から同意を得る必要がありました。 その効果的な方法として私たちは社内報告会という形式を取る事にしました。

<<

---

Ｖｏｌ．７　１９９８年９月 社内報告会

プロジェクトからの提案を報告会という形で社内に伝える事にした私たちは、まず報告会の方向性について検討しました。 ただ提案内容をまとめて読み上げたのではあまりにも説得力に欠けます。そのため、このプロジェクトが行ってきた作業の必要性を社内に伝え、社員全体が同じ意識で取り組むという気持ちを持ってもらう事を目標として、報告会の内容を考える事にしました。 会社を取り巻く環境の変化を背景としたプロジェクト発足の経緯や、以前検討した連絡体制の提案はもちろん、ハード的な部分の説明、使用するソフトについて等、細部にいたるまで取りこぼしの無いよう慎重に準備を進めました。その末に、報告会を以下の3回に分けて行う事としました。 第1回 プロジェクト発足の経緯とネットワーク環境の説明 第2回 新連絡体制の提案 第3回 インターネットソフトの使用法 しかし、電子化等についての報告を行うのに紙という媒体を使用したのではあまり効果的な報告会になるとは思えません。そこで、ちょうど時を同じくして購入していたプロジェクターを利用して、電子的なプレゼンテーションを行う事になったのです。 その上で、この3回の報告会ですべてを伝えるべく、数度にわたりリハーサルを行い、準備を整えました。 そして第1回報告会当日、ほぼ予定通りに開会し、ハプニングも無く一通り報告を終える事ができました。 が、当初予想していた通り質疑応答のときは反応が薄く、しかも環境整備の必要性よりも、新しい環境に対する期待へと社員の興味の矛先が向いていることをその時感じ取ったのでした。

<<

---

Ｖｏｌ．８　１９９８年９月 発注

受け入れ体制整備班を中心に社内報告会の準備をしているころ、情報インフラ整備班ではVol.6でご紹介したアウトラインに沿って、具体的な検討を終えようとしていました。 新規購入台数や既存のマシンとの兼ね合いも考えたPCの配置、ケーブルの取りまわし、ハブの設置場所と必要台数などを確認し、検討や概算見積を算出してはやり直しのくり返しで、どうにか発注できる段階までこぎつけ、ようやく一段落です。 しかし翌日になってから、クライアント機として予定していたDOS/V233MHzの在庫不足とラインナップの変更のため、同メーカーで1ランク上の266MHzが同じ金額になるという情報が入りました。 そのとき、業者と密に連絡を取ってきてよかったと思うのと同時に、パソコン業界の価格競争の激しさをあらためて実感しました。 しかし私たちユーザーにとっては悪い話ではありません。さっそく導入機種をすべて２６６MHzのものに変更する事にして発注をしました。 納品まで約2週間あったので、その間にIP Messengerというメッセージ送受信ツールをつかい、TCP/IPを使用したネットワークとEメールを想定した電子的なメッセージ交換の環境を体験する事にしました。 まずはプロジェクトメンバー内で接続する事にしたのですが、恥ずかしながら私はそれまでWindowsでのネットワーク設定方法を全く知らなかったのです。 Macintoshでは何度もネットワークの設定をしていたので、そんなに違いはないだろうとタカをくくって作業に臨んだのですが、それは私の甘さを再認識するだけの結果となったのです。

<<

---

Ｖｏｌ．９　１９９８年９月 ネットワーク設定１

Windowsネットワーク初心者である私は、まずWindowsの標準的なプロトコルであるNetBEUIでファイル共有に挑戦する事にしました。 NetBEUIは最初からネットワーク構成に含まれているらしく、コントロールパネルのネットワークアイコンを開いた時点で既にリストに入っていました。 各種設定をおこない、あとは共有フォルダを作成して完成です。ワークグループの設定など多少手間取った箇所はあるにしろ、意外とすんなり接続する事ができました。 つづいてTCP/IPでの接続に挑戦です。 TCP/IPについては、Macintoshで経験済みですし、WindowsのネットワークもNetBEUIでやったばかりなのでこれも問題なくできるだろうと踏んでいたのですが、そうそう甘くはありません。 まずネットワーク構成のリストにTCP/IPを追加する事から始めました。 追加ボタンをクリックし、構成ファイル→製造元→プロトコル指定と、ここまではGUIの強みである「直感的な操作」でおこなう事ができたのですが、問題はその後です。 今追加したTCP/IPの詳細を設定しようとプロパティを開いたのですが、タグが７つもあるのです。 NetBEUIのときは２つだけで、しかも変更する箇所が無かったのですが今回はそうもいかないようです。 その上分かる言葉がIPアドレスしかなく、とりあえずIPアドレスを設定した時点で既にMacintoshでの経験が意味の無いものに感じられました。

<<

---

Ｖｏｌ．10　１９９８年９月 ネットワーク設定２

WindowsをTCP/IPによるピア・トゥ・ピアで接続する際に、まず手をつけたのがIPアドレスでした。 正直なところ他にわかる言葉が無く、ここからしか手のつけようが無かったのです。 IPアドレスを他のマシンとダブらないようにつけ、ここまでは良かったのですが問題はこの先です。 7つもあるタグの何をどう設定したら良いものかわからず、とりあえずIPアドレス以外は初期の設定のままで接続を試みる事にしました。 マシンを再起動し、ネットワークコンピュータを開いてみると、先行して設定をおこなっていたプロジェクトリーダーのマシンが見えるではありませんか。 私が悩んだ、難しい言葉のタグはその時点では必要なかったようです。 忘れないうちにと、隣にいるプロジェクトメンバーと一緒に、そのメンバーのマシンの設定をやってみたのですが、だめでした。 同じように設定したはずなのですが、どうもつながりません。 そこで一度追加したTCP/IPをリストから削除してもう一度設定してみました。 それでもだめだったので何度か削除しては追加という作業を繰り返したところ、ようやく接続可能になりました。 恥ずかしながら接続できなかった原因はいまだに分かっておりません。 ただ経験上、設定を確認して間違いが見つからないときは、削除してもう一度やり直してみるのも一つの手かと思います。

<<

---

Ｖｏｌ．11　１９９８年９月 IPメッセンジャー

試行錯誤の末に何とかTCP/IPによるピア・トゥ・ピア接続に成功した私たちは、次にIPメッセンジャーを使って電子的なメッセージの交換がおこなえる環境を構築する事にしました。 IPメッセンジャーは、TCP/IPプロトコルを採用したシンプルなメッセージ送受信ツールです。 送・受信両方のマシンでこのツールが立ち上がっていなければならないのですが、手軽さなどを考えればそれでもかなり有益なツールだと思います。 Win3.1やMS-DOSでLANを利用していた方でしたら、「LAN Manager」のようなものと考えていただければ良いかと思います。 ただ、前述のようにTCP/IPを採用しているため、クロスプラットフォームを実現しているのです。 当時、私はクロスプラットフォームは非常に難しいものと考えており、フリーのツールを一つ入れたところで・・・と思っていました。 しかし、意外にもあっさりとつながったのです。 IPメッセンジャーをインストールし、ユーザー名やグループ名などの簡単な設定をしただけで、Mac・Winを問わずメッセージの交換ができるようになりました。 成功したときは初めて体験したクロスプラットフォーム環境に感動したのですが、一方で今後この環境を社内に広げる場合に、一般的にネックになるといわれる管理職の人たちに受け入れてもらえるかという不安も大きかったのが正直なところです。

<<

---

Ｖｏｌ．12　１９９８年９月 クライアントマシン納品

ネットワーク整備プロジェクトメンバー内でIPメッセンジャーがつかえるようになってまもなく、注文していたクライアントマシンが納品されました。 納品されたマシンは、開封から接続、Windowsのセットアップまで各人でおこなってもらいました。そうする事によって、自分のマシンだという意識が強くなり、パソコンに対する興味も湧くのではないかと考えたのです。 セットアップ時にかなりの質問がでる事を予想し、あらかじめ各部署の連絡担当者を決めておき、プロジェクトメンバーが設定法などを連絡担当者に伝え、連絡担当者は自分が所属する部署の指導をするという体制を取りました。 それでも各所からいろいろと質問されたのですが、連絡担当者経由という体制をとらなければ対処しきれなかったでしょう。 今後もこの連絡担当者にはなにかと手伝ってもらうつもりです。 なんとかセットアップも終了し3日ほどたって、イーサネット用のネットワークボードが届きました。 今回購入したマシンにはネットワークボードがついていなかったため、マシンとはべつに注文していたのです。 私は各マシンにネットワークボードを組み込むことにあまり気が進みませんでした。 組み込む作業自体がいやだったわけではなく、ネットワークでつながれた環境、具体的には電子的な会話（IPメッセンジャー）が社員に受け入れてもらえるか心配だったのです。

<<

---

Ｖｏｌ．1３　１９９８年９月 IPメッセンジャー導入

先日納品されたクライアントマシンにネットワークボードを組み込む作業をおこないました。 通常ですと、TCP/IPの設定や動作テストなどもおこなうのですが、今回はVol.12で紹介しました各部署の連絡担当者にだけ説明し、それ以外の社員には連絡担当者から伝えてもらう方法をとりました。 連絡担当者を集め、実際に設定する様子を画面上で見せながら説明したのですが、反応を見るといまいち理解していないような表情です。 それでも自分のところの設定はできていたようなので、様子を見る事にしました。 現場から社員が戻り、連絡担当者が設定の方法などを説明し始めました。 するとやはり部分的に理解できていない箇所があったようで、あちこちから呼ばれる事になりました。 うまく設定できない原因の大半はIPアドレスでした。 入力する箇所が違ったり、番号がおかしかったりと単純な事だったのですが、連絡担当者がきちんと理解できるように説明しなかった私のミスと反省するばかりです。 それでも各マシンの設定も終わり一安心、というわけにはいきません。 以前から心配していた「この環境が受け入れられるか」という一番大きな問題が残っています。 しかし、意外にもすんなりと受け入れられたのです。それどころか、その環境を楽しんでいるようにも見えました。 普通の会話や電話とはまた一味違った文字でのやり取りを、手紙よりも簡単にできるということが新鮮に感じられたのかも知れません。私自身そうでした。 また、それまでMacintoshを業務の中で使っていた事がコンピュータに対する拒否反応の免疫となっていたこともあるでしょう。

<<

---

Ｖｏｌ．1４　１９９８年10月 メールアドレス

IPメッセンジャーもだいぶ社内に浸透し、使用する事に違和感がなくなってきたころ、数日後にUNIXのサーバーが納品されるとの連絡が入りました。 その時まだ社員のメールアドレスを決定していなかったため、正式に決める事にしました。 しかし、それまで何も考えていなかったわけではなく、どのような規則でアドレスをつけるかといったアウトラインはできていたのです。 基本的に当社では以下の規則に従ってアドレスを決定致しました。 1.@前(アカウント)は姓をローマ字（ヘボン式--->shi,tsu等）であらわす。 2.姓が同じ場合は若い人を”姓頭文字−名前”とする。 3.ヘボン式で8文字を超える場合は本人に確認をする。 ですから、今回やらなければならなかったことは、規則３が適用される社員に文部省式のローマ字とするか、部分的に省略したものとするかの確認をしたぐらいです。 それから2日後、ついにサーバーがやってきました。

<<

---

Ｖｏｌ．1５　１９９８年10月 サーバー納品

各社員のメールアドレスを決定し、準備を整えたところでサーバーが納品されました。 当社では、Linuxでサーバーを構築してもらい、管理を自社でおこなっていく事となっていたのですが、私が本格的に使った事があるのはMacとWinぐらいだったので、正直なところきちんと管理していく自身はあまり無かったのです。 しかし、サーバーが納品された１０／１５の時点ではまだDION専用線の開通までに一週間程度の余裕があったため、その期間を利用していろいろ覚えるつもりでした。 納品されたときには既にほとんどの設定が終わっており、あとはユーザーの登録程度の作業しか残っていません。 私はまず触ってみなければと思い、サーバーを構築していただいた業者さんの立会の元にユーザーの設定をしてみました。 すぐ隣に詳しい方がいて教えてもらいながらという環境のせいもあって、意外とすんなり設定する事ができました。 ちなみに、その時の社内用サーバーの内容は以下の通りです。 ・Webサーバー ・DHCPサーバー ・ftpサーバー ・メールサーバー ・グループウェア 私は、Linuxって意外と簡単だという浅はかな考えをもったまま、専用線が開通する日をまっていました。

<<

---

Ｖｏｌ．16　１９９８年10月 Linuxの勉強

サーバーが納品され、専用線が開通するまでの十日間ほどを利用してLinuxの勉強をする事にしました。 なにか新しいものをさわることが好きな私はもうドキドキです。しかしそれはほんの数分間の事でした。 まず参考書をみて・・・理解不能です。 こういうものは実際にモニタを見て・・・だめです。 結局その日はログインの仕方とディレクトリ移動程度の事しか覚える事ができませんでした。 十日で管理できるまでのレベルになろうというのはかなり甘い考えである事にようやく気づきました。 たとえその間、他のすべての作業を放ってかかっても私の能力では無理でしょう。 Linuｘについては、構築していただいた業者さんにいろいろ教わりながら少しずつ覚えていく事にしました。 その他にもう一つ私が興味をひかれたものが、Office２というソフトです。これはサイボウズ社によるグループウェアソフトで、あらかじめ社内サーバーにインストールしていただいていたのです。7月にある会社のネットワークを見せていただいた時から実はきになっていたのです。 そしてさっそくOffice２を開いてみました。

<<

---

Ｖｏｌ．17　１９９８年10月 Office2

あらかじめ社内サーバーにインストールしていただいたサイボウズ社のOffice2が前々から気になっていた私はさっそく見てみました。 Office2には特別なクライアントソフトは必要なく、一般的なブラウザで使用する事ができます。 ブラウザを立ち上げURLを打ち込むと、イラストが入った楽しげな画面が表示されました。 掲示板や電子会議室、ビジネス情報などたくさんの機能があるのですが、それぞれがばら売りされており、必要な機能だけを選んで購入する事ができるのです。 ちなみに当社では60日間のお試し期間中にいろいろと検討し、現在ではすべての機能を使用させていただいております。 当初、私の考えでは新連絡体制にも利用が定義されいる掲示板の購入のみで良いのではないかと考えていました。 しかしその他にもスケジュール管理や行き先案内板など、うまく使えばとても有益だとおもわれる機能ばかりです。 社長もそのように判断したらしく、前述のとおりすべての機能を購入しました。 今後Office2をどう使っていくか等、私が一人で想像している間に専用線が開通する日がすぐ迫ってきていました。

<<

---

Ｖｏｌ．18　１９９８年10月 専用線開通

当社の専用線開通の日がいよいよ明日となりました。 私は知らんぷりをして会社に残り、午前0時をまわると同時に一番乗りで接続してやろうと考えました。 しかしDDIの方の話によると、接続後なにかしらの手続きをする必要があるとの事だったので、一番乗り計画を断念し、その日は帰宅の途についたのです。 そして次の日、待ちに待った専用線開通の日です。 DDIの方やサーバーを構築していただいた業者さん、回線工事業者の方が朝からいらっしゃってなにやらやっています。 電話の配電盤あたりで問題があるようです。 社屋の図面などを広げ、いろいろと話をしていたのですが、各業者さんとも都合があり、その日の開通は半ばあきらめていました。 そしてまもなく12時になろうとしていたときです。つながりました。 私があきらめて別の作業をしている間に何とか問題が解決したのでした。 一番乗りしてやる！と思った瞬間、社長より社内メールが届きました。 それはサーバーの構築などで今回何かとお世話になった業者さんからの、社長に対する返信を転送されたものでした。 という事は、既に社長がメールを送っていたのです。 私が前から密かにねらっていた一番乗りにライバルがいたとは考えませんでした。 そして、いよいよ本格的にLinuxサーバーの管理をおこなっていく事になったのです。

<<

---

Ｖｏｌ．19　１９９８年11月 接続不可

インターネットへの接続が可能になってからまもなく、社内のある部署から「ネットワークにつながらない」との苦情がきました。 いってみると、確かにつながっていません。 以前Macでのネットワークを使っていたときも同じような事が起きていたので、私はまず接続ケーブルを疑いました。 一度ケーブルを抜いて、さし直すとつながるという事を何度か経験していたのです。 まずパソコン側のケーブルを確認して、次にHUB側のケーブルをさし直してみました。 しかしそれでもつながりません。 どうしたものかと考えているその時、キーボード上のCapsLockのランプが輝いているのが目に入りました。 すぐにCapsLockを解除し、スタートメニューの終了からログオンし直してパスワードを入力すると、接続が確認されました。 その場はそれですんだのですが、まもなくあちこちから同じような苦情が多発したのです。 原因はほとんどの場合がケーブルの接続が甘いかログオン時のパスワード間違いのどちらかでした。 こんなことでいちいち呼ばれていたのでは仕事にならないと考えた私は社員全員に同報メールで以下のような内容のメールを送信しました。 ＞ ネットワークにつながらない場合は以下のようにしてみて下さい。 １．ネットワークケーブルの確認 ２．CapsLockの確認後、再ログオン ３．メール受信時のパスワード確認 ４．以上でもだめな場合は再起動 ＜ その後しばらくは苦情が出なくなったため安心していました。 しかし、またすぐに同じような苦情が出てきたのです。

<<

---

Ｖｏｌ．20　１９９８年11月 接続不可2

ネットワークにつながらないという苦情は、対処法を通知する事によって解決されたように思われました。 しかしその後同じような苦情がまた発生したのです。 私はどうせ簡単な事だろうと思いながらその部署に向かいました。 ネットワークケーブルの接続確認や再ログオンなどの処理をおこない、デスクトップ上のネットワークコンピュータアイコンをクリックしてみたのですが、何も表示されません。 どうやらシステム的にどうこうの問題ではないようです。 しかしシステム的な問題でないのなら何を疑えば良いのか、私には見当もつきません。 が、幸いシステム課内に電気、無線などの技術に詳しい社員がおり、相談してみました。 すると彼はHUBの場所を確認し、工具箱をもって席を立ちました。 しばらくして戻ってきたので話を聞くと、HUB同士をつなぐケーブルに問題があったとの事です。 詳しくは、芯線とコネクタ部分のはんだ付けに不備があったため、接触不良をおこしており、それを付け直して修理完了です。 それは私にとって盲点でした。 自分の視野の狭さを再認識し、その日のうちに今回起きた事を私のトラブル対処マニュアルに追加しました。

<<

---

Ｖｏｌ．21　１９９８年11月 社内ホームページ

ケーブルの修理をおこない、社内のネットワークも安定しました。 今までのように苦情処理で一日をすごす事もなくなり、ようやく落ち着いてOffice2を見る事ができます。 しかしなぜか物足りなさを感じてしまいます。 掲示板、スケジュール管理、その他もろもろツールは揃っているし使い勝手も上々なのに何が不満なのか？これだけがイントラネットか？そんなことが頭の隅に残りつつ日々を過ごしていました。 そんなある日、社長が社内ホームページを立ち上げたのです。 内容は、会社情報、行動指針、Office2へのリンクなど、シンプルなものなのですが、知りたいと思う情報がうまくまとめてあり、非常に便利なものとなっていました。 私は、これだ！と思いました。 ネットワーク環境を構築する事やハード的な保守にばかり気を取られ、イントラネットの本来の目的である「情報を共有する」という考えが抜けていたようです。 私は、各部署ごとに技術情報的なページを作ってもらおうとか、個人で持っている情報も共有したいなど、いろいろと構想を膨らませていました。 しかしその前に、社員の情報リテラシーをそのレベルまで高める必要があります。 まずはそこから着手するべきだと考えました。

<<

---

Ｖｏｌ．22　１９９８年11月 社外メール送信不可

社員の情報リテラシーをそのレベルまで高める必要があると考えている矢先に、社外にメールが送れないという苦情がきました。 いってみると、社内のサーバーにメールを送っていたようです。 これでは社外のメールアドレスを探せるはずがありません。 当社の場合、極端に言えば社内サーバーと社外サーバーはそれぞれ独立しており、社内のマシンから外部にアクセスする場合は社内サーバーではなく、ファイアウォール経由でなければいけません。 サーバー導入当初にそれらしい話はしたのですが、私自身も当時はいまいち理解していませんでした。 そのため、聞き側も理解できずにいたようです。 私はこれを機会に、メールの送信方法にかこつけてもう一度ネットワークの構成を社員に伝えることにしました。 そうした方が、ただ「こうして下さい」というよりも深く理解してもらえるのではないかと考えたのです。 -------------------------------------------------- Vol.22のまとめ： 操作方法を説明するときにはその仕組みから理解してもらう -------------------------------------------------- Vol.22関連項目： セキュリティ

<<

---

Ｖｏｌ．23　１９９８年11月 ネットワーク構成の説明

私はメールの送信方法にかこつけて、もう一度ネットワークの構成を社員に伝えようと考えました。 伝える手段としては、今でしたら迷わず電子掲示板を使うところでしょう。 しかしその当時はまだ本格的にグループウェアの運用が始まっておらず、掲示板を利用するにはまだ早いと判断し、メールで行う事にしました。 まず、以下の項目を簡単に説明する文章を作成しました。 １．ファイアウォールの存在と役割 ２．社内メールがどのような経路で配達されるか ３．社外メールがどのような経路で配達されるか ４．２，３を踏まえてのメール送信方法 しかし、文章だけでは理解するのは難しいと思い、ネットワーク構成図にメールの流れや簡単なコメントをつけ、それをメールに添付しました。 その後、顔を合わせたときやメールでなど方法は様々ですが「図を見て理解できた」との声が多く聞かれました。 私の説明文が悪かったのか図の書き方がうまかったのかはわかりません。 しかし、どちらにしろ人に何かを伝えるときは、どうせわからないだろうと考えるのではなく、わかるように説明する事が必要だという事を学びました。 -------------------------------------------------- Vol.23のまとめ： 説明は相手に分かりやすく、順序を追って行う必要がある。

<<

---

Ｖｏｌ．24　１９９８年12月 クラック？

社員のリテラシー向上も大切ですが、私自身が管理者として レベルアップしていかなければなりません。 そんなことを考えていたある日、Linuxのメーリングリストから来たメールをチェックしていると、不正アクセスの事が話題として上がっていました。 それでなんとなく気になってサーバーのログをチェックしてみると、下のような記録が残っていました。 Crack attempt, host=***.***.***.*** (***部分にはIPアドレスが入ります） 「クラック！？」その文字を見た瞬間私はドキっとしました。もしかと思い、メッセージログ内でIPアドレスを検索したところ、 Login failure user=^?^?^?^ host=***.***.***.*** Login failure、つまりログイン失敗です。 私はとりあえず一安心しました。 とはいうものの、完全に安心することができず、偽造シェル等 はないかとを探してみましたが、それらしいものは見当たりま せん。今回は大丈夫だったようです。 セキュリティの重要さは認識していたつもりでしたが、それについてはおいおいしっかりと勉強していこうと考えていたのです。 しかしそう考える時点で、セキュリティの重要さを認識しているとはいえない、と今になって思います。 私は今回の件に関してさっそく対策を取ることにしました。 ---------------------------------------------------- Vol.24のまとめ：早期発見のため、ログのチェックはこまめに。

<<

---

Ｖｏｌ．25　１９９８年12月 パスワード変更

クラックを試みた形跡を発見して、早急に対処することにしました。 サーバー上で行った設定については、不要なポートを閉じる、パスワードの変更などの対処をしたとだけ書かせていただきます。 その他の対処としては、クライアントのパスワードを以下の手順で変更することにしました。 １．パスワード記入用紙を作成し、社員全員に配布 ２．記入してもらった用紙を回収し、サーバーに登録 ３．記入用紙を社員に返して、パスワードは個人で管理 ここでパスワードを個人管理とした理由は、もしパスワードがらみのトラブルが発生した場合に責任を負いきれないということにしておきました。 しかし、実際はパスワードを個人で管理することによりセキュリティの重要性を社員に理解してもらうという２つのねらいがあったのです。 このことで社員の情報に対する意識が、また少し向上したのではないかと感じております。 社内の意識向上とともに私もセキュリティに対する考えをあらため、最低限のことだけでも今すぐに勉強しようと決心しました。 --------------------------------------------------- Vol.25のまとめ：常に社内のレベルアップをはかる

<<

---

Ｖｏｌ．26　１９９８年12月 セキュリティ

クラックを試みられたことによって、私はセキュリティについて勉強することにしました。 今回は番外編的にそのときに勉強したこと等を掲載させていただきたいと思います。 インターネットの世界ではもはや一般常識のようになっているセキュリティですが、実際にはどうでしょう。 少なくとも私は、大切であるとは思いつつも、正直なところあまり重要視していませんでした。 様々な書籍に「セキュリティは大切である」かいてあるので表面上はそう思うようにしていたのですが、「うちに侵入したって・・・」という思いがどうしても抜けずにいたのです。 しかし調べたところによると、侵入して内部をいじるだけではなく、踏み台にされる恐れがあるというのです。 要するに、例えば一度当社のサーバーを経由し、そこから本来の目的であるところへ侵入するらしいのです。 そうすることによって、侵入された側がクラッカーの追跡を行うと当社に行き当たります。 この場合、侵入した側はもちろん、された側や踏み台にされたサイトにも同等の責任があると思います。 （続く） --------------------------------------------------- Vol.26のまとめ： クラックは内部に侵入されるだけでなく踏み台に使われる場合もある

---

Ｖｏｌ．27　１９９８年12月 セキュリティ 2

クラックに対してどうセキュリティを行っていくべきか。 専門のサイトや詳しい方には到底及びませんが、当社なりに行っていることや一般的にいわれていることなどを記載させていただきます。 まず、今回クラックを試みられたことによってとった対策としては、必要以外のポートをすべて閉じることです。 社内の人間が外からアクセスしようとした場合でも、不便を感じるくらいにしているつもりです。 次に、パスワードの変更です。 サーバーのパスワードはもちろん、社員全員のパスワードを変更しました。 徹底するのなら、頻繁に変更する必要があるのではないでしょうか。 社内への侵入に対するセキュリティも上記の対策にプラスして、ファイアウォールの設置で対応しています。 しかし、どんなに完璧と思われる対策を取っても、「本当に完璧な対策はない」と良く言われています。 要するに、世界中につながっていることを常に意識して、不正アクセスに備えていなければ、どんな対策を取っても完璧ではないということだと思います。 逆に、常に意識していれば、そのこと自体が強力なセキュリティのツールとなるということでしょうか。 --------------------------------------------------- Vol.27のまとめ：世界中につながっていることを常に意識する

---

Ｖｏｌ．28　１９９９年1月 ASH Webサイト

年末年始の休業をはさみクラック騒動も一段落して、Web サイト編集員による編集会議が開かれました。 それまでもWebサイトの運営は行っていたのですが、2月か らのスタートを目標に、社員参加型のサイトにしようとい う主旨に基づいての会議を行ったのです。 会議の方法はKJ法により行いました。 編集員それぞれが思い付く企画を紙に記入し、それを回収 して読み上げます。 その時に、足りない部分を記入者が補足説明する方法です。 これによってアウトラインを作成し、次にこれらの企画を 具体的につめていきます。 提案された企画をどういったグループで括るか、各企画の 担当編集員を誰にするか、記事募集の対象者、更新頻度な ど、細部を数回の会議にわたって検討しました。 その他、基本方針等も企画検討以前の会議により決定して いました。 その結果、現在の当社Webサイトの原形が出来上がったわけ です。 --------------------------------------------------- Vol.28のまとめ： 編集員の意見を反映するためにKJ法により編集会議を行った。

---

Ｖｏｌ．29　１９９９年2月 アクセスカウンタ設置１

1月のWebサイト編集会議で決まった内容を踏まえて、2月13日に当社のサイトがリニューアルすることになりました。 その数日前のことです。 編集長はじめ、編集員内で「アクセスカウンタが欲しい」という話が出たのです。 私はさっそくアクセスカウンタ設置の準備をすることにしました。 まず、インターネット上でフリーのアクセスカウンタを探しました。 というのも、私はCGIスクリプトが全然わからないのです。 いちからCGIを勉強して作れれば良いのでしょうが（私自身そうしたいのですが）それよりも詳しい方がフリーで提供されているものを使用するほうが見栄え、性能、時間的な問題などあらゆる面において得策だと判断したのです。 それで今回は”ホームページの飾り職人”様 のサイトからダウンロードさせていただいたカウンタを使用することにしました。 ダウンロードしたファイルを解凍し、いよいよ設置です。 しかし、当社のサーバーは、セキュリティの方針から、CGIの動作を不可としていました。 そこでまずは社内のサーバーに設置して実験することにしたのです。 --------------------------------------------------- Vol.28のまとめ： カウンタCGIをダウンロードし、社内サーバーで試験をすることにした。

---

Ｖｏｌ．30　１９９９年2月 アクセスカウンタ設置2

社外のサーバーでCGI動作の設定をする前に社内のサーバーでカウンタの実験をすることにしました。 数字のGIFファイルを準備し、説明にしたがってスクリプトの内容を変更し、各ファイルをサーバーの適切と思われる場所に配置しました。 そしてテストです。 ドキドキしながらアクセスしてみると、なんと表示されません。 GIFイメージが表示されるべき所がバツ印となっているのです。 CGI自体はきちんと動作しているようなので、その他の部分に問題があるようです。 私はディレクトリの名前を変更したり、パーミッションを確認し直したりと考えられることは一通り試してみました。 それでも結局カウンタは動作すること無く、サーバーの中と私の頭の中を散らかしただけとなってしまったのです。 とりあえずサーバー内を元に戻して、しばらく時間を置いてからもう一度チャレンジしてみました。 時間を置いたせいか、頭の中がクリアされてあらためて考えることができるようになっています。 サーバーをいじる前にいろいろと調査をした結果、当社のサーバー設定では説明のファイルと同じ設定ではだめだということが判明したのです。 説明には一つのディレクトリ内に階層をつくり、そこでファイルを別けていました。 しかし当社の設定では、もっと上の階層でドキュメント、CGI、イメージデータなどを別けて格納する必要があったのです。 それにしたがってファイルを配置し、再びアクセスしてみると 「００００１」 動作しています。 私は気を良くし、その日のうちに社外のサーバーにもCGIファイルをコピーしました。 --------------------------------------------------- Vol.30のまとめ： 説明を鵜呑みにせず、自分の環境を良く考える。

<<

---

Ｖｏｌ．31　１９９９年2月 アクセスカウンタ設置3

CGIファイルを社外サーバーにコピーした次の日、CGI動作の環境設定を行いました。 CGIが動作することを確認し、あとはHTMLにCGI呼び出しのタグを追加すれば完了です。 私は編集長にタグ追加のお願いをして、カウンタ設置完了をまちました。 まもなく内線の呼び出し音がなり、私は設置完了の知らせだろうと思い、わくわくしながら電話を取ったのです。 が、それはうまく動かないことを知らせるものでした。 なぜだろう、ときかれても私には思い当たることがありません。 HTMLのタグを確認しても問題ない。 ファイルの設置場所も間違いない。 CGIが間違っていることはないだろう。 どうしても理由がわからず、気休めのつもりでCGIのファイルを開いてみました。 「間違いなんて無いよな・・・」などと思いつつ眺めていると、「あれ？」 おかしいところを発見しました。 当社で使用しているカウンタは、そのプログラムを呼び出すページをファイル内で指定しなければなりません。 トップページにカウンタを設置するつもりだったので、そこはトップページのアドレスが入っていなければいけないのです。 しかし、よくよくみてみるとページの指定が何もされていないのです。 私はすぐにプログラムを書き直し、サーバーに戻してみると 「００００１」 動作しています。 数日前に味わった感動が再び訪れました。 こうしてこの日以来当社のサイトにカウンタが設置されたのです。 --------------------------------------------------- Vol.31のまとめ：1999/2/15 アクセスカウンタ設置

<<

---

Ｖｏｌ．32　１９９９年2月 ホームページ視聴率

無事にアクセスカウンタを設置した数日後のことです。 以前ここでも書きました、Cybozu社から「ホームページ視聴率」という製品が発売されているとの情報が入りました。 さっそくCybozu社のサイトで詳細を見てみると、 ・一日、一ヶ月、累積のアクセス状況の確認 ・時間帯毎のアクセス状況の確認 ・ページ毎のアクセス状況の確認 ・ドメイン毎のアクセス状況の確認 ・ドメイン別の閲覧ページ内訳 といった機能があるようです。 確かに当社のアクセスカウンタはトップページからのみ呼び出し可能なわけですし、途中のページにリンクをはって頂いたり、ブックマークをつけていただいたりという状況も考えられます。 そうした場合に、カウンタの数字がそのまま実際のアクセス件数かというと、そうとも言い切れません。 むしろ、同じではないと考える方が妥当かと思われます。 また、アクセスが多いページと少ないページを明確にできることにより、今後のサイト運営に役立てることができます。 以上のような内容をWeb編集長である社長と協議し、Cybozu社「ホームページ視聴率」を導入する運びとなったのです。 --------------------------------------------------- Vol.32まとめ：「ホームページ視聴率」導入検討

<<

---

Ｖｏｌ．33　１９９９年2月 ホームページ視聴率2

cybozu社「ホームページ視聴率」を導入することに決定し、私はすぐにcybozu社のサイトからプログラムをダウンロードしました。 サーバー上でファイルを解凍し、あとはカウンタを設置したときと同じ要領でセットすればOKです。 強いて問題をあげるとすれば、ファイルを解凍した時点でいくつかのファイルが勝手にディレクトリを移動してしまい、それを探すのに苦労した程度でしょうか。 ともあれ、カウンタ設置の経験が生きて、意外とすんなりインストールすることができました。 その後は、毎日のように状況の確認などを行い、当社のサイトのあり方や方向性などを検討する材料の一部として活用しています。 それによって、かなり主観的ですが、このサイトも少しずつながら成長しているように感じられる今日このごろです。 --------------------------------------------------- Vol.33まとめ：1999/2/18「ホームページ視聴率」導入

<<

---

Ｖｏｌ．34　１９９９年3月 フレーム

「ホームページ視聴率」を導入したことにより、ページごとのアクセス数が明確にされるようになり、ますますがんばって記事を書かなければと思っていた時でした。 建設CALS情報局を運営されている錦織様より、このページにリンクをはっていただけるとの話がきていることを聞いたのです。 それは編集長にとっても私にとっても大変うれしいことです。 しばらくしてリンクが張られていることを確認し、そこからこのページにアクセスしてみると・・・見事に表示されます。 しばらく眺めていると、？？？。 何か変です。 妙にすっきりしている印象を受けたのでした。 コンテンツがなかったのです。 当社のサイトは、どこからでもどこへでも移動できるようにと、画面をフレームで区切って、左側にコンテンツを設けております。 当初は、このサイトを訪れていただいた方に、快適に見ていただくためには非常に有用な機能だと考えていました。 しかし、環境によっては表示に時間がかかるなどする恐れがあり、逆に不便なものになっているかもしれないのです。 そのとき、当社のページはリニューアルしたばかりだったので、すぐレイアウトを変えてしまったのでは、頻繁にきてくださる方の困惑を招くことも考えられます。 そこで、とりあえず「電算導入の歩み」のページから上の階層に戻る際にフレームを再表示させる方法を探すこととなりました。 --------------------------------------------------- Vol.34まとめ：ページのフレーム使用について考える

<<

---

Ｖｏｌ．35　１９９９年3月 フレーム2

「電算導入の歩み」にリンクをはっていただき、そのページから上の階層に戻る際に、フレームを再表示させる方法を探すことにしました。 とはいうものの、私はHTMLに精通しているわけでもなく、手元にそれらしい資料もありません。 こんなときこそインターネットです。 早速検索サイトにアクセスし、「HTML」の文字を入力して検索を開始しました。 たくさんのサイトが候補として表示され、これだけあれば目的のものが見つかるだろうと思いきや、そうはいきませんでした。 検索されたサイトが多すぎるのです。 私は、検索条件を「HTML 講座」と打ち込み、再検索してみると1000ちょっとにまで減りました。 あとは紹介文をちらちらっとみて、目的に合ったものにアクセスすればOKです。 初心者向けの講座から中・上級者向けまでさまざまなサイトの中から、私は初心者向けの講座のサイトを選び、開いてみました。 さまざまなタグの説明があり、それを順に追っていくうちに、フレームに関する説明が目にとまりました。 「TARGET="_top"」 これはページの移動を行なう際に、一度フレームをクリアするスイッチらしく、この後にフレームが設定されているページに移動すれば問題解決のようです。 早速、「電算導入の歩み」内の戻りボタンにこのスイッチを追加し、うまく動作することを確認してなんとか解決です。 しかし、フレームによる速度低下などの問題とフレームの機能的な良さについては、今後考えていくべき問題のひとつとしてのこっています。 ----------------------------------------------------------- Vol.35まとめ： 1.わからないことはインターネットで。 2.TARGET=でフレーム表示の操作

<<

---

Ｖｏｌ．36　１９９９年4月 サーバーからのメール

差出人がサーバーというメールが、システム管理者である私のところにちょくちょく届きます。 最も多いのがメールに関するエラーを知らせるもので、アドレス間違いや、外部宛のメールを社内のサーバーに送っているなど、単純なミスによるものです。 はじめのころは何もわからず大慌てしていたのですが、何回か続くうちに「またか」といった感じで、すぐに削除するようになりました。 その他に、バックアップをとったログを知らせるものがあります。 当社では、毎朝3：00にサーバーのバックアップをハードディスクにとっていまして、それが完了すると管理者宛にメールがくるようになっているのです。 ある日、私が出社してメールを確認してみると、サーバーからのメールが届いていました。 メールのエラーかバックアップログだろうと思い、受信してみるといつもと様子が違います。 「I/O Error」 私は”Error”という文字には非常に弱く、もう頭の中が大変なことになってしまいました。 とりあえずタバコを一本吸い、なんとか落ち着いたところでもう一度メールを見てみると、”マウントするシステムのタイプを明確にしなさい”というようなことが書いてあるようです。 実際どうしたらいいのかわからない私は、とりあえず思いつくことを片っ端からやってみることにしました。

<<

---

Ｖｏｌ．37　１９９９年4月 HDD認識

「I/O Error」という文字を目にし、とりあえず思いつくことを片っ端からやってみることにしました。 まず、外付けハードディスクを手動でマウントすることにしました。 Linuxの場合、外付けハードディスクなどを参照しようとするときは、コマンドによりマウントさせる必要があるようです。 私はマウントさせる命令を打ち込み、リターンを押すと、やはり「I/O Error」です。 次に、外付けハードディスクの接続を確認しました。 しかし緩んでいる様子は無く、原因はこれではないようです。 私ではなんとも対処のしようがなくなり、サーバーを構築していただいた業者さんに聞いてみることにしました。 すると、以下のような返事が返ってきたのです。 ---------------------------------------------------------- １）シャットダウンし、ＰＣ、ハードディスクの電源を入れ直してみてください。 ２）ファイルシステムのタイプを指定してみてください。 ３）パーティションテーブルがみえるかどうか確認してください。 もし駄目ならパーティションを切り直し、再フォーマットということになります。 ---------------------------------------------------------- 私は2）、3）の内容がよく理解できないまま、とりあえず電源を入れなおしてみました。機械が立ち上がったことを確認し、もう一度ハードディスクをマウントしてみると、きちんと認識しています。 Errorの文字を見てあせり、少ない知識を総動員して対処法を考え、一人で大騒ぎしていた問題もこれで解決です。 後でシステムのログを確認してみたところ、SCSIカードの動作不良が原因らしいということが判明しました。 まずいろいろと試してみるのも勉強のためにはいいかもしれませんが、落ち着いてログを見てみるという作業を、今回の件で覚えたのでした。

<<

---

Ｖｏｌ．38　１９９９年5月 カーネルの問題点

いろいろと苦戦しながらも、なんとか落ち着いてきた様子を見せていた当社のネットワークですが、ある日大変な情報が入りました。 当社で使用しているLinuxのカーネルに問題があるというのです。 それまで、2.0.35を使用していたのですが、問題があるとわかってはそのままにしておくわけにはいきません。 私は早速Linuxのサイトを見てみることにしました。 サイトはすべて英語でしたが、辞書を片手になんとか理解することができ、それによると 「2.0.35はなりすましによる攻撃が弱点となっており、危険度が高いため早急なバージョンアップをすすめる」 ということのようです。 これは大変と思い、すぐにサーバーを構築していただいた業者さんに連絡をとりました。 すると、なんとすでにバージョンアップの準備はできており、私が連絡した時点ではテスト中だというのです。 私は情報収集と対応の早さに驚きました。 ともあれ、早速バージョンアップをお願いすることになりました。

<<

---

Ｖｏｌ．39　１９９９年5月 カーネルバージョンアップ

打ち合わせをして、バージョンアップの日程を５月２７日と決め、サーバー停止の旨をお知らせする原稿を作成しました。 ５月２５日にアップしたお知らせの「メンテナンス」とは、バージョンアップのことだったのです。 サーバー停止のお知らせから２日後に停止では、少々早すぎるかとは思ったのですが、バージョンアップ、特にこの度のような不都合を修正するためのものについては、早いのに越したことはないと判断してのことです。 ２７日、予定通りサーバーを構築していただいた業者さんがお見えになり、バージョンアップ作業をしていただきました。 一通り動作の確認を行なってみても、問題ないようです。 こうして無事、カーネルのバージョンアップを完了することができました。 しかし、今回は前バージョンに問題があるということを教えていただいてから対処するという形をとりましたが、いつもそういった情報が勝手に入ってくるという保証はありません。 やはり自分で情報を収集し、さらには発生した問題への対処も自分でできるようになることが必要であると、強く感じたのでした。

<<

---

Ｖｏｌ．40　UPS

今回はUPSについて書かせていただこうと思います。 UPSとは、ご存知のとおり「無停電電源装置」のことです。 これは、停電時のバッテリーとしての役割はもちろん、落雷などによって異常電圧がかかることも防止します。 当社ではバッテリーを2つ使用しており、説明書によると1つで20〜30分、2つ使用しているので1時間弱は持つだろうと考えておりました。 しかし、実際のところ消費電力が異常に少なく、UPSの自己チェックでも規定外の消費電力量ということでエラーが出るほどです。 このことから、計算によると5〜6時間はもつだろうとのことでした。 今のところ、異常電圧防止のために働くことはありませんし、停電時のバッテリーといっても、そうそう停電するものでもありません。 そう考えると、一見無駄なような気もします。 しかし、Webサーバーやメールサーバーを立ち上げている限り、停電だからといってサーバーが停止するようなことがあってはいけないと思うと、自社でサーバーを立ち上げる際には、ぜひそろえておきたい装置ではないでしょうか。

<<

---

Ｖｏｌ．41　停電対策

前回UPSについて書かせていただきましたが、今回もその辺りに因んだ話題です。 例えば、停電が起きてUPSが働いても、バッテリーが切れる前にサーバーをシャットダウンしなければなりません。 一般的に、他のOSでもそうですが、特にUNIXの場合はいきなり電源を切ってはいけないといわれているからです。 しかし、停電後会社に向かい、シャットダウンができるのも、停電に気づけばこそです。 会社から離れた地域に住んでいる場合や、近くにいても真夜中に停電したため、気づかなかったなども当然考えられます。 そこで当社のシステム課内で持ち上がったのが、停電通知機能でした。 これは、停電がおきてサーバーへの電源供給がUPSに切り替わったら、システム管理者に知らせるというものです。 こういったシステムは実際にあるらしく、非常に便利とは思ったのですが、ちょっとした時間になんとなく話をした程度で、あとは他の作業に追われていたこともあり、具体的な方法や詳細を調べることなく流れてしまったのです。 しかし、これから雷も多くなりますし、前回それに関するような話題を出したこともあって、一度真剣に検討する機会も必要ではないかと思っています。 などと言っている間にも付近で落雷があったらしく、瞬断してしまい、記事を書くのも一時中断しました。

<<

---

Ｖｏｌ．42　1999年６月　WindowsNT

以前、Ｏｗｎｅｒ通信の記事にもありましたように、当社にNTを導入しました。 搬入から設定まで（株）ＪＥＣさんにしていただき、ネットワークのテストです。 このシステムは、CADのサーバーからいろいろな設定を読みこむらしく、しばらく処理をしていたのですが、急にそれがとまってしまい、タイムアウトエラーを起こしてしまいました。 クライアント、サーバーともいろいろ見ていたのですが、原因はどうもネットワークケーブルにあるようです。 当社では、それまで10BASE-2によるネットワークを構築していました。 10BASE-2ではHUB間を同軸ケーブルで接続することになりますが、同軸ケーブルはツイストペアケーブルと比べて、データの転送効率が悪いらしいのです。 そこで、とりあえず窓からツイストペアケーブルを出し、それによってクライアントとサーバーの間をつないでみました。 その状態で再起動すると、設定もきちんと読みこみ、何事も無く起動したのです。 NTを導入してすぐ、その日のうちに新たな課題が発生してしまい、さっそくネットワークのみなおしをすることとなりました。

<<

---

Ｖｏｌ．43　1999年６月　スイッチングハブ

ネットワークを見なおすことになり、まず最初に考えたことがケーブルです。 同軸ケーブルをツイストペアにすれば接続が可能であることは実証済みですので、これはぜひともやっておかなければいけないことです。 しかし、それだけでは社内全体のネットワークに及ぼす影響を考えると、少々不安です。そこで、スイッチングハブを導入することになりました。 スイッチングハブは、データの宛先情報を判断し、その宛先だけにデータを送る装置です。 通常のハブですと、ネットワーク上すべてにデータを流し、送られた側が宛先情報から判断し、データを拾い上げる方式をとっているようで、それだと余計なネットワーク部分にまでデータが流れてしまうため、ネットワーク全体に影響してしまうのです。 早速スイッチングハブを注文し、納品されるまでの対応として、NTマシン〜CADサーバー間をツイストペアケーブルで、つまり10BASE-T方式で接続することにしました。 こうしておけば、スイッチングハブが届いた時点でハブを交換するだけですむ上に、とりあえずですが、NTマシンはサーバーからの設定を読みこみ、立ち上げることができます。 私達は、各部署の協力も得ながら、なんとかツイストペアケーブルの配線を終え、あとはスイッチングハブが届くのを待ちました。

<<

---

Ｖｏｌ．44　1999年６月　ハブ交換

ツイストペアでの配線を終えるとまもなく、スイッチングハブが届きました。 しかし、ハブを交換するには、ほんの少しの時間ですが社内のネットワークを切る必要があったので、すぐに作業に入るわけにはいきません。 そこで、社内のネットワーク利用率がもっとも低くなる時間帯に作業を行うこととし、しかも最小の時間で完了させるために、理論、方法、手順の整理や打合せを綿密にシステム課内で行ないました。 客観的に見れば、たかがハブの交換ぐらいでと思うのですが、そこは「一時切断したことがネットワーク上で気づかれないよう作業する」という、限りなく自己満足に近い目標を達成するには必要な打合せだったのです。 そして、交換作業開始の予定時刻となり、打合せ通り作業を進めます。 一通り作業が完了しテストしてみると、うまく接続されました。 作業が終了したことと、たぶんネットワークが一時切れたことは誰も気づいていないだろうという2つの喜びとともにネットワークみなおし作業の第１段は完了です。 今後、おいおい社内全体の環境を見なおす必要が出てくることでしょうが、その前に今回のNT導入に関わる問題で、早急に解決しなければならないものがもうひとつあったのです。

<<

---

Ｖｏｌ．45　1999年６月　NTのネットワーク

スイッチングハブへの交換を終え、CADサーバー〜NT間のネットワークはつながったのですが、社内全体のネットワークへ接続するための設定も行なわなければなりません。 今のところ、CADネットワークをつなぐために使用しているプロトコル「NetBeoui」だけが設定されているのですが、それではTCP/IPを使用している社内のネットワークにはつながりません。 通常ですと、何度もやっていることなのでなんのことなくできるのでしょうが、今回はNTです。 これまで一度もさわったことがないのです。 そればかりか、下手にいじってCADネットワークの設定を壊してしまうなどの恐れもなきにしもあらずです。 しかし、悩んでいてもしかたがないわけですし、とりあえずネットワークの設定部分を開いてみました。 これまで使用していたWindows95や98と比べると、若干違っているようですが、それでも基本的な部分はほぼ変わり無く、問題はなさそうです。 これならと、まずは一般的にこうであろうと考えるような設定をしてみることにしました。

<<

---

Ｖｏｌ．46　1999年６月　完了

WindowsNTを社内ネットワークに接続するために、まずは一般的にこうであろうと考えるような設定をしてみることにしました。 通常通りにTCP/IPプロトコルを追加し、再起動してみると、難なく社内ネットワークに接続されました。 心配していたCADネットワークも、何事も無かったようで、順調に動作しています。 共有フォルダの見え方が、これまでとは多少違っていたため、若干戸惑った部分もあったようですが、一度わかってしまえばあとは問題ありません。 プリンタの設定も行ない、サーバーにも新マシンの登録を済ませ、各種ソフトウェアのインストールや設定も終了し、これでようやく完成です。 あとは、うまく使いこなせるように使い込んでいただければという思いで、システム課は通常業務に戻ったのでした。

<<

---

Ｖｏｌ．47　1999年６月　メールの許容量

ある日、外部へのメールが戻ってきてしまうという報告を受けました。 こういった話は以前からよくあることなので、まず送り先及び自分のアドレスを確認してもらうことにしています。 その旨を伝えてから数分後、やはりだめだという報告を受けました。 これも以前からよくあることです。 ほとんどの場合、私達がいって確認してみると、どこかしらアドレスに間違いがあるのです。 今回もそのパターンだろうと思ったのですが、どうもそうではなさそうです。 普段と違うところをしいてあげるとすれば、ファイルを添付しているところぐらいでしょうか。 そこで思い浮かんだのがファイルを圧縮して添付送信することでした。 プロバイダによっては、一通のメールの許容量に制限があることを思い出したのです。 もし、送り先のプロバイダで設定している許容量よりも、添付ファイルのほうが大きければ戻ってくることもありえます。 実際、圧縮したファイルを添付送信してみると、うまく送信できたようです。 これからは、ファイルを添付して送信する機会もどんどん増えてくることでしょうし、そういった意識を社内に浸透させる必要性を感じた一日でした。

<<

---

Ｖｏｌ．48　1999年夏　夏のケーブル

少し前のことですが、山形では平気で30℃を超える日が連続したことがありました。 そんなある日の月曜日のことです。 前日、前々日、そのまた前日と平均気温が34〜35℃という状況で迎えた月曜日です。 朝からどうもネットワークの調子が芳しくなく、システム課で原因を探ることにしました。 いろいろ見て回って、どうやら原因はケーブルにあるようなのです。 サーバー付近のケーブルを触ってみたところ、熱を持ってふにゃっとしています。 その上、長さ的にあまり余裕が無く、少々引っ張られているような状態でした。 それで接触が悪くなってしまったと考えたのです。 その部分を修理すると、ネットワークは通常どおりに動きました。 平日は窓をあけるとか冷房をつけるなどによって、いくらか室温は下がるのでしょうが、休みの日ともなれば室内はかなり暑くなるのでしょう。 8月もまもなく終わり、秋がくるという時期ですが、まだまだ残暑が厳しいことと思われます。 これからしばらくはこのような現象もないとも限りませんので、ケーブルには余裕を持たせるなどの対処が必要だと考えるのでした。

<<

---

Ｖｏｌ．49　　パソコン時計

古い話ですが、現在使用しているDOS/V機を導入してまだ間もないころのことです。 最初のうちは、なんの気なしに使っていたのですが、あるとき同じような問題があちこちから聞かれました。 パソコンの時計が大幅に遅れるというのです。 原因が特定できない私達は、おかしいといわれるパソコンのうちの１台と、問題のないパソコンの内蔵バッテリーを交換して、様子を見ることにしました。 すると、いままで時計が遅れていたほうの機械が正常に動作し、正常に動いていたほうの時計が遅れ出したのです。 早速時計が遅れるものの内蔵バッテリーを交換し、問題を解決しました。 パソコンは新品で購入したものですから、バッテリーだけが中古だということはないでしょう。 しかし、保存状況などによっては、新品のバッテリーでも正常な電流を流すことができないものも、中にはあるようです。 皆さんもパソコンを購入された際には、細かい部分にも気を使われてみるのも良いのではないか思います。

<<

---

Ｖｏｌ．50　　Macintosh

当社では、クライアント機の極一部のPC98を除き、サーバーをはじめほぼすべてがDOS/V機です。 そのなかで1台、フル稼働しているMacintoshがあります。 それがデータベースサーバーです。 データベースサーバーは、PowerMac8500/120上で4D Serverを動作させる組み合わせで使用しており、自社開発システムが24時間立ちあがっています。 ある雑誌で見たところによると、「Macはサーバーとして使用するには安定性に欠ける」とのことだったのですが、実際に当社で使用している限りではその片鱗も見せず動作しています。 周波数が***MHzだとかのパソコンの世界からすると、一昔前の機械であるという感は否めませんが、それでも非常に安定してストレス無く使えています。 DOS/V機の導入により常時使われることがなくなったMacintoshでも、これだけのすばらしい機械をなんとか上手に使って復活させたいと、日夜使い道を考えているシステム課でした。

	copyright1998：株式会社朝日測量設計事務所
	ASAHI SURVEY ＆ PLANNING OFFICE CO.,LTD.