quality-postmortem

構造化された、責任追及を伴わない振り返りを通じて、リリース後に発覚した欠陥、テストスイートの健全性、品質プロセスのギャップを分析します。各振り返りでは、曖昧な「もっと注意する」といった決意ではなく、具体的で追跡可能なアクションアイテムを1〜3件作成します。目標は、個人を責めることではなく、システムを改善することです。

---

クイックルート

状況	移動先	テンプレート
分析したいリリース後に発覚したバグが1件ある	バグパターン分析	リリース後に発覚したバグの分析（references/templates.md）
リリース後に発覚したバグが10件以上あり、傾向を探したい	時間をかけてパターンを集約する	—
事前に四半期ごとの点検を行う（インシデントなし）	テストスイートの健全性レビュー	—
P0/P1の本番インシデントが発生した	品質インシデントの振り返りテンプレート	references/templates.md
スプリントごと／月ごとに定期レビューを行う	レトロミーティングのテンプレート	references/templates.md

---

確認事項

まず、プロジェクトルートにある .agents/qa-project-context.md を確認してください。品質目標、リスク領域、テストスイートの詳細が記載されており、振り返りの土台となります。その内容を活用し、すでに回答されている項目は省略してください。そのうえで、次の点を確認します。

1. 定期的なレトロの実施ペースは決まっていますか？ スプリントごと、月ごと、またはインシデント発生時のみでしょうか？ 定期的に実施すれば、徐々に進行する問題を早期に発見できます。インシデント発生時のみでは、問題が深刻化するまでパターンを見逃します。

2. 何が今回の振り返りのきっかけになりましたか？ 本番インシデント、リリース後に発覚したバグの傾向、テストスイートの検出力不足への懸念、テストスイートの劣化のいずれでしょうか？ きっかけによって焦点が決まります。

3. どのようなデータを利用できますか？ 重大度や発見フェーズが記録されたバグトラッカー、CIの合格率履歴、不安定なテストのレポート、カバレッジの推移はありますか？ データがなければ、振り返りは意見交換だけに終わってしまいます。

4. 過去の振り返りで決めたアクションアイテムはどうなりましたか？ 完了しましたか？ 追跡されていましたか？ 忘れられていませんか？ 過去のアクションアイテムが放置されているなら、チームは振り返りに意味がないと学んでしまっています。次の振り返りを行う前に、実行の徹底を改善してください。

5. 誰が参加すべきですか？ 影響を受けた領域を担当したエンジニア、その領域をテストした（またはテストしなかった）QA、影響がユーザーに及んだ場合はプロダクトオーナー、システム的な変更が必要ならエンジニアリングマネージャーが対象です。参加者は4〜8人に抑えてください。

6. 現在、テストスイートの健全性についてどのような懸念がありますか？ 不安定さの増加、実行時間の長さ、重要領域のカバレッジ不足、古い隔離テストなどでしょうか？ 健全性レビューは、インシデントへの対応ではなく未然防止を行う、事前の振り返りです。

---

基本原則

1. 責任追及を避けるとは、システムに注目することです

責任追及を避けることは、「誰にも責任がない」という意味ではありません。個人のパフォーマンスではなく、システム、プロセス、ツールに焦点を当てて分析するという意味です。「なぜこの欠陥がシステムから漏れてしまったのか？」は、責任追及を伴わない問いです。「なぜ開発者はテストを書かなかったのか？」は、分析を早々に打ち切る責任追及の問いです。開発者がテストを書かなかった背景には、テストフレームワークが使いにくかった、PRチェックリストにテスト作成が求められていなかった、知識を共有するペア作業がなかった、時間のプレッシャーによりテストが任意に感じられた、といった理由が考えられます。これらは、システム的な解決策を必要とするシステム上の問題です。

2. インシデントではなく、パターンに注目することです

リリース後に発覚したバグが1件あっても、それは単なる一例です。2か月間に同じ機能領域でリリース後に発覚したバグが3件あれば、それはパターンです。振り返りでは、インシデントを集約して、同じ根本原因、同じチーム、同じテスト上のギャップ、パイプラインの同じフェーズといった、繰り返し現れる傾向を探してください。パターンなら具体的な対応につなげられます。個別のインシデントへの対応は、火消しにすぎません。

3. 各振り返りにつき、具体的なアクションアイテムを1〜3件設定することです

