顧客は「目指しているもの」を見ている

先日、十年超ぶりくらいでしょうか、あるファミレスに入りました。

店に入ると、店員が出迎えにきません。わたしが知る昔の経験では、店に入るとすかさず店員が気付いて「何名様ですか?」と聞かれるという認識でした。ところが、なかなか出てきません。待っているべきなのか、勝手に座っていいのか、判断がつかずに立ち尽くしていると、ようやく店員が(わたしに気づいてやって来たのではなく)近くを通りかかったので、こちらから声をかけました。「お好きな席へどうぞ」という回答でした。 

席に座ると、タブレット端末が置いてあります。操作説明はありません。自分で勝手にその端末からオーダーしろということのようです。端末の使い勝手は特に悪くはなく、適当に選んで注文をしました。

選択したメニューはどうやらセルフでドリンクバーに取りに行くスタイルだったようなことに、注文してから気づきました。よく見直すと、ほとんどのメニューがそうなっています。それはそれで理解しましたが、セルフのカウンターに向かうと様々なものが置いてあります。ここで、何をセルフで取っていいのか、わかっていないことに気付きました。席に引き返してメニューを見返し、取っていいものを理解してから、再びカウンターまで取りに行きました。

ドリンクバーで、水とスープを自分で取って席に戻ると、先ほどのタブレット端末では動画がしきりに流れています。どうやら、注文後はデジタルサイネージに化けて宣伝を流し続けるようです。その宣伝は、わたしが店を出るまで続きました。

料理は(さすがに)店員が運んできました。食事を済ませると、見透かしていたかのようにすぐさま店員がやってきて、食後の皿を下げていきました。

ふと店内を見渡すと、入店してからというもの、店員の姿はフロアにほぼ見当たりません。かなりスタッフは少ないようです。お昼時の真っ最中の時間帯でしたが、店員はバックヤードも含めて5人いたかいないか、というふうに見受けました。

人力によるノーマルな会計を済ませて店を出て、「この店は、いったい何を目指しているのだろう」と、わたしは感じました。

このファミレスは、過去に提供していたような来店客へのホスピタリティは、完全に捨てているように思います。コロナ禍が要因なのか、恒常的な人員不足が要因なのかは知りません。いずれにせよ、店員の対応や人数だけでなく店内の業務の仕組みからみても、ホスピタリティへの努力は捨てていると判断せざるを得ません。

そうかといって、デジタルにより自動化や効率化を推し進めたようにも見えません。そうしたつもりなのかもしれませんが、感心するような取り組みには気づきませんでした。空席が目立ち来店客が少ない割に、オーダーが出てくるまでの時間はそれほど早い印象はありませんでした。少ないスタッフでも従来と変わらない提供体制、ということなのかもしれませんが、顧客には関係のないことです。

オーダー用のタブレットにしても、使い慣れている人ならともかく、不得手な客にとっては、説明もなしに操作するのはなかなか抵抗があるに違いありません。現に、ある客に店員が、「そこじゃないです、青いボタンです!」などと、操作をインストラクションしている声が、どこからともなく店内に響いていました。

そのわりに、タブレットを使って抜け目なくマーケティングしようという意図はうかがえました。しかし実際には、その映像は客にほぼ顧みられていないだろうと感じましたし、しきりに動画が流れるさまは、人によってはうざったく思えるかもしれません。

要員不足に効率化で対応しよう、デジタルでクロスセルを促そう、業務を整流化して回転率を上げよう、などという話は五月雨式に思いつくかもしれませんが、この店には「それで、何を目指しているの?」がないように思います。少なくとも、ホスピタリティの高さではないし、デジタルによる洗練された顧客体験でもないし、ファストフードのようなスピード感でもない。それらは間違いなく、客の立場からは感じられませんでした。

共感できるポリシーが感じられない店には、客はなんとなくですが、また来たいとは思いません。二度と来ないとまでは思わずとも、また来たいとは思いません。わたしのような専門家は論理的にそう思うのですが、専門家ではない一般の客でも、深層心理でなんとなくそう思うものです。

このファミレスチェーンは過去に、データ分析を緻密に実行できる情報基盤を構築したとして事例になっていました。ファミレスの業務フォーマットはおよそどの店舗も同じである可能性が高く、今回のわたしの体験がどの店舗でもほぼ同じだと仮定すれば、このサービス提供でどんなデータ分析を行ったところで、事業の発展につながる有益な情報を得ることはないだろうと推察します。

