2018年12月4日に開催されたCTO meetupで、「データドリブン×オープンイノベーション」をテーマとしたパネルディスカッションが行われました。膨大なデータをどう抽出し、どう活用すればいいのか。そして、デードリブンがどのようなオープンイノベーションにつながるのか。規模を問わず各企業のCTOやリードエンジニアを招き、エンジニア、プロダクト、そして企業においてデータドリブンがどうあるべきか、たっぷりと語っていただきました。

【ご登壇者】 ●THECOO株式会社 執行役員 Product Manager 星川 隼一 氏 ●株式会社Hacobu　執行役員 高橋 道幸　氏 ●株式会社リブセンス 不動産ユニット IESHILディベロップメントグループリーダー 竹馬 力　氏 ●弊社FLEXYご登録専門家 本間美香　氏

【モデレーター】 株式会社マクアケ 執行役員 CTO 生内 洋平　氏

登壇者のご紹介

異業種、異分野で大量のデータを取り扱う最先端のエンジニアたち

生内：株式会社マクアケでCTOをしております、生内です。もともとはミュージシャンで、バンドのホームページを綺麗に作りたいという思いからデザイナーになり、インタラクティブなどにも興味を持つうちに自動的にエンジニアになっていた、という経歴です。以前はKDDIグループのSupership HDというアドテクの会社に所属していましたが、去年からマクアケに参入しました。マクアケは国内最大のクラウドファウンディングサイトMakuakeを運営していて、現在急成長している会社です。本日はどうぞよろしくお願いします。

星川：THECOO株式会社で「fanicon（ファニコン）」という、SNS的な会員制ファンコミュニティアプリのプロダクトマネージャーを務めています、星川です。「fanicon」はサービスも徐々に拡大して、現在エンタメランキングのトップ４にランクインするレベルになってきています。 僕自身のキャリアとしては、2011年にGoogleに新卒入社してデータ分析系の仕事をこなしていました。BigQueryを活用して検索やGoogle playのデータ分析を行い、それをセールスマーケティングに活かしたり、エンジニアにパスしてさらに解析してもらうといった業務内容です。その後、THEBOOに参入しました。今日のテーマに合ったお話ができるかはわかりませんが、どうぞよろしくお願いします。

高橋：株式会社Hacobuの高橋です。本日はどうぞよろしくお願いいたします。出身は北海道で、高卒エンジニアです。この業界には36年ほど携わっています。大型汎用機をはじめ、UXやハードなど、さまざまな事業に関わってきました。 Androidが出始めてからは教育関係事業の立ち上げに伴って講師を務め、通算200名以上技術者を排出しました。その後通信キャリアのモバイルネットワーク開発に参入し、大量のグラフィックをさばくためのシステムに携わりました。OSの構築・実装も経験しています。注目している技術はブロックチェーン系で、当社の開発しているサービスに取り入れることができないかどうか、研究を始めている状況です。

竹馬：竹馬と申します。大学時代に上京し、ベンチャー企業に就職しました。７年間のフリーランスを経て、前職のビルコム株式会社ではCTO兼開発マネージャーを務めています。株式会社リブセンスには5年ほど前に入社しました。現職では2015年に「IESHIL（イエシル）」という不動産価格査定サイトの立ち上げを経験しています。「IESHIL」は、機械学習で中古マンションの価格査定をして、結果をWebサイトに掲載して集客するというビジネスモデルのサービスです。立ち上げ期からシステム全体を見ており、開発においてはデータエンジニアとしてビッグデータをどう整形するのか、という部分を中心に進めています。その一方でローンチから３年経過したこともあり、どちらかといえば組織づくりに注力している状態です。副業的にCodeZineというメディアでRuby on Railsの連載をしたり、技術顧問としても活動しています。 不動産業界はFAX、電話文化が根強く残っていて、まったくIT化が進んでいないため「IESHIL」の立ち上げは非常に難航しました。Real Estate Tech（不動産テック）が叫ばれてはいますが、果たしてどんなTechでどのように勝負するのかが重要だと痛感していますね。そんな中で最近は「ビッグデータを上手に扱う仕組み」をきちんと作れるデータエンジニアの需要が非常に高まっていると思っています。