具体的なアクションアイテムには、明確な成果物（「クーポンAPIの統合テストを追加する」）、担当者（「Alexに割り当てる」）、期限（「スプリント14の終了まで」）、検証方法（「PRがマージされ、CIでテストが合格する」）が必要です。「テストを改善する」ではアクションアイテムになりません。「3月30日までに、決済サービスのエッジケースを対象とした統合テストを5件作成する」なら、アクションアイテムになります。

4. 完了まで追跡する

追跡されていないアクションアイテムは、完了していないのと同じです。チームがすでに使っているタスク管理ツール（Jira、Linear、GitHub Issues）を使用し、postmortem-action などのタグを付けてください。次回のポストモーテムの開始時に、完了状況を確認します。アイテムが継続的に放棄されている場合は、アイテムの規模が大きすぎる（細分化する）か、優先順位が低すぎる（スプリントのコミットメントにする）かのどちらかです。

5. 1つではなく2つの指標で改善を測定する

アクションアイテムを実施した後、問題が再発したかどうかを測定してください。ポストモーテムで決済テストの不足が特定され、統合テストの追加がアクションになった場合は、別の決済バグが流出したかどうかを追跡します。測定しなければ、ポストモーテムはツールではなく、ただの儀式です。

次の2つの指標をあわせて追跡してください：

• 欠陥流出率（同様のバグが再発したか？）
• アクションアイテム完了率（確約した期間内に完了したアクションアイテムの割合）

完了率が高いのに流出率が上昇している場合、チームは作業を進めていますが、取り組む内容を間違えています。完了率が低い場合、ポストモーテムは形だけのものです。最新のインシデント対応プラットフォーム（incident.io、Rootly、FireHydrant）では、担当者、期限、完了状況などのアクションアイテムのフォローアップが標準で追跡されます。ダッシュボードを構築する前に、すでにある情報から両方の数値を算出してください。

6. AIがタイムラインを下書きし、人間が判断を担う

チームでAI SREツール（Rootly AI SRE、incident.ioのAI SRE／自動下書きポストモーテム）を使用している場合は、ログやトレースからインシデントのタイムラインを下書きさせ、考えられる根本原因を提案させてください。その後、対応を指揮したインシデントコマンダーとは別に、指名された非難を伴わないRCA担当者が5 Whysを実施し、実際の根本原因を選定して、アクションアイテムを作成します。AIはノイズの多いデータを横断した相関分析は得意ですが、何が重要だったかを判断するのは苦手です。AIの出力は結論ではなく、出発点として扱ってください。タイムラインを手早く下書きするにはSonnet 4.6で十分です。因果関係が曖昧な場合に、より大規模なモデルを使用してください。

---

バグパターン分析

流出した欠陥の分類

バグが本番環境に到達した場合、予防の機会を特定するために、3つの観点から分類してください。個別のバグ分析ワークシート（Escaped Bug Analysis）は references/templates.md にあります。

観点1：根本原因のカテゴリ

カテゴリ	説明	例
ロジックエラー	ビジネスロジックに誤りがある、または不完全	特殊な通貨のケースで割引が適用されない
統合の失敗	2つのコンポーネントが正しく連携しない	APIがフロントエンドの想定と異なる形式を返す
データの問題	想定外のデータ形式、null値、エンコーディング	名前に絵文字を含むユーザーがいるとCSVのエクスポートが失敗する
競合状態	タイミングに依存する動作	同時に実行された2件のチェックアウトにより、最後の1点が過剰販売される
設定	環境固有の設定が誤っている	ステージングでは機能フラグが有効だが、本番では無効
リグレッション	以前は動作していた機能が壊れる	リファクタリングでnullチェックが削除され、以前のバグが再発する
要件の欠落	動作が仕様化されておらず、プロダクト仕様に漏れがある	期限切れのOAuthトークンに対するエラー処理がない
パフォーマンス	機能はするが、負荷時に遅すぎる	10万件以上のレコードがあると検索がタイムアウトする

観点2：どのテストレベルで検出すべきだったか