「先進的で有名になる」ことには、意味がない

ITにおいてユーザー企業が「先進的」であることには、ほとんど意味がありません。

ITというトピックになると、とかく先進性に価値があるという方向で理解されるような向きもあるようです。しかし、ITに先進的であることは、ユーザー企業にとっての目的にはほとんどなりえません。

ビジネスの成長や発展に役立つこと、顧客の支持を得ること、こうしたことに役立つことしか、企業においてIT採用の目的にはならないと思います。

こんなことは言ってしまえば当たり前なのですが、しかし現実には、そうでない動機付けでITの取り組みを考えている(ようにしか見えない)責任者やリーダーが、案外目立ちます。

先進的な取り組みをしていると、人より先を行っているように感じられて得意げになるのかもしれません。マスコミが取材しに来て褒めたたえられてうれしくなるのかもしれません。先進的な取り組みであるとして表彰されたりすれば、誇らしくなるのかもしれません。

しかしながら、中長期的に見て、そうしたことで事業として得られるものは、たいてい大したことありません。

世間に知れることでエンジニアの入社志望が増えるのはメリットかもしれませんが、同時にベンダーからの売り込みは急増するだろうと思います。「あの会社はカネを使う」と思われるからです。先進的であるということで名が知れてしまった以上、投資の手を緩めるわけにもいかなくなるでしょう。そんなふうにして投資ありきの投資を繰り返しても、事業に対するリターンを毎度創出できるはずもありません。

しばらくは、経営者がよくわかっていないことをいいことに、適当なメリットをこじつけて稟議を通せるかもしれませんが、経営者が気付いたときには、実は無用だった投資の積み重ねが大いなる不良資産に化けているかもしれません。

過去の事例を振り返れば、マスコミに取り上げられてえらく著名になった人物によって導入された情報システムや組織体制が、その人物が転職したり社長が交代したりした途端に、ほとんど否定されて違う取り組みが推進されるという、残念な顛末のケースばかり目立つように思います。

本当の意味でITをうまく活用できている企業というのは、それを手掛けたとされる特定の個人が有名になることはおよそ少ないものです。むしろ、その会社のシステムそのものが有名になります。そしてそれが脈々と引き継がれ、進化していきます。

世間に知られるようになったから、表彰されたから、などという理由で、得意満面にならないことです。そのITが自社のビジネスの役に立っているのか。顧客がそのITによってもっと買ってくれるようになったのか。経営者は、そういうことを冷静かつ多面的に評価すべきだと思います。当然、そうした評価ができるだけの知識も必要です。

成長させたい事業なら、トップが動かないとダメな理由

ビジネスがデジタル前提となる時代にシフトしつつあります。そんななか、これまでの事業の常識を変える取り組みや、切り口を変えた事業を推進するといった、新しい取り組みに挑戦する企業は増えているように思います。

こうした取り組みは、すなわちビジネスシステムを描きなおすこと、設計しなおすこと、でもあります。根本的なレベルから事業の仕組みを構築する必要があるならば、それはトップが主導し、トップが絵を描き、トップが指導して仕組みを構築することです。そうでなければ、一貫した組織行動のもとに、実現したい提供価値を実現することはできません。

トップが本気でやらない事業がうまくいかないのは、当たり前のことです。

例えば、自社の強みを生かして新規事業を立ち上げることを考えたとします。その場合、強みを生かすのは良いとしても、事業の戦略立案はもちろん、ビジネスシステムをイチから設計し、実行に移し、軌道に乗せなければなりません。

誰も描いたことのない絵を描き、未開拓の地に道を作らなければならないわけですから、その事業の総責任者であるトップがそれを描かなければ、トップより下のメンバーはリアルなイメージを持つことができません。

こういう時に、心得のないトップは往々にして、自分の得意分野ではないところを、権限委譲という聞こえの良い言葉で「全面的に」他者に丸投げします。全面的でなければ救いようがあるのですが、残念ながら全面的であることがほとんどです。そうやって、全体設計もせずに自分からその部分を切り離すのです。それが、業務の属人化の始まりになります。

業務の属人化というのは、始めのうちはあまり問題になりません。権限委譲された人が成果を出せば、うまく行ったような気になるものです。しかし、年を追うごとに、事業が拡大するごとに、属人的な業務をつくってしまった問題は顕在化していきます。

気づいたときには、修正しようにもしがたい、修正するとしたら多大なるコストとエネルギーを伴う課題と化すのです。そしてたいていは自力で修正できず、ある日、依存度を増した特定の人物が機能しなくなることで、事業の成長は止まります。

他にも例えば、トップが本気で取り組まないがために、現場における過去の成功体験からくる考え方や、染みついたカルチャーを変えられないケースがあります。

モノ売りを得意としていた会社が、これからはコト売りだと宣言してサブスクビジネスを始めようとしたとします。

言うまでもありませんが、モノの販売とサブスクビジネスは、似て非なる事業です。モノの販売では、売ってしまえば顧客との関係はそこでいったん区切りを迎えます。一方でサブスクビジネスは、顧客が商品やサービスを継続して利用することによるLTV(Life Time Value)を最大化することを目指す事業です。

つまりサブスクは、商品やサービスを売ってからが本当の勝負の始まりです。顧客と定常的に接点を確保し、使用状況を把握し、困っていることがあれば企業側から手を差し伸べ、必要ならばアップセルやクロスセルを勧奨し、新機能やサービスの開発を間断なく進めて提供し、顧客が自社の商品やサービスによって成功を収めてくれるように、継続的に働きかけることが重要だとされます。

そうした一連の取り組みを「カスタマーサクセス」と呼ぶわけですが、これはモノを売って終わっていた企業からすれば、かなりのマインドシフトを伴う取り組みです。

マインドシフトが組織としてできないまま、モノ売りのカルチャーでサブスクに取り組もうとすると、口で言うこととは裏腹にまったく行動が伴いません。

言葉ではコト売りしよう、顧客のカスタマーサクセスを実現しよう、などと言っているわりに、KPIは相変わらず商品やサービスの販売数や販売時の利益で測定する。事業施策もモノ売りの販促と何も変わらない。カスタマーサクセスなどと一応称しているけれど、行動の実態は従来の「カスタマーサポート」と何も変わらない。なにより顧客の情報を自分で持っていないし集めようともしない。顧客のLTVを向上させることの重要性は頭では理解しているのに、現場では「商品の手離れがよいのが営業的にはベスト」などと指示が出ている。そんなことがフツウに起こります。

それもまた、トップが従来から染みついたカルチャーを根本から変えようと本気で取り組まないから、起こることです。

本当に成長させたい事業なのであれば、トップが主導してビジネスシステムを設計するべきだと、わたしは思います。

ITを「ツール」にしている会社のザンネンな誤解

ここ最近は、中小規模の企業でも、ITを一切使っていないという企業に出会うことはほぼなくなりました。どの企業でも、何らかのソフトウェアやデジタル機器が使われています。

ただし、典型的な誤解のもとにITがうまく使えていない企業も、いまだ多いように感じられます。

例えば、バックオフィス周りは結構IT化しました、勤怠管理、会計処理、給与等々。でもその程度で、会社の中でITの存在感は特に大きくありません、というケース。

別の例で、ウチは結構ITは使っている、いろんなツールを入れて使ってきた、でもこれでいいのか、なんだかモヤモヤしながら使っているんだよね、というケース。

ITはずいぶんその適用範囲のすそ野が広がり、安価で手軽に使えるようになりました。それはとてもよいことなのですが、企業が自らの事業の強化のためにITを使おうとするのなら、素人考えでの使い方から脱しないと、なかなか「強化」するには至りません。

ITがうまく事業の強化につなげられていない会社というのは、ITが「便利なツール」程度にしかなっていません。

例えば、あるA社では、外回りしなければならない営業担当者が、会社に戻らないと客先に電話連絡できなかったところに、会社がひとり一台のスマホを支給したところ、出先からでも顧客に電話ができるようになった、という話をしているとします。

一方で、同様にスマホが営業担当者に支給されているB社では、客先に定期的に送っている情報は頃合いを自動的に見計らってメールで送信されるようにしていて、もしそれに反応があった場合には担当者に通知が自動でスマホに届くので、その時に初めて客先に連絡を入れる。直接の訪問先は厳選されるので、そもそも外回りの頻度自体は多くない、と言っているとします。

A社とB社では、同じ外回り営業のことでも、全然質の異なる話をしています。あくまでわかりやすく丸めた例ですが、概ねこんな雰囲気の違いが見られるのです。

どこで、こうした違いが生まれるのでしょうか。

たしかに、どこででも自由に電話ができるようなったのは、ひとつの効率化でしょう。しかしA社は、そもそも出先で電話のやり取りが必要になるのはなぜか、という疑いは持っていません。B社は、その根本要因を問うことから始めているから、A社とは根本的に異なる営業プロセスの発想が生まれるわけです。

