皆様、こんにちは。再びの登場で失礼致します。

通常は、１日１レースのオートレース前予想コラムにてお目汚しをさせて頂いておりますが、前代未聞のレベルとして数日前より発生している競輪でのシステム障害については、分野こそ違いますが本職の方でシステム開発の現場に身を置く者としては見過ごせず、まだ全面解決には至っていない時期ではあるものの、ここでひとつ下名なりの考え方をしたためておきたいと思い、本日連投とはなりますが、緊急寄稿させて頂こうと考えております。

まず、このテーマに対する「下名なりの考え方」としての結論を申し上げておきますと、「基本的に原因の無いシステム障害は存在しない」、なので「原因究明が出来ないという事は無い」、なので「それを受けての再発防止策が立てられないという事も無い」、というか「そこまでの報告が無いと、システム障害で被害を受けている方（我々の業界で言えば、そのシステムの納入先、ユーザ様）がそもそも納得しない」、従って「原因究明および再発防止策を確実に立て、それを利用者に説明する事に拠り、問題は収束するものである」という事です。

システム障害の原因が「全く分からない」というのは通常あまり考えられず、まず少なくとも「どのような影響によって障害が発生したのか」という大別くらいは出来ますし、発生事象を分析する事で、少しずつそこから掘り下げていき、場合によって程度の差は有るものの、真の原因に辿り着く事が出来るものと考えています（というより、そのように原因に辿り着けるような仕組みを予めシステムに組み込んでおく事（例えば常にログファイルに処理記録を残すようにしておく等）が、システム開発では重要になってきます。

例えば、ざっと思いつく範囲で、以下のような事が考えられます。

■システム変更の影響

　プログラム本体の新規作成、改修、その周辺で連携しているソフトウェアやOSの改修（バージョンアップ等）に始まり、サーバー、ネットワーク等、周辺機器の入れ替え（耐用年数を超えた物を入れ替える）等のハードウェア面での改修も含め、何らかの「変更」が入った場合、その影響によって不具合を起こすという事がよくあります（「よくあります」というより、システム障害の大部分はこれがキッカケになるのでは、とすら思います）。
　当然、何かを変えた事に拠って、今まで動いていたものが動かなくなる、という事は基本的に有り得る事ですが、システム業界の常として、リリース前のテスト工程において、変更した影響が無い事を確認します。ポイントは、その「変更した部分」そのものだけではなく、変更していない部分についても動作確認を行い、間接的に影響が無い事を確認する事です（これを業界内では「無影響試験」とか「リグレッションテスト（RT、退行試験）」と呼んだりします）。この過程で、想定外であった事も含めて影響を全て確認し、その対処を行い、問題が無い事が確認できた上で、本番へのリリースを行います。

■資源の枯渇に拠る影響

　何かを変更していなかったとしても、システムを「使い続ける」事に拠って、何らかの制限に引っ掛かってしまい、システムが正常に動作しなくなる、という事も往々にして有ります。分かりやすいところで言えば、例えば処理結果をデータベースやファイルサーバにどんどん溜め込んでいくようなシステムを使い続けた結果、データベースやファイルサーバのディスク容量をオーバーしてしまい、それ以上処理が出来なくなる、というような事です。通常こういうものは、予めシステム設計の段階で、例えば「何日前までのデータは保存するが、それより前のデータは削除していく」とか、「定期的にハードディスクを増設していく」というようにして、システムを使い続けても想定通りに動作するような取り決めをします。

■仕様外のインプットが入ってきた事に拠る影響

　システム開発の常として、「どのようなデータを、どのような状態でも取り扱えます」というようにしておく事は、現実的には有り得ません。必ず、「このシステムではこういうデータをこのように扱います」という事を取り決めた上で、開発を行います。これを一般的には「仕様」と呼びます（前項の取り決めも「仕様」のひとつです）。例えば、「ユーザIDは、8桁の半角英数とします」というような事です。これを取り決めないシステム開発は現実的に有り得ません。なぜなら、「製品」として保証のしようが無いからです。「ユーザIDは何桁でも、どんな文字でもOKです♪」という事にしてしまった場合、システム的に問題無い事をテストで検証しようと思ったら、何パターンのテストをしなければいけないのか、という話になります。開発予算や開発人員が無尽蔵にあるわけではありませんので、必ずどこかで線を引かなければなりません。その中で、「この仕様の範囲であれば問題有りません」という事を開発側が保証して、利用者側に納品する、それがシステム開発案件の基本中の基本となります。
　ただ、そのように取り決めを行っても、何らかの事象により、その取り決め以外のインプットが入ってきてしまう、という事が有ります。分かりやすい例を挙げると、例えば前述のように「ユーザIDは、8桁の半角英数とします」と仕様で取り決めていたのに、「10桁で記号や漢字が入ったもの」がユーザIDとして入力されてしまった、というような場合です。そのように「仕様外のインプットが入ってきた場合」、それによって「製品として保証している範囲外の状態に陥った場合」に、システム障害が発生する可能性が生まれます。
（上記はあくまで分かりやすい例として挙げただけであり、通常このような場合では、そもそも8桁の半角英数しか入力されないように、画面上で制御したり（9桁目以上入らないようになっているとか）、入力した情報をチェックして、ルール以外の文字が入っていたら「ユーザIDは8桁の半角英数で入力してください」というように画面に表示して再入力を促すようにする、というような対策を取るのが普通ですので、通常は起こり得ません。これで問題になるようなシステムは失格の烙印を押しても良いレベルです。）

