05-06
オフショアセンターは東京からプロバイダエッジ装置の設定についてあれこれ言われるのをあまり好ましく思っていないと聞く。都はその気持ちはわかる気はした。
案件によって、お客と都たちＭＰＬＳ構築担当の間に別の部署が挟まることがある。挟まる理由は通常のＭＰＬＳサービスの構築に含まれる調整、統制以上のプロジェクトマネージメントが必要になるからだ。ＭＰＬＳサービス以外に、クラウドやセキュリティサービス、拠点のＬＡＮ周りの構築などもお客が導入する場合、本来であればお客自身で各サービス毎に異なる窓口と対応しなければならない。サービスによって窓口が異なるのはお客にとって煩雑だし、場合によっては同じことを異なる窓口それぞれに説明したり申請したりしなくてはならない。お客にかかるストレスは徐々に高まり、顧客満足度の低下を招く。
それを避けるためには、お客の要望をよく理解した上で各部署と連携し、各サービスの構築を統括してマネージメントする担当が求められる。ワンストップにお客との窓口となり、お客ＩＴ環境のシステムインテグレーションとして様々なサービスを統括し提供することを企図している部署がある。その部署から全体統括ＰＭとして人やチームがアサインされる。このようなプロジェクトの場合、全体統括ＰＭがサービス毎に必要な事項をまとめてお客からヒアリングする。各サービスにおいて進捗が思わしくない時は事実ベースで各部署から報告してもらい、お客への出し方を考えたりもする。
また、ＭＰＬＳで設置する客宅ルーターのＬＡＮ側にＬ２機器やＬ３機器をシステムインテグレーションの一環として提供、構築することもある。こういう機器は基本的に都たちの部署の責任範囲外だ。ＬＡＮ機器も提供するとなると、その全体統括ＰＭチームにはシステムインテグレーションとして全体を設計をするＳＥが加わることになる。
全体設計を担うＳＥが全体統括ＰＭチームにいると、そのチームが客宅ルーターのコンフィグに口を出してくるようになる。事前にコンフィグの提示を要求されチェックを受けたりするのだが、担当者によってはああしろ、こうしろ、この行はなんだと細かいことをいちいち言ってくる。まるで検閲みたいと都は心の中で悪態をついてしまう。
例えばＢＧＰのフィルターにはいくつか設定の方法があるが、効果としては同じというものがある。いくつかのルートをフィルターしたい時、フィルター対象のルートを否定で定義していき、最終行にそれら以外全部を許可する定義で締めたリストを作成する。そしてそのリストを直接ＢＧＰのネイバーに適用する。都はまずこの方法は取らない。
それとは違って、フィルターしたいルートを許可定義で並べただけのリストを作り、それとは別にポリシーを作成する。ポリシーの最初のシーケンスでそのリストにマッチしたら否定し、次のシーケンスで残り全てを許可する。そしてこのポリシーをＢＧＰのネイバーに適用する。都はこちらの方法を必ず取っている。どちらの方法でもフィルタ対象のルートは拒否され、それ以外は全て受信されるという挙動になる。
後者の場合、万が一受け取るルートに重み付けを変更する必要が出てきた場合など、微調整がし易い。否定羅列型のリストを直接当ててしまうと、細かい調整をするには、リストを作り直し、ポリシーを新たに作らなくてはいけない。極端な例を挙げると、対象のルートを拒否するフィルターではなく、対象のルートのみを許可するフィルターに変更したい場合、前述のやり方だとリスト全部を作り替えなくてはいけないが、後述のやり方だと、リストはそのままで良く、ポリシーの最初のシーケンスを否定から許可に変え、次のシーケンスを許可から否定にするだけで良い。
全体設計の担当ＳＥによっては、この都のやり方は無闇にコンフィグを長くしているだけだと映る。リストを当てるやり方に変えるよう指摘を受ける。よりわかりやすく、よりシンプルにするために、という注釈つきでだ。都が心配しているような急な変更の必要性などそうは起こらないのでやり過ぎだとも言われる。こういう指摘があると都は内心非難されているように感じてしまう。効果が同じならどっちだって良いじゃないの、という投げやりな思いと、客宅ルーターの設計はこっちの仕事なのに、という意固地な思いとで心がささくれる。だから海外オフショアセンターも彼らが設計責任とコンフィグ権限を持っている機器の設計について東京から指摘を受けるのは面白くないだろうことは想像に難くなかった。文化も環境も違う異国の人間が本当に都と同じ理由で面白くないと思っているかは疑わしいのだが。