システム開発を確実に受注する丸秘営業テクニック
筆者が担当している業界は競合SIerとの競争が激しく、非常に厳しい業界だと言われている。しかしながら、もし自分が営業担当だったとしたら、システム開発のコンペ案件を勝ち抜き、受注を重ねることは意外と簡単ではないかと思う。
営業部門の方々からシステム開発をほぼ確実に受注する方法を教えてもらったので、ここでそのノウハウを公開することとしたい。
（注：SIerの営業・提案プロセスにおける「●●●●●の作り方」を極端に脚色して書いています。内容はもちろんフィクションです。）
営業・提案フェーズ
まずは、お客様からRFPを受領する。社内のどこかから適当な開発部門を捕まえてきて、RFPを受け渡し、原価見積を依頼する。コストに厳しいお客様であることは特に強調して伝えておく。開発時にお客様から求められる制約事項や条件があることは知っているが、そんなことは開発部門には伝えない。RFPには書いていないし、自分は営業担当だから「システム開発のことは分からない」というフリをしておく。
さらに条件を加えるならば、開発部門が原価見積に掛けられる期間は、できるだけ短い方が望ましい。「お客様から提案依頼があり、期限は今週中なんです。スケジュール上、どうしても明後日の正午までに原価の見積を行って頂く必要があります！」 RFPを受領してから数日間、自分の手元で眠らせておいたことはもちろん秘密である。
RFPの受け渡しが遅れた言い訳は、いくらでも準備できる。「提案するかどうかを本部長に判断して頂く必要があった」とか、「組織間での依頼手続きに時間が掛かった」とか、「当初見積予定だった部署が人手不足で、結局対応してもらえなかった」等々。
開発担当者がミスをして、開発費用を低めに見積もってきたら… しめたもの！
「この見積は外してそうだな」と思いながらも、そのまま「ご提案」を行う。
お客様への提案前には、別の有識者にチェックを依頼することも可能である。しかしながら、自らが原因を作った“スケジュール上の制約”を理由にしたり、「～システムで実績のある部署だから大丈夫だろう」「生産性向上ツール※ を適用すると開発部門は言っており、工数削減ができるのだろう」等という楽観的で無責任な推測に基づく“だろう運転”で、提案に向けた手続きを進める。
（※ そんなツールは社内で誰も使ったことがなく、本当に存在するのかさえ微妙ではあるが。）
まともな有識者へのチェック依頼は、絶対に行わない。なぜかって？ そのチェックのお陰で、見積が増えたりしたら大変じゃないか！！
開発部門がまともな部隊で、妥当な開発費用を見積もってきたら… さてどうするか？
実はこれも大した問題ではない。
営業部門と開発部門を取りまとめる本部長クラスと懇意になっておき、うまく巻き込む。その本部長クラスから「なぜこんなに工数が掛かるんだ！ 競合のX社はこの半分の工数で提案するという“噂”じゃないか！ 見積をやり直せ！」というように開発部門を強く責め立ててもらう作戦が非常に有効である。
あとは、付き合いのあるグループ会社やパートナー会社に対しても、並行して見積を依頼しておけば完璧。依頼する際に意識する点は先述の通りだ。もし自社の開発部門がまともで“頑固な”部隊だった場合、営業担当としては、グループ会社やパートナー会社からの見積を採用した「ご提案」を選択肢にすることができる。
自社の持つそれなりのネームバリューと開発実績、そして競合よりも低い提案価格。以上の条件が揃えば、相当な確率で受注は決まる。そして、受注が決まってしまえば、その後の仕事は開発部門が担当することになる。
開発部門のメンバーが集まり、システム開発プロジェクトの完遂に向けて、開発チームは進軍を始める。進軍の途中、それもかなり早い段階で、誰かが「これは何かまずいぞ…」と気付く。実のところ、このシステム開発プロジェクトが「デスマーチ」になることは、受注した時点で確定していたのだが。
開発フェーズ
受注と売上は確保した。原価に対する責任は開発部門にあるのだから、自分の責任範囲ではない。毎週のようにお客様から頂く数々のクレームや、開発スケジュールの遅延は、現場の開発メンバーがイケてないことが原因である。
チームリーダの羊川さんが徹夜明けで倒れたのは、サポートすべき立場にあるPMの熊切さんが頼りないことが原因である。そう言えば、PM熊切さんの営業に対する非協力的な態度が前から気になっていた。お客様に対して「熊切さんから牛田さんへの交代」を「ご提案」するのも良いかも知れない。
このプロジェクトが赤字になるのは、開発部門に全ての責任がある。
と、レポートを作って、上司には報告するし、自分にも暗示をかける。良心の呵責から逃れるために。
さぁ、今回の四半期も営業成績は悪くない。満額頂くボーナスを使って、海外旅行にでも出かけよう。サービスインに向けて開発部門は大変そうだが、自分が休暇を取っても関係無い。ただし、旅行に出掛けることは、一応、開発部門のメンバーには内緒にしておく。
今回の失敗を受け、見積手法を勉強しようなんて、夢にも思わない。それより本部長が気に入りそうなお土産を下調べする方がよっぽど大事なことだ。
次の「ご提案」に向けて、たっぷり英気を養っておく必要がある。気持ちの切り替えが早いのは、営業担当として誇るべき素養の一つである。
もしかすると、休暇中にお客様から別システムの提案依頼があるかも知れないが… RFPは帰国後に受け取れば良いだろう。
提言
開発担当
営業担当者からの急な見積依頼に対しては、冷静な思考を保って慎重に対応を進めるように努めたい。もし打診された期日までに十分な見積対応が不可能な場合、「超概算見積」等といういい加減な見積を提示することは避け、見積対応自体を断るべきである。「超概算見積」はあなたの手を離れた瞬間から一人歩きを始め、営業担当者にいいように使われた揚句、近い将来、必ずあなたの首を締めに帰ってくる。
受注後に問題プロジェクト化した場合、当然ながら自社にも迷惑を掛けるし、プロジェクトに参加したメンバーも大きく疲弊する。加えて、システム開発を依頼した顧客にも迷惑を掛けてしまう。このような事態を避けるための重要なポイントが、見積依頼を受けたタイミングであることを日頃から意識しておく。
営業担当
システム開発プロジェクトにおいて、開発費用の見積を複数の組織や委託先会社に対して依頼し、その中で一番安価な開発費用を提示した組織・会社を「開発パートナー」として選定する、そのようなSI業界の悪しき慣習はそろそろ見直した方が良い。なぜなら、相見積の結果、一番安価な見積を提示した組織・会社には、見積時の考慮不足や見積対象外の項目が存在する可能性が極めて高いためである。
営業組織の長は、自組織に見積能力が無く、見積をチェックする能力も無い場合（私の知る限り、多くの営業組織にこのような能力は備わっていない）、相見積によって提示を受けた中で一番安価な開発費用を「原価」として採用してはいけない。もしそのような判断をすれば、プロジェクトは非常に大きなリスクを伴うものとなり、結果として自社に損失を与える可能性が高いことを認識するべきである。
経営層・スタッフ
社内の評価制度として、営業組織や営業担当者を「受注」と「売上」を軸として評価することは止めた方が良い。「受注」は評価の対象外とし、さらには「売上」以上に「利益」に比重を置いて評価を行うべきある。なぜなら、システム開発プロジェクトの実行結果として自社に「利益」をもたらすことこそが、営業組織や営業担当者が「営業活動」を実施する最大の目的なのだから。
営業がシステム開発プロジェクトの実行結果に責任を負わない場合、本稿で述べたような思考パターン・行動パターンに陥る営業担当者を生み出してしまう。意図的である・ないに関わらず、このような営業担当者を生み出さないために、制度面からも抑止を図ることが重要である。
