「2013年」カテゴリーアーカイブ

「詳しいことはわからない」CEOは、正しいのか

投稿日時: 投稿者:

先日読んだ、日経ビジネスオンライン（NBonline）のコラムのなかで、おもしろいものがありました。

デジタル化に乗り遅れたという架空の企業を題材に、立て直しに奮闘するCEO、CIO、CMOの姿を描いた連載なのですが、登場人物のやり取りがいわゆる「経営トップへのインタビュー」の特徴をよくとらえていて、思わず笑ってしまいます。わたしの経験上でも、本当にこんな感じになることが少なくありません（残念なことですが）。

このコラムで描かれているようなマインドセットを持つユーザー企業は、「弱いシステムユーザー」の典型例にも見えます。強いユーザー企業なら決して取らない態度が、このコラムでは3つほどあるのに気付きました。

ひとつ目は、システム導入のきっかけがベンダーで、ベンダーの言われるがままにシステムを導入する、という点です。そういう場合、たいていは結果としてまともに動かないか使いこなせず、「こんなはずではなかった」ということになります。しかしそれは、ベンダーが悪いのではありません。

強いユーザー企業では例外なく、経営者や責任者に、システムに対する強い当事者意識があります。そういう方々は、概してシステムを厳しく査定しようとします。NBonline のコラムでは、CEOがある意味失敗を放置していて、外部から招聘したCIOにまたしても、委任という名の丸投げをしようとしている意識を感じてしまいます。

ふたつ目は、システムをつくるのにもかかわらず、ビジネスの仕組みが極めてアバウトである点です。強いユーザー企業では、ビジネスの仕組みにかなりのこだわりがあります。それがアバウトであることはあり得ません。

例えば、自動車をつくろうと思ったら、ふつうはまず設計図を描くものだと思います。しかし、ことITとなると、ビジネスの仕組みを明らかにすることなくシステムを導入してしまうわけです。コラムでは「とりあえず売ってみようと思った」「できるだけ利用してもらおうと思った」といった、こだわりはかけらもないような言葉が出てきます。これらは、ビジネスの仕組みの意識の不在を象徴していると思います。

そして三つ目は、「詳しいことはわからない」ことにまったく平気でいられる点です。

新しいことだから広告代理店に頼んだ！？というのは千歩譲ってよしとしても、その広告代理店が検討する「ビジネスの仕組み」に首を突っ込まないどころかフォローも一切しないのは、その会社のビジネスを預かる経営者としてやはりまずいと思うのは、わたしだけでしょうか。

くどいようですが、強いユーザー企業は、ビジネスの仕組みと、そのアウトプットに強いこだわりを見せます。システムとは話が違うようでいて本質的には同じ例として、大手コンビニ各社のトップが、おにぎりなど新しく開発した商品を必ず試食して合否を出すことなどは、非常に端的ですがアウトプットへのこだわりの表れだと思います。「オレが納得していないものを、お客様に提供するな」ということです。

ITの細かい技術までは知らなくてもいいと思います。しかし、システムのあるべき姿のデザインについて、ビジネスの仕組みの構築について、他人に任せたそれらのことは本当にわからなくていいことなのか。このCEO殿にも、今後の連載のなかでぜひご理解いただきたいと念じてやみません。

 

（追記）
つい先日、元ソニーCEOとCIOの両氏による対談記事を読みました。

こんなCEOのもとで働けるCIOは幸せだろうなと、感銘を受けました。上記と合わせて参考にしていただきたい内容です。

 

知るだけで、終わっていないか

投稿日時: 投稿者:

最近、技術の進化を背景にしたトピックに、事欠かないような気がします。

例えば、電子書籍。リーダーやスマホで読書する人は珍しくなくなり、本はもはや紙で読むのが当たり前でもなくなってきました。ビッグデータにまつわる喧騒は、単なるバズワードでもない様相も感じさせます。JR東日本がSuicaの利用履歴データを利用者に十分な説明をせずに販売し、パーソナルデータの取り扱いについて論議を呼びました。そういえば最近、自動車業界では自動運転技術が盛り上がっています。日本でも、複数の企業がデモンストレーションを公開して技術を競っています。

こうした動向をメディアなどで目にしたときに、自分は何を考えるか。ビジネスの仕組みやシステムを企画するうえでとても重要なことだと、常々ボヤッとしているアタマをたたき起こしてリマインドするようにしています。

ともすれば、「電子書籍もいいけれど、やっぱり紙で読んだほうがいいなぁ」であったり、「自動運転の車が買えるようになるのはもうちょっと先だろうから、まだあまり関係ないかなぁ」などと、個人の視点で捉えて終わってしまいがちです。個人の趣味趣向であればそれでよいのですが、ビジネスの世界において同じことをしていると、たとえいま一流の会社でも、いつのまにか事業がピンチに追い込まれてしまうかもしれません。

