Security Risk Management プランニング

プランニングの進め方

私たちのマイルストーンプランニングは、可能な限り非同期で処理されます。プランニングの議論は流動的で継続的であり、一般的に事前定義された月次スケジュールには従いません。

プランニングブレイクダウン

今後のリリースマイルストーンのトップ優先フィーチャーは、それぞれのグループのプロダクトマネージャー（PM）、プロダクトデザイナー（UX）、エンジニアリングマネージャー（EM）、エンジニアによるプランニングブレイクダウンを経ます。 毎週のグループレベルの同期ミーティングでこの議論を促進します。 議論する Issue のリストは、ミーティングの少なくとも1日前に PM から提供されます。 すべての参加者がミーティング開始前に Issue をレビューしていることが期待されます。 参加者は Issue を事前にレビューしたことを示すためにニンジン 🥕 絵文字を追加します。

回答すべき質問:

  1. 要件はリクエストの意図を理解するのに十分明確ですか？
  2. 実施すべき作業の範囲を把握していますか？

これらの質問のいずれかに「いいえ」の場合、チームのリクエスト理解を改善するために PM との議論が続きます。必要であれば、エピックまたは Issue での議論が非同期で継続され、将来の週次ミーティングに持ち越されます。

これらの質問に「はい」の場合、チームは Issue が単一のイテレーション内で提供できるかどうかを推定します（その同じイテレーション内の他の作業は無視します）。議論中の Issue が単一のイテレーション内で提供できないと判断された場合、チームは PM と協力して、それぞれがイテレーション内で提供でき、顧客が使用できる価値の独立した「スライス」（モックアップ UI やアクセス不可のバックエンドのみの作業ではない）であり、すべて提供されると元の Issue の要件を完全に満たす複数の MVC Issue に分解します。

  • EM アウトプット: 上記のすべての要件が満たされたら、EM はフロントエンドとバックエンドのエンジニアをそれぞれの DRI として割り当て、MVC エピック配下に実装 Issue を作成させます。UX が作成したデザイン Issue もこの時点で EM によってクローズされます。

  • エンジニアリングアウトプット: フロントエンドとバックエンドの DRI は gitlab-org プロジェクト Issue で利用可能な 実装テンプレート に従って 実装 Issue を作成します。完了したら、自分自身のアサインを解除し、Issue を workflow::refinement 状態に移動します。

リファインメント

workflow::refinement 状態の Issue は、EM によって個々のエンジニアにリファインメントのために割り当てられます。 リファインメントに割り当てられたエンジニアは、Issue に成功したリファインメントと実行に必要な情報やデザインが欠けている場合に、PM に質問し意見を述べるよう奨励されています。

Issue をリファインメントに割り当てるのは、プロダクトマネジメントが決定した最高優先度アイテムに集中するためです。これは Issue の作業への割り当てではありません。

  • エンジニアリングアウトプット: リファインメントが完了したら Issue を workflow::ready for dev 状態に移動し、自分自身のアサインを解除します。何らかの理由でリファインメントが完了できない場合は、Issue を workflow::refinement のままにして EM に割り当てます。Issue に適切な 作業タイプ分類 があることを確認します。

リリーススコープ確定とキックオフ

現在のマイルストーンが完了する前の週までに、次のリリースのスコープが EM と PM によって確定されます。

  • EM アウトプット: 提供にコミットする Issue に Deliverable ラベルを適用します。このラベルを受け取る Issue は EM の裁量に委ねられており、Say Do レシオの計算に使用されます。考慮要因: マイルストーン内で Issue が完了する自信度、前のマイルストーンから持ち越された Issue の完了状況、他のグループやステークホルダーとのコミットメント。
  • EM アウトプット: 提供できそうにない Issue を次のイテレーションに移動します。
  • PM アウトプット: workflow::ready for dev 状態の Deliverable ラベル付き Issue が正しい優先順位にあることを確認します。

リファインメントガイドライン

バックログリファインメントは、Issue が開発に移行する準備ができており、作業が提供された際に全員の期待に合致することを確実にするための最も重要なステップです。

リファインメントプロセスの目標は、以下を実施して Issue が作業可能な状態であることを確実にすることです:

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

