プロポーザル提案書の「加点」攻略｜評価項目別テンプレ（体制・実績・工程・リスク・セキュリティ）
初めてプロポーザルに挑戦しようと募集要項を開いた瞬間、「評価項目は分かるのに、何を書けば点になるのかが分からない」と手が止まった経験はないでしょうか。
プロポーザルは、提案内容や実績などの“総合力”で選定されやすい分、書き方次第で差がつきます。ここでは審査で頻出の評価項目を、採点者が比較しやすい形に変換するテンプレとしてまとめます。
プロポーザルで「加点」を取りやすい提案書の前提：定性評価を“比較可能”にする
プロポーザル方式は、価格のみで決める方式ではなく、提案内容・技術力・実績などを総合的に見て事業者を選ぶ手続きとして説明されます。仕様を固めきれない業務で採用されやすく、典型的には「公募→提案書提出→審査（書類・ヒアリング等）→優先交渉→契約」という流れになります。
この構造上、審査側は“良さそう”という印象だけでなく、複数社を公平に比べられる材料を求めがちです。加点のコツはシンプルで、定性的な主張を、根拠・数値・手順・体制図で「点が付けやすい文章」に翻訳することです。
審査側が点を付けやすい「3点セット」
根拠：なぜその提案が妥当か（前提・制約・データ・経験則）
手順：どう進めるか（工程、レビュー、合意形成、成果物）
責任：誰が担うか（体制、役割分担、承認者、代替要員）
評価項目が「実施方針」「工程」「提案の妥当性・実現性」「実績」「価格」などで構成されるケースでは、上の3点セットが揃っているほど採点が安定し、結果として加点につながります。
評価項目別テンプレ①：体制（実施方針・体制）で加点する書き方
体制は「ちゃんと遂行できる会社か」を最短で判断される章です。プロポーザルは選定後に協議して契約条件を詰める側面があるため、発注者と並走できる設計（合意形成・課題管理）まで書けると強いです。
そのまま使える見出し構成（体制章テンプレ）
1. 実施体制（体制図／役割と責任／意思決定）
2. 要員計画（必要スキル／稼働配分／増員条件）
3. 発注者とのコミュニケーション設計（定例会／議事録／承認フロー）
4. 品質・セキュリティの責任体制（品質責任者／セキュリティ責任者）
書き方の型：体制図＋役割定義（例文）
【体制図】プロジェクトマネージャ（PM）を統括責任者とし、品質責任者・セキュリティ責任者をPM直下に配置します。発注者窓口はPMに一本化し、意思決定の遅延を防ぐため、週次定例で課題・リスク・変更要望をレビューします。
【役割】PMは進捗・コスト・品質・リスクの最終責任を負い、品質責任者は成果物のレビュー基準と受入条件を管理します。セキュリティ責任者はアクセス権、ログ監視、インシデント対応の運用手順を管理し、月次で点検結果を報告します。
加点になりやすい小技
代替要員：キーパーソン不在時のバックアップを氏名まで書けない場合でも「同等スキル要員を○名確保」など条件を明記
合意形成：議事録の発行タイミング、承認期限、ToDo管理（誰が・いつまで）を固定化
責任の所在：「最終責任者」を必ず置く（兼務でも可）
評価項目別テンプレ②：実績（業務実績）で加点する書き方
実績は「似た案件をやったことがあるか」だけでなく、「今回に再現できるか」が見られます。文章で盛るより、比較できる表に落としたほうが得点に直結しやすいです。
実績サマリー表（コピペ用フォーマット）
案件名（公開可能な範囲で）
発注者種別（国／自治体／独法／民間など）
規模（人数、拠点数、対象端末数、対象ユーザー数など）
期間（開始〜完了）
自社の役割（元請／共同企業体／下請、担当範囲）
成果（定量）：例）納期遵守率、障害件数、運用定着率、対応時間短縮率
今回との類似点（業務フロー、体制、制約条件）
「成果」を定量化できないときの逃げ道
数字が出せない場合は、成果物や運用資産を“再現性の証拠”として示します。
手順書・チェックリスト・教育資料などの整備有無
レビュー観点表、テスト仕様書、受入条件の雛形の保有
問い合わせ対応の分類表、ナレッジ運用の仕組み
評価項目別テンプレ③：工程（実施方針・工程）で加点する書き方
工程は「速そう」ではなく「現実的に回る」が評価されます。特にプロポーザルは仕様が固まりきらない案件で採用されやすいため、前提条件や発注者側の作業も含めて“遅れやすいポイント”を先回りして書くと、妥当性・実現性の点が伸びます。
WBS（工程表）に必ず入れたい5要素
フェーズ：要件整理／設計／構築／テスト／移行／運用など
成果物：議事録、要件定義書、設計書、運用手順書など
レビュー：社内レビュー→発注者レビューの順番を明記
承認ポイント：発注者の承認が必要な箇所（いつ・誰が）
品質ゲート：受入条件、完了条件（定義があるだけで加点されやすい）
前提条件・依存関係（例文）
本工程は、発注者様からの現行資料（業務フロー、台帳、既存手順等）の提供を第1週までに受領する前提で計画します。提供が遅延する場合は、影響範囲（設計開始日、レビュー日程）を即日可視化し、代替としてヒアリングセッションを増枠して遅延吸収を図ります。
評価項目別テンプレ④：リスク（妥当性・実現性）で加点する書き方
リスクは、書くほど不利になると思われがちですが逆です。定性的な審査では「課題を理解しているか」「手当てがあるか」が比較ポイントになります。リスク登録簿（リスク一覧表）を付けるだけで、主観評価を客観材料に変えられます。
リスク登録簿（コピペ用フォーマット）
リスクID
事象（起きうること）
原因
影響（QCD：品質/コスト/納期）
発生確率（高/中/低）
影響度（高/中/低）
検知方法（どう気づくか）
予防策（起こさないために）
発生時対応（起きたらどうするか）
責任者（自社・発注者側の窓口）
発注者側リスクも「対案付き」で書く
プロポーザルは契約条件を選定後に詰める特性があるため、要件未確定・意思決定遅延など“発注者側のリスク”が現実に起こりやすいです。ここをタブー視せず、合意形成の仕組み（承認期限、決裁者の明確化、議事録確定）をセットで書くと、協業のしやすさが伝わります。
評価項目別テンプレ⑤：セキュリティ（特定テーマ対応）で加点する書き方
IT・BPO・情報を扱う業務はもちろん、建設・物品でも個人情報や図面、仕様書を取り扱う場合はセキュリティ記載が評価に効きます。ポイントは「気をつけます」ではなく、準拠方針→脅威認識→対策体系→運用ルールの順で、採点できる材料に落とすことです。
書き方テンプレ：セキュリティ章の骨子
1. 準拠方針：法令・ガイドライン・社内規程に基づく運用方針（公共領域では姿勢の明確化が重要）
2. 脅威認識：なぜ必要かを、客観データで短く示す
3. 対策体系：網羅性が担保できる枠組み（例：情報セキュリティの7要素）で章立て
4. 運用ルール：最低限の行動原則（例：情報セキュリティ5か条）を「頻度・責任者・証跡」に落とす
脅威認識に使える根拠データ（書きぶり例）
近年はサイバー攻撃が増大していることが観測データでも示されているため、当社は“侵入される前提”でアクセス制御・ログ監視・復旧手順を設計します。
根拠データの参照先として、民間事業者の解説ではありますが、観測結果に触れているNTT西日本のサイバーセキュリティ解説ページが利用できます。
7要素で「漏れ」を潰す（章立て例）
情報セキュリティの7要素（機密性・完全性・可用性など）を見出しとして置き、各要素に対し「技術対策＋運用対策＋点検方法」をセットで書くと、審査者が評価しやすくなります。7要素の定義整理はLANSCOPEの解説が参考になります。
「情報セキュリティ5か条」を運用ルールに落とす（例）
OS・ソフトウェア更新：適用期限（例：公開後○日以内）、適用状況の月次報告
ウイルス対策：定義ファイル更新頻度、検知時の隔離・報告フロー
パスワード強化：複雑性、使い回し禁止、多要素認証の適用範囲
共有設定の見直し：アクセス権棚卸しの頻度、権限申請の承認者
脅威理解（教育）：年○回の教育、受講記録、標的型訓練の有無
5か条の内容整理は情報セキュリティ5か条の解説を参照できます。
加点を落としやすい「提案書の事故」を提出前に潰すチェックリスト
最後に、内容以前に失点しやすい“事故”を潰します。プロポーザルは作り込み負荷が高いと言われることもあり、忙しい現場ほど抜けが起きがちです。
評価項目と見出しが1対1で対応している（採点表の順番どおりが安全）
主張には根拠がある（実績、数値、手順、体制、前提条件）
工程に承認ポイント・成果物・完了条件がある
リスク登録簿に「検知方法」「責任者」まで入っている
セキュリティは運用（頻度・責任者・証跡）まで書けている
提出形式（ページ数、フォント、押印、ファイル名、提出方法）が要項どおり