2004-10-30 大災害に共通する「慢心」と事故後の企業幹部の対応を考える
2004-02-26 カテゴリー6ケーブルって必要なの？
2003-02-23 高速増殖原型炉もんじゅのナトリウム漏れ事故に見るシステム設計のあり方
2003-01-29 [プロジェクトX]「執念のテレビ技術者魂30年の闘い」裏話
2002-07-25 ADSL対応のCategory 5eケーブル
2002-02-14 正直者はばかを見るのか − 本末転倒な話
2002-01-29 UFJ銀行の失態 - いろいろな意味で、旧三和銀行とはつきあいたくない
2001-08-23 LAN配線の基本−つながればいいというものではない
2001-08-21 そこまで言うか　その2
2001-08-21 そこまで言うか　その1

この記事は、エルネオス誌2004年9月号に掲載された内容です。


　去る8月9日、関西電力美浜原子力発電所３号機で配管が破裂して高温の蒸気が噴き出し、作業員１１人がやけどを負って、４人が死亡、２人が重体、５人が重軽傷という重大事故が起きた。事故の詳細がわかるにつれ、筆者は「またか」という思いを強くしている。

　バブル経済の崩壊した1990年代になってから、日本では重大な産業事故が頻発している。しかも、その原因には必ず共通点がある。「慢心」である。


□ 配管を破裂させたものと生かされなかった教訓

　各社報道によると、配管が破断して蒸気が噴出した部分は、原発の運転開始以来28年間にわたって一度も検査が行われていなかったという。

　今回事故が起きた部分は熱源である原子炉ではなく、お湯を沸かすやかんの方に穴があいたという事故であり、おそらく、放射性物質には直接触れないから重要部分ではないという認識だったのあろう。

　しかしながら、この配管を流れているのは、通常の気圧の10倍の高圧で143℃に加熱した「水」である。しかも破断部位直前には流量計測のためのオリフィスという絞りが配管に挿入されており、流れが乱れている。専門家から見ればこのような部位は配管が摩耗する要注意個所であり、必ず定期的に検査が行われるべき場所である。

　実際、破断面を見ると、10 mm以上の肉厚であったはずの配管が、一番薄いところで1.6 mmしかなくなっている。新聞の写真でも薄さがわかるくらいである。

　検査会社が検査の必要性を報告していたにも係わらず放置したのは、「今まで大丈夫」という慢心から来る、物事の本質を見抜けないで楽な方向に考えていた証拠でもある。

　「日本経済新聞」によると、全く同様の事故が1986年、米国サリー原発で起きていたという。その教訓が全く生きなかった。

　過去の事故の教訓が生きなかった事例として筆者が思い浮かべるのは、2000年3月8日午前9時に中目黒駅付近のカーブで起きた、乗客4人が死亡した地下鉄日比谷線の脱線衝突事故である。事故原因は、「車輪にかかる重量バランスの乱れなど複数の要因による乗り上がり脱線」である。

　事故以前、相互乗り入れしている東横線と日比谷線を利用している筆者が不思議に思ったのは、日比谷線の外側を走る東横線の方が、カーブが緩いにもかかわらず脱輪防止装置が線路に取り付けられており、日比谷線にはなかったことである。実は、東横線で1986年3月13日朝、運用開始から4日の満員の新型電車が横浜駅構内で乗り上がり脱線を起こしている。

　相互乗り入れをしている相手である東急でこういう事故があったにも係わらず、営団地下鉄（当時）は何も対策を講じなかった。美浜原発の経緯と全くそっくりである。


□ 間違った効率重視一人作業が招いた大災害

　企業経営者がてっとり早くコスト削減を考える時、安全に係わることを削るのが一番簡単である。うまく生産ラインや仕事が機能している場合、全く無駄であるように思ってしまうのである。

　しかし、これは車を運転するのに任意保険を全く掛けないのと同じである。重大事故を起こして、初めて「保険」の重要性を思い知る。中国のような、安全無視の競争相手と同じ土俵に上ってはいけないのである。

　工事現場や工場の安全で、基本中の基本は「一人作業をしない。」である。一人では、事故が起きて怪我をした場合、身動きできなくなる可能性があり、二人だと、お互いの判断ミスを牽制しあえるからである。ところが、最近筆者が耳にするのは、現場の作業員の数を減らし、一人作業を強いているということである。実際、工場などの死亡事故は増加している。

　2002年10月1日に三菱重工長崎造船所で発生した豪華客船ダイヤモンド・プリンセスの火災や、2003年9月8日に発生したブリジストン栃木工場の火災は、この一人作業が招いた災害の典型である。いずれも作業員が溶接を行うのに所定の手続きをせず、こそこそと隠れるように作業をして出火した。背景には、効率や納期のみ重視の会社の姿勢にある。いずれも作業届けを出さなければならないのを無視して作業している。

　筆者が製鉄会社に勤めていた頃、会社は現場のブルーカラーのクビを切り、使い物にならないホワイトカラーを温存した。「痛み」が少ないからである。結果、新製品の開発能力は失せ価格競争力はなくなり、業績は悪化した。間違ったコスト削減は安全のみならず、企業の存続を危うくする。

　いくら手順や規則を決めても、それで安全性は確保されない。ISO 9000認証を取得しても、全く関係ない。前述したように規則を無視すれば、とんでもない事故になる。その最悪のケースは1999年9月30日茨城県東海村のJCOで発生した、ウラン溶液の臨界事故であろう。


□ 経営者の顔色を窺う逸脱行為とトラブル隠し

　経営者が間違った効率のみを求めていたら、現場はそのことばかりに気を取られ、逸脱行為を行う。また、トラブル発生となると工場や発電所は停止せざるを得ず、対策を講じるとなると費用がかかる。したがって、現場はトラブルを隠そうとする。

　昨年、それで東京電力は結果として長期間原発を止めざるを得なくなり、リコール隠しを続けた三菱自動車は糾弾された。

　今回の美浜原発の事故でも、記者会見での関西電力の説明が二転三転するのが気になった。破断部分の直前にオリフィスが存在していることすら記者会見に臨んだ責任者は把握していなかった。当初「配管は直線だったので、特に危険はないと思っていた。」と答え、記者からの質問で、携帯電話で現場に問い合わせたくらいである。

　情報が上まできちんと上がっていないことが垣間見える。組織としては危険な状態であり、事実大事故につながったわけである。

　記者会見での発言が変わることほど、事故後の対策としてまずいことはない。事態はどんどん悪化する。リコール隠しでの三菱自動車が好例である。

　今回の場合、関西電力に事故を隠そうという意図は見えないが、正確な情報を記者会見する当事者が把握していないことにより、結果として企業の印象を悪くし、原子力行政全体にも悪影響を与えてしまう。

　しかしながら、今回の事故でひとつだけこれまで事故を起こした企業の対応と明確に違うことがある。関西電力の藤洋作社長本人が、間髪を入れず遺族と患者を訪問し、丁重にお詫びをしている点である。そして顔面蒼白意気消沈した社長の姿がニュース映像となって繰り返し映し出される。

　残念ながら、記者会見に登場する関西電力常務以下の、どこか他人事のような表情とは大違いである。「自分たちの責任ではない」という本音が、ちらちらと顔をのぞかせている。

　このような、これまで何度も不祥事の度に我々が経験してきた白々しさと比べて、藤社長の逃げずに事態を真摯に受け止めている態度は特筆すべきであり、企業の危機管理の範となるものである。

つっこみ 先頭 表紙

この記事は、「Network Cabling」誌2003年8月号に掲載された内容です。

　近ごろ、急速にUTPカテゴリー6仕様のケーブルの敷設事例が増え、個人ユーザ向けのケーブルの発売も発表されている。事実、数年ほど前までは、カテゴリ6のシェアが、影ゴリ5やエンハンスドカテゴリ5（カテゴリ5e）を追い越すとも言われていたし、アメリカやヨーロッパでは普及めざましく、2004年のヨーロッパでは、カテゴリ5eが33%に対して、カテゴリ6が60%に達するという予測もあった。

　しかし、本当にそんなに普及したのだろうか？また、そんなに必要なものなのだろうか。

　配線システムは、ケーブルだけの性能では決まらない。コンピュータとコンピュータを接続する間の、ネットワークインターフェースカード（NIC）やハブ、コネクタ、ケーブルのすべてが条件を満足して、初めて目的の性能を発揮する。その点カテゴリ6はどうなのかというと、私は、現在の状況から言って、カテゴリ5eにとって変わるものとはとても思えないのである。

　UTPケーブルのトップメーカーである通信興業株式会社は、「TSUKOニュースレター」という、配線システムの最新動向を知る上で大変貴重なニュースレターを定期的に無償で発行しているが、その2003年春発行の17号の「カテゴリ6規格の行方−その3−」の記事の中で、カテゴリ6の問題点を以下のように指摘している。


1. カテゴリ5eより部材の価格が高い。
2. コネクタ取り付け作業が煩雑。専門加工工場での取り付けが必要。
3. プラグとジャックの他メーカー同士の組み合わせで相互接続性がない。場合によってはカテゴリ5の規格も満足しない。
4. 配線工事後の現場での性能検査で信頼性が十分に得られない。


　カテゴリ6のケーブルやコネクタがかなり安くなってきたとは言え、まだまだカテゴリ5eに比べると高い。そして、コネクタメーカーが独自技術について特許での囲い込みを行い、互換性を乏しいものにしてしまった。組み合わせによってはカテゴリ5の規格も満足できないなんて、とんでもないことである。さらに、ケーブル自体固く、取り扱いが煩わしい。さらに、施工性も悪く、配線工事後の検査で性能がでなくて、配線工事のやり直しなんてことも考えられる。

　これらはすべてコスト増として跳ね返り、結局ユーザがばかを見るのである。

　さらに、「TSUKOニュースレター」に書かれていない問題点として、カテゴリ6に対応したNICやハブが、ほとんど世の中に存在しないということである。例えば、私が日ごろ使用しているパソコンはギガビットイーサネットに対応しているが、それはカテゴリ5eに対応したNICである。念のため、ネットワーク機器のトップメーカーの1社であるアライドテレシスに問い合わせてみたが、現在カテゴリ6に対応した製品は全くない。当面、カテゴリ6対応製品を発売する予定もなさそうである。すなわち、カテゴリ6のシステムで配線システムを構築しても、結局カテゴリ5eでしか使えないのである。

