気づいたら入社して 8 年も経っていた。
2022 年の 4 月にアプリケーションエンジニアへ転向したので、その経緯や転向してやったこと、今やっていることをまとめてみる。
転向の経緯
自分で作りたいものを作りたかったからというのが一番大きい。
アイレットに入社してから 7 年間インフラエンジニアとして生きてきて、ほぼ毎日楽しく業務に励んでいた。5 年目くらいから「あーこれつくれたら便利だな」という場面に何度も遭遇した。
例えば、日々の業務を効率化するような Web アプリケーションや CLI、内部向け API などあったら便利なモノだ。
「よしつくったろ！」と意気込むも手が進まず、最終的には諦めて要件を纏め、コードを書くのが得意な人にお願いしたりしていた。そして要件通りのモノができあがって喜びつつも、「あぁこうやって実装すればいいのか」「実装できてすごいなぁ」「オレにもできたらなぁ」と複雑な気持ちになっていた。「いやそう思ってる暇があるならコード書けよ」と言われたら何も言い返せない。
このままじゃいかんなと思っていた矢先、育児休業から復帰するタイミングで所属していたチームが解散することとなった。
当時の上司からも「開発に異動したらもっと成長できると」とのコメントをもらい、確かにそうかもと思い自分の今後のキャリアを考える時間をつくった。
このタイミングで転職も考えた。7 年も働いてきたし、そろそろいいかなという気持ちがあったのと、業務に対するモチベーションが低下していたから。転職サイトでいくつかの企業にコンタクトをとってカジュアル面談を受けたりもした。主に自社のサービスを提供する事業会社の方と、会社やサービスのこと、ワークライフバランス（育児と仕事）、技術について話したりした。話して分かったのは、オレはこの業界・サービスの開発に携わりたいという想いがなかったということ。今までさまざまな業界のサービスのインフラ構築に携わってきたが、例えば金融系だとかゲーム系などといった特定の業界の会社にいきたいという気持ちがなかった。今までのキャリアも小学生時代から振り返ってみてもそうだった。
最終的に、特定の業界にこだわりがないので開発チームに異動することに決めた。1 社だけ、このサービスの開発に携わりたいと強く思える企業に出会いコンタクトをとってみたが、残念ながら縁がなかった。心残りはあるが、またどこかでチャレンジの機会を伺いたい。
他の企業の選考に進む選択肢もあったが、書いたとおり何がやりたいのかが明確になっていないまま進むのはよくないし、何よりもアイレットが大好きで居心地も良いというのが大きかった。ママパパの働き方にも理解があって自分の裁量で仕事できるのがありがたい。居心地の良さを求めて自社に留まることによって、成長曲線が横ばいとなってしまうことを懸念していたが、当時は家族を最優先にしたかったのでそうした。この選択が正しかったかどうかは分からないけど、現時点では技術者として成長できていると実感していて、プライベートも幸せなのでよかったと思える。
1 年間何をしてきたか
主にバックエンドを担当していて、Web サービスの API を開発している。技術スタックとしては Python、MySQL、API Gateway、Lambda、AWS SAM などで、サーバレスで開発を進めている。直近だとキャンペーンサイトの API やバッチの実装だったり、チャットボットサービス向けのイベントドリブンで動作するコードを運用している。実際に関わっていはいないが、以下事例の構成と似たようなことをやっている。
www.iret.co.jp
異動後はトレーニングから始まり、Vue + API Gateway + Lambda + DynamoDB で簡単なサーバレスアプリケーションを構築した。教材がとてもよくできていて、フロントエンドとバックエンド間通信の概要が理解できた。このように Web アプリケーションが作られているのだなとイメージが沸いた。トレーニング終了後は少しテーマを変えて DB を MySQL に変えてみたりした。トレーニングは約 1 ヶ月で終了した。
トレーニング後はチャットボット向けサービスのプロジェクトにジョインした。これが初めての複数人での開発で、どのようにチーム開発を進めていくのかを体験できた。コードレビューのフローであったりリリースフローが確立されていなかったため提案したりもした。以前からドキュメントを書くのが得意であったこともあり CONTRIBUTING.md を書いて実際に運用して、開発メンバーから良い評価をもらった。実装の部分は、SQS トリガーで動作する Lambda のリファクタリングを行い、メンバーにフォローしてもらいながら進めた。テストコードを書いてなくて、挙動を確認するにはデプロイして手動で動作確認を行う必要があった。当初はそのままテストコードを書かずに開発を進めてしまったが、今思い返すとまずテストコードを書くところから始めるべきだったと反省。
同プロジェクトで新規に API を開発することとなり、API 設計やテーブル設計にも関わらせてもらった。メンバーとあーでもないこーでもないと議論しながら設計を進めていくのは面白かった。オレ自身はじめての設計だったため分からないことだらけだったが、とてもいい経験になった。テストコードも書いた。Aurora Serverless v1 の Data API を用いたテストで実行時間が非常に長い問題にも直面した。このあたりは以下の記事に書いた。
enokawa.hatenablog.jp
チャットボットのプロジェクトが一段落したあとで、キャンペーンサイトプロジェクトにジョインした。主に API の開発やインフラの構築を担当した。良い API 設計をしてくれたメンバーのおかげで特に問題なくリリースできた。前回の反省を踏まえて開発はテストファーストで進めて、スピーディに高品質なコードが書けたと考える。テスト実行も 10 秒程度で済んだのはよかった。諸事情あって CI を整備できなかったのが心残りで、次に活かしていきたい。
インフラが強みであったことからインフラの改善なども推進した。CloudFormation のテンプレート充実化であったり、OpenAPI(Swagger UI)の AWS Amplify でのホスティングを行ったりした。OpenAPI のホスティングは GitHub に openapi.yaml が commit されると Amplify でビルドが走りデプロイされる。複数のプロジェクトで、同じ仕組みで動いていて嬉しい。今後はインフラエンジニア時代に使っていた Terraform をやっていきたいと考えている。CloudFormation も好きだが、やはり terraform plan の安心さが欲しい。オレが CloudFormation をちゃんと理解できていないだけだが、デプロイ時に意図しない挙動（変更されるはずのないリソースが更新されたり）をしたりしている。change set の差分わかりづらい。
とあるプロジェクトで Flutter も触った。アプリケーションエンジニアという肩書なのでチームでは iOS や Android 向けのアプリケーションも開発していて、ゆくゆくはクライアント側のコードも書けるようにしたいので積極的に取り組んだ。簡単な bugfix から始まり、レイアウトの微調整、環境（dev/stg/prd）毎の遷移先リンクの振り分け、画面遷移時に発生するエラーの調査修正などを行った。Python を触ったあとに Dart を書いたので、静的型付け良いなぁというのと、ドキュメントがすごく丁寧な印象をもった。関わる期間が短かったため深くは学んでいないが、まだプロジェクトは動いているので今後も機会があれば貢献したい。
チームの雰囲気とか
上長以外は初対面で、かつリモートのため馴染むのに時間がかかった。少しずつ慣れていった。
異動してから毎日夕会を実施していて、トレーニングや業務で詰まったときに画面共有しながら質疑応答してくれたのはよかった。
Slack での質問も快く回答してもらった。当時オレを除いたメンバーは 2 人いて、1 人はバックエンド開発に長けていて、もう 1 人はフロントエンドに長けている。上長は何でもできるって感じだったので、ほとんどの問題は質問することで解決できた。特に質問しづらいといった雰囲気は感じなかった。
困ったことは、開発フローやコーディングガイドがなかった点。どのような流れで PR を作成してレビュー依頼をするのか、Python のフォーマッターや Linter は何をつかうのかとか。あとはコードの書き方に統一感がなかったのも気になった。Lambda で API を書く場合は特に Web フレームワークを利用しない（コンテナ使えばできるが）ため、例えば共通処理はどのように切り出すかであったり、変数宣言時に型も明記するかなどが不明瞭だった。これらの問題は今後の課題。
直近のプロジェクトでは積極的にモブワークをした。素早く相談したり意思決定をしたかったり、コードレビュー時にお互いの認識が合わないといった場合に「モブりませんか？」と気軽に話せるのはよかった。話した内容は Wiki なり PR に明記するように心がけた。後で絶対に話した内容を忘れるので。VSCode やターミナル、Wiki を画面共有しながらあーでもないこーでもないとフラットに話せるのが心地よかった。画面共有は Gather を使った。常駐しているわけではないが、「いつもの部屋で」ができるのはとてもいい。Meet や Zoom だと都度ミーティングを払い出さないといけなくて手間だが、Gather は広いマップに複数の部屋があるイメージで他の人と被ったりすることもない。
www.gather.town
これからどうしていくのか
この 1 年はがっつりバックエンドをやってきたので、今後はフロントエンドもやっていきたい。
多くの場合、API はフロントエンドから叩かれてはじめて意味を成すため、フロントエンドを分かっていると、よりよい API を設計・実装できそうだと強く感じたから。
あとは、DynamoDB などの NoSQL もやっていきたい。関わったプロジェクトは RDBMS しか使っていないので、以降関わるプロジェクトでやっていきたい。
リリース作業も積極的に行った。まだまだ手作業な部分が多く、例えば DB のマイグレーションやサービスの動作確認、IAM ポリシーの権限修正などを手動で行っている。
人間なので手作業でやると必ずどこかでミスが発生する。挙げた手作業は全て自動化できる内容なので、開発初期の段階で自動化や IaC などを推進していきたい。
とはいえ開発中は機能の実装やバグ修正、打ち合わせなど様々なタスクに忙殺されることが多いので、日頃から検証しておくなどの素振りが必要。
インプット
読みきったものは少ないが、この 1 年は以下の書籍を読んだ（購入した）。
techbookfest.org
www.shoeisha.co.jp
gihyo.jp
www.oreilly.co.jp
www.oreilly.co.jp
gihyo.jp
gihyo.jp
www.seshop.com
www.shoeisha.co.jp
www.seshop.com
アウトプット
業務に関わるアウトプットはこれくらい。
enokawa.hatenablog.jp
enokawa.hatenablog.jp
enokawa.hatenablog.jp
おわりに
あまりまとまりがないが、インフラエンジニアからアプリケーションエンジニアへ転向した経緯ややってきたことをまとめた。
プログラミングの経験はかじる程度しかなかったが、この 1 年でフロントからバックエンド、インフラまで幅広く経験できて成長した実感がある。
まだまだ課題は山積みで、作りたいモノを作れるようにはなっていないが、こつこつやっていく。
