ホーム > mixiニュース > IT・インターネット > IT総合 > 「ごみデータ」を入れれば「ごみ」が出てくるだけ――変化の時代に勝つためのデータ活用、IT部門はどう関わればいい?

「ごみデータ」を入れれば「ごみ」が出てくるだけ――変化の時代に勝つためのデータ活用、IT部門はどう関わればいい?

1

2018年12月29日 08:22  ITmediaエンタープライズ

  • 限定公開( 1 )

  • チェックする
  • つぶやく
  • 日記を書く

ITmediaエンタープライズ

写真写真

 「日本にCIOという職業を確立させる、それが私のミッション」――。その言葉通り、日本全国津々浦々の“お座敷”で講演を行い、CIOの必要性を説いているのがフジテックのCIO、友岡賢二氏だ。CIOが果たすべき役割とは何か、選ばれるためにはどんな経験や考え方が必要なのか――。



【その他の画像】



 本対談の前編では、友岡氏とクックパッド 情シス部長の中野仁氏が、変化の時代を生き抜くために欠かせない「データ活用」について、また、真に使える生きたデータを生成するために情報システム部門がすべきことについて、対談を通じて明らかにする。



●世界で勝つためには“足元のデータ連携”がキモに?



中野氏: 今回の対談が実現すると分かったとき、松下電器産業(現パナソニック)出身の友岡さんにぜひ、お聞きしたいと思っていたのが、「グローバルで勝つための仕組みをどう作るか」だったんです。なぜかというと、今、まさにクックパッドではそんなシステムを構築しているところなんです。



 クックパッドは2016年に企業としての戦略が大きく変わったんですね。それまで国内中心にさまざまなドメインで事業を展開していたのが、体制変更以降は料理のレシピにフォーカスしてグローバル展開することが決まりました。



 グローバルで戦うとなると、海外も含めて情報を網羅できる仕組み作りが求められるので、システムもそれに合った形にしなければならない。しかし、当時のシステムは事業部がそれぞれの判断で選んでいたこともあって、分散と分断が起こっていたんです。そして、それぞれのシステムの間はExcel職人が手作業でつないでいるような状況でした。



友岡氏: それを、“海外でスケールすることが前提”のシステムに変えなければならなかったわけですね。



・海外で勝っている企業のシステム構成は驚くほど似ていた



中野氏: そうなんです。そこでお手本にするために、海外で成功している企業のシステム構成を聞きに行ったんですよ。すると、どの企業のシステムもシンプルで一貫性があって、スケールすることを前提としてシステムが組まれているわけです。会社の戦略を実行するために、スピーディーな意思決定ができるシステム構成になっていました。システム構成が標準化していて、最初から海外への展開を視野に入れているとしか思えない。



 正直、当時のシステムのまま海外展開しても「勝てるわけがない」と思い知りました。



 そういう背景もあって、グローバルで成功している企業のシステムを参考にしながら、構想も含めて約1年半かけて“海外で戦えるシステムの屋台骨”を作りました。ポイントは3つ。「海外展開を想定したスケール前提の仕組みを作る」「労働集約的な作業は可能な限りシステム側で行えるようにして、スタッフが“人にしかできない仕事”をできるようにする」「“情報システム”という名前の通り、情報を使えるようにする」ということでした。



・世界で勝つためのシステム選びの条件は



友岡氏: どのような条件でシステムを選んだんですか。



中野氏: 幾つかあるのですが、システム的な要件としては「システム運用は可能な限り省力化する」「システム連携(API・SSO)を前提とする」「海外でも同じシステムを利用できるようにする」という3点は重視しました。グローバルで戦うWebサービスの場合、いかに変化に即応できるシステムにするかが最優先です。しかし、組織は小さいので、運用管理に人手を掛けるのは難しい。ここでいう「運用」とはハードウェアの更新やパッケージソフトのバージョンアップ、システム間の手連携といった作業のことを指します。極端な言い方ですが「運用を捨てる」方向に振り切ったところはありますね。



