ランサムウェアに感染したら、身代金を支払うのか

ランサムウェアに感染したという企業が、後を絶ちません。一時期下火になりながら、再度復活し、わたしもここ最近は毎月複数件の感染情報に接しています。

ランサムウェアに感染すると、データをことごとく暗号化され、解除をしてほしければ身代金を支払えと脅迫されることは有名です。ではその時、攻撃者の指示通りに支払うべきなのかという問題は、以前から議論になっているところです。

公に出回っている事例から考察するところでは、多くの日本企業は身代金を支払わない選択をしているように想像されます。これはいくつかの調査でもそのような傾向が言われており、ある調査結果では、指示通りに支払った日本企業は感染したうちの1割程度だったと報告しています。

これは米国企業とはかなり様相が異なるようで、複数の調査を見ると、身代金を支払った米国企業は感染したうちの4割から8割だというのが、およその傾向なようです。

なぜ日本の企業は支払わない選択をするのでしょうか。もちろん、支払った事実を公表しないということも原因としてありえるでしょう。しかし、わたしの想像では、支払っていない企業が本当に大勢ではないかと考えています。そう想像できる理由は、いくつかあります。

ひとつは、バックアップがうまく確保されていて復旧できた、というケースです。ただし、用意周到であったという理想的なケースはまれです。完全なバックアップではないが部分的でもどうにか元に戻せて、それ以外は手動でどうにか戻した、というケースがあるようです。

また、被害範囲が案外小さく、業務への影響が大きくならずに済んだという事例もわりと見うけられます。本当にそうだったとすれば幸運と言えますが、皮肉なケースも想像できます。つまり、日本の中小企業などではデジタル化が進んでいない場合が多く、情報がデータになっていなかったことで、それが不幸中の幸いとなって被害が小さかった、ということはあり得るでしょう。

なかには、泣き寝入りして復旧を断念しシステムを入れなおしたケースもあるようです。先に述べたとおり、身代金を支払ったという日本の企業は、ほとんど聞きません。横並びを意識しやすい日本人の特質からすれば、他の企業がやらないようだと知れば、躊躇する要因としては十分ではないでしょうか。

少し調べてみれば、支払ったとしても攻撃者が暗号化を解除してくれる保証はないとか、暗号化されただけではなくその情報自体が攻撃者の手にわたっていて別の脅迫をしてくる可能性があるとか、ランサムウェア感染では損害保険が効かないことが多いとか、様々なネガティブ情報に触れるでしょうから、企業はなおさら支払わない選択に傾くことが想像できます。

もしかすると、身代金を支払おうと一旦は決意したものの、ビットコインでの支払いを指定されていたがために、支払い方がわからなくて断念した、というケースも、日本の企業の場合ならあるかもしれません。

別の話として、これは噂の域を出ませんが、感染を受けてシステムの復旧を依頼された委託先の業者が、委託費用を使って攻撃者に身代金を実は支払って、それによって暗号かぎを取得し、あたかも復旧データが見つかったかのように見せて復旧させた、という話も一部で報じられています。関係者は(当然)否定しているようですが、良否はさておき、あり得るシナリオではあるでしょう。この場合も、感染した企業の側は、支払った認識はないことになります。

今後もランサムウェアによる感染被害は続くことが予想されますが、日本の企業ではおそらく、身代金を支払わない選択をする企業がこれからも大勢を占めるのだろうと思われます。

どんなやり方にも「向き不向き」がある

先日耳にした話です。某官庁でシステム基盤の統括をしているという人物が、政府の情報システムのグランドデザインやそれに伴う業務変革について語っていました。そのなかで、次のような趣旨のことを述べていたのに、いささか驚きました。

もしかするとご本人はそういう趣旨で述べたつもりはないのかもしれませんが、少なくともわたしには、次のような発言内容だったと理解されました。

いま想定している情報システムの設計方針は、マイクロサービスによる疎結合、APIドリブンで設計、開発スタイルはアジャイル。なぜならば、それが「トレンド」だから。

専門知識のない方々には上記の言葉はピンとこないでしょうが、ひとまず放置して先をお読みください。

情報システムを設計したり構想したりするにあたって、設計者が取りうる考え方はいくつか存在します。

それらのアプローチには、時節柄と言っていいのかわかりませんが、話題によく上るものが確かにあります。そうしたものを「トレンド」と呼ぶのなら、トレンドはあるのでしょう。

ただし、これまでに登場したどのような設計アプローチにも、それを採用するにあたっての前提や条件があり、結果として向き不向きが存在するのが現実です。情報システム設計における万能アプローチともいえる決定版は、個人的にいろいろ勉強してきましたが残念ながらわたしは知りません。

よって、少なくともわたしの理解では、設計アプローチは「状況に対応して適切に選択するもの」なのであって、採用する方針は「何を実現したいのか」「アプリケーションをどう動かすべきなのか」というポリシーに従って決定されるものです。トレンドで選ぶものではありません。

例えば、冒頭の引用にある「マイクロサービス」について考えてみます。簡単に言いますとこれは、他とは完全に独立した小さな機能を「サービス」という単位にしてまとめ、それらの小さな「サービス」をたくさん配置して、その「サービス」の間を通信で連携させることで一定の目的を果たそうとする、情報システム設計の考え方のことを指します。

