こんにちは。介護・医療・障害福祉・保育の求人サイト「ウェルミージョブ」のQAを担当している林です。 ウェルミージョブは、2025年7月にカイゴジョブからリブランディングしてサービス提供を開始しました。
私はアジャイルな開発チームの中で、テストをこなすだけでなく、開発チーム全体でプロダクト・サービス品質を向上すべく日々挑戦しています。 今回の記事では、QA担当の私が開発チームにポストモーテムを導入し、チームでの実践に至るまでの経緯と、その具体的な進め方についてお伝えします。
0. はじめに
エス・エム・エスのQA組織では、Value（行動指針）として「チームで品質保証」を掲げています。 これは、介護/障害福祉事業者向け経営支援「カイポケ」のQAチームにて策定されたもので、ウェルミージョブのQAチームでも同じマインドを共有しています。 QA組織の行動指針を言語化した取り組みについては、以下の記事をご覧ください。 tech.bm-sms.co.jp
「チームで品質保証」の範囲はQAに留まらず、開発・デザイナー・PdM・事業メンバー・運用メンバーなどと幅広く協同することを想定しています。 横断的に「チームで品質保証」を実践している事例については、以下の記事をご覧ください。 tech.bm-sms.co.jp
1. QAの私がポストモーテムにチャレンジした経緯
チームでの品質保証活動における「3つの課題」
私はかねてより「チームで品質保証」のもと、開発チーム全体で質の高い原因分析をして再発防止に取り組みたいと思っていました。 しかしながら、以下のような課題感がありました。
- QAが実施する不具合分析やインシデントの振り返りが、開発メンバーを巻き込んでの活動に繋げづらい
- 過去に開発メンバーでインシデント振り返りやポストモーテムを行った実績もあるが、経験値や関心度はメンバーによって差がある
- 同じ方向をむいて原因分析・再発防止を検討できる基盤がない
私をポストモーテムへの挑戦に導いた「3つの決め手」
課題を抱えていた私に、ポストモーテムについて触れる機会が次々とやってきました。 そして、以下の決め手により、ポストモーテムへ挑戦したい気持ちが固まっていきました。
- チームで同じ方向を向ける「指南書」の存在
- 他チームの成功事例による「道しるべ」
- 「QAの業務」ではなく「チームの活動」にできる可能性
以下に、それぞれの決め手についてお話しします。
1. チームで同じ方向を向ける「指南書」の存在
同僚のQAエンジニアが作成したドキュメント中に、ポストモーテムの指南書ともいえるものを見つけました。 その中には「直接的原因・間接的原因・動機的原因」を切り分けた分析アプローチの例示と、フィッシュボーンチャートがありました。 私は「これを使えばチームで同じ方向を向いて活動できそう！」と直感しました。
「直接的原因・間接的原因・動機的原因」を切り分けた分析アプローチ
「原因」という言葉は意味が広く、人によってイメージするものが異なりがちです。「直接的原因・間接的原因・動機的原因」を分けて考えることで、チームメンバー間のイメージをすり合わせが容易になり、チームで同じ方向を向いて分析を進めることができます。指南書では、「直接的原因・間接的原因・動機的原因」について以下のように身近な例でわかりやすく説明されていました。
- 例：カロリーの摂りすぎで肥満になり、⚪︎⚪︎病（インシデント）になった
- 起きたこと -> 〇〇病
- 直接的原因 -> 肥満（hogehoge数値の増加）
- 間接的原因 -> カロリーの摂りすぎ
- 動機的原因 -> 日々の仕事でストレスがたまっており、過食の傾向があった
フィッシュボーンチャート
フィッシュボーンチャートは、ある問題（結果）とその原因の関係を、魚の骨のような形で整理・可視化するための図です。ある問題（魚の頭）は、どのような原因（骨）から起きているのか？をひと目で理解することができます。
2. 他チームの成功事例による「道しるべ」
他開発チームにおいて「ポストモーテムを重ねた結果、検討の観点・深さがよくなってきて、品質向上のプロセスが磨かれている」との情報をキャッチしました。これは、まさに私の目指したい姿です。 また、他チームにてポストモーテムのフォーマットが確立していることも確認できたため、フォーマットをそのまま流用して省コストでチャレンジできそうでした。
3. 「QAの業務」ではなく「チームの活動」にできる可能性
私は、チーム全体で活動をするにあたり「QA業務を開発メンバーに協力してもらう」ではないやり方を模索中でした。 ポストモーテムは、当時のウェルミージョブ開発チーム内では「QA（または開発）がやるもの」という概念がない状態だったため、「これならQAの業務ではなくチームの活動にできそう！」と感じました。
そして、ついにポストモーテムへ挑戦する日が訪れました。
2. ポストモーテム実施
初回チャレンジ
ステークホルダへ原因や再発防止について報告が必要な状況となったため、私から「今回はポストモーテムにチャレンジしてみませんか？」と開発チームへ提案しました。 ポストモーテムについて、社内における他チームでの実績や参考にできる情報が多くあることを伝え、開発チームの賛同を得ました。 誰がファシリテートするかについてはもちろん、ポストモーテムへの挑戦にワクワクしている私が引き受けました。
以下、初回チャレンジのサマリです。
活動のステップ
- 資料たたき（ステータス・サマリ・タイムライン・影響・原因・対応・アクションアイテム）作成：QA（私）
- 読合せ会1：開発・QA・PdM・事業メンバー
- 読合せ会2：開発・QA・事業メンバー
- 改善アクション実行：開発・QA
大事にしたこと
- チーム全体で同じ方向を向いて原因分析に取り組むこと
- 効果的かつ実現可能な再発防止策を導き出すこと
- 次回以降、私ではない他のメンバー（特に、QAではなく開発メンバー）がチャレンジできるように敷居を下げること
チャレンジ結果
- 【◎】「直接的原因・間接的原因を切り分けた分析アプローチ」によりチーム全体で方向性を合わせ、解像度を高めて効果的な分析ができた
- 【△】読合せ会が初動の話で盛り上がり、原因分析の話が十分にできなかったため、別日に読合せ会2を追加開催することになった
- 【△】後から資料を整理する時間がなく、資料が読みづらいままになってしまった
- 【◎】改善アクションを、QAタスクではなく開発チームのタスクとして進められている
このように、ポストモーテム初回チャレンジは概ね成功といってよい形で実施することができました。
さて、このポストモーテムの活動を開発メンバーへ展開していきたい…と思っていた矢先、予想外に早く、その時は訪れてしまいました。
2回目チャレンジ
初回チャレンジから間を空けず、ポストモーテムの成功体験が記憶に新しいタイミングで、開発チームへ2回目のポストモーテム実施を提案したところ賛同が得られました。 「ぜひ開発メンバーにチャレンジしてほしい、私が伴走する」とファシリテーターについて持ち掛けたところ、ポストモーテム未経験の開発メンバーに立候補してもらえました。
以下、2回目チャレンジのサマリです。
活動のステップ
- 資料たたき（ステータス・サマリ・タイムライン・影響・原因・対応・アクションアイテム）作成：開発（伴走：QA）
- 原因分析の分科会：開発・QA（主要メンバーのみ）
- 読合せ：開発・QA・事業メンバー・運用メンバー
- 改善アクション実行：開発・QA
大事にしたこと
- 私はできるだけ裏方に徹すること
- チーム全体で同じ方向を向いて原因分析に取り組むこと
- 効果的かつ実現可能な再発防止策を導き出すこと
チャレンジ結果
- 【◎】QAが行った品質活動に、開発メンバー主導でチャレンジした実績ができた
- 【◎】原因分析を分科会で事前に実施し、課題が一定クリアになった状態で読合せができた
- 【◎】ポストモーテム前提でインシデント対応中に時系列を記録できていたことで、情報収集の負荷が軽減できた
- 【△】同じ方向をむいて原因分析するために重要なフィッシュボーンチャート等がカットされてしまったため、私にて再掲
- 【△】ポストモーテムの形式にとらわれすぎて、読合せ会の前半が資料の読み上げになってしまった
- 【△】後から資料を整理する時間がなく、資料が読みづらいまま
- 【◎】改善アクションを、QAタスクではなく開発チームのタスクとして進められている
このように、2回目のポストモーテムも概ね成功といってよい形で実施できたのではと思います。
特に原因分析について、分科会としてメンバーを絞って事前に実施したことで、必要十分な工数をかけて余計な圧などがない環境で議論ができ、より確度の高い分析ができたと感じています。 また、改善アクションについて、開発メンバーにて迅速に対応がなされて一部改善効果が出ており、効果的かつ実現可能な再発防止が進められています。
3. おわりに
その後、報告書が必要となる大規模のインシデントは発生していませんが、小規模のインシデント対応においても開発チームのメンバーから「ポストモーテムしましょうか」と声が上がり、ポストモーテムの実施が定着しつつあります。 また、ポストモーテムを意識した情報整理も意識されるようになり、別のインシデント対応において他システムの開発チームとの連携にも役立ちました。 今回のポストモーテムへのチャレンジは、今後の更なる「チームで品質保証」への取り組みの礎となると大いに期待しています。
今回のチャレンジができたのは何よりも、日ごろから開発・QA・デザイナー・事業メンバーが一丸となってアジャイルなチーム開発を進めていることにあります。 チームメンバーである塩井さんの記事『社会課題に取り組みたいRuby大好きエンジニアがセカンドキャリアにエス・エム・エスを選んだ理由』の中で「開発に責任感を持って真摯に向き合い、ごく自然にお互いに助け合うチームメンバー」とあるように、ウェルミージョブの開発チームでは、チーム全体へ働きかける形での品質向上へのチャレンジが歓迎されています。 tech.bm-sms.co.jp
これからも私は「チームで品質保証」のもと、異なる専門性を持つメンバーと協力してチーム全体で品質の向上を目指すべく、チャレンジを続けます。
告知!
ウェルミージョブの開発をリードする@moro が、この度「Kaigi on Rails 2025」にて初日のKeynote Speakerを務めます。 一昨年のKaigi on Rails 2023、そして去年のKaigi on Rails 2024でも大好評を博した@moroの基調講演にどうぞご期待ください！
Kaigi on Rails 2025 Keynote: dynamic!
昨年までの発表
Simplicity on Rails - RDB, REST and Ruby / MOROHASHI Kyosuke - Kaigi on Rails 2023
Identifying User Identity / MOROHASHI Kyosuke - Kaigi on Rails 2024
