セキュリティコンプライアンスチーム

エピック階層

私たちのチームトップレベルエピックは単に、エピックの担当者 / 直接責任者 (DRI) のステータス更新の SSOT です。直近の子エピックには seccomp-roadmap ラベルが付けられ、エピックボードに表示され、事実上私たちのロードマップを構成します。

1. サブエピックは、言及されたアイテムを提供するために必要なタスクをグループ化します
2. サブエピックはロードマップのアイテムを表し、特定のフェーズで提供されます
3. サブエピックは複数月にまたがることがありますが、その終了日は追加されたロードマップフェーズの「予定完了日」と一致するべきです。

以下の図は、完全な階層をたどる例を示しています。

graph TD
A(Security Compliance top-level epic) --> B(SOC 2 Type 2 attestation)
B --> C([Epic])
B --> D([SOC 2 Type 2 Gap Assessment for GitLab.com])
B --> E([Expand SOC 2 TSC scope to include Availability criteria])
C --> G([Sub-epic])
E --> H([Q1 Continuous Control Monitoring])
E --> I([Q1 CCM: GitLab.com backend])
B --> F([...])
E --> J([...])
G --> K([Issue 1])

エピック担当者の責任

各エピックには、プロジェクトの提供に最終的な責任を持つ単一の DRI がいます。これは彼らがすべての作業を行うという意味ではなく、作業が進行していること、ブロッカーが迅速に対処またはエスカレーションされていること、そして毎週ステータスを報告していることを保証するという意味です。

DRI は次のことを行う必要があります。

1. 他者と連携して、Issue をボードを横断して移動させる（例えば、トリアージから進行中、完了へ）
2. エピックおよびネストされた子エピックと Issue が適切なラベルを使用していることを保証する
3. エピックがエピック構造（次のセクション）で概説されている基準を満たしていることを保証する
4. 達成事項、次のステップ、全体的な健全性ステータス、ブロッカーを含む、エピックのステータス更新を毎週提供する

エピック構造

私たちのトップレベルチームエピック直下の各子エピックには以下を含める必要があります（必要に応じてクイックアクションを調整してください）。

## Background

## Objective

## Exit criteria
- [ ]

<!--Edit Labels-->

/label ~"FY27-Q1" ~"seccomp-function::gap assessments"  ~"seccomp workflow::triage" ~"team::security compliance" ~"seccomp-roadmap" ~"ciso-workflow::process"
/health_status on_track
/due YYYY-MM-DD
/assign me
/set_parent &289

-----------
<!--DO NOT EDIT BELOW THIS LINE-->

<!--STATUS NOTE START-->

<!--STATUS NOTE END-->

下部のステータスノートコメントは、これらのエピックとチームエピックにステータス更新を自動投稿するために使用されるため重要です。

含めるべきエピックメタデータ

1. 担当者 は DRI であり、エピックが seccomp workflow::in progress に移動した時点で記入する必要があります
2. 開始日 は予想開始日に設定され、プロジェクトが開始されたら実際の開始日に更新されます
3. 期日 は予想終了日に設定されます
   1. 期日はロードマップに基づいて設定されます
   2. プロジェクトが実際に終了した日付は、エピックがクローズされた日付から取られます
4. 健全性ステータス は最新の状態に保たれるべきです（順調、注意が必要、リスクあり）

ラベルはラベルセクションで説明されています。

ロードマップ

すべてのエピックと Issue には、公式のロードマップに従って期日が設定されます。

エピックの期日 / ロードマップアイテムを更新するプロセス:

1. 各月末後、セキュリティコンプライアンスマネジメントはエピックの（予想される）期日をレビューし、エピックが計画されたフェーズを超える場合、エピックの担当者 / DRI と協力してロードマップの変更を判断します。
2. その後マネジメントはロードマップの調整を判断し、未完了の作業をシフトさせた後も将来のフェーズで計画されている作業が現実的であるようにします。
3. ロードマップの変更は次の週次同期で共有されます。

ステータス更新

私たちは、チームメンバーがステータス更新を一度だけ提供すればよく、マネジメントはそれをレビューするために常に1か所だけに行けばよいことを保証するために、自動化を活用しています。これは GitLab で歴史的に大きな問題でした。エピックと Issue がさまざまなサブグループとプロジェクトに分散していたためです。

セキュリティコンプライアンスロードマップに関連するすべての作業のステータスは、一目で見えるようにトップレベルチームエピックの説明に保持されます。

週次ステータス更新プロセス

DRI は次のプロセスに従って DRI のエピックの週次更新を提供する必要があります。

1. 毎週木曜日午後、アクティブなエピック（seccomp workflow::triage 以外のもの）のエピック担当者 / DRI は、エピックのコメントで @メンションされ、ステータス更新で返信するよう求められます。
2. 金曜日 17:00 UTC / 12:00 PM ET までに、アクティブなエピックの DRI（DRI が OOO の場合はカバーする人）は、子エピックと Issue の関連する詳細を含むエピックのステータスに関する更新を、エピックの説明のステータスセクションに提供します。
   • 子エピックの DRI がエピック DRI と異なる場合、エピック DRI は子エピック DRI から更新を取得する責任があります。
     • 週次更新のフォーマットは、以下の3つの項目それぞれについての簡潔な更新（〜1文または2〜3個の箇条書き）であるべきです。
       • 前回更新からの進捗 - 本番環境にデプロイされた変更、解消されたブロッカー、その他達成された進捗。
       • リスクと信頼度 - 新たに特定されたブロッカーや、継続している既存のブロッカーはありますか？現在または近い将来のその他の課題はありますか？これらのブロッカーや課題は、ロードマップによる予定期日までに完了することへの私たちの信頼度にどう影響しますか？
       • 緩和策 - 特定された課題やブロッカーを克服するために何が必要ですか？これは他のチームメンバー、チーム、エグゼクティブ、またはドメインエキスパートにエスカレートすべきですか？
   • ワークフローと健全性ラベルを更新する - 各ステータス更新後、ワークフローラベルと健全性ステータスを更新する必要があります。ラベル構造の詳細については、SecComp チーム Issue トラッカー Readme を参照してください。
3. トップレベルエピックステータス更新自動化は定期的に DRI のステータス更新返信コメントから更新を統合し、自動的にそのエピックとトップレベルチームエピックにステータスを記入します。
4. 効率を確保するために、Slack でのブロードキャストを含む、他の部門、ディビジョン、または OKR ステータス更新でも同じステータス更新を使用します。

バックログリファインメント

新しい四半期の開始前に、チームはエピックバックログのリファインメントに時間を費やします。このプロセスはチームマネージャーが主導し、ロードマップに従って次の四半期にターゲットされたエピックを確認し、各エピックに以下の情報が含まれていることを保証します（必要に応じて異なるステークホルダーを引き入れて詳細を埋めます）。

• 背景（例: コンテキストとこの作業の目的を提供する。それは何で、なぜ関連するのか？）
• 目的（計画/解決策を説明する SMART な目標: Specific, Measurable, Achievable, Relevant, Time-bound）
• 終了基準（作業をより小さな論理的なチャンクに分割し、依存関係と前提条件を強調する）

上記の情報が追加されると、エピックは Triage から Ready ステータスに移動します。目標は、その四半期の計画されたロードマップアイテムを Ready リストに含めて各四半期を開始することです。