企業が新しい IT を乗りこなすための 3 つの視点

ご承知の通り、IT の世界は進化が早く、次から次へと新しい技術や新しい概念が登場してきます。

最近では、コンシューマー系の技術やサービスが大きな影響を与える傾向がありますね。スマホ、タブレット、ソーシャルメディア、BYOD、無料通話アプリ、等々。

こうした進化に対して、企業とそのリーダーはどのように向き合えばよいでしょうか。私見を 3 つのポイントにして、以下にまとめてみます。

まずやりたいことは、「そのトレンドが、IT 業者のマーケティングの域を出ているか否かの判別」です。

どんな新技術・新サービスも、最初は多かれ少なかれ、IT 業者のマーケティングによって世間に出てきます。これは、別に非難されるものではなく、ビジネスとして当然のことです。

問題は、それが業者の売り込みを越えて、世の中に浸透し、確実に根付きつつあると見るかどうかという、ユーザー側の目利きだと思います。

その判断には、積極的かつ多面的な情報収集が欠かせません。中立的な専門家の見極め、ポジティブな人の意見、ネガティブな人の意見、偏りなく集めて考察すべきでしょう。そのうえで、「マーケティングの域を出た本物のトレンドだ、またはそうなりそうだ」と感じたら、次のステップに進みます。

次に考えることは、「自社に役立つか、役立たないか」です。

その新しい技術やサービスが、自社のビジネスを加速する可能性を持つものなら、積極的に取り入れればよいですし、その可能性を感じないものなら静観すればよい。こんな判断になるでしょう。

そんなこと当たり前じゃないか、と思われるかもしれません。しかし、実践できているかというと、多くの企業で意外とそうでもありません。

どういうことかというと、「役立つか、役立たないか」と考えずに、「それをどう使うか」と考えてしまっている向きも結構あるのです。

前者で考える人には、常に最初に大局的な「目的」や「ゴール」があります。目的やゴールに照らして「役立つか、役立たないか」と考えるわけです。一方、後者で考える人にある目的やゴールは、「その新しい技術やサービスをうまく使うこと」になっているのです。つまり、いわゆる「IT ありき」の発想です。

トレンドなのだから自分も使わなければならない、とは必ずしもなりません。きっと後者の発想の人は「乗り遅れたくない」と思っているのでしょうが、乗り遅れることによる差別化のリスクの大小と、導入したために出てくる労力やコストの大小については、一度考察してみる価値があるでしょう。

安易に流れに乗っかって、成熟していないものにムダな投資と労力を費やし、振り回された上に最後に成果は得られないリスクは高いということも、よく念頭に置くべきです。

たびたびこのコラムでも指摘していますが、IT ありきの発想は大きな間違いにつながります。ぜひ、改めて意識しておきたいものです。

そういえば先日、ガートナーの小西氏によるコラムを拝読しましたが、同氏は顧客からしばしば、「テクノロジーが進化するのに応じて IT 戦略を変化させたいので、中期的なテクノロジ・トレンドを教えてほしい」と聞かれるのだそうです。

ガートナーと言えば大企業の CIO へのコンサルティングで知られていますが、大企業の CIO でもまだそんなふうに考える人がいるのかと、ちょっと驚きました。

さて、本論に戻します。次が、3 つ目に考えることです。

ひとしきり考えた結果、その新しい技術やサービスが「役立つ」と判断したなら、本気で適用の仕方を考えていきます。しかしながら、新しいだけに、すぐに使えるとはなかなかならないことが多くあります。

そんな時に大事になるであろうことが、「時期尚早なものはそのように判断して熟成させる」姿勢です。

本物のトレンドである場合、その技術やサービスは、一度下火になったように見えても必ず進化を続けていきます。現時点で「なんだかしっくりこないな」と感じる部分は、のちにすっきり解消される可能性が、かなり高いです。

ですから、ピンとこないなら躊躇なく「時期尚早」と判断する。ただし、そう判断して捨ててしまうのではなく、ウォッチは続けて「熟成」させる。そのうち進化が問題を解決し、リーズナブルなコストになるのを待って、晴れて採用する。こんなスタンスなら、うまく行くのではないでしょうか。

もちろん、その分野で自社が技術を先導し、他社にノウハウで先んじようと志すのなら、時期尚早なことを承知で採用し、試行錯誤してノウハウを獲得する。その技術が使いやすいものになった暁には、自社が他社に差をつけている。そんなシナリオを目指すこともあり得ます。そのあたりは、やはり「目的」や「ゴール」の持ちかたに帰結するでしょう。

いま起こっているトレンドにも、こんな視点で対応してみてはいかがでしょうか。

「なりすまし事件」が、自分の会社で起こったら

先月、マルウェアやフィッシングを悪用した遠隔操作によって脅迫文などがなりすましで送りつけられ、複数の無関係の人が誤認逮捕される事件がありました。

その後の分析や犯行声明などから、マルウェアやフィッシングのリンクは犯人が自作したもので、誤認逮捕された人が自分の PC にダウンロードしたり、悪意のあるリンクをクリックするなどしたことにより、犯人による操作が可能になったことがわかっています。

