（ほぼ）同じスキルセットでも働き方が劇的に変わった1年を振り返る

はじめに

2024年5月にWHIへ転職し、エンジニアとして働いていたのですが、気づけば転職して1年が経ちました。

あっという間の1年でしたが、転職してどうだったのかを振り返ってみようと思います。

前職について

新卒入社の会社で6年間、エンジニアとして働いていました。
複数のPJTを経験しましたが、まとめるとこんな感じになります。

• 事業形態
  • 2次請け（客先常駐）
• PJTの規模・開発手法
  • ウォーターフォール開発
  • 半年～数年単位のPJTが中心
• 担当業務
  • 基本設計から総合テスト（PJTにより異なる）
  • データ移行やリリース作業の経験あり
• 役職
  • メンバーの立場が多め
  • 1回だけ、PJTリーダーとしての経験あり（40人月程度の規模）
• 働き方
  • PJTにもよるが、最後の1年間は基本出社
• 利用技術
  • フロントエンド
    • jQuery、AngularJs
  • バックエンド
    • Java、Struts、Spring

上記以外にも、様々なことにチャレンジする機会を与えてもらいました。
今の自分のハードスキル／ソフトスキルの大半は、前職の業務経験で培われたと自信をもって言えるぐらい、非常に良い経験をすることができました。¹

現職について

現在はこんな感じです。²

• 事業形態
  • 自社開発
• PJTの規模・開発手法
  • 1ヶ月1イテレーションで開発を実施
• 担当業務
  • 機能追加（企画、設計、実装、テスト等）
  • 不具合改修（実装、テスト）、問合せ対応
• 役職
  • メンバー
• 働き方
  • フルリモート
• 利用技術
  • フロントエンド
    • jQuery、Vue3
  • バックエンド
    • Java

転職後の変化・気づき

転職前後で、開発に利用している技術はそこまで変わっていないのですが、仕事内容について変化が多かったです。
そのため、転職後の変化や気づきについて、いくつかピックアップしようと思います。

働き方について

基本出社からフルリモートへ

前職では、PJTの状況にもよりますが、リモートと出社を組み合わせたハイブリッド勤務か、基本出社のケースが多かったですが、現職ではフルリモートでの勤務となりました。

退職するまでの1年半の間はずっと出社しており、会話によるコミュニケーションに慣れていたので、いきなりフルリモートでやっていけるのかという不安はありました。

転職後は、テキストコミュニケーションが中心となりましたが、文章でのやり取りが難しい内容の場合、日次のMTGや週次の1on1を活用する、必要に応じてチームメンバーとオンラインのMTGの時間を設定するなどで、会話によるコミュニケーションを行いながら、業務を進めることができています。

メンバー全員が基本的にリモートのため、オンラインのMTGを設定する心理的ハードルは低い印象です。（ハイブリッド勤務の場合、自席で実施する場合はオフィスの周りを気にしたり、会議室を利用する場合は予約や移動時間を気にしないといけないなど、些細なことかもですが気を遣うことが多いです・・。）

不規則な勤務が減った

前職だと、システムのリリースやデータ移行対応等で、夜勤、休日出勤、夕方から終電までの勤務など、不規則な勤務になるケースも時折ありましたが、現職だと、問合せ対応、実装、テストが中心のため、不規則な勤務にならなくなりました。³

利用ツールの変化

前職だと、MicrosoftのOfficeを中心に業務を行っていましたが、転職後はGoogle Workspace + Slackがメインとなりました。

また、前職ではWBS等のタスク管理や、社内ドキュメントをExcelで作成していたのが、転職後、タスク管理はRedmineなどのツールを利用する、社内文書はMarkdownで書くなど、業務に利用するツールはガラッと変化しました。

最初は戸惑いましたが、すぐに適応できたと思います。

開発者体験の向上

転職後の開発業務において、

• GitHub Copilotの活用して、実装をする
• ソースレビューをPR上で実施する
• PR時の静的解析やビルド、デプロイのジョブ等のCI/CDが充実している

といった（エンジニアにとっては当たり前？かもしれない）ものについても、開発者体験が向上していると感じた経験でした。

過去に

• 開発PCで外部ネットワークに接続できない
• ファイルサーバーに配置した修正前後のソースコードに対して、Diffを取得しソースレビュー⁴を行う

