バグ分析のすすめ（導入編）

Tweet

皆様、こんにちは。
エコモットの板橋です。
前回は「バグ分析のすすめ」という事でバグ分析の価値について書いたのですが、このままだと、ただの理想論で終わってしまいますので、今回は具体的にどうやって導入したのかや、苦労した話などチームに定着させるまでのリアルな話をしたいと思います。

この記事は下記の記事の続編として記載しており、その内容を前提として進行していきます。
まだ読んでいない方は、先にお読みいただくことで、より理解が深まると思います。
バグ分析のすすめ

導入のきっかけ

まずはバグ分析を導入したきっかけについてお話ししましょう。
まず、私が管理しているグループは、もともと自社サービスの開発をメインに行っており、たまたま老朽化したあるサービスのリプレイスの話が持ち上がり、私たちのチームで担当することになりました。
この記事にも書いてある通り、保守運用の事を第一に考えました。

1. 長期的な観点での保守体制
2. 属人的な知識集約の排除
3. バグ票の長期的な収集と利用

ただ、いきなり理想的なものを一気に作って、チームのメンバーに「必要だからやってね」と言っても、作業負担が増えますし、そもそも、継続できないと全く意味がありませんので、バランス（継続可能なレベル）はとても悩むところでした。
業務ではBacklogを使用していましたので、それをベースに、どのような形で導入するのがスムーズか考えていきました。

バグの修正担当の立場で欲しい情報を考える

私のチームでは、属人性を排除する取り組みの一環で、実装、テスト、バグ修正に関して担当を固定化しない様にしています。
一部では、設計から製造まで同じ担当者になる事も（やむを得ず）ありますが、基本的には、担当はシャッフルです。
そのような状況じゃなくても、バグ修正に関して、他のメンバーが担当した部分を別なメンバーが代わりに修正することは開発現場として十分ありますよね。
その時、自分ならこういった情報が欲しいという内容を挙げていきました。できるだけ修正時にバグ検出時の状況確認を行う場面を減らしたかったのです。

• 詳細
• 再現性の有無及び再現手順
• 影響範囲または他の機能で同様の不具合が出るもの
• 1次解析

このあたりの情報をもらえれば、ある程度対応できるな、、、と感じていたので、これらの情報を盛り込みました。
また、冒頭でも言ったように、「バグ票の長期的な収集と運用」が目標ですから、それだけではなく、修正担当が調査した結果、判明したことも書いてほしいな、、、という事で以下の項目を挙げました。

• 2次解析
• 修正方針

表面上は、バグ報告者の記載の内容通りですが、詳細な調査の結果、実は別な部分に根本的な原因があったという事は意外とありますので、そういった観点で書いてほしい部分です。
また、調査した結果を見て、確認したい場合もあるでしょうし、リーダーなどと修正方針を決めることもありますので、その時のための項目を用意しました。
影響が大きい修正は、修正担当者個人で対応を決められませんからね。

バグ修正のフローを考える

次に、バグをどのようなフローで修正を進めるかという事を考えました。
ルールを設けていない現場では、バグ検出時に、実装担当者に直接口頭やチャットで修正依頼すると思います。以前は、私たちもそうでした笑
この方法は、気軽である反面、規模が大きい場合や特定の機能にバグが集中した時にコントロール不能になる危険性をはらんでいます。
さらに、関連するバグがある場合に、対応順や担当者を調整したりする事も良くあり、このような場面で状況の把握が不十分だと無駄なリソース投入になってしまいます。
つまり、プロジェクトマネジメント上のリスクなんです。そういった状況を改善したくて、バグ対応のフローを決めました。

このフローの特徴は、私(or サブリーダー)を必ず通過するようにすることですね。
それによって、記載レベルの平準化（レビュー）、バグ内容の把握を進めることが出来ます。
また、起票者と修正担当者の間にPL(SL)を置くことで、テスト実施とバグ修正を物理的に分離することができ、それぞれが自身の役割に集中できます。
更に、PL(SL)による状況把握を徹底し、プロジェクトをコントロール下に置くことができます。
私が一番怖いと感じるのは、現場が混乱して近視眼的な対応に終始してしまう事、全体の俯瞰が出来なくなる事ですので、リスク管理をしっかりするという事ですね。
万が一、クリティカルな内容が出てしまった時に、ステークホルダーに対する説明も必要になりますから、この流れは結構、理にかなっていると今思いました！（爆

