「システムリスク」タグアーカイブ

話題の技術に踊らされる会社　踊らされない会社

投稿日時: 投稿者:

AI（人工知能）が巷で話題になると、「ウチも AI を使ってなにかやれ」と部下に指示する経営者。

信じたくはありませんが、本当にいるのだそうです。

「ウチの商品・サービスにAIを適用したら、○○が●●になって、これまでにない新しい価値が出せるのではないか」というような話をするのなら、ひとまず許容範囲です。そうではなく、「なにかやれ」とだけ言うということは、どう使うとよいと思っているのかについてはノーアイデア・ノープランであるのは明らかです。

経営者がそんな技術的なことに専門家並みに詳しいなど無理だ。こんな反論がすぐに返ってきそうですが、うまく技術を取り込む会社では、そんな言い訳は聞かれません。それでいて、経営者は技術の専門家では必ずしもありませんし、目指してもいません。ただ一点、的確に方向性を伝えなければ「まずいシナリオ」に嵌ることだけは、熟知しています。

まずいシナリオとはどういうことか。冒頭のようなかたちで指示すると、技術にフォーカスが置かれ、その検討がうまく行ったとしても、結果はビジネスに対してあまりインパクトをもたらさない「小粒なもの」になりやすい、ということです。

つまり、こういうシナリオです。特定の技術を自社に適用することが目的になると、およそ発想の方向は「その技術はウチの業務のどこに使えるだろうか」となっていきます。そしてその検討の結論は、「～の業務のうちの…の部分に適用できるかもしれない」となります。そして実際に実証試験を行って、たしかにうまくハマりそうだ、となるわけですが、それは所詮「ある業務のいち部分」でしかありません。

たしかにその業務だけで見れば、自動化なり効率化なりを実現しますから、現場としてはうれしいかもしれません。それがマスコミにおいて話題になっている技術だと、先進事例だとして取材に来られて世間に知られることになり、担当者は得意な気分になるかもしれません。

しかし、経営レベルから見れば、そのインパクトは「ある業務のいち部分」でしかありません。通常、「ある業務のいち部分」がビジネス全体に及ぼす影響は、大したことがありません。従って改善のインパクトも、大したことはないことになります。おそらくその会社の経営者は内心、「新聞で言われるほどすごくはないな」「まあそんな程度のものか」というような感想を持つでしょう。

そのような感想を持ってしまうのは、このシナリオを辿るなら、厳しい言い方ですが自業自得です。なるべくして「まあそんな程度」になっています。

ただし、このシナリオにおいて注意すべき例外があります。こと IT の場合、ある技術の採用が会社の業務基盤を根底から変えてしまう影響力を持っているケースが、時としてあります。その技術を採用することで、仕事のしかたがごっそり替わる、問題発生時に解決の仕方がこれまでと変わる、業務のやり方が縛られる、などということが起こりえます。

経営者が、技術の採用によりこうしたインパクトがあることに疎い（そういう類の技術に限って、そのインパクトが素人には分かりにくいのです）と、以前と違う状況になっているとはっきり気づいたときに、小さくないショックを受けることになるでしょう。そして、そこから元に戻すことは、もうできなくなっています。

マスコミはほとんど取り上げませんが、新しい技術を使ってポジティブな成果を挙げる企業は、その技術の適用を考える前に、自社のビジネスのグランドデザインがきちんとできています。事例を「きちんと」分析すれば、その会社がきちんとグランドデザインを描き、それを下敷きにして技術適用の検討を進めてきたのかどうかは、感じ取れることが多いものです。

グランドデザインがあるということは、その会社が実現したいことが明確に決まっている、ということです。ですから、新しい技術がその役に立つ可能性について、容易に判断がつくのです。

そういう会社の経営者は、「ウチも AI を使ってなにかやれ」などとは決して言わないでしょう。そんなこと言わずとも、社内で勝手に検討が進んでいるはずです。それが、グランドデザインを考えている会社とそうでない会社の差です。

ROA、ROE、ROIという数字遊び