A社のITの使い方は、素人の域を脱していません。フツウの人が、電気屋で家電を買ってきて使う、カーディーラーで車を購入して運転する、といったレベルと同じです。

こうした使い方では、ITは単なるツールです。もちろん、それで満足できるケースもあるでしょう。しかし、その程度の適用なら、他の会社でもできます。事業の強化になっているようで、実はその程度の活用は世間的には平均レベル、当たり前の活用でしかありません。

一方でB社の場合、ITを使うことによって「システム」にしている、と言えます。

システムというものの意味は、実はけっこう誤解・曲解されています。「システム」という語は当然ながら英語から来ているのですが、辞書を引くとこんな定義が書いてあります。

a group of related parts that work together as a whole for a particular purpose

出典:Longman Dictionary of Contemporary English

つまり、「特定の目的のもとで」「一体となって連動する」「関連した部品の」「集まり」、ということです。

何らかの目的を定め、それを達成するための仕組みを設計し、仕組みに必要な部品を集め、連動するように組み立てる。そのための基盤やパーツとして、ITを使っているのです。

これが、本来の「システム」です。

単にITという「ツール」を使っているだけなのに、「ウチはシステムを入れている」と主張する企業が結構いるのですが、まったく誤解しています。「システムは設計しないとできない」という事実が抜け落ちているのです。

いわゆる ”DX” に必要なこととは、これまで行ってきた習慣ややり方が本当に必要なことなのかを疑い、自社のあり方をデザインし、それを実装できる、組織としての能力です。

大正時代ならクルマを持っているだけで強力なアドバンテージだったのが、いまやクルマの所有はたいして感心はされないフツウのこととなっています。ITもまた、単なるツールで使っているだけなら何のアドバンテージにもならないフツウのことであると、改めて認識して、その先へ早く進みましょう。

「アプリは自社で内製」がフツウになる時代

近年は、アプリケーションを内製開発する企業がずいぶん増えてきたように感じています。

背景には、ノーコード/ローコード開発ツールのようなプログラミングを簡易化するソリューションの充実、SaaSやPaaSの機能充実化などがあります。コードが書けなくても、専門知識があまりなくても、パーツを組み合わせるような形で処理を組み、データの器を用意することで、簡易で単純なものであれば、動くアプリケーションが短時間のうちに完成してしまうようになっています。

アプリケーション開発の敷居が下がったことで、モノによっては、現場の業務部門の人でも欲しいアプリケーションを自作できるような状況になっています。そうであるなら、外部のベンダーに頼んで何カ月もかかるよりもはるかにメリットがあるということで、ソフトウェアを内製する企業が増えているわけです。

かつてEUC(End User Computing)という概念が流行しました。そのときと同じような雰囲気があります。EUCはその後廃れましたが、なぜ衰退したかというと、各所であまりにも好き勝手にプログラムが作られて、会社としてそれらの管理が行き届かなくなり、作ったものを誰もメンテナンスできなくなった、ということが要因のひとつでした。エクセルのマクロにも、同じような話があることは有名です。

今回の内製化の動きでも、同じような事態に陥る企業はおそらくあるでしょう。ただし、過去の反省を踏まえて、制作したアプリをうまく管理する仕組みを導入したり、またはそれを意識したガバナンス体制を敷くなど、工夫する企業も多くあります。

さらには、アプリと共に使えるセンサーやモジュール、はてはロボットまでも、割と手軽に手が届く状況も生まれています。価格も比較的低下し、またインタフェースが標準化されてきたことで、アプリとの連携も随分しやすくなりました。一昔前までは大企業がおカネを相当かけてやっていたようなことが、それこそ個人レベルでも実行可能な状況なのです。

うまく内製してアプリを使いこなしている企業を見ていると、そうして自在に開発すること自体が、対応力・スピード・柔軟性などといった競争力に直結するようになってきていると感じます。こうした状況が定着すれば、そのうちに、どんな着想を得られるかというアイデアの勝負になっていくかもしれません。または、どのベンダーのプラットフォームを選んで開発しているか、という点で差がつくような事態も、生まれるかもしれません。

ただし、当然ながらうまい話ばかりとは言えません。ノンプログラミングで開発できるようなツールは、複雑で高度な処理の構築はあまり得意とはしていません。部署内の単純作業のような、小さく閉じる領域なら向いている傾向なのが現状です。また、ツールによって得意分野が異なる傾向もあり、選定のしかたも重要になります。