これは、そんなに極端な話でもありません。ビジネスの世界には「企てる人」がいます。「企てる人」はいつでも考えていて、考えている人と考えていない人とでは圧倒的な差がついてしまうのです。

考えている人はこうした情報に触れたとき、その先のシナリオを想像します。

「電子書籍は、学校の教科書にも適用できる。シンクライアントの技術と組み合わせれば、生徒や学生は荷物を持たずに学校に行くようになるかもしれない。そうなると、ランドセルや通学バッグ、もしかすると毎日通学さえしなくなって制服も売れなくなる。」
「自動運転が当たり前になると、トラックにも適用できる。経路のプログラミングができるのなら、例えばアマゾンのような大規模な流通業者は、みずから自動運転トラックを配備したくなる可能性が高い。そうなると、付加価値の高い物流技術を持たない運送業者はピンチになる。」

本当にそうなるかはわかりません。しかし、こうした想像を今からしているバッグ業者や運送業者と、電子書籍なんて自動運転なんてウチの事業に関係ないからと何も考えていない業者では、年を経るにつれて明らかに差がつくと思うのです。

もっと高度な人たちは、自分の考えるシナリオを世の中のトレンドやスタンダードにしてしまおうと企てます。そんな人はひと握りの特殊な人物かと思いきや、意外とサラリーマンだったりするのです。要はそれが、組織的な取組みなのか、その会社が本気でカタチにしようとする取組みなのかどうかの問題です。

そんな「考えたもの勝ち」のような人たちが世の中を動かしているのだとしたら、みなさんの会社で何もできないことはないかもしれません。ガンホーだって、LINEだって、数年前は知らなかった方、多いのではないでしょうか？

 

「事例」の見かた、使いかた

投稿日時: 投稿者:

職業柄、「いい事例があったら教えてください」と頼まれることがあります。

当社ではすでに業界横断で2500を超えるシステム活用事例を調査分析し、エッセンスを蓄積しています。事例の数は、いまでも増えています。そのことを知っている方々から頼まれるわけです。

もちろん口頭で概要をお話しすることもありますが、場合によっては本格的なセミナー形式で紹介する提案をすることもあります。しかし時々、「教えるのは逆に、この会社にとって害になるかもしれないな」とちゅうちょしたくなる場面も、実はあるのです。

そう感じるかどうかの境目は、その人または企業の「事例に対する認識」にあります。

およそ「事例」というと、ある企業が「何をしたか」「どうやって実現したか」が説明されたものとイメージされるかたが多いと思います。そういう説明はそれで参考になりますが、本当に学ぶべきなのはそこではありません。

何でもそうだと思いますが、あることを実現し達成するに当たり、まずはそのことを計画しているはずです。そのときに、その人や企業が何を考えてどういう「発想」をしたのか。これが、まず大事な目のつけ所のひとつです。その「発想」が行動の起点になっているわけで、実現される解決策はほとんど、その発想からの自然な流れで出てきています。

さらに、その「発想」が出てくる大元の根源には、その人や企業の「マインドセット」、大仰に言えば信念のようなものがあります。これも、大事な目のつけ所です。

例えばビジネスインテリジェンスや事業継続など、表面的には同じ内容を実現しているように見えて、実は得られた効果や活用のされかたが意外にも異なる事例があります。なぜそんなことが起こるかといえば、そもそも根本的に目的意識やマインドセットが異なっていて、目指した方向が違っていたからです。しかし、違っているけれど、それらはどちらも正解に思えます。なぜかといえば、マインドセットがいずれの場合も明確で、それに沿った結果を実現しているからです。

つまり、事例から学ぶべきは、ひとことでいえば考え方なのです。

あることに対するマインドセットが固まっていない人や企業は、事例に含まれているWhatやHowにすぐに飛びつこうとします。それをそのままマネしようとし、なんとなく実現するけれど、結果としてはたいした効果を得られず、想像以上にコストがかかるなどして、「思っていたことと違う」などという感想を持つのです。

自らの「マインドセット」がなく、自ら「発想」もしないまま、いきなりITに飛びつくから、そんな結果になるのではないでしょうか。

「マインドセット」が整っている人や企業は、事例で紹介されているソリューションそのものよりも、そこから、考え方や発想といったエッセンスを抽出しようとします。だから彼らは常に、同業他社に限らず幅広く事例を知ろうとします。どんな業界のどんな会社の事例でも参考になりえるのです。