投稿日時: 投稿者:

財務指標を経営目標として重視している企業は珍しくありません。特に、上場企業に多いような気がします。

それらを評価の「ひとつ」として参照するのであれば役に立つだろうと思いますが、それ「しか」見ないのであれば、大局的な方針判断はしにくいのではないかと思います。

財務指標は、ひとつだけを取って見るのでは、極めて一面的です。そして、本来その財務指標が意味する本質を離れ、（言いかたはよくありませんが）数字遊びをすればどうにでもよく見せられる側面があります。

例えばROA（総資産利益率）。本来この指標は、持っている資産をいかに有効活用して利益につなげたのかを見る指標です。ただし、この指標において、利益と資産以外のものは評価対象に入ってきません。この指標だけ見て評価するのなら、利益を増やす努力や工夫はしなくても資産を減らすだけでROAは改善します。

以前、ある著名企業のCIOが、自社の情報システムをすべてクラウドに移行することを発表していました。その企業は経営指標としてROAを重視しているといい、「これで当社のROAが改善する」と誇らしげに語っているのを見たとき、そんな目的で移行すると知ったらきっと株主は怒るだろうなと思ったものです。

最近では、ROE（株主資本利益率）もよくトピックに挙がる指標です。本来は、株主が投資してくれたおカネをいかに効率よく利益につなげたのかを評価する指標です。ただしこれもまた、株主資本（自己資本）を減らして借り入れを増やせば、向上します。もしこの分野の評価をするのなら、その企業が資本を活用するロジックを明確にして、その効率性を評価するようにしないと、本当のところは判断できません。

財務指標とは少々離れるかもしれませんが、ROI（投資対効果）は、よく情報システム関連の投資をする場合に出てくる指標です。いい加減でムダな投資をしないようにするため、という評価目的は真っ当だと思いますが、多くのシステム投資案件ではリターンを明確にすることが困難です。ネットワーク環境やシステム基盤刷新などのITインフラ整備、情報セキュリティ、情報分析環境整備などは、典型的な「リターンを明確にしにくい投資」でしょう。

それでも一律にROIを要求すると、意味が薄い、単なる数字遊びが始まることになります。部下が頭をひねってムリヤリ考案した、一見美しいシナリオは、これまで経営にどれほどの意味があったでしょうか。

情報システムは、ビジネスのしくみを支援するためのものです。見かたを変えて言えば、ビジネスのしくみのないところに情報システム導入は原則としてあり得ません。ビジネスのしくみが明確になっているのなら、情報システムに投資することそのものに迷うという話は基本的にあり得ず、迷うとすれば「その案で、想定しているしくみが本当に効果的に実現できるのか」という視点になるはずです。

指標は参照するのには便利ですが、その指標の裏側にあるロジックが具体的であればこそ意味を持ち、活きてくるものではないでしょうか。ロジックの裏付けなく指標だけを見て判断しようとすれば、芽を育てるべき無骨な案件は迷うことなく却下され、本当のところを隠されて文章や数字でお化粧された素敵な案件は承認されるという、本末転倒な事態を招きやすくなり、かつそれに気づかない。こうした成り行きになるではないでしょうか。

もし好ましくない評価値が出るのなら、その要因をロジックを辿ることで理解し、改善または再検討を図る。このようにして、指標は利用すべきだと思います。

「クラウド移行で業務改革」に見るカンちがい

投稿日時: 投稿者:

各種の調査を見ていると、企業のクラウド利用はそれほど大きく進んでいるようには見えません。グループウェアなどのSaaSは活発に使われるようになっている反面、開発基盤を提供するPaaSやシステムインフラを提供するIaaSはまだ下火、という結果になっていることが多いようです。

一方でここ最近よく目に留まる気がするのは、比較的規模が大きい企業が自社のシステムをクラウドへ移すというケースです。

ちなみにですが、わたしがここでお話しする「クラウド」には、いわゆるプライベートクラウドは含みませんので、あらかじめお断りしておきます。

