いう内容で社内横断的な品質向上の取り組みを紹介しましたが、今回はキャンペーンの一環として行ったポストモーテムの取り組みについてご紹介します。ポストモーテム事例おわりにポストモーテムとはポストモーテムとは、直訳すると検死となりますが、そこから転じて何か問題が発生した際に行うふりかえりのひとつです。問題が発生し収束した後に、落ち着いた状態で客観的に事象を振り返りを行い、認識合わせや原因の確認、再発防止などを検討していきます。私が以前参加していた金融系SIでのプロジェクトでは特に再発防止の意識が高かったため、プロジェクト終了時に必ずポストモーテムを行い、プロジェクト内で発生した問題に対して関係者全員で再発防止策を検討する時間を設けていました。最近では、Oreillyから出ているSRE本でもGoogle社内の事例が紹介されています。ポストモーテムの目的と効果さてポストモーテムの目的とその効果はどのようなものでしょうか。多数の関係者を集めての開催なのでそれなりにコストはかかるため、あまりメリットがなければ行う必然性はなくなります。問題が発生している最中は調査や対応、ユーザーとのコミュニケーションなどで慌ただしいことが多く、関係者間でも情報や認識が食い違うことがあります。そのため、まずはじめに認識を共有する必要があります。当時の状況を客観的に整理し共有することが重要です。次に、発生した事例をドキュメントにまとめて後から参照可能なようにしておくことです。これにより、類似事例が発生した際情報源として役立ちます。重要かつ効果が出やすいのが問題の根本原因の確認と再発防止策の検討だと考えます。一度起きてしまったことは仕方ないにしても、同じことを繰り返すのは悲しいことで誰も幸せになれません。起きてしまったことから学習し対策を講じることで、同じ失敗を繰り返さないようにすることが重要です。再発防止策を検討するための前提条件としての根本原因の確認も重要です。起きた事象や直接原因は比較的簡単に把握することができますが、事象に到るまでの道筋は多岐に渡ります。「作業時の確認漏れ」が直接原因だとしてその根本原因は様々なことが考えられます。手順書がわかりにくいものかもしれませんし、業務量が多く集中できない状況だったかもしれません。これらを一つ一つ検討していきます。開催にあたっての注意点ポストモーテム開催にあたり、以下の点に注意を払いました。非難しない・責任追求の場にしない「誰々が悪い」など、特に個人に対する非難は行っていはいけません。ポストモーテムは責任追求の場ではなく、問題の原因を掘り下げ学習し同じ過ちを起こさないようにするこが目的です。非難や責任追及が行われてしまうと、受けた側が防御的になり客観的なデータが出てくることは望めなくなります。原因や再発防止は仕組みで考える問題発生の原因を個人の能力や注意に求めることはしないようにします。個人に原因を求めてしまうと再現性のある再発防止策を導き出すことができない、もしくは困難になってしまうからです。ルールポストモーテムを円滑に実施するために、以下のようなルールを策定しました。これは上で述べた注意点を具体的に言語化・明文化したものも含まれています。非難の言葉がでたら注意を行う。責任追及が行われたら注意を行う。再発防止策は仕組みを考える。事実と意見を分けるようにする。やる/やらないに関わらず考えられるものは全て出す。その上で実際に取り組むことを選択する。リスト化ポストモーテム事例これまではポストモーテムの開催ルールなど一般論でしたが、ここから実際に開催した際のことを述べていきます。開催の経緯は以下のようなものです。同僚から、本番障害を起こしてしまいその再発防止策を検討のためにポストモーテムを行いたいと相談を持ちかけられました。社内では、チームによってはポストモーテムを行っているところもありますが、全社的に実施されている訳ではありません。関係者を集めての対面での実施よりも担当者が文章でまとめる形式が多いようだったので、事例を作る意味でも対面形式のポストモーテム開催を決めました。開催の事前準備として行なったことは以下の通りです。当事者からの事前ヒアリングの実施。まとめられていたので、その資料をもとに詳細を確認。前述したポストモーテムの開催方法の作成。社内でポストモーテムのルールがあるわけではなかったので、今後も使えるルールをという意図で作成しました。開催にあたり、参加者は依頼者に任せていましたが、できるだけ広い範囲でとお願いしました。これは、直接問題に関係しなくても根本原因の指摘や再発防止策に対しては指摘は可能なのと、チームとしての問題の共有し自分たちの問題だと認識してもらう意味もあります。ディレクターや多数の開発者が参加してくれました。開催してからの流れは、前に述べた通りに進めました。事象についてはすでにまとまっていたのとチーム内で共有がはかられていたため、時間のほとんどは根本原因と再発防止策に費やされました。Requestが大きすぎた。これに対して実際に集まって関係者で話をしてみると、根本原因として代表例としても以下のようなものが指摘されました。仕様の問題なのでユニットテストでは検出できない。修正内容の仕様が複雑。コメントもなく修正は困難。修正対象の画面の状態が複雑。これに対して再発防止策としては以下のようなものが挙がりました。地道なリファクタリング触ったことがない画面について、作業着手前に現状実装がどうなっているのか調べる。当初は根本原因/再発防止策が一つだけでしたが、関係者と議論を行う過程で多くの問題や対策がでてきました。この議論の過程も非常に建設的で、ポストモーテムのルール違反はまったくなく進みました。この議論がきっかけに各自がもっていた修正対象の複雑さや困難さといった違和感が言語化されたことも印象的でした。一環としてではなくポストモーテムの実例をご紹介しました。品質向上というとテストが真っ先に浮かぶかもしれませんが、それ以外にも様々な方法はあります。どれか一つで全てを満たすことはできないので、適材適所で手段を選んでいきたいですね。ピクシブでは、テストだけにとどまらない品質“実質”無料キャンペーンを一緒に進めてくれるエンジニアを募集中です。【中途採用】技術スペシャリストshimashima2017年11月に中途入社した、ピクシブ随一のQA/テストエンジニアで"品質実質無料"の人。社内の品質向上に東奔西走する日々。MEETUP2024-10-30pixivというシステムはどんな形をしているのか、それはなぜか。ユーザーに価値を最速で届けるために。insideは、ピクシブ株式会社が運営するオウンドメディアです。Reserved.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。