paiza times

paizaがお届けする、テック・キャリア・マネジメント領域における「今必要な情報」を届けるWebメディア

logo

paizaがお届けする、テック・キャリア・マネジメント領域の「今必要な情報」を届けるWebメディア

転職して3ヶ月のWebエンジニアが入社後のことを振り返ってみた

f:id:paiza:20190712174825j:plain
Photo by Open Knowledge Foundation Deutschland

清水です。paiza(ギノ)に入社して3ヶ月くらいのエンジニアです。

今回の転職をしてしばらくたったので、前職とのいろいろな違いや気づき、転職について振り返って思うことなどを書いていきます。

転職に興味のあるエンジニアの方や、転職したいけど不安があって踏み出せないといった方の参考になればと思います。

簡単な経歴

情報系大学→新卒で受託開発企業に入社→小規模な自社開発企業→大規模な自社開発企業→paiza(ギノ)

大学から情報系を専攻していて、そのままエンジニアになって10年くらいです。

なぜ前職を辞めたのか

一言で言うと、事業部と開発部にめっちゃ壁があったから

前職では事業部と開発部が完全に分断されていて、エンジニアは事業部が決めたものを作るだけ・そこに提案や意見は必要ない…みたいな組織構造でした。

「そんなもん面接のときに確認しておけや」と思われるかもしれませんが、いや確認したんですよ。で「部門間の壁はないですよ〜^^」と言われていたんですけど、いざ入社したら「いやめっちゃ壁あるやんけ」という感じでした。

ただ、やっぱり見抜けなかった自分も悪かったと思っています。振り返ってみると、面接で人事の人に実務の質問をしても、よくわからなくて「大丈夫だと思います!」みたいな答え方をされてしまうケースもありました。内定後の面談でも、質問の答えで「ちょっと思っていたのとは違うな…」と思ったのに、「まーでもせっかく内定出たし…」となんだかんだ自分を納得させて入社してしまっていました…。

転職時に合わない企業を見分けるには

だから転職を考えているエンジニアの方は、気になることがあればそれがちゃんとわかる人、エンジニアであれば一緒に働くエンジニアの人たちにちゃんと実態を聞いたほうがよいですね。特にできれば選考の序盤で。今はカジュアル面談でエンジニアが出てきてくれる企業もたくさんありますし。

paizaのカジュアル面談」について詳しくはこちら

また、選考を重ねていく中でエンジニアと人事で言っている内容が違ったり、ずれを感じたりする企業は、開発部門と採用部門で距離があったり意志の疎通がとれていなかったりすると思うので、それも見分けポイントだと思います。

私も「やっぱり事業部と開発部の間に壁がない組織で、もっと事業面からかかわれる仕事がしたいな…」と思うようになっていって、2年くらいで転職を決意しました。

転職活動について

今回の転職活動では転職エージェントやpaizaを使っていました。ギノに応募したのも、paizaを通してスカウトメールが来たからです。

paizaの存在は初めて転職したときぐらいから知っていて、サービス自体に興味もあったんですが、選考中に印象的だったのは、最終面接のときに出された課題ですね。

「エンジニア目線でも事業目線でもいいから、今後どうすればpaizaをもっとよいサービスにできるか提案してください」みたいな課題だったんですが、普通にもう社員みたいな感じでpaizaの今後について話しあえる感じでした。これがすごく楽しくて、前職ではそんなふうにエンジニアがサービスや事業について考えたり提案したりすることを求められなかったので、「こんな仕事がしたいな〜」と思って入社を決めました。

今なにしてるの?

いろいろやっているんですが、メインはpaizaの既存システムの改善ですかね。特に今は全社的に技術的負債返済の動きがあり、ユーザ向け、企業向け、バックオフィス向けのシステム改善を実施しています。

負債返済の取り組みについては、開発チームリーダーがこちらの記事で詳しく書いています。

paiza.hatenablog.com

ちなみにこれはリーダーの発言です。言質をとったのでリーダーの金で肉が飲みたい。

f:id:paiza:20190712160430p:plain

ただ、もちろん負債返済は長期的に見ればプラスになることです。負債から目を背け続けても、結局自分たちが損することになります。一方で、もちろん負債返済に注視し続けても企業としての利益を出し続けるのが難しくなってしまいますから、そのへんはバランスの見極めが必要です。

前職との比較や3ヶ月を振り返って感じたこと

開発チームについて

エンジニアのサービス志向について

前職では、よくも悪くもサービスに興味がない技術志向のエンジニアか、もしくはサービスにも技術にも興味がない人が多く、まあどちらにしろエンジニアで事業に興味を持っている人は少なかったです。前述の通り、サービス志向を持ったところでそれが評価されるような組織ではなかったので、ある程度は仕方のないことだったのかもしれませんが…。

今の開発チームは、エンジニア全員サービス志向が非常に強く、事業に対する関心が濃いです。もちろん、paizaがエンジニア向けのサービス(=自分たちがターゲットになっているサービス)だからというのもあると思いますが。

決まったものを作るだけではなく、エンジニア側からも提案ができたり、立ち上げ段階から意見を聞かせてくださいとアサインされるケースも多いです。部門をこえたデザインレビューやアイデアソンも当たり前のように実施されています。

「決められたものを作るだけの仕事がいい」って人もいるかもしれませんが、私は事業を作っていく段階からかかわりたい人間なので、そのへんは希望に合っています。

スペシャリストか、ジェネラリストか

前職のいいところは、特定領域のプロフェッショナル的な存在の人がいて、技術的な困り事があったときに相談できることでした。