企業のシステムをクラウドへ移すべきなのか、移すとしてそれを一部にしておくべきか全部にするのか。このトピックについてはさまざまな論点があります。

判断は各社各様でしょうし、ひとつひとつに対してとやかく申し上げるつもりはありませんが、事例を拝見していると、成功したとする企業が掲げる「クラウド移行の効果」のなかに「業務改革の達成」というものが含まれているのを、時々見かけては気になっています。

例えば、「クラウドにすべてシステムを移行することで、システム導入や開発の柔軟性がオンプレ（自社運用）とは比べものにならないほどに増す。IT部門はシステムの『お守り』から解放され、より企業の戦略や企画へ業務をシフトできる。」　これをもって「業務改革の達成」としているような話です。

それは、「IT部門の業務改革」であって「企業やビジネスの業務改革」ではありません。

IT部門が思い描いたように経営を説得してクラウドへ移行を行えたとしたら、そこから真価が問われることになります。本当にビジネスに資する戦略立案に一役買えるのか。業務部門と連携してデジタルの面からリーダーシップを取るべく企画アイデアを出せるのか。業務部門が「これを実現したい」という要望を持ったときに本当にそれを迅速に実現させられるのか。

それができて初めて「業務改革が達成された」と呼べるのではないかと思いますし、逆にできなければ「クラウド移行でトクしたのはIT部門だけではないか」という話になるかもしれません。

気になることは、ほかにもあります。

クラウドというと、とかく移行のリスクをどう考えるかが話題になります。成功したとする企業の担当者はそれに対して、クラウド事業者が数々の国際認証や国際標準に準拠していることを根拠に「自社でやるより任せるほうがよほどマシ」と結論付ける傾向があるようです。

そうかもしれませんが、重要なのは、任せるクラウド事業者がISOに準拠しているかどうかではありません。

委託することで自社は「何のコントロールができなくなるのか」または「コントロールしにくくなるのか」を見極めることであり、それについて経営層と認識を共有することです。

一例を挙げれば、自社の基幹システムをクラウドに全面移行することに決めた企業のトップならば、ひとたびクラウド側で障害が発生した場合、自社は復旧にあたって何の手も下せずにクラウド事業者にすべてを委ねるしかないこと、それでも顧客に対しては自らの責任として状況説明を行う必要があることを、十分了解しているか、というようなことです。

ほかにも、セキュリティ、責任分界、採用技術など、さまざまな論点がありますが、「移行のリスクを考える」とはつまりこういうことではないでしょうか。

まだ気になることはあります。クラウド化によって「システムの運用から解放される」というメリットを述べる向きもときどき見かけますが、これは大きな勘違いです。

クラウド化することにより、従来型の運用から解放される代わりに、「クラウド対応の運用」に変えていく必要が出てくるからです。

クラウドは「サービス」であり、これに移行するということは、自社の情報システム運用はクラウド事業者の「サービス」に合わせる形で提供されることになります。クラウド事業者のサービスが変更されたり、別のサービスの利用を自ら追加したり、事業者側がサービスを停止したりすれば、そのたびに運用は何らかのアクションが必要になるのです。そのアクションは、自社のシステムユーザーの利用動向や、自社が提供すべきサービスのポートフォリオを考えながら、調整を行わなければなりません。

また、クラウドサービスは通常は従量課金制です。使えば使うほど料金は増加します。利用開始当初から利用状況が変われば、それに気づいて利用のしかたを見直さないと想定以上にコストがかかってしまうリスクが否定できません。しかも、事業者側は頻繁に料金改定を行います。その情報をしっかりキャッチアップし、使い方を見直していかないと、いつの間にか損している状況に陥りかねません。

つまり、クラウド対応のシステム運用では、「クラウド事業者のサービス提供の都合」という、従来型の運用にはなかったパラメーターを踏まえた運用を要求されるようになるということです。解放感に浸っていては、この「パズル」を適切にコントロールすることはできないでしょう。

