Content last updated 2026-08-13

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 はリリースに必須ではありませんが、あると良いもの、またはバックログ Issue です。

機能エピックのロールアウト

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

完了の定義

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

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

フォローアップ作業

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

バグ

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