この考え方では、ひとつの単位を占めるサービス(機能)は小さいので、入れ替えることが容易です。作り替えようとした時でも、個々のサービスは独立しているので、他への影響範囲を小さく抑制することができます。新しく追加しようとするときも、他のサービスに影響を与えずに開発して、あとから通信で連携すればいいので、柔軟にシステムを拡張したり改善したりできるのです。

ただし、難点はたくさんあります。大雑把な説明をしますと、「独立した小さな機能」というのは理想的ですが、これを実際につくるのは案外難しいのです。「独立した」とはつまり、他のサービスからは完全に切り離されていなければならないのですが、一切の相互干渉がないように完全に切り離す設計をするのが難題なのです。

それが的確にできないままにマイクロサービス化していくと、重複した機能やデータを持つ複数のサービスが知らぬ間に出来上がり、それが増殖していくことになります。次の難点は、増殖しやすい分運用管理がしにくくなりやすいこと、さらには、増殖するたびに通信のパスが増殖すること、です。無秩序に拡大してしまうことも考えられ、全体としては、品質要求が高いシステムにはあまり向いていない作りになりやすい特徴があります。

もうひとつ、冒頭の引用にある「アジャイル」についてはどうでしょうか。

これは、情報システムの開発手法の一形態です。ざっくり言えば、予め要求を決められないシステムに対して、まずは大事そうなところから小さく作ってみて、それをどんどん改善しながら大きくしていこう、というようなシステム開発のしかたのことを言います。

世の中には、どういうものが欲しいのか?と言われても、ざっくりとした要望以外に何も細かく決められないことがたくさんあります。そうした場合であっても無理やり要求を固めようとするのは、現実的ではありません。アジャイル開発は、そうした状況に対応できるシステム開発のやり方です。

ただし、ご多分に漏れず万能ではありません。要求を固めずに開発を進める以上、始めからパーフェクトな機能が揃ったシステムは、当然完成できません。アジャイルでつくるシステムは、始めはいまいちですが、だんだんと良くなっていきます。つまり、システム完成当初から一定の品質以上の動きをしてもらわないと困るようなシステムの開発には、向いていないのです。そういうシステムは、やはり設計の時点で要求を固める努力が必要になります。

2020年10月のコラムでわたしは、国のシステムは超巨大で一筋縄ではいかない旨を記しています。どの領域でどのような設計思想を採用し、どのようなアプローチで最適化していくのかは、本当に大変な作業だろうと想像します。少なくとも、そうした方針を「トレンド」で選定すれば解決するような話ではないと思います。

デジタル庁は発足当初から、ITスキルの高い外部人材を大々的に募集し、働き方も柔軟に対応できるようにしたことで、多様なスキルを持つ優秀な人材が多く集まってきていると聞きます。それは大変喜ばしいことですが、昔の某プロ野球チームのように4番バッターばかり集まってきてはいないでしょうか。みんなトップ人材、みんなリーダー格、みんなその筋ではスゴイ人、では、船頭多くして船山に上る、ということになります。まあ、わたしにとっては要らぬ心配なのですが。

小売業のダイナミックプライシングは、悪手でしかない

「ダイナミックプライシング」とは、需要に応じて売り手側が価格を柔軟に変動させる仕組みのことです。

従来は価格の表示が紙で行われていたため、価格を変更することは時間も労力もかかる作業になっていました。これが、近年はITによって価格表示をデジタル化することができるようになり、ダイナミックプライシングは一気に現実味のある取り組みになりました。現在、宿泊業、航空、娯楽施設では一般的に実用されています。

こうした取り組みを、最近真似しようとしている小売業がちらほら見受けられます。しかし、小売業がダイナミックプライシングを実施するのは、先進的どころかむしろ不利益をもたらします。やめたほうがよいと、わたしは思います。

小売業でダイナミックプライシングを採り入れようと考えている企業は、きっと顧客の立場で物事が考えられていません。

例えば、ホテルに宿泊する顧客の場合を考えてみます。その顧客がホテルに宿泊の予約をするとき、先だって予定が決まっているケースも、突然宿泊する必要が出てしまったケースも、いろいろとあるでしょう。ただいずれにしても、その顧客は、特定の日程で特定の場所に宿泊する必要があって、そのホテルに予約をしに来ています。ある意味、選択の余地はほぼありません。

他の例では、野球の試合を観戦したい顧客の場合はどうでしょう。その顧客が試合のチケットを購入するとき、通常なら、特定の日取りで行われる、ひいきの球団の試合を見たいと思って購入するはずです。自分の予定も、連れ立っていく人の予定も、それぞれあるでしょうから、どの日でもいいということにはあまりなりません。つまりその顧客は、特定の日程で特定の試合を見ようとして、チケットを買いに来ます。やはり、選択の余地はほとんどありません。

航空のチケットも、ほぼ同じ論理になります。つまり、こうした顧客は「その時その場で、特定のものを買う必要がある」のです。このようなケースでは、ダイナミックプライシングがうまく適合します。その時その場で利用したいから、その価格が少々高くても選択せざるを得ないし、価格の比較をしたところで他は選択肢になりにくいので、高額な理由が理解できるのなら抗議したくなる余地があまりないわけです。

一方、小売業はどうでしょうか。

小売店に並んでいる商品は、基本的に毎日ほぼ同じです。顧客は、明日に来てもそれを購入できますし、その時その場でどうしても買わないとまずいようなケースはそれほどありません。

さらに、関心のある商品ほど、店に来るたびに買う商品ほど、比較的高額な商品ほど、顧客はその商品の価格を「覚えて」います。

そこに、その小売店がダイナミックプライシングを導入したらどうなるでしょうか。当然、価格が上がれば顧客は買い控えます。

それどころか、「この店は来るたびに値段が変わる、しかも昨日よりも今日のほうが価格が上がっている」と気づきます。それに気づいた顧客は、その店に信頼を置かなくなり、警戒心を持ちます。

ダイナミックプライシングに魅力を感じてやまない小売業者は、消費者は価格が変動していることを知らないと思っているのかもしれませんが、まったく浅はかです。賢い消費者ほど、どの店で何がいくらで売っているのか(場合によっては「いつ」までも)、よく覚えています。同様の話で、食品メーカーはかなり以前から常套手段として、価格を据え置いて内容量を減らすこと(いわゆるステルス値上げ)を頻繁に行っていますが、それも多くの消費者(特に主婦の方々)は気づいています。

さらに言えば、ECの世界ではすでに、特定のサイトの特定の商品が時間経過でどのような価格変動をしているのか、自動的にトラッキングしてくれるサービスまで登場しています。利用者は安くなったところで通知をもらえるように設定しておき、通知が来たところで注文できるというわけです。

そのような自動トラッキングを使わないとしても、その小売業がECサイトを展開しているのなら、顧客はそのサイトに、関心のある商品を ”何度も” 見に来ます。訪問するたびに価格が変わっていれば、それで分かってしまいます。1週間のあいだに何千円や何万円も価格が上がっていることに一度でも気づけば、もう顧客はそのECサイトでは、一見で購入ボタンを押すことはなくなるでしょう。

消費者の信頼をなくしてまで、「最適な価格」で利益追求したいのでしょうか。小売店は正々堂々と、一度決めた価格で勝負すべきだと思います。もし価格をダイナミックに変えたいなら「下げる方向にだけ」にするべきです。上げる方向に変えるなら、きちんと理由を説明すべきだと思います。

実際、現在のような価格高騰のご時世の中、そうした説明は、小規模な小売店ほど危機意識をもって丁寧にやろうとしています。値段を上げたり下げたりを恣意的に行っていることに消費者が気付けば、企業規模に関係なく、小売店は簡単に信頼を失うことを、忘れてはいけません。

デジタル人材養成のための「資格取得のススメ」

ある訪問先の経営者に、社内の人材のITスキル育成にあたって何をさせるのがよいか問われ、わたしは「資格を取るよう奨励すること」をお勧めしました。

IT関連の資格・試験制度は様々にありますが、わたしがお勧めしたのは、IPAが実施している国家試験である「情報処理技術者試験」です。

相談を受けた会社もそうですが、中小企業レベルではITの活用は一定の技術レベルにとどまり、かつ範囲も限定的です。それは、会社の中で経験できる実務がかなり限られることも要因のひとつですが、内部の人材の知識量がそもそも乏しいことも、実情としてあると思います。

大手ユーザー企業や大手ITベンダーなどに勤務する社員であれば、かなり広範囲に、規模も大きくレベルもかなり高いシステムを取り扱いますから、その分多くの実務機会に恵まれます。運がよければ、仕事をしているだけでかなりのスキルを身に付けることも可能です。

中小企業では、残念ながらそうは行きません。加えてさらに都合が悪いのは、実務の内容や質が偏りがちであることです。

情報システムのライフサイクルには、戦略・企画・計画・調達・開発・導入・テスト・切替・運用といった流れがありますが、中小企業ではこうした流れを意識することがほとんどなく、ITが利用されている実態があります。導入はするけれどまともな企画をしたことはない、調達はしてみたけれど運用しているつもりはない、等々。本当は考えなければならないのに考えていない、考えるべきであることさえ知らない、という実態があるわけです。

当の担当者たちは、自分たちが知識不足だとはあまり思わずに、一生懸命仕事をしています。しかしながら実は、本人たちはやっているつもりでいて、本当の意味ではできていないことが往々にしてあります。例えば、運用しているつもりだけれど、実態を観察してみると、やるべき運用業務をしていない、運用に必要な情報を管理していないから状況が分からない、といった具合です。ネットワーク構成図がない中小企業など、ざらにあります。

IT専任の担当者がいる中小企業はまだ恵まれていますが、そういう担当者がいたとしても、その人の経験が偏っていることが多分にあります。自分がよくわかっていないことを、他人に教えられるはずがありません。当然、社内に流通するIT知識も偏ることになります。

そうした環境でどれだけ実務経験を積んだところで、どんな会社に行っても通用するような汎用的な学び、さらにはスキルレベルの高い学び、は期待できないのです。

情報処理技術者試験は、基本・応用・高度の大区分のもとで構成され、高度資格は専門タイプごとに試験が用意されていますが、それぞれの試験に対して知識体系が整理され、その知識体系に対する理解度を問う試験になっています。各資格を取得するための勉強を通して、その知識体系に沿ったスキルを学ぶことになるのです。

