gr-product-dev-ops

🌍 言語 / 言語: 中文 | English | 日本語 | 한국어

📦 インストール

clawhub install product-dev-ops-playbook

インストール後に利用できるもの：

• 三者間の連携チェックポイントを含む、10 日間のスプリントサイクル全体
• Issue テンプレート + 重大度の自動エスカレーションルール（3 回報告されたら必ず修正）
• スプリント計画、レビュー、毎日のスタンドアップですぐに使える会議テンプレート

---

プロダクト開発 × 運用連携 SOP

補足：証拠を追加し、「40 点の機能」の落とし穴を避ける

ローカルのポッドキャストの文字起こしにある AFFiNE の振り返りでは、解決策を思いついたとき、プロダクトの仕事はまだ始まったばかりだと指摘されています。チームが新しいアイデアを追い続けると、活性化や継続率を検証できていない、40～60 点の機能が大量に残ります。各イテレーションの計画では、既存のどの機能を「使える」状態から「信頼できる」状態へ磨き上げるのか、完了の基準は何か、そのために何を明確に中止するのかを必ず確認してください。

本 SOP は、実際のプロダクト戦略会議の議事録、ユーザーフィードバック入力テンプレート、ベータユーザーインタビュー体系を統合し、プロダクト、開発、運用の三者が連携する汎用的な業務フレームワークをまとめたものです。

基本原則： すべては商業化を目的としたサービスです。すべては収益のためです。

使用方法： 本ドキュメントは汎用テンプレートです。すべての [产品名称] / [项目代号] / [系统名称] を該当する情報に置き換えるだけで、そのまま使用できます。

---

一、主要な課題の診断：なぜプロダクト・開発・運用の連携はうまくいかないのか？

1.1 ほぼすべての成長段階にあるプロダクトが直面する三つの矛盾

矛盾	表れ方	根本原因
新機能 vs ユーザーフィードバック	開発チームは常に新機能を追い、ユーザーから報告された小さなバグはいつまでも後回しにされます	優先順位を決める統一的な仕組みがありません
開発がやりたいこと vs 運用が必要とすること	開発は運用が技術を理解していないと感じ、運用は開発がユーザーの声を聞いていないと感じます	共通の目標がありません
スピード vs 安定性	プロダクトの形がまだ安定していないのに成長を急ぎ、技術的負債が増え続けます	プロダクトの段階を判断する明確な基準がありません

1.2 解決策

実際の会議から得られた知見： 商業化による収益化がうまくいっている企業（Manus、DeepSeek など）では、COO または運用責任者が商業化を直接支援し、プロダクト・開発・運用の三者が高度に連携しています。

四つの主要な仕組み：

#	仕組み	説明
1	統合ボード	ユーザーフィードバックとプロダクト要件を同じプールに入れ、同じタグ体系を使います
2	共通の目標	各イテレーションに、明確な商業化指標を設定します（例：「登録→有料転換率を 4.5% から 7% に引き上げる」）
3	運用に拒否権を付与	ユーザー体験や有料転換に直接悪影響を及ぼす問題について、運用はリリース延期を直接提案できます
4	各イテレーションの開始前に三者で調整	プロダクト・開発・運用の責任者が、何を行うか、何を先に行うか、何を次のイテレーションに回すかを共同で決定します

---

二、統一された協業基盤：ボード体系の設計

2.1 2 階層のボード構成

実際の経験から： 各イテレーションの小さなボードだけでなく、必ず総合ボードを用意してください。すべての元の Issue はまず総合プールに入れ、その後、各イテレーションへ流します。

階層	名称	内容	担当者
第 1 層：総合要件プール	[产品名称] 总 backlog	あらゆる情報源からの元の Issue（ユーザーフィードバック／競合分析／戦略的要件）	プロダクト責任者
第 2 層：イテレーションボード	[版本号] - [目标描述]	今回のイテレーションで対応すると決めた要件 + 必ず修正するバグ	イテレーション owner