事例に対する認識は、こんなふうに態度や行動に現れます。同業他社が何をやっているか、何がやれているか、そんなことばかりが気になるケースは、推して知るべしです。まずは自らの（ITに対する）信念を固めるところから始めるべきでしょう。

 

Want to の目標と、Hope to の目標

投稿日時: 投稿者:

システムの構築とはつまり、ビジネスを実行するうえで「実現したい」と思っていることを実際にカタチにすることだと思います。

これは、多くの人にとって容易なことではありません。例えば、他人から「あなたの考えを文章にしてください」と言われたり、「あなたの頭に思い浮かんでいることを絵にしてください」と言われたりすると面食らう人が多いと思いますが、それと本質は似ていると思います。

それほどに大きなエネルギーをもって推進する必要がある取組みなだけに、その実現を本気で追求する意思と環境が必要になります。このとき重要なカギを握るのが、経営トップの「本気度」です。

経営トップになれるような頭のいい人や経験値の高い人は、「目標は何か」「何がしたいか」と聞かれると、大変きれいな回答をします。ただし、皮肉を言うつもりはありませんが、それらの回答の「本気度」には、多くの場合温度差があるものです。

コーチングなどにも応用されている行動心理の世界では、人間が持つ目標には3種類あると言われているようです。

ひとつは、Hope to の目標。「～したいな」「できたらいいな」というレベルの目標です。この目標は、確かに本人の望みではあるものの、その本気度はあまり高くありません。「できたらいいな」は「できなくてもまあいいや」ということでもあるのです。ですので、困難に立ち向かってでも、少々痛い投資をしてでも、とにかく実現したいかというと、否というのがホンネです。

ふたつ目は、Have to の目標。これは、自ら望んでいるわけではなく、環境や制約の要因から「～しなければならない」という必要に迫られた目標です。つまり、単なる義務感で目指している目標なのであって、本心では気が進んでいません。コミットメントのレベルは実はあまり高くないのですが、しかたなく力を入れて実行します。そのため、終わってしまえばそれまで。それ以上の改善や発展は望めません。

最後が、Want to の目標。自分はこうなりたい、これを実現したい、と積極的に望んでいる、最も意識の高いレベルの目標です。この目標を持つ人は、それを実現するために日々考え、困難を乗り越えて実行しようとします。放っておいても勝手にコトを進めていきますし、実現した後は別の課題を見つけてさらに発展させようともします。

こうして見比べてみると一目瞭然だと思います。本気の目標なのは、Want to の目標だけなのです。

システム整備の推進、または情報セキュリティマネジメントの整備を推進していくうえで、経営トップがその課題に対して Want to の目標を見据えて部下に指示をしているのであれば、これほど推進しやすい環境はありません。部下のみなさんがきちんと力を発揮するのみです。

一方、経営トップがその課題の克服を Hope to の目標として捉えているとすれば、システムの具体化が進むにつれてどんどん熱が冷めていき、推進力が萎えていきます。もうすこし率直に言えば、丸投げ状態になっていきます。

ビジネスを発展させるシナリオを描き実行を指示するはずの経営トップがこのような状態でシステム化を推進しても、ビジネスに資するよいシステムにはおよそなりません。特に一旦トラブルに陥ると、「誰が決めるんだ」というような話になりやすく、抱えなくてもよい困難を抱えやすくもなるのです。

その意味でも、経営トップは、本気の目標は熱を持って、その実現に向けたストーリーを語らなければなりません。一方で CIO や情報システムの技術者には、経営側の「本気度」を見極める能力が要求されることになります。

本気かどうかがわからないときは、経営側のアクションや判断が必要になる話を、具体的に掘り下げてどんどんしてみることです。本気でない場合は考えが浅いですから、だんだんとその話をすることに気が向かない雰囲気になっていきます。「そんなのおまえが提案しろ」と言い出したら、アヤシイと思ってください。

 

業務変革・イノベーションを阻む最大のカベ

投稿日時: 投稿者:

業務変革やイノベーションを組織的に実践していくうえで、一番のカベとなるものは何だと思いますか？

推進する人材、資金、ノウハウ、いろいろ要素はありますが、一番の障害になりやすいのは、その企業の社風や企業文化ではないかとわたしは思います。

以前、業務変革とシステム改善の相談を受けて、ある中堅企業に面会にうかがったことがあります。その企業はフランチャイズ形式で店舗を全国に展開している企業でした。

その席でわたしは、業務の見直しと改善を図るなら全社レベルで業務プロセスを一度整理するのがよいと、助言しました。そうすると、先方の役員はこのような趣旨のことを述べました。「店舗の業務に問題があることは把握している。調べる必要はない。それに本社には店舗サイドを管理できるほど人数がいないので、店舗のことは考えなくともよい。本社の業務だけを改善したい。」

