はじめまして。LITALICO発達ナビという発達障害に関するメディアでディレクションを担当している @yossan4343434です。
こちらは「LITALICOアドベントカレンダー 2017」の7日目の記事です。
前日は@5kakrさんの地に足つけた、サイバー攻撃対策でした。

はじめに

CTO@takishの野望と私のノリによって実現した社内ハッカソンを経た学びについて書きたいと思います。

「ハッカソンを企画する以上、自分もコードを書いてみたい！」という思いで、事前に最高のRuby on Railsの指南書を勉強した上で、ランチに行きたい社員同士をマッチングさせるサービスを作成しました。

コードを書くこと自体すごく楽しく学びも多かったですが、今回はコードを書くことでディレクションの業務にどのような影響があったかを書きます。

ディレクターが社内ハッカソンでコードを書いてみて業務がどう変わったか

1. テーブル構造まで理解しながら仕様を検討できるようになった
2. クエリを書いてデータを分析できるようになった
3. 絶え間なきサービス改善の重要性を痛感できた

1.　テーブル構造まで理解しながら仕様を検討できるようになった

WEBディレクターとしての仕事は、論点の解消からホッチキス留めまで多岐に渡ります。
中でも業務の大半を占めるのが、サービスの仕様検討とエンジニアとのコミュニケーションです。

ハッカソンに参加する前の私は、「コレだ！」と思った改善点をエンジニアに提案するも、「んなもんすぐに作れるわけない」と一蹴されることもしばしばでした。

ハッカソン（とその前の勉強期間）にて、実際にコードを書いてみると、目の前のWEBサービスが、どのように動いているのか何となく検討がつくようになります。

その結果、自分のお願いがエンジニアにとってどれくらいリーズナブルなのか肌感を持てるようになりました。

例えば

発達ナビのコラム（記事）から、施設情報（コンバージョン先）にユーザーを遷移させるために、バナーを設置する場面です。

以前の私は「バナー置くなんて一瞬やろ！」と思って、「いかにCTRが高い文言・デザインを作るか」しか考慮できていませんでした。

実は、発達ナビのコラムの構造は以下のようになっています。

• コラムは一つのarticlesモデル（親）と複数のarticle_partsモデル（子）で構成されている
• article_partsモデルは、テキストや写真を表している
• article_partsモデルにはtypeカラムがあり、typeカラムがテキストなのか写真なのかを規定している

そのため、
「コラム内にバナーを貼る = article_partsモデルに新しいtypeをつくる」
ということになります。

このように理解ができると、導線のデザイン・文言も重要ですが、モデルをいじることになるので、「どうやったら汎用的になるかな？」というところまで考慮しなければなりません。

今回は緊急度が高い開発だったため、まずは既存のarticle_partsモデルのみを利用して（モデルはいじることはせずに）対応することにしました。

ただ導線を作るにも、モデルをいじらないといけないのか、単にビューをいじるだけなのかで考慮すべきこと・工数が全然違うことがわかりました。

エンジニアに聞けば一瞬で指摘を受けることですが、私自身が肌身を持って知れたことによって、以前よりコミュニケーションが円滑になったと実感したケースです。

2. クエリを書いてデータを分析できるようになった

WEBディレクターの仕事の中で、アクセス数やCVRをモニタリングして、施策の振り返りと今後の改善点を洗い出すというものがあります。

今までの私は、オレンジのツールを活用したり、エンジニアに「xxの数値ほしいからre:dashでダッシュボード作ってよ」とお願いしたりして対応していました。

しかし、こうした後ろ向きなスタンスでは、大胆な仮説を立てて、数値を見ながらPDCAを回していくことができません。

そこで挑戦しようと思ったのが、自分でクエリを書くことです。

守破離の教えに従うと、学習の最初のステップはとにかく盗む・真似ることです。
まずはエンジニアが書いたあらゆるクエリを見てみることにしました。

ここでも、ハッカソンでrailsアプリケションを作った経験が大いに生きました。

例えば

発達ナビに掲載されている発達支援施設の数が一日に何件ずつ増えているかを示したクエリが以下だったとします（発達ナビではBig queryを使っています）（注1）。

select
  date(activate_at) as date
  , count(1) as facility_count
from
  facilities
where
  activation_state = 'active'
group by date
;

railsの構造も知らない状態だと、摩訶不思議な半角英数字が羅列されているようにしか見えないですが、
モデルの概念が頭にあると、
「facilitiesテーブルの中で、activation_stateカラムがactiveになっているレコードから、activate_atの日付とその日付ごとにレコード数を取ってくる」という意味なのかー
というのが何となくわかります。

何となく解読ができると、今度はこのクエリを起点に自分がほしい情報をとるためのクエリを書くことができるようになります。

その後沢山の人の力を借りて、今ではBig queryを多少なりいじれるようになりました。
railsのモデル構造を知れたことでクエリの学習をするのに役立った事例です。

注1: クエリの書き方については、クックパッド開発者ブログの「分析SQLのコーディングスタイル」を参考にさせていただいています。

3. 絶え間なきサービス改善の重要性を痛感できた

今回のハッカソンでは、ランチに行きたい社員同士をマッチングさせるサービスを作りました。

「誰かとランチ行きたいけど、誰か一緒にいける人いないかな？」というときにマッチング予約をしておくと、同じようにマッチング予約をした他の社員とマッチして、二人仲良くランチに行けるという素晴らしいサービスです。

出来たてホヤホヤのサービスをドヤ顔でチームメンバーに見せたのですが、
恐ろしいほど活用されませんでした

社員にヒアリングしてみると、活用されない理由が様々ありました。

• 見ず知らずの人とランチ行くの怖いから知り合い限定にしたい
• マッチしたのかどうかわかりづらい（通知機能がないから毎回サイトで確認しなければならず面倒）
• たかが社内ランチマッチングツールなのに、メール認証までする必要はあるのか

その後、ニーズに合わせて「マッチしたことを知らせるSlack通知機能」を実装したり、参加者があまりに少ないときのための「強制予約機能」（注3）を開発したりしましたが、社内に広まるにはまだまだ時間がかかりそうです。

0から1を一日で作り上げるハッカソンを通じて、1から100にすることの重要性を学ぶとは皮肉な話ですが、コンセプトがよかったとしても（私はそう信じています）、文化として根付くまでには、絶え間ない改善が必要なのだと痛感しました。

注2: 管理画面から強制的にマッチング予約をさせる機能。この機能が発動すると、「今日は一人でご飯食べたい」と思っていても、強制的に誰かとランチに行かされてしまう

おわりに、ディレクターからエンジニアへ、日頃の愛と感謝を込めて…

WEBサービスは何と言っても、サービスがリリースして世に出てこそ意味があります。
サービスについていくら話し合ったり、考えたりしても、それが実装されなければ、永遠にユーザーの元には届かないのです。

サービスを動かしているエンジニアはやっぱりすごいし、かっこいいなぁと思います。

むちゃな仕様やスケジュールでお願いすることもあるけど、いつも期待値を上回るスピードと品質で実装してくれて、本当にありがとうございます。

これからも、世界を変えるために一緒にがんばりましょう！

次回は@yoshi_kskの実務で学んだRailsのコーディングパターンです！
是非ご覧ください！