広報だけどSQLの勉強はじめました！ データ分析は職種を超えて必要になっている

こんにちは、STORESのえんじぇること、加藤です。

1月末にネットショップ作成サービス「STORES.jp」とグループ会社のキャッシュレス決済サービス「Coiney」がサービス統合し、「STORES」になりました。

• hey、「Coiney」「STORES.jp」のサービスブランドを「STORES（ストアーズ）」に統合（2020年1月30日）

Twitter担当としては、「.jp」がとれたことでサービス名を言いやすく、書きやすくなったのが嬉しいです。これまで「STORES.jp」とツイートに書くと、意図せずリンクになっていて、いつも歯がゆい思いをしていたので（笑）。

でも今回は、サービス統合の話ではなく、SQLについて。

みなさん、SQLってご存知ですか？ SQLとは、データベースを検索して値を抽出できるデータベース言語のことです。

今回は「なんで広報なのにSQL？」「SQLを学ぶとどんないいことがあるの？」をお伝えできればと思います。

STORESではSQLを書ける人が増殖中！

STORESでは、SQLを自分で書いてBIツールからデータ抽出できる人が増えています。私もまだよちよちですがそのひとりです。

なぜ、SQLを書ける人が増えたのか。

STORESには、2018年夏にBIツールが導入されました。しかし、BIツールからデータを抽出するためのSQLを使える人が少なく、活用されているとは言えない状況でした。それをもったいないと思ったプロダクトマネージャが、昨年2月に全3回の勉強会を開いたものの、習得したのは一部の社員にとどまっていました。

時を経て2019年8月にデータアナリストが入社。「SQLを勉強したい！」という社員の声が上がり、それからは毎週SQL講座が開かれることに。今やマーケティングチームだけではなく、カスタマーサクセスや経理のメンバーもSQLを書けるようになりました。

しかも、ただSQLが書けるようになっただけじゃなく、習得した技術を日々の業務で実践しています！ データアナリストにお願いするのではなく、それぞれが必要なデータを自分で抽出して、業務の改善を進めています。

この状況、めっちゃ素敵じゃないですか？

SQLを書けるようになって何が変わったか？

SQLをガシガシ書けるようになったメンバーに、SQLが書けるようになって、何が変わったのか。カスタマーサクセスチームのMさんに聞いてみました。

おもに、メールマガジンの配信対象者リストを抽出することに使っています。

SQLが書けなかったときは、データアナリストにざっくりした条件で依頼をしていたため、データアナリストとの間で何度もやり取りしなくてはならず、お互いに余計な手間と時間がかかっていました。

しかし、SQLが書けるようになってからは、抽出可能な条件かそうでないかが、データを見ればわかるようになりました。

SQLを書けるようになったというスキルアップはもちろんのこと、「この条件を変えれば、もっと反応が良くなるかもしれない」と、データ抽出の際にもより良い打ち手を考えられるようになり、仕事の質が高まっています。

SQLに関して、わからないことがあればすぐにデータアナリストに答えてもらえる状況であることも大きいですが、それぞれが自分でやってみようと思う気持ちが大事だなと思います。

広報にも役立つSQL

広報には関係なさそうなSQLでのデータ抽出力、これがかなり役に立つんです。

まず、サービス内のトレンドや広報切り口になりそうなデータがないかを自分で調べられます！

例えば、「レジ袋の有料化を受けてエコバッグの売り上げが上がっているのでは？」と思い、年ごとのエコバッグの売り上げを調べたときのSQLはこんな感じです。

SELECT
    DATE_TRUNC(DATE(od.created_at, 'Asia/Tokyo'), year) as year,
    count(*) as cnt,
    sum(amount) as su
FROM
    `database_orderA` as A
where
    A.name LIKE '%エコバッグ%' or
    A.name LIKE '%eco bag%' or
    A.name LIKE '%ecobag%'
group by
    year

これまでだと、「こういうデータは取れますか？」「この期間で、こういうデータを出してください」など、欲しいデータをアナリストにお願いして、抽出をしてもらっていました。出てきたデータを見て違和感があっても、何度も「これは？」「あれは？」と出し直しをお願いするのも心苦しかったので、中途半端で妥協してはモヤモヤしていました……。

それが、SQLを習得した今では、

• データベースに何がデータとして入っているのかを理解した
• 欲しいデータがあるかどうかが自分で判断できる
• 欲しいデータをすぐに出せるので、広報切り口にできるかの判断までが早い

と、スピード感を持って、業務を進められています！（もちろんデータに間違いがないかは、データアナリストにレビューしてもらっています）

なによりも、自分のできることが増えたことで業務効率が改善するのは、とても気持ちがいい。

BIツールは導入されているが自分で使ったことはない……という方には、ぜひSQLの習得をオススメしたいです！

データ抽出の前に、仮説構築の力が必要だった

が、やはりデータ抽出ができるようになっただけでは、まだまだ足りていないと感じています。

今、自分に足りないもの。それは「仮説構築の力」です。

これは自身でデータを抽出できるできないに関わらず、必要なスキルです。データを利用して何かをしようとするには、まずは目的を整理し、仮説を立てなければいけません。

例えばですが、副業が世の中的に盛り上がりを見せているので、「ネットショップを副業として始めている人が増えているのでは？」という仮説を立てたとします。

今あるデータには「副業」「本業」がわかるような項目がないとなると、次の仮説が必要になります。

「副業の人は、管理画面にログインしている時間帯が休日や夜なのではないか？」

「たくさんの商品を売るのは大変だから商品登録数は少ないのでは？」

「売上はこれくらいなのでは？」

など、どんどん「仮説を立てる→データで検証する」を繰り返して深掘りをしていくことで、「ネットショップを副業として始めている人が増えているのか？」という問いに対する真の答えに近づいていきます。

この深掘りをおろそかにすると、表面的なデータだけで判断することになり、間違った答えをもとに間違った施策を打ってしまうかもしれません（自戒を込めて）。

深掘りの過程でも、データ抽出そのものがおもしろくなってしまい、どんどん当初の目的からずれてしまうこともあります。何が目的なのかは常にぶれないように気をつけないといけないと感じます（自戒を込めて）。

データは重要だがそれがすべてではない

仮説を立てる。データで検証する。その結果をもとにアクションする。

これがまっとうな仕事の進め方ではあるのですが、データアナリストには「データがすべてではない」といつも言われています（STORESのデータアナリスト西村純のTwitter）。

データ分析ではユーザー“たち”と「向き合う」ことはできる。でも、まとめられたユーザーと向き合うだけでは全然足りなくて、ユーザー側になって一緒の視点でみないと本当のことは何もみえてこない。だからデータ分析だけじゃなくて、それにプラスできるスキルがほしい。

— にしむらじゅん / データアナリスト (@jnishimu) February 7, 2020

私はサービスを利用されているオーナーさんに会うことが多いので、ひとりひとりのユーザー視点を得る機会は多いのですが、データを前にするとどうしても総論になりがちです。

データを見ることはもちろん大事。でも、それを見た後に「あのオーナーさんならどうだろう？」と1ユーザーとしての視点で見直すことも忘れないでおきたいなと思います。