本間：本間と申します。リクルートホールディングスのリクルートテクノロジーズという会社に所属しています。入社は2012年です。リクルートテクノロジーズはホールディングスのさまざまな事業会社のエンジニアに対して、あらゆる形で技術提供をしてビジネスを加速させるという役割を担っています。私はUXを主担当として参画している形です。 １つの領域に特化するというよりは、複数領域に対してUXという武器によってビジネスを加速させる役割を担っているので、現在担当しているプロダクトはアルバイトのタウンワークや、転職権、派遣系、さらにブライダルなどさまざまです。 仕事を進める中で課題に感じているのは、UXのエンジニアにそもそもデータを見るという習慣が徹底されていないということです。そこでUXブートキャンプというコンテンツを社内に作り、新卒・中途入社の方々のベーススキルとして「データを見ながら企画をつくる」という考え方や行動の仕方を教えるという役割も担っています。

生内：ありがとうございます。どうぞよろしくお願いします！

あなたの会社のデータドリブンについて

事業をグロースさせるため、データに基づいたKPIを設定するのは重要か？

生内：ではまず、「あなたの会社のデータドリブン」という視点で、みなさんがどのように事業を進めているかお話しいただけますでしょうか。

星川：当社は40人規模の組織ですが、他社と一番違うところはできるだけGoogleのサービスを利用している点です。サーバはすべてGCPで、Excelなども使わずGoogle Docsです。これの一番の利点は、BigQueryへの反映が非常に簡単だということですね。データエンジニア的役割は、Googleが担ってくれるという認識です。集まったデータは社内の誰でもアクセス可能で、SQLさえ書ければいろんな人が分析できる社内環境になっています。

生内：プロダクトをドライブさせる要素として具体的なKIPなどはあるのでしょうか？

星川：「fanicon」は月額500円のサービスですが、当然一ヶ月加入してもらっただけではペイしませんから、どれだけ続けてもらえるかは当然重要です。また、サブスクリプション業界にはquick ratio（当座比率）というものがあり、これはサブスクリプションモデルの健康度合いを示す数字です。分母に今月退会する人の数、分子に新規入会者を置き、1.1を超えるとサービスは加速度的に伸びていくとされています。例えば今月100人やめても120人入ってくれば、クイックレシオは1.2です。 僕自身、KPI自体は「どうすれば伸びる」という答えがあるというよりは完全にビジネスモデルに依存するものだと思っているので、逆にKPIが重要であるという話があれば聞いてみたいです。

高橋：KPIへのこだわりはさほど無いですね。ただ、ビジネス向けのサービスを扱っている分、いかに顧客を逃さないようにするか、という部分には非常に注力しています。新しい仕組みを入れては分析する、ということを日々繰り返している状態です。

生内：リクルートさんはプログラミングでもかなりデータを見る会社というイメージが強いのですが、本間さんはいかがでしょうか。

本間：おっしゃるとおりリクルートはとにかくデータを見る習慣があり、モニタリングフォーマットも非常に細かいです。とあるサービスの集客の状況をモニタリングするシートの場合はA３表裏全２Pで、チャネルごとにKPIが細かく決まっています。それに対して何％成功したのかをモニタリングして、その理由を週次報告するサイクルです。問題があれば改善計画を立てますし、数字をどう見るのかという点についてはかなり魂を込めて徹底している会社です。

生内：重箱の隅をつつく勢いで、0.1％の伸びを積み上げていきますよね。

