プロダクトエンジニアリング部の興津です。私は前職が客先常駐（SES）専門の会社でエンジニアをしていて、2022年10月にLIFULLへ中途入社しました。
客先常駐でお客様のシステムを開発する前職から、自社のサービスを開発するLIFULLへ転職することは、不安な点が多かったことを覚えています。
今回は、転職して1年が経過した今振り返ってみて、これまでの経験が活かせた点と、活かせなかった点の乗り越え方を紹介します。
同じように客先常駐エンジニアから自社サービスエンジニアへのキャリアチェンジを検討している方の参考になれば幸いです。
（ただし、あくまでも私の・LIFULLに転職した結果であることはご留意ください）
私がLIFULLに転職を決めた理由
もともとは前職と同じ客先常駐ができるような会社に転職をしたいと考えておりました。
そんな中登録した転職サービスでLIFULLからスカウトメッセージをもらいました。
希望業種とは違ったけれど、自分の職務経歴書をしっかり読み込んでくれたことがわかる丁寧なメッセージだったため、カジュアル面談を受けることにしました。それがLIFULLへ入社するきっかけとなりました。
そして、社会課題を解決するという会社の理念に共感し、そのまま縁あって入社を決めました。
その結果、想定外のキャリアチェンジとなってしまい、入社にあたっては多くの不安がありました。
客先常駐エンジニアから自社サービスエンジニアへとキャリアを変える時に感じた不安
求められているスキルが自分にあるか
技術的なスキルも、これまでは常駐先の技術をいち早く把握することが求められました。
しかし自社のサービスとなると、早さよりも深さが求められ、時には新しい技術を提案できなければいけないのではと考えていました。
この向き合い方のギャップがどんな影響をもたらすかが未知数でとても不安でした。
同じ会社の人と長期的なコミュニケーションを取ること
前職は客先常駐の中でも、一人で常駐することをメインとする会社であったため、自社の人とはコミュニケーションの機会がほとんどありませんでした。
また、当然のことながら常駐先が変われば一緒に仕事をする人が変わります。
そのため、技術と同じように、コミュニケーションスキルも、初対面の人しかいない中でより早く馴染むよりも、同じ人たちと長期的に関係性を構築していく方向に変化させる必要があるのではと考えていました。
具体的には、私にコミュニケーション面での欠点があったとしても、これまで一緒に仕事をしてきた人は「このPJが終わったらもう関わらない相手だから」と目を瞑ってくれていたかもしれません。しかし、これからもずっと仕事をする相手だとストレスを与え続けることになってしまうことが不安でした。
自分らしい働き方ができるのかという懸念
客先常駐であれば、働き方のほとんどが「常駐先に準じる」というものです。
一見すると客先の言う通りにしなければならず、自由がないように見えます。しかし、逆に言えば自分の働き方と合った客先に常駐すれば理想通りの働き方が簡単にかないます。
途中でライフスタイルが変わって理想の働き方が変わった場合は、客先をそれに合わせて変えればよかったのです（もちろん、それをかなえてくれるような会社に所属していることが前提となります）。
同じ会社でずっと働くということはそんなに簡単に働き方を変えるわけにはいかないのではないか、と言う懸念がありました。
特に私は小さい子どもがいるため、この不安が最も大きかったです。
入社してから感じたFIT＆GAP
FITしていると感じた部分
開発業務
当然のことながら、コーディングやテスト・レビューなどは今までの経験がほとんどそのまま活かされました。
特に、ドキュメント化の整備は客先常駐エンジニアとしての経験が重宝されました。客先常駐はメンバーの入れ替わりが激しく、一度離れたメンバーとは連絡を取ることが難しい環境に身を置くことが多いため、「自分がこの現場からいなくなった時のこと」を考えさせられる機会が多かったです。その対策として自分の作業のドキュメント化を普段から当たり前のようにしてきました。LIFULLのような自社サービス会社では、客先常駐ほど入れ替わりが多くなく、異動で離任していたとしても同じ社内にいるのであれば容易に連絡をとることができます。その結果、ドキュメントの整備が進んでいない箇所も多く、有識者に都度質問をするコストが肥大化しています。そんな中で自分がこれまで自然とやってきたドキュメント化作業はチームに貢献できる一手となりました。
ちなみにLIFULLではこの「有識者に都度質問をするコスト」が解消できる方法の一つとして、社内向けのAIチャットBotが存在します。詳細はこちらの記事をご参照ください。
また、技術的なスキルのギャップはおおむね当初の予想通りではあるものの、LIFULLでは社内の有識者に気軽に相談できるしくみが充実しています。そのため、メンバーの一人として通常業務をする分には大きな問題とはなっていません。
このしくみの一例については、こちらの記事が詳しいです。
マネジメント手法
自社サービスといえど、チームメンバーとともにリリース日に合わせて開発業務をすることは変わりがないため、マネジメント手法についてもこれまでの経験や勉強してきたことが役に立っています。
ただし、リリース（納品）した後の状況が受託のSIとは異なるため、スケジュールのバッファの取り方や、進捗に遅れが見られた時の対応方法については差異があり、自分の考え方を微調整する必要がありました。
しかし、PMBOKで言うリスクマネジメントや品質マネジメントなどは大きく変わらないと感じています。
自分らしい働き方
私が転職する際に感じていた最も大きな不安でした。結論から言えば、自分の働き方と合った客先に常駐した時ほど理想的な働き方ではないにしろ、LIFULLの制度を利用することで大きな問題なく就労できています。
まず、LIFULLは週2日のリモートワークが可能ですが、申請が承認された場合は、リモートワークの日数を増やすことが可能です。これを利用して私は現在週４日リモートワークをしています。
次に、LIFULLはフレックス制度を導入しているため、1日の始業時間と終業時間を自分の状況に合わせてコントロールできます。担当業務をスケジュール通りに完遂できる状態であれば、今日は6時間だけ働いて、明日は10時間働くということもできます。
私の場合は、子どもの保育園の送り迎えや育児の時間を確保しようとすると、仕事ができる時間は9時半〜18時・または21時以降という非常に限定的な稼働時間となってしまいます。
しかし、LIFULLでは休憩時間の取り方も個人の裁量に任されているため、18時から休憩を取得して保育園に子どもを迎えに行き、子どもが就寝したら仕事を再開することも可能です。
（ただし、22時以降は上長の許可が必要なほか、深夜時間帯はシステムの都合上できる業務が限定されます）
何より、LIFULLはダイバーシティ＆インクルージョンに積極的に取り組んでいることもあり、多様な働き方を受け入れる土壌が会社全体に広がっています。
今後ライフスタイルが変わって働き方を変えたくなったとしても、LIFULLとLIFULLのメンバーならきっと受け入れてくれると確信しています。
LIFULLのダイバーシティ＆インクルージョンについては、下記を参照してください。
GAPとして感じた部分と、乗り越え方
度重なる保守運用業務
LIFULLでは自社のサービスを改善するだけではなく、すでにリリースされたサービスの障害対応や、利用しているライブラリのバージョンアップや脆弱性対応など、保守運用の作業も存在します。
私は前職では常駐先も受託のSI企業が多かったため、納品した後の対応は、基本的に納品先の担当者に一任していました。そのため、自分の開発作業の手をとめて保守運用作業をすることの切り替えコストや、その結果進捗が遅れてしまうことに最初は慣れず、戸惑いました。
現在は、あらかじめ突発的な保守運用業務の発生を見越したPJ進行をするように心がけることで対応しています。具体的には、開発業務の見積もりを出すときにこの作業のリソースも加味したスケジュールにしたり、保守運用の状況もエンジニア以外のチームメンバーに伝えて進捗が遅れることの理解を得るようにしています。LIFULLのエンジニア以外のメンバーは、開発作業以外のエンジニア業務を好意的に応援してくれる人ばかりであるため、衝突が発生することはありません。
また、LIFULLのプロダクトエンジニアリング部では小さな保守運用業務も積極的に取り組むことが数字として評価されやすい環境も形成されています。たとえば、PRマージ数を評価基準として重視することです。 この環境があることで、急な保守運用業務の発生も落ち着いて前向きに取り組むことができています。
自分の仕事が必ずしも会社にとってよい結果につながる訳ではない環境
サイト改善のための開発をしても、リリースした結果、売上などのビジネス的成果の数字が落ちてしまうこともあります。LIFULL HOME'Sの場合、リリース後の一定期間はABテストという、ユーザーを2分して改修前と改修後のサイトを見せて、どちらの層の反応がよいかを計測することを行います。最初から改修後の方がよいことはまれで、何度かのマイナーチェンジを経た後で全ユーザーに向けてリリースします。完全に改修前に戻してしまうことも少なくありません。
客先常駐専門の会社は、在籍エンジニアが客先に常駐する時間を提供することで対価を得ています。つまり、真面目に常駐先で仕事をしていれば、そのまま会社の売上になりました。しかし、LIFULLのような自社サービスの会社では、頑張って改修した結果が会社の売上につながるとは限らないため、うまくいかなかった時の気持ちの保ち方に難しさを感じました。
この気持ちに折り合いをつけるには、自分一人の気の持ちようだけでは難しいです。私は「失敗した施策も次の成功する施策のための学習材料である」と考える土壌や、売上はどうあれリリースを通して市場学習をしたということを賞賛するチームを作っていくことが大切だと考えています。
幸い、LIFULLではその空気があらかじめ作られていて、KPIに市場学習回数を置くなど、しくみの面からも空気を醸成するような取り組みが積極的に行われています。そのため、入社して一年経過した今は、施策が直接ビジネス成果につながらなくても前向きに受け入れられるようになりました。
長期の付き合いを見越したメンバーとのコミュニケーション
チームメンバーとのコミュニケーションの取り方のギャップは、おおむね入社前から予想していた通りでした。
しかし、そのギャップに対する不安のほとんどが杞憂に終わりました。なぜなら、LIFULLでは入社者のオンボーディングやチーム間のビルディングをとても大切にしている会社だからです。
中途入社であってもメンターがつき、入社者が希望する限りは毎日メンターと上長それぞれの1on1の時間が設けられます。また、半期に1回はチームビルディングといって、所属するチームとの関係性を醸成するための時間が業務時間中に作られます。やることはチームに委ねられていて、ゲームをしたりBBQをしたり、さまざまなことを行います。これらのオンボーディングやチームビルディングはPJの進行には関係なく行われます。「PJが忙しいからチームビルディングは後回しにしよう」という価値観ではないのです。
このように、あらかじめチームの関係性を作っているため、お互いに改善点がある時も、思いやりを持って伝えることができて、受け入れる側も過度に傷つく状態にはならないように感じています。いわゆる建設的な話し合いができているという状態です。
さらに当然のことながら、LIFULLでは改善点の指摘の方法を教えてくれる機会や、業務上の困りごとを第三者に相談する機関も存在するため、改善点の指摘が相手の否定にはならないことも記載しておきます。
最後に
私のように自社サービスのシステム開発経験がない人でも、LIFULLのビジョンに共感できるのであれば、きっと活躍できるはずです。
LIFULLではともに働いてくれるエンジニアを募集しています。興味がある方はぜひ下記のページを見ていただけるとうれしいです。