目利き力は要求されるものの、試すだけなのであれば、資金的なハードルもかなり低くなっています。できる人がいないと嘆くより早く、どんどんやってみることができる企業のほうが先に進む。そんな時代になっていることを、経営者の方々には十分認識していただきたいと思います。

データがある会社とない会社の、大きすぎる差

おおよそそうではないかと思っているのですが、ビジネスの仕組みが明らかではない会社には、使えるデータもありません。

使えるデータをたくさん持っているのにビジネスの仕組みはいまいちだという会社を、わたしは寡聞にして知りません。逆に、ビジネスの仕組みづくりに長けている企業には、たいていは多くの使えるデータが存在しています。

そういう傾向になるのは、データに次のような特性があるからです。

まずデータは、使おうとする人が自分で「取ろう」と思わなければ、存在すらしません。自然にそこにあるように思われがちですが、そうではありません。自然にそこにあるデータも見つけることはできますが、それは誰かほかの人が取ろうと意図して取得したデータに違いありません。そしてそういうデータは大抵、自分にとって使えるデータにはなっていません。

次に、データは何らかの目的をもって取らなければ、そもそも意味を成しません。意味をなさないのなら、使えないデータです。何かの情報システムやソフトウェアを入れたりすると、それが勝手に内部でデータを取っていたりします。しかしそのデータ取得が自分が持つ目的に合ったものでないなら、きっとそのデータが参照されることはありません。見たところで意味がないからです。漫然とデータが取られているだけならば、自分に見えてくるものは何もありません。

さらに、データというのは、使わないのなら持っていないのと同じです。出してくれと言われれば多くのデータを揃えて提出できる会社はたくさんあります。しかし、それらのデータを普段から自分で使っていないのだとしたら、実はそれらのデータを出力できない会社とあまり変わりはありません。

最近、AIを適用して業務能力を向上させる事例が、業種を問わず出てきています。ただ一方で、AIを使える企業と使えない企業の差が、かなり顕著になってきている側面もあります。その要因は、技術力の差というよりも、つまるところデータの差です。AIはデータを食べさせることで育成されます。自社内に使えるデータがない会社は、そもそもスタートラインに立てないのです。

データというのはまた、過去から現在までの蓄積の賜物という側面もあります。ある企業では、職人技の調整を要する業務にAIを適用して判断精度の向上を図ろうとした際、数十年にわたって記録してきた作業日報を活用したそうです。そこには、調整のノウハウと、成功失敗の履歴が詰まっていました。

おそらくこの会社では、「どう調整したらうまく行くのか」を長年追究し続けてきた結果、一定の「仕組み」が出来上がっていたのではないでしょうか。その蓄積が、作業日報でした。もちろん紙の情報でしたが、これをデジタル化してAIに学習させたのです。

職人技に依存する多くの企業は、その技を言葉にしようとする努力を欠いています。実際、言葉にしようとすると大変な労力を要します。それでもなお言葉で表現しようとする取り組みは、つまり属人的な仕事を仕組み化しようとするものにほかなりません。仕組みを構築するマインドがある会社はおよそ、データ化する取り組みは自然に実行しているものなのです。

会社のレベルと、問題の感度

様々な会社を訪問していると、業種業態にかかわらず、ある特徴から会社の状態を推し量ることができることに気づきます。

例えば、社内の問題に対する「感度」です。成長性が高く勢いを感じる会社ほど、社内に内在する問題に対する感度が高いようです。様々な改善点に日頃から気づき、それらに対処しようと考える。こうした流れが常にあります。問題があるのはある意味フツウのこと、問題がないなんてありえない、早く発見して早く対処すべし。そういう考え方をしています。そのためか、社内の雰囲気は明るいけれど、常によい緊張感がある。そんな印象です。

逆に、勢いがない会社ほど、問題に対する感度が低いように感じられます。社内には多くの問題が存在し、それは第三者の視点ではかなり目立つものであることも多いのですが、それとなく水を向ける程度だと「特に問題とは思っていない」という回答が返ってきたりします。そのためか、社内にはどこかのんびりした空気が流れている。そんな印象です。

問題山積の会社ほど目が回るほどに忙殺されているかと思いきや、そういう会社ほどのんびりした雰囲気に包まれている、というのは、ずいぶん皮肉なものだと思います。