友岡氏: 刷新後のシステムは、クラウドのおいしいところを総取りしたようなシステムに仕上がっていますね。



中野氏: 確かに構成上はそうなっていますが、やってみて分かった課題もたくさんあります。例えば現状の大きな課題は、システム間のデータ連携ですね。とにかくシステムの複雑性を下げるために、システムの数は可能な限り絞りました。システムが多い分だけ、連携のパスは増え、システム運用負荷が上がってしまうので。



・システムを構築してみて分かった「データ連携」の重要性



中野氏: システム数を絞るためには、システムの汎用性がある程度高いプロダクトを選ぶことになる。例えばSalesforceやServiceNowのようなプロダクトですね。これらはSaaSというよりPaaSです。汎用性が高いというメリットもありますが、一方で個別の業務に特化したサービスより複雑で、構築や運用のノウハウが必要です。アプリケーションというよりもプラットフォームですからね。それぞれやれることが多いし、データも柔軟に出し入れできますが、適切な導入と、運用についてもプラットフォームに対する理解が必要です。要は簡単につなげない。



 大量にあったシステムを、ある程度の粒度のプラットフォームにまとめたところまでは良かったのですが、実際にデータを流そうとすると、プラットフォームごとにデータモデルが違うんですよ。プラットフォームごとの設計思想がハッキリしています。



 それをうまくつなげるには、データ連携部分の設計を丁寧にやる必要がある。コネクターはありますが、それをつなぐだけでは足りなくて、その先のデータ設計まで考慮しないといけない。つなぐ土管だけを合わせても、そこを通す水路まできちんと考慮しないとうまくいかないんですね。



・データの種類が少なくても連携に苦労するわけ



中野氏: Webサービスを展開しているクックパッドは、メーカーと違って生産や販売がないから、「メーカーのデータに比べたら連携はラクだろう。商品マスターや部品表とかないし〜」と思っていたのですが、甘かった。確かにデータの種類は少ないのですが、データの持ち方が違うところを合わせるのが結構、大変なことが分かったんです。



 ワークフローを例に挙げると、設計する前は「社員マスターと組織マスターを連携させれば済む」と思っていたのです。これを実際にやってみると、クラウド系のシステムはそれぞれマスターの持ち方が微妙に違うことが分かりました。特にワークフローに必要な組織情報やセキュリティコントロールに必要な情報は、データ連携でつなぐのが非常に難しい。



 しかも日本企業にありがちなことですが、組織構造的に不明確な役職、兼務のときはどうするのかとか、プロセスにも例外処理がやたらと多い。外資系システム導入あるあるですが、職務分掌と上司部下関係が比較的明瞭であることが前提なので、曖昧な構造を持つ日本企業と相性が悪い部分がある。



 そんなわけで、そのまま“右から左に社員情報や組織情報を土管で流せばよい”、というわけにはいかなかったのですよ。



 社員組織マスターにしても、システムごとに微妙に持ち方が違うので、それをどう吸収するかを配慮しなければならなかった。だから今は、ゴールデンマスターデータみたいなものを作る必要があるね、という話をしています。MDM(マスターデータマネジメント)まではいかなくても、ゴールデンマスターデータでシステム間のデータモデルの差異を吸収し、データを再利用できるようにする。BIや他のシステムでのデータ利用には直接APIでつながせて、って思っていたのですよ。でも、多分それを考えなしにやると、遠くない未来に運用が複雑化して破綻する予感がすごくします。



・アプリの疎結合化を考えないと大変なことに……



