Airtable構築を外注する前に用意するもの──見積もりが早く出る3つの材料と、3〜6ヶ月という期間の中身
「要件が固まっていないと相手にされないのでは」とよく聞かれます。要件定義書は必要ありません。代わりに何があると早いのか、無い場合に私たちが契約前にやっていること、3〜6ヶ月という期間の中身、そして「完成」ではなく「成功」を先に定義するフェーズの切り方まで、受注する側として開示します。
外注を検討する担当者からよく聞かれるのが「要件が固まっていないと、見積もりも出してもらえないのでは」という不安です。結論から言うと、要件定義書は要りません。ただ、あると明らかに早く進む材料はあります。
この記事でわかること
- あると早い3つの材料（きれいな資料でなくて構いません）
- 材料が無い場合に、私たちが契約前にやっていること
- 最短3ヶ月の中身と、短縮できない理由
- 実案件でのフェーズの切り方（着手費用と成功費用の分け方）
- 資料より重要な、発注前に決めておくこと
あると早い3つの材料
私たちが実際に構築を進めるとき、初期にあると話が一気に速くなるのは次の3つです。きれいな資料である必要はありません。手書きでも、作りかけでも構いません。
「既存CRMのER図」
いま使っているCRM/SFAが、どんなデータをどう持っているかの図です。テーブル（取引先・案件・活動履歴など）と、その繋がりが分かるもの。
これがあると、移行対象の全体像と、分解し直すべき箇所がすぐ見えます。Salesforceなどからの移行では、既存の構造をそのまま持ってくるべきではない部分が必ずあるので、最初に全体を把握できるかどうかで設計のスピードが変わります。
「既存の営業業務フローの分解図」
データではなく、人の動きです。リードが入ってから受注までに、誰が何をして、どこで情報を入力しているか。
ER図が「何を持っているか」なのに対し、こちらは「どこで詰まっているか」が見える材料です。入力が二重になっている箇所、誰も見ていないのに更新し続けている項目——こういうものは、構造図だけ見ても出てきません。 実案件で整理したときは、4層・9フェーズという粒度になりました——①リード育成（7段階）→②商談（4段階：見極め→課題・ゴール確認→担当者の合意→決裁者の承認）→③導入（5段階）→④運用。ここまで分解できていると、「どのフェーズで、どのデータが増えるのか」が見えます。
「to-beのイメージ」
どういう業務フローにしたいか。完成された設計でなくて構いません。「この転記をなくしたい」「上長が案件状況を自分で見られるようにしたい」といった箇条書きでも十分です。
これが無いと、私たちは「今あるものをそのまま作り直す」提案しかできません。移行は設計し直す機会なので、目指す姿が言語化されているほど、提案の質が上がります。
整理すると as-is 2つと to-be 1つ
①ER図＝現状のデータ構造、②業務フロー分解図＝現状の人の動き、③to-be＝目指す姿。現状を2つの角度から、そして行き先を1つ。この3点が揃っていると、ヒアリングを設計の議論から始められます。
無くても大丈夫です（実際どうしているか）
ここまで書いておいて何ですが、これらが揃っている会社の方が少ないです。ER図が最新の状態で残っている会社はほとんどありません。
私たちは、契約が始まってから一緒に準備することも普通にやっています。むしろ、業務フローの分解は当事者だけで書き切るのが難しいので、一緒にやった方が精度が上がることが多いです。
契約前でも、as-isとto-beはある程度お見せしています
「要件が固まってから来てください」とは言いません。契約前の段階でも、ヒアリングした内容からas-isとto-beをある程度整理してお見せするようにしています。それがないと、発注する側も何にお金を払うのか判断できないからです。逆に言えば、この整理を出してこない会社には注意した方がいいです。中身が見えないまま金額だけ提示されることになります。
契約前の段階で、こちらがやっていること（実案件の例）
| やったこと | 目的 |
|---|---|
| 既存CRMの検証環境を見せてもらい、実構造を読む | 移行の難易度を実測する |
| 製品カタログを精読し、営業の本質を言語化する | なぜ商談が複雑なのかを理解する |
| as-isの「実物証拠」を集める | 現状の課題を、印象ではなく事実で共有する |
| to-beのテーブル設計を書き、簡易プロトを組む | 「こう変わる」を画面で見せる |
3つ目が効きます。実案件では、現行CRMの取引先テーブルの数十項目がほぼ空欄・金額がすべて¥0という状態、MA連携がエラーで停止している状態、ダッシュボードが「グラフデータがありません」と表示される状態を、そのまま資料に載せました。「入力されていない」を実物で確認するところから始める。ここを飛ばして理想の設計を語っても、同じことが繰り返されるだけです。
期間は最短3ヶ月、長くて半年
よく聞かれるのが期間です。ヒアリングから実際に現場で動き出すまで、最短で3ヶ月、長い場合で半年が実際のところです。
なぜ3ヶ月かかるのか（短縮できない部分）
| フェーズ | やること | 短縮しにくい理由 |
|---|---|---|
| 設計 | as-is整理 → テーブル設計 → to-beの合意 | 関係者の合意形成に時間がかかる。ここを飛ばすと後で作り直しになる |
| 構築 | テーブル・ビュー・自動化・AI連携の実装 | 作るだけなら速い。実データを入れて動かす検証に時間がいる |
| 移行 | 既存データのクレンジングと投入 | 表記ゆれ・重複の整理が一番時間を食う（Excel移行の記事参照） |
| 定着 | 現場が実際に使う状態にする | 説明して終わりではない。使われないCRMになる分かれ目がここ |
最短3ヶ月というのは「作る」期間ではなく、「現場で回り始める」までの期間です。箱を作るだけなら数週間で終わります。ただ、それでは入力されないCRMができあがるだけです。
半年かかるのはどんなケースか
関係者が多い（複数部署が使う）、既存データが汚い（表記ゆれ・重複が大量）、現行業務が属人化している（フローを書き出すところから始まる）——このどれかに当てはまると、設計と移行が伸びます。逆に、部署が限定されていて、データが比較的きれいなら3ヶ月で回ります。
フェーズの切り方（実案件の例）
期間の話とセットで知っておくと役に立つのが、フェーズをどう切るかです。実案件では3つに分けました。
3フェーズの分け方
| フェーズ | スコープ | 位置づけ |
|---|---|---|
| Phase 1 | データ移行／テーブル構築／外部サービス連携／経営ダッシュボード | 箱を作って、現場を回す |
| Phase 2 | 議事録からの自動登録／チャットツールからの登録・編集エージェント | 手入力を消す（PoC） |
| Phase 3 | 追加開発・ブラッシュアップ＋推進担当への伴走 | 月額での継続支援 |
「完成」ではなく「成功」を定義する
実案件では「Phase 2まで実現できたら成功」と定義し、その中身を箇条書きで確定させました。①データ移行が完了している ②想定した連携以外のデータ構造がAirtableで実現し、業務が回る ③必須の外部サービス連携が実現している ④経営が見るダッシュボードがある ⑤議事録からの自動登録が動く——システムは作ろうと思えばいくらでも作り込めます。だからどこまでできたら目的を達したと言えるかを、着手前に文章で合意しておきます。
費用の払い方も、成功の定義と連動させると双方が安全です。実案件では着手費用と成功費用を分け、成功費用は定義を満たした時点で発生する形にしました。発注側は「作っただけで請求される」リスクを避けられ、受注側も何をもって完了とするかで揉めなくなります。契約形態や見積書の読み方は、Airtable開発会社の選び方の「見積書は、金額ではなく『含まれていないもの』を見る」にまとめています。
材料とは別に、発注前に決めておくこと
資料より、こちらの方が重要です
- 1誰が使うのか（部署・人数・役割）— ライセンス費に直結します（権限設計＝コスト設計）
- 2絶対に手作業に戻せない工程はどれか — 優先順位の軸になります
- 3捨てていい業務はあるか — 移行は業務を減らす機会でもあります
- 4社内の承認プロセスと、想定される反対意見 — 稟議・情シス承認の記事が役に立ちます
- 5運用を誰が引き取るのか — 作った後に直せる人を社内に置くかどうか（保守の設計）
資料が無いことより、これらが決まっていないことの方が進行を止めます。
特に「運用を誰が引き取るか」は、設計そのものを変えます
社内に担当者を置くなら、その人が触れる範囲を広く設計します（画面から設定を変えられる、自動化の条件を後から直せる、など）。置かないなら、外部が保守し続ける前提の設計になります。同じ要件でも、作るものが変わる。だから見積もりの前に聞きます。この論点はAIで作った業務ツールは、半年後に誰が直すのかに詳しく書きました。
まとめ
要件定義書は要りません。ER図・業務フローの分解図・to-beのイメージの3つがあると早く、無ければ一緒に作ります。期間は最短3ヶ月、長くて半年。これは作る時間ではなく、現場で回り始めるまでの時間です。進め方と費用の実例はCRM構築サービスのページに公開しています。発注先の選び方についてはAirtable開発会社の選び方もあわせてご覧ください。
他の記事