ピクセルグリッドの仕事術 第1回 JavaScript開発見積もり

ピクセルグリッドはJavaScriptの開発、実装を手がけることが多いのですが、HTMLやCSSの見積もりとはやや異なる部分があります。今回は見積もりに使われる3つの方法を考察し、そのメリットやデメリットを考えてみます。

発行

著者 中村 享介 Jamstackエンジニア
ピクセルグリッドの仕事術 シリーズの記事一覧

JavaScript開発見積もりの問題点

ピクセルグリッドでは受託制作におけるJavaScriptの見積もりに悩まされていました。HTMLやCSSは以前より多くの見積もりを行っていたため、問題になることはあまりありません。

しかし、JavaScriptになると1つの機能でも制作する時間に大きく差ができ、またスタッフによっても何倍といったレベルで制作時間に違いが出ることもあります。HTMLやCSSの見積もりと同じように考えると、実情に合わない見積もりをして、大変なことになってしまいます。

ピクセルグリッドは、もともとマネジメントには関わらず、制作を中心に行っていたスタッフが多いこともあり、この部分に関するノウハウが少なかったのです。ひとたび見積もりを間違えると「金額的な赤字」や「制作者への負担」という形で問題を起こしていました。

なにを見積もるのか

見積もりと単純にいった場合、すぐに金額的なものを想像しがちですが、実際には2つの見積もりがあります。

  • 金額の見積もり
  • 作業工数の見積もり

金額の見積もりは利益に直結する話です。クライアントとしては制作をするかどうか、それによってビジネスとして成り立つかどうかの判断の重要なパラメータです。

制作側としてはもちろんきちんと対価をいただく必要があり、ただ単純に高くすればよい、安くすればよいというものでもありません。

作業工数の見積もりはスケジュールに影響する話です。こちらもビジネスとしては重要なパラメータですが、特に制作者側にとって、通常の時間で仕事を終えられるのかどうかという大事な問題になります。

見積もるのは誰?

金額の見積もりとして実際の金額を算出するのは、マネージャーなど他の人でもかまいませんが、作業工数という部分に関しては制作者自身が見積もりを出すべきです。この部分を他の人に任せてしまうと、制作者以外の他人の予測となってしまい、実際の工数が曖昧になる危険性があります。

もし工数が必要な時間より短く見積もられてしまうと、あふれた分の工数は残業や休日出勤などという形で制作者が負担することになってしまいます(クライアントが机の上の計算で引いたスケジュールは往々にして、不可能なことになってたりしますよね?)。

つまり作業にかかる時間を見積もるのは、ほとんどの制作に関わる人の必須スキルといってもいいでしょう。

3つの考え方

見積もりの2大要素「金額」と「工数」についてだいたい把握したところで、実際の見積もり手法について考えていきます。

数ある見積もり方法について大きく3種類にわけて整理し、それぞれについてJavaScriptの制作に適用できるかどうか検証してみました。

成果物単位での見積もり

この方法は「HTML1ページのコーディング=1万円」などといった方法です。デザイン系の制作会社ではDTPでページ単価いくらなどという方法で見積もっていたこともあり、この手法が採用されていることも多いように思います。

品名 数量 価格 合計
基本料金 1式 50,000 50,000
HTML作成 20ページ 10,000 200,000
消費税(5%) 12,500
総合計 262,500

この手法のメリットとしては、単価が決まっているので素早く見積もることができ、また、それなりに正確です。HTMLでいくとページのボリュームなどに多少影響はされますが、基準単価からの微調整で金額の調整ができることが多いのが特長です。工数に関しても、週にこれぐらいのペースで制作すれば納期に収まる、といった形で見積もることができます。

JavaScriptの実装には使えない

ただ、この手法はJavaScriptの実装には適用することができませんでした。いくつか機能に関して価格を設定してみたのですが、全く同じ機能を作るといったことが少ないのです。

さらに、機能が同じであっても、どんなHTMLに組み込まれるのか、他の機能と競合していないかなどにより工数は大きく変化します。機能ベースで一律に価格を設定しても、工数に見合った見積もりにならない場合もあるのです。

原価を基準にした見積もり

原価、つまり制作者の人件費を基準にコレぐらいの時間がかかるからこの値段、という手法です。いわゆる「人日」や「人月」というものです。

項目 単価 工数 合計
ディレクション 200,000 0.5ヶ月 100,000
カルーセル制作 60,000 1人日 60,000
消費税(5%) 8,000
総合計 168,000

プログラムの見積もりとしてよく使われており、開発系制作会社でよく採用されている方法のようです。また、デザイン会社でもそのような基準でデザインの見積もりを出すこともあります。

この方法は算出された金額に非常に納得感があり、見積もりを作成する時間もそこまでかかりません。原価を基準にしているので、理論上では赤字になることはありません。作業量が増え、スケジュールが延びたら、見積もり金額もその期間に連動して高くなるからです。

生産性が低いと儲かる?

マネージャーとしては夢の見積もり方法のようですが、制作者としては気になる部分が多くあります。

