「システムデザイン」タグアーカイブ

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

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

 

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日時: 投稿者:

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

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

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

なぜか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「クラウド」に踊らされない冷静な消費者（2011年11月）

投稿日時: 投稿者:

「クラウド」は、近年では久しぶりに「大ヒットした」と言ってよい IT ワードになりました。この言葉を知らないと答えるビジネスパーソンは、かなり少数派ではないでしょうか。

ここまで広まった理由と考えると、やはり「もう企業は、自分でコンピューターを買わなくてもよい」という、極めてわかりやすいメリットが提示されたことが、まず思いつきます。

コンピューターは、買おうとするとコストが大変かかるし、メンテナンスも結構面倒くさいものです。しかしクラウドなら買わなくてもよく、メンテナンスしなくてもよいばかりか、必要なら簡単な操作をするだけでパワーを付け足すこともできる。やめたくなったら、契約を解除してやめればよい。後には何も残らない。そんなふうに考えると、長年コンピューターに悩まされてきた経営者にとっては天の声に聞こえるかもしれません。

しかし残念ながら、いくらクラウドになっても、企業が IT を使いこなすうえでの要諦は、何も変わりません。むしろ、解くべき方程式の次元が増えて、答えを出すのがかえって難しくなったと考えたほうがよいのではないでしょうか。

クラウドはメリットがはっきりしていますが、一方でリスクもはっきりしています。セキュリティの問題、契約の問題、ネットワークの問題など、みなさんもいくらかお聞きになったことがあると思います。

クラウドを自社のビジネスに活かすのなら、そうしたリスクを踏まえてもなおクラウドを選択する「積極的理由」を持っていることが、ひとつの条件になるだろうと思います。

例えば、現在ファーストリテイリングが進めている「G1プロジェクト」というものがあります。同社はこのプロジェクトにおいて、事業基盤を全面的にクラウドにする方針のようです。

同社は現在、世界展開を積極的に推進しています。世界の店舗で同じ業務プロセスを適用し、データを共通化する目論見があるのでしょう。そのためには、共通化したシステム基盤上で店舗のオペレーションが実現される必要があるわけです。それを具体化する手法として、同社はクラウドを選択したということです。

このケースでクラウドが唯一絶対解とは言えませんが、そのなかで同社はクラウドを選択しました。そこには、事業形態や戦略方針の上で、クラウドを選択する積極的な理由があるわけです。

おおよそこういう企業は、クラウドを選択してもひとまずうまく行きます。

一方で、逆に「消極的理由」でクラウドを選択する企業は、おおよそ本来の恩恵を受けにくくなります。例えば、トラブルが起こると厄介だからシステムはあまり持ちたくない、という発想の場合です。

5 年程前ですが、MIT が実施した調査でこんな結果が出ています。自社のコア業務の IT 化に成功した企業とそうでない企業の間で比較すると、経営層の満足度は前者が 80% 高く、それでいて IT コストは前者が 25% 低かったのだそうです。

5 年前にはまだクラウドとは言いませんでしたが、すでに ASP はありました。そこで後者の企業群を想像したとき、上記のような「消極的」発想が浮かんでは来ないでしょうか。

そもそも IT への消極的発想は、IT を使うこと自体にリスクや負担を感じている証左です。そうであれば、クラウドを選択する以前に、まず「コンピューターってうちの会社のビジネスに必要なのか？」という疑問から、考えてみなければならないでしょう。

もし必要なのであれば、ビジネスのどこが IT だと都合がよいのか、明確に整理すべきです。そこが明確なら、発想は消極的になりません。もし IT が必要ないなら、面倒ですからなくしたほうが無難です。

「IT を使っておもしろいことをやろう」「IT で他社を圧倒できないだろうか」「IT がもたらすメリットを積極的に取り込みたい」と考えている企業にとっては、クラウドも数あるうちのひとつのオプションにしか見えないはずです。そういう企業こそが、「マーケティングに踊らされない冷静な消費者」になれるのです。