【エンジニア転職】こういう会社とは合わなかった

はじめに

SIerからWeb系エンジニアに転職しましたが約1年で転職しました。

プロダクト自体は自分のやりたいことでしたが、企業文化やエンジニア組織の在り方といったカルチャー面から働き続けていくことが難しいと感じたことが原因です。

そのため、今後同じような企業に入社してミスマッチすることがないように備忘録として記事を書きます。またこれからWeb系企業へ転職しようとしている人や現在転職活動中の人への参考になればうれしいです。

前提

• 事業が安定し始めている段階の企業
  在籍していた会社は創業期や企業の成長ステージのシードステージ・アーリーステージではなく、数百名規模で事業が安定し始めている段階でした。

• Web系企業を1社、約1年だけの経験の視点
  toB向けSaaSを開発しているWeb系企業を1社、約1年だけ経験した立場から見たときの特徴のため、自分の視野が狭く、もしかすると他多数の企業では当たり前の特徴なのかもしれません。

①CTOがいない

経営陣の中にCTOないし技術者の代表がいないことは、開発部門の意見が経営に反映されにくい・後回しにされやすいのではないかと思いました。

経営陣の中にCTOなどのポジションが設置されている企業の方が、会社としてテクノロジーや技術者を尊重しており、エンジニアの意見を受け入れてもらいやすいと思いました。

設置されているにしても、その方の経歴から過去の会社やどういった経験をしているかはチェックした方がいいと思います。個人的にはコンサルなど上流の経験よりも、実際に開発現場で手を動かしてきた経験がある方の方が安心感があります。

②エンジニアの割合が低い

営業・サポート部門など他の部門と比較して、開発部門に人件費を掛けていないことは、開発部門の立場が社内で相対的に低くなってしまうのではないかと思いました。

具体的な割合は伏せますが、在籍していた企業のエンジニアの割合は競合他社の約半分でした。

③創業者がコンサル出身

在籍していた会社では、創業者がコンサル出身でした。自分が実際にコンサル業界で働いたことがないため、偏見がかなり入っていますが、コンサルはクライアントから言われたものをそのままエンジニアに開発させている印象です。

そのせいか、開発は要望を出す営業・サポート・企画と話し合うような場がなく、言われたものをただ作るような体制でした。自社サービス開発というよりも社内で受託開発している感覚に近かったです。

また創業者の出身企業の体質は自社にも反映されやすいのかもしれませんが、恒常的に残業が多い状態でした。以前A社で違法残業が発覚したこともあり、コンサル業界は残業が多い印象です。

④個社の要望に対応している

ユーザーからすれば要望を反映してくれた方がうれしいとは思いますが、要望を1社からでも対応していると機能の複雑化・業務量の増加・小さなタスクがメインで技術力が向上させにくいなどのデメリットがあります。

個社からの要望を何でも開発するのではなく、複数社からの要望がある場合など要望を反映するための条件を設定していることやどのユーザーでも利用する汎用的な機能開発に注力する方針の方が上記の問題を回避できると思いました。

1回のリリースの機能数を確認して、あまりにも数が多い場合は気を付けたほうがいいと思います。

⑤機能ごとにチーム分けされていない

機能ごとにチーム分けされていない場合、様々な機能を担当することになる分、コードを読む力や複数機能で使えるような共通処理を考える力を向上できるメリットはあるとは思います。

一方で機能開発でも不具合調査でも、そもそもどういった機能なのかを理解することから始めなければいけません。機能ごとにチーム分けされている方が、処理や影響範囲を理解しており、速く正確に開発ができる傾向が強いのではないかと思います。

ただ同じ機能ばかり担当していると属人化や他の業務ロジックを考える機会が無くなってしまうため、一定の周期で他チームへ異動できる仕組みがある方が効率的で技術力を向上させやすいではないかと思いました。

⑥既存環境の改善をするチームや時間がない

機能開発とは別に既存の開発環境を改善するためのチームや時間を確保していないと、非効率なまま開発を進めることになってしまいます。

例えば、フロントエンド開発ではIEでもJavaScriptが動作するようにBabelを使わずES5で書いていました。その結果、コールバック地獄のコードになり、保守しにくいコードになってしまっていました。

開発効率の向上や技術負債を解消するなど、既存の開発環境の改善に取り組むチームや時間を確保していた方が、長期的にプロダクトを運用しやすいと思いました。

⑦要望の背景・詳細が分からない

要望を開発するときは、開発者はその要望の背景や詳細を知ることが出来ませんでした。要望を出す側からの開発依頼のテンプレートはありましたが、実装して欲しい機能のみが書かれているものがほとんどでした。

例えば、添付ファイルをDLしたいという機能では、表示されているページ単位で即時DLではなく、バッチで全ファイル一括DLしたかったなどで認識が違うということがありました。全ファイルDLしたいという情報があれば、即時DLだと時間が掛かり画面が操作できなくなるため、バッチの方がいいという提案ができたかもしれません。

開発する機能の規模にもよりますが、文字だけなど非同期でやり取りする場合は認識の齟齬が発生しにくい運用フローか、また要望を出す側と話し合う場がある方が想定したものと違ったとなることを減らせると思いました。

⑧社外へ技術的な情報発信をしていない

テックブログやミートアップなどで情報発信をしている方が、会社として技術を重視していることや社外のエンジニアへのアピールも積極的な印象があります。

またチーム体制やどのように開発をしているかなど求人票には載っていないことを知ることが出来るため、自分と合う環境かどうかも分かりやすくなります。

逆にあまり情報発信していないと、技術を重視しておらず、社外へのアピールに消極的だと思ってしまいます。

⑨人事評価にエンジニアが関わっていない

人事評価にエンジニアが関わっていないと、開発した機能数などどうしても技術者ではなくても分かる指標で評価されてしまいます。

自動テストを書いたことでバグの早期発見、リファクタリングにより保守性を向上させたことなどで貢献したとしても、技術者ではない人からするとプロダクトの表面上は変化していないため、成果が伝わりづらくなってしまいます。

エンジニアの評価はエンジニアが行うことや、技術的な観点でも評価してもらえる方が、技術者としてモチベーションを高く持って働くことが出来ると思いました。

最後に

改めて列挙してみると、少し調べればエンジニアとしては働きづらそうと思うような特徴が多く、自分の情報収集不足を痛感しました。

大雑把にまとめると、「技術を重視しておらず、エンジニアの立場が低い会社」だと思います。

もちろん会社やフェーズによっては当てはまる特徴もあると思います。例えば、創業期はそもそもエンジニアが少ないためチーム分け出来ない・開発環境を改善している時間がない場合などです。ただ前提に書いた規模やフェーズの会社の場合は注意が必要です。

色々と書いてきましたが、エンジニアとしてのキャリアをスタートさせてもらうことができ、開発経験を積ませてもらったことは感謝しています。

現在は退職して別の会社で働いていますが、もしまた転職することがあった場合は上記に書いた特徴に当てはまっていないかかどうか確認した上で転職したいと思います。(全部に当てはまっていないというのは難しいかもしれませんが）