大阪でWeb制作を提案した後に、要件と追加依頼を整理する方法

大阪のマーケターやコンサルタントが顧客へWebサイトの制作を提案し、制作会社も交えて進める場面を考えます。提案時は「サービスを分かりやすく伝えるサイト」と話していても、制作に入ると、ページの追加、問い合わせフォームの変更、原稿作成、外部サービスとの連携など、具体的な依頼が次々に出てきます。口頭の提案、見積書、顧客の期待、制作側の作業表が別々のままだと、どれが当初の範囲かを誰も同じように説明できません。

この段階で必要なのは、追加依頼を一律に断ることでも、出た順に制作へ流すことでもありません。提案者が顧客に伝えた内容を起点に、今回必ず満たす要件、まだ確認していない条件、新しく出た要望を分け、顧客と制作側が影響を見て判断できる記録へ変えます。この記事は協業する提案者の視点から、その対応表と三者の確認順を示します。費用負担や契約上の義務をこの記事だけで確定するものではありません。

情報処理推進機構（IPA）は、関係者の要求を文書化し合意したものを要件と整理し、進行中の追加・変更には要求管理が必要だと説明しています。情報サービス産業協会（JISA）のプロジェクト健全性評価指標も、合意済みの基準を共有し、変更の影響と採否を関係者で判断する観点を示しています。これらは情報システム開発の資料です。小規模なWeb制作へ組織図や会議体をそのまま移すのではなく、「何が合意済みか」「変更は誰が判断するか」という実務の視点を採用します。

提案書の言葉を、そのまま制作範囲と読まない

最初に集めるのは、提案書の最新版、見積書と前提条件、顧客が承認したメールや議事録、制作側のページ・機能一覧です。提案者だけが持つ説明資料と制作側だけが持つ作業表を、同じ日付の版として突き合わせます。「サイト全体を改善する」という提案の目的は重要ですが、その一文だけで全ページの改稿や全機能の実装が含まれたとは判断できません。

一行ごとに、提案の表現、具体的な成果物、作業の前提、確認した相手を対応させます。例えば「問い合わせしやすくする」は目的であり、フォームを新設するのか、既存フォームの案内を直すのかは別の要件です。「事例を見せる」は、掲載枠を作ることと、事例の取材・原稿作成を同じ作業にしません。顧客に説明した内容と制作側が見積もった作業の間に空白が見つかったら、どちらかの解釈を先に正解とせず、確認事項として残します。

提案時の資料に書かれていないことを、すぐ「追加」と呼ぶのも早計です。提案者が口頭で約束し、顧客が承認した可能性や、見積書に含まれる前提の説明不足があり得ます。反対に、提案書の参考図に載っているだけで、実装まで合意したとは限りません。承認済みの記録と当事者の説明を照合し、当初範囲の確認が終わるまでは、料金や納期の結論を出さないようにします。

「必須」「確認待ち」「新しい要望」を分けて記す

制作に必要な情報と、制作範囲の変更は別の問題です。例えば承認済みのサービス紹介ページに載せる原稿がまだ届いていないなら、まず原稿の提供者と期限を確かめます。一方、承認済みの構成に存在しない予約機能を後から希望したなら、新たな要望として目的、利用場面、影響を確認します。どちらも「まだ決まっていない」でまとめると、制作側が見積もるべきものと顧客が提供すべきものが混ざります。

判断状態は少なくとも四つに分けられます。「承認済みで今回制作する」「今回制作するが条件が未確定」「新たに提案されたため影響確認中」「今回は制作しない」です。二番目は必須要件でも原稿、権限、通知先などが決まっていない状態です。三番目はまだ制作決定ではありません。この違いを共有すると、会議で出たアイデアがそのまま制作指示になるのを防ぎやすくなります。

顧客の要望を受けた提案者は、最初に「なぜ必要か」を聞きます。ページを増やしたい理由が既存ページの説明不足なら、文章の改修で目的を満たせる可能性があります。フォーム項目を増やしたい理由が相談の振り分けなら、社内で誰が情報を受け取るかも要件に関わります。ただし代替案を提案者だけで確定しません。顧客の事業判断と制作側の実現方法を並べてから選びます。

提案内容と制作範囲の対応表を作る

三者で一枚の表を使います。次は架空のサイト制作を想定した記載例です。実際の契約条件や作業費用を示すものではありません。具体的な金額や日程は、各案件の見積と承認手続で決めます。

表は左右にスクロールして確認できます。

「当初範囲にない」という欄だけで追加費用を確定しないでください。表は判断の入口です。制作側が必要な作業と影響を説明し、提案者が元の約束との関係を確認し、顧客が事業上の優先順位を決めます。採用しない場合も、理由と次に見直す時期を残します。保留した依頼を制作済みと誤認させないことが大切です。

表には、元資料の版と行番号を加えると後から追えます。提案書の「追加したい情報」、顧客メールの「承認」、制作会社の「作業見込み」がそれぞれ別の場所にあっても、参照先を一行に集めます。議事録は発言の記録であり、必ずしも制作着手の承認ではありません。誰の決定で状態が変わったのかを、日付とともに残します。

三者の発言と決定を混同しない

提案者は顧客の目的と提案時の説明を把握しています。制作側は実装・制作工程への影響を評価できます。顧客は自社の事業優先度、掲載内容、予算や公開時期を判断します。この三つの役割を、一人の「窓口」に押し込まないほうが、追加依頼への回答が明確になります。誰が受け取り、誰が調べ、誰が最終的に承認するかを分けておきます。