竹馬：当社もKPIを比較的重視する文化です。事業の数値が予測から乖離しないように、細部までチェックしますが、エンジニア目線で言うと正直「そこまでKPIが重要だろうか」と感じる場合はありますね。実際、当初採用していたKPIを追うのをやめて、OKRを導入した他社事例も増えています。なぜKPIを設定するのか、KPIの先に何があるのか、プロダクトが実現したいビジョンに対してKPIの目線が合っていないと、テクニカルな部分だけに走ってしまい、最終目的地を見失ってしまいがちです。

生内：当社にはシリコンバレーのCOOだったメキシコ人が在籍しているのですが、その人が言うには、「こうすれば事業が伸びるはずだ」という空気が会社にあふれているうちはデータを見なくていいそうです。もし迷ったらデータを見る。これに関しては、僕もそのとおりだなと思います。

竹馬：「IESHIL」の立ち上げ時は10名以下のコンパクトな組織で意見も比較的まとまりやすかったですし、エンジニアはできるだけコードを書く仕事に専念した方が効率がいい、というのは実感しました。 リーンスタートアップが流行った際はA/Bテストをやった方がいい、いろんな数値を見よう、という風潮がありましたが、情熱を持って「やろう！」と全員が一致団結できたら、数値はそれほど重視せず突き進んだ方が成長への近道だという実感があります。

高橋：僕は逆ですね。うちも規模が小さい頃は開発優先で、データは見ない、とにかく動くんだ、という気持ちで進めましたが、正直、データをきちんと見ておけばよかったと思うことがたびたびあります。作ることを優先した結果、システム全体としては２，３回作り直す状況が起きていて、やっと形になってきたところです。何が重要で何が重要ではないのかを見分けることが大事だと思います。

不動産、物流――IT化が進んでいない領域におけるデータドリブンの在り方

生内：「IESHIL」はそもそも「価格診断をデータに基づいて行う」という文脈のプロダクトで、データドリブンそのものだと思いますが、実際のところはいかがですか？

竹馬：不動産はIT化が十分には進んでいない領域で、なおかつ情報の非対称性の塊のようなものです。ネット上に価格を勝手に乗せるとはなにごとだ、誰に断って価格を決めているのだ、とクレームが出る。内心、「我々はこの情報の非対称性があるから儲かっているのだ」と思っている方も少なくないと思います。インターネットでイノベーションを起こしていこうとしている側と、従来の価値観で働いている側では、価格をネットに乗せるということ自体が、今までの常識からは考えられないことなのです。 その中でデータを入手するのは非常に大変で、webクローリングくらいしか手法がない。不動産会社に詳しい方はご存知だと思いますが、「REINS」という業者間しか見られない流通システムがあり、そもそも情報が一般消費者に開放されていません。そういった既存の仕組みを変えていかなければならないという根本の部分から、苦労しています。「IESHIL」をリリースした頃は、国土交通省や総務省、内閣府などに足を運んだりもしました。

生内：高橋さんは物流系のサービスを手がけていらっしゃいますが、いかがですか？

高橋：Hacobuでは陸上運送に関わるサービスを提供しており、トラックの調達や車両の現在地、倉庫の管理業務などを行っています。ただ、これらの業務は物流の動きそのもののデータを取るための入り口に過ぎませんし、サービスも完成形ではありません。我々は管理によって得られるデータをもとに、共同配送をはじめとしたより効率の良い配送ができるようになると確信しているので、現在はそのためのデータの蓄積を行っているんです。最終的には物流業界全体のプラットフォーマーとして機能することを目指しています。集めたデータは専有せず、広く業界の方に使っていただく。集めたデータを加工してどう表現するかは、当社以外にも力やアイデアのある会社さんにお任せするつもりです。

生内：プロダクトをグロースさせるためにデータドリブンをしていくというケースもあれば、データドリブンそのものをサービスとして提供する例もあるということですね。不動産業界のように、これまでITが入り込めなかった業界に対してアプローチをする際に気をつけていることはありますか？