　そもそも、カテゴリ6という規格が登場した背景であるが、カテゴリ5では、ケーブルの乏しい性能をハブまたはNICを高性能にすることによって通信速度の確保をはかろうとした。確かに、カテゴリ5が普及し始めた当初はハブやNICの値段が非常に高かった。そこで、ケーブルを高性能にして機器の値段を安くしようという意図で制定が始まったのがカテゴリ6である。

　ところがである。カテゴリ6は昨年6月にようやくANSI/TIA/EIA-568-B.2の補遺として正式発行したが、今や、ギガビットイーサネットのスイッチングハブでも10万円を切っている。それに対してカテゴリ6対応の機器はほとんど見られず、もし見つけたとしても、カテゴリ5e対応の機器に比べたら、はるかに高価であろう。しかも、通信速度はどちらの1 Gbpsである。だいたい、1 Gbpsの通信速度で、どれくらいのユーザが使っているのであろうか。

　それでも、カテゴリ6の方が伝送帯域がカテゴリ5eの62.5 MHzに対して250 MHzまで保証されているので、余裕を持って使えると言う人がいるかもしれない。しかし、前述の「TSUKOニュースレター」の問題点を読み返していただきたい。いくらケーブル自体の余裕があっても施工段階で全然余裕はなく、プラグとジャックの相互接続性の問題もあるのである。また、カテゴリ5eは1 Gbpsの伝送を保証したシステムでもある。カテゴリ6のケーブル自体の帯域の余裕は、意味がないのである。

　カテゴリ5eと同じ伝送方式を使ったとすると、カテゴリ6の性能ぎりぎりでの伝送速度は4 Gbpsになる。しかし、250 MHzすべてを使い切るということはまずあり得ないから、200 MHzとしてせいぜい3.2 Gbpsがいいところであろう。この程度の増速しか見込めないのであるのなら、次は光ケーブルを使って10 Gbpsをめざすというのが自然ではなかろうか。Lucinaのような、取り扱いしやすいプラスチックファイバーケーブルも登場しているのである。

つっこみ 先頭 表紙

　1995年12月8日、高速増殖原型炉もんじゅにおいてナトリウム漏れ事故が発生した。少々古い話であるしIT業界とは直接関係ない話のようにも見えるが、この事故には、IT業界にも通じる設計上の錯誤があった。どのような過程を経て設計ミスがあり事故につながったのか、解説する。

　事故の概要は、もんじゅの２次系中間熱交換器出口配管からナトリウムが漏えいし、火災を起こしたというものであった。配管に取り付けられているナトリウム温度計の保護管（さや管）の細管部が折損し、そこから漏えいしたのである。

　まず、もんじゅでなぜナトリウムを使っているのかについてである。

　「もんじゅ」では、原子炉の中で発生した熱を取り出す役割をもつ「冷却材」に金属ナトリウム（一般的な軽水炉は水）を使っている。金属ナトリウムは常温では銀白色の柔らかい固体で、98℃で液体になる。液体ナトリウムは次のような性質から冷却材に採用されている。

1)温まりやすく冷めやすく、よく熱を伝える（水の１００倍の熱伝導率）。
2)中性子の速度を減速させず、吸収も少ないので効率のよい高速増殖炉ができる。
3)高い温度（約880度）まで沸とうしないので、軽水炉のように圧力をかける必要がない。

　このような性質により、冷却剤としてナトリウムを480℃に加熱して使用している。

　しかしながら、金属ナトリウムは不安定な物質で、温度が高い液体ナトリウムが空気にふれると酸素と反応して黄色の炎をあげ白煙をあげて燃える。また、水にふれると激しく反応して水素を発生し、水素が空気中の酸素と反応して爆発することもある。すなわち、水や蒸気、空気にふれないようにしなければならない。

　今回の事故では、漏れたナトリウムが空気と反応し、火災を発生した。

　温度計破損の原因であるが、配管内を流れるナトリウムの流体力により、さや細管部に流力振動が発生し、さや段付部に高サイクル疲労が生じ、破損に至ったと判断されている。流力振動とは、流れによって渦が生まれ、渦のもたらす効果で棒が振動する現象のことである。メーカーの温度計さや管の設計に問題があったためとなっている。

　以上が、ナトリウム漏れ事故の概要である。詳しくは核燃料サイクル開発機構の以下のページにある。

　http://www.jnc.go.jp/zmonju/mj_acci/mj_accipanf/accipanph.html

　さて、核燃料サイクル開発機構のページではメーカーの設計ミスについて詳細に触れられていない。また、根本的なところも抜け落ちているような気がする。ここからは、筆者の推測であるが、以下のような過程で設計ミスが起きたと考えている。

　もんじゅでは、固体の金属ナトリウムを加熱して液体にし、冷却剤として配管の中を循環させている。もしも、ナトリウムの温度が何らかの理由で下がったらどうなるであろうか。部分的に固化し始め、どろどろになると予想される。すなわち、粘性流体となる。粘性流体が流れる配管に温度計を取り付ける場合の常識として、配管に直角に取り付けるのではなく、流れの下流方向に45度傾けて取り付ける。川面に柳の枝が触れているのを想像すればわかると思う。こうすることによって、流体力による温度計の保護管への負荷を軽減する。

　このように、設計段階で対象プロセスに発生しうる現象を想定すれば、温度計を45度傾けて取り付けるという設計になる。核燃料サイクル開発機構の原因解析によると、「温度計さや管に挿入されている熱電対は、さや管の振動を減衰させる効果があるが、保護管に温度計を不適切に挿入したためにその効果が小さかった。」となっている。どうもこれは、温度計を45度に挿入しなかったということを差しているようでありが、「小さかった」などというものではない。根本的に間違っていたのである。

　この温度計の設計者は、ナトリウムが480℃の温度で流れるということしか頭になかったようである。当然、設計段階で与えられるプロセス情報は正しくプロセスが動いているときだけである。しかしながら、エンジニアはそこから想定されるトラブルを含めたあらゆる現象を考え、それを設計に盛り込んでいく。当然、「ナトリウムの温度が下がってしまったらどうなるか。」ということを考えなければならない。

　通常、プラントの設計では、設計者のほか、確認者、承認者と3段階でチェックが入る。それも、機能していなかったようである。停電したらどうなるか、ポンプが故障して流れが配管の中で止まったらどうなるか、ナトリウムが配管から漏れたら周囲はどうなるか、温度低下以外に想定しなければならないトラブルは、ざっとこれだけある。いったいどれだけのことが設計段階で折り込まれたのであろうか。これは、フェイルセーフの設計の基本でもある。

　想定されることをできるかぎり折り込んで設計する。これは、プラントではなく情報システムでも全く同じことが言える。それは、トラブル対策ではなくて使い勝手にも大きく影響する。例えば、金融機関のATMでパスワードを入れ間違えたとしよう。そこで、取り消しキーを押していちいち最初の手順に戻るのか、その場でパスワードのみを削除して入れ直すのかによって、利用者の使い勝手は大きく変わる。これも、利用者がパスワードや金額を間違えたらどうするか、きちんと考慮してシステム設計に反映するかどうかの問題である。プログラミングする立場からすれば最初に戻してしまう方が楽であるが、利用者の立場であれば、いちいちそんなことをされたのでは使いにくくてしようがない。

　どれくらい起き得るトラブルを想定できるか、利用者の操作方法を想定できるか、想定外のトラブルが発生した時にどうするべきか、システムの設計段階でできる限り考えておく。それは、もんじゅのようなプラントであろうが、情報システムであろうが全く同じなのである。

※その後の関係者の話では、やはり内部的には本来45度傾けてつけるべきさやを直角に取り付けてしまったということが事故原因であるという認識である。(2004.3.15)

つっこみ 先頭 表紙

　本日のプロジェクトXはテレビ放送50周年記念番組であった。この番組に関連して、我が父から聞いた話を元に、裏話をふたつほど書いてみたい。


その1　電々公社との確執

　番組の中で、テレビ放送の中継システム開発を担当したのは東芝であり、東京から大阪までのマイクロ波での中継を担うことになったことが紹介された。

　東京から大阪まで、マイクロ波で中継するには、途中中継所が必要になる。中でも三重県霊山の中継所は人里離れたところにあって電源が確保できないために、大変苦労することになる。東芝技術陣は巨大な自家発電装置を山頂に担ぎ上げ、無事中継にこぎ着けることに成功した。

　番組では、マイクロ波中継システムが完成してめでたしで終わっている。ところがである。この霊山の中継所も含め、NHKが東芝に発注して構築したマイクロ波の中継システムは、数年のうちに撤去させられている。

　電々公社から横やりが入ったのである。

　マイクロ波での中継システムは、これは通信であって電々公社の範疇である。したがって、NHKごときがマイクロ波の中継システムを構築してはならんと。ここでふざけた話なのは、電々公社には東京、大阪間にマイクロ波回線の建設予定がなかった。そのために、NHKは、テレビを1日でも早く普及させるために、新技術で自営回線の建設に踏みきったのである。そこに、法律を盾に横やりを入れたのである。

　ということで、電々公社が日本電気に発注したマイクロ波の中継所を建設するまでNHK独自のシステムは存続するが、電々公社のシステムが完成したところで、東芝が納入したシステムは廃棄となったのである。電々公社のシステムは1956年（昭和31年）に完成したと見られるので、1953年1月開通から3年ほどしか使われていない。要するに、マイクロ波回線網を作って儲かることに、電々公社はテレビ放送が始まってから気が付いたのである。

　結局、我々の知らないところで、受信料の無駄遣いをさせられたのである。それも、NHKのせいではなくて。

　今、インターネットの登場で、通信と放送の垣根がなくなり融合していくのが現実となっているのを考えると、信じられない話である。電々公社は壁を作って、囲い込みをやったのである。このことは、テレビ局、特に東京キー局の関係者がインターネットの可能性について全く疎いことにも影響を及ぼしてしまったようにも考えられる（「テレビ局がつぶれる日」読売テレビアナウンサー脇浜紀子著 東洋経済新報社 ISBN4-492-97023-1 参照）。

　電々公社はインターネットの草創期にも邪魔をしている。「音声信号以外、電話線を利用してはまかりならん。」ということを言ったのである。もっとも、法律で当時禁止されていたわけではあるが。すなわち、我が友村井純がインターネットを初めて日本で構築した時、彼は法律違反をやっていたわけである。彼の最大の功績は、技術的なことも去ることながら、何と言っても電々公社の官僚主義に風穴を開けたことである。

　以後、NHKの全国放送網は、電々公社のマイクロ波の中継システムを使用することとなる。NHKが電々公社に対して恨み骨髄であったことは、想像に難くない。BS放送開始に当たっては、電々公社からフリーハンドで全国放送が可能になったわけであり、今振り返ってみると、当時のNHKの不自然なほどの入れ込みようは、こういうことが背景にあったのではないだろうか。