本社の業務にすでにいろいろな課題が表面化している状態であったため、目の前の課題を解決したい気持ちはよくわかりました。しかしこの考え方のままで改善を進めても、本当の問題が現場（つまり店舗）にあると、問題は本当の意味で解決しません。

本社にしか目を向けなければ店舗の問題は見えず、本社だけを治すことで店舗側に別の支障が出る可能性もあります。そして店舗の業務に支障が出れば、ビジネスにマイナスの影響が出るわけです。

したがって、社内的な都合だけでフォーカスを絞るような考え方では、問題の核心を押さえてビジネスに好影響を与えるような業務改善は困難です。

問題がある場合、その問題は表面に見えているよりも、その奥に隠れていることのほうが多いものです。簡単に解決策が見出せない問題ほど、解決のカギは、その企業の常識や習慣に根差したところにある可能性が高くなります。そうした当たり前と思い込んでいる部分に目を向けて自らを変えられる意思が、特に経営層にない場合、業務変革やイノベーションはかなり困難になってしまうのです。

わたしのようなコンサルタントでも、こうした潜在意識を変えていただくように働きかけるのは、企業に入り込む前のご相談の段階ではほとんどファクトを握っていないために、大変困難なのが実情です。ただ、丁寧に説明することで、逆に「とても勉強になった」と感謝していただけるケースもありますので、ひとまずトライするようにはしています。

イノベーションのヒントになりそうな、2つのサービスの仕組み

投稿日時: 投稿者:

今回は、最近見つけた2つの興味深いプラットフォーム・サービスのモデルをご紹介しながら、ビジネスに資する仕組みの発想を巡らせてみたいと思います。システム企画のヒントになれば幸いです。

まずは、NikeのFuelBandのお話から。

ご存知の方も多いかと思いますが、最近健康や栄養に関連するライフログをベースにしたサービスや商品が次々登場してきています。NikeのFuelBandもそのひとつ。腕に装着するリストバンドになっており、常時身に着けていることで日常生活や運動による消費カロリーや歩数などを記録してくれるというシステムです。日々の運動の記録や推移をチャートで確認することもできるので、エクササイズを続けるモチベーションにもつながり、人気商品になっています。

この商品の仕組みも興味深いところですが、もうひとつ興味深いところがあります。それは、FuelBandが取得するデータを活用した連携アプリを、一般の開発者が開発できるようにしている点です。

例えば、FuelBandが取得する運動データを利用して、個人の目標に合わせた日々のトレーニングの提案をするアプリや、バランスの良い肉体を維持する食事のメニューを提案するアプリの可能性が考えられます。つまり、FuelBandを単なる商品としての枠に留めず、サービスプラットフォーム化を目指しているというわけです。

これは、顧客データを持っている、もしくは顧客データが取得できることを強みにしたサービス基盤の発想という点で、ひとつのヒントになる事例ではないかと思います。ビジネスにおけるプラットフォーム・モデルは Google や Apple の事例ですでに著名ですが、彼らは圧倒的人気のサービスまたは商品をもとにプラットフォーム化を狙いました。一方、FuelBandの例のようにデータそのものをプラットフォームの基盤にしようとする例は、まだそれほど多く世の中に出てきていないのではないでしょうか。

ただしこのモデルを成功させるには、そもそもその商品が爆発的に売れて、顧客がデータをどんどん提供してくれなければ成立しません。新たに仕掛けるなら、それが大きなハードルになります。大手企業であればまだ可能性がありますが、中堅以下ですと簡単にヒットを飛ばせるものではないかもしれません。

そこで、もうひとつヒントになる事例を。IFTTTというものです。

IFTTTとは、”If this, then that.”の略なのだそうです。その実態はWebサービスであり、モーションセンサーなどを搭載したハード、またはアプリを、IFTTTのサービスに接続して連携することで、さまざまなオートメーションが実現する、というものです。

例えば、朝ベッドから起きると自動的に部屋の照明が点灯する。外からショートメッセージを送るとエアコンが作動する。机の蛍光灯の電気をつけると、隣にあるパソコンが自動的に作動する。そんな「AならばB」のような連携を登録しておけるというサービスなのです。

こうしたサービスは、これまでの常識では、家電メーカーのブランドを統一しないと無理そうなイメージがありました。IFTTTはその常識を打ち破って、家電のネット化が簡単にできてしまう可能性を秘めていると言えるでしょう。

その点も興味深いのですが、プラットフォームの仕組みの面でも、学べる点があると思います。

