「日本の経営者は IT に無関心」に異議あり

日本の企業経営者はITに弱い、ITを理解しようとしない、とよく言われます。

この意見、外れているとは思いませんが、ズバリ当たってもいないと、わたしは考えています。

たしかにITには関心が低い傾向が強いだろうと思いますが、それよりもむしろ、ビジョンやアイデアを描いて試す必要性への関心のほうが低いように思えてなりません。

経営者は経営の仕事で多忙であり、現場レベルのことにかまっている暇はない、という認識が典型的にあります。経営の仕事は、その判断や指示が会社の行く末を左右するタフな仕事であることは確かです。しかしそうだとしても、現場が自社のビジネスをどのように動かしてくれているか、さらにそのパフォーマンスを高める余地はないか、ということに、かなり無頓着な経営者や経営幹部が多いように感じています。ある意味、売上や他社しか見ていないところがないでしょうか。

経営者が自らビジネスを構想し、「こういうものを世の中に提供したい」「顧客にこういう体験をしてほしい」と強く思っているのなら、実務を社員という他人に委任する以上、思い描いたものを実際に提供できているか、もっとよくできないか、ということが、気になって仕方がないはずです。そういう経営者は、思い描いたビジネスが実際に可能になる業務のしくみを整備しようとし、そのうえでKPIなどの指標を用意しながらモニタリングして課題の発見と解決を素早く図ることができるしくみを整備しようとするものです。

しかし、そのような「しくみ」の意識が高い企業は多くないのが現実です。無頓着であるとすれば、それはつまり、推進したいビジネスを自ら構想し具体化するというプロセスをそもそも経ていないことを意味するのではないでしょうか。

世の中をリードする企業はおよそ、アイデアをカタチにして世の中に提示しつづける企業です。

最近の自動車業界では「自動運転」の技術がさかんに取りざたされるようになりましたが、話題の先鞭をつけたのは自動車会社ではないグーグルです。彼らは自動車業界に参入したくてそうしているのではありません。これを使って効率的に人とつながるビジネスを加速したいわけです。自動運転する車ができるなら、配送業者に頼らず自らで配送を手掛けることが可能になります。顧客と直接つながるきっかけを増やすことができれば、彼らが最も欲しい「情報」をつかむきっかけもまた、増えることになるのです。

アマゾンは最近、顧客の家庭や生活の中にまで潜りこもうとする傾向が顕著です。Kindleは有名ですが、それ以外にも、口頭で音声入力したりバーコードを読み込ませたりするだけで注文できるDashという端末を発売したり、家庭用ロボットのようなechoという商品の販売も始めました。彼らは「必要なものは何でもアマゾンで買ってほしい」ということだけを考えているように見えます。その目的につながることをどんどん発想するから、結果的に小売業とは見紛うような分野にまで足を踏み入れるし、それをためらわないのだと感じます。

もちろん、こうした発想は、グーグルやアマゾンの経営者がすべて自分で発想したものではないでしょう。しかし少なくとも、しくみの新たなアイデアの発想を奨励し、それが自然にできる環境を整え、アイデアは実際に試すことをとおしてよりレベルの高いビジネスを実現しようという強い意欲が、経営者にあることは間違いありません。わたしは経営者の最大のシゴトは「しくみづくり」だと考えています。経営者にその意欲なくして、勝手に社員がすばらしいモノゴトを生み出してくれることはないのです。

そして実は、経営者がITに強いと、こうした発想がいろいろと出てきやすいのもまた、事実なのです。IT技術の進化は、これまで不可能だったことを可能にしてくれます。それが、アイデア発想の源泉になるのです。「アイデアを描くこと」と「IT」は、ここでつながります。

ITに関心のない経営者がいたとしたら、それはもっと深刻な問題かもしれない。これが、わたしの仮説です。

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

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

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

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

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

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

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

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

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

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

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

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

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

システムのオーナーシップは、だれが持つべきか

先日、ある大手企業のCIOのインタビュー記事を読みました。

その方は就任早々、システムのオーナーシップはIT部門で持つことにしたのだそうです。

いわく、各部門が個別にシステムを持っている状態で、たとえ無駄や重複があってもどこかの部門が自ら「統合しよう」とは言い出さない。IT部門がオーナーなら、それが言い出せる。ワークスタイルを変えるべき場合でも、それを言い出して推進する部門はいない。IT部門が全体俯瞰する立場なら、それを言い出せるのだ、と。

記事の解釈違いがなければ、IT部門がオーナーシップをとる理由は、会社を全体俯瞰して全体最適なシステムをスピード感を持って整備するため、と要約できます。

「オーナーシップ」ということばは、少し広い概念を示す言葉であるように、わたしは感じています。このことばを考えるとき、念頭に置くべきことは2つあると思います。

ひとつは、業務構造デザインに対するオーナーシップ。もうひとつは、システム導入に対する成果責任のオーナーシップです。

業務構造デザインのオーナーシップとは、つまり、業務のあり方を全体最適に維持する責任を意味します。このオーナーシップの持たせかたはさまざまです。業務プロセス改革を推進する専任部門を設置するケース、各業務部門が参加する部門横断の検討委員会組織を設けるケースなど。珍しいケースでは、業務部門とIT部門の統括責任者としてCPO(Chief Process Officer)を置く企業もあります。CPOが業務最適化の指揮を執る、という、大変わかりやすい手法です。

ただ、どのパターンにしてもいえることは、業務にもITにもバランスよく牽制が利くような体制を採っている、ということです。

一方、システム導入の成果責任のオーナーシップについては、システムを利用する業務部門が、予算権限も含めて責任を持つのが主流です。

従来は、このオーナーシップはIT部門が持つのが通常でした。しかしその結果、システムを利用する側である業務部門が、システム導入にあたって主体的に行動しない傾向が顕著になりました。いわゆる「丸投げ」です。結果として、システム導入のコスト意識なくあれもこれもと要求し、結果として作りこんだ機能の多くが実際には使われない、またはシステムの機能を使いこなせない、という事態が問題視されるようになりました。

システムというのは、導入するのが「結果」なのではなく、使って成果を出すのが「結果」です。使うのが業務部門なのであれば、成果責任は業務部門が最終的に負うべきであるし、使う側が成果を出しやすいように最初から主導すべきである、そう考えられるようになったのです。

組織設計のあり方は、企業文化などの関係もあり、一概に最適な手法を語ることはできません。ただし、体制のパターンに対するメリットやデメリットは、他社事例から学べるところがたくさんあります。これはもちろん、その施策や責任者のことばを表面的に理解するのではなく、背景や本質を読み取るということです。

特に、ある企業が体制を採った後、数年経ってどうなったかまでを知ると、興味深い知見を得られることがあると思います。

その社外取締役、なぜ置いたのか

過酷な条件で従業員を労働させていたとして、アルバイトが大量離反するなど問題になったゼンショーホールディングス。問題発覚後、同社は第三者委員会を設置、7月末に調査報告書が同社に提出されました。

その報告書によって現場の厳しい労働実態が明らかになったのは周知のとおりですが、合わせて、トップレベルでの管理体制にも、問題の焦点が向けられています。

報告書によれば、現場からの勤務実態の報告や、退職者が続出している状況は、事業部門レベルでは把握していたようです。しかしこうした情報は、取締役レベルにはまったく上がらない状況だったとされています。

同社には社外取締役が置かれていました。本来、社外取締役は、専門的な知見や経験を活かし、外部の視点で会社の運営に貢献するのが役割です。社外取締役には、内部の人間が悪しき環境に慣れきって麻痺してしまっている場面でモノ申す役割が期待されます。しかしながら同社では前記のような状況だったため、社外取締役もこうした情報を把握できなかったということです。つまり、「外部の目も利かない」状態でした。

このような事態が明らかになると、その企業における「仕組みに対するこだわりの浅さ」が、残念ながら見えてしまいます。

社外取締役の設置は、ここ最近では一種のブームになっているようで、多くの企業が設置を検討し、実際に設置しています。外部の目を置くことは大いに有効でしょう。また、2015年4月に施行予定の改正会社法では、選任しない大企業には株主総会でその理由の説明を義務づけています。事実上義務付けられることから、今後もこのトレンドは続くと思われます。

どなたかとのお付き合いの都合だとか、もしくは株主向けに見た目がよいなどの理由なら話にもなりませんが、本来、社外取締役を置くのだとしたら、そこには目的がなければなりません。社外取締役は、その目的のもと、社内でなんらかの役割と働きを占めるはずです。そして彼らに期待される役割と働きがあるのであれば、それはなんらかの仕組みの一端をなしているはずです。

そうした仕組みのないところに、ただポストだけを置いたところで、意味を成すはずがありません。