その2　田中角栄の功績

　テレビと田中角栄と何の関係があるのだろうかと思われる諸兄も多いであろう。ところが、関係大ありどころではないのである。

　テレビ放送が始まったのが1953年（昭和28年）2月1日、田中角栄はその4年後の1957年（昭和32年）7月に、39歳で郵政大臣に就任している。当時、テレビ局はNHKが全国に11局、民放が1953年8月に日本テレビが開局して、このときまでに日本テレビを含め、ラジオ東京（ＴＢＳ）、北海道放送、中部日本放送、大阪テレビ（朝日放送）の５局にすぎなかった。しかしながら、テレビ放送の活況を見て、郵政省には全国から放送局免許申請が殺到していた。

　当時、郵政省は一括大量免許に慎重な立場であった。理由は技術的にも経営的にも時期尚早と考えていたからである。ところが、田中角栄はこの考え方を一発で引っくり返してしまう。調整に努め、就任から4か月後の1957年10月に34社一括の予備免許が交付される。これら予備免許を受けた各社は、58年（昭和33年）13社、59年（昭和34年）20社と、開局ラッシュを迎えることとなる。この時、現在の日本のテレビ放送の骨格が出来上がる。

　このときの一括大量免許交付において、田中角栄はかなり強引なことをやっている。また、金権政治に結びつくようなこともやっている。そのためにかなりネガティブに捉えられているが、テレビの持つ将来性を田中角栄は間違いなく理解していた。そして、現在の状況も彼は予想していただろう。やり方は強引であったかもしれないが、短期間に大量免許交付を可能にするには、彼のような人物がいない限り絶対まとまらず、結果として免許がおりなかったのは間違いない。それだけ、日本はテレビ後進国となりかねなかったのである。

　今現在、低俗な番組も確かにあるが、多種多様なテレビ放送を我々が享受できる礎を築いたのは、間違いなく田中角栄である。



参考にしたURL
http://www.nhk.or.jp/strl/aboutstrl/evolution-of-tv/p09/column/index3.html
http://www.center.or.jp/about%20us/aboutdate/born.html
http://www.aa.alpha-net.ne.jp/mamos/rvw/kakuei1.html

つっこみ 先頭 表紙

　数日前，パソコンショップに行ってUTPケーブルを買おうとして，パッケージを見てぶっとんだ。

　曰く，「ADSL対応ケーブル」とある。全く，IT業界の虚構を象徴しているような表示である。

　まず，Category 5eのUTPケーブルとは何かである。

　LAN(Local Area Network)で市場をほとんど制したのはイーサネット（またはIEEE 802.3）であるが，現在その配線はUTP(Unshielded Twist Pair)ケーブルを使うのが主流である。電話用のモジュラケーブルを太くしたようなケーブルで，このケーブルでハブやパソコンを接続する。最初に登場したときは10 Mbpsのスピードに対応しており，10BaseTと言われていた。ケーブルはCategory 3と言われていた。そして，ケーブルをちょっと太くしてCategory 5ケーブルが登場し，100 Mbpsまで対応できるようになった。この規格を100BaseTXと言う。そして現在はCategory 5の性能を拡張したEnhanced Category 5，すなわちCategory 5eケーブルが登場し，1000 Mbpsすなわち1 Gbpsに対応できるようになり，この規格は1000BaseTと呼ばれている。つい最近までパソコンショップで売られている，モジュラプラグが取り付けられたパッチケーブルはCategory 5が主流であったが，最近はこのCategory 5eケーブルが増えている。

　一方，ADSLであるが。

　これは従来から使われている銅線の電話線を使って，高速でデータ通信を行うための方式である。ADSLは従って，WAN(Wide Area Network)の規格である。当然，イーサネットとは方式が異なる。一般的には普通の電話線にADSLモデムを接続し，信号を変換してパソコンに直接，またはイーサネットを介してパソコンに接続する。すなわち，Category 5eのUTPケーブルはイーサネットのためのものであって，一般的にはADSLには使わない。そりゃADSLモデムを介せばイーサネットにつながるからADSL対応とは言えるが，誤解を与える表現である。

　さらに，高速と言ってもADSLはせいぜい8 Mbps，良くても12 Mbpsのスピードしかない。あくまでも，ADSLが登場するまでは64 Kbpsしかスピードが出なかったことに対して「高速である」というだけなのである。しかもなぜ「非同期」なのかというと，プロバイダからの信号はこのスピードだが，逆方向はせいぜい512 Kbpsしかスピードが出ない。すなわち，Category 5eケーブルにADSL対応なんてわざわざ謳わなくても，従来のCategory 5ケーブルでおつりが来る性能である。いや，今はほとんど見ないが，Category 3でも十分なのである。

　まったく，相変わらず良くわかっていないお客につけ込むような商売が横行している。さらに，Category 5e対応でADSLは10 Mbpsも出ていないのに1000 Mbpsのハブとかカードを購入したとしたら，過剰投資もいいところである。もちろん，わかっていてLANのスピードを上げたいというのなら話は違うが。

　「ADSL対応のCategory 5eケーブル」なんて袋に書いてあったら，このケーブルを使わないとADSLは使えないと思うではないか。

　基本的なことをきちんと調べることが如何に重要か。そうでないと，すぐだまされてしまう。
　

つっこみ 先頭 表紙

　またまた本末転倒な話である。

　本日夕刊各紙で結構でかく掲載されていたからご存知の方も多いであろう。記事の概要は以下の通りである。

　宇宙開発事業団のシステムを共同受注したNEC東芝スペース社と三菱電機のうち、東芝スペース社の社員（社員A氏(仮名)）が本来見ることのできない三菱電機のシステムにパスワードを類推してログインを試みたら、入れてしまった。慌てたこの仮名社員A氏は、情報管理に問題があるという内容のメールを、事業団関係者らに送付した。

　それで、どうなったか。

　NEC東芝スペース社は不正アクセス禁止法に違反したとして、1か月の指名停止処分とした。

　この顛末を読んで、皆さんはどう思っただろうか。口車にいわせれば、これは本末転倒である。あくまでも新聞の記事によることであるが、やばいと思って報告したこの社員A氏(仮名)が、あまりにもかわいそうである。しかし、口車のこの見方は間違っていないであろう。

　目の前にログイン画面があり、ではこのシステム本当に入れないかと試してみるのは、システム屋としては人情である。それでなにげなく試してみたら、入れてしまった。ということは、クラッカー（悪意のハッカー）にアタックされたらひとたまりもない。そこで社員A氏(仮名)は報告した。

　もしも社員A氏(仮名)が報告しなかったとしたらいったいどうなっただろうか。おそらく、そのうちもっととんでもないことになっていただろう。しかも、優秀なクラッカーは痕跡を残さない。システムに不法侵入されて気がつかないうちに情報を盗みだされる。そこで、この社員A氏(仮名)は報告したわけである。

　しかし、社員A氏(仮名)と彼の所属する会社は処分された。ということは、もしもこういうセキュリティの穴を同じように見つけたとしても、だれも報告しなくなる。すなわち、セキュリティホールはいつまでも閉じられることはない。宇宙開発事業団のとった行動は、セキュリティという観点で最悪のことをやったのである。

　しかも、こういうまぬけなというか、なにもセキュリティのことを考えなかった宇宙開発事業団の職員または三菱電機の社員は、処分を受けたとは書いていない。こういうパスワードを設定、というかおそらくデフォルトのままでなにもしていなかったのだろうばか野郎どもこそ処分されてしかるべきである。

　こんなことをやっているから、ロケットがまともに飛ばないのである。おそらく、この記事は外電として世界を巡るであろう。そして宇宙開発事業団は、システムの本質を全く分かっていない組織として、いい物笑いとなるであろう。

　そして、そんなところに衛星の打ち上げを頼むところはないのである。

先頭 表紙

　案の定である。

　アフガンNGO締め出し事件と雪印食品の事件で目立たなくなってしまっているが、UFJ銀行が、銀行としてはあるまじき大失態をやった。


　さる1月15日、日経BPのサイトに以下のようなニュースが流れた（日経コンピュータ）。

　三和銀行と東海銀行の合併によるUFJ銀行が1月15日に誕生し，両行の既存システムを統合した新勘定系システムを無事，稼働させた。UFJ銀行の寺西正司頭取は，「合併と同時に稼働した新システムは，コスト削減という統合効果を先取りするものだ」と胸を張った。合併する都銀同士の勘定系システム統合を，新銀行発足までに完了したのは，国内で初めて。


　はて、合併した新銀行発足までに合併する都銀同士の勘定系システム統合を完了させることが、そんなに重要なことなのだろうか？銀行を使う立場からすれば、窓口で同じようにお金が扱えて同じサービスを受けられるのであれば、中がどうなっていようと関係ない。確かに、三井住友銀行合併でJCBカードの扱いが旧さくらと旧住友で異なるが、そんなことは枝葉であり、知っていればどうっていことはない。むしろ、合併によるごたごたでへんなことになるより、今動いているシステムを少しずつくっつけていって、安定運用してくれるほうが、なんぼか重要じゃないの? 事実、三井住友銀行は合併してそろそろ1年になるがシステムはまだ統合し終わっていない。でも、問題なく動いていれば、そんなことはどうでも良い。


と、この記事を読んだとき思った。本末転倒であると。

　新銀行発足までにシステム統合を完了させたということは、先を急がせたということである。中身はどうでも良い、とにかくUFJ銀行発足の日に、頭取がかっこ良く「同時稼働した。」と言いたいということが目的となり、勘定系システムでもっとも重要な「金額を間違えない。」というリスクマネージメントがないがしろにされたのではないだろうかとも思った。

　そして、どうなったか。

　口座振替がべたべたに遅れ、支払先の企業から利用者に「支払っていない」という文句ががんがんくる。また、企業の方は「なんで支払いがないのか！」となった。さらに、口座から二重にお金を引き落としてしまうという、とんでもない事態まで加わった。

　1月28日付けの同じく日経コンピュータの記事に、事の顛末が詳細に記されている。以下は、その抜粋である。


　口座引き落とし処理の遅れは，「口座振替システム」の不具合や処理の不手際があったために発生した。具体的には，口座振替システムで実施した引き落とし処理の結果を，電力会社やクレジット・カード会社ごとに自動集計するシステムの処理や，磁気テープやフロッピ・ディスクに格納する人手の処理が遅れた。この結果，1月25日までに合計175万件の引き落とし処理が遅れたうえ，電力会社など約1500社の取引先に対して，処理結果を正常に引き渡せなかった。

（中略）

　ところが，UFJ銀行が発足した翌日の1月16日に，引き落とし処理結果の自動集計に約2時間程度の遅れが発生。これがきっかけとなり，磁気テープに処理結果を格納したり，翌日分の引き落としデータを作成するなどの工程に次々と遅れが出た。そしてこの遅れを取り戻すことができず，1月23日，ついに約45万件の引き落とし処理が間に合わなくなった。引き続き24日には20万件，25日には110万件の引き落とし処理に遅れが出てしまった。



　ここまでの文面で、システム切換えに伴う、事前のトレーニングを何も行っていなかったことが伺える。1月15日にシステム稼働を間に合わせることのみに時間を割き、システムエンジニアが教育に時間を割けなかったことが、容易に見て取れる。

　さらに、


　一方，今日明らかになった二重引き落としと引き落とし漏れの原因は，口座引き落とし処理の遅れを解決する際に犯した人為的なミス。被害件数は，それぞれ二重引き落としが約18万件（約28億8000万円分），引き落とし漏れは約5000件。このうち二重引き落とししたものについては，すべてのデータを取り消すことで対処する。引き落とし漏れについては，電話会社やクレジット・カード会社などと相談して，再引き落としなどの処理をする。



　もう、「ばかか！」と言いたい。べたべたに遅れたものだから、とにかく目先の処理をと、手動でシステムを動かしたことが見て取れる。


　結局、このシステム構築のプロジェクトは「頭取」しか見ていなかった。そして、コンピュータでなんでもかんでもやれば人件費がかからず、コストダウンできるなんて、安易な発想を取った。銀行の勘定系システムで一番大事なことを完璧に忘れていたのである。

　コンピュータシステムというのは、安定して動かすまでには大変な人手を食う。したがって、一時的にコストアップになる。おそらく、そんなことも理解できずに、人件費も抑制したのであろう。

　さらに予想するに、こんなばかげたプロジェクトを計画した経営者は、末端の直接の担当者の中間管理職に詰め腹を切らせて、自分たちの犯した「犯罪行為」に対して全く無自覚であろう。

　こんな、金融機関としてイロハのイの字もできないような銀行に、だれが安心してお金を預けられるであろうか。こんなお間抜けな銀行に口座を持ち続ける気は、不肖口車、さらさらない。

　話は変わるが、元々、会社を設立した時に旧三和銀行をメインバンクにしようとした。しかしながら、会社設立1年後に融資係の担当者が変わったときに挨拶しに行ったら、いきなり新融資係の入社2年目の若造のくそ○か（おっとっと）にこのように言われた。

　「うちの銀行は、お宅みたいなちっぽけな会社を相手にするような、ちんけな銀行ではありませんから。」

　即座に、口車は動かせるお金は全部たの口座に動かし、引き落としで動かしようのないものだけ最低限の金額しか置かないようにした。それだけでは怒りはおさまらない。口座がからになっても、そのまま口座を放置してある（こうするだけでも、経費かかるのね、にひ）。

　すでに、当時から今回の大失態につながる体質は持っていたのである。今、日本経済がなぜ不調なのか、その根本原因を端的に表したお粗末である。

先頭 表紙

　この記事は、オーム社発行の「エレクトロニクス」誌の、2000年12月号に連載された記事を、再録したものです。


　近年、パソコンの高速化、携帯電話等の登場によって、EMC・EMI（電磁両立性・電磁妨害）への関心は高まっている。回路設計者にとっては、切実な問題であろう。しかし不思議なのは、日頃EMC・EMIに敏感な技術者も、使っているパソコンLANの配線に対して、あまり関心が払っていないのではないか。その証拠に、配線についてきちんと解説した文献を、ほとんど見ないし、ネットワークのトラブルで、配線が原因であるという議論を、まず見たことがない。

　最近のLAN配線の主流は、RJ45コネクタを利用したUTPケーブルによる配線で、簡単に配線できるようになった。簡単に配線できるのではあるが、この配線方式、実に微妙なバランスの上に成り立っている。しかも、最近は1Gbpsという高速通信をもUTPケーブルで行うようになり、62.5MHzという高周波を扱う。100Mbpsでも、31.25MHzの周波数帯で動作しており、神経質に扱わなければならない。

　ところがである。「つながっていればいい」という程度の安易な考え方で、性能を発揮できない、ひどい配線が多々見られる。プロの工事業者ですら、平気ですごいことをやる。最近100Mbpsが主流となりつつあるが、100Mbpsのつもりが10Mbpsしかスピードが出ていないということもざらなのである。秋葉原辺りへ行けば、ケーブルもモジュラも、圧着器も購入でき、自前で配線することができる。しかしながら、10Mbpsまでだったら簡単な導通テストで大丈夫であるが、100Mbpsでちゃんと性能を出そうと思ったら、そうは簡単に行かない。

　いいかげんな施工をやると、問題になることは2点ある。クロストークとインピーダンス不整合による信号の反射である。どちらも、EMI（電磁妨害）の基本的なトラブルであり、イーサネットの基本的な動作原理、配線の規格と施工方法の基本をきちんと把握しておけば、防げるトラブルである。

　まずクロストークについて考えてみたい。UTPはUnshielded Twist Pairの略であり、遮蔽をしていない。したがって、外部からのノイズに弱い。また、各対の撚りによってクロストークを押さえている。この2点をケーブルの特性として理解しなければならない。ケーブルの周辺にノイズの発生源となるものを近づけないようにしなければならないし、極力撚りをほどかないようにしなければならない。またモジュラへの心線の取り付けの位置も決まっている。

　外部からのノイズの発生源として、意外な盲点は蛍光灯である。最近はインバータ式が主流であり、実はものすごいノイズの発生源でもある。天井裏の配線で、蛍光灯の上をケーブルが通らないようにしなければならないはもちろん、卓上の蛍光灯についても気をつけなければならない。

　初歩的なミスとして最も多いのが、ケーブルをモジュラに取り付けるときの端末処理である。まず撚りをほどきすぎる。心線の端から20mmもほどいてはいけない。心線をモジュラに取り付けるのがつらいくらいでちょうどよい。またよくやるミスは、モジュラへ撚り線を取り付けるとき、端から順次心線を差してしまうことである。これらのミスをやると10Mbpsの通信はできるが、100Mbpsになるとせいぜい10mくらいしか通信できなくなる。また圧着不足も気をつけなければならない。

　次に、インピーダンス不整合についてである。イーサネットは、1本のケーブルを複数の端末で共有する。いずれかの端末が通信している間、他の端末はその通信が終わるまで待っている。しかし、インピーダンス不整合により信号の反射が起きたらどうなるか。いつまで経ってもだれかが使っている状態だから、次の端末は通信ができない。すなわち、通信の実効速度は極端に落ちる。

　では、どういう場合にインピーダンス不整合を起こすかであるが、ケーブルの直角曲げ、結束線での締めつけすぎ、机の脚で潰すといったことがある。工事業者がやるミスで大変多いのは、ケーブルの直角曲げと結束線での締めつけ過ぎである。電話線の場合、壁や柱に沿わせて直角にケーブル曲げるという施工をよくやる。ところが、イーサネットのUTPケーブルも形状が似ているため、同じように施工してしまう。しかし、前述したように、イーサネットは扱う信号の周波数がはるかに高い。電話線と同じ施工をしてはいけないのである。ケーブルの曲げの許容範囲は、ケーブル直径の5倍である。また結束線の締めつけ過ぎもインピーダンス不整合点となるが、これもよく見受けられる。ケーブルを机の脚で踏んづけるということは、室内の配置変更の時に要注意である。

　このように書いてみると、本紙の読者にしてみれば極めて基本的な事項でしかない。しかし、自分の周囲を見回してみて、どれくらい守られているであろうか。

先頭 表紙

　この記事は、ニューズ社発行の「Network Cabling」誌の、2000年8月号から2001年7月号まで連載されたコラムを、再録したものです。


目次
- なんてレベルが低いんだ
- だれだ、こんなことやったのは
- プロジェクトリーダーとしての大学教授
- 「システム」とはコンピュータのことではない
- それでも動く
- いかにしてシステム管理者は育つか
- ああ、勘違いの現場監督

　（つっこみへ）


●　ああ、勘違いの現場監督

　情報システムにおいて、システム管理者はユーザーの立場でのキーパーソンである。前節において、そのシステム管理者はどのようにして育つのか、説明した。本節ではその対極にある、システム設置のキーパーソンである現場監督について考察してみたい。

　情報システムにおいて構成要素はいろいろあるが、何がいったい一番重要であろうか。アプリケーションも重要であるが、もっとも重要なのは配線である。なぜなら、配線は一度設置してしまうと見えないところにあり、簡単には手直しできないからである。この配線の工事品質が、情報システムの性能を大きく左右する。いくら高性能のサーバやルータを導入しようが、配線がいい加減ではその性能は発揮できない。言い換えれば、限られた予算の中で配線工事費は、一番削ってはいけない項目である。予算がなかったらサーバやルータと行った機器の予算を削るべきである。

　さて、本題に戻ろう。

　高品質の配線工事を行うには、当然高い技術を持った職人の存在が不可欠である。しかし、これは必要条件であって十分条件ではない。いくら職人のレベルが高くても「段取り」がしっかりしていないと、ひどい工事になってしまう。

　この「段取り」は、配線工事と合わせて機器の設置作業においても大変重要である。情報システムというのはたいていそうであるが、限られた時間の中で工事や作業を終了させ、いち早く立ち上げなければならない。ましてや、現在稼働中のシステムにおいては、極力作業時間を短くしてシステムが停止している時間を最小限にするのは、絶対条件である。効率良く短時間に作業を行うための段取りは、それだけ重要なのである。

　段取りを決めるのは現場監督である。裏返せばそれだけ現場監督の仕事は重要であり、情報システムの品質を左右する。

　段取りにはふたつの要素がある。

　ひとつは、事前の準備である。事前の準備として、以下の項目がある。

・図面はきちんとしているか。
・作業範囲は確認されているか。
・チェックリスト等の帳票は準備されているか。
・全体の工程はまとまっているか。
・工程に見合う要員は確保できているか。
・機材や材料は確保されているか。
・入構許可等の手続きは済んでいるか。
・電源等は確保されているか。
・同時作業の他業者との調整はできているか。
・作業員の安全は確保されているか。
・関係者に、事前の注意事項の連絡はいっているか。

　ふたつめの要素は、工事や作業が始まってからの対応である。以下の項目がある。