打ち合わせ中に顧客が「事例も載せたい」と話したら、提案者はその場で無料追加や公開日の維持を約束しません。まず何を伝えたいのか、既存ページで代わりに示せるか、素材の準備は可能かを聞きます。制作側へは目的と希望時期を含めて伝え、ページ構成、原稿、写真、確認作業への影響を返してもらいます。顧客には選択肢と未確定事項を示し、承認を得てから制作指示へ変えます。

反対に制作側から「この入力項目が必要」と提案が出ることもあります。技術的に作れるという説明と、顧客がその情報を業務で使えるという判断は別です。提案者はマーケティング上の狙いを説明し、顧客は受付・返信の運用を確かめます。追加の入力項目で個人情報を集めるなら、必要性と取り扱いも顧客の担当者へ確認します。制作側の便利さだけで必須項目を増やしません。

みやあじよの公開済み「Web制作の要件定義」は、依頼者と制作会社の責任分界、未決事項と変更要求、受入条件を広く扱っています。本記事の焦点は、その前後をつなぐ協業時の提案者です。提案者がどの約束を顧客へ渡し、制作側の影響回答をどう顧客の決定へ戻すかに絞ります。要件書の全項目や発注者向けの一般的な作り方は、既存記事と重ねません。

変更の影響を受けてから、費用・日程・範囲を決める

新しい依頼が出たら、制作側へ「できますか」だけを聞かず、現在の制作物のどこが変わるかを確認します。影響は追加ページだけに限りません。ナビゲーション、原稿、写真、フォーム通知、確認テスト、公開後の更新担当にも及ぶことがあります。変更の対象を一覧化し、既に承認した画面や原稿をやり直すかも示してもらいます。

JISAの評価指標は、仕様の変更と追加を分けて優先度を伝え、発注者と受託者が予算内での対応を確認することを挙げています。この考え方をWeb制作に使うなら、「今の範囲を差し替える」「範囲を増やす」「次期へ送る」といった選択肢を、費用、日程、必要な素材、確認担当と一緒に示す形です。常に追加請求になる、必ず当初見積内で収まる、といった一律の結論は出せません。

決定後は、承認した変更と承認していない要望を分け、提案書や制作範囲の最新版へ反映します。口頭で合意したつもりでも、顧客側の決裁者が未確認なら制作に進める根拠になりません。誰の承認が必要か、返信期限を過ぎた場合にどこまで進めるかを、案件の進め方に合わせて決めます。正式な契約や変更合意の方法は、個別の取り決めと担当者の確認に従います。

会議後の一通で、次の作業を確定する

会議が終わったら、要望をすべて「決定事項」として配信しないことです。「今回制作する」「影響確認中」「顧客が確認する」「次期候補」の区分を付けた短い記録を三者へ送り、認識の違いをその時点で戻します。長い議事録を読ませるより、前回から状態が変わった行だけを先頭に置くと確認しやすくなります。

その記録には、顧客へ確認したい質問、制作側が回答する影響、提案者が更新する資料を別々に書きます。回答待ちの事項には、必要な日付と、間に合わなかった場合に止まる作業を示します。期限だけを書いても、何が困るか分からなければ判断が後回しになりがちです。写真や原稿の提供待ちなら、制作側が代替素材を勝手に本番の内容へ決めないようにします。

資料の版管理も必要です。「提案書の最新版」と「制作範囲の最新版」が異なる時点なら、どちらに何が反映済みかを明記します。変更が承認されたら、対応表だけ更新して終えず、ページ一覧、機能一覧、日程、検収時の確認内容にも反映するか確認します。制作が進んだ後に古い資料が再共有されると、同じ追加依頼を再び議論することになります。

架空の二件で、判断の順を点検する

一件目は、提案書に「導入事例を見せる」と記載したものの、見積には既存事例の掲載枠だけが入っている場合です。顧客が新規取材まで含むと思っていたなら、まず提案時の説明と承認記録を確認します。取材を誰が担うか、事例企業の掲載許可はあるか、原稿の確認者は誰かを並べ、当初範囲の解釈と必要な追加作業を三者で整理します。最初から顧客の誤解と決めつけません。

二件目は、制作開始後に顧客が外部予約サービスとの自動連携を希望した場合です。予約への導線を置くことと、データを連携することは同じ実装ではありません。目的と必要な動作を顧客に聞き、制作側が接続条件や検証範囲を調べます。提案者は当初の目的との優先順位を示し、今回採用するか、別の方法にするか、次期へ送るかを顧客が判断できる材料へまとめます。

大阪の協業案件でも、提案者・顧客・制作側の役割は案件ごとに確認します。対面で三者が集まった事実や特別な地域相場を仮定する必要はありません。まず一件の提案書から、顧客に約束した内容、制作側が見積もった範囲、まだ決めていない条件を対応表へ写してください。追加依頼が来たときに「誰が、何を見て、いつ決めるか」を説明できれば、制作を始める前の判断が揃います。

参考資料

• IPA「要件定義とは？ 今さら聞けないDX関連用語をわかりやすく解説」（要件の合意と進行中の要求管理。確認日：2026年9月23日）
• JISA「プロジェクト健全性評価指標」（仕様変更・追加、ベースラインと合意形成の評価観点。確認日：2026年9月23日）
• みやあじよ「Webトータルパートナー」（協業の対象者と提案・見積りから制作への公開フロー。確認日：2026年9月23日）
• みやあじよ「Web制作の要件定義」（一般的な要件定義との対象範囲の比較。確認日：2026年9月23日）