クラウドは、うまく使えば企業の大きなパワーになりえます。いまクラウド利用を検討している企業の経営層の方々には、上記のような点を念頭にきちんと理論武装したうえで検討をいただきたいと思いますし、社内説明でうまく説得された経営層の方々には、上記のような目で今後の成り行きをウォッチいただければよろしいのではないかと思います。

やりすぎない農業ITのススメ

投稿日時: 投稿者:

最近、農業へのIT活用が草の根的に広がっている事例を取り上げたニュースを、よく見かけるようになりました。

センサーネットワークを構築して運用したり、小型ロボットを活用して作業を効率化したり、天気予測データを取り込んだ作業適正化の仕組みをつくったりなど、興味深い取り組みが多く見られます。

特筆すべきは、こうした工夫を農家の方々が自身で行い、さらには機器を調達するなどしたうえで、自作をして取り組んでいる例があることです。そしてそれを、互助会やコンソーシアムといったグループを組みながら運営を推進しているとのこと。まさに user-driven な発想であり、自らであるべき姿を構想してデザインし、それにフィットした仕組みや情報システムを実装していくという、成功率が高まる取り組みのしかたです。

この分野では、大手ベンダーが農業ITソリューションをサービス化してクラウド展開する試みが、盛んに進められてきました。これはもちろん、農家をサービスで囲い込むのが最終的な目標なわけですが、ぜひそれに負けない強いシステムを実現していただいて、クラウドを使うよりも独自性のある、より良い成果を挙げていただきたいと思います。

ただし、注意が必要だと感じるのは、こうした user-driven な発想で自ら構築したシステムを、対外的に販売しようとする動きです。

互助会またはコンソーシアムとして運営するにあたり「運営費」もしくは「会費」を取るというのなら、特に問題には感じません。一方、これが「販売」ということになると、位置づけはかなり変わります。

つまり、その農家の団体は、自分のサービスを売り出したその瞬間に「ベンダー」になるわけです。

ベンダーであるということはつまり、サービスを購入してくれた農家は「顧客」ということになり、システム品質に小さくない責任を負うことになります。片手間ではなくきちんと顧客専用窓口を設けて、問い合わせに対するサポートをする必要が出てきます。その顧客がサービスに依存すればするほど、システムを止めた場合に大きな損害を「顧客」に及ぼすことになります。当然、システムが止まらない保証はどこにもありません。顧客が増えてきた場合、その対応にどのくらいの人員を割けるでしょうか。

システムを止めることがなかったとしても、例えばシステム変更や更新を実施したくなった場合でも、「顧客」への説明や措置が必要になります。互助会であれば、会員のみなさんに集まってもらって方針決定、といった程度で十分ですが、「顧客」となれば安易にはいきません。

そうしたことを、本業である農業に加えて、責任をもって実行する覚悟が、「販売」には必要なのです。

しかも、この分野の技術発展は、しばらくは相当なスピードで進むだろうと思われます。一度システムを構築しただけで安心していると、数年後には技術的に陳腐化している可能性が高いわけです。「ベンダー」ならば、顧客によりよいサービスを提供すべく、それをキャッチアップし続けることも要求されます。

うまく構築できて、マスコミに取材してもらった程度で満足せず、じっくりと農業ITの運営ノウハウ改善を進め、よい技術は積極的に取り込みながら、自らの仕組みの最適化に注力するのが得策でしょう。システム運営とサービス提供のレベルの違いを、甘く見てはいけません。

セキュリティ問題発覚＝責任者辞任、でいいのか

投稿日時: 投稿者:

7月初旬に発覚し大きく報道された、ベネッセコーポレーションの顧客情報漏えい事件。漏えいの規模は2000万件以上、4000万人～5000万人が対象になるということで、世間にこれだけの動揺が広がったのは無理もないでしょう。

すでに、同社のシステム開発・運用を手掛けるグループ会社・シンフォームの業務委託先の元社員が、不正競争防止法違反の容疑で逮捕され、容疑を認めているということです。犯行の手口も明らかになってきており、犯人は自身のスマートフォンに顧客情報をコピーして持ち出したとされています。

