複数アプリの統合判断（1 本化 vs 分離維持）

背景与问题

OPC（B 方向）。小さいアプリが複数育ってきた時、1 本に統合するか分離のままかを感覚で決めないための判断条件を作る。製品ポートフォリオの管理は opc-product-line-matrix-v2、やめさせる手順は opc-sunset-runbook が既存で、本课题は「統合」の判断だけ。

发现

（出典はいずれも 2026-09-17 アクセス）

• 統合の利点：ナビゲーション簡素化・認知負荷の低下・使い勝手向上（Procogia）。
• 統合の反対条件：対象ユーザーが異なるアプリの統合は feature overlap があっても意味が薄い——audience segmentation が鍵（Software Engineering Stack Exchange の実務議論）。
• 単一アプリ戦略の論点：リソースが 1 製品に集中し、コミュニティ成長・store の視認性・リテンション・収益化が強くなる（RevenueCat のカウンターポイント）。
• 判断要素の共通項：audience overlap・機能の結合度・保守コスト・成長戦略（複数出典の一致）。
• 推测：solo の統合の実費は「コードの統合作業」でなく「store の評価と検索ランクのリセット」——見えないコストが最大。

结论

1. 判断 3 条件に固定：①対象ユーザーが同じか ②機能の結合度（同じ場面で使うか） ③保守コストが統合で下がるか。3 つ全部揃ったら統合、1 つでも外れたら分離維持（境界条件なので悩んだら分離）。
2. 統合する時の順序は「小→大の吸収」：小さい方を opc-sunset-runbook に載せて計画的に停止し、store 説明に移行導線。大の方に機能を足す形。
3. store の評価・検索のリセットを統合コストに織り込む：レビュー数・ASO の損失を見積もりに含める（RevenueCat の論点+solo 実費の推测）。
4. 年越し点检（opc-year-end-checklist）で製品マトリクスと一緒に統合判断を年 1 回再確認——統合は情緒でなく条件で決める。

待办 / 下次继续

• 自社のアプリペアを 3 条件で採点（統合候補の有無を確認）。
  
• 統合時の store 移行導線（旧→新の案内文）のテンプレを作る。
  

关联

opc-product-line-matrix-v2 opc-sunset-runbook opc-year-end-checklist opc-cross-sell-minimal