分析のメトリクスを考える

修正担当者が欲しい情報は何かについて考えた。バグ修正のフローについても考えた。
次は、この情報をどのように料理して利用して行くかを考えます。
以下のように考えて、各項目をbacklogの追加項目として用意しました。

※1：分かり易く以下のようにしました。

※2：デグレードが発生すること自体を致命的と捉えていますので、その場合は現象の内容を度外視しています。

チームへの展開

さて、ここからが本番です。
私は、プロジェクト開始の準備段階で、ここまでの内容を事前に枠組みとして決めました。
ただ、これには各メンバーの協力が必要不可欠なので、ミーティング等の折に触れて何度か説明しました。

• 品質向上のための長期的な取り組みである事
• 開発プロセスの改善の為に必要である事
• 目先では作業が増えるが、結果的に作業が速く終わるようになる事
• しっかりと記録されたバグ票を読むことによって、改善点に気付き、各自のスキルアップにもつながる事
• 記述レベル、バグ検出時の調査についてある程度慣れが必要（暫く私がレビューを実施）な事

チーム的には、「とりあえずやってみようか」みたいな感じで、意外とすんなりと受け入れてもらい、運用が始まったのを記憶しています。（多分、半信半疑だった面もあると思いますね…）

やってみてどうだったか

やはり、初めのうちは記述レベルがバラバラで、バグ票の差し戻しが何度かありました。
他人に伝えるための文章を簡潔に書くというトレーニングが必要でした。習得には個人差があるので、辛抱強く取り組むことが必要です。
現在の記載だと何が不足なのか、何が困るのか、どのような目的があって書いているのか、そういった事を説明しました。
メンバーの協力もあって、定着するまでそれほど長くかからなかったと思います。
しかし、運用がスムーズに回り始めたとしても、やはり「厳しい状況だし、バグ修正優先でバグ票の記載は簡略化しようかな」と考える状況が起きてくるのも確かです。
そういった判断を下すことによって、テスト実施とバグ修正に回せるマンパワーは増える（実は大して増えない）かもしれませんが、それ以上に、状況の把握が甘くなり、リスクコントロールの精度が低下します。（潜在的リスクの方が高い）
一度コントロールを失ったプロジェクトのコントロールを再度取り戻すのは、並大抵の事ではありません。
そうならない為にも、目先ではなく、先の事を考えた判断（我慢）が必要になるところです。

リーダーはブレない事

これが意外と難しく、好転の兆しが見えるまで精神的に我慢を強いられる状況でした。
私も悩んだ時期がありましたが、「急がば回れ」の精神で、バグ票の起票は現状維持とし、バグ分析から見える状況をもとに、淡々と方針の微調整をして乗り越えたのを覚えています。

やってみて分かったこと

この取り組みを継続して見えてきたのは、状況が見えることによる安心感が格段に違うという事です。
もちろん、日々の分析を通じてトレンドを示し、「バグが出てもコントロール可能だ」という心理的安全性をチームに示せたことも大きな成果ですが、それ以上にうれしい副産物がありました。
チーム全体のテストやバグに対する認識（向き合い方といった方がいいかも）が少し変わったように感じます。

• バグ発生時の考察がより深くなった
• 根本的な原因の核心にたどり着くまで速くなった
• 修正の方針を提案してくれるようになった

多くのエンジニアはトレンドの言語やツール、プログラムを書くといった目に見えやすい部分に視線が向きがちですが、テストやバグといった地味だけど重要で本質的な部分にも意識を向けてくれるように変化しているのを感じます。

トレンドは短期間で廃れ、劣化するけど、本質は時間や環境が変わっても応用が利く

そういう土台となるスキルをメンバーにも身に着けてほしいのです。

最後に

このような形で、事前準備やメンバーへの説明・フォローなど、定着するまで取り組むことは多岐にわたるのですが、運用してみるとプロジェクトをコントロール下に置いているという実感と安心感から、安定したプロジェクト運営ができるようになると思います。
バグ分析は一度やってみると、手放せない道具になります。
皆さんも、試行錯誤しながら自分たちにあったかたちで、是非取り組んでみてください。

私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。

• Wantedly
• 募集要項（当社HP）