シリーズAで開発の何が変わるか

シリーズAの調達を終えた会社で起きやすいのは、次のような状態です。「人を増やしたのに、以前より開発が進まなくなった」「数字は伸びているが、なぜ伸びているのか説明できない」。

これは失敗ではなく、フェーズが変わった兆候です。シード期にうまく機能していた進め方が、そのままでは通用しなくなっただけです。本記事では、シリーズAで開発の何が変わるのか、何を作り足し、何を捨てるのかを整理します。

開発の目的が入れ替わる

シード期の開発は、確かめるための開発でした。作ったものが正しいかどうかは分からない前提で、速く出して反応を見ることが優先されます。この前提のもとでは、作り込まない、記録を残しすぎない、少人数で口頭で決める、といった進め方が合理的でした。

シリーズAでは前提が変わります。すでに使われるものは分かっており、確かめたいのは「顧客の獲得と定着を、繰り返し再現できるか」です。再現するには、何が効いたのかが分かる必要があり、人が増えても同じ品質で回る必要があります。

この違いを、作るものの言葉に置き換えると次のようになります。

作り足すもの その一：計測基盤

最初に整える価値が高いのは計測です。伸ばす施策を打つ前に、何が起きているかを読める状態にします。

具体的に必要になるのは次の要素です。

• 顧客が入ってから定着するまでの流れを、段階ごとに数えられること。登録、初回利用、繰り返し利用、有料化といった段階で、どこで人が減っているかが分かる状態です
• 指標の定義が文章になっていること。「アクティブユーザー」が何を指すのかが人によって違うと、数字の議論が噛み合いません。定義と、変更したときの履歴を残します
• 施策と数字を紐づけられること。どの流入経路から来た人がどう定着したかが分からないと、広告費の判断ができません

設計の考え方はプロダクトのKPI設計とダッシュボードで扱っています。ここで強調したいのは、シリーズAの計測は「経営会議で見る資料」ではなく、日々の判断に使える状態を指すという点です。担当者が自分で数字を見て、翌週の施策を決められるかどうかが基準になります。

作り足すもの その二：権限管理

シード期は権限の種類を絞る判断が有効でしたが、シリーズAではこれが逆転します。理由は、社員が増え、顧客側の組織も大きくなるからです。

見直す観点は二つあります。

自社側。社員、業務委託、外部パートナーが同じシステムを触るようになります。誰がどこまで見られるかを役割で決め、退職や契約終了のときに確実に外せる形にします。本番データを全員が見られる状態は、この規模になると事故の原因になります。

顧客側。法人向けであれば、顧客の組織内で管理者と一般利用者を分けたい、部署ごとにデータを分けたいという要望が出てきます。これはシード期に作り込むべきでないものでしたが、実際の要望が出た今なら、必要な形が分かります。

権限の変更は、後から入れるほど影響範囲が広がります。この段階で一度、増員を前提にした設計に直しておくと、以降の変更が小さく済みます。

作り足すもの その三：運用体制

三つ目が、開発者以外が運用を回せる状態です。シード期は、問い合わせが来たら開発者がデータベースを見て答える、という運用でも成立しました。件数が増えると、この形は開発を止めます。

必要になるのは次の三つです。

• サポート担当が自分で調べられる画面。利用者の状態、直近の操作履歴、エラーの発生状況が、開発者を介さずに確認できること
• 障害に気づく仕組み。顧客からの連絡で障害を知る状態から、監視で先に気づく状態へ移します
• リリースの手順の自動化。テストと配信がCI/CDとして自動化されていれば、特定の人がいない日でも変更を出せます

この三つは顧客に見える機能ではないため、優先順位が下がりがちです。しかし、ここが整っていないと、増やした人員の時間が運用の割り込みに消えます。

捨てるもの

作り足す話と同じくらい重要なのが、検証期の進め方のどこを捨てるかです。

口頭での決定。少人数のうちは、話して決めてすぐ作るのが最速でした。人が増えると、決定が共有されず、同じ議論が繰り返されます。決めたことと、その理由を短くても書き残す習慣に切り替えます。

一人が全部を把握している状態。シード期の強みでしたが、この段階では単一障害点になります。設計の意図、環境の構築手順、外部サービスのアカウント情報を、一人の頭から出します。

テストなしでの変更。利用者が少ないうちは、壊れてもすぐ直せました。顧客が増えると、壊れたこと自体が信用の損失になります。手作業の確認から、自動テストへ移す時期です。

全員が同じものを見ている前提。役割が分かれると、見るべき数字も変わります。全員が同じダッシュボードを眺める運用から、役割ごとに必要な情報が届く形へ変えます。

増員と同時にやらないこと

シリーズA直後によくある失敗が、「人を増やす」「基盤を整える」「新機能を出す」を同時に始めることです。三つとも必要ですが、同時に始めると、基盤が整っていない状態で増えた人が動き、新機能の追加で基盤の整備が後回しになります。

現実的な順序は、計測を先に整え、次に人を受け入れる環境（環境構築の手順、権限、ドキュメント）を整え、それから増員と機能開発を進める形です。体制の設計は少人数開発チームの体制設計、人数と外部比率の判断はフェーズ別、開発の人数と外部比率で扱っています。

あわせて、この時期には技術的負債の返済が議題になります。全面的な作り直しは選ばず、増員の障害になる部分から順に返す考え方を調達後に返す技術的負債の順番にまとめました。

この段階の判断基準

シリーズAで作るものを決めるときの基準は、「これがないと、次の一年で人が増えたときに何が詰まるか」です。顧客に見える機能は、この基準では優先順位が下がることがあります。それでも、計測・権限・運用の三つを先に整えたチームのほうが、結果として機能を多く出せます。

シリーズA以降の開発体制や基盤の整備については、Webシステム開発、インフラ整備・クラウドコスト最適化、開発チーム体制構築・内製化支援とあわせてお問い合わせからご相談ください。