エンジニアのリファインメント手順

  1. リファインメントが必要な Issue は EM から割り当てられます。バグ と スパイク の違いに注意してください。
  2. バックエンド/フロントエンドラベル:
    • Issue にバックエンドエンジニアが必要な場合は backend ラベルを確認します。そうでなければ、バックエンドラベルを削除し、関連するラベルを割り当てて完了です。
    • Issue にフロントエンドエンジニアが必要な場合は frontend ラベルを確認します。そうでなければ、フロントエンドラベルを削除し、関連するラベルを割り当てて完了です。
  3. Issue の完全性を確認します。
    • 必要なデザインがありますか？
    • 機能が明確に表現され、どのように機能するかについてコンセンサスまたは決定がありますか？
    • 技術的な詳細が概説されていますか？
    • 議論の分野でコンセンサスが達成または決定されていますか？
    • 依存関係はありますか？それを明記します。
  4. Issue が完全でない場合:
    • Issue を完成させるために助けてもらえる関連する人をタグ付けし、何が必要かを説明します。EM と PM をタグ付けして、アイテムが完全にリファインできないことを知らせます。
    • 合理的な時間内（イニシアティブの規模によって2〜3日）にリファインメントのブロッカーを解決できない場合は リファインメント失敗 を参照してください。
  5. Issue を完全に理解していることを確認します。
    • 実装される内容の最終説明で Issue の説明を更新します。
    • 実装計画 で Issue の説明を更新します。
    • 検証手順 で Issue の説明を更新します。
    • Issue タイトルが実施される作業に対して正確であることを確認します。
    • スコープ外となった「フォローアップ」作業や作業のための新しい Issue をオープンします。
  6. ウェイト を割り当てます。
    • Issue がフロントエンドとバックエンドの両方の作業を必要とする場合は、分割して独立してウェイトを付けます。
  7. フィーチャーフラグが必要かどうか を判断します。
    • 特定の Issue にフィーチャーフラグを使用すべきと思う場合は、~"feature flag" ラベルを追加し、説明に Feature Flag セクションを追加して提案する名前を記入します。
    • フィーチャーフラグを使用したリリースの複数のステージを追跡するための フィーチャーフラグロールアウト Issue を作成します。
    • フィーチャーフラグの削除が後続のマイルストーンで発生する場合は、フィーチャーフラグクリーンアップ Issue の作成を検討してください。
  8. コミュニティ貢献を促進します。
  9. リファインメントレビュー。
    • 割り当てたウェイトが3以下の場合は、Issue を直接 ~"workflow::ready for development" に移動します。
    • Issue のウェイトが3より大きい場合は、自分自身のアサインを解除して別のエンジニアにレビューを依頼します。
    • レビュアーが実装計画とウェイトに同意したら、自分自身のアサインを解除して Issue を ~"workflow::ready for development" に移動します。

誰もがリファインされた Issue の説明を読んで、何が解決されているか、どのように問題を解決するか、Issue を実装するための技術的な計画が理解できるようにします。

Issue とその実装を誰かが理解するために、すべてのコメントを読む必要があってはなりません。重要な内容は 信頼できる唯一の情報源 として説明にキャプチャされるべきです。

バグ診断

バグをリファインする際の以下の違いに注意してください:

  1. ガイドラインとして、Issue ごとに1時間以内に留めます。リファインするのに時間がかかりすぎるバグは、より複雑な Issue の兆候です。
  2. ウェイトを追加しません。私たちのベロシティは、新しいバグのないフィーチャーを提供するキャパシティを表します。
  3. リファインメントの時間制限に達したとき、実装計画 に不確実性があっても問題ありません。コード変更が発生すると予想される場所を（高レベルまたは低レベルで）示すだけで十分です。

スパイクのリファインメント

  1. ウェイトを追加しません1。
  2. Issue に費やす時間をタイムボックス化します。
  3. 成果物は通常、今後の Issue で使用される回答またはソリューションです。

セキュリティ Issue のリファインメント

セキュリティデベロッパープロセス は初めての方には難しく感じられることがあります。リファインメントの一環として、「セキュリティ Issue リリースバディ」として行動するボランティアを求めます。

リファインメント失敗

Issue は、追加情報や決定なしには作業できない場合にリファインメント失敗とすべきです。Issue を失敗させるには:

  1. Issue に作業できないことと、まだ何をする必要があるかを強調したコメントを残します。
  2. 現時点でこれ以上 Issue に貢献できない場合は自分自身のアサインを解除します。
  3. workflow::blocked ラベルを割り当てます。

ウェイト

ウェイトは、チームの残りのメンバーに関わる作業量を示すためのおおまかな規模の目安として使用されます。ウェイトはリファインメントプロセスの成果物とみなされ、リファインメントプロセスの目的ではありません。

アイテムが最初のウェイトより時間がかかっても問題ありません。ウェイトを膨らませることは望ましくありません。ベロシティは予測可能性より重要であり、ウェイトの膨張は予測可能性を過度に強調します。

バグにはウェイトを追加しません。追加するとポイントの二重カウントになるためです。私たちの提供にバグが含まれている場合、体系的な品質問題に対処する時間を確保するためにベロシティが下がるべきです。

可能な値

Issue のウェイトにはフィボナッチ数列を使用しています。各数値の定義は frontend-weight と backend-weight ラベル に関連付けられています。5より大きいものは可能な限り分解してください。

Issue に frontend-weight または backend-weight ラベルを設定することは任意ですが、リファインメント中に Issue の Weight プロパティを設定してください。

ウェイトラベルの設定が適切な場合の例:

  • 新しく作成された Issue で、スコープやフロントエンドとバックエンドの両方が必要かどうかをまだ完全に決定していない場合。
  • バグで、直接ウェイトを割り当てない場合。ラベルは複雑さに関するガイダンスを提供するのに役立ちます。

