ホームページリニューアルの仕様書｜プロポーザル公募項目と評価基準

ホームページリニューアルを公募型プロポーザルで発注するとき、外に出す文書は4点セットになります。公募要項（応募のルール）、仕様書（作ってほしいものの中身）、提出様式（提案書の書式）、評価基準（採点表）です。この4つのうちどれか1つでも中身が薄いと、集まる提案の粒度がバラバラになり、見積を横に並べて比べられなくなります。

この記事は、自治体・外郭団体・大学・企業の広報や情報担当として、サイトリニューアルの提案依頼書を自分の手で書かないといけない方に向けています。読み終わる頃には、仕様書に書く項目、評価基準の配点表、価格点の算式、公募から契約までの流れを、自分の案件用に埋められる状態を目指します。

ここで扱うのは社外に出す公募文書だけです。社内の意見をどう1枚にまとめるかはリニューアル要件定義をAIで整理する5ステップ、経営層の決裁を通す資料づくりはB2Bサイトリニューアルを社内で通す提案書の作り方で解説しています。社内側が固まっていない状態で公募文書を書き始めると、公告後に条件が変わって出し直しになります。

Contents / 目次

1. まず決めるのは方式。一般競争入札とプロポーザル方式は別物
2. ホームページリニューアルの仕様書に書く項目一覧
3. ホームページ制作のプロポーザル評価基準。配点表の作り方
4. サイトリニューアルの提案依頼書を作る6ステップ
5. 公募後の流れと、公募文書を整えると何が変わるか
6. 公募型プロポーザルでよくある失敗と回避法
7. 発注側が知っておきたい、公募文書の限界と妥協点
8. 今日やる最初の一歩

まず決めるのは方式。一般競争入札とプロポーザル方式は別物

ホームページリニューアルの発注で最初に決めるのは、価格で選ぶか、企画内容で選ぶかです。ここを決めないまま文書を書き始めると、仕様書の粒度が決まりません。

一般競争入札とは、あらかじめ仕様を確定させたうえで、価格の低い事業者を選ぶ方式のことです。仕様書に書いてあることが完成物のすべてになるので、発注側が「何を作るか」を先に決め切れている案件に向きます。

公募型プロポーザル方式とは、事業者から企画提案を出してもらい、その中身を審査して契約の相手方を選ぶ方式のことです。手続きの根拠や位置づけは自治体ごとに定めが違うので、自分の組織の契約規則・実施要領を必ず確認してください。ホームページリニューアルは、情報設計やデザイン、運用のしやすさといった「やり方によって結果が変わる部分」が大きいため、この方式が選ばれやすくなっています。

方式	何で選ぶか	仕様書の書き方	向いている案件
一般競争入札	価格	作るものを確定させて書く。裁量の余地を残さない	ページ数・機能が確定しているサーバ移設、既存デザインのまま改修
公募型プロポーザル	企画提案の内容（＋価格）	目的・条件・満たすべき水準を書き、実現方法は提案に委ねる	情報設計から見直すリニューアル、CMS入替、運用体制まで含む案件
総合評価落札方式	価格と技術点の総合点	入札の一種。仕様は確定させたうえで技術評価を加える	仕様が固まっていて、品質差も見たい案件

混同しやすい点。プロポーザルの審査で決まるのは、まず「誰と契約するか」です。提案内容を契約にどこまで反映させるかは組織ごとの実施要領によって扱いが違うので、自分の案件の要領を確認したうえで、仕様書には「絶対に外せない条件」を確定事項として書き、それ以外は提案に委ねる書き分けをしてください。

民間企業が発注する場合は、法令上の手続きの縛りはありません。ただし文書の構成は自治体の公募と同じ形が使えます。多くの自治体が公募要項・仕様書・様式一式をPDFで公開しているので、「自治体名 ホームページ リニューアル 公募型プロポーザル」で検索すれば、現在募集中または過去に実施された案件が見つかります。自分の案件に近い規模の公募を2〜3件ダウンロードして、章立てを見比べるのが一番早い準備になります。

この章の結論として、方式が決まれば仕様書の粒度も決まります。提案に委ねたい部分がある案件ならプロポーザル、作るものが確定しているなら入札、と先に振り分けてから文書に着手してください。

ホームページリニューアルの仕様書に書く項目一覧

仕様書に必ず入れる項目は9つあります。この9つのうち抜けやすいのは「現行サイトの規模」「移行の範囲」「著作権とデータの帰属」の3つで、ここが抜けると各社の見積が比較できなくなります。

項目	書く中身	書かないとどうなるか
1. 業務名と目的	リニューアルで何を改善したいか。現状の課題を2〜3点	提案がデザイン刷新だけに寄る
2. 現行サイトの規模	総ページ数、CMSの種類とバージョン、ドメイン数、サブサイトの有無	各社が違う前提で見積もり、金額差が読めなくなる
3. 対象範囲	設計・デザイン・構築・移行・テスト・研修・公開後の運用保守のどこまでか	公開後に別契約が必要になり、予算年度をまたぐ
4. 技術要件	CMSの条件、サーバ環境、対応ブラウザ、スマートフォン対応、SSL、アクセシビリティの配慮	納品後に自分たちで更新できない
5. コンテンツの作業分担	原稿・写真は誰が用意するか、ページ単位で移行するのは誰か	公開直前に大量の原稿作業が発注側に降ってくる
6. 移行とURLの引き継ぎ	旧URLから新URLへの301リダイレクト対応の範囲、計測ツールの再設定	旧URLへのアクセスがエラーになり、追加費用で対応することになる
7. 検査・引き渡し	検収の方法、修正対応の期間、納品物の一覧（データ・設計書・マニュアル）	「どこまでやれば完了か」で揉める
8. 著作権とデータの帰属	成果物の権利の扱い、第三者素材のライセンス、CMSテーマの改変可否	別業者に乗り換えられず、以後の改修が1社に固定される
9. 契約期間と支払	委託期間、公開予定日、支払時期、年度をまたぐ場合の扱い	スケジュールが提案ごとにバラバラになる

現行サイトの規模は「数えた数字」で書く

現行サイトの規模は、感覚ではなく実数で書いてください。書くのは、総ページ数、PDFなど添付ファイルの数、現在のCMSとバージョン、更新担当の人数の4点です。

総ページ数の基準にできるのは、CMSの管理画面で数えたページの件数です。固定ページ・投稿・PDFなどのファイルを種別ごとに数え、その合計と数え方を仕様書に書いてください。CMSを使っていない、あるいは管理画面から全体を数えられない場合は、サイトマップ（sitemap.xml）のURL件数や、Google Search Consoleのページ別データに出てくるURL件数も参考にできます。ただしサイトマップに載せる範囲は運用者の設定次第で、Search Consoleのページ別データは検索結果に表示されたURLなので、どちらも総ページ数そのものではありません。あくまで管理画面で数えた数字の裏づけとして使ってください。数え方はインデックス未登録の原因と再登録の手順でも触れています。

ここで「約200ページ程度」とぼかすと、A社は200ページ分の移行費、B社は主要30ページのみの費用で見積もることになります。金額差が3倍近く開いても、それが提案力の差なのか前提の差なのか判別できません。

運用・保守をどこまで公募範囲に入れるか

公開後の運用・保守は、リニューアルと同じ公募に含めるのが原則おすすめです。別発注にすると、作った会社と守る会社が分かれ、不具合が出たときにどちらの責任か判断できなくなります。

業務名の時点で「リニューアル及び運用・保守業務」のように併記しておくと、応募する側も最初から運用体制を含めて見積もることになります。逆に業務名が「リニューアル業務」だけだと、保守は別途と読まれます。

含める場合は、保守の中身を分解して、次の4点を書いてください。

• CMS・プラグインの更新：対象と頻度
• バックアップ：取得の頻度と保存期間
• 障害対応：連絡窓口と受付時間帯
• 軽微な修正：月あたりの回数の上限

何にいくらかかるのかの内訳はWordPress保守費用の相場と内訳にまとめています。

コピペで使える仕様書の目次テンプレート

仕様書の章立ては、次のテンプレートをそのまま使えます。テキストエディタに貼って、各章の中身を埋めていってください。

【ホームページリニューアル業務委託仕様書】

