少人数チームで複数プロダクトを維持する仕組み
ClearNets は少人数チームで 5 つ以上のプロダクトを運用しています。「そんなに手が回るのか」とよく聞かれます。答えは『回っている』ですが、そこには意識的な設計があります。
1. 「マルチプロダクト戦略」ではなく、それぞれ独立
複数プロダクトを持つと聞くと、「共通基盤で効率化」を思い浮かべる方が多いですが、私たちはあえて逆の方針です。各プロダクトは技術的に独立 しており、共通基盤は最小限にしています。理由は、共通基盤の複雑さが結局は各プロダクトの開発速度を落とすからです。それぞれのプロダクトが、それぞれのペースで進化できる方が、全体としては速くなります。
2. 「今週触るプロダクト」を 1-2 個に絞る
5 プロダクトを同時に、毎日、全部触ることはしません。それは不可能だからです。代わりに、「今週はこれ」と決めて 1-2 個に集中します。他は運用モードで、緊急事態のみ対応する状態にします。
これができるのは、各プロダクトを「触らなくても壊れない」状態に持っていく努力を、初期から続けているからです。放置耐性 は、少人数チームで複数プロダクトを持つうえで最重要の設計原則です。
3. カスタマーサポートを自動化しない、でも構造化する
問い合わせは全部人間が対応します。AI で自動化することは、少人数の頃はやりません。「対応品質＝プロダクトの品質」だと思っています。
ただし、問い合わせの内容と対応履歴を Notion に構造化して蓄積します。似た問い合わせが 3 回来たら、FAQ にする、UI で解決する、機能を追加する、のいずれかで根本対応します。これが「対応が積み上がらない」仕組みです。
4. デプロイは 1 コマンド、監視はダッシュボード 1 枚
各プロダクトのデプロイは、gh workflow run xxx の 1 コマンドで完結します。監視は Vercel の Analytics + Sentry + カスタムダッシュボードの 3 つに集約しており、朝 5 分で全プロダクトの状態を把握できます。この 1 コマンド + 1 ダッシュボード の設計が、複数プロダクトを持つうえで肝です。
5. 「やらないこと」を明確にする
SEO 施策を毎週やる、SNS で毎日投稿する、大量のブログ記事を書く — これらは全部「やらない」と決めています。時間が限られるので、費用対効果の高い施策だけに集中します。
これは間違いを恐れずに言うと、「機会損失を許容する」 という選択です。全部やろうとすると全部が中途半端になります。優先順位を明確にする勇気の方が、少人数チームには必要です。
まとめ
複数プロダクトを少人数で回すコツは、「独立性 × 放置耐性 × 集中対応 × 自動化 × やらない勇気」の 5 つに集約されます。この 5 つを意識するだけで、少人数チームでも意外と多くのプロダクトを維持できます。