IFTTTとFuelBandは、生活環境を便利にするツールという観点では方向性が似ていますが、FuelBandは自らの強みを活用するプラットフォームである一方、IFTTTは単に「つなぐ」ことに徹したプラットフォームになっています。自ら何らかの商品を持つことなく、単に世の中の不特定多数なものをつなごうとしているだけです。

IFTTTのプラットフォーム・モデルでも、多くの人にインタフェースを揃えてもらい、使ってもらわなければ発展しないのは同様です。しかし、事前に圧倒的な強みを所有している必要はないわけです。こうしたモデルであれば、大手でなくてもチャンスがあるかもしれません。

世の中、いろんなところに発想のタネが隠れています。コンスタントな情報収集が大事であることを折に触れて申し上げているのは、そうした理由からです。企業であれば、それを社内の個人に頼るよりも、組織的に行う方がより確実で効果的です。

 

「高速でつくる」前に、やるべきこと

投稿日時: 投稿者:

ビジネスの変化は速い。それなのに、情報システムがビジネスの変化のニーズに対応できないのでは困る。だから、情報システムもまた、速くつくれなければならない。

まったく、そのとおりだと思います。実際、情報システムが足かせになることで、新しいビジネスの取組みに支障をきたしたり、競合に比べて満足のいくものにならなかったりすることが起こっています。それに対して、その場しのぎの対応でお茶を濁している例も少なくありません。経営者の立場になれば、これだけカネ掛けて何のための IT か、という話になってきます。

こんな風潮のなか、システムやアプリケーションの高速開発を実現する手法がいろいろと提案されています。中でも代表的なのは「アジャイル開発」でしょう。

ご存じないかたのために端的に説明すれば、アジャイル開発とは、従来のように厳密にすべてを設計することなく、まずはプログラムをつくって動かすことを優先し、さらにそれを少しずつ改良していくことでシステムを仕上げていく開発手法のことです。ウォーターフォールと呼ばれる従来型の開発手法に比べ、システムに対する要件が後からでも取り込みやすく、設計のドキュメントをつくる工数を少なく済ませることが大きな特徴になっています。ちなみに、英単語である「アジャイル（agile）」には、「迅速な」「敏捷な」といった意味があります。

確かにこれは有力な開発手法で、広義に捉えれば、こうした「作っては直す」開発手法は以前からいくつか提案されてきてもいます。それほどに、柔軟性のある開発手法には以前からニーズがあるわけです。

一方、なかには近視眼な人がIT業界にもいて、「もうアジャイルじゃなきゃ無理でしょ？」とまで云う声も聞こえてきます。先日も、そんな発言をする人に出会いました。

現在使える「速くつくる手法」をうまく適用できれば、これまで何カ月、何年とかかると言われてきた情報システムが、数週間ないしは1～2か月でできてしまうことが実際に起こります。ただしそれは、「速くつくる基盤」があってのことです。これを忘れてはなりません。ドライバーが車をカローラから F1 カーに乗り換えるかように速くなるわけではないのです。

ここでいう「基盤」には、ふたつの意味があります。それは、システムを開発する技術環境の基盤という意味と、その基盤を活用できる組織のガバナンスや体制の基盤という意味です。これらをそろえて初めて、本当の意味で「速くつくる」ことができるようになります。

特に前者の「システムを開発する基盤」は、いったん整備されれば、その柔軟性がビジネスの柔軟性そのものになると言っても過言ではありません。そのため、ことこの基盤を整備しようと思えば、関係者間で共有されたビジネスの目的や今後の戦略などのもとに綿密に企画設計し、構築することが要求されるのです。

どうも先ほどのような近視眼な人たちは、この点をすっかり忘れてしまっているか、ここもアジャイル開発できると思っているか、どちらかのように思えてなりません。

またアジャイル開発では、ITの関係者も、そのシステムにかかる業務の関係者も、一堂に会したプロジェクトチームによって開発を推進していくことが特徴になっています。プロジェクト期間中は毎日同じ部屋で仕事をするようにすることもよくあります。なぜそうするのかといえば、チームとして一体となることで関係者間のカベをなくし、意思決定のスピードを上げるためです。開発は速くできるポテンシャルがあるのに決めるのが遅いのでは、何のためのアジャイルか、ということになるからです。

さらに言えば、そうしたチームづくりは規模が小さければハードルはあまり高くありませんが、全社レベルのシステムならどうでしょうか。グローバルなシステムならどうでしょうか。関係者が増えるほど、距離が離れるほど、意思の疎通は難しくなっていきます。それを克服するような組織体制ができていなければやはり、何のためのアジャイルか、ということになるのです。

