提案書の書き方｜システム開発の構成・目次テンプレートと例

システム開発の提案書は、相手の課題→原因→解決策→効果→費用と期間→体制の順に並べ、最初の1枚で課題と効果を言い切る文書です。 読む人が知りたいのは「自分たちの困りごとをわかっているか」「それがどれだけ良くなるか」「いくらで、いつ、誰がやるのか」の3つで、この順番はその問いにそのまま答える並びになっています。

この記事では、受注する側が書く提案書を扱います。10章の目次テンプレートをMarkdownで全文載せ、各章に架空の「備品管理システム刷新」の記入例を付けました。発注する側が書く提案依頼書（RFP）の書き方は対象外で、RFPを受け取ったあとにどう返すかに絞っています。

確認環境（確認日 2026-10-05）：記入例の費用・効果・回収年数と、適合表の件数は Python 3.11 で検算しました。金額・時間・件数はすべて架空の例で、相場を示すものではありません。

この記事の結論

• 並べる順番は、課題→原因→解決策→効果→費用と期間→体制。自社の紹介は最後に回す
• 最初の1枚（要旨）で「課題・解決策・効果・費用・期間」を数字つきで言い切る。ここだけ読んでも判断できるようにする
• 課題・原因・解決策・効果・測り方は1行に並べて対応させる。解決策だけが浮いた提案を防げる
• RFPへの回答なら、要求事項ごとに対応の可否と記載ページを書いた適合表を付ける
• RFPが無い自主的な提案なら、課題の裏付けと「何もしない場合」との比較を厚くする

提案書の構成 早見表（10章）

なぜこの順番なのか

提案書を読む人は、1人ではありません。決裁する人は要旨と費用を、利用部門は課題と解決策を、情報システムの担当者は構成・スケジュール・適合表を読みます。前から順に読むほど詳しくなる並びにしておくと、誰がどこで読み終えても必要な答えを持ち帰れます。

会社の紹介や過去の事例を最初に置く構成もよく見かけますが、読む人の最初の問いは「自分たちの課題」です。紹介は8章の体制か別紙に置き、1章は相手の話から始めます。

目次テンプレート（Markdown）

そのまま貼って使える10章のひな形です。かっこの中は書く内容の説明なので、書き終えたら消します。

# 【システム名】ご提案書

提出日：YYYY-MM-DD　／　提出先：【会社名・部署名】御中　／　提出者：【会社名・担当者名】
版：v1.0　／　有効期限：YYYY-MM-DD

## 1. 提案の要旨
（1ページ。次の5点を数字つきで書く）
- 課題：
- 解決策：
- 効果：
- 費用：初期 ◯◯万円／運用 年 ◯◯万円
- 期間：YYYY-MM 着手、YYYY-MM 稼働

## 2. 現状と課題の理解
### 2.1 現状の業務の流れ
（聞き取りやRFPから読み取った現状を、図か箇条書きで）
### 2.2 課題
（課題を3〜5個。それぞれに現状の数字を添える）
### 2.3 確認させていただきたい点
（読み取れなかった点、前提として置いた点）

## 3. 課題の原因
（課題ごとに原因を1つずつ。課題・原因・解決策・効果・測り方の対応表を置く）

## 4. 解決策
### 4.1 全体像
（利用者・画面・データの関係を1枚の図で）
### 4.2 機能の概要
（課題の番号と対応づけて）
### 4.3 対象範囲と対象外
### 4.4 システムの構成
### 4.5 現行からの移行

## 5. 効果と測り方
### 5.1 効果の一覧
（課題ごとに、現状の値・目標の値・測り方・測る時期）
### 5.2 費用との比較
（年間の効果、運用費、回収にかかる年数と計算の前提）

## 6. 費用
### 6.1 初期費用の内訳
### 6.2 運用費用（年額）
### 6.3 前提条件と、費用に含まないもの
### 6.4 支払いの時期