などの経験⁵をしていたことがあったので・・。

メンバーの裁量が大きい

転職してからいちメンバーとして業務を遂行していますが、メンバーとしての裁量は転職後のほうが大きくなっている印象です。

前職の場合は、担当するPJTの規模が大きいこともあり、リーダーがWBSでタスクの洗い出しとスケジュールを作成し、各メンバーにタスクを割り当てるなど、リーダーは実作業をすることなく、管理業務に徹する働き方が当たり前だと思っていました。

ですが、今の会社ではリーダー⁶も実装を行い、開発業務と並行してメンバーのマネジメントを行っています。

メンバーも担当する開発チケットや問合せ等、必要に応じてリーダーに相談するものの、まずは自身の判断で意思決定をすることが多いです。Ownershipの価値観⁷を大事にされているなと思っています。
（逆にリーダーはメンバーの業務状況を把握できるのかな・・。と思ったりもします。）

リーダーは手を動かしていたらダメだと思っていた自分としては、こういう働き方もあるのだなと気づかされました。

設計書等の内部仕様に関するドキュメントはあまりない

画面一覧などの一覧系の設計書や、画面レイアウト設計書、テーブル定義など、SIerでは当たり前に存在しているドキュメントがあまり存在していなくて驚きました。

仕様について知りたい場合は、製品マニュアル、社内のナレッジが集約されているリポジトリ、過去の問合せのやり取りの確認、ソースコードの調査で対応することが多いです。（全然知らないサブシステムの場合、初動で苦労することはありますが・・。）

ただ前職でも、ブラックボックスになっている仕様について、ソースコードから解析して資料化することを多々実施していたので、むしろ、これまでの経験をかなり生かすことができているなと感じています。

設計書の充実度の違いは、SIerと自社開発の開発スタイルの違いが大きいのかなと思っています。⁸

ソフトウェアテストは思ったよりしっかりしている

転職前は、自社開発はSIerの大規模PJTと異なり、リリースサイクルが早いため、ソフトウェアテストのそこまで工数を割いていないのではと思っていました。

ただ転職後も、SIerのPJTほどではないですが、ソフトウェアテストに工数を割いている印象です。
詳細なテストのフローは割愛しますが、単体テストもSIerで実施していた時と変わらず、テストケースを網羅的に作成、実施していました。
また、JUnitを用いたユニットテストの実装や、E2Eなどの自動テストでデグレードを防ぐ取り組みもされています。

製品開発の企画から（上流から）かかわることができる

弊社では担当サブシステムで機能追加を行う際、カタログと呼ばれる製品企画書を作成します。

この1年間で自分もカタログを作成する機会があり、

• 今のシステムの業務分析
• 分析から考えられるニーズーとユーザーが求めているニーズとマッチしているかの整理
• 機能追加の案

などをドキュメントに記載し、社内レビューのFBを受けて、ブラッシュアップし、実装に取り掛かるという経験をすることができました。

前職だと要件定義などの上流工程を担当することはなく、詳細設計工程以降がメインでした。
そのため、どちらかというと、顧客が求めている要望に対して、どのように実現するかという視点で考えることが多かったです。
一方で、転職後は上記に加えて、何をやりたいのか、エンドユーザーが何を求めているのか、という視点で考える機会が増えたと思います。

システム開発の上流部分に関われることは、自身のキャリアにおいても貴重な機会であり、また、転職してやりたかったことの一つが実現できたと思っています。

作ったシステムを自分で触れる、FBをもらえる

転職後に担当しているシステムは社内でも利用しています。

自分は幸いにも、この1年間で実装した機能を社内で利用してもらえる機会を得ることができ、FBや感想を見聞きすることができました。

前職では、自分の作ったシステムの感想を聞ける機会がなかったので、この点はやりがいに繋がりました。これもまた、転職してやりたかったことの一つが実現できたと思っています。

個人の発信が活発

前職の働き方が客先常駐なこともあり、常駐先の以外の社員との接点はあまりありませんでした。
一方で転職後だと、Slack上で他のチームの公開チャンネルに参加するなど、自チーム以外のメンバーの様子を知ることができます。

そのような中で、個人の発信が活発だなと感じたのですが、その例を2つ紹介します。

Qiitaについて

弊社では、本記事のように、Qiitaによる発信を行っており、技術的な内容や、チームビルディングに関する内容など様々な記事が投稿されています。

