13-06
13-06
ＰＢＲのヒアリングシートへの記入の仕方については、アクセスリストのパラメーターを記入する欄に、対象のパケットを記入し、当該行の備考欄に、ＰＢＲ用であることと、曲げ先のネクストホップＩＰ、ＰＢＲ先のパスを監視するためのＩＰを記入してもらうよう、都は案内した。それを理解した旨都に返してから、お客はベンダーと、さっき都が投げかけた、ＰＢＲ先のパス監視問題についてまた話し始めた。やはりファイヤーウォールがあるらしく、それの設定変更は考慮になかったようで、それが追加になることや、インターネットＶＰＮ、ポリシーベースＩＰＳｅｃ部分についても、設定変更や設計変更は想定しておらず、その部分に対しても追加工事になるので、再見積もりだというような話になっている。彼らにとって別のベンダー、つまり都たちキャリアがいる目の前で揉める訳にもいかないからなのか、笑顔を交えながらのやり取りになっているが、そもそも良好な関係なのかもしれない。
お客は、デフォルトゲートウェイ冗長プロトコルのメインとバックアップを逆にすれば、設定変更箇所、箇所というよりは金額なのだろうが、減るんじゃないかとベンダーに聞いていた。ベンダーは、どうですかねえ、とあまり真面目に取り合う気がないような返し方をするので、恰幅の良いお客が都にその話を振ってきた。
「これ、どうお思いになられますかね？」
ごく普通の質問、という風に聞いてきたが、これに発言の責任を持たされては堪らない。ベンダーの機器のコンフィグがどうなるかを聞かれているのだから、答えようがない。
「えっと、正直申し上げて、私たちが触るルーターでははないので…。」
詳細はベンダーとお客とで詰めてもらう必要があると断った上で、都は、冗長デフォルトゲートウェイプロトコルだけ、メインをベンダーのルーターにしたとしても、例のサーバー宛のトラフィック以外は、都たちのＭＰＬＳ網を通したいのというのであれば、考慮しなければならないことは多いと返した。ベンダーのルーターで、都たちのルーターの方へ、通常のパケットについてはルーティングしてもらわないといけない。仮にスタティックで切るにしても、現状ＷＡＮに向いている、ポリシーベースのＩＰＳｅｃに乗せるために切ってあるスタティックの方が強いので、これのＡＤ値を上げるとか、都たちの方を向いているスタティックの方がロンゲストマッチになるようにするとかしないといけない。もちろん都たちの網はＭＰＬＳだから、フルメッシュトポロジーなので、個々の回線を死活監視しないといけないが、それはあまりにも煩雑過ぎる。都たちのルーターとベンダーとのルーターで、ダイナミックルーティングを回して、ルートを都たちのルーターから受け取った方が効率が良い。その場合も、必ずこのダイナミックルーティングが、ポリシーベースのＩＰＳｅｃに乗せるためのスタティックルートよりも、ロンゲストマッチか、強くならないといけない、云々。
「…という感じで、いろいろたいへんな感じだと思います。」
都は、最後は曖昧に締めようと思ったら、なんだかちょっとふざけた感じになってしまった。恰幅の良いお客はうーん、と唸ってしまって首をうなだれてしまった。背の高いお客がベンダーに、当初の設計通り、新しいＭＰＬＳ網をメイン、既存のインターネットＶＰＮをバックアップとし、先ほど都がした指摘については、別途ベンダーの方で検討してもらって、再度必要な見積もりを出すようにとまとめていた。ベンダーは承知した旨、丁寧に返していた。
次に、本社側のＬＡＮの機器更改、トポロジー変更についての話に、話が流れ込んでしまった。都はそんなものもあるんだと初耳だったし、都たちの責任区分範囲外の話なので、正直付き合う必要もなさそうだが、ここは客宅の会議室なので、付き合わざるを得ない。都は、結局未だに座るタイミングを逸していて、ホワイトボードの前に立ったまま、話を聞いていた。
現在のトポロジーでは、本社のインターネットＶＰＮルーターから直接、本社ＬＡＮのコアスイッチへ接続しているのだが、都たちのルーターをコアスイッチ、インターネットＶＰＮルーターとも同じセグメントで接続するために、間にＬ２スイッチを挟み込むという。Ｌ２でこれらの機器間を接続することに何か懸念はあるかと、お客が都に聞いてきたので、Ｌ２なので、コアスイッチからインターフェイスコストで、メイン、バックアップの差分が付けられないから、都たちのルーター、ベンダーのルーターで、きちんと、メトリックタイプを揃えて、メトリック値で都たちのルーターからの再配送ルートがベストパスになるようにしないといけないという、先程ベンダーにも伝えた点を繰り返し言った。お客はさらに、それならＬ３接続、つまり、コアスイッチと都たちのルーター、コアスイッチとベンダーのルーターを別のセグメント、サブネットで接続するならどうかと聞いてきた。都は、管理上のデマケーションの区分し易さや設計のし易さなどはその方が良いが、ただ、ＰＢＲはコアスイッチでやってもらう必要があると説明した。恰幅の良いお客は即座に、Ｌ２で行きましょう、と言って、背の高い客やベンダーの笑いを誘っていた。
コアスイッチはハードウェア保守はベンダーがやっているようだが、設計や運用管理についてはお客がやっているとのことだ。それは本社内のレイアアウト変更や急なネットワークの追加などあった時に即応できるためだそうだが、そのためあまり込み入った設計や、複雑な設計を入れたくないとのことだった。設計をシンプルにしておくようにする、ということは大事だと都は思った。それが面倒を避けるためであっても、結果的には運用上のトラブルが減り、実際の業務やビジネスといったものに与える影響も小さくなる。
コアスイッチ更改と同時に、変更するトポロジーやアクセススイッチの話を、都たちとは関係のない、本社ＬＡＮ内の構成図を大型ディスプレイに映して、しばらくお客とベンダーは話していた。都はずっと立っているので、少し足が痛くなってきた。もう１時間くらい立っているかもしれない。腕時計を見るのは失礼なので、見ないようにしていたが、座りたいな、と思い始めた。営業と岸谷が何か小声で話しているのが見えた。
「間宮さん。」
岸谷が振り返って、小さい声で言った。小さい声でも通る声なのできちんと聞こえる。
「座りましょ。」
岸谷は少し首を傾げながら、柔らかく言った。ふと隣の営業を見ると、営業も頷いていた。二人の顔には都を労う表情が見て取れて、都はちょっと安堵したような気持ちになった。
「すみません、立たせたままにしてしまって。」
背の高い客が席に戻る都に声をかけた。都は恐縮しながら否定を返した。都が自分で座るタイミングを見計らって、席に戻ってしまえば良かっただけなのだ。都は不器用だなあ。ふと、兄が面白がって都をからかう声が聞こえてくるような気がした。都は席に座ると、岸谷を見て、小さな声でありがとう、と言うと、岸谷は目を細めて笑顔を返してくれた。
本社コアスイッチ更改まわりの話が続いたが、時折、都はお客から助言を求められた。Ｌ２区間については、普段やらないのでわからない、で返していたが、Ｌ３のルーティングについては、営業が止めに入ってくれないので、それは可能な限り回答して欲しいという意図だから、何々だと思います、とか、何々ではないかと思います、とか断言しないように気を遣いながら意見を述べるしかなかった。
かなり長い間、このお客管理のコアスイッチ更改回りの話が続いた後、実際のＬＡＮ切り替えの話になった。恰幅の良いお客が、日本については回線敷設の遅れはほぼないと聞いているのが間違いないか、と聞いてきた。本社と最初に切り替える国内のある１拠点は、開通日、ここで言う開通日とは、客宅ルーターも設置し、ＷＡＮ開通まで完了する日、と言う意味だが、１０月の第４週にそれぞれ予定されていた。岸谷が標準納期には収まっているので、現地調査の結果で問題がないようであれば、ほぼ間に合うと思われると、相変わらず落ち着いた調子の、ビジネスしゃべりで話した。営業が後を引き取って、現地調査については、先日お送りした日時に、現地調査のベンダーが伺う旨と、本社と最初の切り替え拠点の現地調査は営業も立ち会う旨言った。
この最初の２拠点のＬＡＮ同時切り替えは、１１月の第一日曜日の１７時からで決めてしまいたい、とお客は言った。開通日から一週間バッファがあるのだから、万が一回線が遅れた時は、その一週間でなんとかするようにと、丁寧な口調で依頼してきたが、圧は感じるので、絶対にその日に間に合わせろ、と言うことだろう。こういうネットワークの大きな切り替えについて、必ずその日にやるからなんとか間に合わせろ、とプレッシャーを掛けてくる案件に限って、ＰＭの頑張りや、マネージャーのエスカレーションの繰り返しなどで、とても間に合わないような回線を間に合わせても、お客の準備が整わず、延期を繰り返して、最後には回線を急いで開通させる必要が全くなかった、という結果になることは少なくない。
しかも、この本社とパイロット拠点のＬＡＮ切り替えの日に、同時にお客コアスイッチの更改も実施すると言う。これには営業が、問題が起きた時に切り分けが非常に難しくなる懸念を伝えてくれた。都は、営業がそれを言わなかったら、自分が言わないといけないだろうと緊張し始めたところで言ってもらえたから、小さく溜息が出てしまうくらい安堵した。こういう点は、流石に言ってくれるのかと、この営業はお客の言うことを全部聞くだけだと都は思ってしまっていたので、少し意外だった。都たちキャリアの責任区分範囲と、お客の責任区分範囲とで、同時に大きな切り替えをするのはリスクが高い。岸谷には未だ肌感覚としてそれがないだろうから、どんなにＰＭは自分なのだという意識を持っている岸谷でも、自らこの点に苦言を呈するのは難しかったろう。
お客は、このＷＡＮ更改に合わせて、コアスイッチの更改をするのは、半年以上前から計画しており、そう何度もネットワークを止める訳にはいかないので、懸念は理解するが、同時に実施する、と言ってこちらの意見は撥ねられてしまった。ベンダーも、以前からこの方針には反対しているらしく、先日も言ったが、と言う前置きをして考え直した方が良い旨提案してはいたが、２回に分けるのはどうしても業務に与え得る影響が大きい、ネットワーク断はこの一日にしたい、とのことで曲げてはもらえない。
それでも、まずはＷＡＮを切り替え、既存のＬＡＮ環境で一度全てのテストを実施して、それからコアスイッチの更改作業、コアスイッチ更改後の環境でお客テストを実施する、ＷＡＮの冗長試験は、既存のＬＡＮ環境で実施する、という段取りで擦り合わせが出来た。都たちにしてみれば、既存ＬＡＮ環境でお客試験、冗長試験を実施したところで、都たちの工事は終了で良いのだがら、そう営業に押し切って欲しかったが、ＷＡＮの切り替えも、コアスッチの切り替えも同時にやりたがったお客に、きちんと別々に工程をわけて実施させるには、都たちがコアスッチ更改、テスト終了まで待機することを交換条件のように提案せざるを得なかった。当日は終電か、翌朝始発で帰るか、どちらかだな、と都は思った。間違いなくトラブルだろう。出来るだけ都たちの責任区分範囲でトラブルが出ないようにし、極力ＷＡＮの切り替えはオンタイムで、むしろ前倒しで終わるようにしないといけない。しかし、いくら都たちでトラブルが起こらないようにしても、ベンダーやお客で考慮漏れ、都たちに伝達もれの事項があると、都たちの落ち度がなくても、それに引き摺られる可能性だってある。お客からのヒアリング結果に基づいて設計するしかないのだから。
これは検証環境を組んで、シミュレーションしておかないといけなさそうだと、都が考え始めると、お客がもう一つ注文をつけてきた。
「切り替え当日なんですが、先日、切り替え当日は、御社は基本的にリモートでスタンバイということで伺っておりますが、不測の事態が起きた時のために、ＳＥさんにですね、当日は弊社へおいでいただきたいのですが。」
都は一瞬、現場作業員の会社から、ＬＡＮ切り替えのためだけにスタンバイ要員を、しかも週末夜間になる工事のために、出すことになるのだろうか、と思ってしまった。そういうことは稀にはあることだ。しかしそうではなくて、今日設計についてずっと話してきたＳＥ、つまり都に来てくれ、ということだった。
「…行けますかね？基本オンサイトは出さないのは知ってますが…。」
営業は少し会議卓に被さるように背を前に倒して、岸谷越しに都を見ながら聞いた。その声には、受けてもらえますよね、という強要とも懇願とも取れる調子があった。岸谷は、グローバルＭＰＬＳ担当では基本的に現場作業員を出さない、という基本姿勢なんかどうでも良くて、何か期待するような瞳の色をしていた。都は思わず笑ってしまいそうになった。都はそもそも、現場作業でしか見えないこともあるという考えだし、お客範囲の切り替えにも付き合わされるのだから、この件は現場にいた方が良いと思った。望まれなくても、岸谷には当日現場作業員として行くと、都は自分から言っただろう。たとえ行けないと言ったところで、この営業の上長から、岸谷の上長へエスカレーションが上がって、行かされるだけだ。
「はい、大丈夫ですよ。私がお伺いさせていただきます。」
営業は、ありがとうございます、というと、会議卓の向かい側でも、お客二人がよろしくお願いします、と軽く頭を下げていた。ベンダーは彼らの目の前に広げたＰＣの画面を見ていたので、表情は読み取れなかった。ふと岸谷が都を見ているのに気がついたので、岸谷に視線を送ると、岸谷は小さく、ありがとうございます、と言って頭を下げていた。都はううん、と首を横に降った。間違いなく、その日は絶対に帰れないから、新幹線の切符は行きだけにして、宿を取っておかないといけない。