ここ3年ほど、開発会社の営業というものを本気で考えてきました。

以下は私が試行錯誤の営業経験から得たポイントです。何かのご参考になれば。

【point1】営業は質より量の部分がある

技術者出身の経営者がよく陥りがちなのが、｢質が良ければ必ず売れる｣という発想です。

確かに商談においては｢質｣をアピールできなければ売れないのは間違いないのですが、商談に入る前の開拓営業では、ダイレクトメールなり電話なりページビューなりの、量をとにかく稼がないといけません。

まずお客様の扉を一つでも多く叩いて、万一少しでも開けていただいたら、今度は力のあるシステムエンジニアなりコンサルタントが行って｢質｣をアピールする、というのが王道です。

この両方の技量を、高いレベルで兼ね備えている人間を私は見たことがありませんので、きっちり分けて考えるべきだと思います。

 

【point2】どんなシステムでも作れる技術力では刺さらない

｢何でもできるは何にもできない｣という言葉もありますが、ウチは高い技術力があり、経験も豊富なのでどんなシステムでもできますよ、というのではお客様には何もアピールできません。

たとえば、｢建築業界に特化したシステム会社です｣であったり｢仕様書のないシステムのカスタマイズならお任せ下さい｣のような切り口で、小分けにランディングページを作成して、そこで仮想案件についてのソリューション、価格イメージなどを掲載しておくべきでしょう。本当にそれ専門でやるということではないです。

七面鳥でも子羊でも生のままドカンとテーブルに置いてあったら誰も手を付けません。ちゃんとお客様の顔を思い浮かべつつ、美味しく調理して、食べやすい大きさに切っておくべきです。

 

【point3】選択肢の多さが、お客様の決断を妨げる

力があり、サービス精神旺盛の開発会社ほど、お客様の要望に対していろいろな選択肢を用意しがちです。それは決して間違った態度ではないと思うのですが、たとえば要素技術やサーバの形態、連携する外部サービスなどの組み合わせで10も20もの選択肢になってしまう場合、お客様は思考停止してしまいます。

ある程度の｢お勧めコース｣を担当SEの責任で作ってあげた方がよいと思います。まあ3つか、多くて5つです。

【point4】提案書と要件定義書をごっちゃにしない

提案書は、お客様の夢をスケッチした資料です。多少、夢を盛ってあげることも必要です。
要件定義書は、それを実装というお客様にとって退屈な軸でブレークダウンした資料です。

実装に意識の向いたエンジニアの書く提案書は、要件定義書に近いものになりがちで、大抵実装しやすいように機能がまとめられていたり、コンパクトになっています。

お客様にとっては、『このタイミングで顧客毎にメールを打てるのが画期的！』と思って要望を出しているのに、『汎用メール送信機能』というような機能にまとめられていては夢を萎ませてしまいます。

｢うーん、こんなつまらない話だったのかな？自分の要望は...｣となり、商談が盛り上がらないです。

【point5】取りに行った提案はトラブルのもと

とにかく契約を取りたいあまり、システムの目的が、発注担当者の要望を漏れなく実装するというものになってしまっている提案書を見かけます。これは、使う人の立場に立っておらず、実際に完成した際に使用に耐えないシステムになりがちです。

かといって、エンドユーザーの方ばかり見た提案書もいただけません。発注担当者は、ユーザーの動線をこう持っていきたい、こういう意図で使ってもらいたい、という意志があるからです。

発注担当者の意向と、エンドユーザーの両方を見た提案書を練るべきだと思います。要は、｢システムの目指す物を、プロの視点でアタマで汗をかいて本気で検討する｣ということです。契約を取りに行った提案は、後で必ずトラブります。

【point6】先端技術の研究は、ただのリスキーな仕入である

売上が上がらないとき、余剰工数で新技術の研究やアプリの開発などを行ったりしがちですが、これはほとんど営業にはつながりません。

すべての技術調査・試験研究は｢仕入｣と認識すべきです。お客様がついていない状態で商品を仕入れているようなものですので、以後、それを無駄にしないために営業先を狭めることになります。

これは就職先が見つからないときに、英会話学校に行き始めるようなもので、まずいいことがありません。

仕事がないときには、きちんと営業に資金を充てるべきで、営業に協力するスキルのない開発者は｢雇用調整助成金｣などを利用しつつ休業させるべきでしょう。（まあ実際はそれも難しいのですが...）

一番の問題は、隙間を埋めるための何かをやることで、開発者が仕事をしている気になってしまうことです。

【point7】どこにでも通用する営業フレームワークなどない

開発者たるもの、似たような処理はフレームワーク化してやろうと思いがちですが、そのような発想は営業においては御法度です。

提案資料は言ってみればラブレターのようなもの。それをチャチャっと量産できる仕組みを作って、お客様に惚れていただけるはずもないです。きちんとお客様の知識量やリテラシーに合わせた提案書を心を込めて作るべきだと思います。

年配の方ならフォントを大きく、右脳系の方なら画面イメージを多く、リテラシーの高い方なら専門用語を多用して直球で。テンプレートくらいはあってもいいと思いますが。

どんな提案書でも30分で作れるようなフレームワークで、仮に何回かうまく行ったとしても、その発想は長期的には心の通わない開発を行う経営体質につながっていく気がします。

【point8】価格を下げることが営業努力ではない

数社コンペとかになると、どうしても価格を下げて契約を取りに行きたくなりがちですが、絶対に必要と思える金額を割ってまで金額を下げると、その分どうしてもクオリティを落とさざるを得ず、最終的にお客様の満足度を下げてしまいます。

私も過去何度かそのようなことをしてしまいましたが、お互い不幸しか生みませんので、限度を超えた値下げ要求は勇気を持ってお断りすべきだと思います。それがプロパーなお金でご発注いただいたお客様への誠意でもあるでしょう。

ウチは安くはありません。それは、○○だからです。

この○○を考えるのが、営業戦略の上位の、経営戦略というものですね。