Getting Started

PagerDuty

レトロスペクティブとは?#

レトロスペクティブは、通常2週間ごとのケイデンスで、または大規模プロジェクトの完了後に60〜120分間行われる構造化されたミーティングです。チームが自分たち自身を検証し、今後の協働方法を改善するための計画を作成する機会を提供します。

レトロスペクティブは、チームメンバーがチームにとって何がうまくいっているか、何を改善できるかについて正直なフィードバックを共有するための安全な場を作ることを目的としています。レトロスペクティブでは、チームのコラボレーションを改善する方法についての議論が生まれ、文書化され、将来(例えば、次のレトロスペクティブで)フォローアップできるアクションアイテムが生成されます。

なぜレトロスペクティブを行うのか?#

レトロスペクティブは、チームが相互作用とプロセスの継続的改善の実践を確立するのに役立ちます。これは、チームが「何を」提供するかではなく、「どのように」提供するかを振り返ることで達成されます。

レトロスペクティブは透明性と信頼を生み出します。 チームに問題と成功事例の両方について議論することを促します。良いこと、悪いこと、醜いこと、そしてその間のすべてについて正直で透明であることは、チームメンバー間の信頼を構築します。

レトロスペクティブはチームがリスクを早期に発見することを可能にします。 チームができるだけ早くブロッカーを明らかにすることができます。チームメンバーが快適に感じれば、彼らは後になってからではなく、より早く懸念を提起し、チームに反応する時間をより多く与えます。

レトロスペクティブはチームメンバーに権限を与えます。 チームメンバーは自分たちのアクションアイテムと変更を定義し、所有します。チームメンバーが集団的な決定に基づいて行動する権限を与えられているため、これらの変更を実行することへの抵抗はほとんどありません。したがって、これはチームに力を戻します。

誰が関わるのか?#

誰が関わるのか

ファシリテーターの役割#

レトロスペクティブにおけるファシリテーターの役割は、他の参加者とは異なります。

ファシリテーターはミーティングで自分のアイデアを表明しません。彼らはグループに発言を促し、議論を軌道に乗せます。これには大きな認知的負荷がかかるため、この役割をうまくこなしながら、議論に個人的な考えをもたらそうとするのは難しいです。そしてレトロスペクティブを成功させるためには、あえて議論に参加しようとしない進行役がいることが大事なのです。

ファシリテーターの役割は以下の通りです:

ファシリテーターがしないこと:

参加者の役割#

参加者の役割は以下の通りです:

参加者がしないこと:

レトロスペクティブとポストモーテムの違い#

あなたはすでにPagerDutyのポストモーテムOpsガイドを読んでいるかもしれず、レトロスペクティブがポストモーテムとどのように異なるのか疑問に思っているかもしれません。

ポストモーテムもまた、チームに振り返りの機会を提供する構造化されたミーティングですが、いくつかの重要な点で異なります。最大の違いはミーティングの目的です:ポストモーテムはインシデントへの対応を振り返るためのものであり、一方レトロスペクティブはチームが定期的なケイデンスで進捗、ペース、デリバリーを振り返ることを可能にします。主な違いは以下の表にまとめられています:

ポストモーテム レトロスペクティブ
目的 インシデントに関する分析を行うこと。これには以下が含まれます:表面的および寄与する要因の特定、技術とプロセスの検討、アクションアイテムへの賛同の獲得。 定期的なケイデンスで継続的改善を促進し奨励すること。チームの進捗、ペース、デリバリーをレビューすること。チームのコラボレーションを改善する方法を考えること。チームが最後のケイデンスで彼らの仕事に影響を与えたことについて何でも議論できる安全な場所を持つこと。チームが最後のケイデンスでどのように感じたかの「健康チェック」または「温度測定」を得ること。
発生時期 インシデント後 通常、定期的なケイデンス(例:2週間ごと)で
スタイル インシデントに直接関わったチーム間の議論。サンプルのインシデントポストモーテムのアジェンダはこちらで見つけることができます。 通常、チームメンバー間の非公式な議論。様々なスタイルを通じて進行することができます。
議論のトピック ポストモーテムレポートの要約をレビューします。これには、インシデントの寄与要因、タイムライン、解決のために取られたアクション、顧客への影響などが詳細に記載されています。 強みの領域と改善の領域、最後のケイデンスでのチームの感情、懸念や質問の領域についての振り返り。
参加者 インシデントコマンダー、インシデント対応者、関与したSME(対象分野の専門家)、サービスオーナー、影響を受けたシステムのエンジニアリングマネージャーなど チーム。その他の必要な役割。不必要な参加者の数を最小限に抑える。管理職の出席を避ける。