学習が進んで制作には自信がついてきたものの、いざ「見積もりを出してください」と言われると迷ってしまう人も多いのではないでしょうか？
見積りの算出方法はいろいろあると思いますが、私は下記のような方法で計算するのは良くないと思っています。
- ページ数（トップページ、下層４ページのような）
- デザインカンプのpx数（5000pxでいくらのような）
この方法は一見分かりやすそうに思えますが、その中身にどんな要件や仕様が含まれているか全くわからないため、実際の作業時に想定外のことが出てきてしまう可能性が高くなります。
私もディレクターを担当する際に色々なケースで見積書を依頼されてきました。そのケースも踏まえながら、私が見積もり作成時に気にしていることを共有させていただきます。
何のための見積もりか？
制作の相談をされて見積書を作りましょうとなる前に、この案件はクライアントの中で現在どういう状況になっているのかを確認しておくと良いでしょう。
確認しておくことで発注確度の把握ができ、リソースの準備も前もってできるので下記を確認しておくと良いでしょう。
- 案件のステータス
予算を取るための見積もりなのか、すぐにでも着手したいので早く知りたいのか など。 - 競合の有無
相見積もりの場合は見積書の精度は高い方が良いでしょう。 - スケジュール
納期が決まっているのであれば早く動く必要もあります。 - 上限の予算が決まっているか
安すぎて到底できないものは見積もりするまでもなく断ることも大事です。
見積書を出すのはいつ？
まず悩むのが、見積書はいつ出すのか？
過去に見積書を作らずにプロジェクトをすすめ、制作後にお金の話をするという案件もありました。こうなった時、客先も想定外の金額を請求されて困る、こちらもかかった工数・外注費が回収できないということもあるので、なるべく避けたいケースです。
お金の話は逐一しているほうがいいと考えています。見積書を出すタイミングを３パターンで整理しまてみましょう。
概算見積もり
プロジェクトによっては初めの打ち合わせで「概算金額で、どれくらいかかりますか？」と聞かれることもあります。適当な金額を言ってしまい後で正式な見積もりを出した時にビックリされることもあるので、クライアントとの認識に大きな誤差が出ないように気をつけましょう。
経験がある人であれば打ち合わせの内容でその場で回答してレスポンスよく仕事ができますが、自信がない方は一度持ち帰って翌日に報告するようにした方が良いでしょう。
その他、概算見積もりで気をつけたい点は下記になります。
- あくまで概算見積もりで正式なものではないことをクライアントに念押し
- 概算から正式な見積もり作成までのフローを共有
提案見積もり
初回の打ち合わせで聞いた内容（もしくは要件定義書）をもとにワイヤーフレームの制作に入ります。この時点でプロジェクトの要件や仕様をまとめて、そのワイヤーフレームの内容をもとにこちらから客先に提案するときの見積書を作成します。
ワイヤーフレームで画面構成を共有し、細かい仕様については仕様書にまとめて画面や機能毎に工数を計算して見積書に仕上げていくのが良いと考えています。
この詳細については後述する、デザインとコーディングそれぞれの見積もり方法について記載します。
ここで作った資料をもとにクライアントに提案する打ち合わせを設定し、共有した内容でこの金額になりますという金額を伝えましょう。
この打ち合わせで要望の増減があることが多いので、その後に作るのがこの後に紹介する精査見積もりです。
精査見積もり
提案見積もりを提示した後に要望の追加や削除を受けたら、ワイヤーフレームや仕様書を修正して最終的に合意するための見積書を作成しましょう。その見積書の内容で客先から発注書をもらったら制作スタートです。
この時点で作っている資料の精度やクライアントのやりとりが上手くできていることで、制作がスタートしてからの仕様変更で追加費用が発生する事態になったとしても、クライアントに理解してもらい易い状況が作れているはずです。
なお、制作を開始してから減額することは基本的にありません。発注書を受理したあとクライアントの一方的な理由で仕様変更や減額を要求されることは、場合によっては下請法に抵触するのでご自身と企業の間ではどのようになるのか理解しておく方がいいでしょう。
各作業パートの見積もり作成
ここまで見積りの流れを説明してきましたので、次は実際に見積書の金額をどう作っていくかを整理していきます。プロジェクトの規模によって作業パートは増えていきますが、ここでは小〜中規模開発を想定し、デザイン、コーディング、ディレクションに分けて説明していきます。
デザインやコーディングの制作パートについては、精度を上げるために細かく見ていきましょう。最小単位をコンポーネントとして設計、仕様をまとめるのがいいでしょう。
単位、コンポーネントの考え方
ワイヤーフレームをもとにどれだけのデザイン量があるのかを洗い出し、工数に落とし込んでいきます。先述したコンポーネント単位での考え方ですが、単位の大きなところから分割していくと下記のようになります。
- ページ
トップ、会社概要、お問合せフォーム、採用ページなど - セクション
ヘッダー、フッターなどの共通パーツ、ページ毎のセクション - コンポーネント
ハンバーガーメニュー、フォームのパーツ、見出しの種類、カード型のリンク、ボタン、表組みなど
デザイン
ページ、セクション、コンポーネント単位に分け、デザインする量を算出して工数に落とし込みます。デザインは量が見えたからといってどれくらいの時間がかかるかは見えにくいので、サイト全体のトンマナや大枠のレイアウトなどの工数は別で見た方がいいでしょう。
私が工数を計算する項目は下記の通りです。
- グローバルデザイン
トンマナ、サイト全体のレイアウトなど - イラスト作成や写真の加工
- ページ、セクション、コンポーネントのデザイン
定量的な制作工数に合わせて、制作の工程でどれくらいの作業量が発生するかも合わせて見ていきます。スケジュールにも関係し、この合意がクライアントと取れていないと後々揉めてることが多いので、見積り時点でしっかりと理解してもらいましょう。
- デザインは何案つくるか、どこまで作るか（トップページのみやファーストビューのみなど）
- 修正の回数
よく客先に提案する流れとしては、デザイン案はトップページのファーストビュー＋１セクション、案は２つ作りどちらかの案をもとにページ全体を作っていき、修正は１〜２回（１回が多い）としています。
コーディング
デザイン同様にページ、セクション、コンポーネント単位に分けたものから、実装にかかる工数を算出していきます。コーディングの場合は下記の点を気をつけて考えるのがいいのではないかと考えています。
- HTMLとCSS分割して考える
- JavaScriptも一つの機能ごとに分ける
- テストや動作確認の工数も明確に
- クライアントに見せるかは別として、修正の時間も確保しておく
コーディングはテストやチェックの段階で思わぬことが出てくることがあります。自身が確認しているブラウザ以外の動作をクライアントから指摘されたり、コーディング完了した段階でデザイン修正が入ったりすることもあるので、スケジュール上の修正期間はゆとりをもって設定しておくことをお勧めします。
ディレクション
ディレクションの価格は単純に制作費全体の２割くらいを設定して出していましたが、担当する範囲によっては作業別に切り出した方がいいこともあります。２割に含まれるものとしては
- 進行調整
- ワイヤーフレーム作成
- 打ち合わせ
- ドキュメント作成（どこまで作るか線引き必要）
- 書類業務（契約書、発注書、請求書など）
などがあります。追加分として考えられるものは
- 原稿作成
- 上記線引き外のドキュメント作成
- コンサルタント
などが挙げられます。よく制作前の相談は無料で行っていましたが、結局いつまで経っても発注に結びつかない場合があります。顧客によって様々ですが、プロジェクトの内容を見極めて企画段階のディレクションについては別途コンサルタント料を請求した方がいい場合があります。
クライアントになかなか言いづらいことですが、自身の利益を損ねすぎると赤字になってしまうこともありますので気をつけましょう。
目安としては自身の利益２割ほどは営業費とし、それ以上工数がかかるものに関しては手を引くか、費用を請求できる方が健全かと思います。
バッファの設定を忘れずに
見積書の時点で決まった工数で全てがうまくいくのが一番ですが、途中で要件や仕様が変更になったり、追加のページが出てきたりするのは良くある事です。
その都度、追加見積もりが発生してしまうと進行に遅れが生じたり、クライアントの予算が確保できないといったリスクがあります。
見積もりにバッファを設定しておくことで様々な変更があっても、その工数内が柔軟に対応することが可能です。
私は見積もり時に必ずバッファの工数を見積もるようにしています。算出の仕方としては見積書を提出段階でどれだけ内容が精査できているか、クライアント側の検討事項に不安要素が残っていないかなどを話し合いの中から読み取って決めるのが良いでしょう。
だいたいですが全体の１割前後をバッファとして見積もり、スケジュールとしてはとしては１〜２割くらいの余裕を持っているのが良いんじゃないかと思います。
予実の管理で精度を高める
初めから予想通りの工数見積もりを作るのは不可能でしょう。自分の作業スピードは経験によって何が、どのくらいの時間で出来るかがわかってくるものなので、より正確な見積書を作るためには見積もった工数と実際の工数の差分をチェックする必要があります。
この時にコンポーネント単位で別れていると、どこで遅れていたのかの原因がわかりやすくて次回に活かせます。
デザインにしてもコーディングにしても振り返りはとても大切なことなので、今後の仕事のためにも制作チーム全員でその内容を共有しましょう。とくにディレクターの方には大体の工数感を掴んでもらうためにも必要なことだと思いますので、率先してその場を設けるように働きかけましょう。
終わりに
この見積もりを実際に作るときにはスプレッドシートに簡単な仕様や作業の想定を記載しながら作っていきます。
私が作っているものでもし要望があればサンプルとしてお渡しさせていただきますので、欲しいという方はTwitterでDMいただければと思います。
ここまで読んでくださり、ありがとうございました。
コメント