20代~30代のキャリアを考えるブログ

若手のキャリア、転職についてインタビュー、意見を発信しています。

移転しました。

約1秒後に自動的にリダイレクトします。

WEBエンジニアと一緒に働けない営業、マーケティング部門の人たち

WEBエンジニアは怒っている。理解力のない社長、エンジニア出身のはずなのに要領を得ないPM、営業をはじめとする人たちに。もちろん優秀なPMやエンジニア出身社長や凄腕CTOがいてうまくコントロールしている会社もありそういった会社はエンジニアが定着している。今回はWEBエンジニア目線から見たビジネスサイドの話をしよう。

考え方が違うエンジニアとビジネスサイド

今回は自社サービスを有する、企業で働く複数のエンジニア(フロント、サーバー、インフラ各ポジション)に意見を聞いて記事にした。

記事を書くきっかけになったのが、Twitterで知人のエンジニアが退職した会社の問題点を指摘していたので、他のエンジニアの助けを聞きながら詳しく深堀してみた。

大手企業から数十人規模のベンチャーにいる方のあるあるを掘り出しているので該当する方は胸に手をあててほしい。

エンジニアとビジネスサイドはともに売上をあげるというゴールは共有できているにもかかわらずもっている意識の違いから対立がうまれる。対立がうまれる具体的な問題点に触れつつ述べていきたい。

ビジネスサイドの方に特にご覧いただきたい。

納期への意識の差

まず工数の見積もりに対しての意見の相違をよく見かける。営業部が「4月までに出してください」というのに対して、

エンジニア:「無理です、6月までかかります」

ビジネス:「なんとかしてください」

というやり取りを見たことがないだろうか。

 

営業部長や経営者だったら4月までになんとかして要求に応えようとする。なぜならば通常の1.5倍働いて、死ぬ気で働こうとする。量でカバーしようという発想が強い。

では、エンジニアはどうかというと、もちろん必要なときは無理をして(時には徹夜)、なんとかプロジェクトを完遂しようとする。技量の優れたエンジニアほどパワーもありチームを統率する。

しかし、4月までにする意味合いを見出せない場合が多く、今無理してがんばる理由がないのではと考えそこで議論が宙に浮きエンジニアとビジネスサイドの空気が悪くなる。

 

とあるインフラエンジニアが「プロジェクトの期限を強引にでも決めておかないと何も決められないし何もすすめられないと思っているビジネスサイドがいる」と発言していた。

これに関して意図を聞いてみたところ、期限を決めるのは大事なのだが、するべきことあるべき姿が決まっていて積んだタスクがあるのであればそのタスクから想定される工数に従って計画を決めるべきではないかという考えだった。

期限を決めたのであれば、がんばってやりきろう!というのではなく必要なことは何か優先順位は何かを議論し必要なものだけにしようという考えをもたないとダメだということであった。

必要なことだけ開発するというのはB to C 企業 と B to C 企業のどちらのタイプにもあてはまる。口で言うのは簡単だが実際に実行できている企業はかなり少ないのではないだろうか。

その方が嘆いていたこととして、長い目で見てよいプロダクトを作ろう、積みあがってある改善タスクをしようとみなで同意したにもかかわらず、翌日にはいきなり期限付きのタスクをはさみこみはじめ、それがずっと続き、昨日の話はなんだったんだ?と疑問を呈していた。

ベンチャーで働くとある程度、朝令暮改であることは発生することは理解している。一方で、朝令暮改であることを良いとする経営者が登場したとたん、とにかく思いつきで案だし朝令暮改しだす空気になる事で何も考えずに発言しているのかと半ば諦めの空気が開発陣に漂い始める。

朝令暮改を繰り返しすぎるとエンジニアが離れていくのは当然だろう。

一方、期限に関してビジネスサイドからの文句もでてくる。もっと早くできるだろう、がんばればできるだろうという声だ。

エンジニアによっては安全すぎるスケジュールを引き、1人くらい抜けてもほぼ100%約束のタイミングまでにデリバリーできるくらいのスケジュールをたてる人もいる。

もちろんこの考え方は悪くないが、ビジネスサイドからするともっと早くしてくれよ、もっとタイトなスケジュールを1回はひいてくれないかと思うのは当然だろう。

そこで双方が譲らない話が起きるのには理由がある。
エンジニアとしては、約束を必ず守れるスケジュールをひくべきであるため、できない約束をしないのは当然だろう。

その際にビジネスサイドとしては、なぜ多少のリスクを冒してでも早くすべきなのかという理由を説明すべきなのである。

