対象読者: 自社で初めて業務システム・Webサービス・社内ツールの開発を外注しようとしている経営者・担当者
この記事で分かること: 発注前に社内で固めておくべき 10 項目と、決まっていないまま動き出すと何が起きるか
はじめに — 「とりあえず見積もり」が一番危ない
「うちもそろそろシステム化を考えていて、見積もりだけでも出してもらえますか？」
制作会社の現場で、最も多く、最もつらい依頼パターンです。
つらい理由は単純で、何が決まっていて何が決まっていないかが決まっていないから。 発注側が「ふわっとした要望」しか持っていない状態で見積もりを取ると、
- 見積もりが極端に高くなる（リスクを上乗せするしかない）
- 受注後に「思っていたのと違う」が連発する
- 開発の途中で何度も方針が変わり、結局コストも期間も倍以上に膨らむ
という事故になりがちです。これは制作会社が悪いのではなく、発注前の準備で 8 割が決まる仕事だからです。
逆に言えば、これから紹介する 10 項目を社内である程度決めてから問い合わせするだけで、見積もり精度・スピード・最終的な満足度がまったく変わります。
1. 目的（なぜ作るのか）
最重要項目です。「何を作るか」より先に「なぜ作るか」を一文で言えるかを確認してください。
良い例:
- 「現在Excelで管理している案件情報を、全社員がリアルタイムで共有できるようにしたい」
- 「問い合わせ対応の取りこぼしを月20件→0件に減らしたい」
- 「請求書発行の作業時間を月40時間→5時間に短縮したい」
悪い例:
- 「DXしたい」
- 「業務を効率化したい」
- 「他社もやっているから」
ポイント: 数字で測れる目的になっているか。測れないと完成しても効果が分からず、追加投資の判断もできません。
2. 解決したい具体的な課題（現状の困りごと）
目的の手前にある「現場の困りごと」を箇条書きで5〜10個。
- どの作業に時間がかかっているか
- どこでミスが発生しているか
- 誰がストレスを感じているか
- 紙・FAX・口頭でやり取りしている部分はどこか
これがあると、開発側は「最低限ここは絶対に解決すべき」という優先順位をつけて提案できます。
3. 予算（上限と幅）
「予算は決まっていません、提案してください」は危険な丸投げです。 最低限、上限と希望幅は決めておきます。
規模感 | 目安 |
簡易ツール・既存サービス組み合わせ | 〜30万円 |
業務改善ツール・小規模Web | 50〜200万円 |
業務システム・受注管理等 | 200〜800万円 |
SaaS的なプロダクト・複雑な業務 | 800万円〜 |
「100万でやりたいけど、効果次第で200万まで」のように幅を伝えるだけで、提案の解像度が大きく変わります。
4. 期限（必須と希望）
「いつまでに必要か」と「なぜその時期か」をセットで。
- 「決算前の3月末までに導入したい」
- 「新店舗オープンの6/1までに会員管理機能だけ動いていればよい」
- 「特に期限はないが、夏までに方向性を決めたい」
Must（絶対に間に合わせる必要がある期限） と Want（できればこの時期） を分けるとなお良いです。
5. 責任者と意思決定フロー
「最後にYes/Noを言える人は誰か」を明確に。 これが曖昧だと、開発の各フェーズで判断が滞り、確実に納期が遅れます。
- 社長か、現場責任者か
- 稟議が必要な金額のラインはいくらか
- 仕様変更を判断できる人は誰か
- 制作会社からの定例打ち合わせには誰が出るか
担当者と決裁者が違う場合、最初の打ち合わせに決裁者も同席してもらうのが理想です。
6. 利用者（誰が使うか）
これも忘れがち。
- 社内の誰が使うのか（部署・人数・PCスキル）
- 取引先や顧客も使うのか
- スマホ・タブレット利用はあるか
- 高齢の方や PC が苦手な方も含まれるか
利用者像が違うとUI設計の方針も変わります。「現場のパートさんが片手間で入力する」と「事務職員が腰を据えて使う」では作るものが別物です。
7. 既存システム・データとの連携
完全新規ではない場合、ほぼ必ず聞かれます。
- 現在使っている会計ソフト・販売管理ソフト・スプレッドシート等の名前
- それらとデータをやり取りしたいか（自動 or CSV エクスポート程度でよいか）
- 移行が必要な既存データの量と形式
- API があるサービスかどうか
連携先が判明しているだけで、見積もり時の不確実性が大きく下がります。
8. 運用・保守の体制
ここが一番、後で揉めます。
- 納品後、誰が日常的に運用するか
- バグ・障害が起きたときの連絡窓口は誰か
- 保守契約は結ぶか（月額いくらまでなら出せるか）
- サーバー・ドメイン・ライセンス費用を誰が支払うか
- 機能追加が発生した場合の予算枠
「作って終わり」ではなく「作ってからが本番」です。最初に決めておかないと、納品後のトラブル対応で関係が悪化します。
9. データ・セキュリティ要件
該当する項目だけで構いません。
- 個人情報を扱うか（顧客名・住所・電話番号・メール等）
- クレジットカード情報を扱うか（PCI DSS 対応の要否）
- 業界固有の規制があるか（医療・金融・教育等）
- 社内ネットワークからのみアクセスさせたいか
- バックアップの頻度・保管期間の希望
- 退職者のアカウント管理ルール
特に個人情報を扱う場合、漏えい時の責任分界点は契約書に明記すべきです。
10. 検収条件と支払い条件
「いつ・どうなったら完成とみなして、いつ支払うか」を最初に決めておきます。
- 着手金の有無（業界相場は30〜50%）
- 中間支払いの有無
- 検収期間（納品後何日以内にチェックするか、通常2週間〜1ヶ月）
- 検収項目（何ができれば合格か）
- 瑕疵担保期間（納品後どこまで無償修正に応じるか、通常3ヶ月〜1年）
検収条件が曖昧だと「いつまで経っても完成にならない」「払ってもらえない」のお互いに不幸な状態になります。
チェックリスト（コピペして社内会議でどうぞ）
□ 1. 目的（一文で言える / 数字で測れる）
□ 2. 解決したい具体的課題（5〜10個リストアップ済み）
□ 3. 予算（上限と希望幅を提示できる）
□ 4. 期限（MustとWantを分けて伝えられる）
□ 5. 責任者と意思決定フロー（決裁者の名前が出る）
□ 6. 利用者像（部署・人数・スキル感）
□ 7. 既存システム・データ連携の要件
□ 8. 運用・保守体制（誰が・いくらまで・どう連絡するか）
□ 9. データ・セキュリティ要件
□10. 検収条件と支払い条件
10 項目すべて埋まらなくても構いません。「ここはまだ決まっていません」と素直に伝えるのが正解です。提案を受ける中で一緒に詰めていけます。
nanogram からのお願い
当社では、初回のヒアリングで上記10項目を一緒に整理する無料相談をやっています。 「ふわっとしたまま見積もりだけ取りに行って、何社からも変な金額が出てきて困っている」というご相談も多く、その場合は他社見積もりの読み解き支援もしています。
「とりあえず話を聞いてもらいたい」という段階で大歓迎です。 お問い合わせフォームから、できれば現状の困りごとを2〜3行書いて送ってください。それだけで初回打ち合わせの密度がぐっと上がります。
まとめ
- 発注前の準備で、開発の成否は8割決まる
- 「目的」「予算」「責任者」の3つだけでも先に固めると、見積もり精度が劇的に変わる
- 全部決めなくてよい。ただし何が未決かは把握しておく
- 「作って終わり」ではなく「運用設計まで含めて発注」が成功の鍵
発注は、業者選びより自社の準備で決まります。この10項目を持って、まずは2〜3社に当ててみてください。同じ要件で見積もりを取れば、各社の提案の差が初めて見えてきます。