発注側は提案書のここしか見ていない

山崎行政書士事務所
3 日前
読了時間: 7分

――クラウド時代に「選ばれるベンダー」の見せ方

「この案件、技術的には絶対うちの方が良かったはずなのに、　なぜか競合に決まってしまった…。」

システム開発会社やSaaSベンダーさんから、よく聞くぼやきです。

性能もスペックも負けていない
値段も頑張った
クラウドの知識も自信あり

それでも落ちるときは落ちます。

その裏で、発注側の社内では何が起きているのか。実は、提案書の「ほんの数カ所」しか見ていないことが多いのです。

山崎行政書士事務所として、発注側の法務・情シス・現場の動きを見てきた立場から、

「発注側は提案書のここしか見ていない」

というポイントを、クラウド案件を前提に整理してみます。

1. 発注側の社内で、提案書はどう扱われているのか

まず前提として、発注側の社内では：

現場（ユーザー部門）
情報システム部門
法務・コンプラ
経営層・稟議ルート

など、複数の人・部署が提案書を“斜め読み”しています。

そしてそれぞれが、次のような観点だけをサッとチェックすることが多いです。

現場：「うちの課題、ちゃんと分かってくれてるか？」
情シス：「クラウド構成と運用、無茶なところないか？」
法務：「責任・データの扱い・契約まわり、大丈夫そうか？」
経営層：「全体として、任せても大崩れしなさそうか？」

つまり、提案書全部は読まれません。それぞれが、自分の立場で“ここだけ”を見ています。

2. 発注側が最初に見るのは「1ページ目の3つの要素」だけ

① 「御社の課題」欄の1〜3行

最初に見られるのは、いわゆる

「お客様の課題の理解」

を書いたパートです。

ここがふわっとしていると、その時点で「うーん」と一歩引かれてしまいます。

悪い例

・業務効率化のご要望・デジタル化の推進・属人化の解消

どの会社でも当てはまりそうなことしか書いていないパターンです。

発注側が読んでホッとする例

・拠点ごとに別々に管理されている在庫情報がリアルタイムに見えないため、　欠品・過剰在庫の判断が担当者の勘と経験に依存している。・現行のExcelベースの管理では、月次集計に毎回2〜3日以上かかっている。・上記の結果、営業が「今出せる数量」を即答できず、　大口案件のスピード感に追いついていない。

ここまで書いてあると、

「ちゃんと話を聞いてくれている」
「課題の粒度が、うちの感覚と合っている」

と感じてもらいやすくなります。

② 「クラウド構成＋責任分担」の簡単な図

次に見られるのが、クラウド構成図と、その説明です。

発注側は、細かい技術仕様よりも、

どのクラウドサービスを
どう組み合わせて
どこにデータを置いて
誰がどこまで面倒を見るのか

が、パッと見で分かるかどうかを気にしています。

よくある残念なパターン

ベンダー社内向けの詳細構成図をそのまま貼っている
サービス名と矢印だらけで、何がどこを通っているのか分からない
責任分担（自社／クラウド事業者／お客様）が何も書いていない

発注側が見たいのは、すごくシンプルな図です。

左側：発注企業（ユーザー）
真ん中：受注会社（システム・運用）
右側：クラウド事業者（IaaS/PaaS/SaaS）

という3ブロックで、

データの流れ（どこに保存するか）
管理・監視（誰がどこまで見るか）
障害・インシデント時の動き（誰が誰に連絡するか）

が、1枚で伝わるレベルになっていると、それだけで印象が変わります。

③ 「運用と障害時対応」の1ページ

提案書では機能説明に紙を割きがちですが、発注側が知りたいのは、同じくらい、いやそれ以上に

「作ったあと、日々どう運用されるのか」「止まったら、そのときどう動いてくれるのか」

です。

よくある抜け方

運用フローが「保守サポートします」の一言で終わっている
障害時の連絡方法・窓口・対応時間などが書いていない
どこからが追加費用なのか、曖昧なまま

発注側が最低限見たい項目

