　メアドも甘くみてはいけない

　翌水曜日、牛尾は、研究での進行中プロジェクトを、一旦プロジェクトリーダーに預けるべく、午前中に引き継ぎを終わらせ、再度本社に向かった。これからは毎日のように本社に通うことになりそうだ。

　伊賀を本部長室にたずねると、そこには、外川部長がいた。伊賀は牛尾をみると

「おぉ、ちょうどよかった。外川はしってるよな？彼が今回のプロジェクトをリードするから、彼をサポートしてやってくれ」

　と伝えた。外川も技術畑ではあるが、IT初心者のはずである。なぜ？？？どうやら、インターネット常時接続が至急にもすべき、と進言したのが外川らしい。牛尾は以前、外川とやりあったことがある。研究所のイントラネットをインターネットに繋ぐ、繋がない、で大激論をやらかしたのだ。牛尾は、繋ぐこと自体は反対ではないが、あくまでもそれはセキュリティが確保されたら、という大前提があってのはなしで、現実的にそれができるとは考えていなかった。一方、外川は、情報は使いこなして価値が出るもの、アクセスできなければ使えない、使えなければ意味がない、という考えの持ち主。

　牛尾は、研究館内のイントラネットを設計する際に、各部門のITキーマンとなんども話をしてきた。その時に最も皆が気にしていたのが、情報を不正にアクセスされないだろうか、という懸念だった。もともと研究館内のLANは、性善説のイントラネットだった。それでも、万が一にも悪い奴がいると、大切なデータベースが抜かれてしまうことはリスク。議論では、それに対して、どのように保全するか、に多くの時間を費やした。結果として、データの重要度を三段階に分け、ネットワークをこの重要度ごとにゾーニングした経緯があった。社内閉鎖ネットなので、多少の時間のズレは許容できると踏んで、通信監視、つまりIDS[注2]検証はキーワードでピックアップする方法で運用し、定期的な統計検証で十分であろう、という結論に達し運用が開始されていた。

　動き始めて３ヶ月。そこに外川は、いきなりやってきた。・・・と思ったら、これまでの経緯は一切お構いなしに、インターネットにつなぐことの効果を最優先すべき、と言いだしたのだった。さすがに牛尾は「ちょっとまって、セキュリティはどうするんです？」と噛み付いた次第。

　数時間激論の上喧嘩別れをしたのだが、その中で外川は牛尾に、

「セキュリティーっていうのは、広い意味があるんだ。お前は不正アクセスをいかに防ぐか、しか考えてないじゃないか？それはセキュリティのほんの一部だ。不正アクセスをふせぐことは、もちろん大事だけど、いまやファイアウォールもしっかりしたものが買えるんだから、心配するな。それよりも、使えないデータは守る必要もない、守らなければならないデータは、使えなければ意味がない。長年積み上げてきたデータベースを、どうやって安全にアクセスさせるか、どうやって壊されないようにするか、万一こわされても元に戻せるようにしてあるか、そちらのほうがよっぽど大切なんだぞ。データの重要性、守るべきもの、これは自分たちにしかわからないんだからな。お前の考えでは、インターネットに接続なんかすべきでない、ってことになっちまうぞ。それも一つの考えだが、それでグローバルの情報主導の市場で勝てると思うか？」

　と言った。この言葉で牛尾は『お、この人、ITの細かい話はわからないらしいが、本質的な視点でものを見てるんだな』と、知ることができた。大事なことが何か、守るべきことが何か、それに対して何がリスクか、リスクを顕在化させないためにどうしたら良いか、回避策は。それでも顕在化した時に、被害をできるだけ小さく済ませるために何をしておくべきか、この思考回路で議論ができる人なら、軌道修正しながらでもリーズナブルなゴールに向かうことができる。

　そんな背景から、伊賀本部長室で、外川と対面しても、構えることなく、

「よろしくおねがいします」

　と自然に口をついて出た。

　専門家ではない外川がリーダー、自分も本来は門外漢。でも、ポイントは専門性ではない、ポイントを見極められるか、という伊賀の考えは、ある意味もっともなものだったのかもしれない。さすが、噂通りのタヌキだ。

　何も考えずに、インターネットにつなぐことありきで安全を考えないアクションが進みそうになったら体を張ってでも止めよう、でも、安全第一でのアクションは、リスクを抑えながら一歩ずつすすめよう。

