「バグを憎んで人を憎まず」の精神で、開発チームとして不具合・障害と向き合う

雪山の雪が少なくて悲しいRKTMです。 先日は乗鞍高原へ遊びに行きました。駐車場から歩いて5分でこれだけ立派な氷瀑が見られるなんて、乗鞍は本当に素晴らしいところですね。 可能なら雪のあるうちに乗鞍山頂からのパノラマを楽しみたいと思っています。 f:id:RKTM:20160204084033j:plain

Misocaの開発チームは不具合にどう取り組んでいるか

本日はMisocaの開発チームが不具合をどう検知して、どう再発防止に取り組んでいるかを書きたいと思います。 その際の背景となる「バグを憎んで人を憎まず」の精神についても説明します。

1. Railsで検知できる例外はExceptionNotifierでキャッチして各種ツールへ投げる

Railsで検知した例外は、exception_notificationでキャッチし、下記へ通知しています。

  • Slack: 速報用。開発チーム含め、全員へのアラート用。
  • Bugsnag: 詳細な実行環境の記録。複数のエラーが多発した場合に、重複を除外して管理できるため便利。
  • Trello: Bugsnagからの連携機能を使い、通常の開発バックログにシームレスに移行する用に、不具合カードを自動で作成している。
  • メール: 上記サービス群が死んでいても確実に検知する用。一部のメンバーのみに送っている。

*Misocaが使っているツール群については下記の記事をご参照ください。

tech.misoca.jp

その他、社内外で報告された不具合も基本的にtrelloにカードを作っていきます。 f:id:mzp:20160219111602p:plain

2. 不具合・障害をトリアージ

発生した不具合・障害は、緊急性や重要度を判断し、緊急対応するか、後に回すかを決めます。 後に回した不具合・障害は、通常の開発タスクと同じ扱いとし、プランニングにて対応時期を決めます。

3. 不具合・障害対応をする

担当者を決め、不具合・障害対応をします。

4. 担当者が不具合や障害の記録、原因分析や再発防止策を書く

下記のテンプレートがesaに登録してあるので、それを埋めていきます。 これは不具合を混入させた人が書くこともあれば別の人が書くこともあります。

# 概要 
* (事象の概要)
# 不具合の内容
## 再現手順
## 影響範囲
### 発生した画面
### 発生しないことを確認した画面

# 処置
## 原因の分類
該当するものにチェックをいれる。
 * [ ] 設計で混入した不具合
 * [ ] 実装で混入した不具合
 * [ ] レビューで混入した不具合
 * [ ] その他で混入した不具合
### 類似箇所の調査結果
## 対応
### 応急対応 
### 恒久対応 
## 再発防止策

### この問題を事前に気付けたか?

5. 開発チーム全体で不具合ふりかえりをする

週に一度、開発チームミーティングの後、不具合ふりかえりの時間を設けています。 上記のesaの記事を共有し、他にも影響箇所がないか、恒久対応はどのようにするか、などをチームで改めて議論します。

開発チームとして不具合に向き合う

原則:バグを憎んで人を憎まず

Misoca開発チームでは「バグを憎んで人を憎まず」を原則としています。 不具合を作りこんだ人を責めるようなことはしません。

その背景は以下の通りです。

開発にはチームで取り組んでいて、不具合をレビューで見逃したのは開発チーム全体の責任

不具合を混入したのは実装した人ですが、 実装したものはPull Requestとして開発チームでレビューし、複数人からLGTMがついてからマージしています。 そのレビューで見抜けない開発チームの責任も重大です。その責を実装者個人に負わせるのは間違っています。

不具合が混入しやすい環境がよくない

不具合が混入してしまうような、そして、その不具合を検知しづらいようなコードベースがよくないです。 そういうコードベースを作ってきた(レビューで許容してきた、改善するという選択をしてこなかった)開発チームの責任も問われるべきです。

そもそも

起こってしまったことは仕方がないですし、次に起こらないように開発チームで知見を蓄積し、再発しないように取り組めば良いのです。

もし不具合を混入させた人が責められるようになると?

不具合を混入させた人を非難するような雰囲気がチームに蔓延すると、以下のようになるのでは、と危惧しています。

不具合をなくすために過剰にセルフレビューをすることになる

影響範囲の調査に余分な時間をかけたりして、トータルでの生産性が下がります。

不具合を混入した人が、自分を守るためにガードを固めることになる。ひいてはそれが開発者の正直さや率直さを損なうことになる。

根本原因の追求をするためにヒアリングしようにも、ガードを下げさせるという余計なコスト(言い回しや枕詞の考慮)が必要になります。これもまた生産性を下げますし、さらには再発防止策を考える際の障害にもなります。

まとめ:個人を責めるのはペイしない。チームでワークをしよう。

Misocaでは開発者個々人の力量に頼るのではなく、「バグを憎んで人を憎まず」の精神を元に、開発チームとして不具合・障害の削減に取り組んでいます。