ベネッセコーポレーションでは、他の多くの企業と同様に、社内端末に対するUSBメモリーの接続を禁止する対策を取っていたようです。しかしながら、スマートフォンを外部ストレージとして使用した場合に、多くはUSBメモリーと同等の振る舞いをするところを、犯人のスマートフォンはUSBメモリーと同類のデバイスとしてふるまわず、接続制限が効かなかったと推定されています。

こうしたスマートフォンによる抜け穴は、専門家の間でさえも昨年から話題になり始めていたものでした。この方面の技術動向にくわしい人材でない限り、知らなかったとしても不思議ではありません。すでに対処ができている企業も、まだ少ないと思われます。

それほどに微妙な個所に脆弱性があり、それが今回悪用されたということです。

わたしが気になったのは、この件を受けて、漏えい発覚直後に、本件の責任を取るかたちでベネッセコーポレーションのCIOの辞任が発表されたことです。

確かに、この事件が社会に与えた影響は甚大です。しかし、こと情報セキュリティの問題においては、そうだからといって辞任するのが真っ当というものではないと、わたしは考えています。

情報セキュリティのリスクは、どれだけ対策しても、残念ながらゼロにはなりません。したがって、どれだけ優れた対策を、どれだけ費用をかけて行っていたとしても、事故は発生しえます。今回の問題などは、推定どおりだとすれば「最近までは存在しなかった脅威」が原因ですが、こういうことは将来にも起こりえます。

また特に、内部犯行の防止対策には、限界があるのが現実です。たとえて言うなら、ご自分の自宅の空き巣対策にはある程度の防止策はとれても、家族のだれかが家の貴重品を持ち逃げするのは防ぎにくい、ということに似ています。

もちろん、内部犯行の対策としてできることはあり、情報資産の重要度に合わせてそうした対策は実行すべきです。重要度が高いのなら、技術動向にも感度を高めるべきでしょう。その点で、同社には不備があったのは疑いの余地がありません。

ただし、その不備がどの程度のレベルの不手際なのかは、実際に行われていた措置の内容に依ります。つまり、同社のような規模、かつ同社のように重要な顧客情報を取り扱う事業者であれば絶対確実に実施すべきと、客観的にそう判断される事項が実は行われていなかったのだとしたら、または守る体制の整備をする義務を著しく怠ったと認定されるなら、それはエグゼクティブの責任問題になるということです。

一方、そうではなく、事件発覚前に行われていた情報セキュリティ対策が他と比べてそん色がなかったものの、その穴をかいくぐって犯行が行われてしまったとしたらどうでしょうか。それもエグゼクティブの責任問題だとしていたら、ロシアンルーレットのようにいつか必ず「責任」を取らされることになる情報セキュリティ責任者のなり手は、おそらくいなくなるだろうと思います。

重要なのは、情報セキュリティに知見のある人物が、権限を持って組織をリードし、顧客や社外に明確に説明できる情報セキュリティ対策を実行し、継続して改善を推進することです。事件や事故が起こるたびに責任者が辞任するのでは、組織が混乱するだけで、余計に脆弱になる可能性さえあります。

マスコミや、いわゆる識者と呼ばれる人たちは、多くの場合結果論だけで評価します。問題が発生したのだから、「問題がない」とは言わないでしょう。あとから批判されたくなくて辞めるかどうかは、会社や責任者本人の判断です。しかしわたし個人は、自社が行ってきた取組みをきちんと外部に説明する責任を果たせるよう努めてきたのなら、短絡的に辞任という判断につなげてほしくはありません。特に大手がそういう判断をすると、「事件発生＝辞任」という悪しき前例になりかねません。

また、経営者は、情報セキュリティの対策に十分な関心を普段から寄せているでしょうか。そろそろ経営者には部下に対して、「うちの会社は大丈夫か」と聞くのではなく、「うちの会社はどう対応しているのか」と聞いてほしいと、常々思っています。

さすが銀行のビッグプロジェクトはすごい、と思ってはいけない

投稿日時: 投稿者:

先日、みずほ銀行のシステム統合プロジェクトの工期が約1年延期されることが発表になりました。

同行の勘定系システムは稼働からすでに25年以上が経過しているなど、かなり老朽化・複雑化しているとのことで、さまざまな事情とリスクを勘案した結果だろうと推察します。

マスコミは同行のシステム統合事例を「史上最大規模、世界でも類を見ないシステムプロジェクト」として取り上げるきらいがありますが、わたしはこの事例は、多くの企業が手本とすべきものではないと考えています。

この事例のような大規模システム全面刷新、いわゆる「ビッグバン導入」は、本来避けるべき方法です。莫大な労力と費用を投じた挙句に頓挫するリスクが非常に高いやりかたです。難易度が非常に高いぶん、成功すれば大々的に取り上げられて一様にほめられるでしょうが、正しい努力だとは思えません。同行にとっては、残念ながらこれしか選択肢がないのだろうと、わたしは見ています。

システム開発プロジェクトの理想の姿は、小さく実施することです。プロジェクトの最大の目標は、「つつがなく完了する」こと。そうだとしたら、もし元のシステム構想が大規模であれば、それをできるだけ小さく分割してコントロールを容易にし、リスクを下げて実行できるようにしたほうがよいのは当然です。さらには、開発規模が小さくなればパートナーに選定できるベンダーの幅も広がり、コスト削減の可能性も大きくなります。

大規模なものを大規模なまま実施するということはつまり、ユーザー企業が、いかに分割すればよいのかにアタマを使っていないということです。そして大規模にすればするほど、いわゆるITゼネコンでなければ受注できないようなシロモノになり、コストは半端な規模では済まなくなります。

ビッグバン導入は、百害あって、成功すれば一利に加えてマスコミに取り上げられてほめてもらえる特典くらいあり、失敗や頓挫をすれば百害に加えて会社が傾くほどの損害まで被るかもしれません。経営者はこのことを直感では感じていることが多いのですが、IT担当が出してくる計画にロジカルに反論する力がないのが実情でしょう。

そうした計画しか出せない諸悪の根源は、ビッグバン導入以外に選択肢がなくなってしまうほどに、企業内のリーダー層が、システムのつくりの問題に見て見ぬふりをしてきたことなのかもしれません。それは、経営者の責任でもあります。経営者にはこの点に、まずは目を向けていただきたいと感じています。

Facebook 上場トラブルで読み取る、IT の弱点（2012年6月）

投稿日時: 投稿者:

去る5月18日、米国ナスダック市場に SNS サイト最大手の Facebook が上場を果たしました。

その日は世界中のメディアがこのニュースを取り上げ、大変な盛り上がりようでしたが、その後同社の株価は低迷。上場から 1 週間後には株価は 32 米ドル弱で公開価格を大きく下回り、29日には 29 米ドルを割り込むなど低迷を続けています。このあたりは、多くの方がご承知のとおりのところです。

こうした低迷の原因のひとつに（個人的には主要因と思っていませんが）、取引開始当日に発生したナスダックのシステム障害が取りざたされていることも、ご存知の方が多いでしょう。

この障害、具体的には、Facebook の上場当日、ナスダックが同社の IPO に予定より 30 分遅れ、約 20 分間取引の確認処理が停止、結果的に証券会社に取引の成立が通知されるまでに 2 時間以上を要した、というものでした。社会インフラ化した情報システムがひとたび障害を起こすと社会に大きな影響を与えることが、またしても示された格好になってしまいました。

一方、この障害は、多くの経営層の方々に認識を新たにしていただきたい出来事だと、わたしは考えています。これは単なる話題の企業の上場フィーバーとそのつまずきの話ではなく、情報システムに依存する現代のビジネスでは「システム障害でビジネスが止まる」ということを示しているのです。自らとは関係のない金融システムの問題と、捉えるべきではありません。

こうした出来事に目を凝らしてよく観察すれば、情報システムの弱さはどういう所に出やすいのか、見えてきます。それらはまさにシステムリスクであり、自社のシステムにおいても注意を向けるべきポイントになるのです。