■外部からのサイバー攻撃に拠る影響

　これも昨今では、システム障害の要因としてはよく考えられるものです。ただ、だからと言って傍観してよい問題では無く、決して防げない問題でも無く、なおかつこれだけネットワークセキュリティについて叫ばれるようになって久しい昨今においては、当然システムの設計段階で、その防御策について考慮されるべきポイントとなります。


さて、ここで今回のシステム障害に関する、JKA会長からのコメントを以下に示します。

「このたびのシステム障害により、3日および4日の競輪開催を中止する事態となりましたことを、お客さまならびに関係者の皆さまに深くおわび申し上げます。今回の障害は競輪情報システムにおいて不整合なデータが入力されたことに伴うシステム障害により開催中止・順延・打ち切りが発生することになりました。調査の結果、当該システムそのものに問題はないことが判明しましたので、安全性が確認されたものから順次開催することになりました。なお、今回の事象は外部からの不正アクセスやサイバー攻撃といった事案によるものではなく、情報流出も生じておりません。今後このような事態が発生することがないよう、業界をあげて再発防止と信頼回復に努める所存でこざいます」


これを見ると、ひとまず情報流出等の二次災害が発生していないという事で、「開催が出来ない」という事以上の更なる問題の拡大は無さそうです。また、「競輪情報システムにおいて不整合なデータが入力されたことに伴うシステム障害」という言葉が出ている事から、上記に示したシステム障害の要因（影響）の中では、３番目に示した「■仕様外のインプットが入ってきた事に拠る影響」に類する問題であるという事も読み取れます。４番目の「■外部からのサイバー攻撃に拠る影響」でもない事も明確に示されています。
ただ、「では、どのような「不整合なデータ」が入力されたのか、それに拠ってどのような想定外の処理が実行され、システムが正常に動かなくなる事態に繋がったのか」、そして「それを受け、今後それが二度と発生しないようにどう対処するか」という事についてはまだ示されていません。
勿論、まずはシステムを正常に戻す事が最優先であり、原因分析はその後、という事で現場は動いているものと思いますので、まだそこまでに至っていないというのが実際かとは思います。

ただ、冒頭で示した通り、「原因究明および再発防止策を確実に立て、それを利用者に説明する事に拠り、問題は収束するもの」です。その点においては、オートレースでもそうなのですが、これまでこの業界においては、あまりその部分までをキッチリ示してもらえていなかったような気がしています。今回のケースにおいて、システムの利用者、ユーザ（お客様）は、まさに我々という事になります。起きてしまった事はもう取り返しようが有りませんが、いかにしてこの問題を、利用者側に納得してもらう形で収束させるか、という事が、ひいては信頼を獲得できるか、失ってしまうかの分水嶺になる事は、敢えて下名から申し上げるまでも無いでしょう。
もし仮にですよ・・・、そんな事は無いとは思いますが、「利用者に説明しても分からないだろうから、別にいいんじゃない？」というような考え方が蔓延っていたとしたら、それはもう信頼がどうとかというレベルでは有りません。「またもしかしたら、同じ事が起きるのでは？」という疑心暗鬼を生み、「それだったら嫌だな・・・」と言って、離れて行ってしまう利用者が出てきても何ら不思議では有りません。それでいいんだっけ？この業界・・・という事です。
今回のケースは、既にマスコミ各社でも取り上げられておりますが、それだけでなく、日経コンピュータ等、ITの専門サイトでも取り上げられている状況です。それは既に、この後の収束の仕方が問われているという事にも繋がります。

特にこのシステムに携わっている現場の方々のご苦労を考えると、本職にて分野こそ違えど同じ「システム開発の現場」に居る者としては、身につまされる思いが絶えません。もしかしたら今この瞬間にも、原因究明のために身を削り時間を掛け、ログ解析等、様々な調査を行っているかもしれません。

是非、業界のお歴々の皆様におかれましては、その現場の苦労を水泡に帰する事の無いよう、決して有耶無耶にせず、この問題を「キッチリと収束」させて頂きたいと思います。

勢いのまま書き始めたら、かなりの文章量になってしまいました。長文大変失礼致しました。
また、ここまでお読み頂き、誠にありがとうございました。