少人数チームで 5 プロダクトを回す実践オペレーション (2026 年版)

1. 現在運用中の 5 プロダクト

• Merci: 飲食店向けチップ決済 SaaS (Stripe Connect Express)。本番稼働。 初回チップ end-to-end 検証完了 (2026-07)。
• Kotsukotsu (コツコツ。): 和モダン習慣トラッカー (PWA + Native)。 Web は本番、Native は内部テスト中。
• Kotodama: AI 占いアプリ (Cloud Run + 3 LLM 並列)。本番稼働。
• Paircon (family-safety-os): 家族見守りアプリ (Firebase)。 Android クローズドβ。
• 家族おでかけガイド: SEO 情報サイト (ps-seo-engine 流用)。本番稼働。

加えて、開発中のプロダクトとして スキ活マーケット (teen-earn) (中高生 向けデジタル商品 MP)、clearcast (予測市場) があります。実質 7 プロダクト 並行運用。

2. 週次ルーチン (実測ベース)

1 週間の時間配分の目安は次の通りです。合計約 40-50 時間 (プロダクト稼働) + 10 時間 (経営)。

• 月曜午前: 全プロダクトの状態確認 (30 分)。KPI ダッシュボード 1 枚 で Merci MRR・Kotodama API 利用・エラー率・支払失敗を確認。
• 月-金 集中プロダクト: 週の頭に「今週はこれ」を 1-2 プロダクト決めて 集中。他は運用モード (緊急対応のみ)。
• 金曜午後: 週次振り返り + 翌週の集中プロダクト決定 (1 時間)。
• 週末 4-6 時間: 資料整理・ブログ執筆・SEO 記事更新。運営ドキュメント (会社 backlog / 意思決定ログ) の更新。

3. 「今週は 1-2 プロダクト」の原則

5 プロダクトを毎日全部触ることは 物理的に不可能です。試したことがあり ますが、コンテキストスイッチのオーバーヘッドで生産性が半分以下になります。代わりに 「今週集中するのは Merci」「来週は Kotsukotsu」と決めて、他は完全に運用モードにします。

この方針が成立する前提として、各プロダクトが「触らなくても壊れない」状態に達している必要があります。これが「放置耐性」 で、少人数マルチプロダクトの最重要設計原則です。

4. 放置耐性を担保する 5 つの技術投資

• 健康チェックエンドポイント + 監視: 全プロダクトに /api/health を用意し、Uptimerobot でチェック。落ちたら Slack に通知。
• 1 コマンドデプロイ: gh workflow run deploy-web-prod.yml で本番反映まで自動化。手動 SSH や dashboard 操作は禁止。
• 本番ハードニング (env 検証・rate limit・security headers・fail-fast): 最初から入れる。後付けは 3 倍のコストがかかる。
• 冪等な cron: 掃引処理 (payout・consent expiry) は「n 回走っても 結果が変わらない」設計。Vercel Cron の実行漏れ・重複配信に耐える。
• 包括的な audit_logs: 状態変更が起きたら 1 行残す。障害調査で救われる。

5. 週次 KPI ダッシュボード 1 枚

朝 5 分で全プロダクトの状態を把握するため、以下を 1 枚のダッシュボードに集約:

• Merci: 週次 MRR / 累計チップ数 / Stripe エラー率 / 未対応通報数
• Kotsukotsu: DAU (端末内なのでプロキシとしてサーバへの sync 数) / Premium 加入数
• Kotodama: API 呼び出し数 / Cloud Run 課金額 / 各 LLM エラー率
• Paircon: β登録数 / 通知配信成功率
• 家族おでかけ: PV / セッション数 / AdSense 収益

ダッシュボードは Metabase / Grafana / Vercel Analytics の組み合わせで構築。追加費用 ¥0 で回っています。

6. カスタマーサポートの構造化

問い合わせは全部人間 (私) が対応します。AI 自動化は少人数期にはやりません。 「対応品質 = プロダクトの品質」と考えているためです。

代わりに 問い合わせを構造化して蓄積 します。Notion に問い合わせ内容 + 対応履歴を残し、同じ問い合わせが 3 回来たら:

1. FAQ に追加する
2. UI で解決する (問い合わせが発生しないように改善)
3. 機能を追加する

この「対応が積み上がらない」構造が、少人数運営の生命線です。

7. 「やらないこと」を明確にする

時間が限られる中で 意識的に切り捨てているもの:

• 毎週の SNS 投稿ノルマ (バーストして疲れる → 完全に止めた)
• 週次のブログ更新ノルマ (書きたい時だけ書く → 質が上がる)
• 営業メール送信 (Merci のインバウンドに集中)
• 過剰な UI 追求 (機能が動くことを優先)
• 全プロダクトのマーケティング (集客レバーが効くのは 1-2 プロダクトのみ)

これは 機会損失を許容する選択です。全部やろうとすると全部が中途半端。 少人数チームには「優先順位を明確にする勇気」が必要です。

8. 撤退判断の基準

新規プロダクトを立ち上げる時は、最初から 撤退基準 を明文化します。 スキ活マーケットの例:

• Phase 0 需要検証で LINE OpenChat 登録 ≥30 or 記事反応 (7/31 判定)
• β で応募≥15 + 掲載≥10 + 販売≥3 + 再出品意向≥60% (8/17 判定)
• β で安全インシデント 1 件でも発生 → 即中止

これで「サンクコスト膨張 (作ったからには続ける)」バイアスを防ぎます。基準を満たさ なければ、迷いなく畳んで次に集中します。

9. 全体のガードレール

少人数マルチプロダクトを持つ最大リスクは、資金繰り です。 1 プロダクトで大きな失敗をしたら他プロダクトも道連れになる。対策:

• 各プロダクトは 独立予算で回す (全社共通ではない)
• 新規実験は 固定費 ¥0で開始 (既存インフラ流用)
• キャッシュランウェイが 6 ヶ月切ったら、成長より資金繰り改善を優先

10. まとめ (5 つの原則)

1. 技術的独立: 各プロダクトが独立してデプロイ・運用できる
2. 放置耐性: 触らなくても壊れない状態を初期から作る
3. 集中対応: 今週は 1-2 プロダクトに絞る
4. 自動化: デプロイ 1 コマンド + 監視 1 ダッシュボード
5. やらない勇気: 機会損失を許容し、優先順位を明確にする

少人数チームでのマルチプロダクト運営は「才能」ではなく「設計」です。上記 5 つを 意識するだけで、意外と多くのプロダクトを健全に維持できます。