今回の事件は不特定の個人を狙ったもののようでしたが、この手口は企業に対して行われる可能性も十分にあるケースで、大きな脅威です。企業の方々は、決して他人事と思ってはならないと思います。

どの辺が「大きな脅威」だというのでしょうか。簡単におさらいしておきましょう。

まず、自作のマルウェアというのは、ウイルス対策ソフトなどで検知するのがかなり困難です。特に今回のもののように、既存のソフトウェアの脆弱性を突いたものでない場合は、網にかけるきっかけがないために検知の難易度が格段に上がります。

また企業が狙われた場合、今回の事件のような自己顕示目的よりも、情報の盗用や金銭目的であることが多く、被害側がいつまでも気づかずに発覚しない恐れもあります。

仮に発見できたとしても、犯人を特定することはまた困難であるのが、残念ながら現状です。

今回の事件でもそうですし、話題になっている中国のハッカーやアノニマスが不正アクセスや改ざん行為を繰り返しているにもかかわらずなかなか逮捕されないのも、その証左です。なぜ難しいかといえば、犯人は自分の端末から直接ターゲットを狙うことはしないために足がつきにくいことや、犯人がアクセスの痕跡を巧みに消すことなどが原因です。

このような状況の中で、企業にとって重要になるプロアクティブな対策がいくつかあると思います。

まず、「出口を監視する」対策です。つまり、企業の内部から出ていくトラフィックを監視して、普段使っている状況ではあり得ない異常を見つけるのです。

こうした対策を行うツールやソリューションがすでに販売されてはいます。ただし重要なのは、それらを導入することよりも、「ユーザー企業が常に監視を続ける」ということです。

異常というものは、正常な状態とはどういうものかがわかっていて初めて、理解できます。普段監視をしていない企業には、正常がどういうものかわかりません。だからそういう企業に、異常は発見できないのです。

監視など素人には難しいのではないかと思うかもしれませんが、普段と違うかどうか判定することは、どちらかというと経験の問題です。スキルはそれなりに必要ではありますが、この場合はすこし勉強すればすぐ克服できる程度のレベルだと思います。

もうひとつ重要な対策は、「証拠の保全ができるようにしておく」ことです。

ただでさえ犯人は痕跡を消そうとしますから、証拠になるものはあまり残されていないのが常です。さらに不都合なことに、実は、証拠になるような情報はすぐに消えてしまいやすい傾向にあるのです。例えば、再起動したり、電源のオフをしてしまったり、ウイルスのスキャンを実行したりすると、消えてしまうような証拠情報もあるのです。

その意味で証拠保全は、あらかじめ一定の手順なり方法なりを確立しておかないと、有事にミスを犯して消してしまう可能性が高くなります。

こうした取り組み、どれも以前から言われていることで、すぐに思いつくような話なのですが、きちんと実践できている企業は本当に少ないです。

これはまさに、マネジメントの話だと感じずにはいられません。

運用作業全般に言えることなのですが、こうした取り組みには目に見える成果が普段から現れるわけではなく、何も起こらなければ目立たない特徴があります。その分、マネジメントサイドが気に留めない、評価しない傾向があるのが問題ではないでしょうか。

こうした取り組みの重要性に気づいている担当者が社内にいたとしても、マネジメントが気にしないために「正式な、やるべき仕事」として取り扱われない環境が生まれている場合もあります。わたし個人も経験がありますが、担当レベルで一生懸命頑張っていてもマネジメントレベルが聞き流すような「仕事」は、結果として良い取り組みになりません。

情報セキュリティ対策について、わたしは常々「トップマネジメントの見識の高さが出る」と考えています。こうした社会的事件を他山の石と捉えて、意識を新たにするきっかけにしていただきたいと、こんな話が発生するたびに願う次第です。

user-driven な企業は「マネジメント・イニシアティブ」

IT 活用に関連して、企業の講演を聴講する機会が多くあります。

先日、わたしが参加している研究会にて、ある企業の CIO によるケース発表が終わった後、同会の会長が「すごい企業は、マネジメント・イニシアティブですね」ということをコメントされました。

これは、登壇した CIO の方が所属する企業がなぜそこまですごいのかを紐解く中で、同社の社長のこだわり様が半端ではないということが分かったことを受けてのコメントだったのですが、ほんとうに仰るとおりだと思いました。

というのも、わたし自身、これまでいろいろな「強い IT ユーザー企業」の事例を聴き、必ずと言っていいほど、その企業のトップが IT に対して並々ならぬイニシアティブをとっていることを、まさに実感していたからです。

最近聴いた中で言えば、例えばある小売業の企業。

講演ではこの企業の社長が自ら、自社のデータ活用について語ったのですが、その内容に驚きました。いわく、過去の購買履歴だけ見ていても売れ筋など分からない。「売れているそれぞれの品目にはヘビーユーザーが例外なくついていて、彼らが来店するかどうかで売れ行きは激変する」。その来店がいつになるのかは「過去の履歴からは読めるはずもない」。顧客は「欲しいものを、欲しいタイミングで、欲しい価格で買いたい」。だから、折込チラシには「効果がない」し、「特売は粗利には直結しない」。