中野氏: また、システム間のデータ連携では、アプリの疎結合化を考慮し切れなかったことについての学びがありましたね。各アプリケーションの間はInformaticaのIICS(Informatica Intelligent Cloud Services)を介してつないでいて、データのつなぎ方自体は標準化できました。いわゆるEAI(Enterprise Application Integration)の領域です。CSVによる手連携やダブルメンテナンスはもちろん、手組みのプログラムによる連携があちこちに混在して“何がどうつながっているのか分からない状態”は回避できました。データ連携部分は魔窟化しやすいので、つなぎ方を標準化できたことで一定の秩序は確保できた。



 しかし、各システム同士をInformaticaの中で直接つないでいた。つまり、システム間が密結合化してしまったので、エラーが起きた際の切り分けが難しく、影響が出たときのリカバリーが大変なんですよ。運用負荷がひどく高くなってしまうことに気が付いたんです。



 そこで、システムの真ん中にデータハブをかませて、そこから配信するような方法を採るべきだったなと。この部分は、最初の段階から手を付けておくべきで、後でやればいいと思っていたのは良くなかったかもしれない。



 ただ、これも「振り返ってみるとそうだった」という話で、当時はそこまで考える余裕が全くなかったのですけども……。5並列でプロジェクトを走らせていたので、時間的な余裕がなかった。クラウドシステムを組み合わせるからこそ、データ連携というか、システム間連携についてちゃんと考えないといけない。



友岡氏: 現実的にはデータベース連携が一番ラクになってしまいますね。



中野氏: 本当は第2フェーズで、データウェアハウス(DWH)を考えるときにデータベース化はやればいいか、と思っていました。でも、第1フェーズでもある程度、やるべきだったなと。ちょっとそこの見積もりが甘かった。フジテックでは、データ連携部分はどうしているのですか?



友岡氏: データ連携はまだまだ十分とは言えません。連携させる手前の、コードをそろえたりするところで苦労しているのが実態であり、ステップバイステップで連携を進めています。こういうことはグローバルな大企業にありがちなことですが……。



中野氏: 異なるシステム同士をつなごうとすると必ず現れる、コード体系の見直しと、あとは絶対に発生する名寄せですよね。この手の仕事は「グズグズなのを何とかする」という、約束された負け戦ですよ(笑)。



友岡氏: そうそう。まずはコード標準化の問題と、それを業務実装したマスター化の問題があって、それをクリアしても、今度は「マスターを各国のレガシーシステムにどういうふうに連携させるか」という問題がある。そこはまさに連携の仕組みだと思いますが、そのあたりはまだ十分できていないですね。そこに注力するよりも、「まずはグローバルでの利用用途に合わせて各国で変換してデータを出す」という形で連携させるスタイルですね。



●データの精度を上げるためにすべきこと



中野氏: ちなみに、システムは情シスが統括して見ているのですか? それとも部門に散っていたりします?



友岡氏: もともと、さまざまな部門に分散していた仕組みを、段階的に情シス部門に集めていますね。



 まず、サーバを情シスが管理しているデータセンターに集めるような物理統合からスタートして、次は「論理的にどう統合するか」に進みましたね。論理的に統合するところはものすごくハードルが高くて、そこにコードの問題やマスターの問題、アプリ連携の問題があります。



 現実的には、コード標準化のところはちょっと目をつぶりながら(笑)、まずは集計するときにコード変換しながら最速でデータを集める、各アプリのコードの標準化は古いアプリが順番になくなるところまで時間をかけて徐々に合わせていく――というスタンスが、フジテックでは現実的だと思っています。現場実務はローカルコードでしっかり回っているので。



中野氏: ロジスティック系のシステムは、事故を起こすと生産販売の全てが止まってしまうから気を抜けないですよね。人事や会計のシステムなら、仮に事故が起こっても、「決算に間に合えば」「発令がきちんと行われれば」みたいなところで済みますが、ロジスティック系システムはそんなわけにいかない。トラブルで即、業務が止まる。そして炎上、みたいなシビアさがある。



友岡氏: そうですね。基幹システムをどのように統合するかを考えるときには、いろいろなアプローチがありますよね。私はフジテックが3社目なのですが(1社目は松下電器産業、2社目はファーストリテイリング)、過去の経験から、無理に基幹システムを合わせようとはしていないんです。



・データの精度をどう高めていくか



