この一連のツリーは面白いけど、別観点で書いてみる。概ね同意ではある。
前にも書いたけど営業部門のマネージャーだったことがある。同じ組織内に我々みたいなシステムエンジニアと生粋の営業がいるという実験的な組織。あれ、実験どうなったんだっけ？と思い出してみたら、オレが社内公募で他部署に移ったのだったｗｗ
実験どうなった？（おい
一連のツリー
例えば物売りの営業がさ。
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) 2024年1月29日
できない事できるつったら、キャンセル喰らうんだわ。
金融系の営業がウソついたら、えらいことになるよな。
営業のスキルって、状況を悪くせず『No』を言う技術も含まれてると思うんだが。
IT業界の営業はスキルが乏しいって話なんだわ。
なぜそうなるかって、 https://t.co/eoqmFUJxi4
あとは、請負が影響してるかもね。
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) 2024年1月29日
請負契約である以上。納品の為に必要な全ての情報が出揃わないといかんが。それを得る術が無い。
(無償で常駐で調査とかすりゃいいのか？ 失注リスクある他、顧客が嫌がる事も多そうだ)
全部得られたとしても、そこでNoを言うスキルは必要無いし。
ほぼ全ての競合が常に必要な情報を得られない状態としたら。
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) 2024年1月29日
あとはチキンゲームになるだろうし。
できますできます受注しか、飯を食う術が無いかもしれん。
これも貧すれば鈍するで、ロースキルを扱う(競合が多く、競争が厳しい)ほど、営業が『受注』をとって来ることのウェイトが大きく。
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) 2024年1月29日
少々盛ってトークして受注しても、チャンスを活かせなかったエンジニアが悪いとなりがち。
異業種出身の営業からすると、どれもこれも気持ち悪いんだ。
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) 2024年1月29日
まー、技術部署側が、その受注の優先度の高さを無視して、
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) 2024年1月29日
前提条件の変更次第でできる事をできないって言ったりとか。
そう言うのがあったりして、『営業と技術部署間に信頼関係が無いから』とか。
そう言うのを体験した人が営業優先の組織設計にしたりとか。
まーいろいろあんだろな。
そういう営業しか目にしないことは多い
まあ「人による」って部分もあるんだけど、スキルが低いというのは多くの場合肯定できる。きちんとできないことはできないと説明するスキルが無いし、値引きでしか他社との競争手段を(営業本人たちは)持たない。
できないことはできないと説明するスキルというのは、わかりやすい例で言えば、「(あなたの言っている予算感では)全部盛りは無理です」とか「(あなたの考えているスケジュールでは)全部は完成しません」とかである。ヘタすると軟禁されるけど、こちらもビジネスなので言わなきゃ後でもっと大変なトラブルになる。客先の会議室内の軟禁で済むならまだマシ。トイレ我慢する能力は必要。
営業は「できますよ。是非うちに。」とか安請け合いしてきて、社内に持ち帰ると「できるわけねーだろ」となる例を多く聞く。ネットでもそうだしリアルに他部署トラブル事例などでも他社事例の噂でもそういう経験をしてきた過去がある。大体の大トラブルの一部は「できるわけねーだろ」が顧客に通用せず、「お前の会社ができると言ったんだから、(些少ながら)金は出すんだからやれ」である。些少じゃなく金出せば解決することもあるんですが。
入札でもそんな札入れちゃまずいだろっていう事例も知ってる。他部署のやらかしでオレの正月が緊急招集で無くなり新幹線でとんぼ返り深夜の永田町駅へ、(顧客先が面積的に広大なため)足を棒にしてPCセットアップした記憶が。なぜキッティング完了動作確認したものを配らない？まあこの件、営業のせいだけじゃないけどさ。
「なぜキッティング完了したものを配らない？」を例えると、「クリスマスケーキ売ります、最後のデコレーションは皆さまのご家庭で」である。大量販売でそんな売り方あるか？
まだ買える？買えるなら2023年12月24日に届けてくれ。
請負だ準委任だの前に
そもそも決まったパッケージを売るパッケージ営業(今回は面倒なのでハードウェア販売もこれに類するとしておく)と、ユーザアプリ開発の請負や準委任で受任する話は別である。パッケージ営業は基本的には他業種のモノ売りと同等である。いかに少ない労力で受注まで確定させるかである。例えばWindowsやOfficeを売るのに労力掛けてたらおかしいでしょ。そんなものはリバースオークションであっても、価格やサポートなどで勝てるように仕込んでおく話であって、個々の営業のスキルというよりも企業としてどのような勝ちパターンを作るかである。
受託開発とパッケージ営業の間にソリューション営業があるけど、面倒だし冗長になるので割愛。どちらの特徴もあるとだけ。
さて受託開発。元のポストと別の観点を書く。公共なら公共、金融なら金融、製造業なら製造業というように、それぞれ顧客の業務を知悉する営業なんて希少な存在である。そんなことが自分たちに必要だとも思っていない。せいぜい業界知識や業界情報程度の把握、IT系の知識も上っ面だけだが、顧客業務まで踏み込んで会話できる営業は少ない。
オレはやったよ。関連法令は全部読む(覚えてはいない)。まず、法的な縛りなのか業界慣習なのか社内慣習なのか切り分けしなきゃいけない。法令的な縛りがあるものは「これ、無駄だから無くしましょう」っていうのは国に言えという話である。監督官庁に働き掛けるのか国会議員に言うのかという違いはあるけど。
ネットでは「どうせ死刑になるんだから医療いらんだろ」みたいに軽口叩けない内容なのに軽口叩くバカが存在するけど、仕事はそうはいかない。法令的な縛りがあるものに対して「これ、無駄だから無くしましょう」「〇〇のほうがいいのに」っていう奴は取引してもらえない。多分、顧客の担当者がその瞬間に心を閉ざす。シャットダウンされる。この先まともな会話にならないじゃん。「え？そこから？」って思うはず。
対象が慣習やなんとなく決まったものということになって、初めて色々提案できる。
ここでようやくIT系の知識である。だから世の中に名前が出ているようなスーパーなITエンジニアはこういう分野はやりたくないのだと思う。自分の構想通りに自分の考えている手順で物を作り上げるほうが楽しいじゃん。こういう意味でも苦行だよ受託開発は。
スーパーじゃない平民はそういう苦行を金にするの。
じゃあ、そういう営業を育成できる？
無理かなあ。相当情報処理能力が高い個体ならそういう方向に育成可能だけど、企業が組織として(ほぼ全営業要員を)育成できるかというと無理かなあ。なら、IT企業としては営業は御用聞きで結構ってなりそう。それなら、せめて顧客内の人事・組織情報をしっかり把握してもらうほうがいい。
オレが社内事情を知らない企業ではどうか知らないけど
なんだ、この章題はｗｗｗｗ
個々の企業で、受託開発の損益をどう見ているのかは知らんのだけど、ヤバい案件を安請け合いして来る営業を少なくする方法はある。営業にも損益責任を持たせるだけでいい。受注件数や受注金額で評価していたら、そりゃ安請け合いするし勝手に値引きしてくる。
ひぃひぃ言いながら開発して、それで業績悪いとか言われたらそりゃなんでも「できません」ってまず言うだろ。安全牌案件持っているなら特に。
業績の一端が営業にあるのであれば、それは責任も応分に負担すべきである。
![[サモエスキー] 安全牌 麻雀 おもしろ Tシャツ 半袖 ブラック L](https://m.media-amazon.com/images/I/31KFN2JbhqL._SL500_.jpg "[サモエスキー] 安全牌 麻雀 おもしろ Tシャツ 半袖 ブラック L")
架空の例を挙げると、(金額は皆さんの想像におまかせ)億円のビッグプロジェクト受注しました、受注した〇〇第2営業部を表彰します、一方その数か月後プロジェクトは火の車、担当している△△第1事業部は毎日経営幹部と進捗会議でつるし上げ、しかもさらに時間が進むと毎月の業績会議でも予定外の要員追加で人件費開発拠点の費用増大、大赤字ということでもつるし上げみたいな話。架空とは思えないって人も多そう。笑えない。
章題はクソだけど、言いたいのはそんなところです。
なお
大元はこのポスト。
セールスとエンジニアの仁義なき戦い pic.twitter.com/pyMUAKKCiA
— のなと@もちねこはｻﾗﾘｰﾆｬﾝ🐈💨 (@MochinecoNonato) 2024年1月29日
だいたい、全部足りない。
解決策？
無いんじゃないでしょうか。あるとすれば大規模な受託開発には手を出さない。
