はじめに

私はいくつかのサービスについて品質保証の仕事をしています。ちょっと前までプロジェクトマネージャーを担当していました。どのような立ち位置でも、品質やテストに関して計画をし、実行をリードし、評価するということをやってきました。うまくいかないこともあるし、うまくいったこともあります。その中で、個人的にうまくできないなとおもっていた、障害のふりかえりについて感じていた課題と取り組んだことを書きます。

なぜこれを書くか

障害が発生する、もしくはミスが起きるとふりかえりをして、次に同じことが起きないように対策を立てる、教訓にするという活動を行っているチームは多いと思います。私も、次に生かすためにふりかえりを行うことは大事、と思っています。障害が起きればふりかえりを行い、次に向けた対策を考え、次のプロジェクトでは同じことが起きないように対策を実行するということを行ってきました。

その一方で、私自身はふりかえりという活動がうまくできないなと思っていました。大きく分けると以下の2点に課題を感じていました。

事実の抑えや原因をすっとばして、再発防止策を先に考えてしまう
- 対策が先にあって都合がいい原因を選んでいるイメージ
- 事実という土台がしっかりしてないからそこから導き出される再発防止策もふわふわしている
わかりやすい原因、対策を思いついたらそれ以外の発想が出ない
- 誰かに説明をすることが決まっていると、わかりやすいに加えて、説明しやすいも加わる
- ストーリーとしてこれだ！ってのがあると、それ以外目に入らなくなる、思いつかなくなる

　客観的に考えればできるはずでしょ、という話はありますが、私にとって、思い込み、思惑、心理的抵抗を排除して考えるということはそんなに簡単なことではありません。ましてや当事者の立場であれば、もっと難しいと思います。ということで、私がやってみたことをこれから書きます。

読んでもらいたい人

障害のふりかえりをやってはいるものの、うまくいってないなと思っている人
障害のふりかえりについて深く考えたことがない人

課題を整理

　はじめに、にも記載しましたが、ここで私の感じている課題を整理します。

事実の抑えや原因をすっとばして、再発防止策を先に考えてしまう
- 順を追って考えられていない
- 次に向けた教訓を得ることを目的とするあまり、結論を急ぐ
- 事実⇒原因⇒再発防止策の順で積み上げるべき
事実の把握をおろそかにしている
- 担当者、レビューをした人の話を聞いて、原因を考えていた
- 現物を見れてない、記憶ベースの時もあった
わかりやすい原因、対策を思いついたらそれ以外の発想が出ない
- 障害の原因となる欠陥を作りこんだ原因は１つではなく、複数の要素が絡まっていることがほとんど
- 本来は原因が複数出てくるべきだが、ほかの原因はないか？という問いに対する答えが出てこない

やったこと

やったことは大きく分けて2つです。

障害ふりかえりで考える項目を挙げた。挙げた項目について考える順番も決めた。
- 経緯を現物で抑える
  - 混入した経緯
  - 検出できなかった経緯
  - チケットや成果物の格納場所のリンクを載せる
- あるべき姿
- 今のやり方の課題は？
- 今度こう変える
上記で挙げた項目をマインドマップの1つ目のノードにした。考えた内容は各ノードにぶら下げて書けるようにした。

f:id:yharuta:20201218110655p:plain — 障害ふりかえりのマインドマップ

工夫したポイント

ここでのポイントは以下の3つです。

考えるべき項目を挙げて、順を追って考えるようにした
- 再発防止を先に考えない
経緯を現物で抑える
- 関わった人の話を聞く場合でも、現物をみながら経緯を追うようにする
違う切り口の意見を考えやすいように、Excelなどのフォーマットではなく、マインドマップにした
- マインドマップはExcelなどと比べて、意見をたくさん出す、というときに使いやすいと感じていたため

どうだったか

良かった点、改善が必要な点がそれぞれあります。

良かった点

経緯を現物ベースでやると混入した経緯、検出できなかった経緯が腹落ちする
- 複数人で行うときには皆が同じ経緯を認識して始めることができたので効果的だった
原因や対策は決めうちにならず、いくつか意見が出た
- 個人で考えるときにも、複数人で行うときにも、意見が出やすくなったと感じました。マインドマップの良いところが出た

改善が必要な点

事実はおさえられたが、今度こうしよう！を先に考えてしまうのは変わらず
- あるべき姿、こうすればよかったを軽く考えて、結論をいそいでしまう傾向は変わらずあった
  - 手法だけでカバーではなく、他の工夫も必要。たとえば、複数人で行うときはファシリテーションをうまく行う、一人でやるときは推敲の時間をとるといったこと

最後に

　ここまでで、障害ふりかえりについての取り組みの話は終わりになります。

　最後にもう1つ、取り組みのご紹介をします。障害の再発防止という意味では、ふりかえりして教訓を得るということも大事だけど、その教訓を忘れずに引き継いでいくという取り組みも大事であると考えます。ふりかえりした、というだけでは、次のプロジェクトの対して貢献することができないためです。これに対する取り組みを最後に紹介します。プロジェクト開始のキックオフで、過去の障害の話をして同じことが起きないようにしようというのを伝えるという取り組みです。弥生の他のチームでは同じ取り組みをしていまして、先日行った自分のチームのキックオフでも取り入れてみました。このように、障害が起きたらきちんとふりかえりをする、さらに、そこから得られた教訓を折に触れて思い出すこともセットでやっていくとチームに教訓が浸透していくのではないか、と思っています。まだまだ改善できる余地はあるので、今後も取り組んでいきます。

　ということで、障害ふりかえり、というややニッチなテーマではありますが、私が取り組んだことをご紹介しました。誰かの参考になればうれしいです。ここまで読んでいただきましてありがとうございました。