レベル	検出できるもの	このレベルをすり抜けた場合
ユニット	ロジックエラー、エッジケース、境界条件	テストはあるが、エッジケースが抜けていた？ それともテスト自体がなかった？
統合	APIコントラクト、データフロー、サービス間の連携	統合テストはある？ エラー応答を対象にしている？
E2E	ユーザージャーニーの失敗、UIの状態管理	このクリティカルパスはテスト対象になっている？ 具体的なシナリオをテストした？
手動／探索的	視覚上の問題、ユーザビリティの問題、通常と異なるワークフロー	探索的テストを実施した？ この領域は対象範囲に含まれていた？
モニタリング	パフォーマンスの低下、エラー率の急増	アラートは設定されている？ しきい値は適切？

ディメンション 3：予防の機会

機会	アクション	例
テストの追加	適切なレベルでテストを作成する	通貨の丸め処理におけるエッジケースの単体テストを追加する
既存テストの改善	既存のテストの範囲が狭すぎました	チェックアウトの E2E にクーポンと外貨を含める
品質ゲートの追加	CI チェックで検出できたはずです	CI で API レスポンスのスキーマ検証を追加する
要件の改善	仕様が曖昧または不完全でした	ストーリーテンプレートにエラー状態の受け入れ基準を追加する
モニタリングの追加	防止できなくても、より早く検出する	決済エンドポイントのエラー率が 1% を超えた場合のアラートを追加する
トレーニング／プロセス	知識またはプロセスの不足	null 許容フィールドに対する防御的コーディングのセッションを開催する

時間の経過に伴うパターンの集約

本番に流出したバグを 10 件以上分析した後、パターンを探します。

Escaped Bug Summary: [Q1 2026]
═══════════════════════════════

Total escaped bugs: 14

By root cause:
  Logic error:          5  (36%)  ← unit tests needed
  Integration failure:  4  (29%)  ← API contract tests needed
  Data issue:           3  (21%)  ← input validation gaps
  Configuration:        2  (14%)  ← env parity issues

By area:
  Checkout:             6  (43%)  ← highest risk, needs investment
  User management:      4  (29%)
  Reporting:            2  (14%)
  Settings:             2  (14%)

By should-catch level:
  Unit:                 5  (36%)  ← developers not testing edge cases
  Integration:          4  (29%)  ← missing integration test layer
  E2E:                  3  (21%)
  Monitoring:           2  (14%)

Top action themes:
  1. Add integration tests for checkout API (covers 4 of 14 bugs)
  2. Mandate unit tests for all calculation/validation logic (covers 5 of 14)
  3. Add currency and encoding edge cases to test data fixtures (covers 3 of 14)

この集約により、どこへの投資が最も高い効果をもたらすかが明らかになります。システム上の問題を 1 つ（チェックアウトの統合テスト）修正するだけで、本番に流出したバグ全体の 29% を防げたはずです。複数の四半期にわたって繰り返し現れるパターンは、次のスプリントのアクションアイテムだけでなく、test-strategy ドキュメントに記載してください。それらを昇格させ、実際にどこで欠陥が流出しているかを戦略に反映させます。

---

テストスイートの健全性レビュー

テストスイート自体を対象とした、予防的なポストモーテムです。四半期ごと、または兆候が見られたときに実施します。

不安定なテストの傾向

Flaky Test Trend Review
═══════════════════════

Current flaky rate: _____ % (target: <2%)
Trend (last 3 months):
  Month 1: _____ %
  Month 2: _____ %
  Month 3: _____ %
Direction: [ ] Improving  [ ] Stable  [ ] Worsening

Top 5 flakiest tests (by failure count):
  1. _____________________ — _____ failures — root cause: _____
  2. _____________________ — _____ failures — root cause: _____
  3. _____________________ — _____ failures — root cause: _____
  4. _____________________ — _____ failures — root cause: _____
  5. _____________________ — _____ failures — root cause: _____

Quarantine:
  Tests in quarantine:    _____ count
  Oldest quarantine:      _____ days (target: <14)
  Quarantine resolved this month: _____ count

実行時間の傾向

現在の全テストスイートの実行時間、3 か月間の傾向、実行時間が最も長い 5 件のテストを追跡します。実行時間が増加している場合は、夜間実行に移せるテスト、並列化できる逐次ステージ、時間のかかるテストデータのセットアップ（UI ではなく API を使う）、シャードへの分散を改善するために分割が必要な大きなテストファイルがないか確認します。

カバレッジのギャップのレビュー