　実は、その段階で安岩産業では、国内最大ベンダーの一つ、藤留に全ての情報システムを頼っていた。メールシステムは、藤留が提供している一般向けサービスの一部を借り、掲示板は、有償の電子掲示板サービスの一部機能を使用しているだけであった。そのため、ドメインは藤留、しかも、当時の電子掲示板は、「ダイアルアップ」。つまり、日に何度か、モデム経由で電話をかけてメールを取りに行かなければならなかった。これでは、さすがにビジネスで電子メールを使える環境、とは言えないのは事実であった。館内ではセキュリティにある程度妥協ができるので、牛尾は館内のメールシステムを構築したわけで、オープン系のsendmailを使用していたが、インターネットへのゲートウェイ化はまだ実現していなかった。技術的にはすぐにつなげるようになっていたが、セキュリティのリスク評価がなかなか進まなかったためである。専門家にその辺を確保してもらえればなぁ、と常々思っていたのである。

　牛尾は翌朝、出社すると、外川から「明日、プロバイダ候補選定の打ち合わせをやるぞ、空いてる時間あるか」と言われた。今回のミッションを受けて以降、牛尾は本社に出社しているものの、特に大きな仕掛り案件はまだない。「いつでも結構です」とこたえた。

　次の日、朝9時。打ち合わせ室には、今回の常時接続に向けた対応プロジェクトメンバーが顔を揃えた。外川がまず、切り出す。

「プロバイダー選定は、入札で行う。社内インフラの整備とシステム開発提案も含めたProposalを出させる。今使ってるキャリアの藤留ももちろん候補だが、３社相見積もりでいくぞ。他二者は、藤留と同等の国内二大プロバイダのMKK、もう一社はITコンサルベンダでトータルにやっているブロードバンドサービスビュロー社、いわゆるBSBにする。何か意見や質問はあるか？」

　情報システム部の菅井が

「現在既に、基幹と社内ネットが藤留で動いているので、藤留ベースで進めるのが混乱がないと思いますが・・・」

　外川はすかさず

「藤留は基本的には外す方向で考えている。これは、今まであまりにもジャブジャブになりすぎていると見えるからだ。藤留側も、競争の原理が働かないので、自分のところに必ず来る、という甘えがあるよな。基幹とオープンの共存はリスクが大きい、などと言っているのも藤留だけだ。今現在のインフラを持っているところであるので、候補にはするが、入札の結果同等なら、藤留ではない方を選ぶつもりだ」

「・・・・・」

　外川は言い出すと、よほどのことがなければ意見を変えることはない。もちろん、リーズナブルであれば、聞く耳を持つ、という意味ではとてもよいリーダー資質なのだが、多くの人が、そこにたどり着く前に、けんもほろろの扱いと感じてしまう、誤解を受けやすい、損な性格であった。ここでも、情報システムプロパーの菅井は口をつぐんでしまった。こうなるともう、あとは流れに任せるのみ。

「では、異見がないようなので、３社にRFPを出す」

「どのような内容となりますか？」

　牛尾は聞いた。正直、専門家ではない自分の負担ができる限り小さくなることを期待して、のものである。

「インターネット常時接続、もちろん、電子メールのアドレスも自社ドメインを使うぞ。アメリカの拠点がすでに、yasuiwa.example.com [注3]を取得して運用してるから、それをグループ全体に広げるだけだ」

　会議の隅の方で、情報システム部の数名がコソコソ話をしているのを見とがめた外川は

「おいっ、発言したいことがあれば発言しろっ！コソコソ話をしてるんじゃないっ！！」

　外海は、ちょっと気まずそうな顔をしながら、

「・・・日本でも独自ドメインのメールアドレスが欲しい、という意見を受けてドメインを取得したところですが、どうしますか？今のメールの環境からの移行をどうしますか？yasuiwaドメインを使うとしても、今海外で運用してるわけで、それをどのように移行しますか？誰が？その後の運用は？それ以外にも、色々と不明な点があるのですが、RFPを書くのにも、色々決めないと・・・ちょっと見えないところが多すぎますね」

　外川は苛立たしげに

「だから、それを考えるのがお前らの仕事だろう」

「yasuiwa.example.comにこだわる理由は？」

「いまどき、会社名ドットコムは常識だろう！」

「べつにそうは思いませんけどね。そうでない会社もいくらでもありますけどね」

