3 1. 発⾒ 2. デザイン 3. 開発 4. デプロイ 5. メンテナンス • PMが新機能のリクエストを持ち 込む • PMが要件の検証(顧客インタ ビュー、既存のバックログに対す る機能の検証)を⾏い、 InnerSourcing のための機能の優 先順位を決定 • PMが要件ドキュメントを作成 • PMは、製品の⼀貫性(ユーザー エクスペリエンス、ルック& フィール、製品ロードマップの整 合性など)を確保するための要件 をレビューします。 • Dev/PM が要件をレビューし、 設計ソリューションを議論しま す。 • PMは、必要に応じてさらなる 顧客検証を実施します。 • Dev は、作業を開始する前に、 サポートしている開発者と設計 計画を議論します。 • 開発者は、開発チームの延⻑ 線上で働きます (すなわち、該 当プロダクトのコードベース で機能を構築、PR をチェック、 機能をテスト、バグバッシュ をホスト、デモ、ドキュメン トの作成を⾏います)。 • Dev は必要に応じてガイダン スを提供し、ブロッカーを取 り除きますます。 • PMが機能を有効にする前にコ ミュニティに新機能のリリー スを送信します。 • 顧客に影響を与える機能は、 混乱を防ぐために Feature Flag を⽤います。 • コードは通常、プルリクエス トを完了してから 4 時間以内 に本番環境にデプロイされま す。 • インナーソース中は、開 発者が開発した機能を⽀ 援したり、デバッグした りします。 • 最終的には、開発チーム が製品の責任者となり、 開発終了後も機能のメン テナンスを⾏います。 • Weekly PM シンク • Weekly Dev/PM シンク PM toolkit • インタビューのテンプレート • サンプル要件テンプレート • 製品ビジョン - スライド7 • 機能バックログ PM toolkit • 新機能リリーステンプレート 早めに、オープンに、書⾯でコミュニケーションをとる 貢献者をチームの ⼀員として扱う ⽂書化して実験を簡単に ex: 共通の要件 ex: 30⽇間保証 メンターシップ 貢献の Recognition Best Practices