体系化された知識を勉強することで、実務をしているだけでは得難い知識領域まで漏れなく効率的に触れることができるのが、情報処理技術者の資格に向けて勉強することの利点です。これは、国家試験への合格で箔がつくことよりも重要なことだと、わたしは思います。

「そうした勉強を通して得た知識を会社のIT活用にフィードバックしてもらうようにしてください」と申し上げて、わたしはお勧めをしています。

前記のとおり、情報処理技術者試験では、高度なスキルだけでなく、どの社会人でも知っているべき基礎的なIT知識を問う試験も用意されています。多くの社員に向けて、会社として資格取得を奨励すると理想的です。受験費用の補助や、関連する研修の受講費用の補助、合格時の報奨金支給など、できる限りのサポートをしてスキル向上の取組みにしてほしいと思います。

なんであれば、まず経営者のあなたが、トライするのもよいのではないでしょうか?ものすごい知恵の底上げになるはずです。

「クラウドがやられる可能性」を考えているか

「クラウドファースト」などとして、日本のマスコミはクラウド事業者に情報システムを「すべて」預けることが今の常識だという論調でしきりに語りたがると思っているのは、わたしだけでしょうか。

もちろん、リスクを取ってでもクラウドに完全移行したほうがその企業にとって価値が高いと判断して、そのようにした事例も認められます。納得感のある判断です。ただ個人的な見解ではありますが、そんな目利きをしたようには思えないクラウドシフト事例ははるかに多数あると思っています。マスコミが生み出したそんな後者の企業を、マスコミが多数取り上げる結果、ますます拍車がかかっているように思えてなりません。

実際のところ、目が利くITユーザー企業は、自社管理であるオンプレミスとパブリッククラウドサービスを、うまく使い分けて利用しています。

両方を使い分けるのには、いろいろな理由があります。単にパブリッククラウドに移すのは都合が悪いという理由もあります。個別の都合は様々でしょうが、総合的に考えれば、選択肢がいろいろあるにもかかわらず「クラウド一択」というのは賢い選択とは言えないはずです。だから使い分けるのだろうと思います。

クラウド事業者やベンダーが示す事例はもとより、マスコミが紹介する事例も、有名企業が自社のシステムをすべてクラウドシフトしたなどと大々的に取り扱っていますが、その企業が考え抜いた末にそういう判断をしたのだとしたら、そのリスクについてどう考えたのか詳しく聞いてみたくなります。

クラウドも人が運用するシステムである以上、オンプレと同様に障害は起こりますしシステム停止も発生します。問題なのは、障害が発生した後から復旧するまでのところです。オンプレミスなら自ら手を下して復旧に取り組むことができますが、パブリッククラウドの場合は復旧を待っていることしかできません。

クラウド事業者のほうが技術に長けているから自分で直すよりましだ、という論もあるでしょう。それは否定しませんが、彼らが取り扱っているのは超巨大システムですから、技術力があるエンジニアがあなたの会社の面倒を見てくれるわけではありません。年間何億円も支払っているような、よほどのお得意様企業なら別かもしれませんが、障害が発生して「あなたの会社のシステムは救えませんでした」と言われても、全く不思議ではありません。実際、過去のパブリッククラウドの障害においては、ユーザーのデータがバックアップもろとも消去された事例が複数あります。

あまり論じられることがないように思いますが、パブリッククラウドもITシステムである以上、サイバーセキュリティ攻撃に常にさらされています。いつ何時、脆弱性を突かれて顧客情報に攻撃者の手が届くともわかりません。それはオンプレミスと同じです。クラウド事業者だからリスクゼロということはありません。実際、国内のあるクラウド事業者で、内部の脆弱性を突かれて攻撃者に不正アクセスされてしまったケースが報告されています。

脆弱性を突かれる外部からの攻撃でなくても、クラウド事業者の内部で特権を悪用して利用者のデータに影響を及ぼそうとする事件が起こらないとも言い切れません。内部犯行の脅威もまた、オンプレミスと同じです。もしそのようなことが可能だとしたら、場合によっては全世界の利用者にリーチできてしまうという、前代未聞の漏えい事件になりえることも想像できます。

攻撃や犯行の脅威に限らず、そもそも外国資本の事業者に、自社のデータや資産をすべて預けてしまうのはリスクが高いのではないか、という考え方も、あって当然です。ご承知の通り、いま3大クラウドと呼ばれるクラウド事業者はすべて米国資本の企業です。欧州の企業では当初から、米国資本の企業に完全に委ねるのは危険であるという考えのもと、利用においては重要資産はパブリッククラウドに預けないなどリスク分散させる考え方が根強くあることが知られています。

日本国内でもここ最近、経済安保というキーワードのもとで、行政システムのクラウドシフトに一定の歯止めをかけ、国内の事業者に重要資産を預けるよう義務付けるべきだという意見が出始めました。冷静に考えれば当たり前のことです。これまでそのような話が出なかったのは、政府や行政もまた、トレンドセッターを自任する識者諸氏やマスコミの論調に盲目的に同調していたことの表れなのではないでしょうか。

