少人数チームで複数プロダクトを維持する仕組み

0. なぜ複数プロダクトを持つのか

「1 つに集中したほうが早いのでは」と何度も言われました。それでも 5 プロダクトを並行させているのは、経営判断としての意味があるからです。理由は 4 つあります。

• 収益源の分散：単一プロダクトの MRR は、価格改定・競合参入・プラットフォーム規約変更で 1 ヶ月で半減しうる。実際、2026 年上期に決済プラットフォーム側の手数料改定で 1 プロダクトの粗利が急落したが、他 4 プロダクトが下支えして全社キャッシュフローは平坦に保てた。
• ドメイン学習の速さ：toC 課金 SaaS、toB アウトリーチ、金融アルゴ、家族向け見守り、ユーティリティアプリ — 領域が違うと課題も違う。1 プロダクトに深掘りするより、5 プロダクトを浅く広く回した方が、汎化できる学び（オンボーディング設計、課金導線、CS 分類）が 3〜4 倍早く溜まる。
• toC と toB を両方持つ：toC は KPI が日次で動くが LTV 読みづらい、toB は数字が動かないが LTV 明確。両方の視点を毎週持つと、日次意思決定の質が変わる。
• 新規判断と運用判断のバランス：全プロダクトが立ち上げ期だと精神的に持たない。5 プロダクトあれば「今週は 1 個立ち上げ / 4 個運用」の配分になり、意思決定の負荷が平準化する。

つまり、複数プロダクトは 「効率が良いから」ではなく「持続可能だから」 選んでいます。ここを取り違えると、共通基盤の罠にハマります（後述）。

1. 「マルチプロダクト戦略」ではなく、それぞれ独立

複数プロダクトを持つと聞くと、「共通基盤で効率化」を思い浮かべる方が多いですが、私たちはあえて逆の方針です。各プロダクトは技術的に独立 しており、共通化しているのはドメイン管理と DNS レイヤーだけです。

具体的にどこまで独立させるか

• リポジトリを分ける：monorepo にしない。1 プロダクトの CI が 8 分になった時、他 4 プロダクトの CI まで巻き添えで遅くなる問題が起きる。依存関係のアップデートも「monorepo 全体で pnpm を上げる」議論が発生して、結局誰も上げなくなる。
• 認証を共通化しない：Kotodama は Supabase Auth、家族見守り (Paircon) は Firebase Auth、Merci は Stripe Customer Portal ベース。「共通認証基盤」は 3 プロダクト以上で必要になった時のみ検討する — と決めているが、現状 5 プロダクトあってもまだ必要になっていない。ユーザー層が重ならないから。
• デザインシステムも共通化しない：各プロダクトのブランドが違うので、Tailwind の config は独立、共通コンポーネントライブラリも作らない。共通化するとブランド差別化が消える。
• 唯一の共通化：ドメイン *.clearnets.org と Cloudflare Zone、そして GitHub Organization 管理のみ。ここを共通化しておくと、SSL 証明書・DNS 変更・組織アカウント権限で不要な手作業が減る。

共通化を検討する基準はシンプルに 「3 プロダクト以上で本当に必要になった時のみ」 にしています。予測で共通化した基盤は 100% 使われません。実際に困ってから抽象化する方が、結果として無駄がない。

2. 「今週触るプロダクト」ルールの実運用

5 プロダクトを同時に、毎日、全部触ることはしません。それは不可能だからです。代わりに、月曜朝に「今週の担当プロダクト」を Slack の #weekly-focus チャンネルに宣言します。

書き方は決まっていて、[week=2026-W30] focus=merci, sub=btc-auto-trade の 1 行だけ。focus に 1 個、sub に 1 個、それ以外の 3 プロダクトはその週「緊急障害のみ対応」モードに入ります。

この 1 行が生む効果

• 5 週サイクルが自然発生：5 プロダクトあれば、各プロダクトは 5 週に 1 度だけ深く触られる。「毎週何か新しい機能を出す」という自己都合の焦りから解放される。
• 機能追加のペースに天井ができる：5 週に 1 度しか触らないなら、10 機能一気に入れるのは無理。1 スプリントで最重要 2〜3 機能に絞る力学が働く。結果として無駄な機能が減り、後から剥がす作業が減る。
• 他プロダクトへの罪悪感が消える：「今週は Kotodama を触っていないけど、それでいい」と自分に許可を出せる。これがないと 5 プロダクト全部を毎日気にすることになり、精神的に破綻する。

例外は「緊急障害」だけです。判定基準は明文化してあり、DAU 影響 > 10% / 収益停止 / データ整合性破壊 の 3 つのどれか に該当したら focus を中断してでも対応する。それ以外の細かい不具合は、そのプロダクトの担当週まで貯めておきます。

3. 「放置耐性」の具体的な設計

「今週触らない 3 プロダクト」が壊れないためには、放置しても動く設計が必要です。ここが少人数マルチプロダクトの最重要の設計原則 です。実装しているのは以下の 4 層です。

3-1. 監視と通知の分離