・作業場所への入構手続きと顧客への挨拶。特に守衛に対して。
・始業時ミーティングによる作業確認。
・構内業者および同時作業の他業者への挨拶と作業確認。
・職人のやる気を引き出す的確な作業指示。
・トラブル発生時の臨機応変の対応。
・終業時ミーティングによる作業確認。
・小銭の用意

　これらの項目が有機的に機能して、質の高い工事及び作業が実行される。特に、工事及び作業が始まってからの現場監督の対応いかんによって、決定的に決まってしまう。

　ところで、ここにあげた項目の最後の「小銭の用意」とはなんのことかと思われたかもしれない。「小銭の用意」だけでピンと来た読者は、現場監督として優秀である。休憩の時に自動販売機に走って缶ジュースを買ってきて差し入れをする。しかも自腹であることが肝要。こんなちょっとしたことで、職人はやる気を出すものである。現場監督に必要な能力は、段取りの良さと気配りである。加えて、何かあったときの責任は全て自分が取るという胆力であろうか。

　この記事の事例1で、現場監督の経験がない現場監督の話を書いた。確かに現場は混乱したが、何がまずいのかを具体的に帳票で示した途端、その彼は的確に現場監督の職務をこなしてくれるようになった。どうするべきかを吸収してくれたのである。ところが、いい年をして経験も豊富なはずの現場監督が、信じられないような対応をする。いい年をしているだけに、始末が悪い。


事例6

　今から4年前のある日、仕事でお付き合いさせていただいている大手工事会社（以下D社）から筆者のところへ電話が入った。ある金融機関のオフィス移転作業で、パソコンとサーバの移設設定作業も請け負っているが、1か月後には引っ越しが始まるのに、まだ何も手順が決まっていないという。作業量は、毎週末約1000台のパソコンを設定し、それが6週にわたる。しかも、元請けのSI業者と実際にパソコン設定作業を行う下請け業者の関係が、こじれてしまっているという。この状態をなんとかして欲しいという依頼だった。準備期間はあと1か月を切っていて、6000台に近いパソコンの設定である。しかも、都内4箇所に分散しているオフィスからの移転という。結局請けたのであるが、お手伝いするかどうか筆者は考えてしまった。

　このプロジェクトの場合、元請けのSI業者のプロジェクトマネージャー（以下PM）が現場監督ということになる。実際に会って話をしてみると、やたら調子が良い。続いて、お客との打合せ兼現地調査で設定作業を行う業者の責任者（以下Mさん）と会い、これまでのいきさつを聞いてみる。そして、なぜこじれたか、理由がはっきりする。

　前回、Mさんはお客との打合せがあるというので、初めてお客のオフィスを訪問し、入口でPMと待ちあわせた。そして、PMからいきなり怒鳴りつけられた。

　「おい、なんだ、その襟のバッジは。なんでそんなものつけているんだ。今回はうちの会社の仕事なんだから、自分の会社のバッジははずしてこいと言っただろ。すぐはずせ。」

　Mさんはその時点でかちんと来てしまった。彼は、というか彼の会社は、そんなこと何も聞いていなかったのである。どこで連絡ミスがあるかわからないのだから、こういうときは、「あれ、話聞いていなかった。悪いけれど、バッジはずしてくれない。」とやるべきである。さらに、その時はお客との初顔合わせであり、また、指示通りにパソコンの再設定を行うだけと聞いていたのに、いきなり作業手順書の作成をその場でやれとやられた。お客からも作業対象のパソコンの一覧表を受け取っておらず、全体の作業量すら把握できないでいたことも加わり、Mさんすっかり頭に来てしまった。「全く話が違う。」ということで、作業をいったん止めてしまったのである。

　この時点で、このPMは失格である。もっとも、作業が滞っている理由ははっきりしたから、解決する算段はつく。Mさんの会社の信頼を回復するとともに、お客から必要な情報を得ることである。しかし、そんなことだったら何も筆者に頼まなくても、依頼してきたD社の中にもそれくらい解決できる人材はいる。ところが、運悪くこのプロジェクトの担当者が「はずれ」だったのである。そうなると、D社が筆者に電話をかけてきた理由が見えてくる。ある意味筆者は第三者であり、そういう立場でなければ折り合いがつかないところまでこじれてしまっていたのである。

　筆者がMさんの会社の信頼を得るために、まず筆者は打合せのたびに必ずM
さんの会社まで出向いた。実際の作業手順書作成の担当者は若いKさんであったが、絶対見下さず、「打合せに出てこい。」と横柄な態度もとらなかった。当時Mさんの会社は、新宿の区役所通り奥の、新宿駅から歩いて15分のラブホテル街の隣り合わせという、なんともはやなところにあり、暑い最中、パソコンをかついで通った。こっちが汗だくで歩いている目の前に、すっきりしたアベックが突然現れたりするのだから、たまったものではない。Kさんに「大変良い環境ですね。」と冗談言ったら、「とんでもない、最悪です。」と言下に否定していた。そりゃまあ、そうですな。

　些細なことに思えるかもしれないが、呼びつけるのと出向くのでは大違いである。後々の作業に大きく影響することになる。現場監督、この場合PMだが、作業指示も的確に出せずに横柄な態度だけとって、何も得るものはない。逆効果である。しかもこのPM氏、そのばかさかげんはこんなものでは済まなかったのである。

　準備段階で実はこのPM氏、もうひとつろくでもないことをやっている。今回の我々の作業の中には、サーバ移設も含まれている。通常サーバにはいろいろ機器や配線が取り付けられている。そこで、取り外すときにはケーブルとコネクタに合わせ番号の印を付け、組立時に間違えないようにする。そこで、筆者が簡単な手順書を作成してPMに渡したのだが、「そんなことどうでもいいんだよ。」と言って、見向きもしなかった。Mさんも頭来ているから、結局自分たちにはね返るとわかりながら、何もしなかった。結果どうなったか、言わずもがなである。この時点で、段取りの重要性もわかっていないことがばれてしまった。

　さて週末、いよいよ最初の作業日である。前夜、別の引っ越し業者が移動したパソコンを、いよいよ土日の2日間で設定作業を行う。事前にPMは、新しいオフィスに朝入館する場合、20人を超える人数なので、必ず事前に集合してまとまって入館すること、朝9時と昼13時15分には必ず時間厳守でミーティングを行うことを指示していた。ここまでは良かったのであるが、問題は早速初日の朝一番に起きた。

　このような段取りを組んだ場合、お客のオフィスに入る前に集合して朝礼を行うのが常識である。しかしながら、これまでのPMおよびD社の「はずれ」担当者の言動からして、この最初の日の朝、だれも朝礼に来ないだろうと睨んでいた。そして、その予想は当たった。元請けのSI業者はおろか、「はずれ」担当者もいないのである。結局、D社の立場を代表して、筆者が朝礼の挨拶を行うこととなった。

　工事をやったことがある読者であれば、この挨拶の重要性がおわかりになるであろう。ここで初めて関係者が一堂に会すのである。しかも、作業者全員に、「何かトラブルが起きたときの連絡先は私です。」と宣言しているのである。したがって、この朝礼の挨拶は絶対現場監督、この場合PMがやらなければならない。しかし、この重要な局面、ここしかないという時にPMはいなかったのである。この瞬間、このPMは指揮系統の第一線からはずれてしまったことになる。すなわち、情報が集まらなくなるから、お客から突っ込まれても臨機応変の対応ができなくなる。したがって、お客からの評価は下落することとなる。後述するが、実際そういうことが起きてしまった。

　さて、このPM氏、もう一つの問題点として、「他人に厳しく自分に甘い」ということがあげられる。自分で決めたこと、Mさんの会社のような下請けには厳しく言うが、自分は守ろうとしないし、自分の会社の人間にもうるさく言わない。「ジーンズ禁止」と言っておきながら自分の部下が着てきても、何も叱責しない。これでは、現場の職人や作業員は動かなくなる。そして、決定的にすごいことをやってくれた。

　前述したように、時間厳守で朝と午後一番にミーティングを開くとPMは宣言した。ところがである。2日目の日曜日、PMの部下とD社の我々がまとまって昼食に外に出たところ、周囲の飲食店はほとんど休業しており、ただでさえ12時をかなり回っていたのにやっと店を見つけたのは12時50分であった。どう考えても13時15分のミーティングには間に合わない。そこで筆者が、「もどって一言言っておきましょうか。」といったら、「そんなのほっときゃいいんだよ。」ときた。全く信じられない言動である。横柄な態度をとって下請けを厳しく叩けば現場監督が務まると、勘違いしている。そして、15分も遅刻して作業控室に戻ると、悪びれもせずへらへらして登場し、「いやー、遅れちゃった。」である。Mさんの会社には、作業が遅れているのだからなんとかてこ入れしろときつく言い、なんと心配になった取締役まで手伝いに来ていたのである。朝礼に続き取締役の目の前でこういう不始末をやった。PMがへらへら登場したとき、S取締役を筆頭に、Mさんも作業員も、全員PMに向かってものすごい視線を発したのは言うまでもない。

　そしてその夜、事件は起きる。

　「口車さん、ちょっと来てくれます。」

　夜の9時近くであろうか、本来ならこの週末の作業はもう終わろうかという時刻になって、Mさんが血相を変えて筆者のところにやって来た。何事かと彼について別のフロアに行くと、そこに作業員全員とS取締役が集まっている。Mさん曰く、最後の確認段階で設定手順のひとつが抜け落ちており、パソコンが朝一番で動かない可能性があることがわかったという。正直なところ、お客の作業指示のミスである。パソコンの中には、コールセンターで使用しているものも含まれる。それが動かないとなったら一大事である。「だから、Windowsはきらいなんだよぉ。」と愚痴を言っても始まらない。とにかくやるしかない。確認作業自体は1台当たり5分弱であるが、なんせ1000台である。筆者は全員に向かって、「あなた達に落ち度はないが」ということを匂わせながら、「申し訳ないが、今夜は徹夜覚悟で動くようにしてください。」と指示を出した。その指示にしたがってMさんが具体的な割り振りをし、全員持ち場へと散っていった。

　こういう大事なときに、どうしてPMはいないのであろうか。もっとも、MさんはPMを全く信用していないから、控室でこういう相談をせずに別のフロアに人を集めてミーティングを持った。これまでの言動でPMが全く当てにならず、とんでもないことを言って振り回し、作業員の反感を買うだけということを見抜いていたからである。PMは、完全にはずされたのである。

