技術の準備とは、コードを綺麗にすることではなく、「今どうなっているか」を説明できる状態にすることです。
使い方
各項目について、「資料がある」「口頭なら説明できる」「今は説明できない」の3つに分類してください。すべてを資料にする必要はありません。重要なのは、説明できない項目がどこに集中しているかを把握し、調達準備の期間中に埋める順番を決めることです。社内に技術責任者がいない場合は、開発を依頼している相手と一緒に埋めるのが現実的です。
A. プロダクトの全体像を説明できるか
最初に問われるのは、細かい技術ではなく全体の構造です。どのような部品でできていて、どこが外部サービスに依存しているかを、図一枚と数分の説明で伝えられる状態を目指します。図は手書きでも構いませんが、実態と一致していることが前提です。
- システム構成図(利用者から見た画面、サーバー、データベース、外部サービスの関係)が最新か
- 使っている言語・フレームワーク・クラウドを列挙できるか
- 外部サービスへの依存を一覧にし、それぞれが止まったときの影響を言えるか
- 自社で作った部分と、既製品を使っている部分の境界を説明できるか
B. 開発体制と、人への依存
小さなチームでは、特定の一人しか触れない領域が生まれがちです。これ自体は珍しいことではありませんが、把握していないと、その人が離れたときに事業が止まります。どこに集中しているかを地図にしておきます。
- 現在の開発メンバー(社員・業務委託・外注)と、それぞれの担当領域
- 一人しか触れない領域はどこか、その領域の資料は残っているか
- 本番環境を操作できる人は誰か、その権限は記録されているか
- 調達後にどのような体制へ移行する想定か(採用か、外部の継続か)
C. 権利と契約の整理
調達の場で確認されやすく、かつ後から直すのに時間がかかるのがこの領域です。関係者が増えるほど遡っての整理が難しくなるため、早い段階で状態を把握しておきます。
- ソースコード・デザインデータの権利の帰属が、契約書で確認できるか
- 業務委託・副業メンバーとの成果物の取り決めが書面であるか
- 使っているオープンソースのライセンスを把握しているか
- ドメイン・クラウド・各種サービスの名義が自社になっているか
D. 個人情報とセキュリティの現状
取り扱う情報の種類によって、求められる水準は変わります。過剰な対策を先回りするより、「何を持っていて、どこにあり、誰が触れるか」を正確に言えることが先です。説明できない状態が、もっとも懸念されます。
- 取得している個人情報の項目と、保存場所の一覧があるか
- アクセスできる人の範囲と、その記録が残るか
- プライバシーポリシーと実際の運用が一致しているか
- 過去に起きた障害や不具合の記録と、その後の対応を説明できるか
- 外部サービスに顧客データを渡している場合、その範囲を把握しているか
E. 数字が取れる状態か
調達の議論では、事業の数字とプロダクトの利用状況が結びついている必要があります。集計のたびに手作業が発生する状態だと、議論の速度が落ちます。どこまで自動で見えるかを確認します。
- 主要な指標(登録、継続、利用頻度、解約)が、毎回手作業なしで見られるか
- その数値の定義が文書化され、社内で同じ意味で使われているか
- 過去分のデータが残っているか、いつから残っているか
- 数値の集計方法を第三者に説明できるか
F. 拡大に向けた見通し
現時点で大規模な負荷に耐える必要はありません。求められるのは、利用が増えたときにどこが先に問題になるかを把握していることと、その対処の方針を持っていることです。分からない場合は「未確認」と書き、確認の計画を立てます。
- 利用が現在の10倍になったとき、最初に問題になりそうな箇所はどこか
- その箇所の対処方針(設定変更で足りるか、作り直しが必要か)
- 現在のインフラ費用と、利用が増えたときの増え方の見当
- 作り直しが必要な箇所があるなら、その規模感と時期の見通し
G. 調達後の開発計画
技術準備の最後は、調達した資金を何に使うかの説明です。機能の一覧ではなく、事業の目標と開発の項目が結びついている形にします。ここが弱いと、他の項目が整っていても説得力が下がります。
- 調達後12か月で達成したい事業目標
- その達成に必要な開発項目を、大きな単位で3〜5個
- 各項目に必要な体制(人数と期間の見当)
- 開発以外に必要な支出(インフラ、外部サービス、採用)
- 計画が想定どおりに進まなかった場合の、優先順位の落とし方
H. 埋める順番を決める
すべてを同時に整えるのは現実的ではありません。説明できない項目のうち、後から直すのに時間がかかるものを先に着手します。目安として、権利と契約の整理、個人情報の所在の把握、数字が取れる状態の3つは、着手から完了までの期間が読みにくく、早めに始める価値があります。
- 今週中に着手するもの(所在の確認や棚卸しなど、調べれば分かること)
- 1か月以内に着手するもの(契約書の確認や、関係者との調整が要ること)
- 調達準備と並行して進めるもの(体制の移行計画、開発計画の精緻化)
関連するインサイト
- 資金調達フェーズ別に見る、開発パートナーとの関わり方プレシード・シード・シリーズA・シリーズB以降の各フェーズで検証すべきこと、開発体制、契約形態、避けたい失敗を整理し、外部の開発パートナーとどう関わるかを段階ごとに解説します。
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
- プロダクトのKPI設計とダッシュボード — 見るべき指標を絞る北極星指標を起点に先行指標・遅行指標へ分解し、PMF前後のフェーズに応じて見るKPIを絞る考え方と、意思決定に使えるダッシュボードの設計、計測の信頼性、やりがちな失敗を整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開