全体のカバレッジ（行／分岐）、カバレッジが不十分な重要パス（決済、認証、データエクスポートは 90% 以上にする必要があります）、テストが更新されていない最近の変更コード（git log --since="30 days ago" とカバレッジレポートを相互参照する）、E2E カバレッジなしでリリースされた機能を追跡します。

無効化／スキップされたテストの一覧

スキップまたは無効化されたテストを、経過期間と理由で監査します。スキップから 1 週間未満のテストは、作業中である可能性が高いです。1～4 週間スキップされているテストには、チケットとスケジュールが必要です。1～3 か月スキップされているテストは期限を過ぎています。修正するか削除してください。3 か月を超えてスキップされているテストは削除してください。今後も修正されることはありません。それぞれについて、修正してスキップを解除する、削除する（古くなった場合）、またはチケットへのリンクを添えて隔離する、のいずれかを行います。

---

プロセス改善サイクル

改善スプリント

各スプリントの固定割合（キャパシティの 10～15%）を品質改善に充てます。ポストモーテムのアクションアイテムと健全性レビューの指摘事項をもとにします。

構成：

1. IDENTIFY    — Top 3 pain points from latest retro/postmortem
2. ROOT CAUSE  — 5 Whys analysis for the #1 pain point
3. PROPOSE     — Solution with effort estimate (S/M/L)
4. IMPLEMENT   — One improvement per sprint (start small)
5. MEASURE     — Did the metric improve? By how much?
6. ITERATE     — If not improved, dig deeper. If improved, tackle #2.

5 Whys 根本原因分析

5 Whys 手法では、表面的な症状を掘り下げ、システム上の原因を明らかにします。重要な規律は、個人の行動ではなく、プロセス、システム、または構造上の原因にたどり着くまで「なぜ」と問い続けることです。

例：決済のバグが本番環境に流出

Problem: Users were charged twice for a single purchase.

Why 1: The payment API was called twice on form submit.
Why 2: The submit button was not disabled after the first click.
Why 3: The frontend developer did not implement button disabling.
Why 4: The acceptance criteria did not mention double-submit prevention.
Why 5: The story refinement process does not include edge case review
       for payment-related stories.

Root cause: Process gap — payment stories are not reviewed for transaction
safety edge cases before development begins.

Action: Add a "Payment Safety Checklist" to the story template for any
story touching payment flows. Checklist includes: idempotency,
double-submit prevention, partial failure handling, timeout behavior.
Owner: [Product Manager] — Due: [Next sprint]

5 Whys のガイドライン：

• チームが変更できるもの（プロセス、ツール、構造）にたどり着いたら、そこで止めます。「なぜ予算が限られているのか」と問うのは行き過ぎです。
• 原因の連鎖が枝分かれすることもあります。1 つの症状に複数の要因が関係する場合があります。最も影響の大きい枝をたどります。
• それぞれの「なぜ」は、推測ではなく証拠で確認します。「開発者がテストを書かなかった」は事実でしょうか。PR を確認してください。テストはあったものの、不十分だったのかもしれません。
• 根本原因が「ヒューマンエラー」に行き着いた場合、掘り下げが足りません。人は間違いを犯します。システムによって、間違いを起こしにくくするか、検出できるようにする必要があります。

工数見積もりを伴う解決策の提案

根本原因ごとに、工数の異なる解決策を 1～3 件提案します。繰り返し発生する不安定なテストの問題に対する例：

Root Cause: E2E tests fail intermittently on async-loaded content

Solution A (Small — 1 day):
  Replace fixed waitForTimeout calls with explicit wait-for-condition
  assertions in the 5 flakiest specs.
  + Quick to implement, kills the most common flake source
  − Manual, one spec at a time; new flakes can creep back in

Solution B (Medium — 1 sprint):
  Solution A across the suite + add a flaky-test detector to CI that
  reruns failures once and tags any test that passes on retry.
  + Automated detection, surfaces flakes before they erode trust
  − Requires CI config change; reruns add pipeline time

Solution C (Large — 2 sprints):
  Solution B + auto-quarantine tagged tests and route them to an
  owner-assigned backlog with a 14-day fix-or-delete SLA.
  + Self-healing trust in the green build; flakes can't block releases silently
  − Needs quarantine infrastructure and ownership process buy-in

Recommendation: Start with A immediately, implement B this sprint,
plan C for next quarter as strategic work.

---

ポストモーテムと振り返りのテンプレート