## 7. スケジュール
（工程ごとの期間と、相手側の作業が入る時期。主な節目の日付）

## 8. 体制
### 8.1 当社の体制
（役割・人数・関わる割合）
### 8.2 お客様にお願いしたい体制
### 8.3 会議と報告

## 9. 進め方とリスクへの備え
### 9.1 進め方
（工程の区切りと承認の方法、変更が出たときの扱い）
### 9.2 想定するリスクと備え
（起こりうること・起きる条件・備え・起きたときの対応）

## 10. 要求への適合表・別紙
### 10.1 要求事項への適合表
### 10.2 別紙一覧
（会社概要、担当者の経歴、画面の例など）

記入例：備品管理システム刷新（架空）

題材は、社員600名・備品約4,200点の会社が、表計算ソフトの台帳とメールでの貸出申請を新しいシステムに置き換える、という架空の設定です。

1章 提案の要旨

要旨は、ほかの章を書き終えてから最後に書きます。 2〜9章の結論を1行ずつ抜き出すと、本文と数字が食い違いません。

## 1. 提案の要旨
- 課題：備品台帳と現物の不一致が 4,200点中 310点（7.4%）あり、棚卸しに1回あたり延べ240時間かかっています。
- 解決策：貸出・返却・棚卸しを QRコードの読み取りで記録する備品管理システムを構築します。
- 効果：不一致を1.0%以下に、棚卸しを1回80時間に、申請から承認までを2.5営業日から0.5営業日に短縮します。
  作業時間の削減は年900時間、重複購入の削減と合わせて年450万円相当を見込みます。
- 費用：初期 980万円／運用 年120万円（回収の目安は稼働から約3年）
- 期間：2027年1月着手、2027年6月1日稼働（約5か月）

直したい例は、どの会社あての提案書にもそのまま貼れてしまいます。相手の数字が入っているかどうかが、要旨の良し悪しを分けます。

2章 現状と課題の理解

## 2. 現状と課題の理解
### 2.1 現状の業務の流れ
1. 社員が総務あてにメールで貸出を申請する
2. 総務が上長に承認を依頼し、承認後に台帳（表計算ソフト）へ入力する
3. 社員が備品を受け取り、返却時に総務が台帳を更新する
4. 半期に1回、総務が紙の一覧を持って全フロアを回り、現物と照合する

### 2.2 課題
| No. | 課題 | 現状の値 |
|---|---|---|
| P1 | 台帳と現物が合わない | 前回の棚卸しで 4,200点中 310点（7.4%）が不一致 |
| P2 | 棚卸しに時間がかかる | 1回あたり延べ240時間（年2回） |
| P3 | 申請から承認までが長い | 平均2.5営業日 |
| P4 | 返却が期限を過ぎる | 月平均35件 |
| P5 | 所在の問い合わせが多い | 総務あてに月120件 |

### 2.3 確認させていただきたい点
- 備品の点数は RFP の記載（約4,200点）を前提にしています。増減の見込みがあればお知らせください。
- P3〜P5 の数字は、9月12日の聞き取りで伺った概数です。

課題には、必ず現状の数字を添えます。数字が手に入らないときは「聞き取りで伺った概数」「RFPの記載」など出どころを書いておくと、読む人が確かめられます。

3章 課題の原因（課題・原因・解決策・効果・測り方の対応表）

提案書の背骨になる表です。 課題1つにつき1行で、原因・解決策・効果・測り方を横に並べます。行のどこかが空いたら、その解決策は課題に結びついていないか、効果を確かめる手段がないということです。

表計算ソフトに貼れるタブ区切りです。

