ＩＴサービスは見積りから始まっている
『見積り』は重要です。
超重要です
超々重要なのです！
過小に見積るとプロジェクトが始まる前に失敗が決まります。過大に見積ると会社としては売上や利益に貢献したように見えますが、それで顧客満足度が低いと今後の機会損失を生み出しかねません。
それほど重要な見積りなのですが、開発現場では意外に軽視されています。エンジニアにとっては「モノづくり」ではないと認識されているのかもしれません。
見積りのタイミングと言えば確かにプロジェクトはまだ始まっていませんし、結果として失注してしまって見積り期間が全て無駄になってしまうこともありますが、この時点から真剣に取り組んでおかなければプロジェクトとして失敗を招きかねませんし、お客さまの満足度を向上させることができません。
受託開発…特に一括契約の見積りはプレッシャーがかかります。
適正な利益を保ちながら正確な金額をはじき出すのは簡単ではありません。ここでいう「見積り」は、スティーブ・マコネルが『ソフトウェア見積り』
で言うところの「コミットメント」に相当します。
コミットメントとは要するに、
定義された機能を、特定の品質レベルを確保しながら
期日までに納品するということを、お客さまに対して約束する
と言うことです。マコネルは見積りとコミットメントはまったく別物であるから注意せよと言っていますが、ほとんどの開発現場ではその意識は浸透していません。
見積りという言葉を使う際には、どちらの意味で使っているのかを注意してください。見積りを単に値切交渉の場にしてはいけません。きっちりと見積らないと、この時点でプロジェクトの泥沼化が決定してしまいます。
見積りを外した結果、コミットメントを守れず赤字になるのは非常に痛いですが、これはお客さまにとっても同じことです。赤字のプロジェクトが生み出した成果によってお客さまの高い満足を引き出せるはずがありません。
見積りでお金は稼げませんが、プロジェクトを成功させられるかどうかの重要なカギを握っているプロセスなのです。お客さまに対するサービス提供はこの時点ですでに始まっているのだと心得てください。
お客さまは金額だけで発注先を決めるのではありません。
見積り期間におけるサービスの質も重視しましょう。
「見積り」というサービスの質を上げるには次の３点に注意を払います。
見積り根拠の納得感
まず、見積り根拠の納得感が必要です。
事前に十分な情報をもらえるのであれば、それに見合った根拠の提出が求められます。お客さまにとっての納得感は「数えられること」であり、「計算によって全体が導けること」です。
画面や帳票など数えられるものを洗い出し、簡単な計算で全体が導き出せるようにします。「ざっくりと見積ってください」などと言われ具体的な話が聞けない場合もありますが、そのような場合でもなんらかの理屈付けは必要です。想定を交えた見積りであることを前提条件としたうえで、できるだけ納得感が出せるよう努力しましょう。
また、お客さまに応じて内容を書き分ける工夫も必要です。
エンドユーザのお客さま（元請けでの受託開発）の場合は、最終的な見積書には機能ごとに金額を出すといいでしょう。
お客さまが簡単に調整できるからです。
上図の場合、注文受付画面の開発を見合わせれば40万円費用が下がることがすぐにわかります。一方、同業者のお客さま（下請けでの受託開発)の場合は、金額ではなく工数での見積りのほうが納得感を持たれるようです。
この見積りは機能ごとの工数で出したものです。
実質上段の図と同じことなのですが、お客さまが根拠として受け取る印象は違います。商社色が強い企業やエンドユーザー企業は上段を、ＩＴベンダーであれば下段の見積り方が納得されやすいでしょう。
最後にもう一つ、見積りには「成果物感」を出します。
たとえばシステムテストなどの作業は機能としては表現できません。その場合は「作業ベース」ではなく、「成果物ベース」でまとめましょう。作業の成果が「モノ」として表現されているため、お客さまにとって納得感があるのです。
そもそも「請負契約」は成果物責任が問われる契約形態で、どんな作業をしているかは関係ありません。成果物で見せる…と言うのはいわば当たり前のことなのです。
これを工数でしか提案できないのは、お客さまを見ていないと言うことです。
「お客さまが何にどの程度の価値を見出しているのか」
という観点で見ておらず、要員計画や自部門の数字の達成しか見ようとしていないとお客さまが納得できる説明ができないのも当然です。「お客さまに納得していただこう」という相手目線の思いがどこにも無いわけですから。
提案のバリエーション
ここまでは見積りをするのであれば当たり前の流れとなっていました。ここまでの時点で反省すべき点を見つけてしまった人は注意してください。過去に見積りで失敗をしているか、これから失敗する可能性が強いと言うことです。
しかし、所詮は「当たり前」のことですから、普通はサービスの質として差がつくことはありません。技術的に優れている部分…と言うのもなかなか表現しづらいところでしょう。そのため特筆すべき差別化も見られず、価格競争に陥る可能性があります。
しかし吉野家などの牛丼チェーン業界を見ていてもわかるように、価格競争になって各社が疲弊していくだけの状況は誰も望んでいません。
そこで提案のバリエーションをたくさん持って柔軟に対応できるようにします。金額面で折り合いが付かなかった場合でも簡単には諦める必要はありません。サービスといっても単純に値引きを行うだけではないのです。
お客さまが本当に困っているポイントを引き出し、お互いにとってのリスクを最小化あるいは折半するような提案と交渉を行います。
「値引き」は最後の最後に用いる手段です。
簡単に提示金額をコロコロ変えるようでは真っ先に信用を損ねることになります。サービスとしては最低・最悪の手段になります。だからこそ金額提示は慎重に、かつ相手が納得できる根拠を以って示す必要があるのです。
具体的には、次のような提案があります。
高くつく機能の代替案を提案すること
機能の優先度付けを行う
優先度の低い項目を開発候補から外す 等
ドキュメントなどの中間成果物を減らす、あるいはお客さまに担当してもらうことで調整することもできます。もちろんこれらのやりとりは開発者というよりは営業のスキルに近く、ひょっとするといちエンジニアには交渉の材料としての金額や要員に関して決定権を持っていないかもしれません。
しかし開発者にもできることはあります。
直接お客さまとやりとりすることはなくても、プロジェクトマネージャーや営業担当から金額を削減するアイデアを求められることはあります。特定の機能を短期間で実現するための技術や新しい方式の提案は、開発者の得意領域であり腕の見せ所です。アーキテクチャの構成から無駄を省き、より効率的な開発の進め方を提案できるかもしれません。
プラスα（付加価値）
提案は常にプラスαを意識しましょう。
お客さまの想定をどこか一ヶ所でも上回るのです。
たとえば、お客さま自身「やりたいこと」に対する具体的なイメージが湧いていない場合があります。そのような場合、最もポイントとなる機能のビジュアルを見せてしまうのが効果的です。
私が以前担当したプロジェクトでは、一番よく使われる画面のモックアップを本物に近い操作性で実現し、それを見積り時の打ち合わせでお見せしました。ドキュメントに書いて説明するよりも格段に鮮烈な印象を持たれたようです。
また、別の案件ではさらに一歩進め、実際に機能を一部実装し、デモンストレーションしたことがあります。ひとことで言えばプロトタイピングモデルの応用ですがこれも効果的です。
オープンソースの普及により、今は手軽に機能を実装することができます。これらを活用することで低コストでお客さまのイメージを確認できるのです。
提案のバリエーションやプラスαを意識するには、お客さまの求めている内容を相当に理解する必要があります。いただいた情報を読み込み、繰り返し質問する必要もありますし、下調べや技術検証が必要になることもあります。
ただ、こうしてお客さまの要望の急所に対して一手間加えることで確実にサービスの質を上げることができます。また当然ながらそうして得た知見は、仮に失注したとしても他のお客さまに転用できることが多いのです。
そしてさらに見積り段階でこれらを意識することで、あとの開発に良い影響を残すことができます。
まず、お客さまの「やりたいこと」がクリアに頭に入ってきます。また開発がスタートする前にお客さまから一定の信頼を得ることができています。そしてなにより一手間かけたことで自分の仕事に対する愛着と責任感がわきます。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。