前回の転職エントリ
【雑記】31歳になりました/転職します - B-Teck!
TL;DR
4/13に最終出社をし、GW明けから次の会社で働くことになりました。
在職期間はざっくり2年弱くらいでした。
主にScala、Angularを書き、スクラムで進めながら要求の検討から保守まで一通りできたなと思います。
次もtoBのSaaSプロダクトでWeb開発をすることになりそうです。
退職のきっかけ
- 組織の志向するものと、自分がプロダクト開発に求めているものとマッチしないと感じる機会が増えた
- 今の進め方で自分の職能の幅を増やしていける自信がなかった
- 出社日が増えることになり、ライフスタイルと合わなかった
大きくこれがキツかった！みたいなのはなかったんですが、積み重なった結果という感じです。
もっと色々聞きたいなと思ったら飲み会でも誘ってください。
転職活動
元々キャリアの検討や棚卸しのために継続してカジュアル面談を受けていました。
2月頃に数社の選考を受け始め、3月中旬に自身に合っていそうな企業に内定をいただけたので、転職という形です。
学べたこととか感想
チーム開発
スクラム開発
スクラムでの開発は経験がなかったのですべてが新鮮でした。
チームで見積もり、設計し、スウォーミングでタスクを片付けるという進め方はとても楽しかったです。
対外的なロードマップの提示しづらさや、プロダクトゴールが定まらない状態での方向性の検討みたいな難しさも味わいましたが…。
この辺の本を読んだ記憶があります。
複数チームでの協働
同じ製品を扱うチームが複数存在していて、同時にコードを触ることもありました。
他チームの開発案件や修正内容をある程度把握しておく必要があったり、協力できる体制を整えておくという経験ができたのはよかったです。
もっと良い情報共有のフローが合ったかもしれないなーというのは少し反省。
個別の案件の進め方
終盤はスクラムではなく、少人数のチームや個人に案件がアサインされる開発スタイルになっていました。
ここでは久しぶりに、
- 要求からの要件定義
- リリース計画策定
- 開発途中での仕様変更やスコープ変更の調整
をやって、プロジェクト計画ってやっぱり難しいなあと思ったり。
持った案件は2人で進めていたのですが、同僚の id:kzk0829 さんがほぼ全部バックエンドを爆速で倒してくれました。
おかげで私は計画や調整、必要に応じてフロントエンドの開発に回ることで期間内に収めることができました。
プロダクト開発とその組織
SaaSプロダクトの開発ということで、様々な人・組織と関わる機会がありました。
toBということで、自分が直接のユーザーになることはほぼありません。
そうなると使われ方や求めている機能を想像することが難しい場面もあります。
そういった場面で、デザイナー・POの方々の顧客理解能力にはものすごく助けられました。
また、顧客の生の声を伝えてくれるCSの方にもたくさん助けていただきました。
実際のお客様の運用・困り事などを伝えていただいたりと会話の機会も多く、相談しやすかったなと思います。
組織についてはこのあたりの本を読みました。
比較的規模の大きいソフトウェア開発
これまでの職場では数十テーブル、100kLOCくらいの割と小さめの開発が多かったです。
今回は3桁のテーブルや数十万行のコードベースがあり、モジュール間のごちゃごちゃした連携もありました。
アプリやインフラも含めたアーキテクチャ設計、考えるべきこと多さなど、学べることがたくさんありました。
モダンなクラウドアーキテクチャ
今まではほぼオンプレでの開発経験しかなく、AWSを触ることがあっても社内のSRE頼りという感じでした。
今回もめちゃくちゃたくさん触ったかと言えばそうでもないんですが、EC2ポン置きではないAWS上のアプリケーションの作りや、非同期・バッチ処理を含めたインフラ構成などはすごく勉強になりました。
AWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか を実感を持って読むことができてすごく嬉しかったです。
テスト
恥ずかしながら前職までほとんどユニットテストを書かず、結合テストだけを作って過ごしていました。
色々理由はあるものの、言い訳になってしまうので書けませんが…。
ユニットテストが書かれているのが当たり前という世界観はかなり体験が良くて、今後もちゃんと書きたいと思っています。
一方で、古くなったテストや実は変更容易性を下げているテストケースもあったので、あの辺を改善できる腕力もつけないとな気がします。
その他、E2Eテストも正常系はかなりの部分が網羅されていて、リリースサイクルの中で救われたことが何度もありました。
総じてテスト・QAの体験が良かったなという印象があります。
エンジニアとしての姿勢
経歴上チームで動くということが少なかったので、全部自分で解決しなければならないという感情がありました。
また、降りてくる要求が過多だったことも多く、ゴールから逆算して実現可能な方法を探す、という思考パターンが染み付いていました。
今回の職場では、困ったことがあれば周囲に相談することができ、必要であれば前提から考え直すといったこともありました。
どうしても一人で抱え込みがち、無理やり解決することを選びがちな私に辛抱強く向き合って一緒に解決してくれたチームメンバーには感謝しきりです。
そのおかげか、きちんと意思を持って進め方を提案したり、前提を変える必要があれば自分から代案も含めて持っていったりと動き方に幅が出たような気がしています。
前に出ることが苦手だったのですが、浮いてる議論の中ではファシリテーターを買って出て前に進めるという動きもできるようになってきたので、だいぶ成長かなと思います。
一時期ファシリテーションの勉強をしようと思ったときはこの本を読みました。
会議の生産性を高める 実践 パワーファシリテーション
ドキュメント管理
これまでもなるべく整理された資料を書くようにしていたのですが、前述したように経験したことのない複雑さがあるためより意識をしました。
暗黙知だった機能仕様を集約したり、整理したり、口頭でのやり取りを記録することを率先して行っていたように思います。
後悔としては、自分が書く、人に読んでもらうはうまくできたものの、人に書いてもらうところまでは広げられなかったなぁというところです。
普段ドキュメントをあまり書いていなかった人にどうやって書いてもらうのか、価値を感じてもらうのかというのはずっと悩んでいるので、新しい場所でなにか良い方法が見つかると良いなと思っています。
休暇中の過ごし方
次の職場のキャッチアップ
次の職場は久しぶりにJavaを書くことになりそうです。
書いていた期間が長いとはいえ、本腰を入れて書いていたのは数年前で、かつアップデートも早くなっているので、最近のJavaを一通り復習したいなーと思っています。
あとは実は使ったことないSpring周りをかるーく頭に入れておこうかなと。
フロントは会社によって結構形が違うので触りながら覚えるしかないかなーと思いつつ、できる範囲で勉強していこうかなくらいの感じです。
プライベート
実は自動車免許を持っていなかったので、通いで取ろうかなと思っています。
とはいえ最短でも6月くらいの取得になってしまいそうではあるんですが…。
MTの免許を取ろうとしているので、うまく運転できると良いなぁ。
あとはできていなかった場所の掃除とか、しばらく積む一方だった積読を崩すとか、そういう感じですかね。
あまりいなさそうな気がしますが、ここまで読んでくれた人が居たらありがとうございます。
様式美なので一応ほしいものリストも置いておきます。
https://www.amazon.jp/hz/wishlist/ls/Y51M0G89KP09?ref_=wl_share