No. 課題（現状の値）    原因  解決策 効果（目標の値）    測り方
P1  台帳と現物の不一致が310点（7.4%）    貸出と返却の記録が手入力で、後回しになる    QRコードの読み取りで貸出・返却をその場で記録 不一致を42点（1.0%）以下に    半期の棚卸しで、不一致の点数÷総点数
P2  棚卸しに1回240時間 紙の一覧と目視で1点ずつ照合している  スマートフォンで読み取り、台帳と自動で照合   1回80時間に 棚卸しの作業時間の記録
P3  申請から承認まで平均2.5営業日    メールでの依頼で、承認者が不在だと止まる    申請の画面と承認の流れを用意し、代理承認を設定 平均0.5営業日に   システムに残る申請時刻と承認時刻の差
P4  返却の期限超過が月35件    期限を知らせる仕組みがない   期限の前日と当日に自動で通知  月10件以下に 期限超過の件数を月ごとに集計
P5  所在の問い合わせが月120件  台帳を見られるのが総務だけ   全社員が所在と利用者を検索できる画面  月30件以下に 総務の問い合わせ記録の件数

原因は「人が気を付けていないから」ではなく、仕組みの側に求めます。「手入力で後回しになる」という原因なら「その場で記録できる手段」という解決策が自然に出てきます。

4章 解決策

## 4. 解決策
### 4.1 全体像
社員はスマートフォンかパソコンのブラウザで申請し、上長が承認します。
総務は貸出・返却のときに備品の QRコードを読み取ります。台帳はシステムが自動で更新します。

### 4.2 機能の概要
| 機能 | 内容 | 対応する課題 |
|---|---|---|
| 備品の検索 | 名前・分類・設置場所で検索し、所在と利用者を表示 | P5 |
| 貸出の申請と承認 | 申請、上長の承認、代理承認、状況の確認 | P3 |
| 貸出・返却の記録 | QRコードを読み取って記録 | P1 |
| 期限の通知 | 期限の前日と当日にメールで通知 | P4 |
| 棚卸し | 読み取った結果と台帳を照合し、差分を一覧で表示 | P1、P2 |
| 台帳の管理 | 備品の登録・変更・廃棄、QRラベルの印刷 | P1 |

### 4.3 対象範囲と対象外
- 対象：本社と2つの支社の備品約4,200点、社員600名
- 対象外：消耗品の在庫管理、購入の申請（次の段階としてご提案できます）

### 4.4 システムの構成
クラウド上にWebアプリケーションとデータベースを置きます。社員の認証は、既存の社内アカウントと連携します。

### 4.5 現行からの移行
現行の台帳（表計算ソフト）を取り込み、稼働前の棚卸しで現物と合わせます。
QRラベルの貼り付けは、総務のみなさまと当社で分担します（8.2 参照）。

機能の表には「対応する課題」の列を付けます。課題の番号が付かない機能は、提案に入れる理由をもう一度確かめます。 逆に、3章の課題のうち機能が1つも対応していないものが無いかも、この列で確かめられます。

対象外を書くことも解決策の一部です。書いていない範囲は、読む人によって「含まれている」とも「含まれていない」とも受け取れます。

5章 効果と測り方

## 5. 効果と測り方
### 5.1 効果の一覧
| 課題 | 現状 | 目標 | 測る時期 |
|---|---|---|---|
| P1 台帳の不一致 | 7.4% | 1.0%以下 | 稼働後、最初の棚卸し |
| P2 棚卸しの時間 | 1回240時間 | 1回80時間 | 稼働後、最初の棚卸し |
| P3 承認までの日数 | 2.5営業日 | 0.5営業日 | 稼働の3か月後 |
| P4 期限超過 | 月35件 | 月10件以下 | 稼働の3か月後 |
| P5 問い合わせ | 月120件 | 月30件以下 | 稼働の3か月後 |

### 5.2 費用との比較
- 削減できる作業時間：年900時間（棚卸し320、問い合わせ対応180、申請の処理400）
- 金額に直した効果：年450万円（作業時間 270万円＋重複購入の削減 180万円）
- 運用費を引いた効果：年330万円　→　初期費用980万円の回収の目安は約3.0年
- 前提：作業1時間を3,000円、問い合わせ1件を10分、申請の処理を1件15分から5分として計算

