エンジニアはマネジメントのスキルよりも営業のスキルを上げた方がお金が稼げる
弊社のセミナーに来てくれた、とある営業さんから言われた一言。
「エンジニアさんが営業ができるようになったら我々営業は不要なので、 切られないように勉強しようと思ってセミナーに参加しました」
元々私自身が営業職を経験してからエンジニアに転職したので営業さんの大変さはとてもよくわかる。 そしてビジネスにおける営業の不可欠さは重々承知している。 良いビジネス、良い商品やサービスでも営業が破綻していたら商売にならない。
すでにある市場で、能力のあるものがほぼいないので超特殊状態ではあるが、 エンジニアの皆様は営業スキルを覚えてしまえば少なくとも年収は1.5倍にはなる。 エンジニアの方にはマネジメントスキルを覚えるよりもお金になるので個人的に強くお勧めします。 ちなみに営業はコーディング規約覚えるのに似ていて、特殊なスキルなんて要りません。
せっかくなので、なぜ我々IT業界の営業が破綻しているかということについて具体例を挙げて説明したいと思います。 最初に言っておきますが私とこの記事に悪意はありません。 デキる営業さんは本当に尊敬しています。
ケース１：勉強をすることがないので壊滅的に知識がない
この前聞いた怖い話。
— あれっくす@今の現場は外苑前 (@MHTcode_Alex) 2017年1月19日
ITの営業が若手のエンジニアに「JSPってなんですか？」って聞かれて「ああそれはね、JavaScriptのことだよ」って説明してたらしい。
もう平成も終わるのにね、こんな営業ばっかりっすよ。
IT営業の怖い話。
— あれっくす@今の現場は外苑前 (@MHTcode_Alex) 2017年1月19日
スマホアプリのエンジニアはサーバのエンジニアよりも技術力が低いと思ってるらしく、普通に聞かれたことある。
「アプリ作ってる人とサーバ作ってる人だとどっちの方が技術力高いんですか？」って。
水道屋がコンクリ打つのか？って思った。
これらはネタとしてTwitterでツイートさせてもらっていたがこの業界は営業が壊滅的に知識がない。
分野やジャンルが広いし、情報の更新スピードがとても早い業界ではあると思うが、営業の知識がないレベルは桁が違う。 車のバイヤーが、なんで車が動いているのかを知らないレベルで車を売っているのだ。 トラックと軽自動車を同じ感覚で売り歩いているのだ。 エアコンが欲しいお客さんに対して、USBのホットプレートを持ってくることも普通にある。
お客さんにとって危険なものを売りつけることは当たり前だし、 商品となるエンジニアリングを提供するこちら側もたまったものじゃない。 私の体感値ではあるが営業が知識がないことで迷惑をかけられた経験と、 知識があることで助けられた経験を比較すると９９：１だ。 最近では信頼できない営業とは会話をしないで顧客と直接会話するようにしている。 その方が関係者全員が不幸にならないからだ。
知識がないことの原因は実にシンプルでとにかく勉強をしない。 残業ばっかで〜、仕事が忙しくて〜、私は文系出身なので〜と、できない理由を見つけてきては勉強をしない。 とある営業は「会社から月に１度はセミナーに参加しろって言われてて〜」なんて言うから 弊社のセミナーを紹介したのに、たったの１度さえも来たことがない。 もちろん自分で探して弊社セミナーに来られる方もいらっしゃいます。 そういう方はとても信頼のできる営業さんだと私は判断していますので、悪しからず。
エンジニアの技術的な専門用語を使う打ち合わせでは会話にならないし、 プロジェクトマネジメントの用語も知らなければ、自分の仕事に関する法律も知らない。 営業としての必要だと思われる基礎的な話法も、ビジネス用語も、コーチングの知識も知らない。
知らなくてもエンジニアという専門家が何とかしてくれるから無知なままで居られる。 この無知な人たちにIT業界は営業をさせている限り、まだまだ問題は多発する。 いずれは淘汰されるとは思うけれど。
ケース２：自分の頭で考えることができないし、連絡係もできない
私はFAXやプリンタ、電話回線や金融商品と物もプランも売ってきた。 営業を通して顧客や見込み顧客の抱える悩みを解決すると、商品やサービスのあるべき姿が見えてくる。 持ち帰った情報を商品部や、管理部と会話をしてより良い商品やサービスに改善するとチームもお客さんも喜んでくれた。
ITの営業に関しては他の業界の営業と同じように考えてはいけない。 彼らが問題を解決できる能力は皆無に等しいので期待してはいけない。 もし顧客の問題を解決していることがあるとすれば、一緒にミーティングに参加していたエンジニアの力が大きいだろう。 新しい商品やサービスの提案をすることもなく、ただ金額と条件の調整をコウモリのように行っているだけだ。 解決してくれるのは誰かであって営業である自分は当事者ではない。 彼らはお客さんと一緒に、いつでもヒーローを探しているのだ。
ーこんな話がある。 大手金融機関からスマホアプリの内製アジャイル開発チームを作りたいと、 要望があったので相談に乗ってもらえないかと言われ、打ち合わせに参加した。
打ち合わせにはビジネス的にどういうことをやりたいのか、 ビジネスとアジャイルが本当に合っているのかを確認しに行った。
アジャイルはお金も時間もかかり、失敗を受け入れないといけないので、 よくよく社内調整をなさってから始めた方が良いですよ。とアドバイスをした。 私に「ぜひチーム作りに対して監修してほしい」とのことだったので お金は要らないんで知人としてなら相談に乗りますよ、とだけ伝えた。 大きな企業はお金が動くまでに時間がかかるので、 お金にならない仕事ならお請けできないことはやんわりと主張させてもらった。
後日、営業から顧問をするための契約を作っていると言われたが、 「何をやるのか決まってないのにお金なんて出ないでしょ」と話した。 これに対して「打ち合わせするのにも、秘密保持契約などを結ばないといけないので 契約をしないといけない」と言われたのでもう深くは突っ込まないことにした。
しばらくして営業と話すと「提案をしたのだが、監修をする契約は実際にチームが立ち上がってから 入れるエンジニアの費用に上乗せしてお支払いしたいと言われた」とのこと、 「とにかく御社のエンジニアをください」「いなければ探してみてください」と言われ私は苦笑した。
私は「エンジニアを探すにしたって何がやりたいのか、何のスキルが必要なのか、 どんな条件や環境なのかがわからなければ探せないよ」と伝えた。 「じゃあ私がエンジニア探してきますんで提案できるか判断して下さい」と言われたが、 「何を以って適性を判断すればいいのかを私は知らないので、それを教えてもらえないと判断できない」と強く伝えると 「お客さんに確認してくるんで内容をメールにしてください」と半ギレで言われた。
この営業の仕事は一体なんだろうか？ 自分の頭で考えることができないだけではなく、自分の仕事さえも放り出している。 我々エンジニアでこんな人間が居たらお客さんからだけでなくチーム内でもボコボコにされる。
この営業さんには丁寧に項目分けした確認内容をメールで送ってあげて、 これがわからない以上は協力できないのでお断りしますと添えてあげた。
ケース３：継続的な取引ができない営業は人を見下している
営業だから今日の数字を追うことは理解している。 今日の数字にならないのであれば時間を割く優先度が下がるというのも理解している。 私も営業の頃は同じように考えて行動していた。 だけど意識的に月に１回は過去の見込み客や、過去に取引していたお客さんに営業していた。 そこから数字が上がると、新規に上がった数字よりも愛着が湧くのでとても嬉しかった。
ところがこの業界の営業は１度でも取引をやめると、エンジニアに連絡してくることはほぼない。 「担当している現場が多いのでエンジニアのことを覚えてられないんですよねw」とエンジニアの私に言ってきた営業もいる。 その場しのぎの数字を出すことに注力している営業が大半なので、いずれボロが出て辞めていく。 こちらが世の中で普通に商売をしていれば、勝手に向こうから脱落していってくれるので楽で助かってます。
また多くの営業はお客さんとのスケジュールを優先をして、 エンジニアとのスケジュールは平気でリスケとドタキャンを繰り返す。 こんな人間がいたら友達でも嫌になる。 そんなことを対等である取引先のエンジニアに対して平気で繰り返しているのだ。 この行動は、心理学上「見下している人間」に対して行う行動だそうだ。
当然のようにその営業が所属している会社の品位を疑うようになる。 だが面白いことに疑った目で見てみると、その会社の他の営業も等しく同じ場合なことが多くて 今では逆に取引先与信として役に立っているので我々にとってみれば怪我の功名でした。
ケース４：業界内外でも困ったちゃん
とあるIT企業グループの人事は営業職の採用は、同じIT業界からは絶対に採らないと言っていた。 シンプルな理由で「使えない人が多いから」とのことでした。 とあるメーカー系のグループの人事と管理職の人たちもIT業界からの営業は絶対に採用しないと言ってました。 シンプルな理由で「仕事ができない人が多いから」とのことでした。
業界の内外でも取り扱いに困っているそうです。 とても雑になりますけど、まぁ頑張ってください。
システム開発に必要なのは理数系のスキル？
「スマホアプリの開発をやっている」と知人や友人に説明すると、よく「俺は理数系得意じゃないからできないな〜」と言われます。 確かに私も理数系が得意であればもっと良いプログラミングができるんだろうなと思うことはありますが、必ずしも必須じゃないです。
必要なのは理数系スキルではなくて論理的な考え方と想像力
システム開発で重要なのは論理的な考え方と想像力です。 微分や積分の公式だとか、接弦定理を知らなくても問題ありません。 システム開発のお仕事というのは下記のような課題を解決することを繰り返します。
「１という数字を"いち"という平仮名に変えたい」
これに理数系スキルはあまり必要なく、論理的な考え方と想像力で作業を進めていきます。
・１という数字の型がintegerなのか、2byte文字なのか ・数字型だったら文字型に変更した方が使いやすいかな ・よく使いそうな機能ならいつでも使えるようにしておこうかな
これを料理で例えてみます。
「じゃがいもをフライドポテトに変えたい」
この問題を解決するためには以下のような行動が取れます。
・じゃがいもは皮をむかないといけないのか、皮付きでもいいのか ・皮つきのポテトじゃなかったら、皮をむいていたほうが使いやすかな ・よく皮をむくのなら包丁じゃなくて皮むき器のほうがスピードが速いかな
同じように論理的に考えて、想像力を使って便利にしているだけなのです。 これはシステム開発だけでなく、あらゆる職種で必要とされているスキルです。
文系と理系の違い
これは諸説あるんですが、私は以下の基準が最も確からしいかなと考えています。
文系 … 考える時の基準が自分が正しいと思うかどうか：主観的 理系 … 考える時の基準が自分以外の事実で判断する ：客観的
「数学は表現方法の１つ」という言葉
これらはすべて数学的な要素があります。 恥ずかしい話ですが私は中学生の時は音楽やイラストを描いたりと、芸術の道に進みたいと思っていましたので理数系の勉強については得意だと思ったことがありませんでした。 むしろ数学が役に立つわけない信者の１人でした。
覚えていないのですが過去に見た映画や本の中で「数学は表現方法の１つ」という言葉がとても印象に残り、それ以来数学的なことが好きになりました。 「愛してる」という日本語は「I love you」という英語に変換することができます。 英語が話せる人は世界が違って見えるんだろうかって思うことがあります。 それと同じで数学ができる人は世界が違って見えるんだろうかと思うようになりました。 ロマン大事です、ロマン。
デザインに関しても同様です。 可愛いは作れますが、客観的に伝えれるように定義することができません。 美しさは作れますし、客観的に伝えれるように定義することができます。 「黄金比」というキーワードがそれに当たります。
黄金比とは、黄金比を使ったすごいデザインテクニックのまとめ -Webデザイン・紙デザインに | コリス
私は個人的な趣味でデジタル一眼で写真を撮るのですが、これを意識している写真と意識していない写真では同じカメラで撮っているのにまるで違います。 芸術的なことにも実は数学が使われているということがわかった時はますます数学的なことが好きになりました。
まとめ
連日、ビジネス的なことを書いてきて飽きたので今日は雑談です。 皆様も日常生活で数学的なものを見つけたらロマンを感じてみてください。 くだらない話ですいません。
即戦力って何？（ハナホジー）
我々エンジニアの業界だけでもなく、どこの業界でも人手不足との声が聞こえてきます。 「本当に人が足りてないの？」と聞くと「実は、即戦力になるような人材が採用できない」と言われることが多いです。 私は頭が悪いので「即戦力」と言われても具体的なイメージが湧きませんので、「大変ですねー」と言うことしかできないのですが、このようなことが起こらないように弊社で実施していることを書こうかと思います。 もっといい方法などあったら教えてください。
マンハッタンコード全体で取り組んでいること
仕事の生産性や技術を向上させるための仕組みは人によって違うため方法は多種多様です。 ですが世の中にはこの仕組みを持っていない人もたくさんいます。 弊社ではこれを真摯に受け止めて、社員の個人を尊重しつつ最低限のやり方を覚えてもらっています。
資料なしLTでも、セミナー形式でも発表はガンガン推奨：方法の共有
運転する方法を知らなければどんなに速いスポーツカーを持っていても走ることすらできません。 これと同じで優秀な参考書をたくさん会社が買い与えても、勉強する方法がわからなければ習得スピードは向上しません。
弊社では社員が各自で持っている良い仕組みをみんなに共有しています。 共有の形式は様々でLT方式で説明する人もいますし、資料を作ってからセミナー方式で説明する人もいます。 これは社員だけでなく他社の方もよく参加してもらっています。 知りたいのはみんなが取り入れたらよくなる行動や方法なので効果測定などは行っていません。 「いいものがあるのよ〜、奥さん〜」のノリです。
ペアプログラミングの導入：経験の共有
新しい技術について自ら本を買って勉強したり、ネットで調べて勝手に一人でやっていける人もいます。 しかし悲しいことにどんな業界のどんな職種でも、これができる人は圧倒的に少人数です。
世の中には大衆的な飲食店でも独りで初めてのお店に入れない人の方が多いのです。 私も小さな子供の頃から親や兄弟といろんなことを一緒に経験して大人になってきました。 経験は共有することのできる行動です。
この考えを基にして弊社では「まず一緒にやってみる」ということを意識して行っています。 例えば、ずっとサーバの開発しかしてこなかったエンジニアさんが「iPhoneアプリ作ってみたい！」となったら、iPhoneアプリのエンジニアさんが隣で一緒にツールを動かしながら作ります。 AWSを触ったことのないエンジニアさんがいれば一緒にサーバを立ち上げてみます。
同じ場所にいなくても継続してできるようにScreen Heroというツールの導入しました。 このツールは同じ場所にいなくても自分のPC画面を共有することができ、共有される側もソースを書くことができるのでペアプログラミングに最適です。 xcodeでも使えるので、とても使いやすくおすすめです。
Screen Heroでペアプログラミング - 髪も切れるiOSエンジニアのブログ
おまけの実例紹介
先日は私が「調べる」ということをテーマに１０分間のLTを行いました。 発表する前日に思いついたので資料は用意できませんでしたが、ホワイトボードに要件を書いてLTを行いました。 はじめはテーマだけ聞いて「調べるについて発表？」と首をかしげていた人もたくさん質問をしてくれたりして嬉しかったです。 LTが終わった後に「単純なことだったけど、言葉や図にしてもらってわかりやすくなった。意識してみます」と言ってもらって嬉しかったです。
目的と狙う効果
個人で勉強するスピードが向上する
運転の方法というのは実は軽自動車でもトラックでも基本は同じです。 車種によって注意することは違いますが、運転する方法を学んでいる人であれば覚えるのも早いです。 これと同じで１つの技術を覚えてしまうと２つ目の技術を習得するスピードは圧倒的に上がります。
まだ人数は少ないですが、弊社ではほとんどの社員がたった１年でswiftでiOSアプリを作り、AWSでLAMP環境によるアプリを作れるようになってます。
勝手にコミュニケーションが取れる
弊社では「コミュニケーションを円滑にするために飲み会を開く！」なんてことは一切していません。 ですが他社の方たちからはよく「みなさん仲が良いですね！」と言っていただけます。
勉強でも作業でも一緒に行動することで嫌でも言葉が増えます。 説明するには会話が必要です。質問するのにも会話が必要です。 勝手に言葉を交わすことになるので自然とコミュニケーションが生まれます。
影響とリスク
社内の雰囲気が変わる
勉強することは良いことだ！楽しいことだ！という雰囲気になります。 「勉強しないとなー」と社員が口にする回数も減ってきました。 そして今では「勉強しないとなー」という言葉は「悔しい！！」という意味に変わりつつあります。
自発性が生まれた
「〜について発表してみんなの意見を聞いてみたい」「〜さんが来たら〜のことを聞いてみよう！」という自発性が生まれています。 何より社員本人が充実してそうな姿を見れることが非常に嬉しいです。
リスクは時間がかかること
１人でやることに比べたら２人でやる方が時間は２倍かかります。 独り立ちした後のスピードが圧倒的に早いので私は十分に元が取れると考えていますが、投資の初期コストをケチりたい人にはおすすめしません。
まとめ
弊社がまだ小さい規模だから実施できているのかもしれませんが規模なんてただの数字です。 いいと思う、いいと考えるのであれば小さく始めればいいだけです。 １００人規模の会社だったら、最初は５人くらいと一緒にやってみる。 できそうだったら徐々に横に展開すればいいだけです。 自分の行動が変わらなければ周りも結果も変わらないです。
この取り組みから弊社は長く運営をしていけばいくほど、他社に比べて有利にビジネスを進めることができると考えています。
ビジネスが下手くそな人ほど移動時間をコストとして見れない
ビジネスにはリソース（資源）となるものがあります。 有名なのは「ヒト、モノ、カネ」ですが、本当はここに「ジカン」も必要です。 我が社が行っている生産性向上の取り組みの１つを紹介します。
マンハッタンコード全体で取り組んでいること
原則、社員の自宅最寄りから現場への通勤時間は基本的に30分程度にする
ただし本人の希望により変更は可能です。 弊社は東京に会社があり、お客さんも東京ですので基本的な移動方法は電車を使います。 この移動を極力30分以内にしています。 東京駅から横浜駅は26分で移動できます。 30分以上も電車乗るとか、東京の人間にとっては単なる旅です。
弊社所在地に対して45分以上かかる場合は補助金を出して引越しを提案する
ご家庭の事情などは十分に考慮させていただいております。 当然郊外に比べて家賃は高くなりますので、そこは会社から幾分か補助しています。
目的と狙う効果
小さな行動の積み重ねが効果を生みます。
営業交通費の圧縮
遠ければ遠いほどお金かかります。 得られるお金が決まっている契約の場合はお金がかかればかかるほど事業としてはマイナスです。 ケチくさいかもしれませんが毎日移動にお金を使うくらいだったら新しい備品買います。
社員個人の時間確保の向上
遠ければ遠いほど疲れが溜まります。 社員のモチベーションが下がる要因は容易に見つかりますが、上がる要因はありません。 弊社ではこの取り組みにより確実に他社より個人の時間を確保することができます。 これがモチベーションと個人の勉強時間の増大することとなり、 他社よりも技術力の向上スピードが早いです（自画自賛）
具体的な数字で見る通勤時間
通勤時間の世界平均は32分30秒で、これに対して日本の平均は39分30秒でした。
平均の通勤時間、知っていますか? | 業務基礎スキル診断株式会社
たいした違いがないように見えますが、これを日本国内に限って分析するとかなり違います。
東京圏 51分 大阪圏 43分 人口30万人以上の地方都市 34分30秒
大都市ほど通勤時間が長いのです。 調査によっては大都市の通勤時間が1時間を超えるものもありました。
通勤時間の平均は往復1時間19分、大都市圏勤めほど長い傾向(2016年)(最新) - ガベージニュース
首都圏は電車バスなどの交通機関が発達してしまっているので、 車通勤がメインの地方都市よりも時間がかかっているのが大きな要因です。 大都市の通勤時間が日本の通勤時間平均を引き上げているということがわかります。
仮に毎日3時間近くを通勤に費やすと60時間も移動してます（月20日出勤x往復3h） 年間では720時間も移動します（12ヶ月x60h）
影響とリスク
毎日満員状態の電車に乗ることでストレスや疲れが発生しやすくなります。 特に最近の東京の埼京線、東西線などの満員状態は異常です。
冬の時期は流行病に罹りやすくなります。 私の知り合いは電車に乗っているだけで押し潰されて骨折しました。 同じ業界の知り合いは業務で使用するPCを壊されました。
電車内の乗客同士で起こったトラブルは鉄道会社は関与出来ず、 警察や弁護士を入れて当事者同士が対処することになります。 こうなると時間とお金が大量に費消されていきます。
弊社では遅刻してもいいのでちゃんと状況を把握して、 リスクは見送るように社員にはお願いしています。 これは他の作業のリスクコントロールにおいても良い影響を与えてくれています。
頭のおかしい人間や、考えが古い老害は「たかが満員電車くらいで」などと反論してきますが、 この精神論はお金も時間も生み出しません。 聞く価値はゼロどころか確実にマイナスなので聞き流しましょう。
まとめ
通勤時間が長い事のメリットとしては「本が読める」「ゲームができる」などが挙げられますが、そんなものは抱えるリスクと、抱えない時のメリットに比べるとカスです。 電車を降りてからゆっくりカフェで本読んだ方がよっぽど内容が頭に入ります。 家に帰ってからダラダラとゲームやった方が絶対楽しいです。
ただこういう細かい内容について考えたり施策を実施したりする会社はほぼないので、 弊社は有利にビジネスを進めることができるという証拠の１つとしてはありがたいです。
ブログ始めました。
うちの社員さんたちにブログやればいいじゃんwとか言っておいて、自分がやってないと批判が出ると思ったので始めました。
プログラミングとか技術的な内容は正直Qiita使えばいいと思ってるので、こちらのブログは会社の経営だとかビジネスだとかそういう内容を書いていこうかと考えています。
よろしくお願いします。