友岡氏: 経営成果をクイックに出そうとすると、やっぱり重要なのはアプリじゃなくてデータなんですよ。生産管理や販売管理のデータは、まずは「今あるものは正しい」として、コンバージョンをかけてでもいいから“あり姿のままでとにかく集める”という形ですね。



 最初にそれをやった上で、「そもそもデータの精度が悪い」とか「データがそろっていない」といった問題を、ある程度可視化してから課題化して、解決する――というアプローチを取った方が、現場納得感を得やすいんです。



中野氏: それは、DWHやBIといった情報系を先に走らせた方がいいということでしょうか。DWH、BIはどんな形で展開していますか。



友岡氏: そこも内製でやっているんですよ。



 現場と製品と顧客に関する全ての情報をグローバルに集めて、1つのデータベースとして確立する。細かいところでのローカルコードなどで違っているものも“いったんは飲み込んで”長いスパンの中で合わせていく――というスタンスですね。私の過去の経験から、このようなスタンスを取っています。



 データのクレンジング処理にも、実際時間がかかります。集めてみたときに「結果的に使えない」という問題が出てくるのも、あらかじめ想定しています。結局、“使えない”という事象の背後には、必ずプロセスの問題があるんですよ。単なるデータの問題ではない。そこにプロセス的なイシュー(考え、論じるべきポイント)を見つけて、解決すべき課題をプロセス視点で見ていくんです。



 「何でこのデータが違っているんだろう」ということを突き詰めると、原価管理の在り方や、そもそもの利益の考え方が違っていたりする。そうしたら、「違っている部分の考え方を合わせていかないといけない」ことが分かる。



 例えば、「コードがきちんとそろっていない」ということは、“言葉の定義もそろっていない”ということになるけど、「データを合わせましょう」という議論をしたところで現場は喜ばないし、本気になってくれないんです。だから、“データを集めた上で使えないことを可視化して、イシューを見定めて解決する”――というように、“ダメさを可視化”した方が早い。



 最終的に目指すところは同じなのですが、あちこちに過去からのレガシーシステムがあるような製造業において、手段と目的が逆転せず、共通の目的に向かって進めていくための作戦の組み立て方は非常に重要ですね。



中野氏: それはとてもよく分かります。私もかつて、メーカーの情シスとして働いていたことがあって、当時、「まずはきちんとデータを合わせなきゃダメだろう」というスタンスでやっていたんです。けれど、これがとにかく進まないんですよね。データの大本である基幹系システムに手を入れることになって投資金額もリスクも大きい。



 そのときに、「これは、先にBIを何とかした方がいいかもしれない」と思ったんです。そこを可視化した上で、納得感を醸成する形にしないと、特に生産とかは動かないですよね。



●それは本当にビジネスを回すのに必要なデータなのか



友岡氏: データを集めた上でもう一つ議論が必要なのが「集めるデータが、本当に日々のビジネスを回す上で必要不可欠なデータなのか」ということですね。実はそうでもなかったりするものもあるんですよ。



中野氏: 惰性でやっていたり、昔からのプロセスだからやっていたり――というのは、確かにありますよね。「これは何に使うんだっけ」と思って調べてみると、実はあまり使われていなかったりする。



友岡氏: なぜ、「データを集めて、課題を炙り出す」という進め方を推奨するかというと、そこに活用する上でのリアリティーが浮き上がるからなんですね。情報が可視化されて初めて、本当の活用シーンや活用する人が分かるので、そこで初めてデータ活用のオーナーシップが生まれてくるんです。



 そこから先は本当に困っている人、社内を黙らせるだけの強い影響力を持った役員レベルの人をオーナーとして巻き込んで、「この人たちが問題だと言っているのだから、対応すべき」という社内への落とし方ですよね。



 「お金をかけてデータを集めたにもかかわらず、精度が悪いから……」と、文句を言う人もいますが、重要なのは、「“解決しなければならない問題”という課題化ができるかどうか」だと思うんです。前述のプロセスを経て出てきた課題は、“本質的に必要としているかどうか”といった点で、全然迫力が違うんですよね。



 そのあたりをしっかり見極めないと、「大変な思いをしてまで、誰のためにデータ統合をやっているのか」という議論になってしまいます。