社外取締役に外部専門家の視点と役割を期待するとしましょう。それなら、彼らによいアウトプットを出してもらうために、どうやって彼らにインプットするのかを考える必要があります。彼らの知見を効果的に引き出すには、適切な情報が必要です。そのためには、社内の取り組みや状況が明確に伝わるような仕組みを用意し、鮮度の高い情報が抜かりなく共有可能な状態が要求されます。さらに言えば、社外取締役が発したフィードバックを現場にインプットし、具体的な対応をモニタする仕組みも重要です。

これらができてはじめて、ご参画願うことができるのではないでしょうか。

ゼンショーの事例を聞くと、社外取締役設置の目的にかなう仕組みを整えることなく、単に任命して取締役会への出席をお願いしただけに過ぎなかったのではないかと思えてなりません。

およそ強い企業とは、所作のすべてに意味があり、なぜかを問えば「そこまで考えているとはすごい」と言われるほどの回答をする企業ではないでしょうか。どの世界においても、およそ優れたプロフェッショナルにはそのような特性があるように感じます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ITを使いたおす組織のしくみに、通すべきスジ

たまたまなのかもしれませんが、ここ最近「組織のありかた」に関する記事や論考をよく目にしています。

ビジネス分野でいえば、「イノベーションを創出する組織とはどういうものか」「人材育成とは」「リーダーシップとは」 といった類のもの、IT の分野では 「ビジネスに貢献する IT 部門のありかた」「業務部門との人材交流の方法論」 といった類のものです。

わたしの関心分野は 「ビジネスの仕組み」 であり、そのなかには組織の仕組みも含まれますので、とても興味のある話です。こと IT 部門のありかたに関しては、さまざまな取り組み事例があって興味深いものがあります。

同業種であっても、企業ごとに社内環境も文化も異なります。そうなれば、組織づくりのアプローチにしても採用する手法にしても、それぞれの企業で独自に工夫が必要です。組織づくりの方法に、マニュアルや教科書のようなベストプラクティスがないのは、ある意味当然だと思います。

しかし、さまざまな事例を見ていると、うまく組織設計できている企業は、ビジネスとの連動を主眼に組織を最適化させるというポリシーが明確だと感じます。いくらベストプラクティスがないとは言っても、組織デザインの工夫の根底にある思想については、どのような環境や条件であれ、いかにビジネスをうまくオペレートするか、いかに顧客にうまく価値提供をするか、という筋が通っていることが重要です。

IT 部門のありかたに関する論調を読んでいると、次のように考える向きも見かけます。

従来の IT 部門は、汎用業務を支える業務システムを管轄してきました。一方で、ここ最近要求が高くなっている「ビジネスに役立つ情報システム」は、顧客へのサービスを提供するシステムです。汎用業務の情報システムとは毛色が異なるし、既存のシステム運用だけで IT 部門の手はいっぱいです。だから、別の部門を設置し、サービスをつかさどるシステムを運用すべきだ、というものです。

これはこれで、間違った考えだとは思いません。ただし、勘違いしてはならないのは、汎用業務を担う既存の情報システムもまた、本来は 「サービス提供のためのシステム」 であることです。上記でいう 「ビジネスに役立つ情報システム」 との違いは利用者の差、つまり、社外の顧客が使うのか、社内の従業員が使うのか、の差です。

どちらのシステムにしても、それぞれを使う利用者へ何らかの価値提供を行う必要がある。また社内の従業員が仕事をする目的は、直接か間接かの違いはあれど、社外の顧客への価値提供のためであるはず。そう考えたとき、管掌は別々にするとしても、どこか根底でつながっている部分があるはずなのです。

グランドデザインを描いて、そこを見出さない限り、サービス系システムと汎用業務系システムは、まったくの別物として社内に認識され、一貫した思想がなく運用されることになります。それは必ず、ビジネスの全体的なパフォーマンスの非効率につながります。

「IT はビジネスに貢献するべきだ」という議論に合わせて、「ビジネスアナリストが必要だ」ともよく言われます。

この指摘をする人の意見を掘り下げて聞いてみると、およそその人材が満たそうとする領域は  「対象とする個別業務の分析ニーズ」 のように、わたしには聞こえています。

それよりもむしろ重要なのは、その企業が手掛けるビジネスのグランドデザインが描け、そこから個別業務までブレークダウンしていけるビジネスアナリストなのではないかと、わたしは考えています。

