読者です 読者をやめる 読者になる 読者になる

下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・個人開発の瓦礫の記録

データ可視化なWEBサービスを作ったけど供養します

概要

MashBoard(マッシュボード)というサービスを半年ほど動かしていたのですが供養します。

f:id:yuzutas0:20170315214609p:plain

もくじ

  1. どんなサービスか
  2. なぜ作ったのか
  3. どうやって作ったのか
  4. なぜ供養するのか
  5. 思ったこと

1. どんなサービスか

統計データをヒートマップで表示するサービスです。

名前の由来は忘れました。ダッシュボード(DashBoard)と何か(Mではじまる言葉)を掛けていたのは覚えているのですが。

1-1. 対象・用途

かなりニッチで

  • IT勉強会などのイベントが対象
  • どの曜日・時間帯に
  • どのくらい多くのイベントが開催されるか

を描画するだけです。

この時点で廃棄まっしぐらな気がしますね。

1-2. ささやかな機能

フリーワードでの絞り込み!

例えば、"iOS"の分野で絞り込むと「iOSの勉強会はこの曜日のこの時間帯が多い」と分かるので

  • iOS開発チームに対してはその曜日・時間に予定を入れないようにしよう
  • 有志でiOS勉強会を開くときはバッティングしないようにしよう

といったデータドリブンな意思決定ができるようになります。

2. なぜ作ったのか

某所でエンジニア組織の運営に携わることになり、会議体を設計する過程で作りました。

2-1. 経緯

メンバー1人1人にヒアリングしたところ「週次ミーティングが外部の定期勉強会とバッティングするので、時間を早めるか曜日を変えてほしい」なる意見がちらほらと聞こえました。

*その週次ミーティングは、プロダクトや担当領域が異なる複数の開発チームが横断的に情報交換する場で、偉い人のスケジュールに合わせて水曜日の夜に実施していたのです。

メンバーの意見を聞いた私の最初の感想は「勉強会の開催スケジュールが変わったらどうするねん」でした。 バラバラなチームが集まるミーティングなので、スケジュール調整を何度もやり直すのは面倒だからです。

とはいえ、否定から入るのは良くないということで、ひとまずデータを見ることにしました。 また、仮にスケジュールを変更するにしてもビジュアルで示した方が関係者を説得しやすいと考え、可視化ツールを作ることにしました。

2-2. 結果

  • 本当に水曜の夜は勉強会が多かった!(データを見た事実)
  • 某エンジニアいわく「定時帰宅の会社が多いからでは」(定性的な考察)

これらを添えて、「外部勉強会とかぶりやすいスケジュールでミーティングを設定するのはエンジニア組織としていかがなものか」と偉い人に進言。

無事に別の曜日・時間に変更することができました。

めでたしめでたし。

3. どうやって作ったのか

3-1. クローラージョブ

以前作ったものを流用しており、ATND・connpass・DoorKeeper・Zusaarが取得対象となります。

交流会やパーティーを除外するために「勉強会」でフリーワード検索したところ(ミーティングの設計をしていた当時では)4ヶ月分・約540件の有効データを得られました。

yuzutas0.hatenablog.com

3-2. オンラインアプリ

フロントエンドはReactを用いてペラ1の画面を描画しており、バックエンドのRails製WebAPIをコールしています。

ちょうどReactが話題になり始めた時期だったので、お試しがてらチュートリアルのサンプルコードを見ながら実装しました。

  • APIでHashを受け渡す
    • Key:それぞれの曜日・時間
    • Value:イベント開催数が上位何パーセントなのか
  • JSで表組みを描いて、イベント開催数に応じてclassを指定する
  • CSSが各classに応じた着色をすることで、結果としてヒートマップが描ける

4. なぜ供養するのか

Jupyter Notebook があるから
          ↘
         Jupyter Notebook があるから
          ↙
Jupyter Notebook があるから
          ↘
         Jupyter Notebook があるから
          ↙
_人人人人人人人人人人人人人人人_
> Jupyter Notebook があるから <
 ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄

わざわざWebサービスにする必要がない、という一言に尽きます。

データ分析をするだけなら、既存の優秀なツールを活用するのがベストだと思います。 というかJupyter Notebookが強すぎる。

分析結果をもとに何らかのアクションを自動化する、といったプラスアルファがあって初めてWebサービスとして輝くのかなと。 それこそ、会議の自動スケジューリングのような価値提供ができれば魅力的……かも?

5. 思ったこと

5-1. 反省点

説得材料として自分で使ってみて、分かりやすいビジュアルとは言えませんでした。結局は雰囲気でゴリ押しました。いわゆる “Data Visualization” なる分野ですが、単純に面白いです。プレゼン・分析のスキルとしてある程度確立されているはずなので、勘所を抑えられるようになりたいです。

5-2. 良かった点

  • 組織運営の課題を技術で解くことの面白さを感じました。自分の組織だけではなく、世界中の組織の抱える課題を解決できるようになるとビジネス化できるのかなぁとワクワクします。
  • また、フロントエンドの技術検証として、jQueryでやりたきことは十分できるから「最新ツールに振り回されなくても良いのでは説」が私の中で浮上し始めます。

これらの学びが自作Qiita:Teamクローンに繋がります。

yuzutas0.hatenablog.com

最後に

  • 長くなってしまいましたが最後まで読んでいただき本当にありがとうございます。
  • 一応Githubリポジトリは公開しておきます。