サービスを運営していく上で必要なMTG、今回は再発防止MTGについて書いていきます。
不具合、問題の再発防止を目指す
サービスリリース後、ユーザーに不利益のある不具合や問題が発生することがあります。
再発防止策を実施せず、再度同様の問題が発生してしまうと、ユーザーからの信頼を損ねてしまいます。
不利益の有無・問題の大小に関わらず、本番環境で発生してしまった問題は再発防止策を検討・実施する必要があります。
その為のMTGが再発防止MTGです。
本番環境で発生した不具合を検知する
MTGの前に、本番環境で不具合が発生していることをいち早く検知しなくてはいけません。
・自ら見つける
・Twitterで探る（弊社ではSlackとTwitterを連携しています）
・お問い合わせ管理ツールで不具合報告を検索する
・サーバ側でエラー検知する
のような経路が想定できますが、誰が・どんな状況で検知したか、というのは振り返り材料のひとつになりますのでメモしておきましょう。
不具合の埋め込み原因を探る
本番で不具合が発生したら、必要な修正・補填・お知らせなどを行い、事態を収拾させます。
（※ここでのエスカレーションも大事ですので語りたいですが、別の機会に。。）
一段落したら、なぜ不具合が生まれてしまったのか？という埋め込み原因について、
担当者（プランナー、サーバエンジニア、クライアントエンジニアなど）は整理します。
再発防止に向けてチケットで管理する
担当者は調査と同時に再発防止のタスクチケットを起票しておきます。
このチケットに埋め込み原因と、その再発防止策を記載します。
記載が完了したら、チェック担当者（別の担当者、またはQAなど）にチケットを渡します。
チェック担当者は、なぜチェック時に見逃してしまったのか？という見逃し原因と、その再発防止策まで記載します。
埋め込み原因と見逃し原因と、２種類の原因があるので、
再発防止策は不具合を作らないようにする対策と見逃さないようにする対策という2つの軸で検討してもらうのです。
チケットの記載が完了したら、再発防止MTGの事前準備完了です。
関係者を集め、対策を練る
MTGの参加者については各担当者である、QA、サーバーエンジニア、クライアントエンジニア、プランナーです。
さらに必要に応じてマーケティング、デザインといったメンバーにも参加頂きます。
ちゃんとMTGまでに記載が完了しているチケットを優先的に取り上げ、再発防止策が妥当かどうか、MTG参加者に説明し合意を得ます。
MTGの進め方の注意点としては、懺悔室や裁判のような雰囲気にさせないことです
どうしても「ワタシが悪うございました・・
」となってしまいがちだからです。
チケットの記載が完了していなかったり、
再発防止策が妥当でなかったり、（根本解決に至ってない、など）
MTG中にさらなる防止策が思いついたりした場合、次回のMTGに持ち越します。
再発防止策が無事実行されたら、チケットをクローズします。
MTGの実施タイミング
定期的に、できれば週次で開催しましょう。
チケットの記載はその人にとって宿題となってしまうので、ちゃんと記載する時間を各チームで確保してもらう必要があります。
今週も宿題忘れました～ なんて人がいたりすると、ダラダラしてしまいMTGが崩壊する可能性があるので注意しましょう。
別のプロジェクトに共有する
再発防止のチケットに書かれている情報は、他のプロジェクトにとっては宝の山です。
隠すべき情報もあり大変ですが、なるべく再発防止の取り組みは横展開していきたいですね。
参考書籍
ソフトウェアではない業界の書籍ですが、
人為ミスを直接要因（管理面）と間接要因（心理面）に種別し、その再発防止策について記載されています。
あらゆる職場ですぐに使える 人為ミスの未然防止手法 A-KOMIK: 人為ミスゼロ実現のための考え方と手法 冨澤 祐子
https://www.amazon.co.jp/dp/4817196106/