TOPハウツー・学習テクノロジーSoftware Testing Journey🌍#154 失敗を活かすポストモーテム12:15 2025年5月13日 138再生 問題を報告する 再生する シェアする AI目次ポストモーテムとは?その語源に迫る失敗から学ぶ3ステップを公開関係者との連携、成功の秘訣再発防止策の実行と管理方法「人を責めない」という鉄則AI文字起こし(β版) # タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # 失敗を活かすポストモーテム こんにちは、救援神社のサミーです。今日もワクワクしていますか。今回はですね、Voicyのトークテーマ、失敗の生かし方でしたっけ、ということでポストモーテムの話をしたいと思います。 まさにポストモーテムってこう失敗を生かす方法、処方なんじゃないかなぁなんて思うわけですよね。 今回の放送の流れとしては、最初にポストモーテムの語源について簡単にお話をして、 2つ目が具体的にポストモーテムで今どういうことをしているのかという事例をお話しします。 最後がポストモーテムで大事にしていることについてお話をしていきます。順番にお話ししていきます。 まず最初にポストモーテムの語源なんですけど、知ってます? ポストモーテムの語源は、あれです、死法解剖って言うんですかね。 死因の解明のために行う遺体の解剖っていうのが語源になっています。 結構これを最初聞いた時、え、そうなの?ってちょっとびっくりしたりもしたんですけど、 もともとは医学の文脈で使われていた言葉だそうです。 それが比喩的に使われるようになって、ソフトウェア開発の世界でインシデントが発生した後に行う振り返りとか 原因分析というものをポストモーテムというふうに呼ぶようになったということですね。 ここまでが1つ目、ポストモーテムの語源についてでした。 続いてがポストモーテムで具体的に何をやっているのという話なんですけれど、 ざっくり3ステップに分けると、まず最初に関係者を集める、 2番目にディスカッションというか振り返りをする、 そして3番目に再発防止策を実行する、実行管理みたいなところも含めてですね、超ざっくり分けるとこの3つになります。 最初にその関係者を集めるというところなんですけれど、基本的にそのポストモーテムというのはインシデントが起きたとき、起きた後に行うんですね。 だいたい忘れちゃうというのもあるので、障害が発生する、あるいは落ち着いてから一時対応とかをした後に1週間以内に行うということを私はいつも気をつけています。 じゃあこのポストモーテムに参加する参加者って誰なのという、先ほど関係者って言ったんですけれど、 その障害を対応した人も関係者ですよね。あるいはその障害の事象に詳しい人も関係者ですよね。 例えばインフラ系でサービスが止まっちゃった、ダウンしちゃったみたいな場合であればSREの方を呼ぶみたいな、そんなこともありますし、 もしそのインシデント、もしっていうのかな、基本的には何か修正を加えた、過去に加えた修正だったり変更というものが悪さをしてっていう場合は、その時のプロジェクトの担当者とか開発者とかにも参加してもらえますし、 あるいは何だろうな、その開発というか変更で良いよねっていうところをジャッジしたレビュアの方を呼ぶっていうこともあるし、結構その関係者はどこまで呼ぶんだ問題っていうのは組織によっては大変、どこまで呼んだらいいんだろうっていうのが大変になる可能性があるかなと思います。 とにかく最初のステップとしては関係者を集めるというところから始まります。 ステップ2のところでは振り返りですね。 ポストモーテムって何を振り返るのかみたいなテンプレートフォーマットっていうのは、ブログとかにも多分探せばあるかなと思うんですけど、基本的には事象と直接的原因と間接的あるいは同期的原因、 その直接的原因を引き起こした裏側背景にある行動だったり、エラーだったりというものですね、間接的要因というところがメインはそこら辺なのかなというふうに思ってます。 直接的原因とか事象というのはわりかしわかりやすいんですよね。 コードのどこに問題があったのか、本来こういうふうな動きを想定していたんだけど、実際はこういうコーディングになっていたので、こういう事象につながったという感じで、 ポストモーテムのそのミーティングの前までに事前に詳しい人に書いてもらうということをしているんですけれど、じゃあその振り返りの場ではですね、その事実の確認とか、間接的原因、同期的原因の深掘りというのがメインになります。 この深掘りの仕方というか、なぜなぜはなかなか難しくてですね、私もまだ自信を持ってうまくいっているというふうにあまり言えないんですけれど、 でも今やっていることとしては、2つの切り口を少なくとも見るようにしていて、なぜこの方法実装内容で良いと判断をしたのかというところの深掘りをしていくのと、 あとなぜ検出、リリースの前に検出できなかったのかというところ、最初の大体この2つの切り口から基本的には深掘りをしていくみたいなことをチャレンジしているところです。 直接的原因の背景、裏側にはどういう、例えば思い込みとかコミュニケーションでの仕様の認識が、例えば開発チームとPDMとで認識がずれていたみたいな話なのか、 期日とか時間に追われていて、何かプロセスをすっ飛ばしてしまったとか、いろんな背景があるわけですよね。その背景を理解した上で、再発防止のためにはどういうアクションが取れるのか。 アクションといっても、何かプロセスを変えたりとか、分かりづらい行動があったら、じゃあ似たようなものは他にはないだろうかというのを調べて、 リファクタリングをするとか、テストの設計の方法に問題がありそうであれば、何か観点だったり、観点というのかな、やり方を変えたりとかということもあります。 ポストモーティングの関係者のミーティングの中では、再発防止策までを考える。そして担当者と期日、大きいタスクであれば目安、いつ頃までにやるかというところを決めるようにしています。 3つ目のステップ、再発防止策の実行と実行管理というところなんですけど、私はサーナーとかディラとかのタスク管理ツールにポストモーティングのタスクも追加をしています。 ポストモーティングの全体の流れとして、先ほど言ったステップ、まず事前準備というかミーティングをして、再発防止策を実行して、 最後、再発防止策を実施したら完了みたいなところのステータスがあるので、タスク管理ツールを使って、今ミーティング前なのか、ミーティング中なのか、再発防止策で必要なのか、完了なのかというのが分かるようにしています。 実行管理という意味だと、どうしても後回しにされがちだったりとか、あるいはこれをやろうと言っても、それが忘れされてしまうということがよくあると思うんですよね。 なので、定期的に、大体週に1回とかですかね、今の進捗どうなっているかというところを確認する。もちろん何かタスク管理ツールを見て分かればそれでもいいんですけど、動きがなさそうだったらリマインドするというところも含めて。 あとは、どうしても今はこれをやるのが厳しいということで、あればいつ頃やりますかとか、その来期のプランニングに入れましょうかみたいな感じで、無理に全部を今やるというのはやっぱり難しいと思うんですね。 新機能の開発との兼ね合いだったりとかというところもあるので、現実的にどういうことがいつまでにできそうなのかというところはしっかり管理をしていくというか、 ちゃんと失敗から学んだことを、そして次、同じことを起こらないように防ぐためにはこうしたらいいとせっかく考えたので、それをちゃんとやり切るというところまでサポートしていきたいなというふうに考えています。 最後、大事にしていることですね。これは人を絶対責めないということを私はいつもポストモーテルにやるときとかお話をしています。 ソフトウェア開発ってとても難しいんですよね。とても複雑だし、いろんなプレッシャーを耐えながらというか、技術感だったりとか技術的難易度だったりとか、 いろんな難しい要素っていうのがある中でやっているプロジェクトですし、そもそも人間が作っている以上ですね、どうしてもミスっていうのは絶対起きてしまうと思うんですよ。 そういうものだと私は思っているので、なので何か大きなインシデントが起きたというときも絶対人は責めないということを気をつけていますし、 初めてポストモーテルにやる人とかには必ず説明をしています。このポストモーテルの会というのは、仕組みを変えると、仕組みをアップデートするための振り返りですと。 インシデントは結果として失敗になるわけですけど、そこから学べることはたくさんあるので、それを学んで次に生かしていきましょう。 そのためには何ができるのか、何をすべきなのかをディスカッションしていきましょうと、そんなお話をしております。 ということで今回は失敗を生かすポストモーテルについてお話をしました。 # 今日のほっこり話♪ 今日のほっこり話です。 オペラの話をします。今ですね、練習でオペラをやってる。練習でオペラやってます。 7月にオペラの本番があって、練習をしてるんですけど、先日ですね、あの 舞台稽古と一緒にって言うんですかね、 音を合わせたんですよ。それがすごく、なんだろうな、楽しかったですし、見ていて、こう 面白かったっていうのが今日のほっこり話なんです。 本番になってしまうとですね、オーケストラはオーケストラピットに入ってしまうので、 舞台上ってほとんど見えないんですよ。多分今回自分の座席の座席配置的にも、絶対に舞台側なので、絶対 ステージ見えないんですよ。なので、練習の時しか、 歌い手さんとかの動きだったりっていうのは見れないんですよね。 で、これまでは 歌い手さん、歌手の方も合わせ、オーケストラ練習には何名か参加していただいてたんですけど、 動きはなくて歌だけだったんですね。で、こないだ初めて動きがついているのを見て、すごくテンションが上がりました。 ちなみに演目はグノーのロミオとジュリエットですね。 引き続き練習も頑張っていきたいと思います。以上、今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、働く場所の壁は超えられるのかというところで、 ワーケーションだったりとか、あと海外拠点とのやりとりみたいな感じで、 働く場所の壁っていうのを超えられるのかっていう話をしていこうと思います。 このトピックはですね、以前におしゃべりリクエストボックスでいただいたリクエストからのトピックになります。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 ぜひ画面右下、ハートマークでいいねをしていただけると、とっても励みになります。 ぜひフォローもよろしくお願いします。 それではまた明日お会いしましょう。ごきげんよう。 もっと見る #ポストモーテム #失敗の活かし方 Software Testing Journey🌍プレミアム放送配信中!00:191.タイトルコール09:552.失敗を活かすポストモーテム01:253.今日のほっこり話♪00:374.次回予告コメント感想・質問・応援メッセージを書こう みずけん2025年5月14日ポストトーテムの語源ってそうだったんですね。。。衝撃でした。。。1返信
#682 私のクリスマス準備は10月から始まる&今後のイベントのご案内 18分・13時間前・ 20再生AI目次私のクリスマス準備が10月開始の理由境界を越える体験作りの挑戦とはデモサイトで探るテストエンジニアの思考東京TestFestと異業種LT会の見どころカードゲームで探るリリース基準の深層
#680 (再放送)QAエンジニアの道を再び選んだワケ 10分・10月23日・ 15再生AI目次新卒テストエンジニア選択のワケQAエンジニア限界の深層管理部門で得た成長の視点QA市場変革と復帰を決めた理由掛け算キャリアが示すQAの進化
#679 Tokyo Test Fest 2026の見どころ 55分・10月22日・ 43再生AI目次東京Test Festの熱い軌跡と誕生秘話垣根を越えるTest Festの独自性とは?注目キーノート!AI時代のTest戦略リバースMutation Testingが拓く新境地言語の壁を越える国際交流の醍醐味
#678 「リリースしていいですか?」を、現実のリリース判断と照らし合わせる 16分・10月21日・ 92再生AI目次リリース判断のリアルとカードゲーム完璧ではないシステムのリスク許容スピードと品質、最適バランスの探求情報が揃わぬ現場での最終判断は?リスナーからの不具合報告体験談
#677 2018年の私 15分・10月20日・ 55再生AI目次母の還暦祝バラの花束と星空の魅力クルーズ体験が育んだ星空への情熱リスナーと共感する2017年の足跡思い出を紡ぐパンと卓球、そして家族ディズニーシー満喫!疲労困憊からの奇跡
#676 振り返りの成果物はネクストアクション 10分・10月19日・ 94再生AI目次過去の反省を未来のアクションへ繋ぐ振り返りを結果に繋げる秘訣とは課題発見よりも1つの改善を実行成長実感がない時の処方箋ゲームマーケット戦利品とイラスト買い
#673 『Taking Testing Seriously』14章で印象に残ったこと 11分・10月16日・ 79再生AI目次シグナルベーステストの概念を解説シグナルとリスクベーステストの違いユーザー視点テストの知られざる効果VCアプリ先行リリースの反響は松茸とトリュフ 秋の味覚論争