今回のソフトバンクの件でシステムの脆弱性が問題になりました。
後だしジャンケンのように、状況を見ながら私は最初から判っていたと騒ぐコメンテーターは別として、最初から予測していた人も少なくないでしょう。
それに何故気がつかなかったかは、テレビでは急過ぎる変更が混乱を招いたと報道していますが、ＭＮＰの流出が原因だったと発表している事からも少なくとも 直接の原因ではなく、トラフィックの問題は有りますが「予想外割り」をやって無ければ流出に歯止めがなくもっと早く落ちていたかもしれません。
恐らくソフトバンク独特の仕組みの主回線・副回線と言う構造でＭＮＰで主回線が他社に移動して、主回線の代替わりで下手すると請求書の送り先まで変わってしまう顧客情報の変更を行い（残債があるので主回線の請求書はどこかに置いといて）最適な主回線を探す作業を行っているソフトバンクのコンピューターはとりあえず別の電話会社に移転の情報を投げて、その後当然のように繰り上がりで主回線になった副回線もＭＮＰで移動するというような作業が繰り返されるとシステムのパフォーマンスが落ちているときであれば 最初のリクエストは返事できても次のリクエスト時には未だ繰り上がり処理中の副回線の解約に対してタイムアウトが起きてもおかしくはありません。
孫さんの言う「複雑な料金体系」があだになった形でしょう。
故にＭＮＰの停止はシステム管理者の大英断で、僅か数時間ででおおよその原因を突き止めた辺りは優秀な人がいるのでしょう。
障害原因をとめればそれ以外の処理はうまく行くのですから。
結果的には、システム的には孫さんのお陰でうやむやになったところもあるかもしれません。
業界内で取り決めた、ＭＮＰの仕組みが遅延ならともかくタイムアウトぐらいで落ちてしまうのは 少なくともちゃんとした再送ルールが予定されていなかったのではと疑ってしまう状況です。
そうなった場合には、事は業界全部に行き渡り 全体でＭＮＰをなめていたと言う事になるわけですから。
さて、このシステムなのですが以前は 人が手でこなしているものを機械に置き換える作業でシステム化が進んでいました。
しかし、今は逆にシステムを作ってランニングしながら現場に落とし込むと言う導入方法が多くなってきています。
故に読みが甘いと、現場にシェイクダウンしてから後の工数が増え 採算性の悪いシステムの導入に企業もＳＥも苦しむことになるのですが・・・
それはともかく、今回の件でもそうですが孫さんも含め上層部が頭の中で考えたことを システム化する。
事実かどうかはともかく「予想外」な処理をコンピューターに要求した。
当然要求を満たす仕様のものは作ってあったのですが シュミレーションを繰り返したというシュミレーションは、過去にあった事例から起こしたシュミレーションで本来「予想外」を本当にしたのであれば それに伴うシュミレーションでは出てこない障害を想定した試験が必要になります。
その障害の発生する可能性は、人間が頭の中で考えて その発生すべき障害を列記してテストでつぶしてゆくしかないのです。
システムの管理者は、常に現場とともにあり 現場で発生する業務を熟知し それによって起き得るであろう問題を考えるだけの能力を必要とするのです。
実際問題難しい限りです。
今まで人が行っていたことを機械化する段階では、現場がつぶしていた問題点を これからはその時点でつぶさなければいけなくなったと思うと これからもシステムトラブルがなくなることは無いような・・・・
少なくとも号令一つで会社が動くと思っている管理者の人の下でいる限りは辛いところでしょう。