references/templates.md には、詳細なコピー＆ペースト形式のテンプレートが 2 つあります。

• 品質インシデント向けポストモーテムテンプレート — P0／P1 の本番環境のバグ、データ損失、セキュリティ問題、またはコード変更による障害向けです。概要、重大度／影響、UTC のタイムライン表、根本原因、5 Whys、存在したテスト／不足していたテスト、検出、即時／短期／長期のアクション項目表、学んだ教訓を含みます。
• 振り返りミーティングのテンプレート — 定期的なスプリント／月次の品質振り返り向けです。7 つのセクションから成る 30～60 分のアジェンダ（前回のアクション項目の確認 → データの確認 → うまくいったこと → 改善が必要なこと → 根本原因の議論 → 新たなアクション項目 → 締めくくり）と、ファシリテーター向けメモが含まれます。

どちらも、前回の振り返りのアクション項目を確認するところから始まります。このクローズドループが説明責任を果たす仕組みです。これがなければ、項目は気づかれないまま消えていきます。

---

アンチパターン

責任追及に偏ったポストモーテム

ミスが本番環境に到達するのを許したシステムではなく、ミスを犯した人に焦点を当てることです。責任追及は恐怖を生みます。恐怖は隠蔽を生みます。隠蔽は、より大きなインシデントを生みます。「誰がこのバグを書いたのか？」が問いであれば、人々は問題を表面化させないようになります。「どのプロセス上の欠陥がこれを許したのか？」が問いであれば、人々はプロセスの改善を学びます。

アクション項目のないポストモーテム

理解は深まっても変化を生まない、気持ちを吐き出すだけの議論です。具体的な担当者を割り当てたアクション項目を設定せずにミーティングを終えると、同じ問題が再発します。さらに悪いことに、チームはポストモーテムを改善のためのツールではなく、セラピーの場だと学んでしまいます。

フォローアップされないアクション項目

アクション項目を作成しても、バックログに入り、優先順位が付けられないままになることです。改善したかのような錯覚を生むため、アクション項目がないよりも悪い状態です。ポストモーテムのアクションが 2 スプリント以内に完了しない場合は、エスカレーションしてください。アクション項目が頓挫する理由には、予測可能なものがあります。「忘れていた」と責める前に、このチェックリストを使って完了率を監査してください。

• 担当者がいない。 チームに割り当てられた項目は誰の仕事にもなりません。対策：着手に必要なコンテキストを十分に持つ、名前が明確な担当者を割り当てます。
• 期限がない。 「近いうち」は期限ではありません。対策：具体的なスプリントまたは日付を指定します。
• 範囲が大きすぎる。 「テストフレームワークをリファクタリングする」は 1 スプリントで完了できません。対策：それぞれを 1 つの PR に収まる項目に分割します。
• 次回の振り返りの冒頭で確認しない。 確認の機会を強制しなければ、項目は気づかれないまま消えていきます。対策：すべての振り返りの冒頭に、クローズドループの確認を行う予定枠を定例として設定します。
• 指標が設定されていない。 項目を完了しても、名前を挙げられる数値が変わらないのであれば、効果があったかどうかを判断できません。

反対のパターン：すべての振り返りの冒頭で、5 分間の「前回のアクション項目」レビューを行います。それぞれを「完了」「進行中（現在の完了予定日を記載）」「取り下げ（理由を記載）」として記録します。

インシデント発生後にしか行わないポストモーテム

本番環境で障害が起きるまで品質レビューを待つことです。テストスイートの健全性、カバレッジの傾向、不安定なテストの一覧など、先回りした健全性レビューによってインシデントを防げます。先回りしたレビューを毎月実施してください。インシデント後のポストモーテムは、先回りした定期レビューを補完するものであり、置き換えるものではありません。

根本原因分析を早々に打ち切る

「開発者がテストを書かなかった」は根本原因ではありません。症状です。なぜテストを書かなかったのでしょうか？ フレームワークが使いにくかったのでしょうか？ 時間がなかったのでしょうか？ 要件がなかったのでしょうか？ ペア作業やレビューがなかったのでしょうか？ 個人のレベルで打ち切ると、システム全体の改善を妨げます。

曖昧なアクション項目