そうなってしまうのは、会社において「何を問題とみなすのか」という基準の厳しさに差があるからでしょう。厳しさに差がある、とはつまり、その会社が達成したいクオリティやレベルの違いです。ひいては、その会社のミッションやビジョンの位置づけの違いということになります。問題の感度が低い会社には、そもそも明確なミッションやビジョンが定義されていないことも多いものです。

言葉を変えれば、その会社にとっての「当たり前」が何なのか、それをいかに社内で固く共有しているか、この差であるとも言えるでしょう。世間で凄い会社と言われるところは大抵、現場の業務を個別に観察するとおよそ「やって当然」の仕事をこなしているように見えて、その当たり前の仕事をこなす「レベル」が普通ではないのです。

よく言われることではありますが、問題を解決するスキルは重要だけれど、もっと重要なのは、問題を設定するスキルです。間違った事柄を問題として捉えれば、どれほど正しく問題を解いたとしても、出てくる答えはやはり間違いです。データ分析の世界には、”Garbage in, garbage out.” という戒めの言葉があります。厳しい言い方ですが、「ごみを入力したら、出力はごみ」という意味です。

このようなことから、問題に気づき設定する役割にあるマネジメント層の能力というのは、非常に重要だと感じます。

コンサルが「正しい」助言をしにくいとき

先日、同業のある知人から、こんな話を聞きました。

ある中小企業の社長から、DX推進に関してどうしたらよいか支援してほしいと打診を受けて、事情をヒアリングしに行ったのだそうです。会社を訪問すると、社長からその場で経営計画からDX推進の体制案まで、いろいろな文書を見せてもらったと言います。すでにその計画は社内に展開され、社長自ら社員向けに説明も行っているということでした。

訪問先の社長はかなり勉強熱心な方だったようで、計画は自分で立案したがコンサルタントを入れたことはこれまで一度もない、と言っていたそうです。

随分と完璧に見えますが、提示された文書を知人がつぶさに見通すと、その計画は相当に未熟なものに映ったと言います。ミッション、ビジョン、行動指針といった企業理念の3点セットは高らかに謳われているのはいいけれど、それを実現するロジックがまるで考えられていない。

現場の社員たちには、社長が掲げる経営計画に従って自部門の目標をブレークダウンさせたそうですが、その内容を見ると、部門視点の発想から生まれるようなお決まりの目標しかない。それは無理もないことで、スローガンだけ掲げられて経営シナリオが提示されないから、社員から見ると全体の構図がなにもイメージできないわけです。そのため結果的に、過去の経緯と自部門の課題意識の範疇でしか発想ができない。

ヒアリングの席では、進め方に対する社員からの反発はすごいという話だったそうです。それは当然そうなるだろうと、わたしは思います。

それを受けてこの知人はどういう提案を考えたか。結局、その社長の経営計画に沿ってDXを推進する支援企画を考えたのだそうです。

本来ならば、経営計画のレベルからやり直すのが正論です。経営計画が納得感をもって現場まで降りていないそもそもの要因は、社長が立案した経営計画が未熟だからです。漠然としたビジョンを具体的なシナリオにしない限り、起こっている問題は根本的には解決しません。しかし、そうはしない。なぜかといえば、すでにその計画は社内に展開され、社長が自ら説明してしまっているからです。

もし正論を通せば、その経営計画を全否定するように聞こえる。社長自身のモチベーションも低下するし、プライドも傷つくかもしれない。社内も、突如として方針転換がなされたように見えて混乱する可能性もある。支援を推進して成功裏に完了させるには、未熟な計画なことは承知で、それとなく促して良い方向になるように仕向ける支援をし、うまく立ち回ることを選択する。こういう判断です。

この判断は、まったく妥当だと思います。しかし一方で、この社長は損をしたなと、わたしは思います。勉強熱心なのはよいことですが、社長業をしていれば専門家ほどに究めることはほぼ無理です。勉強不足により我流に陥りすぎる結果に嵌るが、自身はそれに気づかない。そのまま他人に相談せずに、計画を実行してしまいました。計画を展開する前に識者に相談していれば、おそらく適切な助言がもらえ、実効性の高い計画立案ができ、それを良い形で社内に展開して円滑に浸透させられていたのではないでしょうか。

専門家であっても外部の人間がアドバイスしにくい状態になっている場合がある。それによって、本来なら得られていた助言が得られなくなる。そういうことがありえると、経営者のみなさんには頭の片隅に置いておいていただきたいと思います。

