技術の準備とは、コードを綺麗にすることではなく、「今どうなっているか」を説明できる状態にすることです。
使い方
各項目について、「資料がある」「口頭なら説明できる」「今は説明できない」の3つに分類してください。すべてを資料にする必要はありません。重要なのは、説明できない項目がどこに集中しているかを把握し、調達準備の期間中に埋める順番を決めることです。社内に技術責任者がいない場合は、開発を依頼している相手と一緒に埋めるのが現実的です。
A. プロダクトの全体像を説明できるか
最初に問われるのは、細かい技術ではなく全体の構造です。どのような部品でできていて、どこが外部サービスに依存しているかを、図一枚と数分の説明で伝えられる状態を目指します。図は手書きでも構いませんが、実態と一致していることが前提です。
B. 開発体制と、人への依存
小さなチームでは、特定の一人しか触れない領域が生まれがちです。これ自体は珍しいことではありませんが、把握していないと、その人が離れたときに事業が止まります。どこに集中しているかを地図にしておきます。
C. 権利と契約の整理
調達の場で確認されやすく、かつ後から直すのに時間がかかるのがこの領域です。関係者が増えるほど遡っての整理が難しくなるため、早い段階で状態を把握しておきます。
D. 個人情報とセキュリティの現状
取り扱う情報の種類によって、求められる水準は変わります。過剰な対策を先回りするより、「何を持っていて、どこにあり、誰が触れるか」を正確に言えることが先です。説明できない状態が、もっとも懸念されます。
E. 数字が取れる状態か
調達の議論では、事業の数字とプロダクトの利用状況が結びついている必要があります。集計のたびに手作業が発生する状態だと、議論の速度が落ちます。どこまで自動で見えるかを確認します。
F. 拡大に向けた見通し
現時点で大規模な負荷に耐える必要はありません。求められるのは、利用が増えたときにどこが先に問題になるかを把握していることと、その対処の方針を持っていることです。分からない場合は「未確認」と書き、確認の計画を立てます。
G. 調達後の開発計画
技術準備の最後は、調達した資金を何に使うかの説明です。機能の一覧ではなく、事業の目標と開発の項目が結びついている形にします。ここが弱いと、他の項目が整っていても説得力が下がります。
H. 埋める順番を決める
すべてを同時に整えるのは現実的ではありません。説明できない項目のうち、後から直すのに時間がかかるものを先に着手します。目安として、権利と契約の整理、個人情報の所在の把握、数字が取れる状態の3つは、着手から完了までの期間が読みにくく、早めに始める価値があります。
関連するインサイト
- 資金調達フェーズ別に見る、開発パートナーとの関わり方プレシード・シード・シリーズA・シリーズB以降の各フェーズで検証すべきこと、開発体制、契約形態、避けたい失敗を整理し、外部の開発パートナーとどう関わるかを段階ごとに解説します。
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
- プロダクトのKPI設計とダッシュボード — 見るべき指標を絞る北極星指標を起点に先行指標・遅行指標へ分解し、PMF前後のフェーズに応じて見るKPIを絞る考え方と、意思決定に使えるダッシュボードの設計、計測の信頼性、やりがちな失敗を整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開