NTTドコモの回線障害の根本原因を推測する
NTTドコモまた通信障害、背景にグループの足かせ 技術者が慢性的不足 カナ速
なところに、「技術者不足」とあるけど、単純にゼネコン体質だから、というのが結論
以前、ドコモの仕事をしていたので、内実を想像すると（10年前なので、今は違うかもしれない）、
- NTT は、NTT Docomo の親会社である。
- NTT Docomo が、基地局の設置、ソフトウェア開発を指揮している。
- 基地局のハードウェアは、外注（どこかしらないけど、NEC とか？）
- 回線のソフトウェアは、富士通などに外注
- 富士通から富士通の子会社に外注
- 子会社から、協力会社へ外注
- 協力会社から孫会社あるいは、派遣会社から人員を募集 ← ここが、ソフトウェア技術者
になっている。この体制は、建築業界のゼネコンと変わらない。
ドコモや、富士通は何をやっているかというと、親会社と協力会社（下請け会社）との調節。
ソフトウェア開発自体のマネジメントは、下請け自身が普通行う。
派遣社員は、大抵が、ソフトウェア開発歴が5年以下の新人（ソフトウェア業界では「新人」ではないけど、他の業界から云えば、5年以下の経験なんて、経験と言えない）が担当する。
なので、ソフトウェアの中身は、内実、新人が担当していると思っておけばよいのです。
じゃあ、設計はどうなっているかというと、確かにシステム設計っぽいもの、はできてはいるのですが、大抵は「机上の空論」が多くて、「日本語」でしか書かれてない仕様書、設計書が多い。なので、この手の障害に直結するような、ウエイトのかかる部分は、新人プログラマの力量に掛かっていると云えます。当然、お分かりの通り、「新人プログラマの力量」なので、たかが知れています。
受託開発の罠
http://moonmile.net/mymy/solution/008.html
を書いたころには、血気盛んなこともあって、なんとかできるのでは？と思ったものなのですが、いえいえ、なんともできませんね。記事自体は、2004年に書いたものですが、ほころびが今になって出てきているという感じです。
あと、この手の受託開発プロジェクトから、今の私は抜け出してしまった（稼ぐという意味では、どこかに派遣は行きますが、自分の意志でできるという点で今のほうが断然良い）ので、この手の大手の会社の技術力の無さによる（無さというか、もともと無いのだから、今後も技術力が付くわけがない）弊害は、私にとって別世界となっております。勝手にやってください、という感じです。
以前は、アジャイルとか、制約理論とか、プロジェクト管理に原因がとか考えていたのですが、いやいや、成功するプロジェクトは必ず成功します。失敗するプロジェクトは必ず失敗します、というだけです。プロジェクトの構成員（プロジェクトマネジャ、顧客の要望、技術的なバックグランドを持つメンバ、補充すべき指針）などが揃っていれば、ほぼ 100% でプロジェクトは成功します、というだけです。
～
さて、技術者不足...だけでは、解決にならないので具体的なドコモの障害の原因を推測するに、「制御機器のバッファオーバーラン」ではないか、と思っています。バッファオーバーランというのは、確保している以上のメモリにアクセスしてしまうハッキングの手段なのですが、初心者が頻発する初歩的なバグでもあります。
ドコモのような24時間運転の機器の場合、内部では java や c# のような vm を使うことはできません。大抵は、unix マシンに c 言語で書きます。vm を使うとメモリの浪費が多いのと、メモリ配置が予測できないので「使えない」のですね。そして、c 言語を使うにしても、malloc や free を禁止しています。malloc を使うと、同じくメモリの配置が予測できないので、使えないのです。なので、監視系の場合には new/delete を繰り返しても良いのですが、メモリのフラグメントが重大な「事故」になってしまう運用系の場合には、あらかじめ巨大なメモリ/配列を確保する、ということをやります。こうすると、あらかじめメモリの配置が分かるために、メモリ確保による不具合が出にくいのです。
で、配列にする場合、アクセスをインデックスで参照させるわけですが、このインデックスが範囲内で収まっている（回線が少ないとか、最大値以下だとか）間は、最大値のチェックを忘れていても動きます。おそらく、いままでのドコモの場合は、そんな感じです。ですが、ひとたび回線が混雑する状態となり、配列の最大値までアクセスしようとする場合に、一気に不具合がおきます。
この不具合がどういう現象になるかというと、通常は不正なメモリアクセスのためにコアを吐く（アプリケーションエラー）となることを想像するでしょうが、実は「あらかじめ配列」を確保しているために、バッファーオーバーランをしてしまうと、隣にある「一見正常そうなメモリにアクセスする」という現象が発生します。なので、アクセスしただけでは落ちないのです。なので、「一見正常な値」を拾ってくるために、一見正常そうな動きをします。以前もあった、sp メールの誤配信の状態がこれで、メモリアクセスが不正であれば配信自体が起こらないのですが、「誤配信」をするところみると、隣のメモリにアクセスしてしまった、と考えます。逆に、この現象から、現在の運用系のプログラムが、主に固定配列を使っていることが想像できます。
この固定配列の方式は、基地局自身に含まれるファームウェアにもあるわけで、いえ、むしろファームウェアのほうが固定メモリが多いのですが、ここでも似たような原因で不具合が発生します。通信障害のように通話ができない≒サブ機器が動かなかった、という問題は、実は２つの原因があります。
- 回線障害のもとの原因は何か？ハードウェアの故障？ソフトウェアの不備？
- 切り替えが正常にできなかったのは、何故か？ハードウェアの故障？ソフトウエアの不備？
前者のほうは、ハードウェア機器が壊れる確率も結構高いので、ソフトウェアの不備だけとは言えません。しかし、後者のほうは、スタンバイしているハードウェアの故障が重なった、とは考えにくいですよね。よく知られているように、この手のバックアップの器械って、きちんと動かないのが常なのです。なんのためのバックアップか分かりませんが....
なので、大抵、バックアップのほうが正常に起動できなかたのは、バックアップ機への切り替えを行う、ソフトウェアの障害（というか、不備）が原因です。自動切り替えができないのですが、手動切り替えができる、っていうのがミソですね。自動（ソフトウェアによる）切り替え試験が非常に足りないのです。かつ、切り替えソフトが駄目駄目すぎる。
となると、切替ソフトが駄目駄目なのですが、それと同じ技術力しかない開発者（この場合は、孫請けの新人開発者）が作った本体の運用機器だけが「頑丈に」できているワケがありませんね。同じぐらいの品質しかない、と想像できます。
そういう想像から、通常行われる固定配列操作に対して最大値のチェックを怠るような新人プログラマによる開発が主原因で、回線障害が頻発しているのでは？と思っているわけです。そうそう、ソフトウェアのバグは、GKB と同じように、ひとつ見つかれば、10個見つかるものですよ。このあたりは、テスト技法とかQAとかが詳しいでしょう。
そんな訳で、ソースのコードレビューから始めましょう、ドコモさん。いえいえ、コードレビューができる方は、ドコモ社内にいるわけはないのですが...頑張ってください。
ネタ的に DeNA の会員数も概算してみる
GREE のアクティブ会員数が、53万人程度だとしたら、果たしてモバゲー（DeNA）の場合はどうなんでせう、と思って調べてみます。
(株)ディー・エヌ・エー【2432】：会社概要 - Yahoo!ファイナンス
http://profile.yahoo.co.jp/fundamental/2432
(株)ディー・エヌ・エー【2432】：単独決算推移 - Yahoo!ファイナンス
http://profile.yahoo.co.jp/independent/2432
(株)ディー・エヌ・エー【2432】：連結決算推移 - Yahoo!ファイナンス
http://profile.yahoo.co.jp/consolidate/2432
比較として、GREE も再掲。
単独で計算した場合は、GREE も DeNA も同じぐらいですが、DeNA のほうが売上高が倍ぐらいあるので、単純計算でいけば、GREE の1.5倍ぐらいのアクティブユーザーがいないと成り立たない、営業目標を達成できない、ということになります。
携帯ゲームをしないので、GREE とモバゲーのどちらが会員数が「多そうか？」というのが分からないのですが、まぁ、GREE の会員数が「3000万人」とすれば、モバゲーのほうは倍の「4500万人」ってことになりますね...が、そうはならないでしょう。当然、GREE もやるし、モバゲーもやるという人もいるのでそしょうが、両方に月1万円ずつ突っ込むという人はいない、と思われるので、ここでで計算される、GREE の 53 万人とモバゲーの 86万人は重ならないと思われます。
DeNA のほうを連結で計算したときには、営業目標はひとりあたり7000万円。この金額が、GREEの8500万円と似た位置にあるので、高額の平均年収（平均なので、上もあれば下もある）を支えるには、これだけの B2C の売上とアクティブな会員が必要な訳です。
GREE のアクティブ会員数を概算する
3000万人の会員数を誇るGREE利用者があまりにも回りにいないので調べた結果、本当に住む世界が違ったという話（Yamada_nt） - BLOGOS（ブロゴス）
http://blogos.com/article/30874/
なところで、アンケートを取ってみたようので、私のほうは売上高から概算してみましょう。
グリー株式会社 | IR情報 | 財務ハイライト | 業績ハイライト（連結）
http://www.gree.co.jp/ir/highlight.html
グリー(株)【3632】：会社概要 - Yahoo!ファイナンス
http://profile.yahoo.co.jp/fundamental/3632
グリー(株)【3632】：単独決算推移 - Yahoo!ファイナンス
http://profile.yahoo.co.jp/independent/3632
程度があれば、ひとまず十分ということで。
従業員が758名ということなので、単純に売上高から割れば、ひとり頭年間8500万円の売上が立てばOKです。この数値の妥当性は、リコーなどのサービス販売では、1から2億円/年間の目標となるので、まあ、その位というところでしょう。GREE社内の開発者と営業の比率があるでしょうが、基本は、B2C になるので営業職も開発職もあまり変わらない売上目標が想定できる、と考えてよいでしょう。
経費の内訳は、人件費と広告費が主でしょう。まぁ、ハードウェアとか、東電に支払う電気代とかもあるでしょうが（いや、サーバーは違うところにあるかな？）
肝心の会員数ですが、3000万人にすると、一人当たり2,000円使うことになりますね。これは限りなく低いと考えられます。携帯ゲームの売りが、「釣り竿」だったりする訳ですから。
想定として、300万人のアクティブユーザー（10%のアクティブユーザーということです）として計算すると、年間21,000円使うことになります。月に千円ちょっとというところですね。結構、ゲームとしては妥当な人数に見えるのですが、実は、
優位性を得るために、ゲームのアイテムを買う
という営業方針（なのか？）があるので、有料会員 ＞ 無料会員 でないと駄目なんですね。この場合、10人に１人というのは、ちょっと優位性を保つには少ないですよね。
今度は、年間使われる金額からアクティブ会員数を逆算してみまよう。
月に1万円つかうという想定を立ててみます。一見、高いように見えますが、携帯電話の料金が月5,000円から10,000円ぐらいであったり、パチンコ代にどれだけ使われるか、ということを考えると月1万円、年間12万円は、それなりに達成できそうな金額です。
月1万円で逆算をすると、53万人という会員数を得ます。全体の会員数（幽霊会員、アカウントしか持っていない会員も含めて）の比率からすると、アクティブ会員数が 2% 以内になるので、「優位性」が保てます。
こうなるとですね、１億人中53万人なわけで、0.5%。200人に1人というところですね。こうなると、身の回りに「GREE をやっているよ」とう人がいなくても不思議ではないわけで...という感じなのかなと。住む世界が違っても仕方がない。
IT企業の場合、仕入れがほとんどない（ゼネコンIT企業は別として）ので、営業目標が 8500万円というのは、どうなんでしょうか？結構高いような気がするけど（正確には、営業目標というよりも達成された営業目標ですが）。他のIT企業と比べてみると分かるかなと。
試してに出してみたのがこれ。まぁ、普通はこの営業目標が普通ですね（連結ですが）。参考まで。