米国の政府がパブリッククラウド事業者に行政システムをどんどん預けていると知らされて、日本の政府もクラウドシフトの動きを強めたのかもしれませんが、実際の所、米国政府はパブリッククラウド事業者に、政府専用の「物理的領域」を設けさせて、そこに行政システムを置いています。最近そうし始めたのではなく、始めからそうしているのです。要するに、(政府の手が滞りなく及ぶ専用の)データセンターにシステムを預けるという、従来のやり方と実質変わりはありません。

そして、パブリッククラウドのおひざ元ともいえる当の米国内の企業においてさえも、パブリッククラウドに預けたシステムを再びオンプレミスに戻すという揺り戻しの動きが顕著にあることが(米国内では)伝えられています。

言い出せばきりがないことです。また、だからといってクラウドサービスが有用であることを否定するつもりもまったくありません。

クラウド一択の何が結局問題なのかと言えば、パブリッククラウドは利用者自身のコントロールが(特に利用者にとって一番肝心なところで)事実上効かないこと、パブリッククラウド事業者にコントロールの主体があること、なのです。それが、およそすべてのクラウド利用にまつわる利用者側のリスクを生み出しているように思います。

目が利くITユーザー企業はそのことを理解し、何があっても決して自分のコントロールを失ってはならない情報資産を、自分の支配が及ぶ領域に置いておこうとしている、ということです。

マスコミが記事として出すクラウドシフト事例の企業も、実はよくよく聞いてみると、ちゃんとオンプレミスをうまく使って資産保護しているケースが多数あります。要するに、記者が見たい事実にだけ着目して報道しているだけであることが多いのだと、わたしは理解しています。少なくとも、記事の見出しだけ見て鵜呑みにするのはリスクが高いと、心得ておきたいものです。

人材を「資産」と考えるのなら、やらなければならないこと

政府は企業に対し、従業員の育成状況や多様性の確保といった人材への投資にかかわる経営情報を開示するよう求めるそうです。上場企業は今後、有価証券報告書にそうした情報の開示を義務付けられる方向だとのことで、人材をいかに無形の「資産」にできているのかが問われるようになります。

当然と言えば当然の考え方ではありますが、従来から人的な費用はおおよそ「コスト」と捉えらえてきた向きは否めないでしょう。その意識が念頭にあることで、「人材を資産と考えて投資する」という発想には至っていなかった面があるのではないでしょうか。

その結果が、人材評価の仕組みの欠如や、人材育成に対する計画性の欠如などに現れることになります。人材は、育成する努力を何らか施さなければ、自社にとっての「資産」には転換しないものです。それがいかに優秀な即戦力人材であったとしても、会社が目指すところ、業務を動かしている体制やフロー、業界の慣行やルール、過去の経緯、抱えている課題、等を体系的に教え伝えなければ、すぐに能力を発揮することはできないはずです。

また人材が客観的に評価できなければ、育成した結果として人材を資産に転換できたか、まだ不足があるなら何が足りないのか、わからないままになります。

こうした点においては、ほとんどの中小規模の企業は後手に回っているのが実情だと感じます。わたしもこれまで、リーダーシップを誰も取ろうとしない会社、仲はいいけれどチームにはなり切れていない会社、個々のスキル不足を自覚していない会社、社員に向上心がない会社、できる人にほとんど任せて出来ない人は放置している会社、いろいろ見てきました。

どれだけ優れた業務の仕組みを持っていても、また先進的な情報システムを整備しても、それらを使うのは結局「人」です。また、これから発展していくうえでどういう方向に会社をもっていくべきか、どういう仕組みに改善していくのが適切なのか、そうしたことを考えてカタチにするのもまた「人」です。

さらに言えば、これから会社を成長発展させていこうと考えた時に、会社をドライブしていくのが人だとするならば、どういう人材が自社に在籍している必要があるのか、どういうスキルを自社に保有する必要があるのか、そうした戦略が必要になるはずです。普段から人材の育成に考えが及ばない会社では、その方針は考えても浮かんでは来ないと思います。自社には現段階でどういう能力を持った人がいて、どのスキルが不足しているのかが、見えないからです。

つまり、そもそも人材を育成しようと思えば、その前提として、人材のスキル評価の仕組みの確立と、それを使った現状の見える化は、欠かせないということです。

人材育成が進められているということは、会社が成長していっているからこそでもあります。社員が成長を実感しているなら、自然と社内の雰囲気には活気が生まれます。そうしたことは会社の外にも自然に伝わり、会社の魅力になるわけです。「中小企業だから人が集まらない、採用できない」という愚痴をよく聞きますが、実はそれ以前のところに原因があるのかもしれません。

冒頭に紹介した政府の方針は上場企業の話だからウチは関係ない、と考えるのは、この件についてはやめましょう。

メタバースがビジネスになるのか、考える

海のものとも山のものともつかないバズワードに、「メタバース」があります。今月は、このメタバースとビジネスは相いれるものなのかについて、少しだけ考えてみたいと思います。

メタバースという言葉、実はその定義はあいまいです。それほどに、何ができるものなのか、そもそも何がしたいのかさえ、まだ誰もわかっていないように思います。だからこそ、何でもできるような位置づけで語られることが多いように思いますが、その一方で、大きな魅力を感じるようなキラーコンテンツが示されているわけでもありません。