競合は全く同品質で2か月早くしているため売上に深刻な打撃があるといった具合だ。
ベンチャー企業では特にそうだが、エンジニアもビジネスへの意識は比較的高く、売れない、意味のないものは作りたくないと考えている。

もちろん技術向上になれば、売上につながらなくてもいいと考えている人がいないわけではない。

エンジニアに無理をさせるときは納得をさせるコミュニケーションを時間をかけてでもいいからやってもらうべきである。

無理をするとき(経営的にキャッシュがやばいとき)を理解して助けてくれるが毎回そのようなことになっていたらたまったものではない。

長年エンジニアをやっている中年エンジニアに言わせると、WEB業界の環境が年々改善され、環境がブラックなWEB系の企業からはどんどん退職が相次いでいる。

市場環境もありエンジニアは引く手あまたであり、ある程度の技量があればそこそこの賃金で採用してくれる企業がごまんとある。エンジニア専門の転職サイトも増え、フロント、サーバー、インフラとも採用に困っている企業が非常に多い。

よって、このような状況から劣悪な企業からはすぐに逃げられる市場環境がととのった。給料も安く、理解の悪い経営者からはさっさと逃げればいいのだ。

待遇的な問題はさておき、給料はでているのにエンジニアの退職が多い会社がある。そういった会社の状況を見てみるといくつかの特徴があるので見ていきたいと思う。

エンジニアが語る思いつきへの対処法

プロダクトをつくっているとビジネスサイドや経営陣からどんどんあれやって、これやってと指示が飛んでくる。PMがじっくり考え長期的な計画はきちんと行わなければいけないのだが、そうでないものに関しては、思いつきでどんどん差し込みがやってくる。

とあるWEB系ベンチャーのフロントエンジニアはこの問題についての対処法として、その場で「やります」と答えて答えた後はやらないと答えていた。

彼曰く、1度思いつきでやってくださいと言われたことのほとんどは言った側も忘れており、もし2度同じことをやってくださいと言われたらそれは本当に大事なことだという線引きをし、長年WEB業界で高いパフォーマンスを出している。

一方まじめなエンジニアは言われたことを全部やろうとしパンクしてしまいうつ病等にかかってしまう。

この手法はいいか悪いかはわからないがまじめなタイプだと思う方は実践してほしい。人は思っている以上に覚えていないのだ。そしてビジネスサイドの方で思いつきで発言をしていたら果たしてそれが必要か自分のなかでも、そしてビジネスサイドで議論したうえで提案してほしい。

f:id:sportsmania:20180302202437j:plain

営業が勝手に約束しちゃった問題

営業が勝手に顧客と約束したから納期までにやらないといけなくなった経験はないだろうか。おそらく営業側もエンジニア側も心当たりがあるだろう。

先のフロントエンジニアは、営業にも同行し全部やりますといって全部やらなかったけど、何もクレームがこなく、そのまま自社製品を使い続けてくれたと言っていた。
「やります」ということで相手が喜ぶのでそれが大事だと極論にも聞こえることをいっていた。

さて話がそれたがエンジニアのあずかり知らぬところで勝手に営業部門が約束することはあるだろう。そうした際にどういった対処法がよいのか考えてみてほしい。

現実的に営業と顧客の約束を反故にすることはよろしくない。そのため、その場では実行しないといけないがこれでは営業側が全く学習せず同じことの繰り返しになってしまう。

そこで営業部に対して、追加でやるアクションのおかげで他の作業が遅れてしまうことを伝え、今後追加でやる場合はそのような弊害が出てしまうことを伝えてほしい。

追加アクションに限らず、要望への対処がどれくらい時間がかかるかがなかなかわかりにくい面がある。営業に工数の相場観をもたせるようにしてあげるのもめんどくさいがエンジニアとしてすべきであると私は考える。

『「とにかく」って言葉は、いよいよピンチになるまで使っちゃだめ。』というセリフがとても印象的で、説明もなしにとにかくやろうというのは本当によくないのだ。

とにかくというときに納得する場面はかなり少ないだろう。

このようにエンジニアとビジネスサイドの間におこる問題は様々ある。皆様の会社でも大小問題があるであろう。

エンジニアの方で転職を検討している方へ

エンジニアの方で転職を検討している方は、ビズリーチに必ず登録してほしい。エンジニア特化サイトではないが、総合的に良質な求人が多い。残念ながらエンジニアにとっていいエージェントがいるということは言えないが、企業の人事部門から直接くるのでそこを利用してほしい。

また、スカウトサービスではForkwell Scoutも多くの求人がくるのでおすすめだ。求人を見比べてみてほしい。すぐに登録ができる。

ぜひ今回の記事を呼んで振り返っていただけると幸いだ。