　しかし、悪いことはできないものである。作業員全員でミーティングをやっているその脇を、お客の課長が通ってしまった。またよりによって、その課長に案内してもらって組合事務所の中のパソコン設定を筆者がやることになっていた。ミーティング後二人で部屋に入った途端、すかさず課長から、「何かあったの。」と来た。「いや、ちょっとトラブルが見つかったのですが、すでに対処方法を見つけて作業にかかっています。ですから大丈夫です。」と説明した。

　課長が出ていって10分も経たないうちに、PM氏とD社の「はずれ」担当者が血相を変えて組合事務所にやって来た。そして開口一番、「なんでお客にトラブルなんて言うんだ。そういう余計なことを言うんじゃないよ。」と文句を言いだした。一瞬、「あんたが肝心なときにいないからだろうが。」と言いかけたが、その場は「申し訳ありません。」と謝っておいた。そこで喧嘩してみても作業が遅れるだけで、何の得にもならないからである。

　自分の配下の不始末をお客に先に知られてお客から指摘されるというのは、現場監督として完璧に失格である。さらに、その不始末を筆者のせいにしようとしたのである。また、見栄っ張りであり、トラブルは隠して当然、お客に知られるなんてもってのほかとでも思っているのであろう。ただならぬ雰囲気で作業員が集まっているのを目撃していて、それに対して「何でもありません。」と言ってお客が納得するとでも思っているとしか考えられない。

　幸いにして作業は0時前に終了した。徹夜も覚悟していたが、なんとか全員終電車に間に合って帰ることができた。的確な指示を出して余計なことを言わず、みんなのやる気を引き出せば、こんなものなのである。

　さて、筆者がもうひとつやったこととして、Mさんが頭来て怒鳴りだす前に筆者が怒鳴り散らすというのがあった。PMには直接やっていないが、PMの会社の社員には二度ほど頭来て怒鳴っている。こういうことはお勧めできることではないが、Mさんは実際に作業を行う作業員のまとめ役であり、彼がぷっつんしたらそれこそおしまいなのである。

　他にもこのPM氏の意に沿わないことを筆者がやり、D社の「はずれ」担当者を通して、次の週からは来なくて良いと通告してきた。しかし、逆にPM氏の会社は、その後そのお客にお出入り禁止となったのである。一方、感心したのはD社の対応である。残り5週間、全く仕事をしなかったのであるが、その分も含めて代金を支払ってくれた。無理矢理頼まれたから、当然と言えば当然なのであるが。

　自分の信ずるところで動けば、必ず道は開けるものである。　（目次へ）
　

先頭 表紙

　この記事は、ニューズ社発行の「Network Cabling」誌の、2000年8月号から2001年7月号まで連載されたコラムを加筆訂正し、再録したものです。


目次
- なんてレベルが低いんだ
- だれだ、こんなことやったのは
- プロジェクトリーダーとしての大学教授
- 「システム」とはコンピュータのことではない
- それでも動く
- いかにしてシステム管理者は育つか
- ああ、勘違いの現場監督

　（つっこみへ）


●　なんてレベルが低いんだ

　さて、IT（情報システム）業界関係者にとって、かなり辛口の内容を書いて行こうと思う。まず、なぜ辛口のことを書きたくなったか、その前提となる筆者の経歴から説明させていただく。

　筆者が学校を卒業して最初に就職した会社は、「御三家」と言われている、専業エンジニアリング会社の一社である。入社後早々に配属されたのは、工事部である。ここでは工事現場に出て行くのはもちろん、電気計装の工事積算、プラント建設の工程管理ということも仕事としてやっている。その後電気計装設計部という部署の配属となり、計装設計のエンジニアとして仕事をしている。その間、土木、建築工事の積算システムを作成し、工事現場や職場のシステム管理者をやっている。すわわち、設計から工事現場まで、プラント建設の一通りを経験させてもらった上に、システム構築もやった。特に、タイの田舎の電力事情の悪い場所で、溶接機と同じ電源でコンピュータを動かしたり、日本にまだインターネットなどというものがない頃にタイと日本でパケット通信を実施したりできたのは、これは貴重な経験であった。

　すなわち、「プロジェクト」を一通り経験し、しかも「プロジェクトマネージメント」の中枢を経験している。

　このような経歴を背景に、考えることがあって転職し、システム構築を行う業界、すなわち今で言うIT（情報技術）業界へ転身し、そして驚いた。うぬぼれるわけではないが、自分たちの仕事に対する取り組みがいいかげんな、レベルの低い企業というか技術者のなんとまあ、多いこと。エンジニアリング会社に勤めていたとき、協力企業を含め周囲で仕事をしていた人達は、例外はあるにせよ本当に「プロ」であった。それに比べると、あまりにもひどい。

　もちろん、IT業界にまともな企業はあるし、まともな技術者もいる。しかしながら筆者の経験では、こういうまともな企業や技術者に遭遇する確率は、残念ながら非常に低い。「プロジェクトマネージメント」もわかっていなければ、「工事」の常識もわかっていない。しかも「品質」もないときた。要するに、ちゃんと仕事をしていない。それが堂々と、「通産省認定システムインテグレータ企業」などと名乗っている。信じられない。いったいどういう基準で決めて認定しているのだろう、この資格。

　確かに、前職のエンジニアリング会社においても、今日は通産省のお役人がやってきて、天井クレーンの官庁立ち会い検査という工事の元請けとしては大変重要な日に、仕事さぼってゴルフやりに行っていた「現場事務所長」とか、馬鹿野郎なオヤジが存在したことは事実である。しかし、こういうオヤジはどちらかというと例外的な存在で、問題が発生すると、直ちにバックアップシステムが働いていた。すなわち、こういう連中が責任者として存在する工事現場は、絶対どこかでおかしくなるのであるが、その兆候が見え始めた途端、応援の要員が出ていって、実質的にその責任者達の職務を乗っ取ってしまうのである。あわれオヤジ達、あっという間に窓際族である。

　当然、レベルの低い企業にも、きわめてまともで優秀な社員は存在する。しかしながら、それは「常識」が通じる企業とは逆で、例外的な存在でしかない。その企業の中で「点」の存在でしかないから、前述のようなトラブル発生時のバックアップシステムなど働くわけがない。運良くその優秀な社員が担当者になればよいが、そんなことは宝くじに当たるのといっしょである。

　また、お客との間にトラブルが発生したとき、事後の対応で逆にお客の信頼を得ることがある。というか、筆者は「トラブルこそ、チャンス。」と思っている。ところが、レベルの低い企業では、このような次の受注に結びつくような事後処理は、望むべくもない。危機管理なんて概念は、はなっからない。

　これまでは、程度の低い、いいかげんなことをやっていても、それで通ってしまった。コンピュータのことがわからない顧客はうまく丸め込まれ、そんなものだと思い込まされていたからである。しかしながら、コンピュータの中のことがわからなくても、システム構築は機械ものや建物を発注するのとなんら変わらない。やるべき仕事の基本はいっしょなのである。顧客の要求をしっかり把握して設計し、図面や図書をきちんと作成管理し、段取り良く製造や工事を行い、きちんと検査を行って納期に間に合わせる。そして最後に完成図書を収めて検収。こういう基本的なことが、全然守られていない。逆に、「なぜ、やる必要がある。」と来る。

　最近IT業界において、ことさら「プロジェクトマネージメントの重要性」が強調されている。しかし、「プロジェクトマネージメント」なんていう、曖昧模糊とした「横文字」なんか使っているから、具体的にどうせいということがぴんと来ない。「プロジェクトマネージメント」なんて、言っている本人も具体的な意味がわからないような用語を使っていないで、「段取り」と言えばよろしい。「プロジェクトマネージメント」の意味をわかって使っている業界関係者、いったいどれくらいいるのだろう。こういう「横文字言葉の氾濫」についてはまた別の機会にゆずるとして、次へ進もう。

　えっ、「段取り」の意味がわからないって。まずは国語辞典で調べましょう。特に工事は、「段取り」勝負です。こんなこともわからないから、「なぜ、やる必要がある。」となるのである。

　さて、筆者がどうレベルが低いことに憤慨したのか、実際に遭遇した実例を列記してみよう。


事例1

　最初に申し上げておくが、この事例はトラブル発生時のバックアップシステムがうまく働いて、いわゆる「結果オーライ」となったものである。心臓に良くないので、いきなり過激な話は避けてみた（んなことはないか）。であるから、「なんじゃこりゃ」ということではないが、バックアップシステムはどのように機能するか、知っていただくための実例である。または、筆者の自慢話とも言う。

　筆者が現在の会社設立直前に勤めていた某大学で、ネットワークの張り替え工事を行うこととなった。ところが、その工事業者の現場監督は、入社2年目の全く工事現場の経験なし。工事工程表を作成することができず、場当たり的にその日の朝に作業指示を出していた。職人さんはぷっつん寸前、教員個室に勝手に入って作業をおこなうわで、もう大変。発注側の担当者であった筆者は上司を呼び出し、「人を替えろ。」と申し出た。当然現場監督が替わるわけもなく、また替えてもらうつもりもなく、上司にどういうことになってしまっているのか、強烈に知ってもらうのが目的である。監督さえしっかりしていれば職人はトップクラスであり、工事はちゃんとするのである。上司に会社としてサポートの約束を取り付け、同時にできない部分についてこちらが積極的に介入した。教員個室毎の工程表を作って渡し、予定を穴埋めさせた。上司がまめに現場を見に来るようになったので、その工程表に基づいてきれいに作業が進んでいく。現場監督君、元々設計担当者で図面はきちんと起こしていたから、完成図書もばっちり。逆に信用を得て、この業者はその後も仕事を請け続けている。

　この事例、「段取り」すなわち「プロジェクトマネージメント」とはどういうことをするのか、その具体的な事例でもある。どこがポイントなのか、まあ考えてください。

　さて、いよいよこれからすごい話に突入していく。　（目次へ）


●　だれだ、こんなことやったのは

　さて、いよいよ信じられないような話に突入していく。これから登場する事例を読んで、「どこがいけないの。」と思うようだったら、あなたもかなりやばいです。ちなみに、これらの事例に登場する企業は、すべて名前を聞けばだれでもが知っている、「立派」な企業です。


事例2

　前述の大学において、事例1の工事の前、実は別の業者が配線工事を行った。もう10年も前だから、今はほとんど使われなくなった10Base5と10Base2が主体であり、バックボーンがFDDIであった。しかし工事の基本は、現在のUTPケーブル主体の配線でも変わらない。したがって、当時のめちゃくちゃな話は、現在の配線工事でも通用するのである。