「テストカバレッジを改善する」や「デプロイをもっと慎重に行う」は、アクション項目ではありません。追跡、測定、検証ができません。次の例と比較してください。「決済 Webhook の処理に、成功、失敗、タイムアウトのシナリオを含む統合テストを追加する。担当者：Alex。期限：Sprint 14。検証方法：統合テストを 3 件追加した PR がマージされ、CI ですべて成功していること。」

データを使わない振り返り

データではなく、感覚や意見に基づいて品質の振り返りを行うこと。「最近、バグが増えている気がする」というのは、事実かもしれませんし、直近の出来事を過大評価しているだけかもしれません。データを確認してください。実際に流出したバグの件数は増えているでしょうか。バグはどこに集中しているでしょうか。データがなければ、チームは最も重要な問題ではなく、最も声の大きい問題を解決することになります。

---

検証

成果物は、文書化されたポストモーテムと、追跡可能で完了まで管理されるアクションアイテムです。まずは最小限の確認で、確実に実行されたことを証明してください。

# Every action item became a real, owned, dated ticket — not a doc bullet.
# (gh example; swap for `jira issue list` / Linear API as appropriate)
gh issue list --label postmortem-action --json number,title,assignees,milestone \
  | jq '[.[] | select(.assignees == [] or .milestone == null)]'
# Expect: []  (empty). Any item missing an owner or due milestone is not done.

# The escaped defect's timeline is reconstructable from evidence, not memory.
git log --since="<introduced-date>" --until="<detected-date>" --oneline -- <affected/path>
# Expect: the introducing commit is in this range and named in the postmortem.

# The fix/regression test the action item promised actually exists and passes.
git log --grep="<INCIDENT-ID>" --oneline      # the fix commit references the incident
<your test runner> <new regression test path> # exits 0

次に、内容を読んで確認してください。5 Whys がプロセス／ツール／構造に関する原因に行き着いていること（「開発者がテストを書かなかった」ではなく）、アクションアイテムの完了率と流出欠陥率の両方が記録されていること（片方だけではない）を確認します。

完了条件

• コミット履歴とバグトラッカーの証拠に基づいて、流出した欠陥の時系列（発生、リリース、検出、解決）を再構成していること。
• 5 Whys による根本原因分析を完了し、「開発者がテストを書かなかった」ではなく、システム上の原因（プロセス／ツール／構造）で分析を終えていること。
• テストのギャップを特定し、具体的なカバレッジの欠落（不足しているテストの種類、シナリオ、または領域）に結び付けていること。
• 担当者の氏名と期限を指定したアクションアイテムを割り当て、ポストモーテムタグを付けてチームの作業トラッカーに追加していること。
• 調査結果を文書化した要約としてチームに共有していること。QA に閉じ込めたり、非公開の文書に埋もれさせたりしていないこと。
• アクションアイテムの完了率を、流出欠陥率と合わせて追跡していること（片方だけではなく両方）。インシデントのポストモーテムでは、どちらもインシデントプラットフォームの標準のフォローアップ追跡機能から算出できます。
• AI SRE ツールを使用している場合、AI が作成した時系列と根本原因の候補を入力として記録し、担当者名を明記した非難を伴わない RCA 責任者（インシデントコマンダーではない）が、人間の手で作成した 5 Whys とアクションアイテムを承認していること。

関連スキル

• qa-metrics — ポストモーテムで分析し、対応するデータ（欠陥流出率、不安定なテストの割合、カバレッジの傾向）を提供します。継続的なダッシュボードにはこれを使用し、分析セッションにはこのスキルを使用してください。
• test-reliability — 不安定なテストの分類と隔離管理を行い、テストスイートの健全性レビューに活用できます。
• test-strategy — ポストモーテムで四半期をまたいで繰り返し発生するシステム上のギャップが判明した場合、更新する文書はテスト戦略です。
• shift-left-testing — ポストモーテムのアクションアイテムの多くは、より早い段階でのテスト、より適切な要件、開発と QA の連携など、シフトレフトの実践に関するものです。
• release-readiness — ポストモーテムの調査結果に基づいて、品質ゲートとリリース基準を更新する必要があります。実際のリリース可否の判断にはこれを使用し、振り返り分析には使用しないでください。

参考ファイル（references/ 内）

• templates.md — 品質インシデント向けポストモーテムテンプレート、振り返りミーティングテンプレートとファシリテーター向けメモ、単一バグ向けの流出バグ分析ワークシートをコピーして使用できます。