こうしたことを、社長自身が語るのです。まるでデータ分析の専門家であるかのような洞察でした。そしてこの企業は、こうした分析を社内で自由に実践できる情報基盤を、社内に整備しています。

他にも、例えばある金融系のネット企業。

この企業は、起業以来スクラッチでシステムを作り上げてきました。しかも内製で。なぜ内製かというと、内製だと固定費になるからだと言います。損益分岐を超えれば、あとは利益になる。特に金融系は、スケールメリットを出して収益を上げる業界。情報システムもそうしたほうがよい。

この企業、現時点のシステムの運用状況や構成情報などを、すべて「数字」で公開しています。それだけでなく、顧客のクレームや満足度など、あらゆる管理事項を「数字」にしています。それらをベースに、客観的に施策の判断をしているのだそうです。この「数字」を社外にも公開すれば、社員の意識はおのずと上がり、「数字」が改善されれば顧客の信頼につながると言います。

こうしたことを、社長自身が語るのです。この企業、社長自身もアイデアパーソンとなって、どんどんシステムを改善して新しいサービスを創出し続けています。それができるシステム基盤を、天塩をかけて育ててきているのです。

ほかにもたくさん例はあります。ただ、これが日本企業で一般的かというと、現状では残念ながらそうではありません。

わたしがこうした事例に触れる中で感じるのは、システムが生み出す成果のシナリオと結果にトップ自身がこだわるだけで、こんなにもアウトプットがすごくなる、ということです。

一方、IT リーダーや IT 担当者のモチベーションは高いけれど、経営層があまりシステムにこだわっていない企業があります。こうした企業の中にも時々、興味深い成功事例を創出するケースがあります。

しかし、アウトプットの鮮烈さを考えた時、わたしが感じる限りではやはり、前者と後者では前者のアウトプットがよりビジネスに直結しているし、ダイレクトに顧客の役に立っているのです。なにより、その会社の顧客が得している様子が見えるようで、聴いていて爽快な気さえするのです。

何とか、そんな「マネジメント・イニシアティブ」な会社をもっと増やしたい。思いを新たにする今日この頃です。

 

ユーザー企業に「ジョブズ」は要らない

ビジネスにおいて IT や情報システムの力を借りるのが当然となった昨今、企業に求められている IT プロフェッショナルの像は、もはや「情報システムを管理する人」ではないことは明白です。

依然、情報システムを管理する以上の役割を担えていない情報システム部門も、残念ながら存在しています。しかしおそらくその場合、その部門は、経営者をはじめ企業内からあまり高い評価を受けていないのではないでしょうか。

今要求されている IT プロフェッショナルの姿、それは端的にいえば「ビジネスの仕組みをデザインする人」ではないかと思います。もう少し言えば、ビジネスの価値創造をデザインする人、ということです。

一方、こうした人材(一般的には「企画人材」と表現されています)は、あらゆる企業で不足している、と評されているのが実態です。さまざまな調査で、それが示されています。そしてこの不足傾向は、何年も変わっていません。

こうした傾向を見て、企業の経営者は、「そうした素材の人物は世の中にほとんどいない」と考えてはいけないと思います。

「企画人材」と聞いて、なにか iPhone のようなイノベーティブなアイデアを生み出す人材をイメージして、それは稀有な存在だと思ってしまっていないでしょうか。稀有な存在だから、いないのは当然だと。企画人材不在の傾向が何年も続いているのは、そうした意識が背景にないかと心配してしまいます。

ユーザー企業で求められている企画人材とは、わたしが考えるに、ゼロから奇抜な発想をする人材ではありません。誤解を恐れずに言えば、「組み合わせるのがうまい人材」です。

ユーザー企業自身が先端的な技術を単独で生み出すのは、かなりの無理難題です。それは、ベンダーや専門企業に任せればいい話です。実際、IT ソリューションは世の中に無数に存在していますし、生まれています。

ただし、ユーザー企業はそれを単に採用するだけでは差別化は図れません。差別化を図りたい領域に市販パッケージなど当てはめても、他社が同じパッケージを導入すれば差別化にならないのは当然です。

しかし、組み合わせとなると、個性が出ます。そもそも選ぶ側がソリューションを知らなければ、組み合わせることはできません。知っていたとしても、組み合わせかたによるシナジーがわからなければ、採用もできません。

これが「組み合わせの妙」であり、企画能力すなわちデザインセンスなのです。そしてこうしたセンスは、鍛えることができます。

経営者や CIO がやるべきことは、先ほどのような、企画人材がどの企業でも不足しているという調査結果を見て、「これはチャンス」と捉え、社内に「技術を試す環境」を整備することです。

実はほとんどの技術者は、試行錯誤を通してベストプラクティスを見出すプロセスが大好きです。試す環境が整備されれば、嬉々として取り組むはずです。その中で、ビジネスに価値をもたらすソリューションの創出を「結果」として求めてください。その過程で、「ビジネスの仕組みをデザインする人」が育ちます。

その人たちこそが、世の中で不足している「企画人材」なのです。

IT のトレンドはものすごい速度で移り変わります。5 年したら、iPhone や iPad も時代遅れになっているかもしれません。また、移り変わるだけでなく、選択肢が激増していきます。