今回のナスダック障害で考えるなら、次のようなことが見えてくるでしょう。

まず、情報システムは、「高速」「大量」をこなすのがウリだけど、「超高速」とか「超大量」にはわりと弱い、ということです。

ナスダックの発表によれば、実は Facebook 上場開始前に IPO Cross と呼ばれるオークション入札が行われていました。それに入札が殺到し、その入札結果で算定される上場開始時株価の計算処理において障害が引き起こされた、とされているようです。

入札を締め切ってから株式の実際の公開まで十分時間が取れるなら、きっと何の問題もなかったでしょう。しかし実際は、入札自体は上場開始直前まで受け付けます。したがって、高速な処理ができなければ株式の公開に支障があるわけです。「高速」が要求されるところに「大量」が重なり、障害が発生したと理解できます。

もうひとつ見えるとすれば、それは情報システムは「状態の整合」に弱い、ということです。どういうことかというと、複数のシステムがあったときに、お互いに状態を引き継いで動作するのがあまり得意ではない、ということです。

今回のナスダックの障害では、「ナスダックは IPO に予定より 30 分遅れた」とされています。実はこの「30 分」というのは、IPO 予定時刻から、ナスダックが障害のあったシステムをバックアップ側に切り替えたタイミングまでの時間です。これで、Facebook の株式が公開されました。

このとき、バックアップ側では、例えば株価の情報など、当初現用系であったシステムの状態を当然引き継いで動作しなければなりません。ところが、この時のバックアップ側は、切り替えられたタイミングから約 20 分前の状態までしか持っておらず、それ以降の入札情報を無視した状態で動作をスタートさせていたのです。

結果として、上に記したとおり、その約 20 分間の入札に関しては取引が成立したのか不明となり、それが 2 時間以上経過して解決となった、というわけです。

あるシステムに対してバックアップを設けるというのは、一般的に行われていることです。しかし、現用の状態に合わせた切替を精確に行おうとすればするほど、実は技術的難易度が高くなるのです。

今回のケースでは切替自体はうまく行った様子ですが、実は切替そのものに失敗するケースも多く発生しています。ベンダーが有償で販売しているソリューションであるにもかかわらず、です。

これは必ずしも、ベンダーにすべての責任があると言い切れません。もちろんベンダーには、いかなる状況でも安定して動作するソリューションを要求するべきですが、少なくとも現時点では、状態の整合は技術的難易度が高く、結果として脆弱性がぬぐえない、というのが現実です。

また、今回取り上げているケースとは若干離れるかもしれませんが、もうひとつ情報システムのもろさとしてぜひ知っておいていただきたいのが、「同期」に弱いということです。これは例えば、システム A とシステム B があったとしたら、A と B を完全に同調させて動作させるというようなことです。

これも、技術的難易度が高い処理です。「同期」させる対象として最も取り沙汰されるのは「データの同期」ですが、データの同期を前提として動作を行う処理があった場合、万一データの同期が外れてしまえば、その時点からその処理は完全に間違った動作を行うことになります。

こうしたことにもベンダーはソリューションを用意して「できます」と言うかもしれませんが、高価なうえに障害が出るリスクは大きいと捉えておくべきでしょう。

このように、ひとつのシステム障害をよく見るだけでもさまざまに教訓が得られ、自らがシステムを選定するときに使える「見る目」を養うことができます。

経営者やリーダーの方々も、ITには疎かったとしても、新聞は毎日ご覧になるでしょう。その中でシステム障害に関する記事を見かけたら、上記のような見方をしてみてください。

「情報システムはこういうことに弱い」と知っていれば、企画提案が上がってきたときにも、そういう視点で話が聞けるわけです。もっと安全かつ確実なやり方でできないのか。高価で失敗するリスクを抱えてでもやるべきことなのか。より深い検討ができるようになるはずです。

単に新聞の解説を読むだけで満足せず、ぜひこうした切り口で「本質」を読み解いていただきたいと思います。