5.2の数字は、次のコードで検算しました。前提の値を変えれば、自分の提案の数字に置き換えられます。

# 提案書の数字の検算（金額・時間はすべて架空の例）
steps = [("要件定義", 1.5), ("基本設計", 2.0), ("詳細設計・開発", 4.5),
         ("試験", 2.0), ("移行・利用者教育", 1.0), ("進行管理", 1.0)]
unit = 80            # 1人月あたりの金額（万円）
goods = 20           # QRラベル・読み取り端末など（万円）
run = 120            # 年間の運用費（万円）

mm = sum(m for _, m in steps)
print("工程別の費用")
for name, m in steps:
    print(f"  {name:<10} {m:>4.1f} 人月  {m * unit:>6.0f} 万円")
initial = mm * unit + goods
print(f"  合計 {mm:.1f} 人月 × {unit} 万円 + 物品 {goods} 万円 = {initial:.0f} 万円")

hour_rate = 3000     # 作業1時間あたりの金額（円）
saved = {
    "棚卸し": (240 - 80) * 2,                 # 1回240h→80h、年2回
    "問い合わせ対応": (120 - 30) * 10 / 60 * 12,   # 月120件→30件、1件10分
    "申請の処理": 200 * (15 - 5) / 60 * 12,       # 月200件、1件15分→5分
}
print("削減できる時間（年）")
for k, v in saved.items():
    print(f"  {k:<8} {v:>5.0f} 時間")
hours = sum(saved.values())
time_yen = hours * hour_rate / 10000
rebuy = 180          # 重複購入・再購入の削減（万円/年）
benefit = time_yen + rebuy
print(f"  合計 {hours:.0f} 時間 × {hour_rate} 円 = {time_yen:.0f} 万円")
print(f"年間の効果 {time_yen:.0f} + {rebuy} = {benefit:.0f} 万円")
net = benefit - run
print(f"運用費を引いた年間の効果 {benefit:.0f} - {run} = {net:.0f} 万円")
print(f"回収にかかる年数 {initial:.0f} / {net:.0f} = {initial / net:.1f} 年")
print(f"5年間の合計 効果 {benefit * 5:.0f} 万円 / 費用 {initial + run * 5:.0f} 万円")
print(f"台帳の不一致 {310 / 4200:.1%} → 目標 {42 / 4200:.1%}")

工程別の費用
  要件定義        1.5 人月     120 万円
  基本設計        2.0 人月     160 万円
  詳細設計・開発     4.5 人月     360 万円
  試験          2.0 人月     160 万円
  移行・利用者教育    1.0 人月      80 万円
  進行管理        1.0 人月      80 万円
  合計 12.0 人月 × 80 万円 + 物品 20 万円 = 980 万円
削減できる時間（年）
  棚卸し        320 時間
  問い合わせ対応    180 時間
  申請の処理      400 時間
  合計 900 時間 × 3000 円 = 270 万円
年間の効果 270 + 180 = 450 万円
運用費を引いた年間の効果 450 - 120 = 330 万円
回収にかかる年数 980 / 330 = 3.0 年
5年間の合計 効果 2250 万円 / 費用 1580 万円
台帳の不一致 7.4% → 目標 1.0%

効果の金額には、計算の前提を必ず並べて書きます。 「年450万円」だけでは確かめようがありませんが、「1時間3,000円×900時間＋重複購入の削減180万円」と書いてあれば、相手が自分の数字に置き換えて計算し直せます。

6章 費用

