みなさんこんにちは！ピクシブで唯一のテスト専任エンジニアの @shimashima です。

前回、「品質“実質”無料キャンペーン」を開始しましたという内容で社内横断的な品質向上の取り組みを紹介しましたが、今回はキャンペーンの一環として行ったポストモーテムの取り組みについてご紹介します。

ポストモーテムとは
ポストモーテムの目的と効果
開催方法
実際のポストモーテム事例
おわりに

ポストモーテムとは

ポストモーテムとは、直訳すると検死となりますが、そこから転じて何か問題が発生した際に行うふりかえりのひとつです。問題が発生し収束した後に、落ち着いた状態で客観的に事象を振り返りを行い、認識合わせや原因の確認、再発防止などを検討していきます。

私が以前参加していた金融系SIでのプロジェクトでは特に再発防止の意識が高かったため、プロジェクト終了時に必ずポストモーテムを行い、プロジェクト内で発生した問題に対して関係者全員で再発防止策を検討する時間を設けていました。

また最近では、Oreillyから出ているSRE本でもGoogle社内の事例が紹介されています。

ポストモーテムの目的と効果

さてポストモーテムの目的とその効果はどのようなものでしょうか。多数の関係者を集めての開催なのでそれなりにコストはかかるため、あまりメリットがなければ行う必然性はなくなります。

認識共有

問題が発生している最中は調査や対応、ユーザーとのコミュニケーションなどで慌ただしいことが多く、関係者間でも情報や認識が食い違うことがあります。そのため、まずはじめに認識を共有する必要があります。当時の状況を客観的に整理し共有することが重要です。

事例の収集

次に、発生した事例をドキュメントにまとめて後から参照可能なようにしておくことです。これにより、類似事例が発生した際情報源として役立ちます。

根本原因の確認と再発防止策検討

最後に、一番重要かつ効果が出やすいのが問題の根本原因の確認と再発防止策の検討だと考えます。一度起きてしまったことは仕方ないにしても、同じことを繰り返すのは悲しいことで誰も幸せになれません。起きてしまったことから学習し対策を講じることで、同じ失敗を繰り返さないようにすることが重要です。

再発防止策を検討するための前提条件としての根本原因の確認も重要です。起きた事象や直接原因は比較的簡単に把握することができますが、事象に到るまでの道筋は多岐に渡ります。例えば、「作業時の確認漏れ」が直接原因だとしてその根本原因は様々なことが考えられます。手順書がわかりにくいものかもしれませんし、業務量が多く集中できない状況だったかもしれません。これらを一つ一つ検討していきます。

開催方法

開催にあたっての注意点

ポストモーテム開催にあたり、以下の点に注意を払いました。

非難しない・責任追求の場にしない

「誰々が悪い」など、特に個人に対する非難は行っていはいけません。ポストモーテムは責任追求の場ではなく、問題の原因を掘り下げ学習し同じ過ちを起こさないようにするこが目的です。非難や責任追及が行われてしまうと、受けた側が防御的になり客観的なデータが出てくることは望めなくなります。

原因や再発防止は仕組みで考える

問題発生の原因を個人の能力や注意に求めることはしないようにします。個人に原因を求めてしまうと再現性のある再発防止策を導き出すことができない、もしくは困難になってしまうからです。

ルール

ポストモーテムを円滑に実施するために、以下のようなルールを策定しました。これは上で述べた注意点を具体的に言語化・明文化したものも含まれています。

非難は行わない。非難の言葉がでたら注意を行う。
責任追及は行わない。責任追及が行われたら注意を行う。
再発防止策は仕組みを考える。
事実と意見を分けるようにする。意見が悪いわけではない。
恒久対策・再発防止策は、やる/やらないに関わらず考えられるものは全て出す。その上で実際に取り組むことを選択する。

ポストモーテムの流れ

ポストモーテム全体の流れは以下のように行いました。

開会宣言、謝辞
目的・ゴールの確認と共有
ルール説明
ポストモーテム対象概要説明
1. 事象と影響
2. 時系列の対応
3. 直接原因確認
4. 現在のステータス
根本原因確認
恒久対応策・再発防止策検討
課題リスト化

ポストモーテム事例

これまではポストモーテムの開催ルールなど一般論でしたが、ここから実際に開催した際のことを述べていきます。

開催の経緯

開催の経緯は以下のようなものです。同僚から、本番障害を起こしてしまいその再発防止策を検討のためにポストモーテムを行いたいと相談を持ちかけられました。社内では、チームによってはポストモーテムを行っているところもありますが、全社的に実施されている訳ではありません。また、関係者を集めての対面での実施よりも担当者が文章でまとめる形式が多いようだったので、事例を作る意味でも対面形式のポストモーテム開催を決めました。

事前準備

開催の事前準備として行なったことは以下の通りです。

当事者からの事前ヒアリングの実施。事象の概要や本人が考えた根本原因、再発防止策などはあらかじめまとめられていたので、その資料をもとに詳細を確認。
前述したポストモーテムの開催方法の作成。社内でポストモーテムのルールがあるわけではなかったので、今後も使えるルールをという意図で作成しました。

開催

開催にあたり、参加者は依頼者に任せていましたが、できるだけ広い範囲でとお願いしました。これは、直接問題に関係しなくても根本原因の指摘や再発防止策に対しては指摘は可能なのと、チームとしての問題の共有し自分たちの問題だと認識してもらう意味もあります。幸い、ディレクターや多数の開発者が参加してくれました。

開催してからの流れは、前に述べた通りに進めました。事象についてはすでにまとまっていたのとチーム内で共有がはかられていたため、時間のほとんどは根本原因と再発防止策に費やされました。

根本原因と再発防止策の検討

開催前に当事者からだされた根本原因は Pull Requestが大きすぎた。複数の変更を加えていた で、再発防止策は Pull Requestのテンプレートを修正し、複数の変更を無意識に混ぜないようにする でした。これに対して実際に集まって関係者で話をしてみると、根本原因として代表例としても以下のようなものが指摘されました。