複数の開発会社から提案書を受け取ったとき、金額の安さだけで選ぶと、契約後に「思っていた進め方と違う」「それは範囲外なので追加費用です」と言われる場面が出てきます。自己資金で立ち上げる個人にとって、提案書は金額表というより、その会社が何をどこまで引き受けるつもりなのかが書かれた、契約前に手に入る数少ない資料です。
結論から言うと、提案書では次の4点を確認します。
- 要望への理解度が、提案内容に反映されているか
- 進め方（開発体制・コミュニケーション方法）が明記されているか
- リスクや制約について、正直に説明されているか
- 作業範囲（SOW）と、発注者である自分が担う作業が書かれているか
4つ目の作業範囲は、非エンジニアの発注者が読み飛ばしやすく、後から追加費用の境界として効いてくる部分です。見積もりを比べる段階の視点は個人が複数の見積もりを比較するとき、価格以外に見るべきポイントで扱っているので、この記事では提案書の文面の読み方に絞ります。
ポイント1：要望への理解度は、提案内容に反映されている？
伝えた要望をそのまま繰り返すだけでなく、背景にある課題・優先順位・使う人まで書かれていれば、理解したうえでの提案と判断できます。
たとえば「売上集計を自動化したい」という要望に対して、「自動集計機能を実装します」とだけ書く提案書と、「どのタイミングで集計するか」「どの画面で確認できるようにするか」まで書く提案書では、要望の受け止め方が違います。
理解度が高い提案書に共通する書き方
- 要望の背景（なぜそれが必要なのか）を、提案者自身の言葉で説明し直している
- 「この課題も一緒に解決したほうがよいのでは」といった、提案側からの追加の視点がある
- 対象ユーザー（誰が、どんな場面で使うのか）が具体的に書かれている
- 要望のうち、優先度が高い部分とそうでない部分を分けて整理している
反対に、要望メールやヒアリングで話した内容を、ほぼそのままの言葉で貼り直しているだけの提案書もあります。文章として整っていても、背景や目的への言及がなければ、理解度を判断する材料にはなりません。
具体例で見る「理解度の差」
以下は、同じ要望に2社から提案が来た場合を題材にした比較例です。実在の会社の提案書ではありません。自分が受け取った提案書に置き換えて読んでみてください。
A社の提案書：「予約管理システムを構築します。予約の登録・変更・削除ができる管理画面を用意します。」
B社の提案書：「現在、電話とLINEで予約を受けており、ダブルブッキングが月に数件発生しているとのことでした。まずは予約の一元管理を優先し、次のフェーズで自動リマインド機能を追加するご提案です。管理画面はスタッフの方が操作されることを想定し、スマートフォンでも操作しやすいレイアウトにします。」
A社の提案は機能の列挙にとどまり、B社の提案は課題（ダブルブッキング）・優先順位（まず一元管理、次にリマインド）・利用者（スタッフ、スマートフォン操作）まで書かれています。金額はA社のほうが安いこともありますが、B社のように前提が文章になっている提案書は、契約後に認識の食い違いが起きたとき、何を合意していたかを確かめる手がかりになります。
ポイント2：進め方（体制・連絡方法）は明記されている？
担当者の人数と役割、進捗報告の頻度、連絡手段、自分が確認・承認するタイミングの4つが書かれているかを確認します。
書かれていない場合は、契約前に直接質問します。非エンジニアが発注者になる場合は、専門用語を使わずに説明してくれる担当者がいるかどうかも、この段階で確かめられます。
確認しておきたい体制の項目
- 担当者は何人で、それぞれどんな役割を担うのか（営業担当と実際に開発する担当者が別なのか、同じなのか）
- 進捗報告はどのくらいの頻度で、どういう形式で行われるのか（週次のミーティングか、チャットでの報告のみか）
- 質問や相談をしたいとき、どの連絡手段を使えるのか（メール、チャット、電話など）
- 発注者側が確認・承認すべきタイミングはどこにあるのか（デザイン確定時、テスト開始時など）
- 開発期間中、担当者が変わる可能性はあるか
これらに一切触れていない提案書が、必ずしも悪い会社のものとは限りません。ただ、「契約後に聞けば教えてくれるはず」と後回しにせず、契約前に質問して回答を残しておくと、判断の材料がそろいます。
体制が不明確なまま契約して起きる失敗パターン
体制の説明が曖昧なまま契約した場合に起きやすいのは、次のようなケースです。
- 契約時に対応してくれた担当者と、実際に開発する担当者が別人で、要望の背景が引き継がれていなかった
- 「進捗はまとめてご連絡します」とだけ書かれていて、1ヶ月以上連絡がなく、進んでいるのか分からない期間が続いた
- 質問をメールで送っても数日返信がなく、スケジュールがずれ込んだ
- 途中で担当者が退職・異動し、それまでのやり取りの経緯が引き継がれていなかった
提案書の段階で「体制」と「連絡方法・頻度」を質問し、回答をメールなど文書で残しておくと、こうした事態の多くは契約前に芽を摘めます。開発期間が数ヶ月に及ぶ場合は、担当者の異動・退職時の引き継ぎ方も一言確認しておきます。
体制面のチェックは、会社そのものの見極めにも通じます。どんな会社に頼むべきかという観点からは、開発会社を見極める7項目も参考になります。
ポイント3：リスクや制約は、正直に説明されている？
実現が難しいこと、注意すべき制約、追加費用が発生しうる条件まで書かれている提案書は、何を引き受けないかも明らかにしています。
「何でもできます」という提案より、「この機能はこういう制約があるため、この形で実現するのが現実的です」という提案のほうが、契約後に何が起きるかを見通せます。
「何でもできます」型の提案書に潜むリスク
要望に対して一切の懸念を示さず、すべて「対応可能です」とだけ回答する提案書には、次のような背景が隠れていることがあります。
- 要望の技術的な難易度を、深く検討せずに提案している
- 受注を優先し、後で追加費用や期間延長を持ち出すつもりでいる
- 実現方法について、まだ具体的な検討ができていない
本当に難易度が高くない要望なら、制約が特にないという説明も自然です。ただし、複数の要望のすべてに同じ「問題ありません」しか返ってこない場合は、具体的にどう実現するのかを質問してください。
リスク説明の「言い換え」に注意する
リスクを柔らかい言葉で言い換えているだけのケースもあります。たとえば「柔軟に対応可能です」が、実際には「詳細は決まっていないので、追加費用が発生するかもしれません」という意味で使われていることがあります。気になる表現には「具体的にはどういう場合に追加費用が発生しますか」と質問し、想定されるケースを具体的に答えられるかどうかを判断材料にします。
ポイント4：作業範囲（SOW）と、自分が担う作業は書かれている？
「何を作り、何を作らないか」「発注者は何をいつまでに用意するか」が文章になっていれば、追加費用の境界を契約前に確かめられます。
開発会社が実施する作業の範囲・成果物・スケジュールなどを明文化した文書を、SOW（作業範囲記述書）と呼びます。個人の小さな発注では、SOWという名前の独立した文書は出てこないことが多く、提案書や見積書の「作業範囲」「前提条件」「対象外」といった欄に書かれています。名前は違っても、次の項目がどこかに書かれているかを探してください。
- 作業内容と成果物：画面・機能の一覧、納品されるもの（公開された状態のサービス、ソースコード、操作説明書など）
- 対象外（やらないこと）：デザイン制作、文章の作成、公開後の保守、既存データの移し替えなど、見積もりに含まれない作業
- 前提条件：対応する端末やブラウザ、想定する利用者数、使う外部サービス
- 発注者が担う作業：写真や文章などの素材提供、確認・承認の期限、テスト用データの準備
- 完成の判断方法：何をどう確認すれば完成とみなすか（検収の方法）
特に見落としやすいのが、発注者側の作業です。情報処理推進機構（IPA）が「情報システム・モデル取引・契約書」第二版とあわせて2020年12月に公表した資料「第二版の公表にあたって」では、システム開発をめぐる裁判例でユーザ（発注者）の協力義務がたびたび問題になっていることに触れたうえで、ユーザもプロジェクトマネジメントを行う必要があり、双方が各段階で果たす役割を踏まえることが重要だと整理しています。素材の提出が遅れた、確認に時間がかかった、という発注者側の事情でも、スケジュールや費用は動きます。自分が何をいつまでに出すのかが提案書に書かれていなければ、契約前に確認して書き足してもらいます。
作業範囲が曖昧なまま始めると、「これもお願いできますか」が積み重なり、どこからが追加費用かで揉めるスコープクリープにつながります。範囲の外の依頼が出たときの扱い方は「これも追加でお願い」が積み重なる前に、決めておくべきことで整理しています。
提案書の分かりやすさと、質問への対応も判断材料になる？
専門用語を噛み砕いて説明できるか、質問に早く的確に答えるかは、契約後のやり取りの質を見積もる手がかりになります。
提案書が専門用語ばかりで読みにくい場合、開発会社側が非エンジニアへの説明を意識していない可能性があります。分からない用語は遠慮せずに質問し、噛み砕いて説明し直してくれるか、専門用語のまま返してくるかも見ておきます。
提案書を受け取ったら、いくつか質問を送ってみます。見るのは次の点です。
- 回答が、事前に決めていたであろう営業日数（1〜2営業日程度）以内に届くか
- 質問の意図を理解したうえで答えているか（的外れな回答や、はぐらかす回答がないか）
- 「分からない部分は確認して回答します」と、正直に持ち帰れるか
- 追加の質問にも、最初と同じ丁寧さで対応するか
契約前は、どの会社も比較的丁寧に対応します。契約前の対応の質を、契約後の対応を見積もる上限の目安として扱うと、判断がぶれにくくなります。
複数の提案書は、どう並べて比べる？
金額の欄ではなく、下のチェック項目ごとに横並びで比べ、チェックが付かない項目は質問して埋めてから判断します。
金額が高い提案書のほうが、リスクの説明や作業範囲の記載が具体的だった、ということもあります。個人が複数の見積もりを比較する際の視点は個人が複数の見積もりを比較するとき、価格以外に見るべきポイント、比較の前提をそろえる頼み方は相見積もりの条件をそろえる、個人開発者のための伝え方で扱っています。
比較のためのチェックリスト
- [ ] 要望の背景・目的への言及があるか
- [ ] 対象ユーザーや利用シーンが具体的に書かれているか
- [ ] 開発体制（担当者の人数・役割）が明記されているか
- [ ] 進捗報告の頻度・方法が明記されているか
- [ ] 質問への回答の速さ・丁寧さに問題がないか
- [ ] 実現が難しい部分・制約について、正直に説明されているか
- [ ] 作業範囲と「対象外（やらないこと）」が書かれているか
- [ ] 発注者側が用意するもの・確認の期限が書かれているか
- [ ] 見積金額の内訳（何にいくらかかっているか）が分かるか
- [ ] 専門用語を使わず、図や具体例で説明されているか
- [ ] スケジュール（いつまでに何ができるか）が明記されているか
- [ ] 保守・運用フェーズについても触れられているか
金額の欄しか具体的でない提案書は、チェックが付かなかった項目をまとめて質問し、回答がそろってから比較に戻します。
専門知識を活かしたツールや、店舗向けツールで追加で見る点は？
専門職のツールなら業務ルールの理解を、店舗のツールなら実際に使う場面の想定を、提案書の中で確認します。
士業や専門職の知識を活かしたツールでは、業務上のルールや計算方法が複雑になります。提案書の中で「このルールについては、こう理解しています」と開発会社が自分の言葉で説明し直していれば、要件を理解している手がかりになります。専門用語をそのまま転記しているだけなら、実装の段階で誤解が生じないよう、契約前に具体的な確認を重ねます。
店舗の業務改善ツールでは、実際に使うのが店舗スタッフで、発注者自身ではないことも多くあります。「レジ業務の合間に使う」「閉店後にまとめて確認する」のように、誰が・どんなタイミングで・どんな端末で操作するかまで触れているかを確認します。パソコン操作に慣れていないスタッフが多い店舗なら、操作のシンプルさへの配慮が提案に含まれているかも見ておきます。
提案書の見極めで、よくある失敗は？
金額だけでの即決、回答の鵜呑み、体裁への安心、口頭合意の放置の4つです。
パターン1：金額の安さだけで即決してしまう
比較の時間を惜しんで最も安い提案書で契約し、安さの理由が「必要な工程を省いている」だけだった場合、後から追加費用が発生して、結果的に他の提案書より高くなることがあります。
パターン2：質問への回答を鵜呑みにしてしまう
「その機能は簡単にできます」という回答を、実現方法を確認せずに信じてしまうケースです。契約後に想定より複雑な実装が必要と分かり、スケジュールが遅れることがあります。
パターン3：提案書の体裁の良さに惑わされる
デザインが整った提案書に安心し、内容（理解度・体制・リスク説明・作業範囲）の薄さに気づかないケースです。見た目の完成度と、開発力・対応力は必ずしも一致しません。
パターン4：口頭で聞いた内容を文書に残さない
打ち合わせで補足説明を受けたのに、提案書やメールに残っていないケースです。後から「そんな話だったか」という水掛け論になりやすいため、合意した内容は文書にしてもらいます。
非エンジニアが提案書を読むときは、「専門用語が多い＝技術力が高い」「ページ数が多い＝丁寧」「知り合いの紹介だから大丈夫」と受け取ってしまう癖にも注意が必要です。「今月中に契約いただければ割引します」のように契約を急がせる言葉があるときは、内容の確認を後回しにしないよう、一度持ち帰ってください。
サービスの形態によって、提案書で見る点は変わる？
予約・申込、定期更新、決済のどれを含むかで、提案書に書かれているべき運用の中身が変わります。
- 予約・申込を受け付けるサービス：キャンセル対応や重複予約の防止など、運用のルールが提案に反映されているか。「フォームを作るだけ」で終わっていないか
- 自分で記事や情報を更新するサービス：画像のアップロード方法、公開・非公開の切り替えなど、管理画面の操作性が具体的に説明されているか
- 決済を含むサービス：決済代行サービスとの連携方法、決済失敗時の表示、キャンセル・返金の処理まで含まれているか。「決済機能を実装します」の一文だけなら、契約前に質問する
提案書のフォーマットによって、読み方は変わる？
スライド形式は機能と体制の具体性を、文書形式は前提条件と別紙の有無を、箇条書き形式は4つのポイントが押さえられているかを見ます。
スライド形式（企画書寄り）の提案書
デザイン会社やWeb制作会社から提出されることが多い形式です。ビジュアルが整っている分、内容が薄くても立派に見えることがあります。
- デザインのイメージ図と、実際の機能要件が対応しているか
- ページ数に対して、機能一覧・体制・スケジュールといった具体的な回答が含まれているか
- 「今後のビジョン」など抽象的な内容にページを割きすぎていないか
文書形式（見積書に近い）の提案書
システム開発会社やSES（システムエンジニアリングサービス）系の会社から提出されることが多い形式です。機能要件や工数の記載は詳細な一方、非エンジニアには読みにくいことがあります。
- 機能ごとの説明に、専門用語の注釈や図解が添えられているか
- 前提条件（「〇〇という環境を前提とします」等）が、発注者にも理解できる言葉で書かれているか
- 別紙・別添で詳細を示すとされている場合、その別紙が実際に添付されているか
簡易的な一覧・箇条書きだけの提案書
小規模な開発会社やフリーランスの開発者から提出されることが多い形式です。情報量が少なくても、要点が押さえられていれば問題ありません。少ない情報量の中に、理解度・体制・リスクの説明・作業範囲の4点が入っているかで判断します。
提案書に書かれていないことは、何を確認する？
保守・権利・サーバーの管理・継続できなくなった場合・個人情報の5つは、提案書に記載がなくても契約前に確認します。
- 公開後の保守・運用（不具合対応、機能追加の依頼方法、その際の費用）
- 開発したソースコードやデザインデータの権利が、契約後どちらに帰属するか
- サービス公開後、サーバーやドメインの管理を誰が行い、費用を誰が負担するか
- 開発会社側の事情（人員異動、廃業など）で開発が継続できなくなった場合の取り決め
- 個人情報を扱うサービスの場合、プライバシーポリシーの整備やセキュリティ対策
これらは開発中ではなく、公開後・運用開始後に問題として表面化することが多い項目です。
契約の前に、やっておくことは？
疑問点をまとめて質問し、合意を文書に残し、提案書と契約書・見積書の記載を突き合わせます。
- 疑問点をリストにして、まとめて質問する：回答の抜け漏れが減り、その会社が複数の質問をどれだけ整理して返せるかも分かります
- 認識合わせの議事録・メールを残してもらう：「言った・言わない」を避けるだけでなく、後から契約書や仕様書を作る際の土台になります
- 提案書と、契約書・見積書の内容が一致しているか確認する：提案書で示された体制・スケジュール・作業範囲が、契約書や見積書から抜けていないかを、押印前に確認します。契約書で見るべき条項は契約書で必ず確認したい条項（知的財産権・検収・保守）で解説しています
まとめ：提案書は「何を引き受けるか」が書かれた資料として読む
提案書は、金額の欄だけでなく、要望への理解度・進め方・リスクの説明・作業範囲の4点で読みます。特に作業範囲と、発注者である自分が担う作業は、契約後の追加費用やスケジュールの遅れに直結するのに、書かれていないことが多い項目です。
手元に提案書があるなら、まずチェックリストの12項目に印を付け、付かなかった項目を質問リストにして送ってみてください。その回答まで含めて比べると、金額だけでは見えなかった違いが分かります。
