デザイナーがデータ分析に業務範囲を広げて学んだこと

こんにちは、株式会社アトラエで Growth Designerをしています三上蒼太です。
この記事は、Atrae Advent Calendar 2020 の1日目の記事です。

Atrae Advent Calendar 2020 - Qiita

本記事では、デザイナーとして新卒入社した僕がGrowthの役割を担うようになり、その中で得た「データ分析」という役割についての学びを振り返ります。

デザイナー出身でPM的な役割になろうとする方や、もっとデータと仲良くなりたいデザイナーの方など、誰かの何かの参考になれば幸いです。

私は誰か

株式会社アトラエの新卒入社2年目のデザイナーです。
ビジネスマッチングアプリ「yenta」の事業部に所属しており、主に国内Growthを担当するチームにいます。

アトラエでは明確に職種名を決めてはおらず各々が好きに自分を表現しているのですが（僕は Growth Designer と言うようにしています）、
一般的には僕はPM/PjM的な役割をしているのだと認識しています。

事業KPIの設計やそのシュミレーション, 戦略/施策立案, 分析, プロジェクトマネジメント, 一部UIデザイン等を担当しています。
（幅広そうですがレベルはまだまだです）

「データ分析」に対し、なかなか拭えなかった苦手意識

最近になりようやく分析業務への苦手意識はなくなりましたが、1年近くはずっと避けて逃げてをしてしまっていました。

僕が入社してすぐ、同期のエンジニアが「エンジニア以外もデータを扱えた方がいいでしょ」とSQL勉強会を企画してくれました。
学生時代、少しの間プログラミングスクールに通っていた僕は、その勉強会自体は「全然できるじゃん」と余裕の表情で過ごしていたと思います。

ただその後、実務として実際に行いたい分析を考えるときに、
『知りたいデータがあるが、それにどう向かえば良いのかわからない』という状況に陥りました。

これは

・そもそもサービスのDB構造がわかっていない
・クエリも基本中の基本しか知らない/何ができるのかをわかっていない
・知りたいことをデータの言葉に翻訳できない
・出すべきアウトプットの形がイメージできない

などが要因でした。

僕の弱い部分として、苦手なものに対し向き合うことをせず、逃げ腰になりがちです。
この「実務レベルになると全然わからん..」という感情がデータ分析への苦手意識を作ってしまいました。
実に1年ほど、ちょこっとSQLは触るけど難しそうな分析業務は避けるという期間が続きました。

苦手なものの「学び方」

ただ今年の10月から、本格的にyentaにおけるグロースの担当になり、その現状把握や課題抽出、改善施策の見極めや計画のために幅広く分析する必要性にかられるようになりました。

チームの動き出しの頃は、同期や先輩のエンジニアと分業しつつ分析業務を進めていたのですが、自分の担当部分がなかなかスケジュール通りに終わらず後ろ倒しにすることが続きました。めちゃくちゃ迷惑をかけまくってチーム全体のスピードにもネガティブな影響を与えてしまいました。

チームの今後を考えると、分業していたエンジニアさん方がそれぞれの開発業務に集中できるよう、分析業務は僕が巻き取れるようになることが重要な課題の一つでした。
そうなれるよう、たくさんアドバイスをくださったり、僕自身でも勉強をしていたつもりですが、どうしてもスピードや分析の質において改善ができませんでした。

そんな様子をみかねた先輩エンジニアが、1on1の時間を設けてくださりました。
そこではペアデザインならぬペア分析のようなことをし、分析に向かう思考方法や思考順序、進め方を直にみながら学ばせていただいたり、僕の進め方へ多くの注意をいただきました。
その約30分間の学びが本当に多く、この機会を境に僕のスピード/質はようやく改善されたと思っています。これをきっかけに少し自信を持てるようになり、分析を自分が担当し、チームのエンジニアさん方の業務範囲から引き剥がしていくんだという覚悟ができました。

これはよかったことであると同時に、情けなさも感じる事象でした。
本やUdemyで勉強していたあの数十時間よりも、先輩との30分の方が明らかに成果につながったのです。
何かを身につけたり成長させようと感じる時、僕らはいろんなインプットを試みますが、適切な方法はケースバイケースあるはずで、ベストな手法を探す姿勢を持たなければと学びました。

1番の学び「過去の自分は他人」

先述の1on1で教えていただいた中でもっとも身に染みたのは「過去の自分は他人」という言葉です。

僕のクエリはとにかく汚かった！！！！！（心の底から思う）
似た分析をしたい時に楽ができるように過去のクエリを保存するなどしていたのですが、全然快適に使いまわせた試しがありません。