こうした環境において、企業内での「ビジネス・デザイナー」の役割はどんどん大きくなっていくだろうと、わたしは見ています。

人材の育成には時間がかかることは、言わずもがなです。早く取り組み始めた会社が、とてつもないアドバンテージを獲得するでしょう。

BYOD、やるならこう考える(2012年8月)

BYOD とは、Bring Your Own Device の略です。ご存知の方も多いことでしょう。

企業では最近、ケータイをはじめとしてモバイル端末の業務利用がかなり浸透しています。そうした企業の社員は多くの場合、企業が貸与した法人端末と、自らが所有する私有端末の 2 台を常時持ち歩いています。そうした「2 台持ち」は結構煩わしい、ということで、企業が私有端末を業務用途に使うことを容認する、という動きが BYOD です。iPhone や iPad がリリースされて以来、随分盛んに言われるようになった気がします。

モバイル端末を業務に使えば、一般的に、業務に関する情報が端末に格納されます。これまでは法人端末でさえ企業側でコントロールがしにくく、ましてや私有端末を業務利用するなど現実的ではありませんでした。ところがスマートフォンの登場でアプリの機能レベルが向上し、遠隔操作で端末のデータを消去できるなど、かなりきめ細かな端末のコントロールが可能になっています。こうしたことも、BYOD が現実味をもって言われ出した背景にあります。

ただし、そもそも BYOD を盛んに取り上げているのはマスコミです。「先進企業はもう始めている」とか「現場は求めている」とか「無視できない」とか「アメリカはもうやっている」とか、いろいろ囃し立てていますが、現実は賛否両論です。アメリカでもそうです。あまり惑わされないほうがよいでしょう。

要は、「自社で必要なのか」「それで生産性が上がるのかどうか」です。逆に管理が増えて工数が上がるのなら、やらなければよい話です。

しかし一方で、必要に迫られる企業があることも事実です。例えば中堅や中小企業で、モバイル端末が業務上必須だが資金的に会社では端末を配布できない、といったケースが実際にあります。

さまざまな事情がある中で、企業は BYOD にどのように向き合えばよいでしょうか。少し考察してみます。

モバイル端末の最大の懸念は、データのセキュリティです。無策で放置すれば、簡単に情報漏えいにつながります。

これに対するスマホやタブレット向けのソリューションとして、MDM (モバイル・デバイス・マネジメント)と呼ばれるツールが充実してきています。SaaS で使えるサービスもあり、選択の余地があります。

しかし BYOD となると、MDM をそのまま適用しにくい事情があります。なぜなら、私有端末に対して企業が完全なコントロールを行うのは、現実的ではないからです。

もし端末を社員が紛失したとき、リモートワイプ機能を使ってデータ消去を遠隔で行えば、業務データのみならず社員個人のデータも消去されます。また MDM では、位置情報から社員の行動履歴も取ることができますが、BYOD では個人的な行動まで記録されることになります。さらに、社員はたびたび端末を乗り換えます。それらをすべて申告させて、管理しなければなりません。社員が申告を忘れて業務に使用した場合、未然に取り締まれるでしょうか。

こうした事情を想定すると、やはり現時点での BYOD は時期尚早と感じざるを得ません。

では、いつ現実味を帯びるか。それは、モバイル端末にクライアント仮想化を実装できるようになった時点、と思われます。

クライアント仮想化ができれば、モバイル端末上で法人用のゲストOSを起動させることで、個人利用と完全に峻別することができます。データはゲストOS上での利用に限定ができますし、ゲストOSがなければ業務利用できないようにすることも可能です。

また、モバイル・シンクライアントも可能性があります。シンクライアントが使えるなら、そもそもデータは端末に一切格納させない使いかたは容易です。

ここまでできると、上記のような諸問題はかなり解決が可能です。

スマートフォンに仮想化ミドルウェアを実装する技術は、試作品レベルではすでに出てきています。初期の実用性はともかくとして、それほど時間がかからずに市場に出てくるのではないでしょうか。

ですから、ひとまず BYOD は、シンクライアントや仮想化ソリューションが現状でも使えるラップトップ PC のレベルに留め、スマホのクライアント仮想化ソリューションが市場に浸透してきたときに本格導入を考える、というのが無難だろうと思います。

こうして見ていくとわかるのは、BYOD の現状の諸問題はおよそ技術的なものだということです。そのうち解消されていく方向でしょう。

では少し話を進めて、BYOD を実現する前提となったら何を考えればよいでしょうか。

やはり、BYOD での利用範囲を限定する必要があると思います。いくらデータセキュリティが担保されるとしても、何でもかんでもスマホでできますというのではハイリスクです。

実際、マスコミがさかんに先進事例として取り上げている企業の取り組みを見ていると、利用範囲はメールだけ、インターネット接続だけ、などと限定されています。米国での事例も、例外ではありません。

そもそも、スマホやタブレットでどうしてもやるべき業務というのは、それほど多くないはずです。そのほとんどは閲覧ベースの業務であるはずで、ファイル作成や計算処理の実施などはラップトップのほうが便利なはずです。また、単純な業務に利用を限定すれば、それだけ接続環境もシンプルになり、追加投資が異常にかさむこともありません。

