大規模なソロ運用：少人数で数十のプロジェクトを管理する
小規模な事業でも、成長するにつれて、進行中のプロジェクト数が頭の中で把握できる範囲を超える時点が来ます。複数のマーケットプレイスで注文を監視し、インフラを定期的に保守し、新機能を開発する必要があります。顧客からは出荷、コンプライアンス、見通しについて質問が届きます。どれも必要な仕事ですが、使える時間はプロジェクト数に比例して増えません。
この状況への助言は、たいてい増員を前提としています。それが適切な場合は多いものの、常に正解とは限りません。特に、技術スタック、分野、運用のペースが異なる多様なプロジェクトを抱え、個々のプロジェクトから得られる追加収益では専任者を雇えない場合です。数十のプロジェクトを管理する少人数チームには、人員だけでなく仕組みが必要です。
この記事では、当社の進め方を紹介します。長期にわたって有効だったツールの選択、調整負荷を減らす運用原則、新しいものを作る仕事と既に動いているものを保守する仕事の両立について説明します。
開発と保守の両立
規模が拡大した少人数チームの運用では、2種類の仕事が同じ資源、つまり注意力を奪い合うことが根本的な課題となります。新しいものを作るには、途中で中断されない、探索に向けた集中が必要です。既存システムの保守には、状況に応じて即座に反応する注意力が必要です。この2つの状態は両立しにくく、切り替えのコストはプロジェクト管理ツールには表れません。
実際の運用上の問題の多くは、一方を選ぶ判断を誤ったためではありません。選ばないまま、保守と開発の境界が曖昧になり、どちらも適切に進まなくなることから生じます。開発が保守を押しのけるため保守の未処理項目が増え、保守による中断が重なるため開発が停滞します。両方に悪影響が出ます。
当社では、成り行きではなく、意図的に時間を配分しています。毎週一定の割合をインフラの確認、依存関係の更新、監視の点検、顧客への報告などの保守に確保し、どれほど魅力的な開発案件があっても、その時間は開発に使いません。開発時間も、実際の障害を除いて保守による中断から守ります。分単位で厳密に固定するわけではありませんが、他の優先事項にいつの間にか使われてしまわない程度には徹底します。
ツールの選択
ツール選定の原則は、スタック内の標準化を徹底し、スタックの種類を最小限にすることです。ツールが1つ増えるたびに、故障し得る箇所、学ぶべきこと、問題発生時に無関係な仕事まで止める依存先が増えます。ツールのコストはライセンス料ではなく、それに関わるすべての作業で継続的に必要となる注意力です。
インフラには、単一のプロバイダーでDockerを運用しています。Kubernetesでも、マルチクラウドでも、サービスメッシュでもありません。十分な仕様のVPS上のDocker Composeで、現在運用するすべての処理をまかなえます。明確なドキュメントがあるため、障害からの復旧も容易です。より高度なインフラの運用複雑性は、他の面で得られる利点以上に、保守に必要な注意力を増やしてしまいます。
アプリケーション開発では、少数の技術に標準化しています。WebフロントエンドにはTypeScript、バックエンドサービスとデータパイプラインにはPython、永続ストレージにはPostgreSQL（多くの場合TimescaleDB）、キューとキャッシュにはRedisを使います。新規プロジェクトも、別の技術を使う明確な理由がなければこの構成を採用します。その理由は明示し、標準外のスタックを長期保守するコストと比較する必要があります。
プロジェクトとタスクの管理には、ツール自体の管理が1つのプロジェクトにならないほどシンプルな仕組みを使います。複雑なプロジェクト管理システムの維持負荷が、管理対象のプロジェクトの調整負荷を上回ることも珍しくありません。必要な構造は、各プロジェクトの現在の状態、次の行動、担当者が明確であることです。それ以外の詳細は任意です。
大切なのは、まだ抱えていない問題を解決する新しいツールへの導入圧力に流されないことです。新しい可観測性プラットフォーム、デプロイパイプライン、チーム連絡ツールは、いずれも解決策として提案されます。しかし、導入コストは確実に、すぐ発生する一方、利点は不確かで後から得られるものです。当社は「現在のどの具体的な問題を解決し、導入と保守のコストに見合うのか」という問いで新しいツールを評価します。
非同期のやり取りを優先する運用
通話、会議、リアルタイムのチャットといった同期的なやり取りには、話題の複雑さにかかわらず、毎回一定のコストがかかります。日程調整の負荷が、やり取り自体の負荷を上回ることもあります。多様なプロジェクトを抱える少人数チームでは、同期的な調整が稼働時間の過大な割合を消費しかねません。
当社は非同期のやり取りを優先し、文書での連絡と記録を基本としています。同時に話すのは、文章だけでは十分でない場合に限ります。資料を読めば答えられる質問は、資料を読んで解決すべきです。資料がなければ、質問への対応として資料を作ります。その場だけ答えて次回の質問を未解決のままにする通話ではありません。
この原則を実践するため、意思決定は文書に残します。データベースの選定、デプロイ手順の変更、顧客の業務フローの修正など、技術面や運用面で重要な判断をしたら、理由、検討した代替案、期待する結果を記録します。後世のためではなく、同じ問いが再び生じたときのためです。少人数で複数プロジェクトを運用すると、それは予想以上に頻繁に起こります。
進捗報告も、その都度口頭で行うのではなく、予定を決めて文書で行います。各プロジェクトについて、現在の状況、最近の変更、今後の作業、障害となる事項を毎週簡潔に記録し、会議での報告に置き換えます。文章にすると具体性が求められるため、口頭の確認では表面化しなかった問題が見つかることもあります。
自社開発か購入か
自社で作るツールはすべて、期限を定めず保守を続けることになるプロジェクトです。開発を決める時点では、目に見えるコストは構築費用、利点はツールが提供する機能なので、この点を忘れがちです。継続的な保守コストは後から見えてきますが、確実に存在し、積み重なります。
当社は、自社開発か購入かを3つの基準で判断します。第1に、問題を十分に解決する既存ツールがあるか。十分とは完璧という意味ではありません。課題の90パーセントを適切に解決する商用ツールは、継続保守を必要としながら100パーセントを解決する独自ツールよりも、ほぼ常に望ましい選択です。残る10パーセントの不足は、独自ツールの継続保守コストより小さいことが多いためです。
第2に、外部ツールでは把握できない自社固有のデータやシステムの知識が必要か。データパイプライン、業務ロジック、自社管理システム間の連携は、自社開発の候補です。メール配信、決済処理、認証、監視ダッシュボードなどの汎用機能は、商用の選択肢が適さない場合を除き、購入の候補です。
第3に、対象データを外部サービスと共有してよいか。注文の詳細、顧客情報、財務記録などの運用データは、独自の目的で記録、分析、利用する商用サービスを経由させるべきではありません。こうした機能では、商用サービスが技術的に優れていても、プライバシー保護の観点からセルフホスト型の選択が正当化されます。当社が分析基盤、Supabaseのバックエンド、監視スタックをセルフホストしているのもこの理由です。
実際、当社で最もコストがかかった開発判断も、その時点で明らかに誤っていたわけではありません。特定のニーズに合った妥当な独自ツールに見えました。コストが明らかになったのは18か月後、依存関係の変更に合わせた更新が必要になったとき、外部ドキュメントのないコードを新しいメンバーが理解しなければならなくなったとき、あるいはツールのバグで顧客向けの成果物が止まり、相談できるサポート窓口もなかったときです。教訓は、自社開発を一切しないことではなく、構築費用だけでなくライフサイクル全体のコストを正直に見積もることです。
ポートフォリオの視点
数十のプロジェクトを同時に管理するには、それぞれを独立した義務ではなく、ポートフォリオの一部として捉えると取り組みやすくなります。ポートフォリオには、継続的な投資が比較的少なくても成果が時間とともに積み上がるプロジェクトと、横ばいまたは下降傾向のプロジェクトが含まれます。それぞれで資源配分の判断は異なります。
成果が積み上がるプロジェクトでは、機能しているものを守るための保守投資は必要ですが、大規模な追加開発が必要なことはまれです。自然検索順位が安定し、レビュー評価が良好で、物流も確実なEC事業は、既に収益を生む状態を築いています。仕事は改善することより、壊さないことです。まだ構築中のプロジェクトとは根本的に姿勢が異なり、必要な注意力も少ないため、まだ成果が積み上がっていない案件に取り組む余力が生まれます。
成果が積み上がらないプロジェクトは、追加投資で状況が改善しそうなのか、それとも結果を受け入れて資源を再配分すべきなのか、明確に評価する必要があります。多くの案件を抱える少人数チームは、既に費やした労力を理由に、うまくいかない案件へ投資を続ける埋没費用の誤謬に特に陥りやすいものです。ポートフォリオとして捉えると、停滞した案件の維持に使う注意力は、成果が積み上がり得る案件には使えないという比較が不可避になり、この失敗に気づきやすくなります。
本当のボトルネック
少人数チームの拡大を妨げる制約として、一般には資金と時間に注目が集まります。プロジェクトが増えれば、その資金と実行時間もより多く必要になります。それは正しいものの、十分な説明ではありません。
複数分野にまたがる多様なプロジェクトを管理する少人数チームにとって、決定的な制約は注意力です。特に、背景を理解したうえで判断するために使える注意力の質が重要です。定型的な運用作業は、仕組み化、委任、自動化が可能です。一方、次に何を作るか、市場の変化にどう対応するか、新しいマーケットプレイスへ参入するか、技術的な方針は妥当かといった判断には、全体の背景を理解する人の判断力が必要です。この種の注意力はチームの人数に比例して増えず、仕組み化で不要にすることもできません。
したがって、少人数チームの運用で最も重要なのは、同じ作業を速くこなす効率性よりも、そもそも何に取り組むかを選ぶ選択性です。存続のために常に注意を向ける必要がある案件は、直接費用が低くても安価な案件ではありません。最小限の介入で安定して動く案件は、高度な判断を要する仕事の注意力を消費しないため、売上から見える以上の価値を持つポートフォリオの要素です。
当社は案件選定で、この点を明示的に評価します。新しい取り組みを決める前に、構築工数だけでなく、安定運用時に必要な注意力、つまり完成後の運用に週何時間かかるかを見積もります。得られる成果に対して安定運用の注意力コストが高い案件は、構築費用と潜在的な利益だけを見る場合ほど魅力的ではありません。注意力には限りがあり、資金や時間と違って、追加で買うことはできません。
関連記事
- 販売の仕組みを設計する：自分が売り込まなくても売れるシステムの構築：少ない注意力で運用できる仕組みを作る基本原則。
- 100を超えるDockerコンテナ：毎月の健全性チェックの手順：インフラの運用負荷を予測可能に保つ保守の習慣。
- FastAPIとTimescaleDBでAmazonのデータウェアハウスを構築する：自社開発を選んだ例と、ポートフォリオを支えるデータ基盤。