クラウドでサービスをつくり込む企業の「責任感」

あまり目立っていないように思えてならないのですが、ここ最近、AWS、Azure、Google Cloudと、いわゆるメガクラウド事業者で相次いで大規模障害が発生しています。

それに伴って、例えば気象庁のホームページが閲覧不可となったり、仮想通貨を取り扱うコインチェックではサービスが全面停止したりなど、多方面での影響が発生しました。

その中で、いわゆる「スマートホーム」の機能を担うデバイスにも、様々な影響が出たという話もあります。例えば、家電の操作をスマート化するデバイスです。エアコンや照明の電源を外出先から操作できたりします。こうしたデバイスを扱うサービスも、パブリッククラウドサービスを基盤にして機能を実装しているケースがかなり多いと見られます。

その場合にクラウドが障害になってスマートデバイスが機能しなくなると、利用者はどうなるか。容易に想像できますが、スマートデバイスに依存した生活をしていれば、オンオフや開け閉めといった操作は一切利かなくなります。かわりに手動で対応できればよいですが、リモコンがないと操作が事実上できないという家電も、最近は少なくありません。スマホでの操作に依存しきっていてリモコンがもはや手元にない、またはそもそもスマホからの操作しか想定されていない、などの場合は、結構つらい状況になることがありえます。

例えば、スマートロックだとどうなるでしょうか。家のカギをスマホで開閉錠できるようになるデバイスです。完全にこれに依存し、物理的な鍵をもう持ち歩いていない人が、外出中にクラウド障害に見舞われてデバイスが機能しなくなったら、家には入れなくなるかもしれません。

高齢者や障がい者が、生活に欠かせないツールとしてこれらのデバイスに頼っていた場合はどうでしょうか。機器などの切替操作などが身体的に困難なために音声認識でそれを実行するようなケースです。もし突然、音声認識が動作しなくなったりしたら、死活問題に陥るリスクもあるかもしれません。

わたしが気になっているのは、こうしたデバイスを供給しているサービス事業者が、どこまでクラウド障害によるサービス影響を「自分のこと」として捉えているだろうか、ということです。

パブリッククラウドを基盤に自社のサービスを構成した以上、クラウドが障害になれば、サービス事業者側ではなすすべはほとんど何もありません。ただ、障害復旧を待つのみです。ですから、「クラウド側が障害のため、復旧までお待ちください」とアナウンスするしかない、というのは正論です。しかし利用する顧客にしてみれば、サービス事業者からサービスを買っているのであって、クラウドを使っているつもりはありません。

クラウド側で何が起ころうとも、サービス事業者側ではコントロールすることはできません。ですから、クラウドが障害で止まるとしたら仕方がない、復旧が遅くてもあれだけの技術を持つすごい企業なのだからそういうものだと捉えるしかない、と考えるのは正論です。しかし、利用する顧客が見ているのはサービス事業者のほうであり、対応がまずくて信頼を失うのもサービス事業者のほうです。クラウド事業者ではありません。

スマートデバイスは、”現時点では” 社会基盤になるほどには普及しているとはいえず、仮に利用が全面的に止まったとしても、社会に大きな影響を与えるには至らないでしょう。サービス事業者の方針や態度が他力本願であったとしても、問題にはあまりならないと思います。

ただし、もし今後生活のスマート化が当前に組み込まれる社会が到来するとしたら、そのときサービス事業者は、より厳しく社会的な責任を問われることになります。そのときになってから、他者に左右されない基盤を自ら開発運用する能力を身につけようと思っても、時すでに遅しだろうと、わたしは想像します。

クラウドファーストだと言われているのに何を後ろ向きなことを、と言う論者もいるかもしれません。しかし、世間は通常、いかなる時でも一定以上のクオリティを要求し、不備を感じれば容赦なく批判します。通勤時間帯に通勤電車が全面ストップし、車内に「クラウド障害の影響で電車が発車できません。復旧までお待ちください。復旧の見込みは不明です。」などというアナウンスが流れたら、利用客はどう思うでしょう?少なくとも翌日のマスコミの記事の見出しは、鉄道会社を擁護するものにはならないと思います。

クラウドを使うのは、イージーです。使うほうがトクです。しかし一方で、牙を抜かれていないか。自らは何を重要な能力として保持し、なにを他者に依存するか。こうしたことは、経営者が考えるべきことです。技術分野だの専門知識だのは関係ありません。エンジニアは往々にして、イージーで見た目格好よさそうなほうを取ります。