また、もし何でも社外で業務ができるとなれば、それは在宅勤務が可能ということと等価です。在宅勤務がその企業にとって必要かどうかは、BYOD とは別の議論が必要でしょう。

BYOD に向き合う際の視点を、いくつか挙げてみました。やはり肝は、ビジネスの仕組みに対する自社のスタンスです。モバイルをどう使いこなしてビジネスの仕組みを補完するのか、うまいシナリオを練って使いこなしてください。

「ビッグデータ」で見かける、あぶないカン違い(2012年7月)

ときどき、企業の業務改善に関する事例やストーリーを目にする方も多いことでしょう。参考になる話がたくさん盛り込まれており、わたしもよく勉強させてもらっています。

そうした業務改善に取り組むに当たって必須になるのが、業務分析と呼ばれる作業です。ところで、この業務分析には、置かれた状況に応じて 2 つのアプローチのしかたがあることをご存知でしょうか。

ひとつは、あるべき(ありたい)姿やあるべき(ありたい)シナリオがわかっている状態で使うアプローチ、もうひとつは、それがわからない状態で使うアプローチです。

言われてみれば当たり前に聞こえるかもしれません。しかし、この違いをはっきり意識して使い分けないと、間違った取組みに邁進することが実際によくあります。

先日、こんな話を耳にしました。

ある企業に、モノには自信があるのになかなか売れない商品がありました。なんとか売れるようにしたいということで、その企業は、売れない商品を売るための対策を立てることにしました。

具体的には、現状の営業の業務プロセスを見える化し、「~数」とか「~率」などの数値を割り出しながら、科学的に業務分析をしたのだそうです。その結果から、成果を上げるプロセスを設計したとのことでした。

その話では、設計したプロセスを実践してみた結果が語られなかったのですが、わたしはこれを聞いて「いまいちうまく行かなかっただろうな」と直感しました。

なぜなら、アプローチが間違っているからです。

先ほど、2 つのアプローチがあると述べました。これらをどう使い分けるかというと、端的にいえば「あるべき姿が理解・共有できているかどうか」でアプローチを変えます。

つまり、理想のフォームが明確なのであれば、科学的な手法で業務を分析し、理想との違いを浮き彫りにして成果を出しやすい個所を特定し、理想に近づける方策を実践します。

一方、理想のフォームが明確でないのなら、リファレンスがないので採るべき方針が明確にできません。その場合は、仮説検証型のアプローチを採ります。仮説検証型のアプローチでもし科学的な分析をするのなら、仮説を実践した後の検証のパートにおいてです。

先ほどのケースに戻りましょう。売れない商品を売る、という場合、みなさんには「売れる営業プロセスのあるべき姿」がわかるでしょうか。わかるのなら、そもそも売るのにあまり苦労しないのではないでしょうか。このケースの場合、採るべきは仮説検証型のアプローチです。

ところがこのケースでは、仮説を立てずにいきなり「科学的な分析」を始めています。それでも何らかの「成果を上げるプロセス」は導出され、分かった気になるのですが、いわゆる机上の空論になりやすく、やってみても思ったとおりには行かないことがほとんどなのです。

これが、わたしが「うまく行かなかっただろうな」と直感した理由です。

ここでぜひ強調したいのは、「知りたいことが何かがわかっていないのなら、分析しても意味をなさない」ということです。これは、巷で話題の「ビッグデータ」に関しても言えます。

ときどき経営者のインタビューなどで、「欲しい情報をすぐに見たい」を発言されているのを見つけることがあります。このとき、「欲しい情報」とは何か、それによって何を見出しどういう判断を下せるのか、そうしたシナリオまで語れるのなら、このセリフには説得力が出ます。しかしそうでないなら、それは「ビッグデータ失敗予備軍」の傾向です。

よく「データは語る」などのかたちで、さも万能であるかのように、マスコミも「ビッグデータ」を少々煽るようなストーリーを展開することがあるように感じています。データは語るかもしれませんが、実際は使う側から働きかけなければ何も語りませんし、使う側がデータを見抜こうとしなければ、何も見えません。ベンダーが提供する技術によってデータを出力すれば勝手に語りかけてくれると思ったら、確実に間違えます。

それは、今も昔も変わらないことのはずです。「ビッグデータ」によって新しくなったのは、技術の進化によってかつて不可能だったような大量のデータが簡単に処理できるようになった、ということ。誤解を恐れずに言ってしまえば、そのことだけなのです。

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には疎かったとしても、新聞は毎日ご覧になるでしょう。その中でシステム障害に関する記事を見かけたら、上記のような見方をしてみてください。

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

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

「IT がわかる経営者」の意味を考える(2012年5月)

先月、日経ビジネスで、情報システムと経営に関する特集記事が掲載されました。それに呼応する形で、同誌のウェブサイト版である NBonline でも、経営者と情報システムに関わる提言が掲載されています。

経営者やビジネスリーダーが愛読する、日本で No.1 の読者数を誇るビジネス誌が、情報システムについて特集するというのは大変意義のあることだと感じます。システムをビジネスに活かす支援を生業とするわたしとしては、この特集記事は喜ばしい出来事でした。

