こんにちは、エンジニアリンググループの福林(@fukubaya)です。
僕が所属するチームでは、約1年前から不具合分析の取り組みを始めました。 その結果、品質の向上とさらにはチームのエンジニア全体の能力向上につながったので詳細をご紹介します。
チームの概要
まず、チームの概要を簡単に。
僕達のチームでは、ニュースや独自作成の記事配信、専門的な意見交換のための掲示板、医師向けのクイズ、などのサービスを担当しています。 主にPCやスマートフォンサイトのフロントからバックエンドまでを担当しますが、場合によってはスマホアプリの開発も引き受けます。 サービスが多岐に渡りますし、ユーザに一番近いサービスでもあるので、大小含めて多数の開発を並行して実施してます。 弊社では、使用する言語やフレームワークなどは、全社で特に指定はなく、チームの裁量でサービスの課題に合わせて選択するのもあって、 扱う言語も多いです*1。
一方で、ここ半年でメンバーが1.5倍程度に増えており、それぞれの経験もバックグランドもバラバラです*2。 僕達のチームでは、エンジニアごとに担当サービスを決めず、その時スケジュールが空いているメンバーが開発を担当することになっているので、 どのメンバーであっても、担当するサービス、言語、フレームワークが初めて触るものであることは珍しくありません。
このようなチームなので、不具合の抑制だけでなく、チームメンバー全体の能力底上げも課題のひとつです。
不具合分析会
不具合分析会は、チーム内で発生したバグで、すでに修正が完了したものに関して、 1〜2週に1回のペースでチーム内のエンジニア 全員 とQA担当者が一緒に振り返る会です。 後述しますが、エンジニアは全員参加することに意味があると考えています。
僕達のチームでは、開発中のQA段階で見つかったバグ、本番で発生したバグは、まとめてJIRAで管理しているので、 JIRAのバグチケットを1件ずつGoogle Spread Sheetに書き出し、そこに分析結果を書き出していきます。 分析会の場で1件ずつ分析結果を書き出していくと時間がかかるので、 事前にそのバグ修正を担当したエンジニアが分析結果を埋めておきます。
担当したエンジニアは、
- どうやって見つけたか
- どのようなバグだったのか
- どのように直したか
を説明し、全員で発生要因を分類します。
不具合要因分類
発生要因の例です(実際にはもう少し細かいです)。分類の粒度は会を重ねていく中で増やしたり、減らしたりしていきました。
- 仕様検討不足
- 要件漏れ
- 仕様書ミス
- 暗黙ルール (仕様書に記載がなく当たり前の仕様と認識されている)
- 記載ミス
- 仕様理解不足
- ソース調査不足
- 仕様理解不足
- 社内基盤理解不足
- 実装ミス
- 値の代入・初期化
- アルゴリズム
- あとでやる忘れ
- 言語習得不足
- 作業ミス
- デグレード
- リファクタリング
- 外部要因
- サーバ不安定
- サポート不在
- ブラウザ依存
あまり発生しないような要因は、細かすぎるので似たような要因と統合します。 また、分類する種類が多すぎると次第にやる気が低下するので、はじめのうちは少なめがいいと思います。
一方で、発生要因に対する対処が分かれるものは、別々に分類すべきです。
例えば、同じ「仕様理解不足」と分類できる要因でも、 既存コードの動作仕様を正しく理解せずに実装してしまった「ソース調査不足」と、 社内基盤の構成、利用方法の理解が正しくなかった「社内基盤」とでは、 対策が異なります。 「ソース調査不足」は、ソース内コメントを充実させる、とか、誤認しづらい命名をする、などが考えられますが、 「社内基盤」は、基盤に対するドキュメントの充実や教育、など、それぞれ対策が異なります。
不具合発生サービス、プラットフォーム分類
僕達のチームでは、多くのサービスを同じチームで担当しています。 なので、開始当初は、不具合が発生しやすいサービスとそうでないサービス(例えば、古いコードが多いサービスは発生しやすい、など)や、 不具合が発生しやすいプラットフォーム(例えば、Javaは発生しやすい、スマートフォンサイトは発生しやすい、など)がありそうという仮定に基づき、 サービスやプラットフォーム別にも集計していましたが、あまり偏りがなかったので、途中でこれらの集計はやめました。
有意な差異があれば、分析結果を理由にサービスやプラットフォームのリニューアルを提案しやすくなると思うので、 これらの分析は必要に応じて検討するとよいと思います。
バグを憎んでエンジニアを憎まず
会を運営する上でひとつ注意する点があります。
あくまで要因を探り、対策を検討するための活動であり、 責任追及の場ではない ことを参加者全員が認識することです。 要因を深く探っていこうとすると、バグを出した担当者は自分が責められているように感じてしまうことがあります。 この会が苦痛となってしまうと検出するべきバグを隠すようになってしまい本末転倒です。
分析と対策
会を重ねていくと、どういう不具合がよく起こるのかが数字に表れます。 よく起こる不具合は、これからも繰り返し起こる可能性が高いので、対策を打って減らすことで、将来の品質向上につながります。
僕達のチームの例をご紹介します。
事例1: あとでやる忘れ
これが本当に多かったです。
- 機能追加に合わせて、一部動作設定を変えないといけないと 認識していたが 、変更するのを 忘れていた
- メインの処理を先に実装して、エラー処理を あとで実装しようとしていた が、 忘れていた
- テンプレートの変更箇所が複数あるのを 認識していた が、たくさんあったので一部を変更するのを 忘れていた *3
- 送信側の変更に合わせて受信側の変更も必要だと 認識していた が、受信側の変更を 忘れていた
- テスト環境にデプロイする前にDBのマイグレーション、サーバの設定変更が必要だと 認識していた が、 忘れていた
わざと強調してありますが 「認識していたが忘れていた」 のが 「あとでやる忘れ」 です。 「認識していなかったのでやっていなかった」は「ソース調査不足」、「仕様理解不足」、「暗黙ルール」などに分類され「あとでやる忘れ」とは違います。 分析会ではその違いを意識して分類しています。
この対策として、チケットや、Merge Request(GitHubにおけるPull Request)に 「あとでやる」チェックリストを作ることを実践しました。 チェックリストは必須ではなく、開発担当者や周りのエンジニアが「忘れそうだ」と思った時に作ります。
もちろん個人レベルの作業ならばTODOリストを作って書いておくのもアリです。 とにかく作業漏れを減らすことが目的なので、対策はメンバーやチーム、環境に応じて色々やり方は考えられます。
僕達のチームでは、これを始めたおかげで、その後の「あとでやる忘れ」は減りました*4。
事例2: Chrome DevTools機能拡張の開発
詳細は書けないのですが、ブラウザの画面上では正しいかどうか確認するのが面倒な機能があり、これに関する不具合が多く発生していました。 そこで、この機能の動作確認が簡単にモニターできるChrome DevToolsの機能拡張を作りました*5。 確認作業の手間が減ったので、この種の不具合は減ったはずです。
事例3: 文言警察
弊社では、サイト全体で表記を統一すべき語句や表現をまとめた表記ガイドラインがあります。 不具合というほどのものではないですが、このガイドラインに合わないものが修正対象として挙がることが度々ありました*6。
まだ実践はできてはいませんが、CIでのビルド時にルールに外れる表記を見つけたらアラートを出す仕組みを検討しています*7。
効果
効果1: 不具合の減少
分析を始めた結果、不具合は減りました。
チームメンバーが増えた分、件数自体は増えていると思いますが、開発にかかった工数に対する不具合の割合は減っています。
ただし、月別で見ると本番不具合は減少傾向にありますが、QA不具合がそれほど減っていないので、自動テストの強化など、対策が必要かもしれません。
効果2: チームのエンジニア全体の能力向上
個人的にはこの教育効果が分析会の一番の利点だと思っています。
不具合が減った要因として、上記で説明したような対策の結果もありますが、 分析会を通してチームのエンジニアの能力が向上したのも要因の一つだと思います(客観的なデータはなく、主観です)。
チームのエンジニア全員が参加することで、失敗事例に触れる機会が増え、参加するだけで不具合に対する知見が増えるはずです。 その結果、同じような不具合が出なくなったのだと考えています。冒頭でエンジニア全員参加を推奨したのはこのためです。 担当サービスも言語も多いですし、メンバーの経験やバックグランドがバラバラなので、特にこの効果が高かったと思います。
まとめ
- 不具合分析会を1年やったら不具合が減った
- よくある不具合には対策を実施した
- チームのエンジニア全員参加とすることで、全員の能力が向上した(と思っている)
We are hiring!
本文でも書きましたが、僕達のチームでは多くのサービス、プラットフォームを扱っています。 事業の成長がある限り、これからも不具合はなくならないでしょう。 共に開発し、不具合を分析し、成長できる仲間を募集中です。お気軽にお問い合わせください。
*1:僕は入社して約2年で、Java(Spring、Android)、Kotlin(Spring)、Scala(Play)、Swift、Objective-C、Python、Ruby、Javascript(jQuery、AngularJS、Vue.js)、bash、SQL を業務で書きました。古いものは減らしていきたい。Objective-Cはなくなりました。けどGoも書きたい。
*2:Rubyが得意でもJavaはあまり書いたことがないメンバーもいますし、フロントは得意でもバックエンドは経験が少ないメンバーもいます。
*3:そもそも変更箇所が1箇所になるようにするのが正しい場合もある
*4:最近また増えてきたので別の対策が必要かも
*5:ちなみにVue.js製です
*6:例えば、サイト内で使えるポイントをユーザに進呈する場合、「付与」や「提供」ではなく「加算」や「進呈」と表記するルールになっています
*7:表記をいちいち指摘するので通称「文言警察」と呼んでいます
