見出し画像

第９回　ＤＣＭ分科会活動報告

DCM運営

こちらは DCMメンバーで奇数月に開催している分科会(勉強会)で発表されたライトニングトーク(以下ＬＴ)やTips、ワークショップの模様などについて 活動報告をするnoteです
第9回目は「ケーススタディ ディスカッション」です

こんにちは！DCM運営の株式会社三恵クリエスの佐藤です
今回は３月に開催されました、第９回分科会の活動内容についてお届けします

DCMとは

DCMは「Developers Cocreation Meet up」の略称で、IT業界の請負案件やLABO案件の受注活動に従事する営業があつまるコミュニティです

「営業力や開発力の向上をメンバー同士で助け合い、共創の場をつくりだすこと」

をポリシーとした、一人一人の”繋がり”を大切にするコミュニティです

【リンク　https://dcm-it.net/】

活動報告

2020年10月よりスタートしたDCM分科会もきづけば今回で9回目を迎えました

次回はいよいよ二ケタ開催を数えることとなります
参加メンバーにより良い刺激を与えられる様にこれからも運営一同企画に励みたいとおもっています！

さて、今回はこれまでと趣をかえて、営業が直面する課題をお題にしたケーススタディを実施しました

かなり極端なお題だったかなぁという反省もありますが、参加者からは
「逆に印象にのこって良かった」
「他の営業さんの意見が聞けて有意義だった」
という声をきけたので、これはこれでよかったのかな、、うん

ぜひ自分だったらどう行動するかな？と考えながら読んでみてください
すこしでも読んでくださっているアナタの参考になれたらうれしいです

それではさっそく設問１からみていきましょう！

設問１「競合他社がウチより安い・・・どうする？」

★背景

あなたが営業としてロビー活動をつづけてきたお客さまから
初めてコンペ参加のチャンスをいただきました！

ただ、参加中のコンペにて競合先の価格が
自社より安価であることがわかりました　(がーん😨)　

あなたはこれまでの経緯から何とか受注したいと思っています

★課題

社内調整しようにも、赤字となってしまうため
単純に競合他社に価格をあわせることはできません

★設問　

あなたは、この事態に営業担当としてどのような対応をしますか？

お客さま向け・社内に向けてなどいくつかパターンがありますが
自分が一番良い！と思う対応内容を考えてください

SI営業において、自社単独に声がかかっているというケースはまずありえませんよね

どうしても取りたい案件に対して、あなたはどういった行動をとりますか？



（　＾ω＾）・・・考えがまとまりましたか？
それでは参加者の回答例をいっしょに見ていきましょう！


参加者のみなさんの回答としては
大別すると社内とお客さまの両面に調整をかける考えがありました

どちらかというとお客さまへの働きかけが重要
と考えている方が多かった印象です

回答例

社内向け

・上司と相談して受注できるギリギリの金額を確認して再提示する

・今後の拡販を訴えて、今回は競合の金額に近づけられないか上司に交渉する

・アサインメンバーを再検討し人件費を抑えることで見積金額削減ができないか考える

・MbaaSやオープンソースの活用でコストを抑えられないかエンジニアと相談して再提案

お客さま向け

・改めてお客さまへヒアリングのうえ仕様の優先度を整理、工数削減のできる点を検討して再提案をおこなう

・見積粒度を細かくだして見積の妥当性を訴える
　安かろう悪かろうよりも良いものを適正価格で！を訴える

・不用意に金額を下げることで想定されるリスクを説明して自社見積の適正を訴える

・コスト以外の勝負に持ち込む
対応の速さ、お客さま担当者がコスト以外に重視しているところは無いか？　
提案案件に近い事例があれば、引き合いに出し安心感を訴える

・値引きを受け入れる代わりに自社のメリットとなる条件を提示する
　実績紹介や顧客インタビューの実施や公開許可など販促につなげられる内容など

いかがでしたでしょうか？

自分の考えと同じだ！
あーその考えもあるのかぁ

なにかしらのヒントにはつながりましたでしょうか？？

顧客の本当に欲しいものは何か？を把握すること
コスト以外の利点を訴えること

この二つが重要だと改めて筆者は考えさせられました

可能性を模索する意見の一方で
どうしてもだめなら無理をせずに次に行く！という意見も多くきかれました

お客さま のいうままに、無理なコスト勝負にのっかることはお客さまにとっても、自社にとっても不幸な結果になりますからね
（営業は切り替えも重要）


それでは次いってみましょう！

設問２「受注確度高いけどリスキーな案件っぽい・・どうする？」

★背景

あなたが営業をしているお客さまより
海外向けアプリと業務システムの相談を受けました

お客さまが海外市場へ進出するにあたり
現地のカスタマー向けのスマホアプリと
カスタマーのデータを管理する業務システムです

お客さまからは「コストはいくらでも出す」と言われています

新規事業のため

「とにかくスピード優先！」
「サービス開始日は遅らせたくない」

というお客さまの強い希望があります

★課題

お客さまの予算は潤沢…
でも、成功に導くためにはリスクが多いと
あなたは感じています

★設問

あなたは、リスクを軽減するための施策を考えつつ
スピード重視と言われているこの案件に対し
営業担当としてどのような提案・対応をしていきますか？

これはかなり尖った設問ですね

手を挙げれば売り上げは立ちそうですが・・・
同時にリスクの匂いもぷんぷんしています

さあ、あなたならどうしますか？


考えがまとまりましたら、回答例をみていきましょう！

参加者の多くはリスクの整理とお客さまにリスクの理解をしてもらうこと
から考えている方が多かった印象です