## 6. 費用
### 6.1 初期費用の内訳
| 項目 | 工数 | 金額 |
|---|---|---|
| 要件定義 | 1.5人月 | 120万円 |
| 基本設計 | 2.0人月 | 160万円 |
| 詳細設計・開発 | 4.5人月 | 360万円 |
| 試験 | 2.0人月 | 160万円 |
| 移行・利用者教育 | 1.0人月 | 80万円 |
| 進行管理 | 1.0人月 | 80万円 |
| QRラベル・読み取り用の機器 | ― | 20万円 |
| 合計 | 12.0人月 | 980万円 |

### 6.2 運用費用（年額）
120万円（クラウドの利用料、問い合わせの対応、軽微な修正を含む）

### 6.3 前提条件と、費用に含まないもの
- 備品の点数が5,000点を超える場合は、移行の費用を見直します。
- QRラベルの貼り付け作業のうち、お客様に分担いただく分は含みません。
- 消費税は含みません。

### 6.4 支払いの時期
契約時・基本設計の完了時・検収時の3回に分けてのお支払いを想定しています。

費用は合計だけでなく、工程ごとの内訳と前提条件を書きます。前提が変わったときにどこを見直すのかが決まっていると、あとの話し合いが短く済みます。

7章 スケジュール

## 7. スケジュール
| 工程 | 期間 | お客様にお願いすること |
|---|---|---|
| 要件定義 | 2027-01-12 〜 2027-02-05 | 聞き取りへの参加（週2回）、要件の承認 |
| 基本設計 | 2027-02-08 〜 2027-03-05 | 画面の確認、設計の承認 |
| 詳細設計・開発 | 2027-03-08 〜 2027-04-23 | 質問への回答 |
| 試験 | 2027-04-12 〜 2027-05-14 | 受け入れの試験（5月の2週間） |
| 移行・利用者教育 | 2027-05-10 〜 2027-05-28 | QRラベルの貼り付け、説明会への参加 |
| 稼働 | 2027-06-01 | ― |

相手側の作業が入る時期を同じ表に書いておきます。相手が自分の予定を押さえられるかどうかで、スケジュールの確からしさが変わります。

8章 体制

## 8. 体制
### 8.1 当社の体制
| 役割 | 人数 | 関わる割合 | 主な担当 |
|---|---|---|---|
| プロジェクトマネージャー | 1名 | 30% | 全体の進行、報告、変更の調整 |
| リーダー | 1名 | 100% | 要件定義、設計、品質の確認 |
| 開発担当 | 2名 | 開発・試験の期間は100% | 開発、試験 |

### 8.2 お客様にお願いしたい体制
| 役割 | 主な担当 |
|---|---|
| 責任者 | 要件・設計・検収の承認 |
| 総務の担当者 | 業務の説明、受け入れの試験、QRラベルの貼り付け |
| 情報システムの担当者 | 社内アカウント連携の設定、ネットワークの確認 |

### 8.3 会議と報告
週1回の定例（60分）で、進捗・課題・変更の有無を報告します。

9章 進め方とリスクへの備え

## 9. 進め方とリスクへの備え
### 9.1 進め方
工程ごとに成果物をご確認いただき、承認をいただいてから次の工程に進みます。
承認後に要件を変える場合は、影響する費用と期間をお示ししたうえで、対応を一緒に決めます。

### 9.2 想定するリスクと備え
| 起こりうること | 起きる条件 | 備え | 起きたときの対応 |
|---|---|---|---|
| 台帳のデータに重複や欠けがあり、取り込みに時間がかかる | 現行の台帳の入力の形がそろっていない | 要件定義の期間に台帳を受け取り、状態を調べる | 直す範囲と分担を決め、移行の期間内で調整する |
| QRラベルの貼り付けが稼働日に間に合わない | 4,200点を2週間で貼る人手が足りない | 4月から設置場所ごとに順番に貼り始める | 貼り終えた場所から順に使い始める |
| 社内アカウント連携の設定に時間がかかる | 連携の方式を確認する窓口が決まらない | 1月中に窓口と方式を確認する | 稼働時はシステム内のアカウントで始め、あとから切り替える |