中野氏: 「皆、なんとなく欲しいものがあるのだけど、実際に作ってみたら違っていた」ということになりがちなのが、BIの難しいところですよね。常に更新や変更があるという、かなり柔らかいシステム。“やってみるまで欲しかったものが分からない”ことが割とある。



 作ってみてから、「大体合っているけれど、ここは変えなきゃいけない」という修正が出てきたときには、組織としてどのように対応しているのですか。



・データを“使えるもの”にするためのアプローチ



友岡氏: 粒度が粗ければ粗いほど汎用性が高く活用する人が多いので、まずは活用度の高いところ(粒度の粗いところ)で、使えるレベルを目指すのが最初のフェーズだと思うんです。



 それがどこかというのは、活用する場面やシナリオを考えると見えてくる。例えば、役員会のような重要な意思決定をする場面において「こういう情報が、こういう粒度で、このタイミングにそろっていなければいけない」と分かったら、それは絶対にその要求に合わせなければならないけど、それ以上の精度は追う必要がない。



 そしてこのレベルをクリアしたら、そのとき出てくる「なぜ」に答えるために、もう一段詳細レベルにドリルダウンする。すると情報の精度が問われるので、もう一段、情報の精度を高めなければならない。さらにドリルダウンして3つ目の「なぜ」に答えられるレベルになると、全然違う要素のデータと突き合わせて見たい、という要望が出てくる。そうなると、さらに上のレベルの精度が必要になってくるんですね。



 活用のレベルが上がれば上がるほど精度が上がっていくので、最初から完璧を求めずに、まずは大きな意思決定を間違わないための「最低限の粒度でピチっと合うところまでをまず固める」ということですね。



中野氏: 抽象度が高くて、汎用性が高くて、かつ、確実に使うというもの――例えば、「財務諸表」に近いようなものや、メーカー担当者なら必ず見る「在庫数」といった“固いところ”を決めてから、徐々にディテールに降りていくような形ですか?



友岡氏: そうですね。ただ、おそらく実務で議論されるのは財務会計のレベルではなくて、管理会計の世界ですね。「原価を解析したい」とか、「市場をどのように見るか」といった、セグメンテーション別やルート別での見方ですよね。



 例えば流通チャネルが大きく3つあったら、3つそれぞれにちゃんとデータが分かれているよねとか、何とか全社レベルでその粒度を押さえて、まずそこで使える姿というか、横並びで全部使える状態を作る。一社でも情報が欠けると全部が使えないので、確実に全社がそろえられるレイヤーをしっかり作って、「このレイヤーは全部使える。よし、次の段階でこれは全部使えるようにしよう……」というように。



●BIのデザインは、経営の見方をデザインすること



中野氏: 上からそろえて徐々に詳細なデータに降りていく。キーマンと握りながら、詳細のデータやそれを作るプロセスを徐々に直していく。例えば「ここのコード体系を直さなきゃダメだよね」「これを見ると、こういったアクションがとれていいよね」みたいな会話をしながら直していくという流れになるのかなと。



 ちょうど今、クラウド型ERP(Workday)導入の真っ最中なのですが、ERPの最初の段階から完全にプロセスを最適化して生産性を最大化するのは難しいと思っていたのですよ。なにせ、一人情シス状態で組織もできてなかったので。最初に最優先事項として設定したのは「マスターの統合」と「データを1つのデータベースにまとめる」という2点だったんです。”Integration”がまず先。とにかく最初。次に”Productivity”だと。結果が”DataDriven”につながると。



 ここは順番が違うと、全く違う見え方になると思っています。



 1年半かけてクラウド型ERPへの刷新を進めたのですが、そこで出てきたのが「データ品質の問題」だったんです。外資系のERPは、意外とバリデーション(要件通りのデータ入力かどうか)が雑、という問題があるのですよね。その結果、ちゃんとデータが入ってこなかったり、入力ミスがあったりするんです。



 これをどうしようかと思ったのですが、入力のところで何とかしようとするだけでは不十分だと。それならば、出口であるBIというか、レポートのところでちゃんとデータを見せるようにすれば、たぶん自動的に「データが雑」であることが可視化される。そうすると、データも修正しやすくなるし、プロセスも改善されやすくなるのではないか――という考えに行き着いたんです。



 今までの友岡さんのお話を聞いていて、BIって実は、「最後に満を持して出てくるもの」ではなくて、「早い段階で差し込むと、それはそれで意味があるもの」なのかもしれないと思いました。