そのクエリが汚い由縁は、具体的には以下のようなものでした。

🙅‍♂️ インデント揃ってない
🙅‍♂️ as での命名が雑。省略しすぎ
🙅‍♂️ サブクエリのネストしまくり
🙅‍♂️ コメントは使わないのがかっこいいという思い込み&無駄な固執

僕の分析業務で、「やっていること」と「かかっている時間」を振り返った時があります。
わかったのは、以前書いたクエリを活用して今やろうとする分析を進めるべく『過去のクエリを眺めて解読している時間』が無駄に長いことでした。

自分で書いたものなのに、読み返すことにとても苦戦していたのです。
自分で書いて読めないクエリを他人にレビューいただいていたのですが、今思うと本当恐縮です。。。汗

↓のブログから、読みやすいクエリを書くための考え方をたくさん勉強させていただきました。

分析SQLのコーディングスタイル - クックパッド開発者ブログ

データ分析業務のプロセス

先述の『知りたいデータがあるが、それにどう向かえば良いのかわからない』という1年前の自分とも、もう縁を切ることができました。

今は以下のように業務プロセスをフレーム化することができており、この過程で進めることでほとんど迷うことがありません。

1 / 問題設定
1 - 1 / イシューを定義する
1- 2 / Dashboardなどにすでに参考情報がある場合は、その事実を確認する
1- 3 / 仮説をたてる

2 / 仮説の検証のために必要なデータを整理する
2 - 1 / たてた仮説を、データを使った言い方に翻訳する
2 - 2 / 出すデータのアウトプット形式をイメージする

3 / 検証
3 - 1 / イメージした形式にデータを加工, アウトプットする
3 - 2 / その結果を元に考察する
3 - 3 / もっと調べるべきことが見つかれば次の調査を行う。1 に戻る

4 / 活用する
4 - 1 / 必要に応じてグラフ化などの可視化もしつつ、チームのナレッジにしたり施策の裏付けとなるようまとめを行う

↓の記事には、よりテクニカルなことなども紹介されており大変参考になりました。

デザイナーがデータを扱える強み

（まだこんなことを語れるレベルにはなっていないと自覚しつつも）
データに対する苦手意識がなくなった今、デザイナーがデータと仲良くなる意味/強みについて、僕は以下のように感じています。

◯定量視点と定性視点を行き来できるようになる
→課題解決のための手段/武器を増やせる

◯アウトプットの根拠に定量データを用いることができるようになる
→その説得力&納得感が増す&意思決定のコスパがよくなる

◯アウトプットの成果を振り返りやすくなる
→アウトプットの成果と向き合う機会を自分で作っていけるようになる
→(おそらく)続けることで施策立案やアウトプットの確度が高まっていく

おそらくほとんどの組織で少なからずデータは活用されていて、エンジニア（あるいはデータアナリスト）とデザイナーがペアになるなどして上記の内容は満たせていることでしょう。
ただ、それをデザイナーが一人でできるようになることで、コミュニケーションのテンポが上がり、限られた時間内で打てる手数を増やすことができ、結果世の中に届けられる価値が大きくなるはずだと考えています。

この二つの視点を一人で持てることを僕の強みの1つとし、今後よりチームに貢献していければと考えています。

注意）
本記事では「デザイナーのみなさん、僕みたくデータ扱う方がいいよ！」などと言いたいわけではありません。
デザインのスペシャリストになっていく道もありますし、フロントエンドのスキルを身に付けることやマーケティングスキルを身に付けるなど、いろんな選択肢があるでしょう。みんな違ってみんないいと思います。

結局やりたいことは世の中の課題を解決したり、世の中に価値を届けることのはずで、それに適切な振る舞い方は環境によって異なることでしょう。
僕の場合は、業務レベルでデータを扱えるようになることがそれだったというだけです。

最後に

昨年11月にnoteさんが開催された「noteの躍進を支えた”定性と定量の甘い関係”」というセッションが大好きです。というか題目から好きです。

↓動画や資料も公開されています

このセッションをみるたびに、定量定性の両方の視点を持ち組み合わせることの可能性や意義にとってもワクワクしています。

このセッションにて「定性」側の立場にいらっしゃる深津さんと、「定量」側にいらっしゃる樫田さんは、それぞれ各領域のレジェンド的な方々ですが、
お二人のような高い視座と深い思考で、サービスを健全に成長させていける人間になりたいなと強く思います。

頑張る！

---

明日はエンジニアの @otokam_Na君が書きます！お楽しみに！