2017-09-12

Slackとtogglで頑張らない情報共有

Diver Downで開発者をしているen30と申します。

Diver Downでは
各自が頑張ることなくチームとしていい状態が維持できること
を理想として仕組みを模索しています。

今回はそのなかでも

誰が今何をやっているかが明確であること
各自が生産性をあげるためのフィードバックを得られること

のためにやっているtogglとSlackの連携について紹介したいと思います。

toggl

togglは

何を
どれだけの時間

やったかということを記録できるシンプルなWebアプリです。

名前の通りコアの機能は時間の計測中している状態、していない状態を切り替えるトグルスイッチといった感じです。 toggl上で使う場合には何をやるかを入力して計測を開始するという形で使えますが、Chrome拡張を入れると

todoistであればタスクの横に f:id:en30:20170911002641p:plain

githubであればIssueのサイドバー等に f:id:en30:20170911002708p:plain

といった形で色んな所にトグルスイッチを置かれて、それを押すとコンテキストに応じたタスク名を自動で入れておいてくれます。便利！
Diver Downでは短期のタスク管理にはtodoistを使っているので、基本Chrome拡張でtodoistを通して使っています。

何にどれだけの時間を使ったかがきちんとログに取られていると、自分の生産性が振り返りやすくなります。「文面の微妙な調整でこんなに時間を使ってしまっていたのか…」みたいに。

難点はタイマーの回し忘れが時々起きることですね。いっそ自動で何やってるかを全部トラッキングしたい…

Slackでの分報

分報自体についてはこちら c16e.com

分報自体は以前から使っていて、頑張らない情報共有手段としてすごく良いなと思っていました。
ですが少し前にチームで使うツールと使い方を整理することになり

タスク管理にtodoist
タイムトラッキングにtoggl

を使うようになってみると、todoistやtogglを使って、その内容を分報に書いて、というのはやってられなかったので自動で分報に送ることにしました。

todoistでは一人ひとりが自分用のプロジェクトを持つ形で運用していて、

そのプロジェクト内にタスクを作ると自動でアサイン
そのプロジェクト内にタスクの作成、完了、削除をすると対応するSlackの分報チャンネルに通知

されるようになっています。またtogglとの連携に関しては

togglのタイマー開始、終了をSlackに通知
todoistで完了すると自動で対応するtogglのタイマーが止まる

という状態になっています。

todoistでタスクを作ってtogglを回してタスクを完了すると分報はこんな感じ

f:id:en30:20170908200732p:plain

todoist周りは今のところ再利用可能な形では切り出せていないのですが、toggl周りはGoに触ってみるがてらdiverdown/toggl2slackとして切り出してみたので紹介させてください。

toggl2slack

基本togglのタイマー開始、終了をSlackに通知するというだけのプログラムです。

github.com

にバイナリが置いてあるのでlinuxであれば

$ wget https://github.com/diverdown/toggl2slack/releases/download/v0.1.1/toggl2slack_0.1.1_linux_amd64.tar.gz
$ tar zxfv toggl2slack_0.1.1_linux_amd64.tar.gz
$ toggl2slack init
$ $EDITOR config.json
$ toggl2slack start

で使い始められます。 Diver Downでは適当にsystemd unit fileを書いてlinuxサーバ上に置いてます。

config.jsonは

{
  "interval": 10,
  "toggl_token": "TOKEN",
  "dashboard_id": ID,
  "webhook_url": "SLACK_INCOMING_WEBHOOK_URL",
  "templates": {
    "started": "「{{.Description}}」を開始",
    "finished": "「{{.Description}}」を終了（{{div .Duration 60}}分{{mod .Duration 60}}秒）"
  },
  "log_file": "toggl2slack.log",
  "users": {
    "TOGGL_USER1_ID": {
      "channel": "#log_user1"
    },
    "TOGGL_USER2_ID": {
      "channel": "#log_user2"
    }
  }
}

