Security Policies - プランニング

このページでは、Security Policies グループ固有のプランニングおよび開発プロセスについて説明します。ステージレベルの SRM プランニングプロセスについては、SRM プランニングページ を参照してください。

プランニングの進め方

私たちのプランニングは、四半期ごとのインターロック駆動型アプローチに従います。各四半期、ディレクター、プロダクトマネージャー（PM）、エンジニアリングマネージャー（EM）がインターロックプロセスを通じて高レベルの製品ロードマップを調整します。これにより、次の四半期以降にチームが注力するエピックとフィーチャーが決まります。

四半期計画が確定したら、EM が個人コントリビュータ（IC）と協力して、各エピックにバックエンドとフロントエンドの DRI を割り当てます。エンジニアは一方的に割り当てられるのではなく、特定のエピックのオーナーシップを取りたいかどうか確認されます。

マイルストーンレベルのプランニングは非同期で処理されます。EM は各マイルストーンでプランニング Issue（例参照）を作成し、チームが提供すべき作業を収集・整理します。Issue はマイルストーン開始前または最初の週中にエンジニアに事前割り当てされます。

キャパシティ配分

デフォルトでは、以下のキャパシティ配分を目標とします:

• ~80% フィーチャー提供（エピック作業、インターロックコミットメント）
• ~20% バグ修正、リファクタリング、技術的負債

これはガイドラインであり、厳格なルールではありません。EM は現在のバグバックログ、直近の締め切り、チームの状態に基づいて配分を調整します。

3フェーズリリースプラン（Experiment → Beta → GA）

現在または次の四半期に計画されているインターロックレベルおよびエピックレベルのフィーチャーに対して、デフォルトで段階的リリースアプローチに従います:

これは柔軟性を持ったデフォルトのガイドラインです。フィードバックをより早く収集するために Experiment を早期に出荷したり、スケジュールより前倒しで Beta に移行したりすることがあります。正確なフェーズはエピックの複雑さとチームの自信度によって異なります。EM と DRI はエピックプランニング中にフェーズについて合意する必要があります。

GitLab の成熟度ステージの詳細については、Development Stages and Support を参照してください。

エピックのスパイクファーストアプローチ

新しいエピックまたはインターロックアイテムが計画されたとき、そのアイテムがインターロックされる四半期が始まる前に****スパイク（タイムボックス化された技術的探索）から始めます。これにより、チームは検証されたアプローチと準備の整った実装計画を持って四半期に入ることができます。

スパイクの目標は以下のとおりです:

1. 動作するソリューションの概念実証（PoC）を構築します。
2. 多大な時間を投資することなくアプローチが実現可能であることを証明します。
3. 適切な場合には最新の AI ツールを活用して PoC 開発を加速します。

PoC がフィーチャーの実現可能性を示したら、DRI は実装計画と個別の実装 Issue の作成に進みます。このアプローチは、完全な実装にコミットする前に技術的な仮定を早期に検証することでリスクを低減します。

週次チームミーティング

チームは週次チームミーティングを開催し、PM が今後の優先事項を共有したり、チームが質問する時間を持てます。目標は、チームが今後の作業の意図とスコープを確実に理解することです。

バックエンドをフロントエンドより先に

エピックにバックエンドとフロントエンドの依存作業がある場合、可能であればバックエンドの Issue をフロントエンドの1マイルストーン前に計画します。これにより以下が確保されます:

• フロントエンドエンジニアが統合するための安定した API を持てます。
• バックエンドの作業がマイルストーンの終わりに完了し、フロントエンド統合の時間がなくなることを防ぎます。
• エピック全体の提供がより予測可能になります。

これは依存する作業のガイドラインです。バックエンドとフロントエンドが独立している場合は、同じマイルストーンに計画できます。

週次トリアージ

EM は新たにオープンされた Issue の週次非同期トリアージを実施します。トリアージ中、各 Issue には以下が付与されます:

• 優先度と重大度ラベル
• 担当者（対応するエンジニア）
• 計画マイルストーン

これにより、新しい Issue が迅速に分類・スケジュールされ、チームの現在の作業をブロックしないようにします。

リファインメント