流れ：

总需求池（所有来源的 Issue）
    ↓ 经过评审，认为可以形成方案
形成方案的需求
    ↓ 经过排期会议决策
进入某个迭代的项目
    ↓ 迭代内开发
发布上线 / 回滚到需求池 / 延到下一期

2.2 Issue 入力テンプレート（汎用形式）

重要な原則： 運用が起票する各 Issue には再現可能な情報を含める必要があります。そうでなければ、開発側は修正できません。

フィールド	説明	例
Issue タイトル	問題を簡潔に説明します	「iOS 版の命盤結果が Android と一致しない」
情報源	ユーザーフィードバック / 競合 / 戦略	ユーザーフィードバック
報告回数	同じ問題が何回報告されたか	3 回以上 → 重大タグを付与
システム／プラットフォーム	Web / iOS / Android / Self-host	iOS
バージョン番号	具体的なバージョン	v2.3.1
再現手順	再現できなければ修正できません	1. 合盤を開く 2. XX を選択する 3. 結果を確認する
期待される動作	ユーザーが期待する動作	両バージョンの命盤結果が一致する
実際の動作	現在の実際の動作	iOS の表示順序が Android と逆になっている
スクリーンショット／録画	証拠を添付します	[添付ファイル]
影響の評価	体験／有料利用への影響	ユーザー 1 名が返金を申請する原因となった
タグ	Bug / Feature Request / UX最適化	Bug
優先度の提案	運用側による判断（高／中／低）	高

運用側の特別ルール： 同じ Issue が 3 回以上報告された場合、自動的に severe タグを付与し、直近のイテレーションで必ず解決します。

2.3 Bug と Feature Request の振り分け

種類	定義	対応方法
Bug	既存機能の動作が期待と異なります	Bug ボードに直接登録し、開発側が工数を見積もった後に修正します
Feature Request	ユーザーが新機能を必要としています	総合要件プールに登録し、プロダクト側が解決策を作成した後にイテレーションに追加できます
UX最適化	コア機能には影響しませんが、ユーザー体験に影響します	Bug と同等に扱い、運用側から優先順位の引き上げを働きかけることができます

---

三、イテレーションのリズム設計

3.1 イテレーション期間の選択

プロダクト段階	推奨イテレーション期間	説明
初期の PMF 検証	1～2 週間	短いサイクルで素早く試行錯誤します
成長期	3～4 週間	スピードと安定性のバランスを取ります
安定期	6～8 週間	安定性を優先し、大規模なバージョンを開発できます

⚠️ 注意： 現代の Web 開発のペースでは、10 日～2 週間に短縮することを推奨します。イテレーション期間が長すぎると、チームの緊迫感が失われます。

3.2 10 日間の標準イテレーションプロセス

日	開発の作業	運用の作業	成果物
1 日目	開発を開始	—	—
6 日目	テスト可能なバージョンを提出	テスト版を受け取り、半日以内にテストを完了	テストレポート（バグ一覧 + 優先順位）
7 日目	優先順位に従って P0/P1 を修正	運用 × 開発の調整会議（20～30 分）	今回のイテレーション範囲の確定
8 日目	修正を継続 + 第 2 テスト版を作成	第 2 ラウンドのテスト（必要に応じて）	—
9 日目	最終修正	リリース素材を準備（スクリーンショット／公式サイト／SNS）	素材の準備完了
10 日目	リリース	各チャネルにリリース内容を同時配信	リリース完了

3.3 リリーススケジュールの厳守事項

実際の失敗から得られた教訓： 金曜日や週末には絶対にリリースしないでください。

---

四、三者間調整会議の仕組み

4.1 デイリースタンドアップ（毎日、15 分）

参加者： プロダクト／開発／運用の全員

