freshtrax

ビートラックスがサンフランシスコから最新情報を配信中

  • Brandon K. Hill

    Brandon K. Hill

    CEO of btrax, Inc

    CEO of btrax, Inc - Design Mentor to Startup Weekend - Contributor to TechCrunch Japan - Guest Speaker at UC Berkeley Asia Business Conference - Guest Speaker at Social Media Week Tokyo - Guest Speaker at 500Startups Japan Day

  • → 記事一覧

    • このエントリーをはてなブックマークに追加
    • follow us in feedly
  • Apr 23, 2017

main-pic

見積もりはどのように出すのが最も合理的なのか?

皆さんはデザインや開発などのプロジェクトに対して、どのような見積もりを出しているだろうか?おそらく日本では”制作業務”として認識されるか”コンサル業務”として請けるのか、もしくは”顧問契約”になるのかによってその方法は様々であると考えられる。ざっと想像してみても下記のような見積もり方法があるだろう。

一般的な見積もり算出方法

  • 人月単位
  • 時間単価換算
  • プロジェクト単位
  • クライアントの予算
  • 期間ベース
  • 納品ベース
  • 成果報酬
  • サービス提供側の言い値

しかしどれをとっても、何が”正しい”かがはっきりとしないし、実はベストのものはない。それぞれに弱点があるのだ。

それぞれの見積もり方法の弱点

では、上記の異なる見積もり算出方法で弱点をみてみたい。

人月/時間単価換算の弱点

予想以上にプロジェクトが長引いた際にクライアントが納得しにくい。多くの場合コミニュケーションや手戻り作業に時間が費やされるが、これを見積もりとして事前に算出するのが非常に難しい。多くの場合、クライアント都合で想定以上に時間がかかったとしても、追加チャージができないために強引に当初の時間数に収めようとして作業に無理が生じる。

プロジェクト単位

クライアントからみると何に何時間かかるかよりも、サービスの提供内容 = プロジェクト単位での見積もりが合理的に感じられる。しかしサービス提供側はプロジェクトをスタートしてみてから想定していなかった作業やニューキャラの登場で実際の作業時間が大幅に変化し、場合によっては赤字になる可能性もある。

クライアントの予算

大企業の場合、事前に予算が想定されており、その範囲内での作業が期待されるケースも少なくはない。その場合、プロジェクトの見積もりは、つじつま合わせの「後付け」でしかなく、実態が無いに近しい。サクッと終われば利益の高いプロジェクトになるが、手こずるとアリ地獄にハマる可能性もある。

期間ベース

アメリカで最も一般的なのがこれ。リテイナーとも呼ばれる方法で、プロジェクトの概要とチーム編成をざっくりと決め、1ヶ月分の費用x月数で算出する。言い換えると納品物ベースではなく、作業ベースで見積もり、請求を行う。日本でもコンサル系のサービスはこの方法を取っているケースが多い。提供側からすると売上が安定するのでありがたいが、クライアントとしては「本当にちゃんと結果を出してくれるのか?」という疑問が残ってしまう。

納品ベース

日本の商習慣における最も悪しき習慣がこの納品ベースでの見積もり、支払い文化であろう。納品されるモノの対価に対して価格が算出されるという、まさに「下請け」扱いのロジックで現代にあっていない。ハードウェアでもソフトウェアでも、Webでもアプリでも「リリースしてからが勝負」であり、全てのサービス化が進んでいる今の時代では「完成」という概念自体が時代遅れで、この方法は全く非合理的である。

成果報酬

できたモノのクオリティーやそこから生み出される結果で金額が変わる方法。例えばECサイトを制作した場合、そこから生み出される金額に応じて支払額も変化する。クライアントからすると一番理にかなっているが、提供側にとってはかなりリスクが高い方法である。そして一番の問題は、良い結果が出た際にそれが「誰のおかげ」かで揉めるケースもある。一見最高の方法のように感じるが、実は双方の信頼関係がかなり高く無いと成り立たない。

サービス提供側の言い値

世界的に著名になった個人や企業に仕事を依頼する際には、サービス提供側が自由に金額を決めることになる場合がある。例えば一流のハリウッドスターに出演をお願いした場合がこれ。クライアント側に値段の交渉する余地がほとんど無い。サービス提供側からすると最強の状況であるが、そもそもそのレベルに到達できるのはトップの数%ほどしかいないので、あまり現実的では無い。

最も意味がないのは”単価 x 費やす時間”