1 業務名
2 業務の目的
  2-1 現状の課題（3点以内・数字を添える）
  2-2 リニューアル後に達成したい状態
3 委託期間・公開予定日
4 対象サイト
  4-1 対象ドメイン ［例 www.example.jp］
  4-2 現行の総ページ数 ［数えた件数と数え方を記入］
  4-3 現行CMS・バージョン ［不明の場合は「不明」と明記］
  4-4 対象外とするサイト・システム
5 業務範囲
  5-1 全体設計（サイトマップ・ワイヤーフレーム）
  5-2 デザイン制作
  5-3 CMS構築・機能実装
  5-4 コンテンツ移行（担当区分を明記）
  5-5 旧URLから新URLへのリダイレクト設定
  5-6 テスト・検査
  5-7 操作研修・マニュアル作成
  5-8 公開後の運用保守（期間・内容）
6 技術要件
  6-1 CMSに関する条件
  6-2 サーバ・ドメイン・SSLの条件
  6-3 対応端末・対応ブラウザ
  6-4 スマートフォン対応
  6-5 アクセシビリティに関する配慮事項
  6-6 セキュリティに関する要件
  6-7 アクセス解析ツールの設置
7 発注者が用意するもの／受注者が用意するもの
8 納品物（データ形式・部数・提出期限）
9 著作権等の取扱い
10 個人情報・情報セキュリティの取扱い
11 検査及び引渡し
12 瑕疵対応・修正対応の期間
13 その他（疑義が生じた場合の協議）

この章の結論として、仕様書の役割は「各社を同じ前提に立たせること」です。デザインの好みを書く場所ではなく、規模・範囲・条件を確定させて見積を比較可能にする場所だと考えて埋めてください。

ホームページ制作のプロポーザル評価基準。配点表の作り方

評価基準をいつ公表するかは、組織の実施要領で定めが違います。ただ、順位をつけたらその理由まで説明しないといけないので、公募要項と一緒に事前公表しておくほうが選定後に説明しやすくなります。あとから配点を決めると、特定の提案に有利な基準を作ったように見えてしまいます。

配点表は、技術評価と価格評価に分け、合計100点で組むのが扱いやすい形です。次の配分は、集客改善と運用のしやすさを重視する場合の一例です。案件の目的に応じて、重い項目に点を寄せてください。

評価項目	配点例	何を見て採点するか
業務理解・実施方針	15	現状の課題を自分の言葉で分析できているか。仕様書の写しになっていないか
情報設計・サイト構成	15	サイトマップ案の粒度。誰がどの情報にたどり着くかの導線が説明されているか
デザインの考え方	10	見た目の好みではなく、伝わりやすさと操作しやすさの根拠が語られているか
アクセシビリティ対応	10	配慮する内容と、どう検証するかの方法まで書かれているか
CMS・更新のしやすさ	10	担当者が自分で更新できるか。研修とマニュアルの内容
移行・リダイレクト計画	10	既存ページの評価を落とさない手順が具体的か
実施体制・スケジュール	10	担当者の役割と稼働。無理のない工程か
類似業務の実績	10	同規模・同種の実績。会社の総数ではなく担当者の経験
価格	10	算式で機械的に算出
合計	100

価格点の算式は先に決めて公表する

価格点は、審査委員の裁量を入れず算式で出します。次に挙げる3つは、公的に定義された制度用語ではなく、算式の考え方をこの記事で整理して名前を付けたものです。要項に載せるときは、名称をそのまま使わず、自分の組織の契約規則・実施要領に定めがあればその用語と算式に合わせてください。

【1】最低提案価格を満点にする形
価格点 = 価格の配点 × （最低提案価格 ÷ 当該提案者の提案価格）

例）価格の配点10点、最低提案価格500万円のとき
  A社 500万円 → 10 × (500 ÷ 500) = 10.0点
  B社 600万円 → 10 × (500 ÷ 600) = 8.3点
  C社 800万円 → 10 × (500 ÷ 800) = 6.3点

【2】予定価格からの引き下げ率で見る形
価格点 = 価格の配点 × （予定価格 － 提案価格）÷ 予定価格

例）価格の配点10点、予定価格800万円のとき
  A社 500万円 → 10 × (800 － 500) ÷ 800 = 3.75点
  B社 600万円 → 10 × (800 － 600) ÷ 800 = 2.50点
  C社 800万円 → 10 × (800 － 800) ÷ 800 = 0.00点
  ※満点が出にくいので、価格差を点差に出したくない案件向き

【3】基準額を超えた分だけ引く形
価格点 = 価格の配点 － （提案価格 － 最低提案価格）÷ 減点単位額

例）価格の配点10点、最低提案価格500万円、減点単位額50万円のとき
  A社 500万円 → 10 － (500 － 500) ÷ 50 = 10.0点
  B社 600万円 → 10 － (600 － 500) ÷ 50 = 8.0点
  C社 800万円 → 10 － (800 － 500) ÷ 50 = 4.0点
  ※減点単位額を小さくするほど価格差が点差に強く出る（下限は0点とする）

どの算式を選ぶにせよ、事前に決めておけば価格差が点差にどう反映されるかを見積もれます。【1】の例では、300万円の価格差がついても点差は3.7点にしかなりません。つまり技術点で4点差がつけば逆転します。同じ価格差でも【3】なら6点差になり、技術点で覆すのが難しくなります。価格の配点と算式をどう組むかは、価格差をどこまで技術で覆せる設計にしたいかの意思表示です。安く発注することが目的なら価格点を厚くして引き下げ幅を点差に強く出す形、成果を重視するなら技術点を厚くしてください。

採点のブレを防ぐ評価表の書き方

評価項目だけ並べても、審査委員によって点が大きくぶれます。各項目に「何点をつけるとどういう評価か」の段階を書いてください。5段階なら次のように定義します。

• 5（優）：要求を満たしたうえで、想定していなかった有効な提案がある
• 4（良）：要求を満たし、実現方法が具体的に示されている
• 3（可）：要求は満たしているが、実現方法の記述が一般的
• 2（やや不足）：要求の一部しか触れられていない
• 1（不足）：該当する記述がない、または要求を満たさない

そのうえで、配点を「項目の重み × 5段階評価」で算出する形にすると扱いやすくなります。たとえば情報設計15点の項目なら、評価4で15×(4÷5)＝12点です。この形にすると、審査委員は5段階を選ぶだけでよく、点数の計算で迷いません。5段階の刻み方や換算の方法は組織によって違うので、実施要領に定めがあればそちらに合わせてください。

基準点（足切り）を設けるかどうかも、要項に書いておいてください。「技術点が配点の6割に満たない提案は選定しない」と明記しておかないと、提案の質が低くても最高点の1社を選ばざるを得なくなります。

この章の結論として、評価基準は「あとで説明できる形」で先に公表するのが要点です。配点、算式、5段階の定義、基準点の4つを事前に決めておけば、選定理由を聞かれても答えられます。

サイトリニューアルの提案依頼書を作る6ステップ

公募文書は、次の順番で作ると手戻りが起きません。目的から入り、条件を固め、最後に評価基準を作るのが基本の流れです。

1. リニューアルの目的を1文にする
2. 現行サイトの実数を棚卸しする
3. 業務範囲を線引きする
4. 仕様書を書く
5. 評価基準と様式を作る
6. 公告前に第三者に読ませる

ステップ1. リニューアルの目的を1文にする

最初にやるのは、「誰の、どの行動を増やしたいか」を1文で書くことです。「デザインが古いから」は目的になりません。提案する側が何に向けて設計すればいいか分からず、結果として見た目の刷新案しか集まりません。

書き方の型は「〈対象〉が〈行動〉しやすいサイトにする」です。たとえば「市外からの転入検討者が、住まいと子育ての情報にたどり着きやすいサイトにする」「取引先の技術担当者が、製品仕様を自分で調べて問い合わせできるサイトにする」のように書きます。この1文を仕様書の冒頭に置くと、提案の焦点が揃います。

ステップ2. 現行サイトの実数を棚卸しする

棚卸しでは、ページ一覧を作って「残す・統合する・捨てる」の3分類をします。全ページを分類し切る必要はなく、上位アクセスのページと、更新が止まっているページを見分けられれば十分です。

