システム開発会社の提案書には、開発実績や体制図、見積りの根拠が並びます。しかし発注企業の情報システム部門が見ているのは、実績の数ではなく開発方針に一貫性があるか、体制と品質管理が説明できているかという点です。
要件定義の段階でこの信頼を得られないと、その後の商談は進みにくくなります。本記事では、提案書の補足資料として機能する一冊に何を書き、何を書かないかを整理します。
この記事で分かること：
- 情報システム部門が提案書を見るときに確認しているポイント
- 守秘義務契約(NDA)がある中での実績の書き方
- 提案書に添える一冊として機能させる条件
情報システム部門が見ているのは「実績の数」ではない
発注企業の情報システム部門は、技術的な評価に慣れた読み手です。実績件数や導入社数の多さよりも、要件定義から保守までの一貫した方針があるか、トラブル時にどう動くかが説明されているかを重視する傾向があります。
営業資料に近いトーンの本は、この読み手には響きにくくなります。むしろ、開発の考え方や品質管理の手順を淡々と説明する内容のほうが、技術評価者との相性が良くなります。
実際によくある失敗は、営業資料をそのまま体裁だけ書籍にした内容です。導入社数やロゴの羅列は技術評価者の判断材料にならず、かえって「中身が薄い」という印象を与えることがあります。
実績の書き方はNDAの壁を前提にする
SIerの実績紹介で最も詰まりやすいのが、過去の発注元との守秘義務契約(NDA)により、社名やシステムの詳細を公開できないという制約です。実名を出せないまま実績を並べようとすると、内容が曖昧になり、かえって説得力を欠く原稿になりがちです。
| 実績の扱い方 | 内容 | 注意点 |
|---|---|---|
| 業種・規模を伏せて一般化する | 「製造業の基幹システム刷新」のように抽象化して書く | 抽象化しすぎると具体性が失われるため、プロセスの描写で補う |
| 発注元に公開範囲を確認する | 公開可能な事例だけを個別に許諾を取って掲載する | 案件ごとに許諾の有無を管理する必要がある |
| プロセスを主題にする | 「要件定義でどうすり合わせるか」など固有名詞を使わない内容にする | NDAに触れずに書けるが、事例の生々しさは出にくい |
当社では、ヒアリングで得た実績エピソードを匿名化・一般化して原稿に反映する編集を行います。 ただし、どの案件が公開可能かという守秘義務の範囲の判断は、貴社にお願いしています。取引先ごとの契約条件は当社では把握できないためです。
書く内容と、断定を避ける内容
技術的な内容を扱う以上、事実と評価を混同しないことが重要です。
| 区分 | 内容の例 | 書き方の方針 |
|---|---|---|
| 事実として書ける | 取得している認証、体制図、開発フロー、保守対応の窓口体制 | 現状の事実として具体的に書く |
| 慎重に書く | セキュリティ対策の効果、障害対応の速さの評価 | 「対策を実施している」という事実と、「絶対に安全」という保証は分けて書く |
| 書かない | 他社との優劣比較、確認していない技術水準の主張 | 公開情報に基づかない比較や、根拠のない優位性の主張は避ける |
セキュリティや品質管理は情報システム部門が最も厳しく見る部分です。実施している対策は具体的に書けますが、その効果を保証する表現は避ける必要があります。技術内容そのものの正確性は、当社ではなく貴社の技術者・セキュリティ担当者に最終確認をお願いしています。
たとえば「要件定義で仕様変更の申し出をどう扱うか」を具体的に書くと、抽象的な「柔軟に対応します」よりも判断材料になります。抽象的な姿勢の言葉は、どの開発会社の資料にも書けてしまうため差別化にならないためです。
体制図も、正社員中心か協力会社を含むかで発注元の受け止め方が変わります。協力会社を含む体制であれば、隠さずに書いたうえで、品質管理の責任をどう分けているかまで説明すると、実態を隠していない印象につながります。あいまいにするより、事実を先に開示したほうが結果的に信頼を得やすくなります。
内容が古くなる速さに注意する
技術文書は経営者本や社史と違い、内容が古くなる速度が速いという特性があります。使用している開発言語やクラウド基盤、取得している認証は数年単位で変わることがあります。
発行時点の情報であることを明記し、提案の都度、最新の体制と食い違いがないかを担当営業が確認する運用をおすすめしています。体制や認証が変わった場合の記載の更新や増刷は、当初の制作費とは別に発生する作業です。更新の頻度が高い会社は、章単位で差し替えやすい構成にしておくと手間が減ります。
提案書に添える一冊として機能させる条件
提案書の補足資料として使う場合、読み手には限られた時間しかありません。30分程度で読み切れる分量に収め、営業トーンではなく技術文書に近いトーンで書くことが、技術評価者には効果的です。
章立ての例としては、開発方針、品質管理の考え方、体制とコミュニケーションの取り方、保守・運用の考え方、といった構成が実務的です。テーマの立て方は会社の本のテーマの決め方で解説しています。
発注元ごとにRFPの評価項目が異なるため、一冊をそのまま毎回添えるより、目次から該当する章だけを抜粋して使う運用のほうが実務的なことがあります。 全章を毎回読ませるより、評価項目に合う部分だけを示すほうが、担当者の負担を減らせます。営業担当がどの章を抜粋するかをあらかじめ決めておくと、提案書作成の時間も短縮できます。
AIで技術文書を書く際の注意点
AIは、ヒアリングで得た開発方針や体制の説明を読みやすい文章に整えることが得意です。一方で、技術的な正確性そのものを保証する仕組みはありません。 特に認証の名称、対応範囲、体制の詳細は、生成後に必ず技術者による確認が必要です。
当社の進め方では、ヒアリングとプロ編集者による構成の確認を工程に組み込みますが、技術内容の正確性は貴社での確認工程を前提にしています。AIを使った企業出版全体の流れはAIで企業出版する全手順にまとめています。
当社が引き受ける範囲・貴社にお願いする範囲
| 工程 | 当社の役割 | 貴社にお願いする範囲 |
|---|---|---|
| 構成・執筆 | ヒアリングをもとにした原稿作成、編集 | 技術内容・体制情報の提供 |
| 実績の扱い | 匿名化・一般化の編集 | NDAに基づく公開可否の判断 |
| 技術内容の確認 | 文章としての読みやすさの確認 | 技術者・セキュリティ担当者による正確性の確認 |
| デザイン・入稿 | 表紙・図表デザイン、Amazon KDPへの入稿代行 | – |
当社のAI書籍出版代行は**80万円〜（税抜・表紙デザインを含む）**です。ヒアリングから企画設計、AIによる執筆とプロ編集者の確認、図表・表紙デザイン、Amazon KDPへの入稿代行、少部数の印刷・製本までを行います。
まとめ
- 情報システム部門が見ているのは実績の数ではなく、開発方針と体制の一貫性です。
- 過去の実績はNDAで実名を出せないことが多く、一般化するか発注元に公開範囲を確認する必要があります。
- セキュリティや品質管理は事実として具体的に書けますが、効果を保証する表現は避けます。
- 提案書の補足資料にするなら、営業トーンより技術文書に近いトーンで、短時間で読める分量にします。
- 技術内容の正確性の最終確認は貴社にお願いし、当社は執筆・編集・入稿までを担当します。
提案書に添える一冊をどう設計するか、要件定義の段階からご相談いただけます。
※本記事は一般的な説明であり、個別の契約内容についての法的助言ではありません。