プログラマに向くのはイヤな奴。年末年始のトラブルに学ぶ世紀を超えた心得

心得其の弐百四十七

メールアドレス漏洩事件

この年末年始のWeb業界を騒がせたニュースといえば、ドコモの「SPモード」のトラブルでしょうか。昨年末の12月20日に、メールアドレスが別のユーザーのものに置き換わるというトラブルから「メールアドレス漏洩」につながる事故が起きました。年明け1月2日には別の不具合が発生しています。これは20世紀のプログラマからみれば、「設計ミス」であり「人災」といってもいいでしょう。今回はとくに「技術系」のWeb担当者への心得をお届けします。

ちょっと待ってくれ「食べログ」の不正操作の方が話題になっただろう。という意見もあるでしょうが、これについては次回を予定しています。とても「現場の心得」が詰まった事例なのですが、「現場色」を強めると黒に近い「グレー」な内容となるので、少しだけ時間をおくことにしましたので。

スマホのふくそうでダウン

事故の概要を報道とドコモの発表から紐解きます。技術解説が本旨ではないので「超訳」となりますが、ドコモのスマホはメールアドレス（正しくは電話番号）とIPアドレスがひも付け（関連づけ）されています。IPアドレスは接続ごとに割り当てられ、随時更新されるのですが、処理能力の限界を超えたことでサーバーが落ち（輻輳【ふくそう】）、一時的に割り当てを更新できない状態となりました。そのわずかな時間に送信されたメールの一部が、更新される前の「古いアドレス」のまま、差出人として届けられたのです。転居届を出す前の旧住所に届いた手紙の差出人を、新しい入居者が見たといったイメージです。

ドコモ自身はサーバーの強化や処理の最適化で再発防止を目指すといいますが、この発想が「設計ミス」であり「人災」です。なぜならトラブルは起こるものだからです。

かつてのコンピュータ

私がプログラマとして社会に出たのは1989年（平成元年）の4月1日、消費税が導入されたその日です。おもにPOSの開発に従事していましたが、NTTのデジタル交換機の開発など、少しずつ色んなプロジェクトを手伝いました。しかしどのプログラム開発の現場でも、システムの要諦が書かれた「仕様書」には必ず「落ちたとき」が想定されていたものです。いまから23年前、落ちないコンピュータという発想自体が存在しなかったのです。

当然、運用の現場でも「落ちる」前提で、さまざまなルールが定められました。POSの場合は、ホスト（いわゆるサーバー）のダウンや、通信が遮断されたときは、「FD（フロッピーディスク）」にて情報のやり取りすることが運用マニュアルに明記されていました。つまりプログラムで開発する部分と、運用の現場での対応策は「設計」の段階から考えるもので、そうした20世紀の視点で見れば、「落ちない」という想定が「設計ミス」なのです。

落ちるという発想

「サーバーの強化」で対応できる……というのが、コンピュータが進化した21世紀のルールなのかも知れません。しかし、所詮は機械です。壊れるときはいつも突然ですし、電気が止まればパソコンは沈黙し、通信が遮断されることは、昨年の東日本大震災からも明らかです。心構えとして「落ちない」と思い込むより、「落ちる」を前提にした対策も立てておくべきなのです。

中小企業サイトで考えればレンタルサーバーが突然「落ちる」リスクがあります。そのとき、Facebookページや、Google+、あるいはmixiページを開設し「電話番号」を記載しておけば問い合わせ対策としての一時凌ぎにはなるでしょう。また、ツイッターやGmailといった情報の受発信ツールの準備はもはや常識です。そしてブログも「アメブロ」などの外部サービスを利用することで安定度・継続性を高めることができます。

もっとも大切な判断

特に「通販」を営んでいる場合には、運用ルールの「設計」が必須です。一例を挙げれば、ネット通販のサーバーが何らかのトラブルに見舞われたときに、

営業を継続するかどうか

という選択です。ネットから注文できなくなっても、電話で発注してくれる熱心なお客もいます。彼らにどう対処するかです。

日頃から顧客台帳などをプリントアウトして保存していれば、電話応対に手書きの伝票で営業は継続できます。パソコンの便利さは望めませんが、紙媒体は故障も停電をものともしません。ちなみに、かつての勤務先で納品したプログラムは、FDやテープストリーマとともに、すべて「プリントアウト」して保存したものです。紙媒体は殴ったり蹴ったりしても、ちょっとぐらいコーヒーをこぼしたとしてもビクともしない耐久性を誇るからです。

そして「臨時休業」も運用時の重要な選択肢です。混乱状態で営業を続けてもトラブルを拡大するばかり。想定外の二次被害、三次災害引き起こさないための「現場のノウハウ」が「止める」です。ドコモの事例では、ふくそうに対しても強行営業する設計からメールアドレスの流出が起きた、とも言えます。

プログラマの心得

人の嫌がることを考えるのが仕事

私がプログラムの師匠に教わった心得です。常に最悪の事態を想定するのがプログラマだということです。21世紀の技術系Web担当者にも通じるのではないでしょうか。ドコモの例に照らせば、メールアドレスの流出とサービス停止を天秤にかけ、後者を選択したのかもしれません。師匠はプログラマに向く性格をこういっていました。

性格が悪いやつ

会議の場などで、その場を丸く収める安易な結論を求めたがることへの戒めであり、課題や問題を見つけ出して嫌われるぐらいがちょうどよいということです。

ドコモの「SPモード」の不具合は「通信量が増大するスマホ」を理由としています。しかし、日本の携帯市場は一部の機種を除き、回線会社が仕様や出荷台数をメーカーに指示します。スマホ契約者の平均パケット数と契約台数をかけ算すれば「標準値」は算出できるのですから、自ずと「販売台数の上限」は見えてきます。仮にこの上限を超え、十分なサービスを提供できないとわかっていながら、熱心にスマホを売り続けた末に起こった障害なら、「経営判断」という名前の「人災」です。