• Sentry：エラー発生時に「即通知」ではなく「閾値超えのみ通知」にしている。エラー率 > 2% or 新種エラー > 10 件/時のときだけ Slack DM を鳴らす。それ以外は日次サマリで送るだけ。
• UptimeRobot：全プロダクトが /healthz エンドポイントを公開しており、5 分間隔で外形監視。3 回連続失敗で PagerDuty 経由の電話呼び出し。
• Stripe webhook 監視：決済関連は失敗を絶対に見逃せないので、webhook delivery failure を Slack の別チャンネルに分離。1 件でも即対応。

3-2. 依存パッケージの自動更新

• Renovate：全リポジトリで有効化。パッチバージョンのアップデートは CI が通れば auto-merge、マイナー以上は PR で溜めて週次レビュー時にまとめて処理。
• auto-merge の対象は重要度低い依存のみ：dev dependencies (prettier, eslint, types) と UI 系ライブラリのパッチ更新に限定。next.js / react / stripe-node など致命的なものは必ず人間レビュー。
• この仕組みで、放置していても脆弱性通知が積み上がらない。1 プロダクトあたり月 2〜3 回、自動 PR が merge されている。

3-3. デプロイの巻き戻しやすさ

Vercel は revert が 1 クリック、Cloud Run は revision タグで 1 コマンドの巻き戻しができる状態を維持。「壊れたらすぐ戻す、原因追及は後で」 の判断ができる状態にしておくと、放置週でも障害が長引かない。

3-4. 目標

「今日誰も触らない」が 4 週続いても普通に動く状態 を全プロダクトで維持しています。実測で、focus から外れているプロダクトの週次オペレーション時間は平均 20 分。ほぼ「Sentry サマリ確認 + Renovate PR の中身チェック」で済みます。

4. カスタマーサポートを「構造化するが自動化しない」

問い合わせは全部人間が対応します。AI で自動化することは、初期段階では逆効果 だと判断しています。ユーザーがまだ多くないプロダクトほど「開発者から返事が来た」という熱量が、Twitter や口コミでのオーガニック流入を生むからです。ここを AI で削ると、獲得コストが上がる。

構造化の実装

• Notion database に一元化：問い合わせと対応履歴を 1 つの DB に蓄積。プロパティは Product / Category / Severity / Root Cause / Resolution の 5 つだけ。
• 3 回ルール：同じ Category の問い合わせが 3 回来たら、必ず 3 択の判断ミーティングを設定する。選択肢は (a) FAQ に追記 / (b) UI で解決 / (c) 機能追加 の 3 つのみ。「様子を見る」は禁じ手にしている。これがないと同じ問い合わせが 20 回来ても放置される。
• 週次 CS レビュー 30 分：金曜夕方に、5 プロダクト分の問い合わせを一気に眺める。全体傾向（どのプロダクトの問い合わせが増えているか、Category の分布が変わっているか）を把握する時間で、個別対応の場ではない。

AI 自動返信を導入するタイミングは、1 プロダクトあたり月 100 件を超えてからと決めています。それまでは人間対応の熱量が LTV に効くので、あえて手を動かす。

5. デプロイ 1 コマンドの実装

各プロダクトのデプロイは gh workflow run prod-deploy.yml -f service=merci の 1 コマンドで完結します。「service=」に merci / btc-auto-trade / paircon / kotodama / revenue-engine のどれかを渡すと、それぞれ適切なプラットフォームにデプロイされます。

workflow の中身

• 共通フロー：pnpm install → pnpm typecheck → pnpm test → build → deploy。typecheck と test が落ちたらデプロイに進まない。事故率を下げる最大の効果はここ。
• デプロイ先の抽象化：service ごとに Vercel CLI / gcloud run deploy / supabase functions deploy を wrapping。呼び出し側は「どこにデプロイされるか」を意識しない。
• Slack 通知：デプロイ開始 / 完了 / 失敗を Slack に自動投稿。ログを後追いしやすい。

この統一により、プロダクトを跨いだ時の「あれ、このプロダクトのデプロイどうやるんだっけ」を完全に消しました。5 プロダクトあっても、覚えるコマンドは 1 個。

6. 1 ダッシュボードの設計

監視は自作の Next.js dashboard 1 枚に集約しています。朝 5 分で「昨日 5 プロダクトで何が起きたか」を把握するための画面です。

指標の設計

• 5 プロダクト × 6 指標 = 30 マス：DAU / MAU / 昨日の売上 / エラー数 / p95 レイテンシ / 未解決 CS の 6 列を、プロダクトごとに 1 行で並べる。
• 色は 3 段階のみ：緑（正常）/ 黄（前日比 20% 悪化）/ 赤（閾値超え）。「何色か」だけを 5 秒で判断できる状態にしている。
• データソース：Sentry API + Stripe API + Supabase RPC + BigQuery scheduled query。Grafana も検討したが、5 プロダクト × 6 指標なら overkill。自作 Next.js で 100 行程度で書ける。

ダッシュボードは 「毎朝見る」ことに最適化 しているので、詳細分析機能は入れない。詳細を見たい時は、そのプロダクトの管理画面に飛ぶ。詰め込みすぎると 5 分で読めなくなり、結果として誰も見なくなる。

