ci × log × mail × chat

CI × Log×Mail ×ChatWrite by 森理麟

第1回Hubot×ChatOps勉強会

Myself

森理麟(@moririring)

職業：ゲームプログラマ

HP : moririringのHP

Microsoft MVP for Visual C#(2013.01 –)

2

MyCommunity

VSハッカソン倶楽部 + Visual Studio勉強会

C++テンプレート完全ガイド読書会

EffectiveC#4.0読書会

Unityクリエイターズ

3

CI×Love

4

CI×Service

5

CI×Make

で、僕はCI自分で作りました

そのCIを定着させるためにやったChatやもろもろの話

既存サービスであれば勝手にやってくれることも多いかと

ま、話として聞いてもらえればと思います。

6

CI

因みにちょっとレベルの低い話です。

CIって当たり前だよねーちゅうチームの人居ます？

寝てて良いですよー

トレタやクックパッド、Ito Naoyaさんなら鼻で笑うような話かも。

7

CI ×あるある

で、CI作った。その時の状況。

「CIしているだけ」

8

CI×Log

CIは継続的なビルドに意味があるのではなく、結果をチームが使うことに意味がある

最初の一歩は結果ログ画面を定期的に見てもらうことから

でも、メール投げて見といてねーでは見ない人は見ない。

→そういう人がエラーを出す。

9

CI

CIをちゃんと機能させるには情報の変化つまりエラーがあった場合にそれを対象者に迅速に知らせる仕組みが必要

いまやアプリやサービスでは当たり前。プッシュ通知。

10

CI×Mail

メール実装が簡単。エラーが出たらメールを投げる。

ログ画面にアクセスカウンター付けるとよい。効果が分かる。

11

あるある

メールでエラーを適切に投げるようになった

↓

「でもエラーが1日直らない」

↓

「メールがノイズになる」

12

Mail

フィルタリング大事。

13

Mail

回数のフィルタリング。

同じエラーなら送らない

似たようなエラーを3回おくるより1回にまとめた方が良い。

エラー修正が当たり前の会社なら3つチェックするなら3回送った方が良いとなるが。

この辺はチームレベルで

14

Mail

送信者のフィルタリング。

その情報が必要な人にだけ投げる。

実は聞き込みが重要かも。

理想はエラー告知は全体。エラー内容は担当者。

15

Mail

情報量のフィルタリング。

いらん文章は徹底的にダイエットした方がよい。

件名超大事。理想は最小で完全

内容は多少長くても良い。100個とかで足切りは入れよう。

16

CI×Mail×Log

つづきはWebでも重要。別にメールを読んで欲しいわけじゃない。

ポイントは導線。何かがあったらどこに行けば良いかを染み込ませる。

17

Log

導線が出来たら集約が重要。

可能であればインタラクティブが理想。つまり受けるだけでなく送るも同じ場所で。

要望連絡やフィルタリング、カスタマイズも出来た方が。

18

CI×Chat

ただメールはすぐ見ない人も意外と多い。

そこでもっと見てくれる場所に投げる。それがチャット。

リアルタイム性が高く、見過ごされる率が低い。

数年前はIMとかに投げてた。要は同じ用途。とても効果的。

19

CI×Mail×Chat

CIのような継続的チェックで問題時を知りたいものはメールとチャットの併用がもっとも効果的という印象

深夜のチェックや次の日でも知っていた方がよいものはメール

リアルタイム性が高いものはチャット↓

20

SDS×SDD

で、終わりのつもりだった。もともと勉強会駆動勉強でまとめるのが目的。

まとめているうちに勉強会駆動開発になりまして、ちょこちょこやってますｗ。

ログ機能を強化したり、今までより情報集約したり。

21

Chat×Bot

Chatへのプッシュを見やすくしてた。顔文字を最初にいれて挨拶してたら急に親近感出た。全メッセージ顔文字から始めたらもうキャラに見えてきた。語尾を付けたらさらに人ぽっくなった性格づけが欲しくなってきたやばい。楽しい。

22

おわりに

ご清聴ありがとうございました

23