・BIのデザインは意思決定プロセスに沿った形で作られるべき



友岡氏: 情報システムは、「情報を活用するところに成果が現れる」わけですから、意思決定プロセスのデザインとすごく密接に関わるんですね。だからBIのデザインはまさに、意思決定プロセスに沿った形で作られるべきなんです。「企業としてどうありたいか」というところまで含めてデザインすべきで、実はそこにERPをやるメリットがあるんです。



中野氏: 私はERPは究極的にはBIなのだと思っています。つまりデータの有用性を買う。日本的なシステム導入をやっていると、データより業務効率化などのプロセスの最適化の方に目がいくんですけど、ERPの最大のポイントはたぶんそこではないと思うのですよね。



友岡氏: そうですね。ERPはデータ構造を買うんですよ。



中野氏: ERPに対する投資はよく「データベースにお金を払っている」といいますよね。データの大本になる部分に投資している。BI関係でいろいろな企業の担当者から話を聞くと、「BIを入れたものの、元になるデータがダメで、結局、業務システムまで直してデータをきれいにする羽目になった」という話を聞いたりしますね。最近では機械学習周りでも同じような話を聞きます。投入するデータがダメだったので機械学習を元にした予測なども精度が低くなってしまうとか……。結局、ごみを入れればごみが出てくるのかと。そりゃそうだ。世の中甘くない(笑)。



友岡氏: データベースに定義された構造というのがあって、それがきっちり定義されているからこそ、きちんと整った形で入ってくる――というんですかね。それが最大のメリットであり、その形は「管理会計を軸にしてどういう見方をしたいか」ということになる。



 BIのデザインとは、経営の見方をデザインすることになるので、「管理会計のビューをそもそもどうデザインしたいのか」ということになる。管理会計のビューから、BS/PLをどういうディメンジョンで細分化して見るか、という見方がまずあって、それに従って組織構造のデザインを行う。ここがERPの基本デザインで非常に重要なところです。



 しかも管理会計のデザインは、経理の実務を担当している人に任せたらだめなんです。決算書を作る財務会計の粒度では、ざっくり集約されてしまう。管理会計は、もっと粒度の細かいレベルのデータが必要なので、実際に売上や利益にコミットしている人たちが、「意思決定」プロセスと、そのための基礎情報としての「管理会計視点でのデータ構造」をしっかりデザインすることがとても重要です。



中野氏: 最近、よく聞くのは、経営層や意思決定者といった「データを見て判断する人たち」が、さほどデータに対するこだわりがなかったり、「こういうデータが見たい」という意思がなかったり、「そもそもデータを見て話をしない」、といったケースが往々にしてある――ということなんですね。そういった問題は今までありましたか?



友岡氏: それも当然、ありますよね。例えば、「在庫がどうこうではなく、これだけ作って売ると決めたら最後まで売り切る」というようなビジネスをやっていたとしたら、「根性で売り切れ!」となるでしょう。とはいうものの、「本当に売り切ることができるのか」という点はきっと気になると思うんですよ。人によってストーリーの組み立て方は変わりますが、BIの構造としてはそこは特に意識しなくてもいいんじゃないかと思うんですよ。



●データドリブンな文化を創るために情報システム部門がすべきこと