組織設計、IT 部門のありかた、必要な人材。一見するとスジの異なる分野に思えて、実際は同じスジが通っている。そんなふうに見るべきではないでしょうか。

「標的型攻撃は防げない」は、セールストークではない

先日、データセンター事業を営む友人から、外部からのサイバーアタックの実態について話を聞く機会がありました。

わたしも情報セキュリティの分野に関しては、ポリシー策定や体制作りのお手伝いをすることがあり、知見や現状に対する認識は持っているつもりですが、それでもなお、その話は衝撃的な内容でした。

あまり詳しくは紹介できないのですが、ひとことで表現するなら、「そこまで洗練されているのか」という印象です。

狙った対象がどんなシステムを所有しているのかを走査してプロファイリングする。不正ログインを試みるにあたって、攻撃相手に気付かれないように十分に時間をあけてログインを試行する。攻撃相手の回線帯域をすべて使い果たすような一斉アクセスを行う。Webサイトに入力フォームを見つけたら、脆弱性をつく攻撃を試みる。攻撃元がランダムに見えるようにアクセスを試みてブロックされることを防ぐ。

こうした行為が「すべて自動で、無差別に行われているように見える」と、友人は語っていました。

ここ最近、情報セキュリティの専門家が、「標的型攻撃においては、狙われたらほとんど防ぎきれるものではない」という趣旨の発言をたびたびしています。実態を聞いて改めて、これはまったく大げさな言い回しではないと、再認識することができたと感じます。

ユーザーの立場ではこうした脅威に対し、予防策としてはきわめて当たり前の対策しか取れません。例えば、パスワードは十分な強度のものを使う、そして定期的に変更する、使用するシステムの脆弱性はアップデートにより最新を保って排除する、余計なシステムは動かさない、ファイアウォールやアンチウイルスなど当たり前のことは必ず適用する、等です。当たり前とはいえ、これらは実際に大きな効果があるので、もれなく実施するべきです。

ただしそのうえで、「カギはきちんとかけたとして、それでも破られたらどうするか」という事後対策もまた、十分考えて整備しておく必要があります。この対策には、攻撃を検知できる手法や攻撃に対応できる技術、また反応できる体制が必要です。そのスキルがないのなら、それを持つパートナーを探しておくことも、取るべきアクションのひとつになります。

特に重要なのは、「体制づくり」です。

前記の話をしてくれた友人は、実際に攻撃を受けた企業でも、まったくその実感がわかず、適切な対応の指示をしないようなCIOが、実際にいたというエピソードも話していました。CIOであるにもかかわらず信じられないことですが、意識が低く知識もないと基本的な反応さえできないという、典型例ではないでしょうか。それはまるで、急病人が目の前に倒れているのに救急車を呼ぶことを思いつかない、というのに似ていると感じます。

 

ビッグデータより、ビックリデータ

ときどき、ホテルやレストランなどで、ちょっと感動するサービスに遭遇することがあります。

例えば、宿泊先のホテルで。チェックインの際に、ホテル内のジムが何時から開いていてどんなサービスがあるのか、フロントの人に少しくわしく質問します。いろいろ教えてもらった後、部屋に入り、食事を済ませてからジムへ行ってみます。すると名前を告げるなり、受付からもインストラクターからも「お待ちしておりました」と言われます。こちらが使ってみようと思っていたサービスを、こちらが伝える前から紹介しはじめました。

例えば、日本料理の店で。来店の際、座敷に上がるため、靴を脱ぎます。居酒屋などでは、げた箱に入れてセルフでカギをかけたりしますが、ここではそういうものは見当たりません。大きなげた箱が玄関に置かれていたので、自分で靴をそこに入れ、店内に入ります。おいしい食事をいただき、満足しながら店を後にしようと出口に向かうと、玄関にはすでに、自分の靴が並べられて土間に置かれていました。

いかがでしょうか。似たような「おもてなし」体験をしたことがあるかたも、多いのではないかと思います。

これらの例を実現した秘密をひも解くなら、前者はフロントとジムで情報共有ができていた結果であり、後者はサービス担当が顧客の持ちものを記憶するように訓練されていたから、ということになります。

こうしたことから、よいサービスになるものの共通項は「自分のことを知っていてくれる、覚えていてくれる」ということだ、と理解できます。これをIT技術で実現しようとしているのが、最近話題の(特にマーケティング分野での)ビッグデータなわけです。

