品質改善：「不具合課題の振り返り会」の進め方について

こんにちは、GxPの衣笠です。
この記事はグロースエクスパートナーズ Advent Calendar 2020の10日目です。

今回は、品質改善の取り組みとして「不具合課題の振り返り会」の進め方についてご紹介したいと思います。

##「不具合課題の振り返り会」とは
お客様へ資材をリリース後に、不具合課題としてあがったものを改修し、別途リリースします。弊社案件では、定期的にリリースします。
リリース後、リリースに含まれる不具合課題についてメンバと定期的に「不具合課題の振り返り会」を行っています。この会のことを指します。

##「不具合課題の振り返り会」を開始した経緯
不具合を減らすために、何らかの取り組みを行えないかというところで、リリース後にそのリリースに含まれる不具合課題の振り返りを定常的に行い、不具合の原因の認識合わせ、再発防止に向けての対策検討を行うことを目的とし2019年9月位より開始しました。

##問題点
「不具合課題の振り返り会」を約一年近く進めてきたものの、時間がかかったり（多い時は1.5日）、対策のまとめ方は現状のままで良いのか、メンバやお客様、上司に対しこの活動についてどのような報告をしたら良いのか、より良い進め方はないものだろうか、困っていました。

##改善のきっかけ
前述の問題点で悩んでいたところ、他チームの方に支援して頂けることになりました。
実際、現状の「不具合課題の振り返り会」に参加頂き、後述「アドバイスの内容」にあるアドバイスを頂きました。
その内容を踏まえ、進め方の見直しを行い、この会での良い感じのゴールを見つけることができました。

##アドバイスの内容
・不具合課題を順番に深堀りすることに時間がかかっているので、視野を広くしてどの工程で問題が起きてるのか不具合の発生個所を抑えるにとどめたほうが良いです。
・議事録は、Excelからconfluenceに変更した方が良いです。
・効率的に振り返り会や分析をするにはjiraの情報が不足しているので追加した方が良いです。
・不具合を工程毎にどこに問題があったのか集計・分析し、「どういうパターンが多いからこういう対策をしている。」という報告がメンバやお客様、上司にもできるようにした方が良いです。
・今月、翌月との比較ができるような分析（バグが減っていることを計る、傾向をみるため）も進めた方が良いです。

##「不具合課題の振り返り会」の具体的な変更点
①進め方の方針

変更前	変更後
不具合課題を順番に深堀りしていた。	視野を広くしてどの工程で問題が起きてるのか不具合の発生個所を抑える。
根本原因の調査に時間がかかっている。	「不具合課題振り返り会」を始める前に必要な情報をjira課題へ記入する。 具体的な対策は引き続き、「不具合課題振り返り会」で検討する。

②議事録ページのツール

変更前	変更後
Excel ※各メンバがコメントを追加する際、文字の色を変えてコメントしていた。後述「Excelの例）」参照。	confluence ※メンバへのコメントの際、コメント機能が使えたり、打合せ時に記入しながらの話す際confluenceの方がやりやすい。後述「confluenceの例）」参照。
jira ※既存フィールドはあるがうまく使えていなかった。	jira ※既存フィールドの入力ルールを整備。また不具合課題の分析を行えるようフィールドの追加を行った。 （※後述「参考情報」参照）

Excelの例）

confluenceの例）

##「不具合課題の振り返り会」の進め方を変更したことで分かったこと
・前述のconfluenceの例）に記載している「基本的なゴール」(根本原因/欠陥の混入した工程/対策)を明確にし、各メンバがその意識をもって、打合せに望むことで、話が広がりすぎても、収束するように進めることができました。

・前述の①進め方の方針の表にある「不具合課題を順番に深堀りしていた。」→「視野を広くしてどの工程で問題が起きてるのか不具合の発生個所を抑える。」に変更したことで、変更前だとどうして不具合が混入してしまったのかということに目が行きがちだったが、変更後の視点に変えたことで、その課題に対しての対策を打つというより、工程で対策を打つという広い視点で考えられるようになりました。

・前述の①進め方の方針の表にある「根本原因の調査に時間がかかっている。」→「「不具合課題振り返り会」を始める前に必要な情報をjira課題へ記入する。」に変更したことで、打合せ前までにメンバと分担し、課題の分析を議事録ページに追記するようにしました。その結果、メンバと認識合わせして確定したい「混入原因」と「対策」だけに時間が取れるようになりました。

・Excelの時は、たまった過去分を総括してみる際、見づらかったが、Confluenceにすることで複数回分を俯瞰して見る際は見やすくなりました。

##「不具合課題の振り返り会」の実施前後で品質において変わったこと
以前と比べ不具合の件数が減ったかどうかの分析は現状できていない状況です。
下表の通り「不具合課題の振り返り会」実施後に開発の注意点のページができたことで、少なからず同じ不具合は発生させない仕組みは整いつつあり、またメンバに対して品質を担保する意識付けはできました。従いまして少しずつですが品質の改善につながってきていると思います。

実施前	実施後
開発の注意点をまとめたページはない	「不具合課題の振り返り会」で検討した対策を開発の注意点としてconfluenceに追記しメンバへ共有

##引き続きの取り組みとして
①今までは、「不具合課題の振り返り会」で検討した対策を開発の注意点としてconfluenceに追記しメンバへ共有してました。このやり方では対策としては完全でないため、開発工程に組み込むよう開発の注意点を見直し、チェックリストにまとめ、チェックリストでチェックし問題なければその作業は完了になるといったような開発の進め方となるようにしたいと思ってます。

②不具合課題の集計・分析を行い、どのサブシステムにおいて、欠陥の混入した工程はどこか、傾向をグラフで表現できるようにしたいと思ってます。

##まとめ
・他チームの方に支援してもらい、率直なアドバイスを頂き、最初はボディブローをくらったように凹みました。が、一旦提案して頂いた通りの進め方を試してみたところ、納得がいきました。他チームの方のご意見を頂けたことに非常に感謝と、まずは試してみることも大事だなと思いました。

・他チームの方に支援してもらった際、以下お言葉頂きました。自分にとっては響いたので共有します。
　- 誰にどういう場面で読んでもらうつもりのページなのかを意識した方がよいです。
　- 報告書をまとめるような気持ちで事実と決定事項を整理する。

##参考情報
分析を行うためにjiraに追加したフィールドは以下となります。
・対象システム：不具合が発生しているサブシステム
・混入原因：作業工程のどの工程に不具合が混入したのか
・発生バージョン：どのバージョンで不具合が混入したのか
・影響範囲：不具合がどの機能に影響があるのか

以上です。