その場で約束せず、実装可否・追加確認・見積りへ進む順番を整理します。
クライアントとの打ち合わせ中に、
「こういう機能って作れますか？」
と聞かれることがあります。
過去に似たサイトを制作した経験があると、つい「できます」と答えたくなるかもしれません。
ただ、同じように見える機能でも、制作環境や納品条件、細かな仕様によって必要な作業は変わります。
一方で、何を聞かれても「コーダーに確認しないと分かりません」では、打ち合わせを前に進めにくくなります。
必要なのは、その場ですべてを判断することではありません。
何を確認し、どの段階でコーダーへ相談し、いつ見積りと納期を出すのか。
この順番を知っておけば、技術的に分からない要望が出てきても対応しやすくなります。
まずは見積りまでの流れを知っておく
クライアントから機能について相談されたら、基本的には次の順番で進めます。
- 要望を聞く
- 目的と実装条件を確認する
- 自分で判断できない部分をコーダーへ相談する
- 必要な項目をクライアントへ追加確認する
- 実装方法を決める
- 見積りと納期を出す
最初から全部を自分で判断する必要はありません。
ポイントは、技術的な確認が必要なところで一度止まり、そのまま金額や納期まで約束しないことです。
その場では、こう返せば大丈夫
打ち合わせ中に突然、
「これ、できますか？」
と聞かれると、その場で答えを求められているように感じることがあります。
でも、すぐに「できます」「できません」と決めなくても構いません。
たとえば、
「実装方法によって費用や納期が変わる可能性があるので、一度確認してからお返事しますね」
と伝えれば、無理に約束せずに話を進められます。
その場でもう少し情報を聞けそうなら、
「どういう使い方を想定されていますか？」
「参考にしているサイトはありますか？」
「この機能を入れたい一番の目的は何でしょうか？」
と確認します。
見積りについて聞かれた場合は、
「仕様を確認してから、正式なお見積りをご案内します」
納期については、
「実装方法と作業量を確認してから、対応可能な日程をお伝えします」
と返しておけば、先に条件を固定せずに済みます。
分からないことをごまかすのではなく、「確認してから回答する」という選択肢を持っておくことが大切です。
まず「見た目」なのか「動きや仕組み」なのかを分ける
クライアントから要望を聞いたら、
「これはデザインだけで決められることか、それとも実装方法に関係することか」
を考えます。
たとえば、画像として実装する前提のファーストビュー、バナー、背景などであれば、その場で話を進められる場合もあります。
一方で、
- アニメーション
- フォーム
- 画面遷移
- 絞り込みや検索
- ログインや会員機能
- 外部サービスとの連携
などは、ユーザーの操作やシステムの動きを伴います。
こうした機能は、実装方法によって工数や費用が変わりやすいため、技術的な確認が必要です。
全部の技術を理解している必要はありません。
「動きや仕組みが関係するなら、一度確認する」
くらいの基準を持っておけば判断しやすくなります。
「何を作りたいか」だけでなく「なぜ必要なのか」を聞く
クライアントから参考サイトを見せられて、
「こんなアニメーションを入れられますか？」
と聞かれることがあります。
このとき、URLだけをコーダーへ渡して、
「これと同じものを作ってください」
と依頼する前に、目的も確認してみます。
たとえば、
「なぜ、このアニメーションを入れたいのですか？」
と聞いてみます。
クライアントが求めているのは、本当にそのサイトと同じ動きとは限りません。
たとえば目的が、
「ファーストビューを華やかに見せたい」
ということなら、同じアニメーションを再現する以外にも方法があるかもしれません。
背景動画など別の方法のほうが、予算や制作期間に合う場合もあります。
コーダーへ相談するときも、
「このサイトと同じアニメーションにしたいそうです」
だけではなく、
「ファーストビューを華やかに見せたいそうです」
と目的まで伝えます。
何を作りたいのかと、なぜ作りたいのか。
両方が分かると、実装方法の選択肢を考えやすくなります。
実装する場所と、デザインに見えない仕様を確認する
次に確認したいのが、
どこへ、どのような条件で実装するのか
です。
たとえば、クライアントからLP制作を依頼され、設置先のURLを指定されたとします。
LP自体はこれまでにも何度も作っている。
それだけなら「できます」と答えたくなるかもしれません。
しかし、そのURLにすでにWordPressサイトが存在していたら、必要な作業が変わります。
単純にHTMLファイルをアップロードすればよいのか。
既存のWordPressへ組み込む必要があるのか。
設置環境によって実装方法が変わるため、URLを聞いたら実際にアクセスして、現在どのようなサイトがあるのかまで確認します。
WordPressなどのCMSかどうか自分では判断できなければ、その時点でコーダーへ確認すれば構いません。
フォームは「見えていない仕様」が多い
フォームも、デザインカンプを見ただけでは見積りに必要な条件が揃わないことがあります。
たとえば、
- 入力後の確認画面は必要か
- 送信完了後のサンクスページは必要か
- 各項目にどのような入力制限を設けるか
- 送信先のメールアドレスは何か
- 管理者へ届くメールの件名・本文をどうするか
- ユーザーへの自動返信メールは必要か
といった項目です。
特にサンクスページは、デザインから抜けていることがあります。
こうした部分は画面上では目立ちませんが、実装の作業量には影響します。
分からない部分だけコーダーへ相談する
ここまで確認しても、自分では判断できないことは出てきます。
その段階でコーダーへ相談します。
完璧な仕様書を作ってから相談する必要はありません。
今分かっている範囲で、
- 何を作りたいのか
- なぜ必要なのか
- どこで使うのか
- どのような動きを想定しているのか
- 参考サイトはあるか
を伝えます。
フォームなら、
- 誰が使うのか
- 何を入力するのか
- 入力後に何が起こるのか
まで分かっていると判断しやすくなります。
そこで、
「この条件なら実装できます」
と判断できることもあれば、
「ここをクライアントへ確認してください」
と追加の質問が出ることもあります。
その場合は、必要な項目だけクライアントへ戻って確認します。
デザイナーが最初からすべての確認項目を知っている必要はありません。
こうしたやり取りを重ねていくと、
「フォームなら、ここを先に聞いておこう」
「この機能なら、設置環境を確認したほうがいい」
と、自分でも判断できる範囲が少しずつ増えていきます。
条件が揃ったら、実装方法を決める
必要な情報が揃ったら、実装方法を検討します。
同じ機能でも、
- 既存のプラグインを使う
- 外部サービスを利用する
- 独自にプログラムを作る
など、複数の方法が考えられることがあります。
どの方法を選ぶかによって、費用、制作期間、納品後の運用方法も変わります。
ここで注意したいのは、
「実装できる」と分かっただけでは、まだ見積りは確定しない
ということです。
作れるかどうかだけでなく、どの方法で作るのかまで決まって、初めて必要な作業量が見えてきます。
実装方法が決まってから、見積りと納期を出す
実装方法まで決まったら、正式な見積りと納期を出します。
ここまで確認する前に、
「前にも似たものを作ったから、○万円くらいです」
「○日あればできます」
と伝えてしまうと、あとで条件が違うことが分かったときに困ります。
クライアントにはすでに約束している。
でも実際に確認すると、その金額や納期では対応できない。
その場合、間に立つデザイナー自身が調整しなければなりません。
どうしてもすべての仕様を決めきれない場合は、
「現在確認できている仕様で実装する場合は○円です。○○を追加する場合は別途見積りになります」
というように、前提条件を明示した概算見積りにする方法もあります。
細かく仕様を確認するのは、確認作業を増やすためではありません。
不確定な部分が多いほど、実装側は作業がどこまで増えるか判断しにくくなります。
反対に、見積り前に仕様が整理されていれば、何をどこまで対応するのかが明確になります。
案件が来るたびにコーダーを探さない
この流れをスムーズに進めるためには、困ったときに相談できるコーダーがいると進めやすくなります。
「この機能は自分では分からないから相談しよう」
と思ったときに、毎回ゼロから相手を探していると、急ぎの案件では時間がかかります。
実際に、
「以前お願いしていたコーダーと連絡が取れなくなった」
「久しぶりに連絡したら、今は対応できないと言われた」
「返信が遅く、クライアントを待たせている」
という相談を受けることがあります。
その結果、納期が迫るなかで別のコーダーを探すことになります。
デザイナーとコーダーの協業に、大げさな仕組みが必ず必要なわけではありません。
普段一緒に仕事をしているコーダーへ、
「今後も案件があれば相談して、長く一緒に仕事をしていきたい」
と伝えておくだけでも、次の案件で相談しやすくなります。
継続して案件を経験すれば、お互いの仕事の進め方も分かってきます。
デザイナー側にも、
「これは自分で答えて大丈夫」
「これは先に聞いたほうがいい」
「この仕様ならクライアントにここまで確認しておこう」
という経験が蓄積されます。
コーダーと協業することは、分からない作業を外注するだけではありません。
一緒に案件を進めながら、自分で判断できる範囲を増やしていくことにもつながります。
「できますか？」と聞かれたときの進め方
クライアントから機能について相談されたときは、その場ですべて答えようとせず、次の順番で進めます。
- その場で安易に「できます」と約束しない
- 「確認してから回答します」と伝える
- 何を作りたいのか、なぜ必要なのかを聞く
- 設置環境や必要な仕様を確認する
- 自分で判断できない部分をコーダーへ相談する
- 必要ならクライアントへ追加確認する
- 実装方法を決めてから見積りと納期を出す
その場で答えられなくても、案件を止める必要はありません。
私は、仕様がすべて決まったあとのコーディングだけでなく、
「この要望は実現できる？」
「クライアントに何を確認すればいい？」
「どんな方法なら予算内で実現できそう？」
という受注前の段階から相談を受けています。
「自分だけでは判断できない」と気づいたところが、コーダーへ相談するタイミングです。