手順は次の3つです。

1. CMSの管理画面またはサイトマップからURL一覧を書き出して表計算ソフトに貼る
2. Search Consoleのページ別データをエクスポートして、表示回数を横に並べる
3. Google アナリティクス 4のページ別の表示回数も同様に並べる

この3つを突き合わせます。設置がまだの場合はGA4をWordPressに設置する手順を先に済ませてください。データがないまま公募すると、判断材料が誰の手元にもないまま提案を受けることになります。

この分類作業はAIに任せると速く進みます。ページ一覧と表示回数を貼り付けて、次のような短い指示から始めてください。あとはAIと対話しながら、自社の分類ルールに合わせて詰めていくのが実用的です。

あなたは自治体・企業サイトの情報設計担当です。
以下はサイトの全URL一覧と、直近12か月の表示回数です。

［URLと表示回数を貼り付け］

次の3分類に振り分けて、表で出してください。
・残す（表示回数が多い、または法令・制度上必要）
・統合する（内容が近い複数ページ）
・要検討（表示回数が少なく、更新も止まっている）

分類の理由を各行に1文添えてください。
判断に迷う行は「要確認」と書いて、私に質問してください。

出てきた分類は、そのまま使わず必ず人が見てください。特に「表示回数が少ない＝不要」ではない点に注意が必要です。制度の説明ページや、年に数回しか見られないが必要な手続きのページは、アクセス数だけで判断すると消えます。AIが「要検討」に入れた行を上から確認し、残す理由がある行に印をつける。この確認作業だけは担当者本人がやってください。

ステップ3. 業務範囲を線引きする

業務範囲は、次の8項目それぞれに「含む／含まない／協議」の3つを記入して決めます。曖昧なまま公募すると、提案ごとに範囲が違い、金額が比較できません。

• 原稿執筆：新規ページの文章を誰が書くか。ライティングを含めるかどうか
• 写真撮影：撮影が必要か、既存素材で足りるか
• 既存ページの移行：何ページ分を受注者が移すか。残りは発注者が入力するか
• ドメイン・サーバ：現行のまま使うか、受注者が用意するか
• リダイレクト設定：URLが変わるページの転送設定を含むか
• 操作研修：実施回数と対象人数
• 公開後の保守：期間と作業内容
• アクセス解析の再設定：計測ツールの引き継ぎを含むか

ステップ4. 仕様書を書く

ステップ1〜3で決めたことを、前章の目次テンプレートに流し込みます。書く順番は、目的（第2章）、対象サイト（第4章）、業務範囲（第5章）、技術要件（第6章）の順が効率的です。

ここでの注意点は、実現方法を書きすぎないことです。「トップページにスライドショーを設置すること」のように手段を指定すると、その手段が最適でなくても提案側は従います。書くべきは「トップページで、初めて訪れた人が3つの主要導線にたどり着けること」のような、満たすべき状態です。

ステップ5. 評価基準と様式を作る

評価基準は前章の配点表を土台にします。あわせて提出様式を用意してください。様式が無いと、A4で3枚の提案とスライド40枚の提案が並び、審査時間が読めなくなります。

最低限そろえる様式は5種類です。

1. 参加申込書（会社名・担当者・連絡先）
2. 参加資格に関する誓約書
3. 質問書（提出期限と提出方法を明記）
4. 企画提案書（枚数上限とページサイズを指定。例として「A4横・20ページ以内」）
5. 見積書（内訳の区分を発注側が指定する。例として設計費・デザイン費・構築費・移行費・研修費・保守費）

見積書の内訳区分を発注側が指定するのは重要です。区分を各社任せにすると「一式500万円」と「11項目に分けて520万円」が並び、どこに差があるのか読めません。

ステップ6. 公告前に第三者に読ませる

公告する前に、その案件に関わっていない人に文書一式を読んでもらってください。確認してほしいのは、次の6点です。

• 読んで見積もれるか：ページ数・範囲・期間から金額を算出できるか
• 矛盾はないか：仕様書の業務範囲と、評価基準の項目がずれていないか
• 日程は現実的か：公告から提案書提出までの期間、提案書提出から公開までの期間
• 参加資格は厳しすぎないか：その条件で応募できる会社が何社あるか
• 様式と枚数上限は書いてあるか：提案書の形式が指定されているか
• 問い合わせ先は生きているか：担当者名・電話・メールが正しいか

