Geo とディザスタリカバリ - ふりかえり
ふりかえりはアジャイル方法論の重要なコンポーネントです。ただし、ふりかえりを行うことは、アジャイルの ToDo リストにチェックを入れることについてであってはなりません。ふりかえりの目的は学ぶことであり、より良い場所に向かうアクションを起こすことです。私たちは過去のアクションと結果から学び、その知識を使って将来の実行を改善します。
Geo チームは、チームとそのメンバーにとってどのように機能しているかを振り返る方法として、月次のふりかえりを行います。目的は学ぶことであり、チームのミッションのコラボレーションと実行という点でより良いチームになることです。
ふりかえりは実行可能なチーム学習を可能にします。学習とは、ふりかえりが新しい知識やスキルの習得に繋がらなければならないという意味です。チーム学習とは、学習が個人に限定されるのではなく、チーム全体のためでなければならないという意味です。そして実行可能なチーム学習とは、チームが習得した知識やスキルが変化に繋がる可能性を持たなければならないという意味です。- David Horowitz（Retrium CEO 兼共同創業者）
アクティビティとケイデンス
ふりかえりのアクティビティは、チームで起きていることに応じてさまざまなテクニックを適用することで、月ごとに異なる場合があります。これはまた、ふりかえりを魅力的に保ち、繰り返しによる燃え尽き症候群を避ける方法でもあります。
ふりかえりは定期的なケイデンスで行われますが、Geo チームはスプリントではなくカンバンプロセスに従います。つまり、ふりかえりでの洞察とディスカッションは、必ずしも特定の時間枠に限定される必要はありません。
GitLab はリモートおよび非同期作業の価値を推進しています。私たちのふりかえりプロセスはこの価値を尊重しています。ただし、振り返りの時間は、より同期的な方法で行われるダイアログによってより良く機能します。チームメンバーが実行可能な洞察に繋がる意味のあるディスカッションを互いに行えることが不可欠です。このため、プロセスはオフラインコラボレーションのサポートで構築されていますが、ふりかえりのさまざまなフェーズのための確立されたスケジュールがあり、すべてのチームメンバーはスケジュールに従って参加することが期待されています。
参加者
Geo チームメンバー（必須）:
- すべての Geo エンジニア
- エンジニアリングマネージャー
- プロダクトマネージャー
オプション:
- テストエンジニア
- プロダクトデザイナー
招待による場合:
- Tenant Scale グループのプロダクトマネージャー
- Tenant Scale グループのエンジニアリングディレクター
スケジュール
ふりかえりは毎月の最終週（つまり、その月の最後の木曜日を含む週）の月曜日から木曜日にかけて行われます。全体として、週全体に分散した約 2.5 時間の時間投資となります。
ふりかえりには 4 つのフェーズがあります:
チェックイン（月曜日）
チェックインフェーズでは、エンジニアリングマネージャーがふりかえりのアクティビティを説明し、ディスカッションのコンテキストまたはスコープを定義し、すべてのチームメンバーが回答しなければならないチェックインの質問を投稿することでステージを設定します。チェックインの質問は、アイスブレーカーや人々がふりかえりに取り組む手助けとなる仕事関連の質問になる場合があります。
このメッセージは Slack を通じて送信され、すべてのチームメンバーはそれぞれのタイムゾーンで月曜日の終業時刻までにアクションを取ることが期待されています。アクティビティを読んで質問に答えるのに 5 分以上かかるべきではありません。
データ収集（月曜日〜火曜日）
チェックインの直後から、メンバーはデータ収集フェーズに参加することが期待されます。データの種類は、手元のアクティビティによって異なります。一般的に、個別にブレインストーミングを行い、ふりかえりボードにデータポイントを付箋としてレコードすることが含まれます。時には、データ収集が前の期間に起きた成果やイベントに関するメトリクスやその他の情報を取得することを含む場合もあります。データ収集は個々のメンバーに 25 分以上かかるべきではなく、月曜日から火曜日の間のいつでも行えます。
インサイト（水曜日）
このフェーズは、データの意味のある分析が行われる場所です。チームメンバーが互いに学び、実行可能な洞察を見つける場所です。
一日を通して、チームメンバーはボードに付箋として収集されたすべてのデータを読み、特定の Issue のコンテキストで書き込まれた会話スレッド（つまりコメント）で互いに質問することで会話を始めることが期待されます。このフェーズでは、特定された問題の「なぜ」を尋ねて根本原因に到達しようとするのに役立つ明確化の質問をすることが助けになります。
終業時には、すべてのチームメンバーがボードを最後に確認し、その日の後半に来た可能性のある最新のコメントを確認する必要があります。全体的に、チームメンバーはこの日のインサイト生成への参加に 1 時間以上を費やすことは期待されていません。
アクションとまとめ（木曜日）
ふりかえりの最終日に、チームは週の間に発見された洞察を確認し、アクションが必要かどうか、どのようなアクションが必要かを決定するためのミーティングを行います。このミーティングで、チームはまた、特定されたアクションに投票して優先順位をつけ、何が重要で短期的に実行可能かを評価して検出します。
すべてのチームメンバーは強く参加が奨励されています。これは月に一度のミーティングであり、同期コミュニケーションの合理的なコミットメントです。さまざまなタイムゾーンに対応するために、チームメンバーが参加するまとめミーティングの 2 つのオプションがあります。1 つは US/EAST-WEST タイムリージョンに位置する人に適したもので、もう 1 つは EMEA リージョン向けです。チームの所在地が変わるにつれて、ミーティングが常に通常の業務時間内に行われるようにスケジュールを調整します。
ふりかえりは、ふりかえり自体がどのように進んだか、調整が必要かどうかについての振り返りに役立つチェックアウトアクティビティで締めくくられます。
スケジュールの例外
これらのステージのそれぞれについて、PTO で不在の場合はスケジュールに従うことを免除され、PTO から戻ってきた際にプロセスに追いつくことができます。PTO を取る前の週にエンジニアリングマネージャーに事前に確認して、出発前に意見を提供することが奨励されています。
プライバシーと透明性
GitLab は透明性の価値を推進しているため、ふりかえりのアクティビティと収集されたデータはデフォルトで公開されます。ただし、誠実なフィードバックと高いエンゲージメントを促す安全な空間を作りたいと思っています。まとめの際には、非公開で共有すべきものを提起する機会があり、そこで会話を続けるための適切な権限を持つ新しい Issue を作成することができます。あるいは、GitLab の内部ノートを使用して、同じ Issue 内でこれらの会話を行うこともできます。
ふりかえりのハイライトは、記録保存としてチームメンバーがアクセスできる GitLab の Issue に記載されます。