7. 「やらない」と決めていること 10 個

時間が限られるので、費用対効果の低い施策は明示的に「やらない」と決めています。決めておかないと、毎回「やった方がいいかも」と迷って時間を溶かすからです。

• SEO の毎週施策：技術的 SEO の基礎（sitemap / canonical / OGP）は初期に整えるが、コンテンツ SEO を毎週回さない。ROI が測れるまで 6 ヶ月かかるので少人数には合わない。
• SNS の日次投稿：X アカウントはあるが、投稿頻度に KPI を設定しない。プロダクト側のリリースがある時だけ書く。
• 大量のブログ記事：週 1 本ペースで、意味のある技術記事のみ。月 20 本のような量産はしない。
• 無料の chat サポート：メール or フォームのみ。リアルタイム chat は人的コストが青天井。
• 有料広告出稿：Google Ads / Meta Ads は原則やらない。獲得単価が LTV を超えるプロダクトが多いので、オーガニックと紹介に集中。
• イベント出展：カンファレンスへのブース出展は 1 回もやっていない。準備に 1 週間かかる割にリード数が読めない。
• 大規模採用：正社員採用は当面凍結。業務委託でスポット的に依頼する。
• 機能の全部盛り：ユーザーの要望を全部実装しない。3 回ルールを通ったものだけ入れる。
• 汎用化のための refactoring：具体的な需要がない抽象化は禁止。DRY より WET の方が、少人数マルチプロダクトには合う。
• 「AI 化」ラベル貼り：既存機能に AI を後付けして「AI プロダクト」を名乗ることはしない。AI がコア価値でないなら中途半端になる。

この 10 個を Notion の /company/DONT.md に書いて、月次で見直しています。増やすのは慎重に、減らすのは大胆に。

8. 失敗談 3 つ

ここまでの原則は、全部失敗から作られたものです。特に効いた 3 つを書きます。

8-1. 「共通認証基盤」を作ろうとした 2 週間

2026 年春、3 プロダクトの認証を統一しようとしました。Kotodama の Supabase Auth、Paircon の Firebase Auth、Merci の Stripe Customer Portal を、内製の OIDC provider にまとめる計画。設計と PoC に 2 週間かけて、結局 「ユーザー層が全く重ならないので統一メリットが 0」 と判明して撤回しました。学び：「技術的に統一できる」と「統一すべき」は別。ユーザー体験に価値がない統一は無駄。

8-2. AI 自動対応で誤情報を送ってしまった事件

あるプロダクトで、CS の初回応答を AI に任せた時期がありました。1 週間で、料金プランについて誤った情報をユーザーに返してしまい、返金対応と信頼回復に 3 日かかりました。学び：「初期段階の CS 自動化は、削減できたコストより信頼失墜の方が大きい」。以降、初期段階の CS は原則人間、と明文化。

8-3. 「今月ローンチ」と宣言して 3 週間遅延

あるプロダクトで、社内 Slack に「7 月末ローンチ」と宣言したものの、実際は 8 月中旬にずれ込みました。原因は、focus 週の切替を守らず、他プロダクトの緊急対応に流されたこと。学び：「宣言した focus は緊急障害以外で崩さない」 を厳守。それ以来、期日を切ったコミットメントの達成率が上がりました。

9. 数字で見る効果

これらの仕組みを 2 年間運用した結果、以下のような数字になっています。

• 週次オペレーション時間：ルール導入前 週 15 時間 → 導入後 週 5 時間。10 時間削減の内訳は、Sentry の閾値通知化で 3 時間、Renovate auto-merge で 2 時間、ダッシュボード集約で 3 時間、focus ルールで判断コスト削減 2 時間。
• 障害対応時間：月平均 3 時間、そのうち手動対応は 30 分程度。残り 2.5 時間は「調査 + 再発防止」で、対応そのものは自動化と巻き戻し設計で短縮できている。
• 機能追加ペース：focus ルール導入後、1 プロダクトあたりの機能リリース数が 30% 増加。「集中する期間」を作ったことで、1 スプリントの完了率が上がったのが要因。
• CS の 3 回ルール発火数：月 5〜8 件。そのうち FAQ 追記 60% / UI 改善 25% / 機能追加 15% の内訳。この分布を見ると、多くの問い合わせは UI とドキュメントで解決できることが分かる。

まとめ

複数プロダクトを少人数で回すコツは、「独立性 × 放置耐性 × 集中対応 × 自動化 × やらない勇気」 の 5 つに集約されます。この 5 つを、抽象論としてではなく、Renovate や focus ルール、3 回ルールのような 具体的な仕組み まで落とし込めるかどうかが分かれ目です。

私たちも 2 年前は週 15 時間を運用に溶かしていました。今は週 5 時間で 5 プロダクトが安定稼働しています。差はセンスや才能ではなく、「何を仕組み化して何をやらないと決めるか」の設計の粒度でした。次の 1 プロダクトを立ち上げる余力を作るのは、新機能ではなく、この地味な運用設計だと思っています。