イメージだけでざっくりとメタバースを捉えると、バーチャルな空間に社会が形成され、そのなかで自分の分身であるアバターが様々な体験や活動を行える、という感じでしょうか。かつて「セカンドライフ」という、似たようなコンセプトのものが話題になりましたが、やろうとしていることはその当時と同じようにも思えます。ただ、技術は当時よりもはるかに向上している分、現在のバーチャル空間のほうがより可能性を感じられるということで、再び注目されているということだと思います。

実際、社名まで変更してしまった旧Facebookはもとより、GoogleやMicrosoft、日本国内でもNTTドコモやKDDIなど多くの企業が、この分野をビジネスとして捉えようと取り組みを進めています。

いま現在語られているメタバースの具体的なケースは、バーチャル空間でイベントを行うとか、繁華街を再現するとか、コミュニケーションできる空間を作るとか、”斬新なデジタルワールド” といった世界観の話が多いように思います。それだけ聞いていると、特定のビジネスなら関係ありそうだけれど、その他ほとんどのビジネス領域には関係なさそうだ、と判断してしまうこともできそうです。

しかし、メタバースの本質的な部分は何だろうかと考えてみると、案外多くのビジネスと相性がいいのではないかとも考えられます。

例えばゲーム。これは言わずもがなかもしれませんが、考えてみればメタバースの空間で展開されるゲームは、従来のゲームとはかなり様相が違うものができそうな気がします。まるでそこで生きているか、戦っているか、というような状況でゲームが展開され、場合によってはゲームをしていながら、そのなかで実際に買い物をするかのようにアイテムの売買が行われ、案外幅の広い経済活動が成立することもできそうです。

エンターテインメントは想像しやすいですが、もう少しお堅いところで行けば、例えば「訓練」とメタバースの相性はかなり良いと思います。訓練というのは、職業に関連したトレーニングやOJTもそうですし、技能訓練、例えば航空機や工業機械、重機などの技能習得を行うのに、カスタマイズして構築したメタバースは使えそうです。もしかすると、一般の自動車教習のかなりの部分は、メタバースで代替できてしまうかもしれません。

体験の提供もできることを考えれば、建設や不動産関連とメタバースの相性もよさそうです。いま建設設計は、かなりの部分で電子化が進んでいます。3D CADで設計した設計データをメタバースに反映するということは容易でしょう。デザイン段階でメタバースにその建築物をリアルに再現し、バーチャル空間で顧客に体験してもらうことができれば有益です。また、街そのものを再現できるメタバースであれば、不動産物件そのものを空間に再現すれば、内見はかなりリアルにできそうです。

他にも、事前に体験することに価値があるような分野、例えば病院での検査や治療をバーチャルに再現するという用途もあるかもしれません。重い病気で長期療養する患者に向けて、どんなふうに検査や治療が進められるのかを事前に理解してもらえれば、患者の安心感は高まると思われますし、そういう情報を提供してくれる病院のほうが選ばれる可能性が高いでしょう。

医療関係つながりでいけば、メタバースはカウンセリングが必要な領域で効果的かもしれません。患者のカルテに加えて個人的なプロファイルをもとにすれば、学習済みの人工知能(AI)がその患者に適切なカウンセリングプログラムを自動で設計し、人あたりを患者に応じて最適化したアバターを介してAIが適切な対話を提供できれば、治療に役立つかもしれません。

メタバースの可能性のひとつは、パーソナライズできるところにあります。利用者の特性に応じて、同じ空間を使いながらも、見るものや触れるものを個人レベルで自在に変えられる特徴があります。それを活かせば、利用者ごとに異なった体験を提供したいものに有効に機能する可能性もあるでしょう。

メタバースは、いまのところバズワードの域をまだ出ていないと思いますが、本質的な特徴は何らかの形で今後実現していく可能性は高いと思います。みなさんも、いろいろと思考実験してみてはいかがでしょうか。

新卒社員が味わう「タイムスリップショック」

デジタルの素養を持つ人材不足が叫ばれるなか、学校教育でもそうした分野が拡充されてきているのは、周知のとおりです。

今年の4月から、高校では情報科目が必修化されると聞きました。情報科目自体は2003年度からあるそうですが、これまでは選択必修だったといいます。

最近の子供たちは小学校からプログラミングに触れ始め、中学高校と情報の取り扱いを継続的に学習し、大学では当然のようにコンピューターを使って課題をこなすようになりました。

2025年度からは大学入学共通テストに「情報」が追加され、入試でも学力が問われるそうです。サンプル問題が出ていましたので、実際に問題を解いてみたのですが、一見では数学の問題のように思えるものの、わたしが学生の頃にはありそうでなかった問題で、デジタル的に物事を考える「素養」を問うにはいい問題だなと感じました。

こうした環境で育った若者が、近い将来、企業に就職してくることになるわけです。こうなると、むしろ心配なのは、企業のほうだと思います。