高度になるIT、問われる組織の能力

ここ最近は、クラウドにまつわるセキュリティ事故の話が目立っていたように感じました。

例えば、セールスフォース・ドットコム(以下、SFDC)が提供するクラウドサービスを使う複数の企業において、第三者が非公開情報にアクセスできてしまう状態になっていた問題。この問題では、名のとおった大企業、情報セキュリティに関しては高い管理知識を有するはずのIT企業などが、挙って同じ問題に陥ったことを公表しました。

SFDCに関連した問題のほかにも、グーグルが提供するクラウドサービスを利用する企業で内部の業務連絡のやり取りが気付かぬうちにオープンになっていた問題、某キャッシュレス決済事業者における加盟店情報約2007万件の漏えい事件、なども報道されていました。

上記で取り上げた問題に共通する要因は、「設定ミス」です。設定の不備によって、本来公開してはいけない情報が一般公開設定となり、インターネットから閲覧可能な状態となっていた、というわけです。

一般に、クラウドサービスを利用するにあたっては、さまざまな設定を利用者の責任の下で実施することになっています。従って、設定にまつわる障害や事故は利用者側の問題として扱われるのが通例です。

ただし、今回のSFDCの問題は、利用者の対応の甘さに全面的な責任があるとは必ずしも言えない面があるように、わたしは感じます。というのも、設定不備の原因となったのがSFDC側による機能のバージョンアップにあるからです。約5年前に行われた機能追加にその火種があり、その際に、新機能の導入により適切な権限設定をしなければ情報漏えいにつながる可能性が生じたといいます。その旨の情報が利用者に適切に提供されていなかったのではないか、そもそもSFDCはそのような脆弱な設定になり得ることを予測していなかったのではないか、という声が少なからずあるとのことです。

つまり、知らぬ間に外部のアクセスを許す状態になっていたという利用者が大勢いたということであり、それは利用者側の「設定ミス」として片付けられるものなのか、という認識が生まれるわけです。至って自然な考えではないかと思われます。

しかしながらこのような状況を踏まえてもなお、結局は利用者が被害や影響を受ける立場になることに変わりはないのが実情です。クラウドサービスは、提供者側の都合でアップデートや機能追加が頻繁に行われます。それが良さであるという評価も一方ではあります。クラウドを利用するということはつまり、利用者が提供者に振り回される面がある、という理解が必要なのです。

設定ミスは人為的なミスなのだから、使う側が気を付ければよいことではないか、と思うかもしれません。実際に使ってみればわかることですが、クラウドサービスは、使い込もうとするほど、または機能が豊富で高度な要求を実現できるものほど、設定は単純では無くなっていきます。利用者側にも、それなりの「ユーザーレベルの高さ」が要求されるのが実態です。それはある意味、当然のことでもあります。

先日セキュリティの専門家から話を聞きましたが、サイバー攻撃の攻撃者がどのような攻撃手法を好んで選択するのかというと、端的に言えばコストパフォーマンスが高い手法が優先されるといいます。かつては多かった、自らの技術を誇示したい攻撃者というのは近年ではほぼ皆無で、手っ取り早く価値の高い情報を搾取し、お金に変えることを目的にしているのです。そのとき、一番コスパが高い狙い目というのが、実は設定ミスや運用ミスを突くことだと指摘していました。

クラウドは利用のハードルが低く、その気になれば利用の幅をいかようにも広げられる面があります。一昔前なら何千万円と支払わなければ手に入れられなかったような技術を、月数千円程度で利用できるようになっています。技術的に出来ないことは、もはやほとんどありません。これは、ITの急速な技術進化の賜物です。

ただし、利用する側にそれを操れるだけの組織的能力があるのかどうか。利用する企業は常にこの点を、自問自答する必要があります。能力を持たざる企業に高度なITが使いこなせないのは、プリウスに乗っていたドライバーが今日からF1カーを乗りこなそうと思ってもできないのと同じです。

特に中堅中小企業は、ITにかかる組織の整備が脆弱な傾向があります。クラウドをどんどん使おうとするわりにIT担当者は兼務しかいない、でいいのか?経営者の方々には、自社で何らかのITを使おうとするなら、まずは組織能力を問い直すこと、いかに整備を進めるか考えること、をお勧めしたいと思います。そうでなければ、安易な設定ミスにより足元をすくわれるリスクを抱えることになります。