ただ、わたし個人は、特集やウェブサイトの提言の根底にあると思われる、『経営者は IT をもっと理解すべきだ、関与すべきだ』という意見には、もろ手を挙げて賛成はしません。

なぜか。

まず第一に、「わたしは IT を理解しようとしていません、関わろうとしていません」と正面切って宣言するような経営者は、世の中にほとんどいないと思うからです。そういう経営者があまり世の中にいないところで、「もっと関われ」と訴えても、「わたしはそこそこ関わってるよ」と受け流されるだけだと思います。

第二に、「IT をもっと理解、関与」するだけでは、経営者またはリーダーの役割は果たせないと思うからです。

わたしが考えるに、こと IT に関する経営者やリーダーの役割は「IT をいかに使いこなすかをデザインする」ことです。自らが展開するビジネスに、IT をどう役立てられるのか、どういうビジネスの仕組みの中で IT が使えればもっとビジネスを発展させられるのか、他社と差別化できるのか。そういうことを(他人に支援してもらってでも)考えるのが、役割だと考えます。

情報システムを設計することの困難さ、開発することのむずかしさ、安定的に運用することの重要さを理解することは、もちろん大事です。しかし、それを「理解するだけ」では、彼らは役割を果たせないのです。それらの重要性を知ったうえで、経営に資する情報システムをどのように整備するのかポリシーを打ち立てることが、立場として求められるのです。

ですから、多少極論気味に例えるなら、経営者が自社のビジネスにとって情報システム運用はあまり価値をもたらさない、むしろベンダーに任せた方が安定してよい、と考えるのなら、経営者は運用をアウトソースすればよいのです。

アウトソースして、サービスレベル面で結果を出していることだけに関心を払い、運用業務そのものの大変さにはあまり関心を払わなくてよいのです。そのアウトソースに筋の通る考えがあるかどうか、それを経営者自身が語れるかどうかが問題です。

つい先日もこんなニュースがありました。食品メーカーの味の素が、情報システム子会社の株式を、野村総合研究所に譲渡したというものです。

記事によれば、同社の伊藤社長は次のように述べたそうです。「国内もそうだし、グローバルに新しい IT 技術を取り込んで仕事をしていくなかでは自社だけでは限界があった」「我々の事業、つまり機能分野として(システム子会社の株式を)100%は持つ必要はない」

100%子会社でなくなれば、事業拡大などによる収益の確保が要求され、必ずしも親会社の開発ばかりに目は行かなくなります。収益確保がうまく行かなくなれば、ゆくゆく野村総研に吸収、結果的にベンダーロックインというシナリオもあり得ます。そうでなくても、「外の会社」になるわけですから、システム開発のスピード感も当然落ちます。そうしたリスクやシナリオも踏まえて「いらない」と判断するのが、役割なのです。

職業柄、経営者やビジネスリーダーの方々と、情報システムに関してお話をうかがったり議論をしたりする機会に恵まれてきました。わたしがそれを通して感じるのは、多くの経営者やビジネスリーダーは情報システムに関与したくないとは決して思っていないということです。むしろ、なんとか自分のコントロールを強めたいと思っています。

しかし、思うままにはならない。その根本にある要因は、経営者やリーダーの「IT に対する自信のなさ」だと、わたしは感じています。知識がなく、経験がないから、担当者の気持ちがわからないし、セオリーがわからない。自信がないから、結果としてあきらめ、話を理解したつもりが鵜呑みにし、任せたつもりが放任し、行動を起こさない人が多いのだと考えています。

何とかできるのなら何とかしたい、と考えている経営者もいるのですから、そういう方に入れ知恵して自信をつけてもらえるような情報発信を、力のある専門誌やサイトが展開したらどうでしょうか。わたしなどは微力なものですが、細々と「入れ知恵する取組み」を始めようとしています。

「IT がわかる経営者」が理想像であることに、だれも異論はないと思います。ただし、このフレーズの「わかる」ということばは、「知識がある、経験がある」という意味ではないはずです。経営者が「わかってる」ってどういうことなのか。それは、「ポリシーをもって行動している」ということではないでしょうか。

わたしは少なくともそうした「行動できるインプット」ができるように、心がけたいと考えています。

「ソーシャルをやらない」、大いに結構!(2012年4月)

今月は、「企業がソーシャルメディアとどう付き合うか」について、考えを少し書いてみたいと思います。

ここでは、わたしがこれまで観察したり、自ら使ってみたりした結果として、考えたことや気づいたことを書き留めておきたいと考えています。世間に逆行するようなタイトルではありますが、案外すでにいろいろなところで言われていることと重なる指摘もあるかもしれません。それも含めて、ご参考になれば幸いです。

さて、Facebook や Twitter、mixi など、ソーシャルメディアと呼ばれるネットサービスは、すでに多くの人が触れるものになりました。

ニールセン・ネットレイティングスによる、2011 年 10 月のインターネット視聴率の調査結果によれば、国内利用者数は Facebook:約 1100 万人、Twitter:約 1400 万人、mixi:約 800 万人、などとなっています。ただしこの数字は、携帯利用者は含んでいないということですから、実態はもっと多いと思われます。

このような状況を目の当たりにして、多くの企業が Facebook ページや Twitter アカウントを開設するようになっていますが、その対応に迷う企業もあるようです。