「それに、今のメールアドレスは、記号と数字の羅列で、誰が誰だか覚えられないじゃないか」

「あれは選べるんですよ、重複していなければ好きな名前に。デフォルトで記号と数字がふられるだけですから」

「そう言うことを言ってるんじゃない！メールアドレスは名刺にも書くんだ。会社としてきちんとしている、ということが伝わらないだろうが」

「・・・・・」

　ちょっと険悪な沈黙が場に流れ、牛尾はたまらずとりなそうと

「お二人とも考えてることはそれぞれに筋が通っていると思います。メールアドレスってお客さまに覚えていただきたい、となると、メールアドレスのドメイン部分は、会社名になるとわかりやすいというのは確かです。しかし、その管理コスト、特にトラブル時の復旧までのダウンタイムでの機会損失をどう捉えるか、TCO、トータルコストオブオウナーシップで考える必要がありますね。ドメインをどうするか、にかかわらず、運用は完全に専門業者に丸投げ、これがベストであることは、お二人に共通ですよね」

　話し始めたら止まらなくなってしまった。

「では、そこで、独自ドメインの運用を業者に投げるか、もともと業者が提供しているメールサービスを利用するか、考えてみましょう。メールアドレスのアカウント部分は、あまりにルール通りにメールアドレスを作ると、無作為にメアドを生成するロボットからの迷惑メールを受けやすくなるリスクもあります。プロバイダのアカウントって、大抵機械的に記号と数値の羅列で発行されるんで、凄まじい量のspamメール[注4]を受けるリスクになります。ドメインがメジャーなものであると、なおさらです。もちろん、その意味では自分でメールアカウント名を決められるのは有益ではあります。たとえドメイン部分がメジャーであっても、アカウントでしっかりと独自性を出して迷惑メールをある程度軽減はできるでしょう。でも、、、変なニックネームでつけると、お客様に不信感を与えるリスクにもなります。それより何より、、メジャーなプロバイダのドメインで、つまり会社以外の人も使うドメインでの運用にするリスクって、セキュリティポリシーがプロバイダに依存する事だったりするんですよね、、、これ、、社内外双方向でお互いに迷惑をかける可能性があるんです。実は今、会社で使っているドメインが、USの有名大学で、フィルタ対象のブラックリストに載ってしまっていて、メールが届かなくなっています。このことが問題になっていないのは、ほとんどその大学とのやりとりがないからだと思います。あれだけ大きなプロバイダなのに、、、どうやらクレームしてるのは私ただ一人なんだそうです。が、私は必要なので、仕方なくプライベートのメールで連絡を取っていますが、その大手プロバイダは対応してくれません。もっと怖いのは、情報遺漏です。例えば、お客様がアカウントをtypoした事を考えてみてください。独自ドメインなら、それでも届き先は目的の会社。でも、プロバイダ名だと、プロバイダ内の全く意図しない人に、極秘メールが届いちゃったりして。。。

　そう考えると、やはりドメインは、責任が会社内で収まるように会社にヒモつく方が良いです。また、安岩グループ間で人の移動があるのですから、グループ内で統一した方がよいです。その場合は一番メジャーなのがドットコムです。ので、まずはドットコムのドメインに統一して、アカウントは名前ベースのルールで作成、が良いと思います。ドメイン内のアカウントが社内に限られるので、ロボット迷惑メールのターゲットになるリスクも、メジャードメインより格段に減ります。ですので、名前ベースのアカウントにしても、それほどはロボットspamの影響は出ないでしょう」

　と、ここで外川がかなりイライラしてるのに気付いて、慌てて、

「まずは独自ドメインの名前を使ったアカウントでスタートを考えてみましょう」

　と言ったところで、とうとう外川が

「ごちゃごちゃ、どうでもいい事をうるさいんだ。もう、そう決めてるんだから、それでいいんだっ！」

　と吠えた。一方で外海は、ずっと憮然としている。こまったなぁ、、と、そのとき、伊賀がその場を引き取るように

「まずは、その辺をはっきりするように、全グループ会社のIT担当を集めて会議をやろうじゃないか。現時点で、くだんの独自ドメインはアメリカ法人が運用してるんだろ？以降の話もあるわけだし。まずは関係者の意見をまとめようじゃないか。ヤスイワインフォメーションコミュニケーション、YICだ」