Security Policies グループは、ステージレベルのリファインメントガイドライン と比較して軽量なリファインメントアプローチを採用しています。リファインメントは、Issue に割り当てられた個々のエンジニアの責任です。正式なハンドオフを伴う独立したワークフローステップではなく、リファインメントはマージリクエストの提供プロセスに組み込まれています。

リファインメントの目標は変わりません:

• 未解決の質問や議論を特定して解決します。
• 不足している依存関係（例: backend API）を特定します。
• 質問、懸念事項、または代替アプローチを提起します。
• 実装計画を概説します。
• Issue にウェイトを割り当てます。

リファインメントの進め方

1. Issue に割り当てられたエンジニアがその完全性と明確さをレビューします。
2. Issue が複雑である場合、またはエンジニアが別の意見を求める場合は、リファインメント計画を作成して別のチームメンバーにレビューを依頼できます。これは任意であり、必須ではありません。
3. Issue が単純な場合、エンジニアは直接 MR の作成に進み、リファインメントを MR 提供プロセスの一部として扱います。
4. エンジニアはソリューションを解決する中で、Issue の説明を 実装計画 と 検証手順 で更新します。

このアプローチは、独立した workflow::refinement ステップを排除することで摩擦を軽減しながら、エンジニアがコーディング前にアプローチを考え抜くことを確実にします。複雑な Issue では、レビューのセーフティネットが引き続き利用できます。

バグ、スパイク、セキュリティ Issue については、SRM プランニングページ のガイドラインに従ってください。

エピックの完了の定義

エピックは、以下のすべての基準が満たされた時に完了とみなされます:

機能的な完全性

• フィーチャーが受け入れ基準に従って動作している。
• フィーチャーフラグロールアウト Issue より上のすべての実装 Issue がクローズされている。
• 必要なすべてのマージリクエストが main にマージされている。

フィーチャーフラグとロールアウト

• フィーチャーフラグがデフォルトで有効化されている（一部の顧客のみではなく、グローバルに）。
• フィーチャーフラグのクリーンアップ Issue が作成・スケジュールされている。

テストと品質

• 適切な単体テスト、統合テスト、フィーチャーテストが実装されている。
• フィーチャーがステージングおよび本番環境で検証されている。
• 重大なバグやパフォーマンスの低下がない。

導入指標

• 利用状況（ユーザー数、プロジェクト数、ネームスペース数）を追跡する導入指標が実装されている。
• チームが導入レベルを把握し、フィーチャーの利用頻度を確認できる。
• 指標が正しいグループとフィーチャーカテゴリに適切に帰属されている。

ドキュメントとコミュニケーション

• ドキュメントが完成・公開されている。
• リリースポストエントリがマージされている（該当する場合）。
• フィーチャーが内部でデモされたか、関連するステークホルダーと共有されている。

完了したアイテムは、上記のすべての基準が満たされた後に Interlock Deck から削除されます。この時点でエピックはクローズされます。

参考として、GitLab の フィーチャーレベルの完了の定義 も参照してください。

エピックエンジニアリング DRI

エピックがアクティブな開発に移行する準備ができたら、EM は IC と協力して、必要な各テックスタック（バックエンド、フロントエンド）の DRI を割り当てます。エンジニアは特定のエピックのオーナーシップを取りたいかどうか確認されます。

エピックの DRI として、エンジニアはすべての作業を実行する責任はありませんが、以下については責任を持ちます:

1. スパイク から始め、PoC で技術的アプローチを検証します。
2. 実装 Issue の分解を提案し、フィードバックを求めます。
3. 合意した実装 Issue を作成します。
4. さらなる調査が必要な場合を特定し、スパイク Issue を作成します。
5. 技術的な意思決定を行います。
6. 求められた際に状況報告を提供します。
7. ブロッカーを特定してコミュニケーションします。
8. セキュリティへの潜在的な影響を特定し、必要に応じてセキュリティエンジニアを巻き込みます。
9. 広範囲に影響する作業の影響を軽減するための対策を講じます。

DRI は作成した Issue の作業を選択して進めることができますが、エピック全体を一人で完成させることは期待されていません。

ページのソースコードを見る - ページの編集 - please contribute.