大阪でWeb制作会社と協業する前に確認する顧客対応・実績掲載・納品

「先方へ直接聞いておきます」と制作パートナーが言ったとき、元請の担当者は安心して任せられるでしょうか。顧客への質問は早く進んでも、回答先、約束できる範囲、変更を決める人が曖昧なら、後で二重の説明が必要になります。納品後には、制作した画面を各社の実績として載せてよいか、どの名前を出せるかという別の確認も残ります。

大阪の制作会社やデザイナーがWeb制作を協業するときは、技術や費用の前に「元請・パートナー・顧客の三者が、いつ誰と話し、誰が何を承認するか」を一枚で確認しておくと進めやすくなります。この記事では顧客窓口、名義、連絡権限、納品範囲、実績掲載を制作工程に沿って整理します。ここでの表と架空の案件は実務を検討するための例であり、みやあじよの標準契約や個別案件の条件を示すものではありません。

顧客と同席することと、顧客への窓口を担うことは違う

みやあじよのWeb制作パートナー案内には、デザインやコーディングの部分対応から納品までの支援があり、パートナー提携の流れには顧客を交えた打ち合わせも示されています。これは案件の目的と要件を直接聞く場面があり得るという案内です。一方、どの案件でもパートナーが顧客へ単独で連絡する、見積や変更を直接確定する、実績を自由に公表するという条件までは読み取れません。実際の窓口と承認者は、案件の開始時に三者で確認します。

例えば、元請のデザイン会社が顧客の店舗サイトを受注し、Web実装をパートナーへ相談する場面を考えます。顧客の担当者が打ち合わせで「予約フォームも付けたい」と言ったとしても、それが追加見積を要する新しい依頼なのか、もとの要件に含まれるのかは、その場で決められないことがあります。パートナーは実装の選択肢を説明できても、金額、納期、契約範囲を変える回答は元請の確認を通す、という線引きが必要です。

「顧客へ話す人」と「決める人」を同じ欄に書かないのがポイントです。打ち合わせへの同席、質問メールの送信、議事録の共有、仕様の承認、費用の承認は別の行動です。案件によっては元請がすべての連絡をまとめるほうがよく、別の案件では実装担当が技術質問を直接行ったほうが早いでしょう。どちらを選ぶにしても、顧客に見える差出人と返信先をそろえます。

最初の打ち合わせで三者の連絡と許諾を表にする

次の表は、架空の店舗サイト制作を想定した確認表です。「例」と書いた担当はその案件で合意して初めて有効になります。元請、協業する制作パートナー、顧客それぞれの組織と担当者名へ置き換え、空欄を残したまま作業を始めないための下書きとして使ってください。

工程・対象	顧客へ連絡する人の例	決定・承認する人の例	パートナーが行う作業の例	残す記録・未決事項
初回ヒアリング	元請が招集、パートナーが同席	顧客が目的を確認、元請が受注範囲を確認	技術面の質問と選択肢の説明	出席者、要件、次に確認する人
仕様の質問	元請経由、または合意した宛先へ直接	元請が顧客の回答を仕様へ反映	質問案、影響範囲、代替案を用意	質問番号、回答日、承認済みの版
変更・追加依頼	顧客は元請の窓口へ連絡	顧客が変更内容、元請が費用・日程を確認	工数と技術影響を元請へ返す	変更前後、見積・日程の扱い
公開前確認	元請が顧客へ確認依頼	顧客が表示・文言を確認、元請が公開を指示	指摘の修正と動作確認	対象URL、確認版、残課題、公開判断
納品物の受領	元請が受領先と期限を伝える	合意した受領者が内容を確認	決めた形式のファイルや設定を渡す	ファイル一覧、アクセス、受領日、保守先
実績掲載	元請が顧客へ可否を確認	顧客と権利関係者が掲載対象を確認	掲載したい範囲と表示案を提出	社名・ロゴ・画面・担当表記・時期の許諾

この表には、会社名だけでなく担当者と代理人も書きます。窓口が休暇中に仕様確認が止まる案件なら、誰に引き継ぐかまで決めます。メール、チャット、会議のどれを正式な連絡として扱うかも合わせておくと、「会議では聞いたが元請へ届いていない」という状態を減らせます。とくに変更の依頼は、言われた人がすぐ制作に着手せず、元請が範囲と日程を確認する経路を表に反映します。

