今日は、デザイナーがSQL勉強したらこんな良いことあるよ！って話をしたいと思います。
読んで、一人でも「やってみようかな」と思ってくれる人がいたら大成功です。
####目次
- デザイナーです
- なぜSQLを始めたか
- SQLの勉強方法
- 利点1:機能策定やUI設計、UXを検討する際に判断材料を自分で揃えられる
- 利点2:DBへの知見が深まりエンジニアとの会話がスムーズに
- 利点3:ただただ、楽しい！
- どんなシーンで使っているのか
- まとめ
デザイナーです
株式会社CAMPFIREのコミュニティ事業部でデザインリードとして、デザイン業務やUXデザイン、プロジェクトマネジメントなども行っています。
私のスペックは
- デザイナー歴14年、システム会社やウェブサービスの会社にいた期間が多い
- デザイン、コーディング、組み込みからプロジェクトマネジメントなど一通りなんでもやる
- 簡単なphp/ruby/js（既に構築された環境やCMSに対して組み込みが出来る程度）
といった感じです。
システムに抵抗感は無く、動くもの、使うウェブサイトが大好きですが、プログラミングが出来るわけではありません。
うす〜くフルスタックな一般的なサービス系デザイナーだと思います。
余談ですが、超絶かわいく天才的に賢いいっぬを飼っております（大事）。
そんな私がCAMPFIREに入社後、SQLを学びました。
2019年4月入社なので、学び始めて1年半ほどになります。
なぜSQLを始めたか
現在所属しているコミュニティ事業部で、全員にSQLを勉強する機会を与えてもらえる事になったからです。
流れにまかせて流されるタイプなので、とりあえず初めてみました。
SQL勉強会、名付けてスパルタSQLと社内で呼ばれています。
Slackチャンネルもあります。
SQLを勉強するにあたり、会社から以下を与えていただきました。
- Progate有料アカウントの付与
- 週に1回、1時間のSQL勉強会
SQLの勉強方法
これを週に1度1時間、業務時間内に行いました。
時間外に勉強したり、本を読んだりはしておらず、のろのろと勉強し、だいたい半年かからず業務でバンバン使えるようになりました。
特にCAMPFIREのDBという、とてもボリュームが大きくて複雑な参考資料が目の前にあるため、かなり鍛えられたと感じています。
Redashで作ったクエリを確認したところ、これまでに約100個ほどのクエリを書いています。
スパルタSQLについて、起案者でもあるエンジニアさんが詳細な内容を書いていましたので詳しくはこちらをご参照ください。
スパルタSQL【SQL勉強会】を続けている話
1:https://qiita.com/tan/private/733b47715c408abfee9d
また、私の場合は自社のDBがあったのでそれを利用して練習をしましたが、手元にDBがなく、構築するのも面倒・・・という方にはSQL FiddleというSQLを試してみれるサービスもあるようです。
利点1:
機能策定やUI設計、UXを検討する際に判断材料を自分で揃えられる
既に運用されているサービス上でUX/UI（と一緒に書くのは好きじゃないんですが今回はユーザーとのタッチポイントという意味でまとめた）を考えるとき、まず必要なのはユーザーを知ることですよね。
新しくインタビューを行ったりA/Bテストも行いますが、DBに蓄積された情報の解析は欠かせません。
ふとした時に、判断材料としてユーザーの統計データが欲しい事が多々あります。
そのたびにエンジニアさんに依頼することも出来ますが、相手の手を止める事になります。
ある程度データの必要性がハッキリしていなければ気軽に依頼することはできません。
自分でSQLがかければ、気軽に判断材料を引き出せます。
利点2:
DBへの知見が深まりエンジニアとの会話がスムーズに
SQLを覚えるにあたり、DBの構造についての理解が深まりました。
私はプロジェクトマネジメントをすることもあるので、仕様策定の際にエンジニアさんとの会話でとても役立ちます。
どういうDB構造になっているから、こういう機能は作れる、作れない、こういうUIが必要になる、時間がかかる・・・というような会話で、より理解が深まるようになりました。
利点3:
ただただ、楽しい！
楽しいです。
シンプルに、楽しい。
これに尽きます。
膨大なデータを可視化したり、データの体裁を整えたり、グラフにしてみたり。
やはりデザイナーなので、綺麗に整ったデータが取り出せたときの気持ちよさは癖になります。
どんなシーンで使っているのか
社内では基本的なクエリは大抵既に誰かが作っているのですが、デザイナーが業務で新しくクエリを作るシーンはざっくり以下のパターンに分けられます。
- UX/UIを策定する時
- 新機能をリリース後に見守る時
- 一定のユーザーを抽出する時
####UX/UIを策定する時
これが一番多いです。
新機能を考える時、UIの改善を考える時、デザイナーの直感や見た目の良さだけで決める事はまずありません。
情報整理を行い、優先順位付け、不必要な情報、足りない情報などを洗い出します。
#####- 最近の例
アクティビティ周りのUIを検討する際に、アクティビティ情報のエリアを小さく纏めたいためにタイトルの文字数をカットしようと考えた。
でもタイトルの重要な位置で文字を切りたくはない。
ということで、アクティビティタイトルの文字数分布をRedashで出しました。
結果、UIとの兼ね合いも考えた上で、ボリュームゾーンを抜けた28文字でカットすることにしました。
 |
