この記事は、THE GUILD勉強会#3「データ×UXデザイン」の 第１部で登壇された、鈴木さん（日本経済新聞社）の講演内容のレポートです。
実際に使われたスライドはこちら↓

では講演内容です。

創業140年の古い会社でデータの民主化を進めた話

多くの人が思っている以上に歴史のある日本経済新聞社。

2009年ごろから鈴木さんが企画開発として関わる日経電子版は、月額4200円という高めの値段設定ながら、多くの人に利用されています。

日経電子版の開発業務の中には、アプリ開発や、webブラウザアプリの開発などが含まれています。

その他コンテンツ開発もしています。データ・デザイン・技術を合わせて見せるデータビジュアライゼーションのwebサイトは有名ですね。

日経電子版ではエンジニア、デザイナー、データサイエンティスト、ビジネス企画などの人が働いています。

2015年にFTというイギリスの会社を買収しました。データを使うということに関して、世界の新聞社の中でも特に進んでいる企業です。

今社内のデータサイエンティストがイギリスで勉強しており、ここで得られた技術を社内に注入しようとしています。

日経電子版以前は、新聞社と読者の間には新聞販売店があるという構造になっていました。

極論ではありますが、新聞社が直接読者とやりとりをしないので、誰が読者なのか全くわかりませんでした。お客さんの名簿は新聞販売店にとっては大事なデータなので、新聞社には教えてくれません。この状態が130年間続いていました。

2010年に日経電子版が始まり、クレジットカード決済の直接取引に変わりました。そうして、漸くどんな人（年齢、性別、職業など）が読んでいるかが分かるようになりました。

それによってはじめて、お客さんがどんな記事を読んでいるのかが分かる土台ができ始めました。

今だと平日１日のデータは１億レコード程あります。実際のPVはこの１０分の１くらいですが、ボタンのクリックやスクロール位置など、細かいところまで追っているため、このくらいのデータ量になります。

この１、２年、社内では、読者の過去２０日間の利用傾向を元に算出されるエンゲージメント指標を追うようになりました。これが高いほど読者が解約しにくいいという相関関係がわかっています。

エンゲージメントレベルは５段階に分かれており、このカテゴリごとに施策が変わってきます。

日経電子版は、ありがたいことにSuper LoyalとLoyalで過半数を占めており、かなり優良なお客さんが多いという特徴があります。
一方で残りの数十％の人は解約し易いため、この人たちに対して重点的に施策を打っていくことが重要です。

最近は色んなデータの要件が出てきたため、新しい内製のデータプラットフォームを構築しています。

ここに溜まったデータをRedashで可視化したり、Elasticsearchに入れてKibanaで見るといったことをしています。

ここまでは、データを扱う点において遅れていた新聞社が活用を始めることができ、システムも構築できて良かったねという話だったと思います。

本題はここからで、データを扱える人を増やし、データサイエンティストだけではなく各現場の人が分析できるようになるための施策の話になります。

色んな社内のツールであることだと思いますが、立派なツールを作りました！と発表しても、使い方がわからなかったりして、結局誰も触ってくれないことが往往にして発生します。

そのような状況を打破するために、去年から始めたのが「データ道場」です。

データ道場では、3ヶ月に渡ってデータ分析のノウハウを身につけるためのトレーニングを受けます。毎週３時間/１日で宿題が出ることもあります。

中身をもう少しのぞいてみましょう。

データ道場の対象はエンジニアではなくビジネス企画やデザイナーで、カリキュラムの始めにはまずSQLの書き方を学びます。

SQLを3週間くらいで学んだあと、PDCAサイクルをどうやって回せばいいのか、グループのメンバーによってカスタマイズされた内容を学びます。

PDCAサイクルを回す時に重要だと思っていることは以下だと鈴木さんは考えています。

上からよくわからないアイデアが降ってくることもありますが、それがビジネス上のゴールに結びついているか？ゴールに結びついているKPIを設定しそれをきちんと追っているか？などの基本的な姿勢が、施策を回す上では重要です。

施策の中止条件も結構重要で、ネガティブなことが発生した時どうするかということを予め準備しておく必要があります。
またABテストのサンプルサイズを決めることもトレーニングの中でやりました。R（プログラミング言語）のコマンドで簡単に出すことができます。
また、施策をやる前に、どのくらいのインパクトがあるのか試算しておくことも大事です。

次にダッシュボードを見てみましょう。レコメンドエンジンを作って、既存のものとどう差があるかについてトラッキングしています。

グラフ上の緑の線が元々のシステムで、ここから新しいレコメンドエンジンの方が安定して勝っているね、といったことが分かります。

前のスライドでも触れましたが、施策をする前にインパクトを考えることは重要です。色んな企業がやっている、一見良さそうな施策でも、別にそんなに効果がないこともあります。施策の実施前に１度シミュレーションしてみましょう。
特にキャンペーン系で直接経費がかかるものは、得られる効果よりも経費の負担の方が大きい場合があります。

一つ、UIを変えてクリック率を４倍にあげた事例の紹介です。

これは連載記事の記事下にその連載の前後の記事を置くようにしたものです。そもそも、記事下までユーザーがスクロールしているのかというデータが取っていませんでした。そこで担当者がデータを取りましょうと声をあげ、そのデータを活用して考えた施策です。

今までやったデータ道場カリキュラムのまとめです。

このおかげで、社員3000人のうち200人くらいが少なくともRedashには登録しており、SQLチョットワカルくらいにはなっているはずです。

まとめです。どうしてデータサイエンティスト以外の社員もデータを扱えるようになる必要があるのでしょうか。

１つは、データ分析には思っているよりコストが高く、それを全部データサイエンティストに任せるよりも、現場が手を動かした方がコストがかかりません。

また、分析をするようになって初めて、分析するのに本当に必要なデータに気づきます。これを現場担当者が知っていることで、開発フェーズに有効なログ取得を組み込むことができます。

実際には道半ばで、より多くの施策に取り組んでいかなければなりません。その時、たくさんの人が同じレベルのデータを見る能力を持っていると、一段高いレベルで話せるようになります。これに関しては、実際にやってよかったなと思っているし、今後も続けていきたいです。