中野氏: クックパッドでは、ようやくシステム統合のめどが立ってきて、次のステップである「どうやってデータドリブンな組織にしていくか」を考え始めています。



 基幹系システムにデータをちゃんと投入し、品質の担保をするためには、多額のコストがかかりますから、今度はそれに見合った分、データを使えるようにしなければならない。そこでまず、国内と海外合わせてDWHとBIを統一しました。ここだけ話すと、「ツールから入る」という、ものすごくダメなパターンのように見えてしまいますが……(笑)。



 理由はいろいろとあって、サービス側と社内システムで同じものを使うべく、まずはプラットフォームを統一しようということです。BIはTableau、DWHはAmazon Redshiftに統一しました。国内と海外、サービス側と社内側を統一する。放っておくと野良BIが大量に発生するので先手を打つ。



 同じデータソースを元に、同じ見え方で見ることができるようにすることが重要で、データが散らかるのは避けたい。「データドリブン」っていうと大上段ですが、「まずはとにかく” Single Source of Truth”をなんとか頑張るぞ」というレベルです。



 取りあえず器はそろえたので、それをどう使うかが、今のテーマですね。これまでデータに基づいた判断があまり行われてこなかった分野もあるわけで、これからどうやってデータに基づく判断ができるよう展開していけばいいのかを、考えていかなければならないのです。



・データに基づく判断ができるようになるためにすべきことは



友岡氏: 何をもって経営が評価されるのかという、「大きな意味での評価軸」ってありますよね。経営成果や部門の成果というような。それを実現するために最低限必要なKPIを考えると、売上や利益、シェア、ビュー、顧客数などがある。ものすごく粗いレベルでいうと、そこをリアルタイムで見えるようにするのが最初だと思うんですよ。



 その上で僕はさっき中野さんが言っていた「野良BI」というのが、実はキーポイントだと思っているんです。野良の状態でまで分析しようという人は、優れた感覚で分析していることが多く、その知見が実はExcelの中に眠っていたりする。それを属人化せず公開すればいいんですよ。「野良BIのオープンソース化」みたいな世界にして、みんなで使えるようにすればいい。



中野氏: まずはいったん、個別に行われてきたレポートを回収して、標準化したプラットフォームに戻す、ということですね。確かに“野良”とはいえ、現場で必要だからExcelなりで頑張って作ったものであって、必要性がないところにそんなものは存在しないですよね。



友岡氏: そうなんですよ。因果関係の薄いところから関係性を見いだせる人っているんですよね。そういうセンスがある人がオーナーシップを持ってビューを作って、そのビューを他の人でも使える形にした方がいい。情報システム部門がお仕着せでやるよりは、利用者がどんどんそういったものを作って公開できる環境を用意して、互いに評価しながら誰もが活用できるようにすることが大事だと思いますね。



中野氏: 組織のヒエラルキーにおいて上の方で行われるデータによる判断は、戦略的に明快かつシンプルにバシッと決めないと、組織全体がブレると思うのです。ただ、経営レベルで追うべき指標ってそんなにたくさんあるわけではないし、もしあったとしてもそんなに複雑なものは機能しない。抽象度も高いから、可能な限り決まったものをシンプルに継続的に追っていけることが必要だと思います。毎回変わったらブレちゃう。柔軟性よりも、「同じものを定点観測して変化に気付ける」ことの方が重要だと思うのです。



 一方で、現場に近い裾野のあたりは、多分、もっとボトムアップで追っていくべきで、担当者が業務の中でより詳細のデータを日々試行錯誤して使えるようにする必要がある。小回りが利くようにすることが必要なのだと思います。それを追っていくことで出た知見や成功事案を横に展開していくような。だから、われわれは、とにかく必要な情報をデータソースとして利用できるようにすることを目指しています。それこそ、データ利用に対してセンスがある人に武器を渡したい。



