サービスづくり

実践!ポストモーテム

shimashima shimashima
2019.3.4
実践!ポストモーテム
シェア
ツイート
ブックマーク
トゥート

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

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

目次

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

ポストモーテムとは

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

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

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

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

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

認識共有

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

事例の収集

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

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

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

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

開催方法

開催にあたっての注意点

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

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

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

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

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

ルール

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

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

ポストモーテムの流れ

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

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

ポストモーテム事例

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

開催の経緯

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

事前準備

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

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

開催

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

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

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

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

  • テスト不足。ただし、仕様の問題なのでユニットテストでは検出できない。
  • 修正内容の仕様が複雑。
  • 既存コードが複雑。コメントもなく修正は困難。
  • 修正対象の画面の状態が複雑。

これに対して再発防止策としては以下のようなものが挙がりました。

  • 仕様のドキュメント化
  • 地道なリファクタリング
  • 触ったことがない画面について、作業着手前に現状実装がどうなっているのか調べる。

開催してみての感想

当初は根本原因/再発防止策が一つだけでしたが、関係者と議論を行う過程で多くの問題や対策がでてきました。この議論の過程も非常に建設的で、ポストモーテムのルール違反はまったくなく進みました。 この議論がきっかけに各自がもっていた修正対象の複雑さや困難さといった違和感が言語化されたことも印象的でした。

おわりに

品質“実質”無料キャンペーン の一環としてではなくポストモーテムの実例をご紹介しました。品質向上というとテストが真っ先に浮かぶかもしれませんが、それ以外にも様々な方法はあります。どれか一つで全てを満たすことはできないので、適材適所で手段を選んでいきたいですね。

ピクシブでは、テストだけにとどまらない品質“実質”無料キャンペーンを一緒に進めてくれるエンジニアを募集中です。 【中途採用】技術スペシャリスト

シェア
ツイート
ブックマーク
トゥート