• 立ったまま行い、15 分以内に終わらせます
• 各自が話すのは三つだけです：①昨日何をしたか ②今日何をするか ③ブロッカーがあるか
• 運用側は必ず共有してください： 前日のユーザーからの苦情で多かった内容、新たに見つかった頻発バグ
• 1 時間を超える会議では、必ず誰かがさぼります

4.2 イテレーション計画会議（各イテレーションの開始時、30～60 分）

参加者： プロダクト・開発・運用の三者の責任者

议题1：复盘上一迭代（20分钟）
  - 核心指标完成情况（对比目标）
  - 有哪些没做完？为什么？
  - 用户反馈集中在哪里？

议题2：本迭代目标设定（20分钟）
  - 运营侧：本迭代最需要解决的问题（关联商业化目标）
  - 产品侧：本迭代主推的新功能/优化
  - 研发侧：技术债/重构需求
  - 共同决策：本迭代的 Top 3 目标

议题3：资源与排期确认（20分钟）
  - 各方投入多少人天？
  - 哪些功能确定进迭代？哪些 hold？
  - 是否有模块需要重构？

4.3 イテレーション受け入れ会議（各イテレーションの終了時、30 分）

主要な確認事項：

1. 今回のイテレーションの目標指標は達成できましたか？
2. 未修正の P0 バグはありますか？リリースに影響しますか？
3. どの機能を次のイテレーションに延期すると決めましたか？
4. 次のイテレーションにおける運用上の重点は何ですか？

4.4 会議頻度の一覧

会議	頻度	所要時間	目的
デイリースタンドアップ	毎日	15 分	進捗を共有し、ブロッカーを発見する
イテレーション計画会議	各イテレーションの開始時	30～60 分	今回のイテレーションで何を行うか決める
イテレーション受け入れ会議	各イテレーションの終了時	30 分	振り返り + 次のイテレーションに向けた準備
月次レビュー	毎月	60～90 分	主要指標の振り返り + 方針の調整

---

五、連携における運用側の役割

5.1 運営はユーザーと開発チームの間の「翻訳者」です

職責	具体的なアクション	頻度
ユーザーの声の収集	ユーザーからのフィードバックを整理し、頻出する問題を抽出して、Bug / Feature に分類します	毎日
Bug の一次選別	各 Issue が再現可能であることを確認し、再現手順を補足します	毎日
優先順位の提案	ユーザー体験と収益化の観点から優先順位を付けます	各イテレーション
バージョン受け入れテスト	6日目から開始し、半日以内にテストを完了してレポートを作成します	各イテレーション
リリース素材の準備	App Store の更新、公式サイトの更新、SNSでの公開内容を準備します	各イテレーション

5.2 リリースに対する運営の拒否権

発動条件： リリース前に、ユーザー体験または有料転換に影響する未修正の P0 Bug が見つかった場合、運営はリリースの延期を提案できます。

P0 Bug の基準（運営側の判断）：

Bug の種類	例	P0 かどうか
支払い関連	支払い失敗、二重請求	✅ P0
コア機能が利用不可	登録できない、結果を生成できない	✅ P0
データの誤り	チャート作成結果が他のプラットフォームと一致しない	✅ P0
画面表示が崩れているが機能は利用可能	ボタンの位置がずれている	⚠️ P1
文言／翻訳の誤り	英語のスペルミス	❌ P2

---

六、ユーザーフィードバック主導の製品イテレーション

6.1 フィードバック→改善のループ

用户使用产品 → 产生问题/建议
        ↓
运营收集（整理/分类/初筛）
        ↓
录入 Issue 到总看板（附复现步骤）
        ↓
同一问题被反馈3次以上 → 打 severe 标签
        ↓
每迭代规划会重点讨论 severe 项
        ↓
进入迭代开发
        ↓
上线后运营验证问题是否解决
        ↓
通知用户问题已修复（增强被重视感）

6.2 ベータテストユーザーへのインタビューの仕組み