また、SlackチャンネルでアドベントカレンダーやQiita Engineer Festaの告知が行われると、活発に投稿が行われます。

中途のオンボーディングで外部発信をテーマにしたコンテンツが存在したり、新卒の社員も積極的に投稿するなど、特定の個人の頑張りではなく、組織として発信活動を盛り上げようとする姿勢が強いです。

timesについて

timesとは、Slackで自分専用チャンネルを作成して、SNSのように投稿するものです。
下記の記事も参考になると思います。

• なぜ WHI では times 文化がうまくまわっているのか？

• 社内コミュニケーションが苦手な人のためのtimes文化入門

基本的にリモート勤務であり、出社の時のように偶発的なコミュニケーションが生まれにくい状況においてはとても有益だなと思います。

自分は、timesを通じてコミュニケーションとるよりかは、業務で得た知識を備忘録的につぶやくことがメインですが、業務で困っていることをtimesに呟いたら、他のメンバーからアドバイスを貰えた・・！という機会は何回も経験しました。

チームの垣根を越えて、様々な社員の学びの共有や意見を見て、自分自身も学びになりますし、社内外のナレッジがSlackに蓄積されており、いい意味で情報の海と化しているなという印象です。

おわりに

転職前後で変わったことは他にもありますが、技術的な内容から離れていきそうなのでこの辺にしておきます。

転職後の自身のスキルセットの部分については、そこまで変化があるわけではなく（GitとVue3に詳しくなった程度）、むしろ転職前の経験を活かせているなという印象ですが、開発プロセスや組織文化は会社によって全然異なるという気付きを得ました。
自分は結果的にうまく適応できたと思いますが、入社前に仕事内容の解像度を上げることの重要性を痛感しました。

募集要項に書かれている仕事内容を見るだけだと、得られる情報も限定的なので、カジュアル面談や面接などで、

• チームの人数、役職、役職ごとの具体的な業務と裁量について
• 定期MTGの頻度、内容について
• ソースレビューの進め方ついて
• テスト手法について（自動テストを利用しているかなど）
• タスク管理、チケット管理、バージョン管理、事務作業等に利用しているツール
• 設計書などのドキュメントの有無について
• 1日のスケジュール、また不規則な勤務があるか

などの観点で質問をして、現場社員の働き方を知ることができると、仕事内容の解像度を上げることができる（＝転職後のミスマッチを防ぐことができる）のかなと思ったりしました。（質問の例は雑ですが・・）

今回の体験談を通じて、転職活動における会社選び等、何か参考になる部分があれば幸いです。

1. 同じ会社でも部署やPJTにより働き方が異なるため、自分の経験はあくまで一例として捉えていただければ幸いです ↩

2. こちらも同様に、同じ会社でも部署により働き方が異なるため、あくまで一例として捉えていただければ幸いです ↩

3. 前職の働き方に特に不満があるわけではなく、むしろ貴重な経験をさせてもらったなと思っています。同じ開発エンジニアという役職でも職務により働き方が変わる一例として捉えてもらえればと思います。 ↩

4. バージョン管理として、Gitを導入している現場もありましたが、SVNからGitLabに移行する過渡期で、SVNと同じような運用でGitを利用している状態でした。主担当ではなかったものの、理想的な運用を提案することなどは（立場的に）できたはずなので、Gitについてキャッチアップできていなかった自分の落ち度でもあります。 ↩

5. PJTにもよりますし、全部ではないですが、この記事に書いている内容はあるあるだなと思うような現場が多かったです。 ↩

6. ここでは便宜上、前職の役職に合わせてリーダーと呼んでいますが、前職のリーダーとしての職務は、今の会社ではマネージャーに相当します。このような役職の違いも、入社後のギャップではありました。 ↩

7. OwnershipはWHIの私たちが大切にしている価値観の一つです。 ↩

8. SIerは顧客との合意形成や保守・引継ぎの観点から契約の段階で納品物として設計書の作成が必要になるケースが一般的な認識ですが、自社開発だと、仕様を決める側と実装する側が同じ、チーム内で運用・保守まで対応するなどにより、設計書の作成の重要度が異なることに起因すると思っています。（一方で、自社開発だから、そのようなドキュメントが不要になるとは思っていないです） ↩