別に相談できないわけでは全然ないのですが(むしろ相談自体はしやすいです)、今はどちらかと言えばジェネラリスト寄りなエンジニアが多い開発チームとなっています。というのも、paiza(ギノ)はまだまだエンジニアの数が足りておらず、(エンジニア絶賛募集中なので興味のある方ぜひ応募してください)「割となんでもやりますよ」っていう、手を動かせるエンジニアを増やしていかなければならない段階にいます。

一方で、最近は負債返済などを進めていくにあたっては「特定分野の技術に精通しているスペシャリストの意見がほしいな…」と感じる場面も増えてきています。技術顧問的な人が、ときどきでもいいからいてくれるとありがたいなぁ。…って話は会社ともしていて、要望をあげているので、そのうちかなうと思っています。

エンジニアの自走力について

※ここでは、自走力を「その場その場で必要なことを考え学び動ける力」とします。

正直、前職では自走力の足りないメンバーが多めでした。たとえば何か新しいツールや技術を導入しようと思っても、教育コストがめちゃくちゃかかってしまうのです。実際、私は教育係をすることも多かったのですが「こんなにコストがかかるなら、諦めて旧来のツールを使い続けたほうがましでは…」ってケースも多かったです。

今はみんな自走力が高く、改善や習得のために自発的に行動できる人が多い印象です。新しいものを作ろう・使おうというときも、そんなにコストをかけずにそれぞれでそれなりにやれるし、前提知識のレベル感にそれほど格差がないし。知見を共有するために社内勉強会などもひんぱんに実施されています。

組織全体について

コミュニケーションについて

前職は事業部に確認をとるだけでも時間がかかるし、チャットなどのツールもあまり使われていませんでした。大企業だと意思決定に時間がかかってしまうのはあるあるですが、チャットよりもメール中心の文化だったり、部門ごとに閉じたコミュニケーションになりがちだったり…というのは前時代的だったなと思います。

今はコミュニケーションはSlackが中心で、みんな何か投げるとすぐにレスしてくれるから、ペンディングするようなこともなくなりました。もちろん実際に顔合わせる機会も多いので、オフラインの場でも聞きやすいです。

ただ、多分これは、今の組織がそれぞれの顔と名前と役割を把握した上でコミュニケーションをとるのにちょうどいい規模感だから…というのもあると思います。

これからもっと人が増えて会社が大きくなっていけば、全員と直接コミュニケーションをとりあうのは難しくなってくるでしょう。そのへんは今後どうしていくか、組織の拡大にあわせて考えていかなければならない部分ですね。

あと、事業規模に対してエンジニアが圧倒的に足りていないのも問題です。エンジニアが全事業部を横断していろいろな事業に携わっていると、どうしてもエンジニア一人一人が特定事業に深入りしづらくなってしまうので、そのへんは課題感があります。

心理的安全性・組織改善について

前職では、1on1などが実施されても、基本的に相談や提案が反映されることはなく「言うだけ無駄」な空気感がありました。(先に辞めた人たちに聞いても同様だった模様…)そもそも組織や制度についてなんらかの改善がなされたことは、ほぼなかったと思います。

組織が大きいと、そのぶん何かを変えるのは大変なので仕方ない面もありますが…。たとえば、リモートワークの導入なども検討されていたはずなんですが、結局いつのまにかうやむやになっていったし…。

今はひんぱんに1on1が実施されていますが、まずリーダーがちゃんとわれわれがやっている業務を把握した上で話を聞いてくれて、説明しやすいし相談しやすいし、また話すことで自分の考えを整理できています。

改善案件もSlackにがんがん流れてくるし、改善要件があれば社員にすぐにヒアリングが実施されて、その意見もすぐに反映されるから、こちらも積極的に提案しようという気になります。

前述の通り、企画の初期段階から事業部と話せる機会も多く、開発部以外への発言しやすさも担保されています。エンジニアの組織だけで閉じていないというか。

あとは業務面だけでなく人事とも1on1があって、福利厚生面などにおける要望も出しやすいです。最近は社内に自販機が2台置かれることになってハッピーです。

こういう企業体制は結構大事だと思っています。一番よくないのは「言っても変わらないから言うだけ無駄」って空気感だと思うので。何か不満や不安が生じたときに「言ったらなんらかの対応がしてもらえるぞ(=だから言ったほうがいいぞ)」って空気感があるのはいいですね。

まとめ

というわけで、paizaに来て3ヶ月のエンジニアが前職との違いや、実際に転職して思うことなどを書いてみました。

繰り返しになりますが、私は「エンジニアも事業からかかわれる企業がいいな」と思って転職したので、基本的に今はそれがかなっていい感じです。でも、この世にすべて完璧な企業なんて存在しないですから、まだまだ課題感満載な部分もあります。

特に今は、エンジニアが増えないと解決できないことが多いです。paiza(ギノ)は現在もエンジニアの方を絶賛募集中ですので、もし興味を持ってくれた方がいらしたら、ぜひご応募ください。

【Webエンジニア】Railsによる大規模Webサービスの開発に興味のある方!

paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。

paiza転職について詳しくはこちら
paiza転職





paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。

詳しくはこちら

paizaラーニング

そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。

スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。

詳しくはこちら

paizaのスキルチェック

paizaのおすすめコンテンツ

PPG proken プログラミングゲーム「初恋 プログラミング研究会〜海に行こうよ〜」 PPG Bingo プログラミングゲーム「コードレビューBINGO!!」
paiza転職 paiza新卒 EN:TRY paizaラーニング 記事内に記載している情報は、記事公開時点でのものとなります。 Copyright Paiza, Inc, All rights reserved.