リスクは「起きる条件」と「備え」を具体的に書きます。「仕様の変更により遅れることがあります」のような書き方よりも、どの作業で、何がそろわないと起きるのかを書いたほうが、相手も一緒に備えられます。

10章 要求への適合表（RFPへの回答）

RFPに要求事項の一覧があるときは、1件ずつ「対応できるか・どう対応するか・提案書のどこに書いたか」を返します。 評価する人はこの表を横に置いて提案書を読むので、記載ページの列が効きます。回答の記号はRFPで指定されたものを使い、指定が無ければ次のように決めて表の前に書いておきます。

要求No.   要求事項    優先度 回答  対応の内容   記載ページ
F-01    備品を名前・分類・設置場所で検索できる 必須  A   検索画面で対応 p.8
F-02    貸出の申請と上長の承認ができる 必須  A   申請と承認の機能で対応 p.8
F-03    承認者が不在のとき代理で承認できる   必須  B   代理承認者を設定して対応    p.9
F-04    QRコードで貸出と返却を記録できる   必須  A   スマートフォンのカメラで読み取り    p.9
F-05    返却の期限を自動で通知する   必須  A   前日と当日にメールで通知    p.10
F-06    棚卸しの結果と台帳の差分を一覧にできる 必須  A   棚卸しの機能で対応   p.10
F-07    現行の台帳を取り込める 必須  C   取り込み用の処理を開発 p.12
F-08    社内アカウントでログインできる 必須  B   認証の連携を設定    p.11
F-09    備品ごとの利用回数を集計できる 希望  C   集計の画面を開発    p.10
F-10    チャットツールに通知できる   希望  D   当初はメールで通知し、次の段階で対応  p.10
N-01    平日8時〜20時に利用できる  必須  A   クラウドの構成で対応  p.11
N-02    検索結果を3秒以内に表示する  必須  C   5,000点のデータで性能を試験して確認    p.13

この例の内訳は、A が6件、B が2件、C が3件、D が1件、E が0件です（12件。Pythonで数えて確認）。表の前に内訳を1行で書いておくと、全体の適合の度合いがひと目で伝わります。

D や E を付けた項目は、理由と代わりの案を必ず書きます。対応できない項目を正直に示したうえで代わりの方法を出すほうが、あとの工程で認識の違いが見つかるより、双方にとって進めやすくなります。

提出前の確認項目

No. 分類  確認すること
1   要旨  1章だけを読んで、課題・解決策・効果・費用・期間がわかる
2   要旨  1章の数字が、5章・6章・7章の数字と一致している
3   課題  課題のすべてに、現状の値と出どころが書いてある
4   課題  相手の言葉（RFPや聞き取りで使われた用語）で書いてある
5   対応  課題・原因・解決策・効果・測り方の表に空欄がない
6   対応  機能のすべてに、対応する課題の番号が付いている
7   範囲  対象外が書いてある
8   効果  効果の金額に、計算の前提が並べて書いてある
9   費用  内訳の合計が、合計の欄と一致している
10  費用  前提条件と、費用に含まないものが書いてある
11  期間  相手側の作業と、その時期が書いてある
12  体制  役割ごとの人数と関わる割合が書いてある
13  リスク リスクに、起きる条件と備えが書いてある
14  適合  RFPの要求事項のすべてに回答し、記載ページが実際のページと合っている
15  形式  提出期限・提出方法・部数・ファイル形式がRFPの指定どおりになっている
16  形式  相手の会社名・部署名・システム名に誤りがない
17  形式  ページ番号・版・提出日・有効期限が入っている
18  形式  ほかの提案書から流用した文に、別の相手の名前や数字が残っていない

提案書・企画書・見積書・RFPの違い

提案書と見積書は一緒に出すことが多く、提案書の6章は見積書の要約にあたります。金額が2つの文書で食い違わないよう、見積書を先に確定させてから6章に写します。

