※長いのでtl;drだけチラ見することを推奨します※
※勢いで書いた部分も多いので、指摘あればマサカリ投げてください…※
tl;dr
- なぜ顧客がその案件が実施したいのか、そのためにどれくらいの金額をかけてよいのかを想定することは見積において金額感を想定する上で重要
- 作業スコープを維持しながら見積金額を下げる(見積単価を維持しつつ)ためには、いわゆる作業効率を上げることが必要で、そのためにはチームとしての技術力向上や付加価値向上を目指す仕組みが必要
- そもそも人月による見積だけに依存せず、サービスやパッケージを構築し、価値提供ベースの見積に移行していく下準備が必要
前提
- クラウド(AWS)アプリ開発をメインにしている部署のメンバー視点のお話
- 見積は人月単価×工数見積
あらまし
夏頃のお話。グループリーダから"営業から新しいクライアントの提案したいから提案資料(システム構成案や工数見積含む)を作ってほしい"との依頼がありました。(他の会社にも見積お願いしているとも聞いていました。)
要件としては以下のような内容でした。
- 業務要件
- 現在、手作業でおこなっている作業をシステム化し、工数削減したい
- 今後、サーバレスなどのクラウドアプリ開発の知見を蓄積し、内製化できるようにしたい
- システム要件
- サーバレスをベースとしたWebサイトの構築 w/クライアントの開発部門
- サーバレスに関するナレッジトランスファー (以降KT) to クライアントの開発部門
要件を確認して、概ね以下の構成での見積、提案を作成しました。
- システム構成
- Frontend: AWS S3+CloudFront+Cognitoなどを使用。言語はReact
- Backend: API Gateway+Lambda+SQSなどを使用。言語はNode.js
- KT
- 機能単位でクライアントの開発部門による開発機能と弊社開発機能を振り分け、クロスレビューとすることでKTの機能を持たせる
- 上記とは別途、技術要素やCICDなどについては資料作成、講義を通じてKTを実施
要件については弊グループにドンピシャの内容で、(個人的には)もらっていた要件も十分満たして、提案内容としてはいいものができたと思い、提出しました。その後、グループリーダや部長から細部について指摘をしてもらい、承認が通ったものを営業の手直し後、クライアントに提出しました。営業とグループリーダーから提案について説明して、感触は良かったとのことで安心していました。
(ここからタイトル回収)
少し経ってから結果を聞きましたが、残念なことに他社ベンダーになってしまいました。。。
営業の方曰く"(感触の通り、)提案内容はとても良かった。ただ費用感が合わず、今回は敗退となってしまった"とのことでした。
敗退原因の分析
クライアントの言葉を前提とするならば、
- 提案の内容については十分満たしている(個人的な認識と相違なし)
- 費用感が合わなかった(そもそもどの程度の費用感なら良いのか認識なし)
となるので、費用感についての認識を少し深掘りする。
- そもそもクライアントの想定している見積金額を超えていた(eg: 工数的に現状50万円/月の作業のシステム化見積が数千万)
- 他ベンダーが同程度(orやや劣化)の提案内容で見積金額が安い(いわゆるこちらの提案のコスパが悪い)
※ 他ベンダーが提案内容も優れ、かつ見積金額も安い場合は勝てないので考慮しない
対策検討
-
そもそもクライアントの想定している見積金額を超えていた
-
ターゲット金額を推定する
直接、クライアントに”いくらで作ったらいいですか？”なんてもちろん聞けない。(ちゃんとしたものを作ってくれる前提で安いなら安いに越したことはない。)ただ、"システム化して顧客が得る価値>システム化にかかる費用" であることは前提とすることは大抵の場合で有効に思えます。今回の場合だと、システム化で削減される工数 + サーバレス開発のナレッジ蓄積(を金額換算したもの) > 見積金額 である必要があったということになります。- システム化で削減される工数:
こちらは情報さえあれば推定が一定の精度で可能に思えます。どのような人が月に何時間かけてその作業を行なっているのか、システムの耐用年数の想定が分かれば、実質、作業単価(人依存)×作業工数×削減対象の期間となり、計算できそうです。
eg)作業単価: 3000円/h, 作業工数: 0.5FTE = 80h, 削減対象の期間: 3年=36ヶ月の場合、3,000円/h×80h×36ヶ月=8,640,000円 - サーバレス開発のナレッジ蓄積
こちらは見積が難しそうです。。。強いて言うなら、クライアントの温度感に依存する変数ということになります。(クライアントの決裁権を持つ人がこの内容にいくらかけて良いと思っているのか)
上記の例のように大まかでもターゲット金額を想定することで、その見積に対する確度の想定が向上することが想定できる。
今回の敗退した提案では、まさに観点として落ちていた箇所であり、この観点が漏れているということは、"なぜクライアントがこの案件を進めたいのか"という要求が考慮から落ちているということと同義になる※1ので、今後の提案時に気を付ける必要がある。 - システム化で削減される工数:
-
ターゲット金額の推定のためにはクライアントからの情報ヒアリングが必要であり、そのため、営業メンバー等とコミュニケーションを増やす等の施策の実施を行い、共通認識を醸成させることやエンジニアが要件ヒアリングの場に参画していくことなどが必要になる
-
-
他ベンダーが同程度(orやや劣化)の提案内容で見積金額が安い
- 費用を下げる
一般的に作業工数×単価で見積を出す場合、簡単に見積金額を下げることは難しい。(営業戦略などの要素を除いた場合)上記前提で見積をしており、金額を下げる場合、稼働率や他案件のリスクを含めて考慮されている自社規定の利益率を下回る要因となり、また、その案件自体の赤字リスクが増すためである。また、提案で競合がどのような内容で提案しているか分からないため、ターゲットとなる金額がわからず、過剰な見積金額の割引を行なってしまう恐れもある。そのため、費用を下げるにあたってもなんらかの工夫が必要となる。- 作業スコープの縮小
費用感が合わない場合で即効性のある手段として採用できる。クライアントから見て優先度の低い作業を実施しないようにし、その作業工数=見積もり金額を減らす方法である。
eg)上記要件にあるKTの温度感が低いため、KT提案のクロスレビューを実施せず、机上でのKTのみとする。
ただ、この方法は提案内容が劣化することと裏表の関係となるため、新規クライアントに対しては採用しにくい。 - 作業工数削減(作業効率向上)
こちらは本質的なコスパの改善が可能だが、そもそも効率向上のためには何らかの事前投資(時間、お金)が必要なため、そうした取り組みを組織的に行なっておく必要がある。
具体例
- テンプレート化による作業内容の画一化
- サービスやツールの導入による要件を実現しつつ必要工数の低廉化
- 作業スコープの縮小
- 提案内容を向上する
費用を下げられない場合に提案内容で差別化する方針だが、こちらは課題に対する対策になり得ない。提案内容を向上させるとそもそも作業内容が増えることが多く、見積金額の上昇となってしまう。金額を上げずに向上させることは利益率を下げていることと同義のため、前述した内容と重複し、リスクを抱え込むことになる。
- 費用を下げる
まとめ
対クライアントへの見積実施する上で気を付けるべき点では、価値ベースでのターゲット金額の想定を行うことは必要に思った。そのためには、クライアントとの接点を営業経由orエンジニア直接などで要件等のヒアリングを積極的に行う必要があるように思います。
同業他社と相見積で正攻法的に戦う場合には、根本的に広義の技術力を向上する必要があり、組織として高付加価値を生み出せるような施策を継続的に行なっておく必要がある。
もしくは、根本的にコスト競争的になる人月による見積のみに頼るのではなく、得意領域についてサービス化やパッケージ化を行い、価値提供をベースとした見積ができるような仕組み作りも必要なのではないかと考えた。(サービス化やパッケージ化について、クライアント視点では低コストで要件が達成できる、ベンダー視点では投入工数が少なく高利益率といったラインを目指したい)
注釈
※1. なぜなら、要求を満たすことでクライアントにメリットが出ることが前提で、費用が価値を上回った場合はそれはクライアントの要求を満たしたことにはならないため。
補足
- 価値ベースの見積に関する記事
- (この方の見積に関する他の記事もあぁ分かると思って読ませてもらっています。ありがとうございます！)