段階	時期	アクション	担当者
ユーザーの選定	ベータテストの1週間前	アクティブユーザーから10～15人を選びます	運営
テストアカウントの配布	ベータテストの3日前	テストアカウント＋ポイントを配布します	運営
ユーザーによるテスト	ベータテスト期間中	実際のニーズに基づいて製品を使用します	ユーザー
詳細なインタビュー	ベータテスト期間中	1回あたり30～40分	運営
毎日の集計	毎日の終了後	頻出する Bug と主要なニーズを整理します	運営
週次レビュー	毎週	リリースに適しているか判断します	製品・開発・運営の共同

インタビューの構成（30～40分）：

時間	セクション	主な質問
5分	ユーザーの背景	現在何をしていますか？どんなツールを使っていますか？最大の問題は何ですか？
20分	製品テストの振り返り	どの手順が最もスムーズでしたか？どこで最もつまずきましたか？Bug はありましたか？
10分	改善案	何を優先的に改善してほしいですか？
5分	締めくくりの確認	今後も参加したいですか？人に勧めたいと思いますか？

基本原則： 抽象的な感想ではなく、実際の利用プロセスについて話し合います。

---

七、コア指標体系

7.1 各イテレーションの目標指標テンプレート

本迭代目标：[具体描述]
- 起始值：XX%
- 目标值：XX%
- 验证方式：[数据来源/查询方式]
- 负责人：产品/运营/研发

7.2 収益化のコア導線指標

段階	指標	説明
獲得	新規登録ユーザー数	チャネル別に分類（オーガニック／SNS／広告出稿／KOL）
アクティベーション	Onboarding 完了率	モジュール別に確認：情報入力／機能体験／結果の取得
継続利用	翌日／7日／30日継続率	ユーザーの流入元別に分類
有料化	登録→有料転換率	チャネル／ユーザー属性別に分類
推奨	K係数（NPS／推奨意向）	招待施策への参加率

7.3 イテレーションの健全性チェック

チェック項目	健全値	警告サイン
P0 Bug の平均修正時間	≤2日	> 3日
機能の予定どおりのリリース率	≥80%	<60%
ユーザーフィードバックへの平均応答時間	≤24時間	> 48時間
同一 Bug への重複フィードバック回数	≤2回	≥3回
テストレポートの期限内提出率	100% が Day 6.5 より前	半日を超える

---

八、技術的負債と製品リファクタリングの管理

8.1 リファクタリングを開始する兆候

兆候	説明
同一モジュールで Bug が繰り返し発生する（関連 Issue が5件以上）	モジュール設計に根本的な問題があります
新機能の開発コストがますます高くなる	基盤アーキテクチャが拡張性を制限しています
複数プラットフォーム間でデータが一致しない	エンティティの抽象化が統一されていません
技術選定が古くなっている	技術スタックのアップグレードが必要です

8.2 リソース配分の提案

種類	推奨割合	説明
新機能開発	50-60%	収益化目標に直接貢献します
Bug 修正	20-30%	基本的なユーザー体験を確保します
技術的負債／リファクタリング	20-30%	長期的な持続可能性を確保します

8.3 リファクタリング関連の要望への対応

• リファクタリング関連の要望は専用の Project を作成し、期間を1～3か月とします
• リファクタリング中も通常のイテレーションのリリースに影響しないようにします（2つの体制を並行して進めます）
• リファクタリング完了後は完全な回帰テストが必要です（コアユーザー3～5人の参加を推奨します）

---

九、各段階での重点

段階	重点	説明
コールドスタート期（<PMF）	協業プロセスを確立する	2～3回のイテレーションでプロセスを確立し、20～30人のユーザーに詳細なインタビューを行います
成長初期	コア指標を明確にする	Onboarding 完了率／転換率／継続率曲線
急成長期	開発効率を高める	イテレーションを10日間に短縮し、社内のグロースチームを設立します

---

十、ツールの推奨