　筆者は、この最初のネットワークが敷設された1年半後に勤めるようになったのだが、配線の実態がわかるにしたがって、びっくりした。めちゃくちゃなのである。図面はどこにもない、ケーブル見てもケーブルマークは打っていない、整線なんてなんのこと？といった調子。なにか機器を増設しようなんて言ったら、遺跡の発掘調査そのものである。キャンパス全体の工事で、造成時に本当に遺跡が出てしまって工事が遅れ、突貫工事になってしまった恨み辛みをこめたのかしら。それにしても冗談じゃないぞ。完成図書を出さない工事業者なんて、どこにいる。

　ただでさえ、こんな状態であきれ返っていたところに、「事件」は起きた。

　ある日突然、研究棟のひとつでネットワークが機能しなくなり、通信できなくなった。だれも使っていないのに、パケットが飛び交っている。最初はブリッジとかリピータの故障と思い交換するが、復旧せず。そこでよもやと思ってEPSの中を調べてみたら、ドアを開けた途端、目の前に10Base5のイエローケーブルがとぐろを巻いているのが目に飛び込む。さらにとぐろの途中で長すぎるのが邪魔なったのか、ケーブルをべきっとへし折り、広がらないようにビニールテープがぐるぐる巻いてあった。思わず筆者は叫んだ。

　「だれだ、こんなことやったのは！」

　全くプロのやることではない。このケーブルをへし折っている箇所がインピーダンス不整合点となり、信号が反射を起こして幽霊パケットが飛び交う結果となったのである。あるセミナーでこのことしゃべったら、前の方に座っていた人達、思わず、「うわっ。」と言っていたな。わかっていれば、思わず口をついて出ますよ、その一言。

　この業者、その直後に別のところで、2.5m間隔で取り付けなければいけない10Base5のトランシーバを、30cm間隔で取り付けるなんてことをやっているのも発覚した。やはり、通信できなくなったのである。いくら突貫工事だからと言って、いったいどういう施工監理をしているのであろうか。しかも、配線図もなければケーブルマークもつけていない。ひとたびトラブルが起きると、重いフリーアクセスの板持ち上げたり、ほこりだらけの所をはいずり回ったり、もう大変であった。

　「LANケーブルを折り曲げてはいけない。」というのは、その周波数特性と、イーサネットの動作原理から言って、当たり前である。それは、最近の配線で一般的に使われるUTPケーブルでも全く同じであるが、電話線と同じつもりで、柱や壁に沿わせて直角に折ってしまっているというのは、よく見受けられる。これだってとんでもないことなのに、故意に折り曲げるとはなんてことだ。

　当然、その次の工事からは、その業者、お出入り禁止となったのである。

　しかし、これは考えてみれば業者も業者であるが、そんな業者にごまかされる、発注者側も発注者側なのである。　（目次へ）


●　プロジェクトリーダーとしての大学教授

　本節では、旧聞に属することであるが、発注者側の大学に、どのような問題点が潜んでいたかについて解説する。極端な例ではあるが、どこの企業にも潜んでいる、普遍的な問題点が含まれている。また、プロジェクトリーダの資質について、キャンパスネットワーク構築の中心人物であった教授を例に、具体的に解説する。個人攻撃のようであるが、プロジェクト管理、あるいはシステム管理を考える上で、この教授の性格は大変重要な意味を持つので、あえて筆者の観察したところを書かせていただく。


事例3

　ここのところずっと登場している、筆者がかつて勤務していた大学は、鳴り物入りでキャンパスネットワークを敷設した。今では当たり前だが、学生を含め、在籍者全員に個別のユーザーIDとファイル空間を与え、自由に端末を使ってインターネットにアクセスできるという環境を、10年前に実現していた。この、今までどこも実現したことがない、自由なコンピュータネットワーキングの環境を実現するという、戦略は良かった。しかし、その戦略を実現するための戦術、すなわち実務において、非常にまずかった。抽象的なことを書いていてもぴんとこないと思うので、具体的な事例を列記していく。

　さて、筆者が勤務し始めてすぐ、経理に行くと段ボール箱を一箱見せられ、「これ、整理できないか。」と言われた。何かと思ったら、キャンパス内に設置されているネットワーク機器、コンピュータ等の納品書の山である。あ然とした。

　キャンパス内、どこに何があるか、だれも全く把握していないのである。実際、ラップトップコンピュータ（SONY NEWS）が2台行方不明となり、納品後、すなわち開校してから3年後、未使用のままロッカールームから見つかっている。この一事を持ってして、どれだけ問題を内包しているか、わかるというものである。

　その原因を分析していくとプロジェクト管理の本質が見えてくる。この事例は、プロジェクト管理が全くなされていないことを端的に表わしている。当然工程管理なんてできてない。したがって、前回は工事業者の問題点を指摘したが、決して業者だけを責められない面もあるのである。さて、なぜこんなことになったかである。

　大学の組織は、研究者であり教育者である教員と、実務担当者である職員からなる。キャンパスネットワークは大学の共通の「設備」であるから、その設置に当たっては、本来、職員が教員の希望を聞いた上で、業者との折衝を直接行い、発注し、工程管理を行う。納品された機器の管理も職員が行う。ところがである。このキャンパスでは立ち上がりの時に、なぜかそういった実務レベルの部分まで、教員がすべてを行ってしまった。前述の納品書についても、本来事務部門が管理して台帳を作り、各機器に備品番号のシールを貼って管理するというのが常である。ところが、事務部門をバイパスし、本来やらなければいけない、こういった管理上の作業をもすっ飛ばして、プロジェクトリーダの教授が、どんどん好き勝手に機器をばらまいてしまったのである。

　筆者が行く前の話なので、本当のところはわからないが、キャンパスネットワークという、これまでにない新しい技術を導入するので、職員には実務を含めて無理、となってしまったようである。しかしながら、プロジェクト管理ということを全く理解していない人物が扇の要にいたらどうなるか、その典型的な事例となってしまったのである。

　教員がすべて、実務能力がないと言うつもりはない。実際、筆者の恩師は、実務レベルを含むプロジェクト管理能力に秀でていた人だったし、当時このキャンパスの名物学部長だったK教授は、「僕は実務能力がないから、任せた。」と言ってくれて、筆者の手に負えない問題解決に、全面的にあたってくれた。すなわち、実務能力がないなんてとんでもない、逆に実務能力があるからこその発言なのである。ただし、残念ながら、こういった大学教授は、例外であると思っていたほうが良い。

　さて、ここで、プロジェクトリーダーであったS教授に登場していただこう。

　このS教授、すべてにおいてだらしがない。まず時間にだらしがない。例えば、月に一度ネットワーク管理のために委員会を開いていたが、その座長でありながら、会議に2時間遅れるのは当たり前である。しかも、あらかた話が進んでいても、彼が登場すると全てがゼロにリセットされる。これがほぼ毎回である。そして優柔不断であるから、具体的なことは何も決まらない。筆者が議事録をとっていたが、「今回は議事録に記載する事項無し。」と何度書いたであろうか。そんな会議に、毎回4時間を費やす。

　時間も去ることながら、お金に対してもだらしがない。だらしがないというか、確信犯的に、業者への支払いを踏み倒す。常々「メーカーや業者は、金を儲けてけしからん。」と言っており、S教授の頭の中には「原価」という概念がないようである。だったら、なぜ自分は大学から給料をもらうのであろうか。ちなみにこの教授の研究テーマは、「マルチメディアベンチャーの研究」である。

　そして最悪なのは労務管理である。まったくできない。筆者がひどいなと思ったのは、大学院に残っているが学位を取れずにいる、というか取らさずにいたようにも見えたのだが、そういう中途半端な状況に自分の研究室の院生を置き、ほとんどただ同然でこき使ったことである。身分も不安定な状態で、徹夜も含む作業に、だらだらと当たり前のようにこき使った。当然、「休め。」とも言わない。「研究活動」を大義名分にしていたから、本人達には自覚がなかったかもしれない。悲惨だったのは、本当に「過労死」を出してしまったことである。持病があったのだから、指導教授としては気を配るべきである。

　金がないから、研究室の助手や院生、学生を使ってというのは、往々にして起きることではある。しかしながら、不安定な状況に置かれている結果、彼らは非常に攻撃的になり、先輩であることも忘れて職員を見下し、少しでも齟齬があるとけんか腰である。しかも、自分たちが知らないこと、都合の悪いことが起きると、いつの間にかどこかへ消えている。身勝手なのである。親分が親分だけに、つま先立ちのような、深いが幅の狭い知識の上に立ち、その範囲で周囲の人達が知らないと攻撃的な言動でばかにし、都合が悪くなるといつの間にかいなくなる、「ネットワークの専門家」が養成される。読者の周辺に、こういう輩、結構いるのではないだろうか。

　こんな調子であるから、運用は大変非効率である。しかも、「設備」として維持管理をどうやっていくか、全く考えていない。そのツケを払うために、一部の極めてまともな助手や院生、安いアルバイト代で手伝ってくれる学生達、職員、そして外注の派遣社員の面々が、じたばた振り回されながら、ネットワークの維持管理に奮闘しているのである。

　大学組織の内側でこんな調子である。そうであれば、業者はどのようにあしらわれることになるか。決めるべきことは決めてもらえない。しかしながら、無茶な納期の要求は来る。しかも、金払いが悪い。いったいだれが、まともに仕事をしようと思うであろうか。ただでさえ、厳しい予算で仕事をしているのに、利益率をさらに悪化させるようなことを、プロジェクトリーダーのS教授とその門下生は、平気でやるのである。であるから、業者を一方的に攻め立てるのは、酷ではある。でも、だからと言って、手を抜いてはいけないところまで手抜きをしてはいけない。

　ところで、筆者が在籍したキャンパスの、そのネットワーク構築の中心にいたとなると、大方の読者は、S教授とはM教授のことではないかと思ったかもしれない。しかし、「はずれ」である。M教授は、さっさと逃げていました。「君子、危うきに近寄らず。」なのである。　（目次へ）


●　「システム」とはコンピュータのことではない

　前節に引き続き、本節も同じ大学の別の助教授に登場してもらい、「システム」とは何かについて、考えてみたい。


事例4

　事例3で登場した同じキャンパスで、筆者が在籍中に大学院が開校することとなり、ネットワーク構築をT助教授が取りまとめることとなった。すなわちプロジェクトリーダーである。まず、この大学院のシステムを解説する前に、既設の学部のネットワークシステムについて触れておきたい。

　ここのキャンパスの基幹システムは、UNIXで構成されている。ご承知のように、UNIXのシステムは停電等でいきなり停止すると、再起動させるのが大変である。そこで、こういう事故が起きないように、無停電電源装置(UPS)が不可欠である。ところが、このキャンパスが開校した当初、なんとUPSが設置されていなかった。

