【雑記】転職前後で変わったことまとめ

初めに

転職して半年たったので、レガシーなSIerからモダンなSIerに転職して感じたことをまとめます。同様のキャリアチェンジを考えている方の参考になればと思います。前職では主に行政法人系の業務システムの担当、現在はイベントの登録、一般ユーザの応募管理、当選者の決定などを行うBtoCシステムのバックエンドリーダーを担当しています。

転職して感じたこと

技術が新しい

インフラはクラウド上にIaCで構築、Webアプリはフロントとバックエンドに分かれ、各アプリはコンテナで構築、DBはマネージドサービス、GHAでのCI/CD、xUnitでの自動テストが実装されています。認証周りについてもシステム内に独自に認証データを持つのではなく、SAML連携やOAuth2.0のようなTokenベースのプロトコルを採用して、他システムと連携することも多いです。ただ、これはあくまでBtoCの1システムを担当しての感想です。ちなみにIDEはVSCodeです（Java環境構築も面倒で拡張機能のバグも多く、正直使いやすいとは言えないです）。

正直コードの質は前職のほうがいいかもしれません。担当プロジェクト限定かもしれませんが、とにかく短い期間で作っていたようで、私の参画時は共通化すべき処理が各所にばらばらに実装されている状態でした。終わりは決まっているがある程度の期間を設けて実装を進めるWFと動くものをいかに早く出してフィードバックをもらいながら品質を上げていくアジャイルの違いでしょうね。ただ、きちんとリファクタリングの時間をとれるのも、CI/CDやユニットテストが整備されていて、柔軟にスコープ変更を行えるアジャイルを採用している利点だなと思います。

ドキュメントはテキストファイルメイン

ドキュメントはMarkdownやPlantUML、Draw.ioなどで書き、テキストファイルをGitで管理しています。ER図とかDraw.ioで書いてSVGファイルで管理されていますし、シーケンス図はMarmaidやPlantUMLをバリバリに使いこなしていて驚きました。設計書類についてはGitにまとめるほかに、JIRAにも記載しています。重複管理になっているのはあまりよくない状態ですが、参照性の都合からある程度仕方ないと割り切っています。ちなみにGithubEntrepriseやJIRAはお客様の持ち物なので、プロジェクトによってはエクセルで管理している場合もあるようです。

プロジェクト推進はアジャイルが多い

現在かかわっているプロジェクトは、ウォーターフォールではなくアジャイル（スクラム）で随時機能をリリースしていく方式です。ある程度大きい機能の要目は設定されているものの、リリース後のフィードバックに応じて優先順位やスコープを柔軟に変更して対応しています。変化の速い現在は、作るシステムの形態に応じてきちんと使い分けるのがより重要だと感じます。

求められる知識の範囲がかなり広い

クラウドネイティブとまではいかなくとも、オブジェクトストレージ（S3）を使用したり、CDN（CloudFront）を活用して高速化を図ったりしている関係上、どうしても関連サービスの知識やHTTP通信の基本的な部分の理解を求められます。より専門的な知識を持つインフラ担当者に必要なサービスの設定をお願いする場合も、なかなか適切に要件を伝えることができずに苦労しています。また、REST構成をとったりTokenベースの認証を使用すると、HTTPの通信の基礎部分の理解を求められます（MVCに慣れていてかつ本当にコアな部分は担当したことがなかったのもあって、セッションやらCokkieやらHeaderやらを意識して実装する機会がほとんどなく、そのあたりの知識が壊滅的で苦労しています）。

また、多分これは社風ですが、バックエンド、フロントエンド両方の知識が求められます。開発そのものは随時募集するパートナーさんにお願いすることが多いので、社員はどちらでも見られるようになってほしいという雰囲気で、フルスタックエンジニアを目指してくれ！と明確に面談でも言われます。成長したいという人は挑戦しがいのある環境ですね。私は今自分の担当のバックエンドで手一杯なのであまりできていませんが、学びたいと思って入っているので、挑戦を許してくれる、推奨する社風があるのはなかなかいいなと思います。求められるだけあって、研修も豊富に受けさせてくれます。

