ITエンジニアがインサイドセールスの白本読んでみた（最終回）
こんにちは。のんです。
今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。
いえーい！
— のん🐘夜型言語 (@nonz250) August 2, 2021
インサイドセールスについて呟いたら、 @Mar_Cyyy さんが本を貸してくれました！😊
スマレジはインサイドセールスにも力を入れています！ pic.twitter.com/ejVLBxvAaM
あくまでも私主観での「感想」に近い感じで書きたい。
やはり本である以上、そのまま丸写し、よくない。良いか悪いかは置いておいて私主観の感想を述べる感じになります。
エンジニアがインサイドセールスについて知ったらこういう事考えるんだなぁ...くらいに考えてください。
具体的な内容が知りたい方は実際に購入しましょう！
Amazonのリンクです。アフィではないので安心して踏んでください。
今回は前回の続きから見ていきましょう。
成果を出すインサイドセールスのテクニック
この章は具体的なインサイドセールス、またはオンライン商談のテクニックについて書かれていました。
私は普段商談をしていませんし、いくらエンジニア目線とはいえ、当たり障りの無い意見になってしまいそうなので、サクッと終わらせたいと思います。
いつもどおり、気になったキーワードをピックアップすると...
オンライン商談時には「普段の半分のスピード」を意識して行うこと、でした。
当たり前のようで、普段できていなかったなと新しい気付きになりました。社内のMTGでも同様のことが言えると思うし、私は議論にのめり込んでしまうと、ヒートアップしてきてしまう癖があるので、より一層注意したいと思いました。
あと、めちゃくちゃ細かいですが、ホイールを利用したスクロールもそうですねｗｗ
Macの仮想デスクトップもよく使うので、注意したいと思いました。
ここで筆者が言いたいのは、できるだけタイムラグを抑えるために、紙芝居的に進められるように工夫すべきということですね。
他には商談前の心構えや、PCの環境準備ですね。
エンジニアの私が普段無意識に注意していた部分が改めて文面になっていたので、「ふむふむ、こういうことをキチンと明文化することも重要なのだな」と感じました。できるだけ自分の考えは口にするようにしていましたが、まだまだ足りませんね。
チームマネジメントの鉄則
うーん...一緒！！ｗ
どこの部署も同じような考えで、同じような悩みを持っていると改めて感じました。
事業戦略の理解度を上げる
エンジニア / プログラマーですから、技術傾倒しがちな人めちゃ多いです。
いや、技術軽視してるわけではないんですよ
でも、その対応で事業成長する？ってこと。よくある。
いくら高度な技術で実装されていたって課題を解決できなければ無価値なんですよね。
もちろん、課題を解決するために技術を求められるときもあるし、課題を解決したときに、すでに高度な技術で実装されていれば文句はないんですよ。
よく、技術と課題を一本の線でグラデーション的に引いて
「このトレードオフが難しいよねぇ」と語る人がいますが、それは違うと思っていて、この2つは全く違うコンテキストなはずです。
「技術がなくても課題は解決できる！」←間違い
「課題を解決する前にまず技術を究めるべきだ！」←間違い
技術と課題のバランスはマネジメント能力とプロフェッショナル能力の2軸のように、縦軸と横軸で展開され、両方とも高いレベルのものが理想形なのに、お互いが敵視しあって、
「技術重視のやつは経営をわかってない」
とか
「良いプロダクトを作るには良い技術が必須だ」
とか、不毛な争いをしているんですよね。
アホらし。
両方チャレンジすればいいじゃん。と。
どちらから手を付けたかの違いじゃんか。と。
僕はそう言いたい。
お互いもっと歩み寄りません？
そのためにはメンバー側は「事業戦略の理解度を上げる」必要があると思っているし、事業側は「技術（プログラミングとかITツールとか）の理解度を上げる」必要があると思っている。
そのためには事業戦略の布教が必要だよね？ということをこの本は言っている（ように感じた）
事業責任者の説明努力がやはり必要。
ぶっちゃけメンバーはほぼ平社員だし、サラリーマンだし、事業がうまく行ったときのリターンを具体的に思い描けていない（と思う）。
- この事業がうまくいくとこういう（めちゃ具体的に説明する。給与とか。）リターンがあるよ！
- そのためにはこの事業のこの課題をクリアする必要があるんだ！
- この課題は〇〇さんの持つ技術にかかっているんだ！助けてくれ！
これでやる気の出ない社員は...いないと信じたい。僕なら結構頑張ると思う。
このリターンを具体的にするために、次の章の...
挑戦と称賛の制度化
につながるわけですね。
この制度ではメンバー側からの訴えが反映されればうまくいくと思っています。
例えば、このようなツールを使って〇〇の課題を解決したいとか、この技術を導入してこの課題を解決したいとか。
その挑戦を評価に落とし込んで、そのリターンそのものを称賛にすると、事業は伸びるし、メンバーは成長するし良いことづくめな気がする。
とまぁ、このIT業界に入ってそれなりの経験をしてきた愚痴の塊のようなものを書いてしまった。
これはエンジニア特有の課題ではないと思うし、きっとISにも通ずることなんだろう。
委任と放置の違い
めちゃくちゃ耳が痛いです。
SLⅡモデル...覚えておきたいと思いました。
私は委任のつもりの放置ってやつかも知れません。。。
この辺はこのキーワードで色々参考になるWEBページがあるので、そちらに任せたいと思う。
このブログはあくまできっかけにしてください。
1 on 1
どの業種もやっているようで安心しました。（エンジニア特有のものかと思っていた...）
業種またぐと突然井の中の蛙になってしまうのなんとかしたいですね。
今の時代、報連相より雑相（雑談と相談）
というのはよく耳にします。そのきっかけに1on1を利用するのは良いかも知れません。相手も感情のある人間ですからね。あまりにビジネスライクに接してしまうと参ってしまう人、多いと思います。
ということで最終章まで（軽く）読むことができました🎉
完全に違う業種かと思いきや、思いの外マインドセットというか、目指すべき方向性に共感を持てることが多くニヤニヤしながら読んでいた章もたくさんあります。
本当はしっかり文字に起こしてブログにまとめたかったのですが、読むという行為と書くという行為、どちらが重いかは、、、書いてみた人ならよく知っているはずｗ
ということで、結構隅々まで読んだつもりでしたが、文字に起こせていない部分もたくさんあります。
少しでも興味がある方は是非ともお手に取ってみるなり、僕のように借りてみるなりしてサラサラと眺めてみるのも悪くない1冊でした！
あ、今思いついたけど商談のYoutube投稿とか良いかもと思った。
メモっとこ。
最後に
今回は6章から最後まで読みました！
感想はすでに書いたので、割愛して...
年末にかけて更に忙しくなりそう。次は何について書こうかな。しばらくはお休みしていた技術記事を書きたい気分。多分Rust周りかな。
あと、バイクを買い換える予定なのでそれについても書きたい。
その時はよしなに。
.