実際にこうしたデータ収集に取り組む人々がどういう思いでいるのかまでは存じませんが、顧客の情報を集めれば顧客を知ることになり覚えることになると、単純にそう思っているのだとしたら、わたしには、大事な気づきがひとつ抜けているように思えます。

それは、「自分のことを知っていてくれる、覚えていてくれる」ということばの前に、「思いがけず」が省略されている、ということです。

何かのサービスを受けて感動するとき、たいていその理由は、「そんなことをしてくれるなんて思いもしなかったから」ではないでしょうか。上記の例でいえば、もし顧客が「ホテルでは情報共有されていて当たり前、フロントに話したのだからジムの担当者は自分が来ることを当然知っている」と思っていたとしたら、どうだったでしょうか。もし顧客が「日本料理店の従業員は、客の持ちものを覚えているのは当然。店を出るときには当然靴が出されている」と思っていたとしたら、どうだったでしょうか。

つまり、サービスが感動を呼ぶには、顧客を「知っている」ことではなく、顧客が「思いがけない」「想像していなかった」ということがより重要と思えるのです。

もうひとつ挙げるなら、「その行為がリアルタイムに起こる」という点も、見逃せません。上記の例でいえば、ホテルのフロントも、日本料理店のサービス担当も、感動につながる行為を「その場で」実行しています。昔から顧客の興味や情報を知っていたわけではなく、その場で情報を入手し、その場で処理して、その場で行動しているのです。

こうして考えてみると、顧客からたくさんの個人情報を吸い上げ、それを分析し、そこから得た知見を活用するというような取り組みだけでは、たとえそれがワントゥワン・マーケティングだったとしても、感動は呼ばないだろうという考えに至ります。なぜなら、顧客はその企業にあらかじめ自分のことを教えているからです。「その情報を使って分析するんでしょ」と、もう思われてしまっているからです。

「いや、レコメンドするのは、お客様が便利になるからです」とおっしゃるのなら、そうかもしれませんね。それなら、「たったそれだけしか教えていないのに、なんでわかったの」と言われるくらい、少ない情報からレコメンドすれば、感動されると思いますよ。

「昭和な会社」と、経営者の「コミット」

先日の日経ビジネス誌で、「昭和な会社」と題して、一見では時代に逆行しているかに見える、ユニークなIT活用をしている企業を取り上げた特集が掲載されていました

例えば、こんな企業が紹介されていました。

  • スマホを使わない社員に奨励金を支給する会社
  • 社員からパソコンを取り上げた会社
  • 朝にパソコンの電源が入らないようにした会社

情報システムにかかわる仕事をしているわたしが申し上げると奇異に聞こえるのかわかりませんが、わたしはこれらの事例を見て、大変よい取り組みをされている企業だと感じました。実はわたし自身も、5年ほど前に、あるサイトへの連載で、このような取り組みをしている企業を取り上げたコラムを書いたことがあります。

大変よいと感じる理由には、いくつかあります。

まずひとつ目に、IT活用を考えるうえでの検討の流れが正しいことです。つまり、「業務のありかた」が先に来て、そのあとにITの使いどころを考えようとしている、ということです。取り組みを紹介されたどの企業においても、変えるきっかけは「業務のありかた」でした。この順番で考えられているなら、いわゆる「ITありき」にはまずなりません。これらの事例のように、「そこはITじゃないね」という結論も、自然に出せるわけです。

ふたつ目に、「なぜその取り組みなのか」ということに対して、ポリシーが明確であることです。なんとなくで目的はあまりない、単にコストを削減したい、などということがありません。あるべき姿を明確にイメージしたうえで行動を起こしている点は、成功に必須な要素を踏まえていると見えます。

最後に、事例に出てきたどの企業においても、そうした取り組みを経営者自身が主導し、その対応についてコミットしていることです。

事例に出ている企業の経営者の姿を見ていると、IT活用において経営者が持つべきマインドセットは何かが、垣間見えると思います。ITに詳しい必要などありません。IT技術者をいいように操れるだけの論陣を張れる必要もありません。必要なのは、顧客に対する価値提供のありかたや、そのためにあるべき業務環境のイメージ、価値を提供するためのしくみの理想像、そういったものなのです。

経営者がコミットする、とはよく言いますが、これらの事例ではまさに、それぞれの経営者が「コミットしている」姿を体現していると感じます。そこに、この事例から読み取るべき本質があるのではないかと思います。

 

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

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

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

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

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

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

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

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

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