未確定事項を残したまま赤字にならないための、確認項目と見積りの考え方を整理します。
Web制作では、すべての仕様が決まってから見積りを求められるとは限りません。
「ページ数しか決まっていない」
「参考サイトはあるけれど、デザインはこれから」
「WordPressで更新できるサイトにしたい」
そんな段階で、
「だいたいいくらくらいになりますか？」
と聞かれることもあります。
仕様が決まっていないからといって、見積りを断る必要はありません。
ただし、分からない部分をこちらの想像で埋めて固定金額を出してしまうと、受注後に想定以上の作業が発生しても追加料金を請求しづらくなります。
大切なのは、最初からすべての仕様を決めることではありません。
何が決まっていて、何がまだ決まっていないのか。その状態で、どこまでなら工数を算定できるのかを整理することです。
概算を出せるかは「工数を算定できるか」で判断する
仕様が未確定でも、作業量を想定できるなら概算は出せます。
たとえば、ページ数だけが決まっている案件でも、
「1ページあたり、この程度の長さ・構成を想定する」
という前提を置けば、
「全○ページ、1ページあたりこの程度のボリュームを想定した場合」
という条件付きで概算できます。
ワイヤーフレームまであれば、ページごとの長さや構成が見えてくるため、さらに精度を上げられます。
参考サイトしかない場合も考え方は同じです。
参考サイトを見ながら、
- ページ数
- 1ページあたりの長さ
- レイアウトの複雑さ
- アニメーションの有無
- フォームなどの機能
を確認し、
「この参考サイトと同程度の構成を想定した場合」
という条件で概算します。
私が見積れるかどうかを判断するときの基準は、
工数を算定するための前提を置けるかどうか
です。
反対に、
「WordPressで更新できるようにしたい」
だけでは、まだ工数を出せません。
たとえば、
- お知らせだけを更新できればよいのか
- 固定ページの文章や画像もクライアント側で変更したいのか
- 商品や実績のように、項目を追加して一覧・詳細ページへ反映させたいのか
によって実装内容は変わります。
「診断機能を付けたい」という依頼も同じです。
- 質問はいくつあるのか
- 回答によってどのように分岐するのか
- 結果は何種類あるのか
- 管理画面から内容を変更する必要があるのか
ここまで分からなければ、必要な作業時間を算定できません。
判断基準は、
「仕様が完成しているか」ではなく、「金額を出せるだけの前提がそろっているか」
です。
仮定した条件は、見積書の中に残す
条件付きで概算を出す場合、その条件は必ず見積書に残します。
たとえば、
- 「お知らせのみクライアント側で更新する仕様を想定しています」
- 「固定ページを管理画面から変更する機能は含みません」
- 「アニメーションは参考サイトと同等ではなく、基本的なフェード表示を想定しています」
- 「詳細仕様確定後に再見積りします」
- 「上記以外の追加作業は別途お見積りとなります」
といった書き方です。
理由は、その金額を出した根拠を見積書そのものに残すためです。
口頭で、
「これは入っていません」
と伝えるだけでは、あとから確認しにくくなります。
チャットに残していても、やり取りが何週間、何か月と続けば、ほかのメッセージに埋もれてしまいます。
また、コーダーからデザイナーへ伝え、さらにデザイナーからクライアントへ説明してもらう場合、途中でニュアンスが変わることもあります。
最終的に見積内容を確認するのはクライアントです。
だからこそ、
金額と、その金額が成立する条件を同じ書類に残しておく
ことが大切です。
見積書は、金額を知らせるためだけの書類ではありません。
「この金額で、どこまで作るのか」を双方で確認するための書類でもあります。
工数が大きく変わる未確定事項から確認する
未確定事項が、すべて同じリスクを持っているわけではありません。
文章の一部がまだ完成していない程度なら、コーディング工数にはほとんど影響しないこともあります。
一方で、次のような項目は、決まり方によって工数が大きく変わる可能性があります。
- 誰が、どこを、どのように更新するのか
- 既存WordPressのテーマやテンプレート構造がどうなっているのか
- 外部サービス側でどこまで設定できるのか
- 会員・予約・決済機能で、どのような画面や処理が必要なのか
- 「参考サイトと同じように」の「同じ」がどこまでを指すのか
たとえば、
「この参考サイトと同じようなサイトを作りたい」
と言われたとします。
この場合は、まず「どこを同じにしたいのか」を確認します。
- デザインの雰囲気だけなのか
- ページ構成も同じなのか
- スクロール時のアニメーションも再現するのか
- フォームや検索などの機能も必要なのか
ここを確認しないまま、
「それなら○万円くらいです」
と固定金額を答えてしまうと、あとから対象範囲が広がる可能性があります。
分からない項目が複数あるときは、すべてを同じ細かさで確認するのではなく、
決まり方によって金額が大きく変わるものから先に確認する
と進めやすくなります。
「分からないから20％上乗せ」ではなく、条件ごとに金額を分ける
仕様が決まっていないと、
「念のため20〜30％くらい多めに見積っておこう」
と考えたくなるかもしれません。
私は、基本的にこの方法を取りません。
できるだけ仕様を明確にし、その内容に対して金額を算出したほうが、見積りの根拠を説明しやすいからです。
どうしても仕様を確定できない場合は、適当に余裕を乗せるのではなく、金額に幅を持たせます。
ただし、
「だいたい10〜20万円です」
だけでは不十分です。
なぜ10万円で済む場合があり、なぜ20万円になる可能性があるのかまで説明します。
たとえば、
「既存プラグインで対応できる場合は10万円前後。独自実装が必要な場合は20万円前後になる可能性があります」
という形です。
そのうえで、
仕様が確定した時点で正式に見積り直す
ことも伝えます。
不確定なことが多いほど、見積る側は想定できない作業のリスクを考えなければなりません。
反対に、
「ここまで作れば完成」
と分かれば、その作業だけを見積れます。
「仕様を決めてください」
と制作側の都合だけを伝えるのではなく、
「ここを決めてもらえれば、余分なリスクを含めずに見積れます」
と説明したほうが、相手にも仕様を決める意味が伝わりやすくなります。
見積りのための確認が「技術調査」になることもある
通常の見積りであれば、ページ構成やカンプ、希望する機能を確認して金額を算出できます。
しかし中には、見積りを出すためだけに何時間、場合によっては何日も調査しなければならない案件があります。
たとえば、
- 既存WordPressの中身を調べなければ、どのように改修できるか分からない
- 外部APIの仕様を調べなければ、連携できるか判断できない
- 既存プログラムを解析しなければ、変更箇所を特定できない
といったケースです。
ここまでくると、見積り前の簡単な確認ではありません。
技術調査そのものが一つの作業です。
私は、このような場合は有料調査を提案します。
もちろん、調査をせずに概算を出す方法もあります。
ただし、その場合は分からない部分を仮定して金額を出すことになります。
そのため、
「調査をしない場合は、この条件を仮定した概算になります。正確な金額を出すには、先に既存環境の調査が必要です」
と分けて説明します。
一見すると、調査費を払うぶん高くなるように感じるかもしれません。
しかし、分からないリスクまで制作費に含めて見積るより、先に不明点を調べ、必要な作業だけを見積ったほうが結果として総額を抑えられる場合もあります。
「とりあえず総額を」と言われたら、仮の条件を置く
クライアントから、
「細かい仕様はあとで決めるので、とりあえず総額だけ教えてください」
と言われることもあります。
この場合も、無理に固定金額を出す必要はありません。
まず、決まっていない部分に仮の条件を置き、その条件に対する概算を出します。
たとえば、
「お知らせのみクライアント側で更新できる仕様を前提として、○円〜○円」
とします。
そのうえで、
「固定ページも管理画面から変更できるようにする場合は別途」
と書きます。
これなら、クライアントは予算感を確認できます。
制作側も、まだ決まっていない仕様まで最初の金額で引き受ける必要がありません。
概算とは、何となく丸めた金額ではなく、仮の条件に対して算出した金額です。
着手後に決まった仕様をどう扱うか、先に決めておく
仕様が未確定の案件では、受注後の線引きも重要です。
制作途中で新しい仕様が決まったとき、
「それも最初の金額に入っていますよね？」
という認識の違いが起こることがあります。
だからといって、着手時点で分かっていることを何十項目も仕様書に列挙するのは現実的ではありません。
そこで私は、
「着手時点で決まっていなかった仕様は、仕様追加として追加料金の対象となります」
という考え方を見積書に入れています。
たとえば、着手時点では
「お問い合わせフォームを設置する」
ところまで決まっていたとします。
制作開始後に、
「問い合わせ内容によって担当部署へ自動で振り分けたい」
という要望が追加されたのであれば、新しい仕様として扱います。
判断するときの基準は、
「見積書に一字一句書いてあったか」
ではなく、
着手時点でその仕様が決まっていたかどうか
です。
未確定事項がある案件だからこそ、どこからが追加になるのかを見積り段階で共有しておく必要があります。
仕様だけでなく「いつまでに決めるか」も決めておく
以前、制作会社から、納期と予算だけが先に決まっている案件を受けたことがあります。
ところが、制作会社側での要件定義や人員確保が遅れ、デザインの確定も遅れていきました。
納期だけは変わりません。
結果として、デザインもコーディングも見切り発車せざるを得ない状態になりました。
このような案件では、下流のデザイナーやコーダーだけが頑張っても解決できません。
上流工程で確認が止まれば、その分だけ後工程に使える時間が削られていくからです。
たとえば、クライアントへカンプを提出するとき、
「お時間のあるときにご確認ください」
とだけ伝えると、クライアントから見れば「急がなくてもよい確認」に見えるかもしれません。
しかし、その返事を待っている制作側には納期があります。
そのため、
「○月○日までにご確認ください。以降になる場合は、公開日をご相談させてください」
のように、確認期限まで伝えておく必要があります。
技術仕様が未確定の案件では、
何を決めるかだけでなく、いつまでに決めるかも制作スケジュールの一部
です。
未確定案件を見積るときの進め方
仕様が100％決まるまで、見積りや受注を待つ必要はありません。
未確定事項があること自体が問題なのではなく、未確定な部分を見えないまま金額だけ確定してしまうことが問題です。
見積りを作る前に、まず次の3つへ分けます。
- 決まっていること
- 決まっていないこと
- 決まり方によって金額が大きく変わりそうなこと
そのうえで、
- 工数を算定できる部分は見積る
- 未確定部分には仮の条件を置く
- 仮定した条件を見積書に残す
- 工数が大きく変わる項目から優先して確認する
- 技術調査が必要なら、見積りとは分けて扱う
- 着手後に決まった仕様をどう扱うか決めておく
- 仕様の確定期限もスケジュールに含める
という順番で整理します。
自分だけでは技術的に判断できないものがあれば、金額を出す前にコーダーへ確認します。
仕様が決まっていなければ、
「ここはまだ決まっていません」
と伝える。
条件によって金額が変わるなら、
「この仕様ならこの金額です」
と伝える。
未確定事項を無理になくすのではなく、未確定のまま見えない状態にしない。
それが、仕様の固まっていない案件でも赤字を防ぎながら見積るための基本です。