この章の結論として、公募文書は「目的→実数→範囲→仕様→評価基準」の順で作るのが最短です。逆に評価基準から作り始めると、点をつけたい項目に合わせて仕様を後づけすることになり、提案の焦点がぼやけます。

公募後の流れと、公募文書を整えると何が変わるか

公募文書を整えた効果は、金額の差ではなく「比較できるようになること」に出ます。同じ前提・同じ様式・同じ配点で提案が集まれば、審査会で議論すべき論点が数個に絞られます。

公募から契約までの流れは、おおむね次のようになります。下の週数は実在の公募を集計したものではなく、年度内に公開まで持っていく場合の組み立て例です。案件規模と決裁の段取りに合わせて増減させてください。

段階	やること	期間の組み立て例
公告	公募要項・仕様書・様式・評価基準を同時公開	基準日
質問受付	書面で質問を受ける。口頭での個別回答はしない	公告から1〜2週間
質問回答の公表	全質問と回答を、全応募予定者が見られる形で公開	受付締切から数日
参加表明・提案書提出	様式に沿った提案書と見積書を受領	公告から3〜5週間
審査（プレゼンテーション）	1社あたりの持ち時間を統一。評価表で採点	提出から1〜2週間
選定結果の通知・公表	選定・非選定の通知。公表の範囲は要項に明記	審査から1週間程度
契約	提案内容をすり合わせて仕様を確定し、契約	通知後

この刻み方が自分の案件で通用するかは、実際に公開されている公募のスケジュールで確かめられます。自治体や外郭団体は、公告日・質問締切・提案書提出期限・審査日を要項に書いて公開しているので、「ホームページ リニューアル 公募型プロポーザル 実施要領」で検索し、規模の近いものを2〜3件開いてください。確認するのは、①公告日から提案書提出期限までが何日あるか、②質問締切が公告から何日目か、③提案書提出から審査日までが何日あるか、④審査日から契約までに何日見ているかの4点です。上の表の週数と並べて、自分の案件で短すぎる区間があれば、その分だけ公告日を前倒ししてください。決裁に時間がかかる組織では、④のあとに起案・決裁の日数を足して逆算します。

整えた公募文書がもたらす3つの変化

公募文書を作り込んだときに実際に変わるのは、次の3つです。

• 見積の差が読めるようになる：ページ数と範囲を確定させると、金額差が「作業量の差」か「単価の差」か「範囲の理解違い」かを判別できます
• 審査の説明がつく：配点と5段階の定義を先に公表しておけば、非選定の会社から理由を聞かれても評価表を示して答えられます
• 公開後の追加費用が減る：移行・リダイレクト・研修・保守を仕様書に書いておけば、「それは範囲外なので別途お見積りです」が発生しません

逆に言うと、公募文書が薄いまま進めた案件は、この3つが全部あとから跳ね返ってきます。特に3つ目は金額に直結します。公開後に発覚する追加作業は、当初の契約に含まれていないため、その年度の予算では対応できないことが多いからです。リニューアル費用をどう会計処理するかはホームページリニューアル費用の勘定科目と資産計上の判断基準にまとめています。

この章の結論として、公募文書の質は「審査の速さ」と「公開後の追加費用」に出ます。文書を1週間かけて整える価値は、選定の納得感と、あとから発生しない請求の両方にあります。

公募型プロポーザルでよくある失敗と回避法

ホームページリニューアルの公募で起きる失敗には、この方式・このテーマ特有の型があります。ここでは実際に起きやすい5つを挙げます。

失敗1. 参加資格を厳しくしすぎて応募が集まらない

「過去5年以内に、同規模自治体の公式サイト構築実績3件以上」のような条件を積み上げると、応募できる会社が絞り込まれます。地域要件（市内・県内に本店または営業所を有すること）を重ねると、さらに絞られます。

そうなると、公告しても応募がゼロ、あるいは1社だけという事態になります。再公告すれば公開予定日が後ろにずれ、年度内の完了が難しくなります。