提供側からするとプロジェクトに掛かる時間を算出し、それに時間単価を掛け合わせて算出するのが最も合理的に感じられる。しかし実はそれが最も意味がない。そもそも誰がどのようにして単価を設定するのか?そして掛かる時間は?

クライアントにとってみれば、だらだらと長い時間を掛けられるよりも、早いスピードでプロジェクトを完了してもらった方が助かる。しかしそれだと、求める結果と金額が反比例することになる。後から単価を変えるわけにいかないからだ。

30秒の作業に100万ドルを請求したピカソ

以前に「ピカソが30秒の絵に100万ドルを請求した」という話を読んだ事がある。とある人がピカソに紙にさらっとスケッチを描いてもらった。30秒程度で描いたのに彼はその作品に100万ドルを求めた。「30秒しか掛かってないのに」と主張する依頼者に対してピカソは「30年と30秒ですよ」と答えたという。

そう、例え30秒しかかからなかった仕事であったとしても、その裏にはその技術を身につけるまでに費やした経験と技術がある。特にクリエイティブ系の仕事においては、その作業”自体”にかかる時間はあまり意味をなさない。したがって、見積もりを出す際にも、時給 x 費やす時間で換算するのは全く意味がない。

実はサービス提供側からすると最もコストに影響するのはクライアントとの関わり方

実は、サービス提供者側から考えてみると、ぶっちゃけ案件の内容よりも、やりとりしやすいクライアントであるかとか、クライアントの知識レベルによって掛かってくる負荷が大きく変わるからだ。以前の記事「クライアントには絶対に聞かせられないデザイナーの本音」でも、デザイナーの本音として下記を紹介した。

デザイナーの本音ベースの価格表:

  • 私が全てデザインしますのでお任せ下さい: 1万円
  • 私がデザインしてるのをご覧頂けます: 2万円
  • お客様のアドバイスをベースに私がデザインします: 3万円
  • お客様の助けを借りながら私がデザインします: 5万円
  • お客様がデザインし、私がそれを助けます: 8万円
  • お客様がデザインし、私がアドバイスします: 13万円
  • お客様がデザインし、私がそれを見ています: 21万円
  • お客様のデザインアイディアを実現すべく作業します: 34万円

このように、同じプロジェクトと成果物でもクライアントとの関わり方一つで何倍もチャージしたい気分なのである。なので成果物ベースもあまり合理的ではない。

大きく異なるクライアントとサービス提供者側の意識

その一方で、クライアント視点で考えると「なぜこの作業にこれほどかかるか理解ができない」と思われるケースも少なくはない。サービスはものを売るのとは異なり、似たようなプロジェクトであったとしても、それぞれの異なる様々なファクターが関わり、そこに掛かってくる労力 = コストが大幅に変化する。

クライアントからすると「シンプルで簡単」と思われる内容でも、そこにたどり着くまでには多大なる苦労が伴うこともある。多クライアントに原因があるケースがほとんどであるが…。逆に「非常に難易度が高そうだ」と思った仕事が、先方の担当者のおかげで意外にもスムーズに進むこともある。そんなこともあり、見積もりを出す方としては、その数字自体ににあまり実態はないのが本音ではないだろうか?

クライアントと提供者の間ではまだまだプロジェクト費用に関しての意識のギャップがある。

双方にとって最も合理的な見積もりの算出方法

では、どのような方法で見積もりを出すのが一番良いのだろうか?冒頭のいくつかの方法の全てに弱点がある。実は双方にとって合理的であり、そして理にかなっている方法があるのだ。その方法とは:

そのプロジェクトが与えるインパクトの大きさ

に合わせて見積もりを算出する方法である。

プロジェクト費用は支出では無く投資

この方法を理解する際には、まず下記の事柄を想定してみてほしい。

  • 200万円を得るための80万円は安い
  • 10万円の効果しかないのであれば、20万円は高い

そう、例えそれが同じような内容の作業であったとしても、そこから生み出される価値によってはそこに費やすべき金額が変わってくる。言い換えると、費やす金額が妥当かどうかはそのリターンで大きく変わるのだ。その費用が高いか安いかは絶対的なものではなく、その結果によって相対的に変わってくる。

まずはクライアントの視点で考えてみる