顕在化していないリスクが最大のリスクですね、やっぱり

お客さまとリスクを共有して一緒に解決する協力関係を築けるかどうか？
が受注にうごくべきかどうかの判断基準といえそうです

回答例

・社内のエンジニア、他営業に協力を仰ぎ潜在リスクを洗い出し、顧客に認識をしてもらう
（認識してもらえたらお客さまにも対応策の検討に参加してもらう)

・リスクを洗い出し「スピードを上げてできないこと」「お金で解決できないこと」については理由を提示して、お客さまに理解をしてもらう
（解決できなものはいつなら可能か？という代替スケジュールも提示する）

・要件の優先度を整理して、期間内に必ずリリースしなければならない内容とそうでないものを切り分ける
(優先度が低いものは段階リリースとさせてもらう)

・スピードを早くするための実現方法を考えて提案する
(ハイブリッド化、ローコード、MBaaS、サーバーレスなど)

・体制を厚めにしていざという時に対応できるように備える

いかがでしたか？

筆者としては、目新しい意見はなかったという印象ですが
裏を返すと開発でいうところの銀の弾丸のような
ウルトラCみたいな解決策はないということではないでしょうか

リスクを見える化し、お客様が望む成果を整理すること

いつまでに何をやるべきかをお客様と一緒に考えていくことが重要ですね

ときにはお客様にとって不都合な真実も
勇気をもって伝えられる存在でありたいですね

それではそれでは　最後の設問です

設問３「それ、やった事ないけど…どうする？」

★背景

あなたが新規で開拓したお客さまより案件の相談をもらいました

ただ、お客さまからは、自社で使用した事のないフレームワーク
使用した事のないライブラリでの開発を指定されました

あなたからお客さまへは
「その環境は自社で使用したことがない」
とお伝えしましたが

「他に請けてくれる会社が見つからないので
貴社にどうしても指定した環境で開発をお願いしたい！」

とつよく依頼をされています

お客さまの希望環境を使用した事のある人員は見つからず
プロジェクトへアサインすることは難しそうです

今後の取引の広がりを考えると簡単にお断りすることは控えたい・・・
とあなたは思っています

★課題

新しい開発環境は、学習コストが別途かかってしまうため
工数も上がり納期も遅くなってしまうことが見込まれます

また、お客さまの要望・期待にお応えできるか あなたは確信が持てません

★設問

あなたは営業担当として
この状況に対してどのように対応をしていきますか？

-断る場合は、今後もお付き合いが続くよう、どの様に断りますか？

-お請けする場合は、開発遂行上の問題をクリアする方法、契約など
どの様な方法でリスクを軽減して顧客の期待値をコントロールしますか？


今回もちょっと特殊な例かもしれませんが、たまーにありますよね

政治的な関係でどうしても顧客指定の環境で開発しなくてはいけない！という場面・・・

さぁ、あなたならどうする？



・・・考えはまとまりましたね？
では、さいごの回答例をのぞいてみましょう！

回答例

[請ける場合]

・希望環境で対応した場合の学習コスト(期間・予算)をエンジニアに確認してお客さまへ説明する

・見積書に前提条件を盛り込む
（学習コストや通常よりも工数がかかること）

・希望環境で自社が対応した際のリスクを前提条件として細かく記載し、お客さまに納得してもらったうえでお請けする

・請負ではなく準委任契約にしてもらえないか交渉する

・なぜその環境にこだわるのかを確認する、再現可能であれば別のフレームワークやライブラリを使用できないか交渉してみる

やはり、リスクを明確に提示して納得してもらうという正攻法が多い印象です

契約形態を変える、という視点は筆者はなかったので
あぁー確かに！と膝を打ちましたね

「どうしてもこの環境でなくてはならない」という時点で
前提がシステム化の本質からずれてしまっているため
そこが一番のリスクと思えます

リスクを正直にお伝えしたうえで、成果を出すためには十分な準備が
必要であることをお客様にも理解いただくことが大事ですね
お客様の施策を成功に導くためには

つづいては お断りする場合のパターンです
どんな断り方があるでしょうか

[お断りする場合]

・お客さまの希望されている開発環境で実績のある会社を紹介する

・お客さまの希望環境を社内で精査・検討を重ねたうえで難しい理由をお伝えしてお断りする（その際には自社の強みをアピールして強みの分野でお声がけいただきたい旨お伝えする）

・請けられない理由と、代替え案を提示してお断りする

・対応できる他者を紹介するとと同時に自社で経験のある環境を資料化して提示しておく
(お客さまの希望環境で行き詰った際に声をかけていただけるように)

ただお断りするだけではなく
他社の紹介や自社の強みをアピールすることで
次の機会につなげる作戦を取っている方が多かったです

お断りするにしても、少しでもお客さまにポジティブな印象を残すこと
が大事ですね

筆者も自社に無理なものは 得意な会社さんをつなげることはよくやってます

どんな形であれ、お客さまの成功に貢献できることは巡り巡って返ってくる
と筆者はおもっています

以上
第9回分科会のケーススタディディスカッションの模様をお届けしました！



いかがでしたでしょうか？
今後もケーススタディは定期的に開催してみたいとかんがえています

こんな場面だったら他の営業はどうかんがえるかな？というお題をお持ちの方はぜひお問合せのうえ参加メンバーに加わってください！お気軽に


次回はいよいよ二ケタ開催の10回目に突入です！

それでは、また次回お会いしましょう！

この記事が気に入ったらサポートをしてみませんか？