用途	ツール	説明
プロジェクト管理	Linear / Jira / Feishu の多次元テーブル	すべての Issue の一元的な受付窓口
データ分析	PostHog / Amplitude / Mixpanel	コア導線のイベント計測＋ファネル分析
ユーザーフィードバックの収集	GitHub Issue / Linear / Feishu の多次元テーブル	ユーザーが直接送信できます
議事録	Feishu のスマート議事録	インタビュー記録を自動で整理します
社内コミュニケーション	Feishu / Slack	プロジェクトごとにチャンネルを作成します
コンテンツ管理	Notion / Feishu のクラウドドキュメント	SOP、テンプレート、ナレッジベース

---

付録一：Bug レポートのテンプレート

## Issue 标题
[简明描述问题]

## 基本信息
- **来源渠道**：[用户反馈 / 客服 / 社媒 / 内测]
- **反馈次数**：[N] 次（≥3次请标注 severe）
- **系统/平台**：[Web / iOS / Android / Self-host]
- **版本号**：[如 v2.3.1]

## 复现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]

## 预期行为
[用户期望应该是什么样的]

## 实际行为
[当前实际发生的情况]

## 证据
[截图 / 录屏链接]

## 影响评估
[对用户体验/付费转化/留存的影响]

## 标签
[Bug / Feature Request / UX优化]

## 优先级建议（运营侧）
[P0（立即修）/ P1（本迭代修）/ P2（下个迭代修）]

---

付録二：イテレーション計画会議のテンプレート

# [迭代名称] 规划会议纪要
**日期：**
**参与人：**

## 一、上迭代复盘
| 目标指标 | 起始值 | 结果值 | 完成情况 |
|---------|-------|-------|---------|
| | | | |

**未完成项：**
1.
2.

## 二、本迭代目标
| # | 目标 | 对应商业化价值 | 负责人 |
|---|-----|------------|-------|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## 三、运营侧需求
| 需求 | 背景/用户反馈来源 | 建议优先级 |
|-----|----------------|----------|
| | | |

## 四、研发侧评估
| 需求 | 技术方案 | 工时估计 | 本迭代可完成？ |
|-----|---------|--------|-------------|
| | | | |

## 五、最终确认范围
**进入迭代：**
**延到下期：**
**技术债安排：**

---

付録三：製品・開発・運営の責任範囲

項目	決定者	提案者	実行者
機能を実装するかどうか	製品＋運営	運営（ニーズ）、開発（実現可能性）	開発
Bug を修正するかどうか	製品＋運営	運営（フィードバックの集中度）	開発
リリース時期	製品・開発・運営の三者で共同決定	—	—
ユーザーインタビューで見つかった課題の優先順位	運営	—	製品＋開発
グロース戦略	運営＋製品	開発（データ支援）	運営
技術アーキテクチャ／リファクタリング	開発＋製品	運営（体験への影響）	開発

---

この SOP は、実際の製品戦略会議の議事録、ユーザーフィードバック記入テンプレート、ベータテストユーザーインタビューの仕組みを統合したものです。製品・開発・運営の三者間で協業体制を構築する必要があるすべての製品チームに適しています。

海外展開コミュニティへの参加と資料パックの購入 · Community & Resources

• 海外展開コミュニティへの参加： WeChat で staywildgrow を追加し、「コミュニティに参加」とメッセージを送ってください。

• 資料パックの購入： WeChat で staywildgrow を追加し、Gingiris の海外展開資料パックについてお問い合わせください。価格は人民元599元です。

• グローバルグロースコミュニティへの参加： WeChat で staywildgrow を追加し、「加入社群」（コミュニティに参加）とメッセージを送ってください。

• 資料パックの入手： WeChat で staywildgrow を追加し、Gingiris のグローバルグロース資料パックを599人民元で購入してください。

コミュニティと資料パックは任意の利用方法であり、このオープンソース Skill のインストールや使用には影響しません。

コミュニティと有料の資料パックは任意です。オープンソースのこのスキルのインストールや使用に、どちらも必要ありません。