企画書は「やるかどうか」を社内で決める文書、提案書は「誰に任せるか」を決めてもらう文書です。発注する側の担当者が、受け取った提案書をもとに社内向けの企画書を書くこともあります。5章の効果と計算の前提を丁寧に書いておくと、その材料として使ってもらえます。

依頼への回答か、自主的な提案かで構成を変える

RFPへの回答で最も大事なのは、相手が決めた形式に合わせることです。目次や様式が指定されているのに独自の構成で出すと、評価の表に点を付けにくくなります。自主的な提案では反対に、相手はまだ課題をはっきり認識していないことがあるので、「なぜ今それに取り組むのか」を2章で示すところに力を使います。

確かめて分かったこと

• 記入例の回収年数は、運用費を引くかどうかで大きく変わりました。 年450万円の効果をそのまま使うと 980÷450 で約2.2年、運用費120万円を引くと 980÷330 で約3.0年です。この記事の例は運用費を引いた値で書いています。どちらで計算したかを前提に書いておきます。
• 作業時間の削減だけでは、年270万円でした。 初期費用980万円に対しては、運用費を引くと年150万円にとどまります。時間以外の効果（この例では重複購入の削減）を別の行として分けて示すと、何がどれだけ効いているかが読み取れます。
• 5年間で比べると、効果2,250万円に対して費用は1,580万円でした。 単年の数字だけでなく、使う期間の合計でも示すと判断の材料が増えます。
• 適合表は、記号ごとの件数を数えて表の前に書くと、12件の内訳（A6・B2・C3・D1）が1行で伝わりました。 件数は手で数えず、表から機械的に数えると書き間違いを防げます。
• 対応表とタブ区切りは、同じ元データから作ると列のずれが起きませんでした。 この記事のタブ区切りは、Markdownの表から変換し、行ごとの列数が一致することを確かめています。

よくある質問

Q. 提案書とは何ですか？ A. 相手の課題に対して、解決策・効果・費用・期間・体制を示し、任せてもらうための文書です。システム開発では、RFPへの回答として出す場合と、こちらから自主的に出す場合があります。

Q. 提案書と企画書の違いは何ですか？ A. 出す相手と目的が違います。提案書は社外の発注する側に「誰に任せるか」を決めてもらう文書で、企画書は社内の決裁する人に「取り組むかどうか」を決めてもらう文書です。

Q. 提案書は何ページくらいが適切ですか？ A. 決まった枚数はなく、RFPに指定があればそれに従います。指定が無いときは、1章の要旨を1ページに収め、本文は読む人が判断に使う内容に絞り、詳しい資料は別紙に回すと読みやすくなります。

Q. 課題の数字が手に入らないときはどうすればよいですか？ A. 聞き取りで伺った概数や、RFPの記載をもとにした値を、出どころと一緒に書きます。2.3の「確認させていただきたい点」に前提として置いた値を並べておけば、相手が正しい値を教えてくれるきっかけにもなります。

Q. RFPの要求に対応できない項目があるときはどうすればよいですか？ A. 適合表に対応できないことを書いたうえで、理由と代わりの案を示します。代わりの方法（記号D）として、当初は別の手段で満たし、次の段階で対応する、といった形を提案できます。

まとめ

• 順番は、課題→原因→解決策→効果→費用と期間→体制。相手の問いに答える並びにする
• 1章の要旨で、課題と効果を数字つきで言い切る。要旨は最後に書き、本文の数字と合わせる
• 課題・原因・解決策・効果・測り方を1行に並べた対応表を、提案書の背骨にする
• 効果の金額には計算の前提を並べ、費用には内訳と前提条件を付ける
• RFPへの回答では、要求事項ごとの適合表に記載ページを入れる
• 自主的な提案では、課題の裏付けと「何もしない場合」との比較を厚くする
• 提出前に、数字の一致・空欄・流用した文の残りを確認項目で確かめる

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。