防ぐには、公告前に条件を満たす会社を実際に数えてください。数え方は、近隣自治体の同種公募の選定結果ページを見て、応募していた会社が自分たちの条件を満たすかを確認する方法が現実的です。数えた結果が競争が成り立たない社数にとどまるなら、実績要件の年数か件数を緩めてください。何社を目安にするかは、案件の規模と地域の事業者数で変わります。

失敗2. 提案書にデザインカンプを求めて、いい会社が降りる

「トップページのデザイン案を提出すること」と書くと、応募する側は選ばれるか分からない段階で無償の制作作業を負うことになります。手が空いている会社しか応募せず、実力のある会社ほど降ります。

さらに悪いのは、審査がデザイン案の見た目の比較になってしまうことです。まだ原稿もサイト構成も決まっていない段階の絵は、公開されるサイトとは別物になります。

デザインの考え方を見たいなら、求めるものを次のどちらかに変えてください。

• トップページの構成案と、その根拠：どの情報をどの順で置くかを、文章と簡単な図で求める
• 類似実績のサイトURLと、そのサイトで工夫した点：すでに公開されているものを挙げてもらう

これなら過大な無償作業を課せずに、設計の考え方を評価できます。

失敗3. 質問回答を個別に返してしまう

公募期間中、電話で個別に質問を受けて口頭で答えると、その情報を持つ会社と持たない会社が生まれます。あとから「回答が公平でなかった」と指摘されたとき、記録がないため説明できません。

回避法は単純です。要項に「質問は所定の様式により電子メールで受け付け、回答は公式サイトで公表する」と書き、電話での質問は「様式でご提出ください」と案内する。回答は質問者名を伏せ、質問文と回答をセットで公表します。

実務上は、ここで出た質問が仕様書の抜けを教えてくれます。「現行のCMSは何か」「移行するページ数は何ページか」といった質問が来たら、それは仕様書に書いていなかったということです。次回の公募では最初から書いてください。

失敗4. 移行とリダイレクトを仕様書に書かず、旧URLが切れる

URLが変わるリニューアルで、旧URLから新URLへの転送設定を仕様書に書き忘れると、旧URLへのアクセスがすべてエラーページに飛びます。外部サイトからのリンクも、印刷物に載せたURLも、名刺やチラシに刷ったURLも同じです。検索結果からの流入も、旧URLが検索結果に残っている間は失われます。

サイト移転時のURLの引き継ぎ方は、Google検索セントラルのサイト移転（URLの変更あり）ガイドに手順がまとまっています。サイトマップの仕様や送信方法も同じ検索セントラルのサイトマップの作成と送信で確認できます。仕様書を書く前に一読しておくと、受注者と条件をすり合わせやすくなります。

この作業は、ページ数が多いほど手間がかかります。範囲を書いていなければ、受注者が善意で全ページ対応してくれる保証はありません。

仕様書には次の3行を入れてください。

• 旧URLから新URLへの301リダイレクトを設定すること
• 対象は公開中の全ページとし、対応表を納品すること
• 公開後1か月間、エラーページの発生状況を確認し報告すること

実際の設定方法は.htaccessで301リダイレクトを設定する手順で解説しています。

失敗5. 著作権とデータの帰属を書かず、次の改修で身動きが取れなくなる

成果物の権利関係を書かないと、数年後に別の会社へ乗り換えようとしたときに問題が出ます。CMSのテーマが独自開発で、そのソースコードの取り扱いが決まっていないと、他社が改修できません。

結果として、以後の改修はすべて当初の1社に依頼するしかなくなり、価格交渉ができなくなります。

仕様書に書くのは次の4点です。

• 成果物の著作権の帰属
• 第三者素材（写真・フォント・プラグイン）のライセンスと継続利用の条件
• CMSのテーマ・テンプレートのソースコードを納品物に含めること
• 契約終了時にデータ一式を引き渡すこと

この4点があるだけで、将来の選択肢が残ります。

この章の結論として、失敗の多くは「書かなかったこと」から起きます。参加資格・提出物・質問対応・移行・権利の5か所は、公告前に文書を検索して該当記述があるか確認してください。