|---|
このように、UIを検討する際には必要な応じてデータのボリュームゾーンを探ります。
ユーザーが見せたいこと、ユーザーが見たいことをデザインやUIの都合で見えにくくすることは避け、ページとしての見た目の良さや見やすさと、データや情報の見やすさの折り合いのベストな位置を考える、というような場合に大変役立ちます。
####新機能をリリース後に見守る時
お見せすることが出来ないのが残念なんですが、Pay Activityにまつわる数字を多角的に取得してダッシュボードを作りました。（実際はこの3倍くらいのデータを表示しています）
ここを眺めるのが毎朝のルーティーンで、楽しみでもあります。
 |
|---|
また、Pay Activityには最近「限定数」という販売上限数を設定できる機能が追加されました。
すぐさま限定数を使っているPay Activityリストを出し、利用状況、どのくらいの上限数が設定されるかなどを確認しています。
利用状況によってはUI調整が必要になる可能性もありますし、利用シーン、目的などを把握しUXの検討に役立てています。
####一定のユーザーを抽出する時
現在私たちはユーザーのみなさまからのご意見を汲み取り開発に活かせるよう、いろいろな方法でアンケートやインタビューを行っております。
そのなかで、ユーザーの皆さまに直接ZOOMでオンラインインタビューも行っております。
インタビュー相手を選定する際には、相手に偏りが出ないようまんべんなくいろいろなタイプのユーザーやオーナーからお話を聞けるよう、SQLを使って選出します。
例えばオーナーインタビューの場合
- コミュニティ公開から現在までの期間
- 参加メンバー数
- カテゴリー
- アクティビティの利用状況
などで絞り込み、偏りが無いようにオーナーを選び、ご連絡させていただいています。
（ご協力いただいたみなさま、本当に有難うございました！ここを見ることは無いと思いますが！）
まとめ
SQLは、とくにきっかけがなければデザイナーにはあまり学ぶ機会の少ない言語だと思われてるのではないでしょうか。
ですが今は、これこそサービスデザイナーが学ぶべき言語だと確信しています。
サービスデザイナーの仕事では、ユーザーやユーザーの行動を深く知ることがとても大切です。
また、様々なユーザーがいる中でより多くのユーザーに有益である良い落とし所を決める必要があります。
SQLはその手助けをしてくれます。
なんといっても、楽しい！
デザイナー、特にサービスデザイナーの方には是非SQLおすすめします。
あと、いっぬとの生活も最高ですので心からおすすめします。