友岡氏: 情報部門やBIの管理者は、実際の成功事例を見つけて紹介したり、ストーリーを発信したりする方がいいと思いますね。ただ、「こういうのを作りました」といっても、誰も興味を示さないですが、「こんな解析方法でこのような見方をすれば、これだけKPIが向上します」という説明なら聞くんですよ。



 BIの議論を進めるとバランスドスコアカードや戦略マップ的な世界に入っていって、「じゃあ財務的な成果に結び付くプロセス面のKPIって何でしょう」みたいなまとめ方になって、戦略ストーリーにおける、因果関係をきれいに作った上で、それぞれがKPIを持ち、それがBIにリストされるというのが、おそらく教科書的な進め方ですよね。一番きれいな世界だと思うんですよ。でも、現実はなかなかそうはいかないですね。



中野氏: 戦略レベルはともかくとして、戦術レベルまできれいに落としていくのはけっこう厳しいですよね。上から下へ、上流から下流へきれいにブレークダウンできるのが理想ではありますが、なかなかそうはいかない。



・大事なのは「データの民主化」



友岡氏: 加えて、その時々で市場の状況も競合の状況も変わりますよね。そんな中で、トレンドを読んでストーリーを組み立てて仮説を立てるのは、そのど真ん中でビジネスをやってる人にしかできない。事業の中心にいる人に、こうしたデータを扱えるプラットフォームを提供して、ユーザビリティや動作のサクサク感を徹底的に研ぎ澄ますところを一生懸命やってあげるのが、情シスの仕事じゃないかと思うんですよ。



 最近では、データアナリストとまではいかないまでも、大学でBIを学んで入社してくる人もいますよね。現状では、そういった方々には申し訳ないような貧弱なIT基盤だったりするわけですが、その中でどれだけ使いやすいプラットフォームを提供できるかも重要だと思うんです。



 結局、大事なのは「データの民主化」なんですね。データを閉じ込めないことです。



中野氏: 大切なのはデータをとにかくオープンにすることだと思います。Webサービス業界は、「隠す理由がない情報はオープンにする」という風潮があって、クックパッドも基本的にはそうしてきました。今後はそれを社内システムにあるデータでもやろうとしていて、本当に外に出たらまずい情報以外は全部DWHに入れて、権限も全員にオープンにして全て見えるようにしたいと考えています。そのためにBIもそろえたので。



友岡氏: それは素晴らしいですね。そう考えるとやっぱりITって、進めるべきは「民主化」なんですよ、社内の民主化。できるだけ組織をフラットにして、情報に対するアクセスを全ての人に平等にすることが大事ですね。



 ジャック・ウェルチ(米国の実業家。元GEの最高経営責任者)が言っていましたが、ほとんどの企業の「意思決定」は“量的な意思決定”で、正しい情報をみんなに与えれば、ほぼほぼ意思決定の結論は似てくるんだと。だから情報共有は徹底的に進めていかなければいけないという趣旨で、僕はすごくそれに共感するんですよ。



 戦略的な意思決定は大きく分かれることがあったとしても、オペレーションレイヤーの戦術面での意思決定というのは、正しい情報さえ与えればそんなに人によって変わることはない。



・データを活用する上で重要な2つのポイント



中野氏: 同じデータを同じように提供すれば、戦術レベルであれば落としどころは大体近くなるんじゃないかと思います。



 データを巡る話には必要なことが2つあると思うのです。一つは正しい正確な情報がちゃんとオープンにされていて、利用できる状態にあること。もう一つは、それを活用できる人材の質や組織文化を確保すること。ここの2つにフォーカスしていれば、たぶん結果は出てくるんじゃないかなと思っています。ちょっと楽観的かもしれませんが。



 この2つの要素のどっちかが欠けていると、データを活用がうまくいかないのではないかと思うのです。一時的にうまくいっても、継続的な改善は難しかったりする。Webサービス企業は、スピードを出せるかどうかが大きなテーマなので、より現場側で重要な意思決定を素早くできるようにするための環境が必要になる。それはつまり、経営と現場の情報格差をなくし、より現場レベルで重要な決定ができることだと思っています。今、手掛けている「データを使えるようにする取り組み」は、そのための重要な下ごしらえなのです。



【次回に続く】


    あなたにおすすめ

    ランキングIT・インターネット

    前日のランキングへ

    ニュース設定