発注側が知っておきたい、公募文書の限界と妥協点

公募文書を丁寧に作っても、避けられない現実がいくつかあります。ここを知らずに進めると、選定後に「思っていたのと違う」が起きます。

仕様書に書いていないことは、基本的にやってもらえない

プロポーザルで選ばれた会社は、提案書と仕様書に沿って作業します。打ち合わせで口頭で頼んだことは、範囲外であれば追加見積の対象です。

これは相手が不誠実なのではなく、公募で金額が確定している以上、範囲外の作業を無償でやると他の応募者との公平性の問題になるからです。「言えばやってくれるだろう」という前提は、公募型の発注では成立しません。

妥協点として現実的なのは、仕様書に「協議事項」の枠を1つ作っておくことです。「軽微な仕様の変更については、双方協議のうえ決定する」の一文を入れておくと、細かい調整が現場でできます。ただし「軽微」の解釈は分かれるので、大きな変更は最初から書き込んでください。

見積限度額を書くと、ほぼ全社がその額に寄る

公募要項に「見積限度額 500万円（税込）」と書くと、提案される金額はおおむねその近辺に集まります。上限が分かれば、その範囲で最大限の提案をするのが合理的だからです。

一方で、書かないと各社の見積が大きくばらつき、予算超過の提案が高評価になってしまう事態が起きます。予算が確定している案件では、書くほうが実務的です。

判断軸としては、予算が議会や取締役会で確定していて動かせないなら明記する、まだ幅を持たせられる段階なら書かずに相場を見る、という分け方になります。書かない場合は、極端に高い提案を排除するために「見積額が予算を著しく超える場合は失格とすることがある」の一文を入れておいてください。

審査委員に、実際に更新する人が入っていないことが多い

審査委員が管理職と外部有識者だけで構成されると、「毎日そのCMSを触る人」の視点が採点に入りません。結果として、見栄えのする提案が高く評価され、公開後に「更新が面倒で誰も触らない」サイトになります。

委員に加えられない場合でも、方法はあります。提案書に「更新画面のイメージ」または「更新手順の説明」を求め、それを実際の担当者に見てもらって意見を出す。その意見を「CMS・更新のしやすさ」の項目の参考資料として審査会に提出する。この形なら、委員構成を変えずに現場の声を採点に反映できます。

公開後に更新が止まるパターンと、その立て直し方は更新されないサイトの信用低下を直す更新体制の作り方にまとめています。

提案書をそのまま生成AIに読ませるのは、先に確認が必要

複数社の提案書を比較する作業をAIに手伝わせたくなりますが、提出された提案書には各社の営業秘密が含まれます。外部のサービスに貼り付ける行為が、自組織の情報管理規程や公募要項の記載と矛盾しないか、必ず先に確認してください。要項に「提出書類は審査以外の目的に使用しない」と書いているなら、その扱いに含まれるかを判断する必要があります。

公募文書を作る側の作業（棚卸し・章立ての整理・誤字確認）は自分たちの情報なのでAIを使いやすい領域です。一方、提出された提案書の取り扱いは別の判断が要ります。ここは線を引いておいてください。

この章の結論として、公募型の発注では「書いていないことは起きない」と考えて準備するのが安全です。柔軟性が欲しい箇所は、協議事項として明文化しておくのが唯一の逃げ道になります。

今日やる最初の一歩

まずはCMSの管理画面を開いて、固定ページ・投稿・PDFの件数を種別ごとに数えてください。その合計と数え方が、仕様書の「現行の総ページ数」に入る最初の1行になります。リニューアル全体の進め方や適切な時期の判断はホームページリニューアルの進め方と期間・頻度の判断ポイントで解説しているので、公募の前段階から整理したい方はそちらもあわせてどうぞ。

ここまで読んで、公募文書を自分たちだけで書き切るのは大変そうだと感じた方は、コレットラボのホームページ制作・運用支援にお声がけください。発注する側の立場で仕様書の抜けを一緒に洗い出すことも、提案を受ける側として要件を読み解くこともできます。まずは現状の整理だけでも構いません。ホームページ制作・運用の詳細はこちらからお気軽にご相談ください。