Security Policies - フィーチャー開発の進め方

プロセス

フィーチャー開発は、フィーチャー関連の Issue を集約したエピックで管理します。フィーチャーは通常、フィーチャーフラグの背後で開発されます。フィーチャー開発プロセスの目標は、フィーチャーフラグをデフォルトで有効化することです。

フィーチャー開発エピックは Interlock Deck に一覧表示されています。

段階的リリース（Experiment → Beta → GA）

デフォルトでは、エピックレベルのフィーチャーに対して 3フェーズリリースプラン に従います。

  1. Experiment（ターゲットの2マイルストーン前）: 無効化されたフィーチャーフラグの背後に動作するバージョンを出荷し、早期フィードバックを収集します。
  2. Beta（ターゲットの1マイルストーン前）: ほぼ完成したエクスペリエンスで、特定の顧客またはプロジェクト向けにフィーチャーフラグを選択的に有効化します。
  3. GA（ターゲットマイルストーン）: フィーチャーフラグをデフォルトで有効化し、十分なテスト・ドキュメント・導入指標を備えた状態にします。

正確なフェーズはエピックの複雑さとチームの自信度に応じて柔軟に変更できます。

スパイクファーストアプローチ

新しいエピックはそれぞれスパイクから始まります。DRI がインターロックされた四半期が始まる前に技術的アプローチを検証するための概念実証（PoC）を構築します。これには、開発を加速するために最新の AI ツールを活用できます。PoC が実現可能性を実証したら、DRI は実装計画と個別の実装 Issue を作成します。詳細は エピックのスパイクファーストアプローチ を参照してください。

エピックの Issue

  • タイトル
    • バックエンドとフロントエンドを示すために ‘BE’ または ‘FE’ をタイトルに追加します。ラベルでも示されますが、タイトルに追加することで識別が容易になります。
  • マイルストーン
    • フィーチャーフラグロールアウト Issue のマイルストーンは、フィーチャーをリリースする予定のマイルストーンです。フィーチャーフラグロールアウト Issue より上の Issue はすべて、フィーチャーフラグロールアウト Issue のマイルストーン以下のマイルストーンを持つ必要があります。
    • エピックにバックエンドとフロントエンドの依存作業がある場合、可能であれば バックエンドをフロントエンドの1マイルストーン前に計画 します。
  • ワークフローラベル
    • ユーザー/PM がエピックの状態を把握し、適切に作業計画を立てられるよう最新の状態に保つ必要があります（例：マイルストーンの半ばですべての Issue に ~workflow::in dev ラベルが付いていれば、エピックは順調に進んでいます）。
  • 「子 Issue とエピック」リストの Issue 順序
    • フィーチャーフラグロールアウト Issue より上の Issue はリリースに必要です。
    • フィーチャーフラグロールアウト Issue より下の Issue はリリースに必須ではありませんが、あると良いもの（nice to have）またはバックログ Issue です。

フィーチャーエピックのロールアウト

  • フィーチャーフラグロールアウト Issue より上のすべての Issue は、本番環境でフィーチャーフラグをグローバルにロールアウトする前にクローズする必要があります。
  • フィーチャーフラグロールアウト Issue は、エピックの状態を示すために「子 Issue とエピック」の中で最も高い位置にあるオープン Issue でなければなりません。

完了の定義

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

  • フィーチャーが動作しており、フィーチャーフラグがデフォルトで有効化されている。
  • 導入指標が実装されており、チームが利用状況を確認できる。
  • フィーチャーが検証・テスト・ドキュメント化されている。

フォローアップ作業

  • フィーチャーのリリースに必要ではない追加作業が特定された場合は、別のフォローアップ/改善エピックを作成し、その Issue を追加する必要があります。
    • この追加エピックはグループの優先リストに入れないでください。すべての Issue が特定のマイルストーンにスケジュールするほど重要ではない場合があるためです。代わりに Issue を個別に優先順位付けします。
  • フィーチャーフラグロールアウト Issue をクローズするとき（フィーチャーフラグがデフォルトで有効化され、フィーチャーフラグのクリーンアップ Issue が作成されたとき）、フィーチャーエピックをクローズし、残りの Issue をフォローアップ/改善エピックに移動します。

バグ

  • フィーチャーフラグがデフォルトになる前に見つかったバグはエピックに追加し、影響を評価します。
    • バグがリリースをブロックする場合は、エピックに残します。
    • バグがリリースをブロックしない場合は、フォローアップエピックに追加します。
  • フィーチャーフラグがデフォルトで有効化された後に見つかったバグは、エピックに追加する必要はありません。
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License