そのような迷える企業に対して、いくつかの方面からはネガティブな論調も聞かれます。「いまどきやらないなんて、考えが古い」「やらないことで、やっている企業と差がつく」「ある企業は、それでかなり集客している」「やらない方がリスク」等々。

だからといって、ソーシャルに取り組もうと社内調整を始めると、「それでどんな効果があるのか」「炎上したらどうするのか」などと言う人が現れ、苦労するという構図も見え隠れします。

さまざまな意見がある中、企業はソーシャルメディアをどう捉えれば、うまく立ち回れるようになるでしょうか。

わたしは、ソーシャルメディアにより「顧客とのコミュニケーション手段が増えた」と考えて対応するのがよいのではないか、と感じています。

例えば、小売業の方でもそうでない方でも、お店に行くとよく「顧客の声カード」という類のメモ用紙が置いてあって、そこに意見を書き込むと店の人に読んでもらえるようになっているのをご存じでしょう。また、たいていの企業には「コールセンター」や「コンタクトセンター」と呼ばれる窓口が開かれており、そこに電話をかけると企業に話を聞いてもらえるようになっています。

お店の中では人が集まることでコミュニケーションが発生します。電話は人と人と結んでコミュニケーションを行う手段です。ソーシャルメディアもまた、サイト上に人が集まってコミュニケーションが行われます。状況こそ違いますが、人が集まる「場所」であることに変わりはありません。

ですから、店舗やコールセンターと同類項で、ソーシャルメディアを捉えればよいのではないでしょうか。「そこにお客さまが大勢いるのだから、企業としてコンタクトを取れるようにしよう」ということです。

その意味では、前記したような「やらないなんて…」という論調は、必ずしも的を射ているとは思いません。これは、自社の顧客とこれまでと違った手段で意思疎通を図りたいかどうかという企業の意思の問題であり、それを顧客が喜ぶかどうかという問題です。

そう捉えれば、ソーシャルメディアに取り組むに当たって企業が考慮すべきことは、その企業が「顧客とどうコミュニケーションを取りたいのか」になります。

この問いへの答えが、ソーシャル対応の仕組みづくりの土台です。

例えば、顧客とやり取りしながら商品のアイデアを発掘したい、という目的が考えられます。顧客の困りごとにすぐに応えたい、というものもあるでしょう。一方で、悪評が表面化する前にすぐ対応して消したい、という動機もあり得ます。あまり深く考えず、ただ楽しいことを伝えたいというのも、立派な目的です。

その企業が顧客と相対するスタイルに応じて、それがソーシャルメディアを使うことで具現化されるなら大いに活用すればよいし、あまり合わないのなら活用しなければよい。それだけのことだと、わたしは考えています。

ところで、ソーシャルメディアを集客の仕組みの一部とするという向きも中にはあるようですが、わたしは必ずしも集客を中心に考えるべきではないと思います。

確かに、ソーシャルの取り組みが集客にうまくつながっている企業の例は多くあります。ただし、それらの企業を見ていると、自社のサービスなり製品なりを、あまり前面に出していないケースが多いようです。どちらかといえば、「喜んでもらえること」を教えたりやってあげたりすることでファンを増やし、それが結果として集客に結び付いている構図に見えるのです。

企業でコールセンターを設置するに当たって、「それはどれだけ集客に貢献するのか」と問う人は、おそらくいないのではないでしょうか。それと同類項で考えればよいのです。

ただし、対応すれば何らかの形でコストはかかりますから、効果のモニターは不必要というわけではありません。各ソーシャルメディアの特性をよく見極めて選択し、目指す効果を創出する必要があるでしょう。

その際、なにも無理してすべてのメディアに対応する必要はありません。

例えば Facebook は友人間の交流が主で炎上はしにくいが少々本音は隠しがちなコミュニケーション・スタイル、Twitter はユーザーがわりと本音を出しやすく人となりが出やすい、mixi は趣味趣向を一致させた若者や学生同士の交流の傾向が強く滞在時間も長い、という特性があるように思われます。

また、プラットフォームのスタイルにも特性があります。Facebook ページはホームページに近く、Twitter よりも一対一のコミュニケーションがしづらい面があります。一方で Twitter は、顧客と対話はしやすいものの、顧客ごとに個別対応が必要な面も併せ持ちます。こうした特性も、企業のコミュニケーションのしかたに影響を与えます。

こうした、各メディアの機能的な特性やユーザーの行動特性を見極めて、自社が採りたいコミュニケーション・スタイルに合ったメディアを選択すればよいと思います。

例えばもし、一番スタイルに合っているのがメルマガなのであれば、わたしはそれでよいと思います。メルマガは、読者に継続的にじっくり読んでもらうには適したツールです。決して時代遅れであるとは思いません。

もちろん、一度始めたなら継続することが重要です。少人数でもしっかりした実行体制が要求されます。特にソーシャルメディアを利用する場合、メディアは自己都合でプラットフォームの仕様を変更することがあり、その対応があることに注意が必要です。

つい先日ですが、3 月 30 日から Facebook は「タイムライン」という新機能を実装しました。これにより、Facebook ページには企業と顧客とのやり取りが時系列に表示されるようになるのですが、一方で顧客とのやり取りがあまり頻繁ではないと時系列が更新されず、活動が少ないページの印象になりかねません。