社内情報発信がかなり活発

社内の共通コミュニケーションはSlackで行われていますが、本当にいろいろなチャンネルがあります（技術的な勉強会の案内、技術記事の共有や議論、社内の共通リマインド、おいしいお昼のお店の共有まで(笑)）。活動しているチャンネルも多く、情報発信は活発です。ランチミーティングの案内、気になった記事の共有とそれに対する議論、推奨資格の受験結果報告、といった前職では公の場ではあまり見られなかった内容が、本当にたくさん発信されています。あとは社員が運用する技術ブログもあり、広報や採用活動の一環として運営されているので、アウトプットを積極的にしていくべしという空気があり、みんな勉強していることがわかって刺激になります。

やっておいてよかったこと

AWSの資格取得

直接昇格要件になっていることもありますが、実務をする上での最低限の知識として、各サービスの性質や基本的な設定内容くらいは理解していないと、単なるアプリのコーダならともかく設計含めて行う立場では業務についていけません。

使いそうな技術の基本理解

OAuthとかOIDCとか、そもそも使い方を理解するのに時間が必要なので、事前に勉強していないといきなり実装してねと言われてもよほどの人以外無理だと思います。あとは周辺製品の情報収集ですね。ローカルで試せるKeyCloakだとか、コンテナ周りの技術だとか、メッセージングに関するミドルウェアだとかは知らないと、どこから調べればいいんだ？どんな使い方をするんだ？となってしまうので、アジャイルというスピードを求められる環境では、代表製品の名前くらいは知っていないと厳しいと思います。

やったほうがよかったこと

HTTPとかもっと基礎的な部分の理解

HTTPの通信プロトコル（ヘッダ、クッキー、セッション、ステータスコードの使い方など）を理解していないと、REST開発、現代的な認証プロトコルの実装は正直厳しいです。何か詰まったときに対応できません。通信経路や通信情報の検証方法を概念でも把握していないと、どの段階で問題が起きているのかすら見当がつかず、必要以上の時間がかかります。ちょっと時間が空いたらそのあたりきちんと勉強しなおしたいと思っている部分です。

使いそうな技術の実際に手を動かしての実装

使用しそうな技術について、基本的な部分がわかっていてもどの段階でどんな実装をすべきかというプラクティスを理解していなければ実務ではほぼ役に立ちませんでした。一番なのは手元で動かした経験を持って、単なるコードのコピペではなく、実際にいろいろ改造してみる経験を積んだほうがよかったと思っています。

コミュニケーションの強化（と異なるレイヤの技術的観点の把握）

一番感じる部分です。それぞれ異なる技術的背景を持つメンバーや周囲のチームの方とコミュニケーションを図るうえで、これまでの同質化された環境でのコミュニケーション方法はほぼ通用しませんでした。アプリについて理解しているメンバー間では通じても、インフラの担当者に対しては全く違う観点からの質問が来たり、想像できない点が異なったり、そもそも依頼内容が完全にすれ違ってしまうという状況です。これは業務的な部分だけ気にしていればよかった、オンプレMVC業務システムと一番異なる点かもしれません。クラウドというパブリックな環境で、いろいろなサービスを組み合わせて構築するアーキテクチャを採用し、時にはOIDCといった外部システムとの認証通信も必要、メールサーバもお客様の持っているSaaSを使う、という環境では、本当にいろいろな背景を持つ方とのコミュニケーションが必要です。

終わりに

転職して半年という転機を迎え、現時点での所感をまとめました。前回の転職エントリに「現時点では成功かな」と書いていますが、今回においてもまずまずの成功だったと思います。正直前職のほうが気楽だったというのは感じますが、上記に書いた点を徐々に克服に向けて努力しており、業務の中で成長できている部分でもあります。久しぶりに忙しくて学ばなければならないことも多いですが、多分このプロジェクトをやり切ったとき、相当自分は変わっているだろうなと思います。

最後までお読みいただきありがとうございました。