まず、制作者自身がスキルをあげたり、集中して頑張って仕事を片付ける、つまり2日かかる作業を1日で終らせることができたとします。すると、理論上、もらえる金額が下がってしまうのです。

2日かかる作業だと言い張れば、もちろん見積もり通り2日なのですが、それを1週間かけてやる人もいれば、3時間で終わらせることができる人もいます。プログラマはスキルによって生産性が大きくことなるのです。

そのため、この見積もり手法では、どんなに凄腕なエンジニアになったとしても、会社の売上にはダイレクトに貢献できず、むしろ見積もりを下げる結果になります*。

*注:見積もりを下げる

この場合、個々の見積もりの金額は下がりますが、時間は短縮できますから、その分、多くの案件を引き受ければ売上の総額を上げることはできるかもしれません。けれど、それだけの案件が受注できるかどうかの保証がないのが問題です。

また、この方法ですと、だらだらやったり、関わる人数を増やして、1人あたりの生産性を下げると逆に儲かります。

極端な話、1日でできる作業を2日かけてやれば、2倍お金がもらえるのです。1人でできる作業を2人でやっても同様です。

この手法はJavaScriptの開発にも適用できますが、スキルの差をどう評価し、見積もりに反映するのかというのが1番の問題になります。

価値を基準にした見積もり

これはコンサルタントが使っている方法です。

「提案した施策を実行すれば、1億円ぐらい儲けが出るから、2,000万円でやりませんか?」あるいは「年間で1億円のコスト削減になります、ですから2,000万円でどうですか?」と言われたらどうでしょうか?

例えそれがHTML数ページとJavaScriptをちょこっと作るだけだったとしても、お願いしようという気になりませんか?(この場合、自分で作れる人は頼まずに作ると思いますが、自分でできないクライアントを想定しています)

作業的にはHTMLを1ページ作ることだったとしても、それが与える価値は様々です。

例えば、同じ工数でも1日10人も見に来ない、見てもすぐ帰ってしまうようなコンテンツのコーディングと、情報として有益であり、そのページを見た人の20%は何かしら購入していく、といった場合を考えてみましょう。前者は1円の価値もなく、後者は追加される利益分の価値があると言えるのではないでしょうか。

クライアントが利益を追求するのであれば、この「価値による見積もり」は、見積もりとは本来、こうあるべきという方法ではあります。

実際クライアントの中では、発注した成果物が生み出す価値(利益)をきちんと見積もっている場合が多いでしょう。想定される利益と、制作会社が出す見積もりを見比べて考えるわけです。

利益予想ができるか?

しかし、この方法をクライアントの事業全体をコンサルティングする部署を持たない制作会社が、すんなり採用できるでしょうか。成果物の価値をどうやって正確に見積もるかが問題です。

というのも、成果物の価値は作って公開してみないと、はっきりしないことがほとんどです。事前に調査して利益を出すところまでやるとすると、かなりの知識と労力が求められることになりそうです。おそらくそれが正確にできるなら、HTMLやJavaScriptを書かなくてもご飯が食べられる気がしますね*。

*注:価値の算定

成果物の価値の算定が難しいとはいえ、JavaScriptの機能は作ったことによる価値が不明なものもときにはあります。こういった部分は常に意識しておきましょう。

クライアントの利益やそれを利用するユーザーにとって、まったく無駄だと思える機能には、工数と金額に見合わないからやめませんかと提案できるくらいになりたいものです。

ここまでのまとめ

今回は、見積もりの代表的な3つの手法をみてきました。

3つの手法

  • 成果物単位での見積もり
  • 原価を基準にした見積もり
  • 価値を基準にした見積もり

どれもメリットはありつつも、問題もあり、なかなかうまくいきそうにありませんでした。

そのため、ピクセルグリッドは、中村がこれらの方法を組み合わせ、経験と勘で独自に見積もりをしていました。

けれど、中村だけにそのノウハウが集中してしまうと、毎日のように見積もりすることになります。また、代わりに見積もりができる人がいない、スケールしない(見積依頼が増えると破綻する)という危険な状態になっていました。

次回はこれらを解決するために、ピクセルグリッドで最近始めたJavaScriptの見積もり方法を紹介します。

中村 享介
PixelGrid Inc.
Jamstackエンジニア

2009年、JavaScriptの会社として株式会社ピクセルグリッドを設立。 多数のWebリニューアル、新規立ち上げを取り仕切った経験を持ち、情報設計、フロントエンド、クラウド活用、開発フローの効率化を得意とする。 Webをより発展させるため、新しくブラウザに実装された機能の活用事例を数多く生み出しつつ、日々、クラウドサービスを利用した効率のよい制作・開発手法の試行錯誤を続けている。現在の興味はWeb Componentsを使ったマークアップの改善とJamstack。 著書に『WebクリエイティブのためのDOM Scripting』(単著:毎日コミュニケーションズ、2007年)など。ここ数年は書籍の執筆をせず、フロントエンド技術情報メディア「CodeGrid」で精力的に執筆活動を行っている。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます