同じ質問を候補すべてに投げると、答え方の違いから、自社に合う相手が見えてきます。
使い方
候補となる会社やチームに、同じ資料と同じ質問を渡してください。答えの内容だけでなく、「答えられない質問にどう対応するか」「質問の意図を汲んで補足してくれるか」も判断材料になります。すべてに完璧な答えがある必要はありません。自社にとって重要な質問がどれかを先に決めておくと、比較がしやすくなります。
A. 事業フェーズとの相性(質問1〜3)
スタートアップは、事業の段階によって必要な開発の性質が変わります。仮説検証の段階では速さと柔軟さ、資金調達後は拡張性と安定性が重視されます。相手がどの段階を得意とするかを確かめます。
- 質問1: 自社と同じ事業段階(仮説検証中、調達直後、拡大期 など)の会社を支援した経験はありますか。そのとき、どのような進め方をしましたか
- 質問2: 資金調達の前後で、開発の進め方や体制を変えることはできますか。たとえば、検証期間は小さく、調達後に体制を増やすといった対応は可能ですか
- 質問3: 自社の事業計画や資金の状況を踏まえて、「今は作らないほうがよい」という提案をすることはありますか
B. 契約と費用の考え方(質問4〜6)
仕様が固まっていないスタートアップの開発では、請負契約よりも準委任契約が向くことが一般にあります。契約の形と、仕様変更や中断が起きたときの扱いを確認します。金額そのものより、その決まり方を聞くのが目的です。
- 質問4: 契約形態は請負と準委任のどちらが基本ですか。仕様が途中で変わることを前提とした場合、どのような契約を提案しますか
- 質問5: 見積りの内訳はどのような単位で示されますか。含まれない作業(設計、テスト、インフラ構築、保守 など)は何ですか
- 質問6: 資金の都合で開発を一時中断したり、規模を縮小したりする場合、契約上どのような扱いになりますか
C. 体制と進め方(質問7〜9)
誰が窓口で、誰が実際に作るのかは、意思疎通の速さと品質に直結します。小さなチームでは、担当者が一人に偏ることもあるため、その備えも聞いておきます。
- 質問7: 窓口となる方は、設計や開発にも直接関わりますか。関わらない場合、自社の要望はどのように開発担当者へ伝わりますか
- 質問8: 進捗の共有はどの頻度・どの手段で行いますか。自社側で確認や判断が必要になる場面はいつですか
- 質問9: 担当者が対応できなくなった場合、どのような備えがありますか。引き継ぎのための資料は日常的に残していますか
D. CTOや技術責任者が不在の場合の支援(質問10〜11)
創業期には、技術の判断を任せられる人が社内にいないことが珍しくありません。その状態で開発を依頼する場合、技術選定や採用の判断を相談できる相手かどうかが重要になります。
- 質問10: 社内に技術責任者がいない場合、技術選定やアーキテクチャの判断について、どこまで相談に乗ってもらえますか。判断の根拠を自社が理解できる形で説明してもらえますか
- 質問11: 将来、社内にエンジニアを採用したり、技術責任者を迎えたりする際に、採用要件の整理や受け入れ準備を手伝ってもらえますか
E. 成果物の帰属と技術の透明性(質問12〜13)
ソースコードや設計資料の権利が誰にあるかは、将来の資金調達や事業売却、他社への移行のときに問題になります。契約前に必ず書面で確認します。また、使う技術が一般的なものかどうかは、後から人を採用できるかに関わります。
- 質問12: ソースコード、設計資料、デザインデータの権利は、納品後に自社へ帰属しますか。ライブラリやテンプレートなど、帰属しない部分があれば明示してもらえますか
- 質問13: 使用する言語やフレームワーク、クラウドサービスは何ですか。それらは一般的に採用されており、後から他のエンジニアが引き継げるものですか
F. 保守と引き継ぎ(質問14〜15)
リリース後の保守と、将来の内製化や他社への移行がスムーズにできるかを確認します。「離れにくい」仕組みになっていないかを見る質問です。
- 質問14: リリース後の保守は、どの範囲を、どのような条件で行いますか。緊急時の連絡方法と対応時間はどうなりますか
- 質問15: 将来、自社が開発を内製化する、または別の会社へ移行する場合、どのような形で引き継ぎを行いますか。サーバーやドメイン、各種サービスのアカウントは自社名義で管理できますか
答えを比較するときの見方
すべての質問に「できます」と答える相手より、「これはできる、これは条件付き、これは他社のほうがよい」と分けて答える相手のほうが、実際の仕事でも境界を明確にしてくれる傾向が一般にあります。また、質問に対して逆に質問が返ってくる(「なぜそれが必要ですか」「事業の段階はどこですか」)ことは、相手が状況を理解しようとしている表れです。最後に、契約前に小さな範囲の作業を先に依頼して、やり取りの質を確かめる方法もあります。
- 答えの一貫性: 契約の説明と見積りの内訳が食い違っていないか
- 境界の明確さ: できないこと、得意でないことを言えるか
- 理解の姿勢: 自社の事業や段階について質問してくるか
- 書面化: 口頭の説明が、契約書や提案書に反映されるか
関連するインサイト
- 開発パートナーの選び方|4つの選択肢の違いスタートアップがプロダクト開発の依頼先を選ぶときの判断軸を整理します。大手SIer、Web制作会社、フリーランス、小規模開発会社、内製の向き不向きを資金調達フェーズと速度の観点で比較し、契約前に確認したい質問と、内製化への移行の考え方を解説します。
- アジャイル開発と契約 — 準委任で進める場合の合意事項アジャイル開発と請負契約の相性、準委任契約で進める理由、目的とスコープ・体制・検収・変更・知的財産権・中途終了など事前に合意すべき事項と発注側の責務を、発注者の視点で整理します。
- 技術顧問・外部CTOという選択肢 — 何を任せ、何を社内に残すか技術顧問・外部CTOに任せられる役割と、社内に残すべき意思決定やドメイン知識を整理し、契約形態、成果の測り方、内製化との関係、向くケース・向かないケースを解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開