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返信
#641会議の前に5分準備すると、仕事がかなり変わる 13分・昨日・ 89再生AI目次会議の目的明確化が時短の鍵会議の脱線を防ぐ勇気ある確認参加者コスト意識で議論を集中ユーザー視点が問いを生む思考法日常のささやかな幸せをブドウに見て
#639秋の夜長、時間を味わう 9分・9月12日・ 110再生AI目次スマホなしで味わう贅沢な時間“時間を使う”から“味わう”思考へ現代人が失った「何もしない」価値大喜利カードゲーム開発秘話の深掘り感謝と熱気!ゲームプレゼント企画
#638 『Taking Testing Seriously』 10章より 7分・9月11日・ 60再生AI目次『Taking Testing Seriously』品質特性の新定義プロジェクトに最適化する品質特性の思考プロダクトの『カリスマ性』を測る指標ユーザーを惹きつける10の評価要素季節の変わり目に感じた気温のサプライズ
#637要求と要件の違い、説明できますか? 11分・9月10日・ 115再生AI目次要求と要件の混同とその影響旅行のたとえ話で学ぶその違いISTQB定義と開発現場での応用本当に達成すべきゴールを見極めるヨーロッパ購入の特別な石鹸を捜索
#636 あと何回両親と食事ができるだろうか? 14分・9月9日・ 129再生AI目次「グッドライフ」が語る両親との時間限られた回数で気づく家族との絆リスナーのコメント:災害への備え仕事を抱え込まないチームの秘訣次回予告:要求と要件の違いとは?
#635 カードゲーム作りの難しさと面白さ 1時間1分・9月8日・ 65再生AI目次声優への愛から生まれた「マッピンカルタ」ゲーム発想の源泉、独自の思考プロセス仕事の複雑さをゲーム化する難しさクリエイターに共通するゲーム作りの型未発表「狩猟ゲーム」とQA愛の真髄
#634 仕事ができる人ほど「問いを持っている」 14分・9月7日・ 127再生AI目次「問い」を持つ人が仕事で強い理由QAエンジニアに不可欠な「問い」の視点良い「問い」を持つための3つの秘訣「自分がいなくても回る業務」の意義別府温泉で満たされた「温泉欲」
#633 ばさつさんと、大喜利カードゲーム作りについて 1時間0分・9月6日・ 72再生AI目次おもちゃ作りへの原点と妄想家コミュニティ「選ぶだけ大喜利」ゲームの着想2年間の試行錯誤!ルール簡素化の秘訣「パワーワード問題」を越えた言葉の妙印刷・PRの苦労とゲムマ出展の現実