同じく GitHub の通知はだいたい目を通してる。流量が多くてブラウザで開いてられないので Gmail で読み流して気になるやつだけ見に行くようにしてる。 GitHub の通知を見る専用のアプリを使っていないのは、 GitHub 以外のサービスからの通知とか、ごくわずかだけど外部の関係者とのメールとかもあってメールを一切見ないわけにはいかないので、だったらいっそ Gmail 一本にしたほうが楽だし見落としが無くて安心だと思ったからです（なので inbox zero を気合で実践してる）
で、気をつけてることで、まだお題で書かれて無さそうだったのがこれです↓
作業の進捗をチャットに逐一報告する
production 環境のデータを修正するとかそういう運用系のタスクというのがけっこうあって、たいてい rake タスク + Jenkins job みたいなのを用意しているんだけど、なかなかボタン一発で済むほど自動化しきれなくて、ボタン押す前後の確認作業とかがあったり、想定外のパターンがでてきてうまく処理できなかったりする。
想定どおりの手順でうまく進んでいるときも、想定外のことがおこって困っているときも、チームのメンバーに逐一状況を報告しておきたい。自分が何をやってるのか、データ修正するならどのテーブルのどのフィールドをどう変更するのか、そういうことを共有していないと、たまたま同じタイミングで同じデータを見たり処理したりしてるとお互いに困るし、後日そのデータを見た人が想定外の状態になっててびっくりしたりする（バグが原因かと思って調査したりして大事になると手間暇がもったいないし、一言言っといてよ、となる）
なのでそういう作業をするときは、「作業開始します」とか「検証環境でデータ修正するこの Jenkins job を実行します」とか「実行終わり。結果を確認します」とか、開発者みんながいるチャットのチャンネルに逐一書くようにしています。あと、これは最近試しはじめたことだけど、作業手順をまず GitHub issue に箇条書きタスクリストの形で書いて、各手順をつぶやきながら実行・終わったら √ を入れつつコメントを編集して実行時のログとか Job の Build URL とかを書き込んで、作業手順書が最終的には作業ログとして残る、みたいにしています。
分報とはちょっと違っていて、今やってる仕事の内容とか疑問点とかをチャットに書くのではなく、あくまで手順が定まっていて終わりがある一連の作業の各ステップを報告・周知する、という趣旨です（分報的なことを書くのもそれはそれでよくやります）
なお、この「逐一報告」スタイルは私のオリジナルではなく、記憶がちょっとおぼろげだけどたぶん kuroda (@lamanotrama) | Twitter さんがペパボ時代からメンテナンス作業などをする際にこういうスタイルで進めていて、開発者は実作業をしないので見てるだけなんだけど、見てれば進捗がわかるのがすごく安心感があって良いプラクティスだなと思ったので、だんだん真似するようになりました。