元請、制作パートナー、顧客の間で、質問、承認、変更、実績許諾を別経路として確認する図 — 話す経路と決める権限を、工程ごとに分けて確認します。

顧客への質問と変更依頼を同じ連絡にしない

制作中の質問には、既存の仕様を確かめるものと、仕様そのものを変えるものがあります。「営業時間の表記はこの資料が最新版ですか」は確認です。「公開前に予約機能も追加したい」は範囲の変更かもしれません。すべてを同じチャットへ流すと、誰かの「了解」が何に対する承認か追えなくなります。質問には対象ページや資料の版、回答期限、回答が必要な担当者を付け、変更の依頼には費用と納期への影響確認を付けます。

顧客がパートナーへ直接連絡できる形にする場合も、元請が見えない場所で作業を増やさない設計にします。例えば技術質問は三者が見られるスレッドで受け、パートナーは技術的に可能かを答える。見積や約束の変更が必要になったら、元請が回答する、と決めます。顧客が「できる」と聞いた時点で発注済みと受け取らないよう、回答の種類を言葉でも分けます。「実装は可能性があります。対象範囲と日程は元請から確認します」と伝えるほうが誤解を防げます。

議事録は長い全文を残すより、決定、保留、次の担当を分けて書きます。決定は承認者と日付、保留は判断に必要な資料と期限、次の担当は一人の名前を入れます。デザイン案へのコメントが複数人から届く場合は、顧客側で一本化する人も確認しましょう。競合するコメントが並んだまま制作側で多数決をすると、最終的にどの画面を承認したのか曖昧になります。

この連絡設計は、大阪で対面打ち合わせをするか、オンラインで全国の担当者と進めるかにかかわらず必要です。訪問や取材が案件に含まれるかは個別に確認します。移動が必要なら、日時や同席者、現場での撮影可否といった実務条件も先にそろえます。地域名から対応方法や費用を推測せず、その案件の進行に合わせて決めます。

名義と素材へのアクセスを、制作の前に確認する

顧客から預かる素材は、ロゴ、商品写真、社員の写真、文章、既存サイトのファイルなど性質が違います。元請が受領したからといって、パートナーが別の用途で使えるわけではありません。制作作業に必要な素材、閲覧だけでよい資料、顧客確認なしでは外部へ渡せない資料を分けます。元請は「パートナーに何を渡すか」、パートナーは「誰が見られる場所に置くか」を確認します。

CMSやサーバーのログインも、共有IDを一つ転送する前に、誰の名義で管理し、どの権限が必要かを確認します。テスト環境での画面編集だけなら、本番公開や全ユーザー管理の権限は不要かもしれません。顧客データを扱うフォームの設定や検証があるなら、閲覧できる情報と作業後の権限整理を別に決めます。個人情報保護委員会の個人情報保護法ガイドラインQ&Aは、個人データの取扱いを委託する場合、委託するデータの内容や事業の規模・性質に応じて委託先の取扱状況を把握する考え方を示しています。どのデータを誰が扱う案件か確認した上で、元請と顧客の管理方法に合わせます。

名義には、顧客へ見せる制作体制の表記も含まれます。提案資料、会議の署名、テストサイトのフッター、問い合わせメールの差出人で、元請とパートナーの関係をどう表すか決めます。パートナーが同席するとき、顧客へ会社名と担当範囲を紹介するのか、元請のチームとして紹介するのかを案件ごとに確認します。特定の呼び方や非表示を標準条件とみなさず、顧客が誰へ連絡すればよいか分かる形にします。

納品は画面だけでなく、受け取る範囲と確認方法を決める

「サイトを納品する」だけでは、公開用ファイル、デザインの元データ、画像の編集データ、CMSの設定、操作説明、保守引き継ぎのどこまで含むか分かりません。元請が顧客へ約束する内容と、パートナーが元請へ渡す内容を別々に書き、その差を埋めます。例えば元請は顧客へ更新マニュアルを渡す予定でも、パートナーへの依頼が画面実装だけなら、マニュアルを誰が作るか未決です。

まず納品一覧に、対象ページと機能、ファイル形式、受領先、保存場所、検収の担当を記入します。次に顧客が運用するために必要なものを見ます。管理画面の使い方、フォーム通知先、画像を差し替える手順、外部サービスの契約者は、制作した画面そのものとは別の情報です。テスト環境から本番環境へ移す担当、公開後の初期不具合を受ける連絡先も決めておきます。検収の返事がないときの扱いや修正回数は、各社の合意した契約・見積で確認します。