実装計画

このフィーチャーを実装するために更新が必要なコードの手順と部分のリストです。実装計画には、他のチームメンバーやチームへの責任も明記する必要があります。例。

実装計画の目標は、Issue の批判的分析を促し、アプリケーションのどの部分が触れられるかをリファインするエンジニアが考え抜くことを支援することです。実装計画は他のエンジニアが Issue をレビューし、依存関係があるアプリケーションの領域や見落とされた部分を指摘することも可能にします。

検証手順

このフィーチャーを検証するために従う必要がある手順のリストです。検証手順には、カバーされるべき追加のテストケースも含めます。例。

Issue 検証手順の目的は、Issue を実装した後にアプリケーションに期待される変更をより良く理解することを支援することです。他のエンジニアは Issue を評価し、依存関係があるアプリケーションコンポーネントや無視されていてさらなるテストが必要なコンポーネントを特定できます。

フィーチャーやバグ修正の検証手順を作成する際には、ポジティブとネガティブの両方のシナリオを含めることが重要です。これにより、フィーチャーや修正が特定の基準が満たされた場合にのみ機能し、すべての状況で機能しないことを確実にします。例えば、MR 承認ポリシーを検証する際には、ポリシーが違反された場合に承認が必要なシナリオと、ポリシーが違反されていない場合に承認が不要なシナリオの両方を提供します。このアプローチにより、より徹底的で正確なテストプロセスが可能になります。

検証

Issue の検証は MR の作者以外の誰かが行う必要があります2。

  1. すべての実装 Issue は説明に検証手順を含む必要があります。私たちの 実装 Issue テンプレート にはこのセクションが便利に提供されています。
  2. エンジニアが作業をマージしたら、~workflow:verification ラベルで示される検証状態に Issue を移動し、リリース Issue のメールでステージング環境に作業がデプロイされた通知を受けるまで待ちます。
  3. 可能であれば、エンジニアが通知を受けてステージングで作業を検証した後、完了したテストの概要をコメントで残します。
  4. .com/本番環境で変更が利用可能になったら（MR に ~workflow:verification ラベルがあり、GitLab Next をオフにした状態で利用可能であることを確認します）、エンジニアは再度検証し、完了したテストの概要をコメントで残し、自分自身のアサインを解除します。該当する場合はプロジェクトやページへのリンクも提供します。
  5. ~workflow:verification 状態の未割り当て Issue は、検証ポリシー に基づいてトリアージボットによって適切なチームエンジニアにランダムに割り当てられます。このエンジニアはその後、Issue を追加検証します。
  6. 両方のエンジニアによって本番環境で Issue が検証されたら、workflow::complete ラベルを追加して Issue をクローズします。

PTO のプランニング

私たちは GitLab チームメンバーの休暇ガイド とエンジニアリングプロセスの PTO カバレッジ Issue 作成 に従います。PTO カバレッジ Issue は3日以上の場合に推奨されます。

  1. グレード8のチームメンバー（EM、Staff+）は、集中管理された Engineering Division / PTO Coverage プロジェクトに PTO カバレッジ Issue を作成します。
  2. 他のチームメンバーは、私たちの Security Risk Management プロジェクトに PTO カバレッジ Issue を作成します。

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

エピックがリファインメント段階に移行する準備ができたら、EM が各必要なテックスタックに DRI を割り当てます。これはプランニングブレイクダウン中に早期に行われることもあります。

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

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

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

FAQ

Q: ディスカバリー Issue はリファインすべきですか？

A: はい。ディスカバリー Issue はリファインすべきですが、上記のいくつかの手順は関連しない場合があります。上記のプロセスを適用するために適切な判断を使用してください。ディスカバリー Issue をリファインする目的は、ディスカバリーのスコープが明確であること、アウトプットが何であるか、ディスカバリーの前提条件が分かっており完了していることを確認することです。ディスカバリー Issue は引き伸ばされたり、実行可能なステップを作成しない傾向があります。リファインメントプロセスは、ディスカバリープロセスで回答が必要なことを明確にします。

Q: Issue にフロントエンドとバックエンドの両方の作業がある場合、どのようにウェイトを付けますか？

A: フロントエンドとバックエンドの両方の作業を必要とする Issue は通常、複数の実装 Issue に分割されます。例外は、一人のエンジニアが両方のテックスタックの作業に同意する場合です。

Q: Issue 内の絵文字の意味は何ですか？

A: プロセスの特定のステップを伝えるために使用します。

脚注

  1. スパイクはユーザーに直接価値を追加しないため、ベロシティに貢献すべきではありません。スパイクによって提供される情報こそがユーザーへの直接的な価値の提供に役立ちます。 ↩︎

  2. エンジニア間のサイクルタイムを最小化するために、作業エンジニアが自分の作業を検証することが望ましいです。Issue が十分に解決されていないと判明した場合、すぐに作業を再開できるためです。別のエンジニアが明らかな失敗を発見するのを待つことで、ターンアラウンドタイムが増加します。 ↩︎

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License