入社4年目の営業がエンジニアに転向した話

Adways Advent Calendar 2018 12日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2018

こんにちは、自社広告サービスの開発・運用を行っているエンジニアのFです。
タイトルの通りですが、もともと営業をやっていました。

アドウェイズの歴史を見ても、営業がエンジニアになるのは非常に稀なケースです。
そもそも営業でエンジニアになろうと考える人がいるのかな？という感じですが、それを実行した話を書きます。

基本情報

入社年：2013年(新卒入社)
学歴：文系大学卒
営業歴：3年半
- 業務内容広告出稿主に対する企画営業
エンジニア歴:2年
- 業務内容自社広告サービスの運用開発

▼営業時代

新卒研修を経て配属されたのはweb系のクライアントを中心に抱える部署です。
web系の中でも月額モデルやリード系、携帯キャリアのプラットフォームのコンテンツのプロモーション等々を担当していました。
このようなweb系の案件の場合、自社アフィリエイトサービスの販売が中心となります。
プロモーションを行うコンテンツの属性に合ったメディアの提案や掲載施策の調整を行い、担当するお客様の要望を叶え、喜んでいただくという点でやりがいのある仕事でした。

▼何故エンジニアになったのか

理由は色々あるんですが、エンジニアという職に興味を持っていた点が大きいです。
元々、学生時代にPerl言語で書かれた無料配布のブラウザゲームをユーザとして遊んでいました。
ある日その開発者がサイトを閉じるということで引き継ぎ先を探していたところに、自分が手を挙げて引き継いだということがありました。
勿論、それまでの人生でプログラミングなど経験がなかったので、1から見よう見まねでPerl言語を学びました。

当時はDBの存在も知らずテキストにデータを書き出す(笑)という愚かな行為をやっていましたが、これがエンジニアに興味を持つきっかけとなりました。

また、上述の通り、クライアント営業を3年半やっていました。
業務内容としては特に大きな変化はない状況で、新しいことを欲していた時期でもありました。
そんな中、同期のエンジニアに相談をしていたところ、今からでもエンジニアになれるよ！という話を聞き、やってみたいということでエンジニアに異動したい話を本部長に持って行き、実現することになりました。

普通の企業だと営業からエンジニアに転向するということはあり得ない話だと思いますが、やる気があれば挑戦するチャンスを与えてくれるアドウェイズだからこそ実現したことだと思います。
本当にありがたいです。

▼ここが違うよエンジニア

営業からエンジニアに転向して、ここが営業と違うなーと感じたことを個人的に印象的だったもの3つをピックアップしました。

1.自身のタスクが明確な為、仕事を進めやすい

開発手法にも依ると思いますが、基本的に案件の調査〜リリースするまでの一連の流れを複数の工程に分けて、一定期間単位で何をいつまでに終わらせるかを明確にするので自分のタスクの進捗を追いやすく、遅れている場合は何かしらの形で事前に調整・対応が出来るので、仕事を進めやすいと感じました。

また、メンバー1人1人のタスク内容や進捗を把握出来るので、チーム内でメンバー間での意思疎通やサポートをし易いのも良いです。

営業だと担当クライアントからの依頼や相談が突然来るので、事前に自身のタスク・スケジュールを決めておいても、その通りに進まないことも珍しくないです。
都度、営業担当者が依頼の優先度を考えて、現状のタスクに対してどう入れ込むのかを考えないといけないので、タスク管理も大変です。
タスク管理が上手くないと区切りが分からずに、ただただ遅くまで仕事をすることにも繋がりやすいかと思います。
　　　　

2. 新しい技術がどんどん出てくるので、学ぶことが多い。

エンジニアの世界に入ってきて大変だと思ったのは、学ぶ量の多さですね。
プログラム言語だけではなく、ミドルウェアやシステム一般知識、インフラ知識、設計、サービスの仕様等々範囲が広く、新しい技術が次々に世の中に出てくるので、学ばないといけない範囲と量が多いです。
エンジニア力は経験や知識量がものを言うので、新しい情報を拾う動きと自身が拾えていない領域をカバーするということをしないと、活躍することは難しいと思います。

3.より本質的な部分を理解することへの意識が強い

エンジニアとして働くようになって頻繁に聞く様になったフレーズが「この意図は何ですか」という言葉なんですが、意見を1つ言うにしても、コードを書くにしても、その意図や目的、背景などを理解しようとする傾向が強いなと感じました。
勿論、営業もクライアントや各方面との間に立って、調整を行う立場なので、コミュケーションミスが起きない様に、コミュニケーションを取る際には本質的な部分を探り認識の相違がない様にしていると思いますが、よりエンジニアは徹底し、認識のすり合わせの粒度が細かい印象を受けました。
それはエンジニアの業務が関係していると思いますが、何かを開発するにしても、その背景や本質的な部分を誤った理解・認識のまま開発を進めた場合、実際に必要だった機能からはかけ離れたものを開発してしまい、それまでの工数が無駄になる恐れがある。
また、開発するそのコード1つでサービス全体に影響を及ぼす恐れがあり、最悪な場合、サービスが停止することもあります。

意図しないコードがプログラムに組み込むことはリスクでしかないので認識のすり合わせや意図などを細かく探ろうとする様になっているのが大きいかと思います。