THE GUILD勉強会#3「データ×UXデザイン」 参加レポート
この記事は、2018年8月23日に行われたTHE GUILD勉強会#3「データ×UXデザイン」に関するレポートです。
登壇された方は以下の通り
山田智久さん（アドビシステムズ株式会社）
大竹雅登さん（dely株式会社）
鈴木陽介さん（日本経済新聞社）
安藤剛さん（THE GUILD）
今回の勉強会は大きく分けて２部構成になっており、前半は「データ×UXデザイン」と言うテーマに沿って登壇者の方それぞれにお話いただきました。後半では、当日予定が入ってしまった深津貴之さん（THE GUILD）に代わり、こばかなさん（THE GUILD）モデレータのもと、パネルディスカッションが行われました。
第１部：登壇者の方の講演
まず初めはdelyの大竹さん。
タイトルは「認知バイアスを回避するためのアイデア検証プロセス」
Design in Tech Reportを引用して、デザイナーも売上などの数値に直接コミットするためにデータを扱えるようになるべきだと始まり、delyにおけるデータを用いたサービス改善プロセスについてお話いただきました。
delyでは、改善プロセスにおいて大きく２つのことが重要だと考えられているそうです。
１つは定量データから課題となる事実を発見→原因仮説をくまなく考える→解決案を他社事例やデザイン原則に倣って組み立てる。そして、それらをきちんと整理した上で、アイデアの検証を始めること。
もう１つは、実装計画を立てる前に、プロトタイプを用いて定性評価であるユーザーテストを行い、アイデアの検証をすること。
このようなプロセスを踏むことで、間違ったデータの扱い方をせずに、スピード感持って確度の高いアイデアをサービスに組み込むことができるそうです。
詳しくはこちらをどうぞ。
次にアドビシステムズの山田さん。
タイトルは「UX/UIを高度に改善！AIを有効活用するためのポイント」
Experience Cloudというデジタルマーケティングの分析から施策実行までの領域で、コンサルタントをされている山田さん。
AI（ここでは機械学習を用いた分析・最適化手法を指す）を用いて、改善プロセスを回す際のポイントについてのお話でした。
この改善プロセスの中で１番大事なことは、AIはあくまで「手段」であり、AIの機能を使う前にその使い方のイメージを描けなければ効果は出ない、ということです。
ポイントは大きく３つ。
1つ目は、改善プロセス全てにおいてではなく、指標の分析と施策の実施のみにAIを用いること。
2つ目は、予め改善目的をブレイクダウンして、ユーザーアクションベースの計測できる指標に落とし込むこと。これを言語化しておくことでAIの使い所がわかりやすくなります。
３つ目は、AIを用いて行いたいのは指標の分析なのか施策の実行なのかをはっきりさせること。それぞれに対応した機能が複数あるため、何をしたいのかがわからないと適切なツールを使うことができません。
またヘルプガイドサイトを例にして、改善プロセスをどう回すのか、具体的にご説明いただきました。
詳しくはこちらをどうぞ。
次にTHE GUILDの安藤さん。
タイトルは「デザインとコミュニケーションで改善するデータのUX」
データとデザインの領域でご活躍されている安藤さん。
様々な企業とお話される中で、データ分析はしているけど、社内全体を巻き込んでの効果的なデータの活用ができていないのでは？という疑問を持たれたそうです。
データに関する社員同士のコミュニケーションは非常に重要です。なぜかというと、データ分析に重要な現場の意見が集まる、データを活用する人が増えるほど社員の企業の動きに対するピントが合っていき意思決定の精度が上がるから、とおっしゃられていました。
そして、社内でのデータに関するコミュニケーションを促進するための、２つのポイントをご説明いただきました。
１つ目は、データを図示する際には何を伝えたいのかが明確で、かつ見栄えも良くすること。そのようなグラフの方が、単純な棒グラフより人の目を引き、さらに理解し易いという研究結果があります。
２つ目は、データ分析をし始めたばかりの企業はむやみやたらと複雑なダッシュボードを作る必要はなく、まずデータを介したコミュニケーションをどう増やすかということに焦点を当てるべき。noteの分析チームでslackをダッシュボードがわりにしている事例をご紹介いただきました。
詳しくはこちらをどうぞ。
最後に日本経済新聞社の鈴木さん。
タイトルは「創業140年の古い会社でデータの民主化を進めた話」
創業140年（！）の歴史の長い新聞社でデータの活用を推進されてきた鈴木さん。
日経電子版に移行したタイミングから、データの活用推進とその基盤の内製が始まりました。
データ基盤や、可視化ツールを整えても社内の人が使ってくれないと意味がありません。
日経では去年から「データ道場」と呼ばれる、SQLの書き方からデータ分析を用いたPDCAサイクルの回し方を学べるカリキュラムを開始したそうです。
対象はエンジニアよりもマーケティング企画やデザイナー。これのおかげで社員3000人のうち200人程度がSQLチョットワカルくらいまでになりました。
データサイエンティスト以外の人たちがデータを見れるようになることには、次のような利点があると、お話されていました。
１つ目は、意外とコストの高いデータ分析を現場の人がすることで、より広い範囲でデータ分析を用いたPDCAを回すことができる。
２つ目は、実際に自分で分析をして初めて、どのデータが分析に本当に必要なのかがわかるようになります。現場の人が理解していることで、開発プロセスにより簡単に組み込めるようになります。
そして何より、データに関する知識レベルが同じ人と話すことで、事業に関して一段高いレベルで話せるようになったそうです。今後の社内全体の知識レベルを底上げしていこうとしているそうです。
詳しくはこちらをどうぞ。
第２部：パネルディスカッション
事前に用意された質問や、会場/twitterからの質問に対して、登壇者の方が答えていくと言うスタイルで進みました。
質問１：データとの出会い、きっかけは？
（鈴木さん）最初会社に入った時は編集者で、日々webのページビューを気にしていました。2001年とか2002年とかは、PV10万とかいったら、おー頑張ったなみたいな感じでした。
でも、その頃から検索のボットやクローラーみたいなものが流行りだして、実際の3倍くらいアクセスログが出たりして。これはどう見たらいいんだみたいな、驚いたりもしました。
（安藤さん）私はキャリアの始まりはエンジニアでした。
検索エンジンを開発していたこともあり、例えばとあるメーカーの社内の文書を全部インデックスして、0.01sで検索結果を返すためにはどのくらいのスペックが必要か、みたいなマシンのパフォーマンス計算をしていました。
パフォーマンスが出ないとき、パフォーマンスチューニングのためにボトルネックを発見しないといけないんです。そのためにログを仕込みまくって、当たりをつけてボトルネックを見つける。次にはそこの改善施策を回すんですけど、そのプロセスって今やってるグロースハックと似ていてですね。
チューニングってすごく地味な作業なんですね。ただ同時の僕はそれが好きで、延々とやっていました。
（こばかなさん）データ見るのが趣味みたいにおっしゃっていましたね。
（安藤さん）素養があったんでしょうね笑
（大竹さん）delyがクラシルを始めたのが2016年の2月でアプリを出したのが5月なんですけど、とにかくレシピ動画サービスの中で一番伸ばしたかった。
じゃあどうすれば日本で一番伸びるサービスを作れるか、という時に先人の知恵を借りるのが一番だろうと思い、伸びてるサービスを作ったことがある人にアドバイスを貰いにいったんですよ。その時は、メルカリとグノシーの人に聞きに行きました。
それで、グノシーの松本さんって方に、どうやって伸ばしましたか、どうすれば伸びると思いますか？って聞いたら、「今データ取ってるの？」って言われたんですね。
その時はGAでDAUくらいは見てます、みたいな程度で。
もっと細かくデータを見て、どういう風にユーザーが行動しているのかを知らないと、改善するにも道が見えないよね。それって目隠しして走ってるみたいなものだから、それで伸びるのはありえないよねって言われました。
それがきっかけで、すぐに自社のデータ基盤を作って細かく見えるようにしました。
もちろん自分でそれを作ったので、見るように、みたいな。
（こばかなさん）最初はGAとか、初心者っぽいところからのスタートだったんですね？
（大竹さん）いや、初心者ですらないですね。重要度をわかっていませんでした。
Kurashiruってdelyの３個目のプロダクトなんですけど、最初の２つの時は、今思い返すと全くデータなんて見てなかった。作って、あれ？伸びないな？みたいな。今思えば、それは伸びないよなって思います。
そうやってアドバイスもらったので、頑張ってみようと思いやってみました。
（こばかなさん）いろんな方に話を聞く中でデータの重要性を感じたということですね。では次、山田さんお願いします。
（山田さん）僕は結構出会いが遅くて、20代後半くらいからやっとデータが大事だってことに気づいたんです。
もともと高校の時に数学を捨てて、私立文系に絞ってたタイプの人間だったんですけど笑
なのであんまり数学とかは得意じゃないし、苦手でした。
それが、とある仕事で企業のfacebookを担当することになったときに、いいね数とかファン数を気にして向き合い始めました。その時にデータを意識しないとダメだなと思い始めました。１個１個の投稿が跳ねた時とダメだった時で、なんでだろうということを要素ずつに分解したんですよ。こういう要素が入っていると伸びるな、と○×つけていった時に、ちゃんとデータを使いこなせれば良くなるものもあるなと思ったのが20後半くらい。それで転職しよっかなと思った感じです。
質問２：データを会社でどう活かしているのか
（山田さん）Adobeの中では、意外とお客さんのデータしか見ていなくて、自社のデータを見ていないのが実情だったりします。
なのでadobeのWebサイトとか、みなさん見ていただいたことがあると思うんですけど、あれってトラフィックが結構な量あって、重要な気づきがある場合が多いんですけど、社員はなかなかアクセスしてなくて見ていないのもありつつ、、
でも、そのデータの活かし方でいうと、お客さんのデータを見た上でチーム内でディスカッションする文化があるなと思っています。
データって秘匿な情報の場合が多いので、あまり表には出せないんですけど。うちのチームなんかだと、いろんな企業さんに入っているデータとかを、こういうニュースがあるとこうなるんだねとか、こういうキャンペーンを打つとこのくらい盛り上がるんだね、みたいなことを、日々みんなでディスカッションして知見に活かしているというのが特徴的かなと思います。
（大竹さん）delyって結構特殊だなと思います。というのも、最初のプロダクトの時にデータを見ていなかったってさっき言ったんですけど、その時って社員もいなかったんですね。
Kurashiruを作ってから入った社員がほとんどなんですけど、人を集め始めた時点ではすでに僕も社長も含めてデータを見ていました。
データを使って伸ばしてきた会社なので、活かすっていう感じはしないですね。Natural born data drivenみたいな笑
さっき話に出てきたSlackやRe:dashも最初はグノシーの中で流行っていたらしいんですけど、それも早い段階から取り入れていて。
さっき（安藤さんの）話を聞いていて、あ、そういう視点もあるんだみたいに思いました。確かにコミュニケーションが生まれるなって。
なので活かすという感覚がない、最初からそうで、そう有り続けるみたいな。
（こばかなさん）文化として根付いているって感じですね。
（安藤さん）GUILDは受託企業なので、クライアントさんの話になるんですけど。
U-NEXTさんに技術顧問としてお手伝いしていてるのですが、最初からそんなにデータ・ドリブンの会社ではなかったんですね。
それが、データ見てやっていきましょうというのを言い続けていたら、今やもうデータ・ドリブンの会社になってきました。今は、データサイエンティストが6人、データストラテジスト４名の10人くらいのチームで、割と大所帯でやっています。
社内でどうかというと、私がそういう実績踏まえて、他の案件やってるメンバーにもデータは大事だよって言い続けてきました。最近では他のメンバーも最初の予算を取るところからデータを見ること前提になってきましたね。
（こばかなさん）もともとU-NEXTの社長さんはデータ見ない人だったという話を昔聞いたんですけど。小さい成功を積んでいって、データの重要度が会社内で上がっていったんですか？
（安藤さん）そうですね。
（鈴木さん）日経新聞電子版では、先ほど説明したAtlasというデータ基盤から、データを吸い出して様々なツールで見れるようにしています。
ダッシュボード的なツールも社内で作っていて、それを各フロアに置いてあるTVに映しています。１フロア２、３つくらいかな。
あと、Domoというdashboardツールを使ったり、いろんな形でデータを見ようとしています。
やっぱり新しいデータ基盤ができてから、基盤もアプリもどちらも内製ということもあり、開発のスピード感が合ってきたかなと思います。
新しいデータ基盤になる前は、プロジェクトのすごい最後の方で、このログを仕込むのどうするんだっけ、もう作るのめんどくさいし今更やだなみたいな感じになっていました。今では、早い段階でデータ取得について話すようになり、改善してきたという気がします。
そういう意味でもデータの活用が進んできたかな。
質問３：データをどう周りに普及しているのか
（鈴木さん）だいぶ説明しちゃってるかもしれないんですけど笑
やっぱり常時TVで出していることかな。
例えば、編集さんとかは、直接ガリガリPCを触ってデータを直接見ることはあまりないんですよね。そういう直接データをあまりみない人たちに、伝えるためにやっています。ビジネス部門の人は自分のPCで見たりしますね。
あと、社内のslackもそうですけど、Qiitaチームって社内ブログの中で、こういう分析をやって、こういう結果が得られましたみたいなことを共有してくれるメンバーもいます。
（こばかなさん）実際の成功事例みたいなものを出していってるんですね
（鈴木さん）そうですね、失敗事例は共有しているかと言われるとそうでもないけど。
（こばかなさん）でも、こういうことをきっちりやっている会社って少ない気がしています。成功事例の共有があれば、自分たちのプロジェクトに活かそうってなりそうですね。
（鈴木さん）まぁそうですね、うまくいったら横展開はしますね
（安藤さん）GUILDの中だと、社内勉強会を定期的にやっていて、そこでデータをテーマにすることがあります。
あとは、毎週データ部会っていう部活動みたいなものがあって、そこで４、５人集まって、毎週何かのテーマに関して分析しています。
最近は、最近流行っている某サービスが、他の競合に比べて何が優れているのかリサーチしました。
あと、データとか統計と言うと、アレルギー反応を示す方も多いんですね。でも、シンプルで簡単な発見でも、おって言うことってあると思うんです。GUILD社内のデータで、何か面白いことがあったら、こんなこと見つけたよってグラフにして見せています。
（こばかなさん）アレルギーがある人に対しても、データをわかりやすく伝えるということですね。
（大竹さん）シンプルに自分たちのプロダクトでいい結果が出たら、slackで伝えるのはもちろんあります。
でも、それはみなさんやられていると思うので、一個特殊なもので言うと…
データって、自分たちのはもちろんだけど、もしあの会社のあのデータが見れたら面白いってあるじゃないですか。
教えてくれない人の方が多いけど、個人的に教えてもらったもので、社内に共有する許可をもらえたら、全部社内で共有します。
それで、あの会社のKPIこんな感じらしいよって言ったら、うちでいうとそれってこのくらいだから、うちって高いねとか低いねみたいな。そういうのがわかると、自社のデータを見るのも面白くなると思います。開発部でも、他社事業の決算資料に、自分たちのプロダクトと近いデータが開示されていることがあるんですね。それを見て同じことをします。外のデータと中のデータを比較できるチャンスがあったら、どんどんやった方が面白い。そうすると自分たちのデータに興味を持つんじゃないかなって思います。
（こばかなさん）確かに自社だけ見てても、これがいいのか悪いのかが全然判断できず、興味を持ちにくいというのは本当のその通りだなと思います。意外と教えてくれるんですね笑
（大竹さん）まぁざっくりとだったら笑 例えば、iOSのPush通知の許可率ってどのくらいですかって聞いて、「えっ、そんな高いんですか！」とか言うともうちょっと詳しくコツを教えてくれたりします。ピーク時からタイミングをちょっと遅らせて〜、あっそうなんですねみたいな。
（こばかなさん）それはもう料理とか関係なく？
（大竹さん）さすがに料理のところは教えてくれないです。全然関係ないところだったら、結構教えてくれますね。
（山田さん）動機付けが大事だと思っていて、自分の実感として動機付けには２つやり方があると感じています。
一つは安藤さんの話であったように、データの見せ方です。僕らはwebブラウザ上でデータを見ればいいんですけど、例えばA3の紙1枚でどう表現すれば見やすいかと工夫することがあります。すると、データを見ることに抵抗のある人も、紙１枚にわかりやすく一覧になっていると、見るモチベーションが上がることもあります。50枚くらいのレポートが並んでいても、人って見たり覚たりしてくれないので、あえて一つの紙に分かりやすく並べるっていうのが、普及の第一歩なのかなと思います。
もう一つは、この人はデータ見れるっていう称号を社内に作っちゃうことです。バッジをあえて作ると、そのバッチ何？みたいな会話が生まれる。そこで、こういう社内で始めた制度で、こういうのに受かるともらえるんですよ、というと欲しくなる。そうやって普及してる事例もあります。
皆さんに聞きたいんですけど、データを見る動機付けってどういう風に工夫してますか？こうやってくださいと一方的に押し付けるのではなくて、必然的に自分のモチベーションとしてデータを見るようにどうやってするのかな、と。特に日経さんだと、多くの人がデータを見れるっておっしゃっていて、どういう動機付けを行なったのかなと思いました。
（鈴木さん）とにかく、多めの人に普及して幅を広げないといけないということは思っていました。
データと馬が合うか否かって、人によって当たりハズレがあると思うんですね。初めてツールを得て、そこからどんどん探索していくタイプと、結局やらないタイプってのはどうしてもいます。なので広めに教えてみて、その中から一人でも二人でもやってくれる人が出てくれば良いという風にやっていきました。
（山田さん）幅を広げようとした時に、会社的にやりなさいと言うような何かがあったのですか？
（鈴木さん）なんとなくデータを見るのって大事だよねという意識が社内にあって、あとは自分たちで考えていきました。
教え方のパターンがいくつかあって、5人くらいに深く教えてみたり、20~30人くらいに一気に横展開したり。内容もマーケティング人向けにABテストに特化したものなど、いろんなパターンをやってみて、良いものを見つけていくと言うやり方を取りました。
（大竹さん）やっぱり、SQLをかくっていうのは相当なハードルで、まずSQLって言葉を使っちゃいけないんですね。
Metabaseっていうデータ可視化ツールの機能として、変数をクエリの中で作れるものがあります。
例えば、うちだったらレシピの動画IDっていうのがあって、SQL書いてるっていってもその動画IDを入れ替えているだけなんですよ。でも、それをいじってくださいと言うと、SQLを見るのがまず嫌なのでできませんと言うことがあります。Metabaseだと、このxの変数のところが動画IDを取るところだから、ここをいじるだけだよと言うとすんなりやって、データを見てくれます。
最近はデータ可視化推進室を作って、そう言うフローを強化しています。
そこでは、自分達により特化したUIのダッシュボードを作って、データを見れるようになっています。そこでは、SQL書くのは一旦スキップして、見てもらうところから始められるようになります。
データを見始めた人の中から一握り、SQLをかけるようになると面白そうと興味を持ってくれる人がいて、その人に教えて見る。そんな感じでやってます。
質問４：データを自分で分析していく時に、何を大事にしているのか
（山田さん）さっき登壇した時に話したことと同じなんですけど、指標と仮説が定まるまでデータを見ないようにしています。
いきなりデータをみはじめてしまうと、途中で何を見ようとしてたんだっけということになりがちだし、人にお願いする時もそこまでブレイクダウンしてから出ないと無駄なことが多くなってしまいます。必ずデータを見るのはギリギリまでやらず、目的と目標のブレイクダウンをしていることが自分の中で大事にしているところですね。
（大竹さん）データを見る時、自分で見て終わるのではなく、見たものを共有することが大事だと思います。
で、僕は共有する時に、ここに金脈があったぞみたいな、できる限りセンセーショナルな文言をつけています。
あと、深く分析したい時は、例えばSEO担当のことだったら、slack上でその人にメンションをつけて自分から意見をもらいにいきます。こんなデータあるんですけどどう思いますかって、深く話した方が会話の中で発散して新しい視点が見つかることもある。コミュニケーションまでセットにしてデータを分析、そういう風にしてやった方が面白いんじゃないかなと思ってます。
（安藤さん）お客さんからデータをいただいて分析をする時に気をつけていることは、意思決定をするためにデータ分析をしていると言う意識を持つことです。ビジネス上の成果を生むために分析をやっているので、成果が生まれないデータ分析はやらないほうがマシ。
例えば、デザインの作業をいただいて納品するのだと、90%の完成度でも納品できてしまうわけですよ。データ分析の場合そうもいかなくて、必ずいただいた報酬に見合う成果を出さないといけない、そういう緊張感を持ってやっています。
あとデータは二次情報、つまりグラフにすることで、勝手に変に広まったり、一人歩きしたりします。その時に変な解釈されたり誤解されないように、説明を近くに書いておくなど、スライドでもどう見せるかは考えますね。
（大竹さん）安藤さんに質問なんですけど、データを見て、そんなこともあるんだってことが見つかる時はいいんですけど、そういうデータが見つからなかった時はどうするんですか？
（安藤さん）最近同じことを大きな企業の人に質問したんですよ。その人は「ここには何もなかったことが判明しました！ってアピールします」って言ってました。ここは俺が塗りつぶしたって、それも成果ということですね。まぁ、僕らの立場だと厳しいんですけど。
（鈴木さん）スライドの中でも触れたんですけど、例えば、これがこのくらい使われてますよっていうデータが出た後に、なんかピンとこない場合は、エンゲージメントレベルでブレイクダウンして見てみます。
辞めそうな人に向けたキャンペーンをやったはずなのに、よく見たらやめそうにない人ばかりが申し込んでた、ということもデータを見ると分かったりします。その我々でいうと、エンゲージメントレベルでクラスタリングしたグループに分けてデータを見ることを最近しています。
あとは、後付けでデータ探してくださいと言われると大変だと思います。ビッグデータをごにょごにょしたらすごいことがわかりましたっていうのはかなり幻想だとは思っていて、最初の段階からログを仕込んだ上でデータを見ることが重要かなと思います。
ここからは会場からの質問です。
「（鈴木さんに対して）自分の会社は65くらいのサービスがあって、自分はログを仕込む専門部隊な部署にいます。すると大きなサービスから小さいサービスまで、あれもこれもやってくださいということになる。ログを仕込むのは専用の開発部隊、または各サービスの人のどちらでしょうか？」
（鈴木さん）データを取る部分は各サービスの担当が引き受けるのが一般的だと思っていました。
データを受け付けて溜めるところはデータ専門部隊ですけど、データを取得する部分は各サービスのフロントの人が実装すれば良いじゃないんですかね。
（大竹さん）データ分析をするときの時間比率的に、ログ埋めたり基盤を構築する時間の方が長いと思うんですよ。なので、そこの時間を短縮できると生産性上がりそうじゃないですか
うちは、アプリの方がトラフィックが多いサービスなんですけど、アプリにログ仕込む時にタイピングミスが割とあるんですよ。それをなくすために、大元のデータソースはスプレッドシートに全部書いて、そこからswiftとかjavaのソースコードに自動生成されるようにしています。
「勉強会はどのように運営していますか？頻度を高くやるためのコツを教えてください」
（安藤さん）週1でやるデータ部会では資料は作りません。テーマだけあって、参加者がそれぞれワークショップ形式で色々分析をやるような進め方です。その流れの中で、教えないといけないと思ったことは都度教える形を取っています。
月2回GUILD内でやる大きめの勉強会ではスライドを作ります。それを今度はクライアントに見せるなど、再利用ができたりします。
（鈴木さん）データの担当者は広報も含めた仕事だと思っています。
ランチでなんでも聞く会をやったり、社内qiitaで共有したりしますね。
（大竹さん）まだ人数が少ないので、勉強会のようなものはせず、都度教えています。
特に、どうしてもこの人にこの分析手法を覚えてほしいって時は、マンツーマンで教えています。
こないだはマーケの事業担当の人にpythonでデータのビジュアライズをやって欲しかった時、僕がmacのセットアップをしてコードを書いて、後はここをこうすればできるよって状態で渡しました。そうしたらできましたって持ってきましたね。
マンツーマンの方が、深く知ってほしい時はそっちの方が早い。スケールはしませんが、ズバリやってもらえます。
（山田さん）安藤さんと一緒で、お客さんに教えることが結構あるので、マテリアルも作り込んでいる。
ただ社内チーム内で勉強会をする時は、資料は作りません。自由に分析してみて、それをお互いに見せて、なんでそれを分析したんですかって、なぜここを分析しようとしたの？みたいな会話を繰り返す、そのキャッチボールの中で、我々が業務に対する意識合わせみたいなことをやっている。
正しいことを教えようとなると、教える側も正しいことを教えないとって言う脅迫概念にかられてしまうと思うんですね。
分析の一番最初に目標や目的があって、それをブレイクダウンしてというところが自然にできるようにならないと、いくら勉強しても身についてきません。その意識づけのためには、自分が壁打ち相手になるところが近道なんじゃないかと思っています。
「（鈴木さんに対して）日経のような昔ながらの大きな会社でも、経営層は初めからデータ活用に理解があったのでしょうか？」
（鈴木さん）FT社の買収は、データを活用しようって流れがあったところに経営層が責任持って買収をしました。
FT社にはChife Data Officerがいて、データ分析に対する意識が高い。そちらからの外圧によってデータをみようという流れが強まったのはあるかな。
爆速化したwebサイトが話題になった時があったじゃないですか。その前に社内でデモをしていたんですけど、その時にFT社の社長の人が開口一番に、そのパフォーマンスは？と初めからデータの話をしました。
そういうカルチャーを外圧によって取締役自体が作ってたりします。なので、そういった外圧をうまく使うのがいいかなって思います。
「日経のように長く続いているwebサイトではたくさんのページがあると思います。そこで新たにこの指標をとりたい！となったとき、一発で全てのページにログを仕込めるような実装をしているのでしょうか？」
（鈴木さん）ベースのテンプレートがあって、そこに大体のログは仕込むようになっています。
また、大きなリニューアルの時は、みんな総出で洗い出しをしていますね。
ただ、我々のwebサイトの性質上、直近のコンテンツに関するアクセスログがかなりの割合を占めているので、古くて眠っているやつをすごい勢いでカバーしなくても大丈夫だったりします。97%以上は新しい記事に関するデータになるかな。
なので、あまり細かいところまでカバーは丁寧にやっているかはわからないですね。
おわりに
自分が情報系出身のデザイナーということもあり、SQLにハードルを感じたことはなかったりします。思っている以上に、ここは強みなのかもしれないなぁとお話を聞いてて思いました。
お話ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？