これまでホームページのようなデザインを前提にして Facebook ページを設計をしていた企業にとっては、ページデザインもコミュニケーションのあり方も、変更を迫られることになるわけです。このような追加・修正・変更・削除は、Facebook に限らず他のメディアでも起こるはずです。

ソーシャルメディアを利用する企業は、こうした変更に即時に追従し、対応していかなければなりません。そして、それを息の長いかたちで取り組むことになります。その程度の覚悟はもって、仕組みをつくるべきでしょう。

ここまで述べたように、顧客とのコミュニケーションの取り方を改めて見据え、それに合うメディアがあるなら積極的に活用して顧客とのやり取りを深める、という考えの下、仕組みをデザインしてみてはいかがでしょうか。肩ひじ張らない、気持ちの良い関わり方をぜひ目指してください。

クラウドは、ユーザー企業をラクにはしない(2012年3月)

今回は、クラウドが企業社会に浸透することで、ユーザー企業が得るのはメリットだけではないかもしれない、ということについて触れたいと思います。

クラウドはいまや、ビジネスにおいてはフツウに使用される言葉になりました。「流行るかどうか」という論点はすでに過ぎて、「どう使うのか」という議論になっています。

企業が情報システムを活用するうえで、クラウドは多くのメリットをもたらすものです。もちろん、丸投げ感覚で利用すれば、ベンダー・ロックインならぬ「クラウド・ロックイン」になりかねませんが、正しく選択すればユーザーには十分なゲインが見込めます。

ただしこの流れは、ユーザー企業に今後新たな課題をもたらすだろうと、わたしは感じています。それは例えば、以下のようなことです。

ベンダー各社は、挙ってクラウド化の動きを加速しています。これに伴って業界も、ここ数年は合従連衡を含めて激しく動きましたし、幅広くマーケティングすることが要求される中でブランド力が低い中小系のソフト開発企業などは危機にさらされています。

もちろんこれは、流行に乗り遅れまいという動きの結果ではあります。ただし内実は、ベンダーにしてみればクラウドで儲かるならその方がよいはずなのです。

これまでベンダーの仕事は、受託開発を中心に顧客の要望に沿ってオーダーメイドでシステム開発、または適切なパッケージソフトを選定し、インテグレーションすることが主流でした。しかしながら、これには何かと失敗のリスクが伴うことは、ご承知のとおりです。ベンダーの開発能力に問題があるケースもありますが、一方で、顧客にシステム開発に対する主体性がないという要因も大きいのが実情です。ベンダーには、常に後者に対する不満や不安が、暗に存在するのです。

それが、クラウドになると解消されます。クラウドなら、ベンダーの自己都合で決めた仕様でシステムを開発し運営ができます。ユーザーは、ベンダーが決めたサービスメニューの中からオプションを選ぶだけです。サービス範囲を超えたユーザー個別の要望には、ベンダーは原則応じる必要がありません。開発しやすく、管理もしやすく、しかも提供価格どおりに売り上げが上がる。ビジネスとしてリスクがより少ないわけです。

だから、クラウドで儲かるなら、ベンダーはその方がよいはずです。そしてもし、クラウドだけで売り上げのほとんどを挙げられるような状況が実現した暁には、要員の多くをクラウド事業にシフトするようになるはずです。

ここに、ユーザー企業に生まれる懸念があります。

これは何を意味するかというと、これまで受託開発に従事していた要員がクラウドの開発保守に移行していくということです。こうしたことが業界全体で起これば、個別のシステム開発に携わる人員は、当然減少します。

つまりユーザーから見れば、システム開発の委託を行う上でのオプションがなくなっていくことを意味するわけです。

ユーザー企業にとって、ビジネスにおける競争力のカギは「差別化」です。ビジネスモデルで「差別化」し、ビジネスの仕組みで「差別化」し、結果として他社に勝る収益を上げてシェアを獲得します。情報システムがビジネスの仕組みの一部であるならば当然、情報システムにも差別化の要素が要求されます。

しかし、クラウドはサービスの一律提供の仕組みです。多くの顧客が同じ条件で同じサービスを利用します。そうなると、差がつくとすればサービス選択の部分だけです。選ぶ側に目利き力が求められるとはいえ、一律サービスの選択だけでは決定的な差別化にはなりにくいでしょう。

こうしたことから、クラウドが進展すればするほど、ユーザー企業にとってはビジネスの仕組みで差別化をしにくくなるリスクが想定できるのです。

先に述べたとおり、顧客が増える限り、ベンダーはクラウド化の動きを加速していきます。現在ではまだクラウドだけで儲かる状況にはなっていませんが、この先そうなる可能性は、十分あるでしょう。

そのシナリオが見えている以上、ユーザー企業は今のうちから、クラウドを的確に選択する能力、一方でいざという時に自らつくり込める機動力、クラウドのサービスと自社開発のシステムをうまく組み合わせる実践力を、蓄積しておく必要があるのではないでしょうか。

これからはますます、user-driven なユーザー企業であるかどうかが問われる時代になる気がしてなりません。