　それで、どうなったか。

　落雷や工事ミスによる停電で、システムが3度ほど停止し、最初の落雷の時は慣れていないため復旧に手間取り、休校となってしまった。そこで、遅まきながら、筆者が在籍中にUPSを導入し、以来学部のネットワークは停電事故を起こしていない。

　さて、大学院のネットワークシステムである。

　普通、このような事故を経験していれば学習効果が働き、電源対策が万全であると思うであろう。ところがである。何もしていなかった。分電盤すら、何も対応していない。にわとりは3歩歩くと、その前のことを忘れてしまうと言われているが、これではにわとりと同じレベルである。ちなみに、大学院が開校した年、7月から9月にかけて瞬停を含め15回停電している。

　常識的に、大学院のシステムは学部のシステムのサブシステムである。であれば、学部のシステムが、運用を含めどうなっているかを踏まえながら構築するのが当たり前だと筆者は思うのだが、T助教授の常識は違ったようである。大学院だけで囲い込みをやり、運用担当者である我々に何も相談しなかった。相談どころか、自分たちの好き勝手なことをやろうとした。ネットワークは「社会基盤」であるという、概念がないのである。カーネギーメロン大学に在籍経験のあるT助教授は、ことあるごとに彼の地の教員と管理者である職員の連携のすばらしさを述べていたが、はて、ご自身がされていることはなんなのであろう。全く、説得力がない。

　既存のシステムを無視して構築した「つけ」は、UPSにとどまらない。

　大学院のネットワークシステムが動き出した当初、ユーザーが接続したコンピュータが通信できないというトラブルが頻発した。調べてみると、学部側で使用しているパッチケーブルを使うと接続できない。さらに調べてみると、ケーブルのワイヤの配列が違っているのがわかった。筆者が実際に現物を見ていないので詳細はわからないが、とにかく、学部と大学院の配線システムの違いがトラブルを引き起こしていた。

　大学院も、学部と同じ施工業者が工事をしていれば、こんなトラブルは防げた。しかも、大学院の工事と同時期に、学部のネットワークの張り替え工事もやっていたのである。費用の点でも安くついたはずであるが、T助教授は別の業者に発注すると頑張ったあげく、このような事態を招いた。別の業者であってもきちんと相談してくれれば、こんなばかなことは起きなかったのである。

　さらに、ネットワークの根幹に、動作が保証されていない新製品のATMコントローラを設置し、当然のように動かなかった。よって、大学院のネットワークは、開校以来半年間、まともに動かなかった。そして、これらのトラブルは、すべて業者の責任に帰結される。

　このトラブルは、「システム」が、コンピュータ、さらにその上で動くソフトウェアだけはないということを物語っている。いくらソフトウェアが優秀でも、コンピュータを動かす環境、電源や空調、配線システムがきちんとしていなければ、システムは動かない。さらにどのように運用するのか、トラブルを起こしたときの対処手順はどうするのか、そこまで考えて初めて「システム」と言えるのではないだろうか。　（目次へ）


●　それでも動く

　ここのところ、以前勤めていた大学の杜撰な話を書いてきたが、本節ではそんな状態でもなぜネットワークシステムは機能しているのか、また、トラブルに遭遇してこそ、システム管理者として育っていくということについて解説する。


事例5

　筆者が勤めていた大学、今ふり返ってみても、あんな状態でよくネットワークが機能していたものだと思う。その理由として、まずあげられるのは、個々人の「なんとかしなければ。」という強烈な動機づけである。「プロジェクトリーダーとしての大学教授」において、助手や院生、手伝いの学生達、職員、そして外注の派遣社員の面々が、頑張って支えていることを書いた。自分たちが重要な基盤を支えており、日本の先頭を走っているのだという思いが、かろうじてネットワークシステムを機能させていた。決して良いあり方ではないが。

　加えて、実務の運用は、結局は落ち着くところに落ち着くものである。やはり「プロジェクトリーダーとしての大学教授」で説明したように、「もの」の管理等、実務も大学教授がいったん握ったが、全くできないことが露呈してしまった。結果、徐々に彼はお飾りとなり、実務は再び職員が仕切るようになる。毎年予算を組んで新しいシステム導入を具体化するのは、結局職員である。したがって、自分の思うように機器をそろえたい賢い教員は、S教授を気にしつつ、さっさと職員のところにやって来る。新規性を出そうとして無理にねじ曲げても、できないものはできないのである。落ち着くべきところに落ち着いたからこそ、なんとか運用できたのである。

　さて、後ろ向きなことばかり書いてきたが、このキャンパスでもプロジェクト管理がうまくいき、効率良く費用最小限で、使い物になるシステムを立ち上げた事例がある。

　このキャンパスでは、体育の授業は毎週希望のコースを学生が予約して、それで授業を受けるという方法を取っていた。どうしてそうなったのかとてもわかるのであるが、当初この予約システムは体育館に設置してある、キャンパスネットワークとは独立のパソコンシステムで稼働していた。これが、授業に来た学生の出席登録と交錯するわ、体育館に来なければ予約できないわで、すこぶる評判が悪かった。そこで、キャンパスネットワーク上で稼働するシステムを立ち上げることを、体育の先生は決断した。

　当初、たまたまトラブルの対応をした筆者に、体育の先生が相談してきた。同時に、筆者の上司にも相談した。当然である。普通は「私にも話があったが、○○君よろしく。」となるところ、こともあろうに、自分だけええかっこしいで筆者のことを煙たがっていた上司は、筆者が知らないところで研究者や院生を動かして動き出してしまった。困ったのは体育の先生である。連絡をもらった筆者は、急遽その研究者のO君と院生二人を呼んでもらい、三者で打合せを行った。ここでかしこいO君は事情をただちに察知し、お互いの役割分担をさっさと決めてしまった。こんなところで変ななわばり意識とか自尊心は、邪魔になりこそすれくその役にも立たない。彼らがプログラミングとコンピュータ本体の調達、筆者が既存システムからのデータの移行と周辺機器の調達を担当することになった。不要となったものをかき集めたりしたので、院生へのバイト代を含め、格安にでき上がった。そして新学期の4月から稼働し始めた。

　システム構築は、稼働し始めたら終わりというものではない。稼働直後のトラブルを押させてこそ、完成する。そしてこの予約システムは、ほとんどトラブルなしに動き続けた。さらに、このシステムの稼働時期は大学院の開校と重なったのであるが、前節で書いたように、7月から9月にかけて停電が相次いだ。最初の停電でまっ青になったO君達は、体育館へ飛んでいった。大学院のシステムはダウンしていたが、体育の予約システムは何事もなかったように動いていた。筆者がこのような事態を想定し、余っていたUPSをシステムに接続しておいたのである。O君達もその存在は知っていたが、実際目の当たりにして、システム構築とは何かということを思い知ったようである。特にO君の下にいた院生二人は。　（目次へ）


●　いかにしてシステム管理者は育つか

　前節で、トラブルに遭遇してこそシステム管理者として育っていくということを書いたが、そのあたりのことをさらに分析してみる。

　筆者の勤めていた大学では、職員の補助として学生コンサルタントをアルバイトで採用していた。彼らはメディアセンターという、学生がコンピュータを使用する場所の一角に机を構え、窓口業務の最前線にいる。ここで利用者がわからないことの相談と、トラブルの初動対応に当たることになる。

　彼らが遭遇するのは、同じ質問の繰返しとトラブルとも言えないようなトラブルである。しかも、質問するのは初心者であるから、初歩的な内容ばかりである。もっとも多いのはプリンタの紙切れで、初心者はプリンタから出力しないと血相を変えてやってくる。また、ネットワーク上のプリントサーバで、しかも大人数が使用しているとすぐには自分の印刷物が出てこないが、初心者はそんなことを知るわけもない。そこで、印刷されないと思って何度も同じプリント指示を出し、プリントサーバの混雑にさらに拍車をかける。この、余計なプリント指示を削除するのも、彼らの仕事である。もちろん、自分たちの知識を駆使したコンサルティングというのもあるが、ほとんどは、こういった単純なことの繰返しで時間は潰れていく。

　そうすると彼ら学生は何を考えるか。楽をすることを考えるのである。楽をするにはマニュアル作成となる。その根幹として、FAQ (Frequently Accessed Questions)すなわち、「よくされる質問集」を作成する。これによって、質問に来られても「これ見てね。」ということで、彼らの負荷が軽減する。

　この「楽をする」という発想はシステム管理者として大変重要で、システム管理者個々人の頑張りでネットワークシステムを維持管理していくものではない。個々人の頑張りということは、システム管理のノウハウはその個人にとどまることになり、その人に何かあったとき、システム管理が滞る。危機管理の観点から、大変まずい。こういう、システム管理者にとってもっとも重要な感覚が、学生コンサルタントという経験を通して養われていく。

　前節で紹介した事例についても、考えてみよう。

　体育予約システムのプログラミングを担当した大学院生二人が、大学で勉強したことは計算機科学についてであり、それは計算機の原理やプログラミングの方法論についてである。組織の基盤としてネットワークシステムを維持管理していくためにはどうすればよいかなどいうことは、教わらない。また、理系の学部ではないから、ハードウェアの基本を教わっているわけでもない。勢い、システムというのはソフトウェアだけで成り立つものであると考えがちであり、それだけで動くと思いがちである。ところが、停電という事態に遭遇して、そういうものではないということを思い知ったはずである。ひとたび停電が起きると、いかに自分たちが困るか実感したわけである。方や、想定される事態に対してちょっとした対応をしておけば、いとも簡単にそういうトラブルが回避されることも目の当たりにしたわけである。自分たちの研究室の周辺では大騒ぎしているのに、すわ大変と、自分たちが作ったシステムを見に体育館に行ってみれば、何事もなく動いている。そうすれば、システム構築に当たって何をしなければいけないか、肌で感じたはずである。

　筆者はかつて、タイの田舎の工事現場でトラブルが発生した時に自分自身で対処しなければならないという状況に置かれ、YHP（現日本HP）で事前にCEとしてのトレーニングを受けたことがある。このときのトレーニング方法としてなるほどと思ったのは、我々は別室に連れていかれ、その間にわざとトラブルを起こしておいて、そのマシンをいかに早く復旧できるかという手法である。結局、ここでもトレーニングの主眼は経験するということである。

　経験とその経験をいかに自分のものとして吸収していくか、それが優秀なシステム管理者への道なのである。　（目次へ）　（続き）
　

先頭 表紙