のようなものです。
togglには今のところWebhookやStreaming APIがないのでpollingしています。intervalはその間隔です。
toggle_tokenはhttps://toggl.com/app/profileで、 dashboard_idは https://toggl.com/app/#dashboard でのurl等からわかります。

おわりに

Diver DownでのSlackとtoggl（とtodoist）連携について紹介しました。
よければdiverdown/toggl2slackを使ってみてください。
うちではこんな工夫をしているというものがあれば是非聞かせてください！

2017-08-31

データに基づいた仮説検証はじめました

Diver Downで開発者をしているen30と申します。

きっかけ

Buildersconの発表、

tech.gunosy.io

のなかの

データで確信が持てない施策は極力許さない

という言葉に感銘を受けて、チームに共有しました。

これを実現することでチームにとってどのような良いことが起こるのかを議論したり、実際に試しにデータに基づいて考えるという作業を行っていったことで、これはいい方向に進めそうだという認識が共有できるようになりました。

実際にしたこと

実施する施策には仮説、数値目標をセットにするように
いままでなんとなく使ってしまっていたGoogle Analyticsの有効活用
- 取りたいデータにあわせてセグメントを切ったり
- 目標設定をしたり
getredash/redashを導入
hakobera/redashbotでKPIをSlackに通知（ついでにParametrized Query対応のプルリク）
前日したdeployの時間と含まれるcommitのサマリをSlackに通知

良くなったこと

KPIをより強く意識するようになりました。
データをきちんと見ていくと、思っていた以上にユーザについて知らなかったことがわかりました。
施策の立案段階でデータによる検証が入り、望みの薄い施策に開発コストを割かなくてよくなりました。結果納得感を持って開発に取り組めるようになりました。
宗教論争を避けやすくなりました。根拠のない仮説どうしをぶつけ合う進展のない議論（のようなもの）を続けて時間をつかってしまっていたような場合にも、実際に検証してみようと思えるようになり早く話を切り上げられるようになりました。

今後施策を考える精度も上がることも期待できますし、時間という貴重な資源をより有効に使えるようになるであろうことが実感を伴って理解できました。

課題

データに基づいた仮説でも、効果のある施策を考えるのはそれだけで十分難しい。むしろ純粋にその難しさに向き合えるようになったとも言えます。
結果を解釈することの難しさ。環境も変化する中、純粋に施策の結果であるとどう判断するか。
短期的な指標を追いすぎて局所最適に陥ることをどう避けるか
サンプル数の少ない部分ではどう考えるか
どうやってうまく仕組み化するか

正直まだまだ手探りの部分だらけです。しかし、データに基づいた仮説検証を積み重ねていけば、もっと強いチームになれるという手応えを感じています。

2016-04-26

Twitterカードのドキュメントに無い仕様

先日アプリ☆メーカーにTwitterカードを導入しました。その上でドキュメントにないビックリする挙動がいくつかあったので共有します。

以下はSummary Card with Large Imageでしか検証していません。また、クライアントの実装次第でありドキュメントに無い以上陳腐化しやすい情報であることに注意してください。

twitter:image属性

ドキュメントではtwitter:imageはrequiredとされていませんし、Card validatorのプレビューやTwitter Web Clientでは画像無しでもカードが表示されます。しかし、Twitter for iPhoneでは画像がない場合にはカードが表示されません。

site属性

Twitter for Androidでのみ、カードを含むツイートにリプライをするとsite属性に指定したユーザが自動でメンション先に含まれます。

creator属性

creator属性を設定するとTwitter for iPhoneでカードを含むツイートにリプライをした場合に自動でcreatorがメンション先に含まれます。これは上のtwitter:imageが無い等の理由で見た目上はカードが埋め込まれていない場合でも起こります。CGMの場合creator属性を入れると作者の人に巻き込みリプライが多く飛ぶことになるので注意が必要です。

2015-06-09

Diver Down技術ブログ