データを見て物事をとらえ、手続きはデジタル環境でほとんどすべてをこなし、多くのやりとりをデジタル端末で済ませる生活が当たり前に思っている人材が、企業に就職した途端、タイムスリップしたかのような時代遅れの業務環境に直面する。業務上の判断をするにも、そもそも材料になるようなデータが社内に存在しない。ファクトに乏しいまま、上司や先輩は直感やら過去の経緯やら前例やらに基づいて判断を進めていく。そんなシナリオが目に浮かびます。

思い返してみれば、わたしが何十年前に就職した時にも、時代をさかのぼるようなことを体験したのを覚えています。わたしが就職した頃はインターネットが一般に広がる直前の時期でしたが、理系の大学研究室では電子メールがフツウに使われていました。電子メールでのやりとりなど、世間に名の知れた有名企業なら当然あるだろう、と思って就職したのです。ところが入社して新人研修中に先輩社員に聞いてみたところ、返ってきた答えは「いや、そんなのないですね」。就職先が通信会社だっただけに、驚愕したのを思い出します。

ちなみに、会社に電子メールが全社で導入されたのは、現場に配属された後の、その年度中のことでした。それでも、日本企業の中では早かったほうだと思います。

想像するに、わたしが当時受けたショックとは比較にならないような衝撃を、新卒の新入社員たちが就職先で受けるのではないだろうかと、いまから気をもんでいます。みなさんの会社では、そうならない自信がありますか?

「前提」が満たされていないと、経営戦略は立てられない

少なくともわたしの理解では、経営戦略を企画するにあたって「このやり方で立案すればよい」という決定版的な手法はありません。

そのせいもあり、いろんな人がいろんな方法を掲げて、自分の方法こそ常識的、と主張しているように感じます。その方法は、その人がどの分野で研鑽を積んできたのかで、けっこう特色が出ているように思います。財務に強い人は管理会計的なアプローチ、経営コンサルの人はフレームワークを駆使した手法、といった具合です。

わたしはもともとエンジニア上がりでして、経営戦略について先達に直接教えてもらう機会がありませんでした。そのため専ら文献を読み漁って研究したほうです。いろんな人が書いているものを、いろいろと読みました。そして学んだ知識をそれぞれ咀嚼しながら実践してみて良い所どりし、いま活用しているノウハウに昇華させてきています。まだ改善の余地はあるだろうと思いますが、概ね考え方のスジは固まっていると感じているところです。

わたしが考えるに、いろんな人が提示しているいろんな方法は、どれもあながち間違ってはいません。ただし、それぞれの手法をうまく適用するには必ず「前提」があり、前提を捉えずにそれらの方法を適用しようとすると、だいたいうまく行きません。

例えば、経営戦略の企画においては、大まかには次の事項が明確になっている必要があるとわたしは考えています。

  1. 顧客に対して、どのような価値を提供しようとしているのか
  2. その提供価値を実現するシナリオは、具体的に何か
  3. シナリオを実行するオペレーティングモデルは、整備されているか(または整備できるか)
  4. 計画の実行が成功し、価値が提供できたことは、どうやって認識できるのか

こと中小規模の企業において問題なのは、上記の1と2が曖昧で、定まっていないことです。

これらが曖昧なまま、一方で日々の業務に関しては、過去の経緯のもとに ”一応” 稼働していたりします。その事実だけをもって、上記の3は「できている」と理解していることが往々にしてあるのですが、それは大きな間違いです。1と2が曖昧なのに3ができていることはありえません。ですから本当のところは、3もできてはいません。

管理会計を念頭に置いた財務的なアプローチを採用しようとする経営戦略立案では、形式的に内部分析や外部分析は行うのですが、それらはどちらかというと管理会計的な問題抽出をしようという試みに留まり、実質的には上記の1、2、3をすっ飛ばして、いきなり計数管理を始めようとします。

つまり、このアプローチを採用するうえでの前提は、上記の1、2、3のすべてが揃っていることです。

このアプローチは、現在のオペレーションに大きな課題がなく、その会社の価値提供の方向性にも業務プロセスがきちんと従っているなら、問題なく適用可能であり、コストの最適化や利益の最大化といった形で成果も出せるでしょう。

しかし、前記したとおり、往々にして中小規模の企業は、価値提供のあり方、その価値提供を実現するためのシナリオ、こうしたものに具体性がないのです。その状況で計数管理的なアプローチだけ実践しようとしても、単に計数管理の仕組みが整うだけです。

計数管理では数字を追いますが、数字は「結果」です。結果をモニタする目的は、自分が思った通りの成果が挙げられたのかどうかを確認することです。そもそも「自分が思った通り」とはどういうことなのかが定義されていないところで、結果だけ追っても意味がないことです。

こういうふうに申し上げると、利益率何%だとか、在庫回転日数だとか、そうした指標を管理することに意味があるのだという反論がありますが、およそそうした目標値は、業界標準や他社との比較、場合によってはコンサルタントの「感覚」で設定された数字だったりします。しかし、業界標準は「自分の思った通り」ではありません。ですから、その数値を達成したところで、実践した企業に、成し遂げた実感は伴わないのです。

利益が出る、売上が上がる、というのは結構なことですが、厄介なことに利益や売上というのは、これまでの成り行きや過去の経緯を踏襲するだけでも上がったりするものです。何も意図していないのにたまたま業績がよいことさえあります。それをモニタしてわかることは、過去の延長線上で(なんとなく成り行きで)行ってきたことが良かったのか悪かったのか、に過ぎません。

