 |
今回はリハーサルで起こったちょっとしたトラブルについて書こうと思う。と言ってもトラブルの内容ではなく，プロジェクト・マネージャとして私がどう対処したか，という話だ。以下は，小説として読んでいただきたい。江戸時代の浄瑠璃作者である井原西鶴は，「文学の妙味は事実と虚構の間にある」といった。この文章は文学というほどのものではないが，事実に基づくフィクションだ。事実をありのままに書くことはできないからだ。
リハーサルのネットワーク移行本部は，首都圏を外れた郊外にあるお客様のコンピュータ・センターだ。都心からちょっとおしゃれな特急電車に乗って行く，山めいた所である。
駅からタクシーに5分も乗ると市街地が切れて田園が広がり，すぐになだらかな山に入る。そこにセンターがある。都心から来るとちょっとした旅をした気分になり，稲刈りの終わった田んぼや山の木々の匂いが季節を感じさせてくれる。今年はいつもの年より金木犀が早かったようで，9月の連休なのに，もういい匂いをさせていた。
土曜午後3時，切り替え開始
ここのネットワークは全国数千カ所を結ぶもので，その基幹部分はATM交換機や大型ルータ，フレームリレー交換機などで構成されている。TCP/IP系のサーバやクライアントはルータで，レガシーなプロトコルはフレームリレーで収容している。
システム側と同期を取って，土曜午後3時に移行リハーサルがスタートした。切り替えはネットワークの外側から内側の機器へと順に設定変更して行う。外側とはホストやサーバに近いということで，センタの大型ＬＡＮスイッチが最も外になる。
そこからルータ，FRAD（フレーム多重装置），ATM交換機という順である。ネットワークの階層で言えば上位から下位へ向かっての切り替えということになる。一つの階層の切り替えが終わるごとに確認試験を行う。複数の層を同時に切り替えると，ミスがあったときに解析が難しいからだ。拠点数，装置数が多いので，作業の大部分はこの確認試験に費やされる。切り替えに必要な予想時間は午後3時から翌日午前2時まで。つまり11時間だ。
私は暇である。プロジェクトの責任者である私の仕事の90％は現場に来る前に終わっている。プロジェクト・マネージャの仕事は開発や移行をするために十分な体制を整えることと，設計や手順書の品質チェックがちゃんとできているかを確認することである。これができていればトラブルが起こることはまずない。残り10％のうち9％は，現場で部下やパートナの社員の動きに問題がないか見ることである。役割分担や指揮命令系統が明確か，属人的に動きの悪い人はいないか，ということを見る。問題があれば本番に向けて修正せねばならない。これで99％になった。ここまでの仕事は，現場で声を出す必要がない仕事だ。最後の１％は何か。難しい，あるいは難しそうなトラブルが起こったときの対処である。
トラブル発生！
午後11時になり，私は暇を持て余していた。その時，システム側の試験をしているチームから「一部のオンラインでレスポンスが悪いので調べてほしい」との連絡が入った。 ネットワークのリーダーが立ち上がって監視端末の前にいる担当者に指示しながら調べ始めた。どうもセンタの大型LANスイッチの該当ポートでコリジョンが発生しているらしい。そのうち，1～2名がリーダーの立っているホワイトボードのところにやって来て，トラブルについて議論を始めた。
どんなネットワークの移行本部でも，トラブルが起こっているかいないかはすぐわかる。トラブルが起こると立っている人間が増えるのだ。ひどいトラブルだと総立ちになって右往左往する。総立ちになって解決できるわけではないのだが・・・。
10分か，20分経って，私は初めて声を出した。LAN関係を担当しているSEが動いていないのだ。「トラブルが起こったら，事象の記録くらいきちんと取れ！ 他人事のような顔をしてすわってちゃダメじゃないか。」
まずは「事象」の正確な把握と記録
トラブルが起こったときに一番重要なのは，事象を正確に把握し，記録することだ。簡単なようだがきちんとできるSEは少ない。把握するためのツールが発生現場にないこともあるが，それ以前にトラブル対応に慣れていないSEは冷静に現象を見ることができない。報告を聞くたびに言っている内容が変わったりする。
やはりトラブル対応は，解析するベテランSEと，その下で記録を取るSEを決めておくのが良い。この現場のLAN担当SEは，私に言われてやおらパソコンでホワイトボードに書かれる情報や会話の内容を記録し始めたが，後でそのメモを読んでわかったのは何を記録すべきかを理解していない，ということだった。経験不足である。
事象を正確に，なるべく詳しく把握し，記録する。記録があってはじめて解析ができる。記録も取らずやみくもに試行錯誤したのでは迷路に迷い込み，いたずらに時間を費やすだけである。
直せる人を連れてくる
私にトラブルは解決できない。解析している人たちの様子を見ているだけだ。11時のトラブル発生から2時間が経ち，午前1時になった。まだ原因は特定できない。そこで私は2回目の声をあげた。「Aさん，Bさん，Cさんを呼びなさい」。
トラブル解決の二つめのポイントは「直せる人を連れてくる」ことだ。なあんだ，と呆れないでほしい。トラブルは直せる人にしか直せない。現場にいる人に直せるかどうか判断するのはプロジェクト・マネージャの大切な役割だ。私は2時間現場の状況を見て，もっと経験豊富な技術力のあるSEを呼ばないとラチがあかないと判断した。気の毒なことだ。秋の3連休初日の夜中，しかも，都心から離れている。3人が移行本部に到着したのは午前3時。しかし，彼等が加わって原因の特定は一挙に進み，デッドラインだった午前5時前にはトラブルは解消した。
判明した原因は，私たちの守備範囲ではなく，大型スイッチに接続したルータの設定にあった。ネットワークのトラブルの多くは原因がわかってみれば「なあんだ」というのが多い。午前5時すぎに近くのホテルに引き上げ，シャワーを浴びた。何でこんな時間に，こんなところでシャワーを浴びているんだろう，とフト思った。そして，そんな時決まって胸のうちで囁く言葉がある。「これが私の仕事です」。
連休の夜中に呼び出された3人も，きっと同じ気持ちで来てくれたのだと思う。
秋を拾う
はっきり言って，ここに紹介したトラブルなど，トラブルと言うほどのものではない。自分の精神や肉体がもつのだろうか，と思うような深刻なトラブルを少なくとも3回は経験した。原因究明が難しく，解決に日数がかかるトラブルもある。そんな時は責任を一身に背負い，ユーザの前面に立たねばならないプロジェクト・マネージャには，自身のマインド・コントロールも重要になる。これは対処に個人差があるだろうが，書き始めるといくらでも書けるほど処方はある。でも，そのほとんどは筆者にしか効果がない方法だろう。
一つだけ，誰にでも使えるかも知れない方法がある。古い映画だが「風と共に去りぬ」という映画をご存知だろうか。そのラストで主人公のスカーレット・オハラが呟く言葉がそれだ。“Tomorrow is anotherday．” いろんな翻訳がある。が，私の翻訳はこうだ。「難しいことは明日考えよう」。難しいトラブルに何日も苦しまされる時，昼も夜も，休日も原因や対策を考え続けても何のプラスにもならない。忘れる時間も必要だ。ふとんに入る前にこの言葉を「胸のうち」で囁いて眠るのだ。
ホテルで4～5時間仮眠して移行本部にもどった。リハーサル2日目はエンドユーザによるアプリケーション試験が行われる。ネットワーク・チームは2～3名待機するだけだ。ホテルからセンターに向かう道端に，ぴかぴかのドングリの実がたくさん落ちていた。こんなドングリの実を見るのは何年ぶりだろう，と思いながら3個のドングリを拾った。秋を拾ったのだ。10月が終わろうとする今も，ペン皿にドングリは乗っている。もう，あのピカピカのドングリではなく，ちょっとくすんだ色が晩秋を感じさせてくれる。
| 松田 次博：情報化研究会主宰。1984年より，情報通信に携わる人の勉強と交流を目的とした情報化研究会（www2j.biglobe.ne.jp/~ClearTK/）を主宰。著書にVoIP構築の定番となっている技術書「企業内データ・音声統合網の構築技法」や「フレームリレー・セルリレーによる企業ネットワークの新構築技法」などがある。NTTデータ勤務。趣味は，読書（エッセイ主体）と旅行。 |