では、これをプロジェクトの見積もりとして考えてみよう。特にクライアント視点で。彼らにとって最も重要なのは、頼んだ仕事を通じて得られる結果であり、ぶっちゃけどのように見積もりが算出されているかを知る必要はな無い。乱暴な言い方をすると、何人のスタッフがどのくらいの労力を投じているかは関係ないのだ。

どれだけ必死に徹夜で仕事をしようが、結果が出ないのであれば、お金を払う価値がない。逆に、実はかなり楽をしてサクッとプロジェクトが進んでいるとしても、大きなリターンを生み出しているのであれば見積額が高くてもその価値は大いにある。

これは”ミラリング”という方法で、サービスを受ける側から物事をみる = 鏡に写してみる事でより合理的な方法を見つける事ができる。

見積もりはそのインパクトに比例して変えるべき

例えそれが同じような仕事内容のプロジェクトだったとしても、A社に提供する場合とB社に提供する場合でそこから生み出されるインパクトが異なるのであれば、見積もり金額が大きく異なっていてもクライアント視点で考えれば理にかなっているかもしれない。

同じ仕事内容でも案件によって異なる影響力

それでは具体的な例として、ブランディングに関するプロジェクトを例にとって考えてみよう。とある高級ホテルチェーンのリブランディングの仕事。このプロジェクトの見積もりを出す際には、その影響力を算出してみるのが良い。一つの目安として、そのホテルチェーンの部屋全部が稼働している一晩の売上は:

25,000円 (部屋の平均単価) x 2,000部屋 x  1 = 5千万円

となる。この場合、リブランディングを行う事で、一晩分の全稼働するぐらいの結果を生みだす事ができるのであれば、5千万円の見積もりは妥当だと言える。言い換えるとクライアント側から見て、プロジェクトに費やした費用を取り戻すには、一晩全稼働を実現すれば良いのだ。

これが同じようなプロジェクト、同じ業界だったとしても部屋単価1万円、部屋数500の格安の小規模ホテルの仕事の場合、下記のように算出される。

10,000円 (部屋の平均単価) x 500部屋 x  1 = 500万円

このように同類のサービスを提供したとしてもその影響力には10倍の差が生まれ、よって見積額にも10倍の差が出るのはいたってロジカルである。

絶対的な作業金額よりも費用対効果による相対的な価値で算出するべき

今回はホテル業界に対してのブランディングの仕事を例にとって考えたが、これは業界やサービス内容が変わっても同じく利用できる方法である。同類のサービスであったとしてもそこから生み出されるであろう影響力 = サービス価値の大きさによって見積額も変化させるべきである。

これは一見かなり乱暴で非誠実な方法のように感じられるかもしれないが、クライアント視点から考えると非常にロジカルである。実はこの方法を以前より業界のスタンダードとして適用してる業界がある。フォトグラファーである。

写真の業界での一般的な費用算出方法は、そこに費やされる労力に加えて、撮った写真がどのように利用されるかによってその金額が大きく変化する。Webだけなのか、プリントにも使われるのか、TVや大きな広告キャンペーンにも活用されるかにおいてその費用は何十倍にも膨れ上がる。

また、京都のお茶屋なんかのお花代も一定の金額が決まっているわけではなく、そのお客さんによって大きく変動するという。これも、そのサービスを受けた人にとっての価値を基準としている事から考えてみると、意外と合理的なのかもしれない。

日本もそろそろ人月換算をやめないか?

このように、これからはデザイン会社や開発会社も見積もりを算出する際には「それが生みだす価値」を念頭に考えるべきである。しかし、サービス提供側からすると「そんな事言っても今の日本では通用しないです」と思うかもしれない。しかしあなたたちがこの方法を進めていかない限り、世の中の商習慣はいつまでたっても変わらないままだろう。

この辺の日本とアメリカにおけるサービスに対する意識とクライアントとの関わり方の違いに関しても来月24日に開催される『DESIGN for Innovation 2017』にてご紹介する予定である。

筆者: Brandon K. Hill / CEO, btrax, Inc.

Like us on Facebook

Scroll to top

シリコンバレーから最新情報をゲット!

 

btrax-logo-100

サンフランシスコに本社を構えるクリエイティブエージェンシーbtraxのニュースレターに登録して最新の情報をいち早くゲットしませんか?

 

・オウンドメディアfreshtrax 今月の注目記事

・CEO Brandonの無料オンラインセミナー情報

・最新サービス・現地イベント情報

 

Subscribe!
Twitterで共有
Facebookで共有
はてなブックマークに追加
pocketで共有
Lineで共有