素材やコードの権利は、納品方法だけでは決まりません。文化庁の著作権契約マニュアルは、制作を依頼し報酬を払うことと著作権の譲渡を区別して説明しています。制作物や第三者素材の利用範囲、元データの引渡し、改変や再利用をどう扱うかは、具体的な契約とライセンスを見て確認します。この記事の一覧だけで権利の帰属を判断せず、判断が難しい場合は契約実務の専門家へ相談してください。

公開後の保守も納品と混ぜません。公開日まではパートナーが修正し、その後は元請が顧客の窓口になるなら、顧客からの不具合報告をどの経路でパートナーへ伝えるか決めます。保守を別に依頼するなら、連絡方法、対象作業、緊急時の扱いを別途確認します。「いつでも連絡できる」という曖昧な説明は、担当者の勤務時間や費用まで約束したと受け取られかねません。

実績掲載は社名・画面・担当表記を分けて許可を取る

案件が無事に公開されても、元請とパートナーがそれぞれ自社サイトへ載せられるとは限りません。「制作実績として紹介してよいか」という一問だけでは、顧客名、ロゴ、サイトのスクリーンショット、作業中の写真、成果の数字、元請・パートナーの担当表記、公開時期の範囲が残ります。顧客がサイト公開を承認したことと、制作会社の営業用ページへの二次掲載を承認したことも別です。

掲載案を作るときは、まず誰が許可を取りに行くかを決めます。元請が顧客の窓口なら、パートナーは掲載したい媒体、ページ、画像、文章、表記する役割を元請へ渡し、元請が顧客へ確認する流れが考えられます。顧客が匿名を希望するなら、社名を外すだけで特定できなくなるか、スクリーンショット、地域や業種、公開時期も見ます。第三者が撮影した写真や購入素材が画面に映るなら、その利用条件も確認します。

許可は「実績掲載可」の一行ではなく、許可された対象と媒体を残します。自社サイトの実績ページはよくても、SNS投稿や広告への転載は別確認が必要という場合があります。公開前の画面と公開後の画面、顧客の売上や問い合わせ数など未公表の数値も分けます。元請とパートナーのどちらがどこまで担当したかは事実に合わせて書き、共同制作という言葉だけで担当範囲を広く見せないようにします。

実績を載せない判断も選択肢です。許可が得られない案件は、無理に「匿名事例」として再構成せず、一般化した技術や進行の説明だけにとどめる方法があります。ただし、一般化しても案件が特定できる情報が残らないか確認します。許諾が未回答の間は下書きに置き、誰がいつ再確認するか記録します。担当者が変わった後に、古い口頭の了解を新しい媒体の許可と読み替えないためです。

協業相談へ持ち込む情報は、一枚の未決一覧にまとめる

最初の相談ですべての契約条項を完成させる必要はありません。ただ、元請が顧客と何を約束しており、何が未決かは示せます。案件の目的、予定する制作範囲、顧客との打ち合わせ時期、希望するパートナーの作業、公開希望日を用意します。その上で、連絡窓口、顧客への名義、変更の承認、納品物、実績掲載の五項目について「決定済み」「相談したい」「顧客確認待ち」を付けます。未決を隠さないほうが、見積や工程の前提を合わせやすくなります。

架空の店舗サイトなら、「デザインは元請、実装はパートナー」「顧客同席の打ち合わせは希望」「技術質問の直送は未決」「公開用ファイルとCMS設定は納品対象の候補」「実績掲載は顧客未確認」と書けます。この時点では顧客へ約束する文言にせず、見積と役割分担を詰めるための資料として扱います。打ち合わせ後は確認表へ担当者と期限を書き、未決の欄を埋めてから制作範囲を確定します。

協業先を比較する際も、得意な技術だけでなく、顧客を交えた確認が必要な工程を引き受けられるか、修正や公開の判断をどの経路で共有できるかを聞きます。実績掲載や権利の扱いに関する一律の条件をサイトから推測せず、案件資料を基に当事者間で確認することが大切です。最初に表を埋めれば、連絡が速いだけの進行ではなく、顧客の意思決定が残る進行にできます。