情報システムにもっとスピードが欲しいと考えておられる経営者や経営幹部の方々には、自社の情報システムがこうした「速くつくる基盤」を実現できているのか、まず確認されることをお薦めします。もしできていないなら、「速くつくる」前に、そのための基盤整備に投資を行う必要があるということです。

システムは、技術者やベンダーに任せていればできるものではありません。

クラウドに冷静なユーザー、食わず嫌いなユーザー

投稿日時: 投稿者:

日本情報システム・ユーザー協会（JUAS）が、「企業IT動向調査2013」を発表しました。これは、同協会の会員企業を中心にユーザー企業のIT動向を調査したものです。

結果の全容を知るにはレポートを購入しなければならないのですが、一部の主要な結果については同協会のホームページで閲覧することができます。中堅企業以上の、ITに関しては比較的積極的な企業が調査対象の主体になっていますが、どのような規模のシステムユーザー企業にとっても参考になる結果です。一度ご覧になることをお薦めします。

わたしが見たうちで興味深い結果のひとつは、ユーザー企業のクラウドに対する見かたです。

クラウドの導入状況を聞いた結果によれば、基幹系をクラウド化した割合は調査企業のうちの 2～3%、情報系はメールシステムを中心に 20％程度になっています。基幹系と情報系の採用割合の差が顕著です。

情報系システムのクラウド化は、特に人材の乏しい中堅以下の企業には向いています。調査結果においても、売上高が 100億未満の中堅中小企業では比較的割合が高くなっているようです。

一方、IaaS および PaaS の導入に関しては、確かに導入は増加しているものの、調査が行われた 2012年時点では導入企業がいずれのサービスも 1割程度。ひとまず検討くらいは行う企業の割合は 4割強で、すでに頭打ちになっていることがうかがえます。

つまり、全般的にユーザー企業はクラウドを非常に冷静にとらえて判断していると見えます。マスコミやベンダーのなかには、「クラウドファースト」であるとか「これからのシステムはクラウドが当然」のような、“クラウド万歳”な論調を採り、これでもかというほどにクラウドを採用した企業を取り上げるケース（よく見ると、だいたいはメールやグループウェアの類を使っているのですが）もしばしば見受けられますが、当のユーザー側は、全般的にはそれに流されていないようです。

ただし、一般的な傾向がそうだからといって自社も同じ歩調を取ればよい、ということでは、もちろんありません。

こうした企業調査に対しておよそ言えることですが、これはあくまで「トレンド」を示しているだけのことであり、実際に採用する方針は、その企業の経営環境や今後の方向性によって、個別に判断すべきことです。極論すれば、クラウドをベースにしたシステムを考えたほうがよい企業ならば、仮に他の 99％の企業がその傾向でなくても、クラウドを採用すべきなのです。

むしろ、他が採用していない中で自社がいち早く採用すればチャンス、かもしれません。このあたりは、自社が置かれた環境に対する読みと論理的な状況判断、つまり「目利き」が要求されます。

このとき、正確な読みや判断をしていくためには、正しい情報を把握することがまず必要です。その意味で、わたしがよく申し上げることですが、「小さく試す」ことが重要になります。

「試す」ことを面倒がってやらないユーザー企業が大多数なのが現状ですが、どこかの大企業にならって「ビッグバン導入」などすれば、大金をはたいたうえに失敗する可能性は高くなります。ちょっと「試す」だけで、かなりの情報を獲得でき、目利き力が上がるのですから、やらない手などあるでしょうか？自分たちが納得のいくシステムを使いたいと思っている企業なら、どこでもやっていることです。要は、その習慣があるかどうかの問題です。

そんなことを考えると、先ほどの調査結果に対してうがった見方をすることもできます。

どういうことかといえば、データとして「流されていないユーザー」に見える中には、単に食わず嫌いで「試す」ことなど考えてもいないユーザーも、含まれているのかもしれないということです。結果を疑いなく、額面通りに受け止めてはいけない、こうした調査を見るうえでのひとつの側面です。

そういうユーザー企業の後を追わないほうがよいのは、言うまでもありません。

 

ITで「イノベーション」を実現する秘策

投稿日時: 投稿者:

「ITで業務効率化を実現するだけでは足りない。これからは、ITで新たな価値を生み出すイノベーションの取組みが必要だ。」

最近、このようなことがよく言われるようになっています。個人的には、ITを考えるうえで業務効率化とビジネス価値向上を分けて考える必要はないと感じていますが、上記のようにおっしゃる方の趣旨には同意します。わたしは、「ITの前に、顧客に価値を生み出すビジネスの仕組みをまず考えよう」と、何年も前から訴えてきました。