平時の窓口体制
- 受付チャネル（メール／ポータル／電話など）
- 対応時間帯
- 1次・2次の役割分担
障害発生時の流れ
- 連絡方法
- 初動（◯分以内に一次報告）
- 復旧見込みの出し方
- 事後報告書に含める内容
費用の考え方
- 保守範囲内でやること
- 別途見積になるケース

詳細なSLAまで書き込む必要はなく、A4で1ページ “絵＋箇条書き” でイメージが湧けば十分です。

3. 技術説明よりも「法務と情シスがOKしやすいか」が重要になる

発注側の社内で、提案書が回るとき、実は「技術」より前に、次の2つで足切りされることも多いです。

法務：契約・責任・データの扱い
情シス：クラウド構成とセキュリティ

法務が見るポイント：

「この会社と契約して、後で困らないか？」

法務は、提案書の中でも次のようなところを見ています。

データの帰属（誰のものか）
契約終了時のデータ返却・削除の考え方
再委託・下請けの有無と、その管理方法
障害・漏えい時の連絡義務・報告内容

ここがあまりに曖昧だと、「契約書のドラフトをもらってから考えよう」ではなく、

「そもそも、この会社とは契約形態をまとめづらそう」

と判断されてしまうこともあります。

ポイント

提案書の段階で、

「データの所有権は御社にあります」
「クラウド事業者・再委託先はこのような立て付けです」
「インシデント時はこのような報告を行います」

といった**“契約の方向性レベル”**は書いておくと、法務としては「話しやすい会社」に見えます。

情シスが見るポイント：

「自社のポリシーに乗せられる構成か？」

情シスは、次のような観点で“短時間チェック”をします。

社内のセキュリティポリシーに違反しそうな構成がないか
- 例：データ保管場所（国外リージョン前提など）
- 例：ログ・監査手段が全く用意されていない
自社の運用体制で、現実的に回せるか
- 全てベンダー任せにできるのか
- 社内でやるべき作業が多すぎないか

ここで「現実味のない構成」に見えると、技術的に魅力があっても、一気に評価が下がります。

提案書のクラウド構成ページに、

データ保存先（リージョン／サービス種別）
ログ取得方法・保管イメージ
発注企業側にお願いしたい運用（権限付与・レビューなど）

が簡潔に書いてあるだけで、

「自社ポリシーと突き合わせる材料がそろっている」

と感じてもらえます。

4. 「全部を頑張る」のではなく、「見られるページだけ磨く」

ここまで読んでみると、

「そんなにいろいろ書き分けるのは大変だ…」

と感じるかもしれません。

ただ、発注側が実際によく見るページは、せいぜいこのくらいです。

冒頭の「お客様課題の整理」＋「解決の方向性」
クラウド構成図＋責任分担のイメージ図
運用・障害時対応の1ページ
データ・契約まわりの考え方（ざっくりでいいので）

つまり、

提案書全体を完璧にする必要はなく、「この4ページだけは毎回とことん磨く」という発想で十分です。

技術仕様や詳細機能は、どうしても見比べるのが大変なので、最後の最後の“決め手”になることはあっても、

一次選抜の段階では「安心感のある会社かどうか」のほうが効きます。

5. 山崎行政書士事務所がお手伝いできること

山崎行政書士事務所では、クラウド法務・情報セキュリティの視点から、

提案書の「クラウド構成」「責任分担」「契約・データの扱い」パートの磨き込み
発注側（法務・情シス）が読みやすいクラウド構成図・データフロー図の作成サポート
RFPに書かれているクラウド条件を読み解き、「ここは守る」「ここは相談できる」ラインの整理
提案書と整合した契約条項案（責任分界・データ帰属・再委託など）のドラフト

といったご相談を受けています。

「技術提案には自信があるけれど、いつも『セキュリティ』『クラウド構成』『契約』のところで説得力を出しきれていない気がする…」

という受注側の会社さんには、発注者視点を織り込んだ「型」を一度作っておくと、その後の案件でもずっと使い回せる武器になります。

静岡県内のシステム開発会社・SaaSベンダーさん向けには、オンライン・訪問どちらでも対応可能です。