概要
今年の8月ごろに異動してから半年が経過したので、振り返りも兼ねて異動後の心境や自分のやってきたことをまとめてみます。
※「これって私の感想ですよね?」という内容なのでご注意ください。
異動前
大規模なアプリ(Javaだけでも全体で1GB以上、大雑把に計算すると1600万行とか)の中の一部の機能の保守担当でした。Redmineに切られたBugのチケットは常に数百件以上で、問い合わせ対応の件数も非常に多い部署でした。
そのため、Bug修正や問い合わせ調査のためにソースと向き合う時間よりも、打鍵やリリースのための作業や問い合わせ返答など、手続き的な時間のほうが多いような業務内容でした。
そして、すでにたくさんのユーザーが存在する以上、Bug修正時はデグレのインパクトが非常に大きいため、「ウォーターフォール開発でとにかく慎重な作業が必要」という感じでした。
自分が触ることのある言語/ツール/技術は大体以下の通りでした。
| 区分 | 言語/ツール/技術 |
|---|---|
| バックエンド | Java(8) |
| Oracle | |
| PostgreSQL | |
| フロントエンド | JavaScript |
| テスト・CI/CD | Mockito |
(こう見るとすっくない…)
もちろんこのプロダクトにはもっとたくさんの技術が使われているのですが、いかんせん規模が大きいので、各グループが担当する技術はどうしても限定的になりやすい状況です。
わたしは末端エンジニアなので、ほぼほぼJavaとにらめっこするだけで終わってしまう毎日でした。
社内での取り組みで自身の経験値をレポーとして可視化するのですが、ほとんどの技術項目が「0: 未経験」になっているグラフを見て落ち込んだりしていました。
そんな中、突然「社内製品に関するAI相談の製品を新規開発中で、このチームからも一人協力してもらえないか」という話が舞い込んできました。もともと「AIに興味あり」と手上げしていたこともあり、幸運にも私にお声がけいただいたので、挽回するチャンスだと思って異動させていただくことにしました。
異動後
リリース前のAI相談アプリの1機能の新規開発に異動しました。
全体でも30MB程度のソースであり、スクラム開発でPDCAをガシガシ回しながらソースがどんどんと追加されていく環境です。
また、このリポジトリに手を加えるメンバーが10人程度なので、隅から隅まで自分たちでなんとかする感じです。
あまりの変化に、最初のうちはビビりまくり・緊張しまくりの毎日でした。
この半年で私が触ったことのある言語/ツール/技術は大体以下の通り。
| 区分 | 言語/ツール/技術 |
|---|---|
| バックエンド | Java(19) |
| Spring Boot | |
| Spring Framework | |
| PostgreSQL | |
| Python | |
| フロントエンド | Vue.js |
| TypeScript | |
| JavaScript | |
| インフラ | AWS関係 |
| Azure関係 | |
| テスト・CI/CD | Mockito |
| GitHub Actions | |
| Playwright |
他のメンバーはさらに幅広い技術を使いこなしているので、現在も私はその後を必死で追っている最中です…。ですが、それでも異動前と比べれば非常に幅広い技術やツールに触れることができているので、私がこの異動で得たかったものがしっかりと得られているという手ごたえを感じています。
さらに、主機能が「AI相談」なので、生成AIに関する勉強会などの知識共有がチーム内では盛んに行われています。そのおかげで、生成AIの最低限のロジックや仕組みについてはしっかりと理解することができましたし、実際にAzure OpenAIのSDKを使って文章を生成させる処理の実装をしたり、開発作業でCopilotやDevinなどのAIツールを活用する機会も多く、なんだかとても 「新しいことやってるぜ」感 があります。こういうのがあるとやっぱり自己肯定感とかモチベーションがあがりやすいですね。
苦労したこと
全然コードが読めない
普段「.java」ファイルしか見てなかったので、異動して間もないときは、「ソースコードレビューお願いします」と渡されたPRに「.py」とか「.ts」とか「.vue」など見慣れない拡張子がドバーーーッと入っていて絶望しました。
かとって、Javaなら読めるかと言うと、Java8に無い記法があったり、Springがわけわからなかったり、リアクティブプログラミング(自分にとっては難しすぎて非常に鬼畜な技術)が用いられていたりで、そこにも救いはありませんでした。
さらに、大規模アプリのバグ修正とは異なり、1つ1つのPRの差分も大きいものが多いです。数百行のPRがポンポンと出てくる状況に、「わァ……ァ……」とちいかわしていました。
解決方法: ソースコードレビューのやり方を教わる
この状況は早急に改善しないとまずいと思い、チームリーダーにソースコードレビューをやっている様子を見せてほしいと依頼しました。そこで以下のような気付きがありました。
- リーダー陣もある程度は苦労して読んでいる(難しいPRは1時間以上かかることも)
- Githubの画面で差分だけを見てレビューするのは相当難易度高いのでお勧めしない
- VSCodeの拡張機能「Github Pull Request」が便利
- いきなり「コメントをつけよう」と考えて読むわけではなく、まずは修正内容を理解することに注力する
- 差分を見たら、ソースの流れを意識してどこから読むか決める
- 例: MVCPモデルを採用しているので、バックの処理はまず「○○Controler.java」からだろうなと考え、そこから読むなど(私はその辺の知識もよわよわだったので、Devinを使って設計思想周りの解説をさせまくりました)
- 読み始めたら、とりあえず範囲選択してcopilotに「選択範囲を解説して」と投げておく
- 自分が読んでみてイマイチわかりにくい部分などをcopilotの回答と照らし合わせて補強する
- 「やたら知識だけある同僚(普通に間違えたりもする)」とモブプロをしているイメージ
- 本当に全く読めない言語のときは、「選択範囲を1行ずつ解説して」と投げるとかなり捗る
- 指摘内容に関してはある程度経験則になるのはしょうがないかも
- 「ここはセキュリティ的に問題になりやすいから注意して見よう」など思うようになっていったとのこと
などなど。
書いていて恥ずかしいくらい初歩的な内容も多いですが、私にとっては大きな気づきでした。
(というか、コーディングスキルは「レビューを受ける」「動作確認・テストをする」「バグやデグレを起こすこともある」という都合上、必要に迫られてスキルアップする側面がありますが、コードレビューに関してはそういうのがあんまりなくないですか…?なんでみんなできるんだ…)
そして、上記を意識してソースと向き合った結果、少しずつ読めるようになっていきました。めでたし。
移動前後の比較
それぞれの部署でのメリットを自分なりにまとめてみようと思います。
大規模アプリの保守(異動前)のメリット
- バグやデグレを発生させるインパクトが大きいため、ひとつひとつのタスクを丁寧に実施する力がつく
- 〆切が厳しいタスクが多く、優先順位や代替案を用意する力がつく
- 問い合わせ対応により、ユーザーがどういう部分で躓くのかや、どのような不具合が業務に影響を与えるのか理解できる
- 小規模開発と比べると、比較的コミュニケーションスキルが求められる場面が多い(気がする)
小規模AIアプリの新規開発(異動後)のメリット
- バグやデグレに対するインパクトがまだ小さいため、素早く開発する力がつく
- 新しいコーディング、ツール、思想などを試しやすく、とにかく幅広い経験が積める
- 小規模なので、メインのソースだけでなく、CI/CDやインフラ周りまで、すべてが手の届く範囲にある
- 生成AIについて明るくなることで、ネガティブなイメージが払しょくされ、どんどん活用していこうと思える
こんな感じでしょうか。
あとがき
年末に殴り書きした内容なので、とっ散らかっていてすみません。
もし読んでくださった方がいましたら、お付き合いいただきありがとうございました。
来年はもう少し技術っぽいことも書けるように意識しながら、引き続きこの部署で頑張っていきたいと思います。