冒頭のスローガンは正しいかもしれませんが、実態はというと、あまり優れた事例を最近耳にしていません。例えば、建機メーカーのコマツがKOMTRAXという優れたビジネスモデルを成功させ、一時マスコミが盛んにこれを取り上げました。すると、同業のみならず異業種の企業までもがKOMTRAXのビジネスモデルを模倣したサービスを始め、これをまたマスコミが「イノベーション事例」として取り上げたりしています。

ビジネスの世界において、マネをすることは法律や倫理に則る限り許容されることですし、モノによっては歓迎されることでもあります。ですから否定はしませんが、ただし、組み合わせの工夫もない単なるマネは「イノベーション」ではありません。

成功した実績のあるものをマネすれば成功確率は高い、と考えてマネするのだろうと思いますが、残念ながらそういう発想の組織では、いわゆる「イノベーション」の果実を得ることはできないと思います。

なぜなら、イノベーションの取組みでは試行錯誤は必要不可欠で、それを組織が許容し、果実が得られるまである程度の時間がかかっても取組みを継続する必要があるからです。

イノベーションを実現する組織が必ずやっていることがいくつかあります。そのうちで一番重要なことは「試す環境をつくる」ことでしょう。

組織の中に「試すチーム」をつくり、彼らに情報収集をさせ、アイデア発想の環境を整備し、発想したアイデアの実現性を積極的に試す。試して可能性がありそうならスモールスタートで適用し、徐々に範囲を拡大、または新たな発想を付加して改善を図る。もちろんダメと分れば途中でもやめるが、小さいうちにやめるので傷口は小さい。やめることのダメージは小さいし、ダメだったからといって誰かが責められることはなく、それよりも傷口の小さい失敗の経験は有益と捉えられる。

こうしたことが実行できるようなリソースを経営側が用意し、属人的ではなく組織として実際に繰り返し「試す」ことが、イノベーションを生むうえで最低限の必要条件です。

アイデアには「打率」のような側面があり、構想段階でどれだけすばらしいと感じていても、ヒットになるとは限りません。一方で、「こんなもの売れないよ」と社内で評価されたものが、出してみたら大ヒットということも実際に起こっています。KING JIMの「ポメラ」などは、その有名な事例のひとつです。

またアイデアには、「一度ヒットにならなければ永久にボツ、というわけでもない」という特質があります。アイデアのヒットは、TPOのすべてが条件として揃ったときに生まれるものです。つまり、たまたまそのアイデアを出す時期が誤っていただけであった場合、時期を改めるとヒットになることがあります。その意味で、アイデアは「寝かせておく」ことも有効なのです。

ポストイットで有名な３Mという会社では、社内にアイデアのデータベースを用意して、一度ボツになったアイデアにも管理番号を振って保存していますが、こうしたことが理解できているからこその取組みです。

アイデアが持つこうした特質を理解していれば、最初に思いついたアイデアでホームランを飛ばすなど、かなり確率の低いことだと容易に気付くはずです。ただし、最初のアイデアをどんどん発展させていくことで、高く支持されるものになる可能性は十分あります。企業がそれを、組織的なバックアップなしに実現するなど、到底ありえません。

「アイデアがあるヤツは上げてこい」といいながら、明確な判断スキームがなく「声の大きな人の気分」で採否を決めている組織や、「アイデアを考えろ」と言いながら仮説を検証する予算はつけない組織では、新しいアイデアの成功確率はかなり低いでしょう。

知る人ぞ知る話ですが、実はKOMTRAXはもともと、販売した建機の盗難を防止するためのシステムとしてサービスを始めたのだそうです。ところが一旦サービスを始めてみると、顧客にさまざまな価値を提供する発想が浮かんできました。建機は世界の工事現場で使われるモノであり、その利用場所は地図で示せないようなケースもあります。「修理をしたい」「実際に仕事しているのか知りたい」、GPSでわかる位置情報を使ったさまざまな顧客ニーズが浮かんできたわけです。

これを見逃すことなく、発想を新サービスとして形にし、いくつも試していったことによって、現在のKOMTRAXがあるのだと思います。話を聞くだけでは当たり前に聞こえてきますが、実際こうしたことは、ニーズが吸上げられ、アイデアが発想され、仕組みが形式化され、実施判断され、実装されるという、一連の組織的な取り組みになっていなければ、まず実現しません。

もしマネをするのであれば、表面的なサービススペックよりも、それを生み出した組織のしくみに、ぜひ目を向けてほしいと思います。

「みんなの意見」を強力な武器にするために

投稿日時: 投稿者:

今月も、ビッグデータを肴に述べてみたいと思います。

データ活用の視点に関して、最近大事だなと感じているのは、「みんなの意見」の有効活用です。企業の立場であれば、顧客の意見であったり、利用者の意見であったり、オーディエンスの意見であったりします。これは、使いかたによっては強力な武器になると感じています。

ベンダーが盛んにビッグデータを喧伝していますが、そうかといって単なるマーケティングだと軽視しすぎてもいけません。宣伝だけでなく、今後の取り組みに有用な視点も含まれているものです。

そうした有用な視点のひとつに「取得できるあらゆるデータをまるごと分析対象にできるようになってきた」ことがあり、その事例の中で、「みんなの意見」を活用するものが取り上げられることがあります。

こうしたケースですぐに思いつくものといえば、Twitter のつぶやきから企業にとって有益な示唆を得る、という話です。企業がアンケートを取るなどの方法では得られない顧客の本音や、まだその企業の顧客ではない人の意見が、Twitter では聞こえてくる可能性がおおいにあります。これを利用すれば従来得られなかった示唆を見出せる、というわけです。

たしかにその通りだと思います。ただし、ネットでは意見が偏っている人が大声を出しているケースも多々あります。言葉の使いかたにしても、きちんと文脈を読み取らなければ意味を取り違えるケースもあり得ます（例えば、「ヤバい」は、肯定でも否定でも使われています）。それに、そもそも人間には「本音」が必ずしも言葉にならない傾向があります。実際に自分自身のことを考えてみても、思っていることを適切に表現するというのは結構難しいことではないでしょうか。

少し思いを巡らせるだけでも、つぶやきをデータ分析すれば欲しい答えが得られるというほど、簡単な話ではないのだと感じます。

その一方で、「みんなの意見」をうまくつかうと結構すごいなということが、いろいろ出てきています。

例えば、ウェザーニューズが配布しているスマホ向け無料アプリ「ウェザーニューズタッチ」。同社が気象サービスを提供するとともに、そのユーザー（「サポーター」と呼ばれる）が自分の居場所の天気を報告する機能を持っています。

サポーターは2013年2月時点で400万人を超え、1日あたり2万件程度、多いときは約20万件の「報告」が寄せられるのだそうですが、こうした「みんなの意見」により、先日気象庁が外した2回の大雪予報（片や「降らない予報」で大雪、片や「積もる予報」で降らず）を、2度とも見事的中させたということです（関連記事）。

別の例でも、興味深いものを見ました。ある2つのゲームアプリ開発会社で開発されている「オセロアプリ」の対決です。片方は、布石のアルゴリズムを精緻化した「頭脳派」タイプのアプリ、もう片方は、アプリを利用するユーザーのうちで強いプレーヤーたちの布石の傾向をデータ化して利用する「みんなの意見」タイプのアプリ。それぞれの会社が「最強」と銘打つその両アプリを対戦させるというものです。結果、この対戦で勝ったのは、「みんなの意見」タイプでした。

もうひとつ、ネットの翻訳サービスも実は「みんなの意見」がベースになっていることで有名です。つまり、ネットの翻訳エンジンの基になっているのは、ネット上にある膨大な量の文書データ、いわば「みんなが書いた文章」です。それをパターン分析して、文の要素ごとに翻訳パターンのテーブルをつくるという、ごく簡単に言えばそんなことをウラで行っています。

英日翻訳などを試してみると、楽しい？！翻訳がときどきなされるときもありますが、汎用的な内容で短めの文章ならかなり翻訳精度が高いことがわかります。旅行する程度のレベルなら、翻訳アプリが載ったスマホ片手で十分かもしれません。

上記の事例、どれも簡単そうに見えて、実際は相当な分析処理ノウハウが必要です。しかしそれを操れる力を組織が得たなら、「みんなの意見」をうまく利用でき、それがかなり強力な武器になることが想像できるのです。

このとき、強力な武器にするための課題としては、「一定の質を持つデータを大量に集めること」「継続して分析し知見を更新できる基盤を構築すること」「みんなにうまく、定期的に、長期にわたって入力してもらえるようにすること」など、さまざまなものがあるでしょう。

そして、それにも増して必要なことは、この武器を有効に使ってビジネスを加速させる「発想」です。

上記で紹介した3つの例はいずれも「みんなの意見」をサービスに活用しています。このように、この手の話でよくある「マーケティング利用」ではなく「サービス」を「発想」してほしいと思います。そのほうが、武器としてははるかに強力になるはずです。

わたしにもいくつか、コラボしたらおもしろいんじゃないかと思えるアイデアが浮かんでいます。