高橋：物流系の企業もアナログ作業が非常に多い上、職人気質の方もいらっしゃいます。データ化やシステム導入をしましょうとご提案すると、自分の仕事が奪われるのではという危機感を感じで、導入していただけないことがあるんです。ただ、人の技術と違いデータだからこそ他社の成功事例をそのままコピーできて、自社にとって有益になるんですよ、という話をすると比較的抵抗なく受け入れてもらえるという話があり、その点は僕自身も実感しています。

生内：ナレッジシェアのような考え方ですね。実際に取得した物流データをどうハンドリングされているのかお伺いしたいのですが、エンジニア組織や環境はどのような体制なのでしょうか？

高橋：技術者が10名、QAエンジニアが12名。データ専門のエンジニアはいないので、今から採用しようとしています。プラットフォームに利用しているのはAWSです。

生内：「IESHIL」はいかがでしょうか。

竹馬：立ち上げは機械学習のモデリング担当が1名、webアプリケーション開発担当が1名、全体管理が1名の計3名でスタートしました。着手から2ヶ月半の突貫で作りましたね。最近は7名体制です。 ビッグデータ活用にTreasure Dataを活用しており、技術的にはDigdagやEmbulkを使っています。不動産業界はデータの不正確性が原因で名寄せが非常に大変です。機械学習は前処理が9割と言われますが、本当に手間暇がかかります。データエンジニアは、Embulkのプラグインを使って複雑な処理を記述することも少なくありません。みなさんが見たらびっくりするようなSQLもあります。かなり泥臭い業務ともいえます。

０→１か、１→100か。プロダクトのステージでデータを用いるかどうか見極めが必要

生内：本間さんにお伺いしたいのですが、実際にデータを集めてきてデザインに活かせる状態にする、それをユーザー体験にまで落とし込むというプロセスについて、気をつけるべきポイントはあるのでしょうか？

本間：データとUXの関係性は、「風が吹く桶屋が儲かる」のようなものだと思っている部分はあります。データを取って見えるのは、「桶が何個売れたか」という瞬間を切り取ったものですが、なぜその状態になっているのか、どういうカスタマーがどういう心境でサービスを利用しているのかは、想像力を膨らませなければいけません。イメージをもとに課題や仮説を立てていき、その内容の正誤は「このデータを見ればわかるのではないか」と予測し、またデータを取りにいく。この繰り返しによって風と桶の関係性の解像度を上げていく作業を仕事として行っているのだと思います。 そのときに、そもそもデータが取れていない、あるいはカラムはあっても正しく入力されていない、一部分しかない、間違った形で入っている、というケースが多々あります。そこを正しい状態に直していくために労力がかかるんですね。一目瞭然でわかるようなデータ設計をしているサービスは本当にすごいと思います。

星川：当社はリクルートさんのようにレポートを提出したり、風と桶の関係を説明する文化はなく、プロダクトが大きくなるという結果のみが必要とされます。そこに対するアプローチとしてデータを用いるのか、風を感性で掴むのかは時々によって変わりますね。

本間：ただ、リクルートがデータばかり見ているかというとそうではないんです。プロダクトを０→１で立ち上げるのか、１→100にグロースさせるのかというタイミングによって、全くアプローチが違います。1から100にしようというフェーズでは細かく数字を見て仕事をするケースが多い。0から1の段階で数字がどうこう言っていたら、ビジョンから全くズレたものが出来上がってしまうので、ビジョン先行で開発すべきだと思っています。

竹馬：「IESHIL」がようやくマネタイズできるようになってきた状態で、0→1と1→10が混在しているフェーズですね。ですからKPI的なものを設置して数字を上げる方法も有効ですし、逆に0→1で作る機能に関して数字はそれほど重視しないこともある、といったように使い分けています。

生内：プロダクトがどの段階にあるのかを見定めて、身の丈に合ったデータドリブンを目指すのが大切なのかなと思いました。では、次のテーマにいきたいと思います。

後編に続きます＞＞