それで構わないのなら、始めから経営戦略の企画など不要だと思います。重要なことは、財務の数字がよくなったという結果より、「自分が思った通りに」利益や売上が上がったのか、ではないでしょうか。思った通りの成果を繰り返すから、企業は継続して成長するのですから。

経営戦略を立てようと取り組まれる経営者におかれては、立案に向けて情報を取り入れる中で、専門家が言っているからといって無防備に情報を受け入れるのではなく、その手法を採用する前に整っていなければならない「前提」を探し、自社がいまどこまで満たせているのか、よく考えてみることから始めていただきたいと思います。それによって、企画への取り組みかたやアプローチは変わります。

恐れていた攻撃の手口から考える、経営とクラウド

昨年のことになりますが、ある大手小売業のECサイトで発覚したクレジットカードの不正利用をきっかけに、その企業を含む11社の小売業者が運営するECサイトから顧客情報が漏えいした可能性が発覚、それぞれ公表されるに至りました。

これらの小売業に共通していたのは、同じITベンダーが提供するECサイト構築SaaS、つまりクラウド事業者のサービスを利用していたことでした。問い合わせを受けて同ITベンダーが調査をした結果、SaaSのサーバーに対する不正アクセスの痕跡、およびサーバーに不正なプログラムが置かれていたことなどを発見したということです。

その後の分析によれば、攻撃者は、SaaSのテナントであったある小売業のECサイトを通じて不正な注文を送り、そのなかに埋め込んだ不正な命令を実行させて、SaaS内部のサーバーを乗っ取ることに成功したようです。それによって、直接攻撃されたその小売業のサイトのみならず、同SaaSを利用していた他のテナントの領域にも不正に侵入する足掛かりを獲得しました。結果、複数の企業の顧客データに不正にアクセスできたといいます。

この攻撃事例を聞いて、これまで恐れてきた事象がとうとう現実になったなと感じました。

パブリッククラウドのサービスは、巨大なシステム基盤上にサービスが構築され、それを多くの顧客が同じ条件のもとに利用する、という形態になっています。優れた機能が使い勝手の良いかたちで準備され、また初期コストのハードルがかなり低いということで、大小問わず多くの企業が利用しています。当然ながら、相乗り型のサービスとはいえ、各テナントの使い方には一定以上の自由度が確保されていますし、データも個別に蓄積できることになっています。

ただし、そうした区分けは、ソフトウェアの制御によって「論理的」に行われています。「論理的」とは「物理的」の反対です。つまり、テナントごとの区画は、戸建て住宅のように物理的に分かれているわけではなく、ソフトウェアに施された「設定」で区分けされている、ということです。

一方で、ソフトウェアには、プログラムの不具合であるバグや脆弱性が「必ず」あります。あらゆる情報システムは、バグや脆弱性は必ずあるけれど見つかってはいない、という状態で運用されているわけです。

クラウドベンダーは、顧客が利用する領域はセキュリティを確保した形で保護されていると謳っています。もし顧客にセキュリティ上の問題が発生するとしたら、それは顧客が行った設定に問題があるのだ、というのが共通した認識になっています。

そこにウソはもちろんないのですが、それはあくまで「ソフトウェアによって」成立していることです。そのソフトウェアに万が一脆弱性やバグがあれば、その保証は崩壊するかもしれません。

それが今回、実際に起こってしまったということだと思います。

注目すべきことは、顧客情報が漏えいしたことよりも、攻撃者がテナントを横断して不正を行うことができた点です。つまり、自社がどれだけ気を付けて対策を実行していたとしても、自分は知らない他の利用者を経由してサービスの大本が乗っ取られ、自社の対策は水泡と化す、というシナリオが成立してしまうということです。

今回攻撃を受けたSaaSベンダーは、決してセキュリティ対策が緩かったわけではなかったといいます。定期的なセキュリティチェックの実践、脆弱性の定期検査の受診、侵入検知サービスの利用など、一定の対策は行っていたようです。それでも今回の攻撃は防御できなかったと主張しています。

また、近年の攻撃は、アプリケーションへの攻撃から基盤ソフトウェアに対する攻撃がより増加している傾向にもあるようです。先にも記した通り、クラウドサービスは複数の利用者が共通の基盤上に構築された機能を、相乗りする形で利用します。その構造上、システム基盤で利用されるソフトウェアは利用者共通です。もし基盤ソフトウェアの脆弱性が攻撃されれば、容易に今回と同様の事象が起こりうることになるわけです。

クラウドサービスを利用するメリットは、その価値によっては非常に大きく、リスクを上回ることもあると思います。避けるよりも、うまく使うほうが賢い選択です。時代もまた、クラウドが使える前提でITを考える時代になっています。

ただし、上記のような攻撃が現実に成功していることを、経営リスクとしてよく理解しておきたいところです。預けているクラウドサービスから自社の情報が漏えいした時に、顧客に謝罪するのは、クラウドベンダーではなくてみなさん自身です。何を預けるのか。どの業務領域を依存するのか。経営にとって重要な選択です。よくわからないからIT専門の人に任せるという話ではないのです。