ID:73591さん

分析DBサーバのコストカット・負債解消を狙い、DBサーバを統合するプロジェクトを担当しました。 移行先の新規テーブル設計に関しては社内のアーキテクトのレビューを受けながら進めました。 テーブル結合は基本的にコストが高いため、求められる要件からどこまで正規化するべきかチームで議論しながら進めたのでとても勉強になったと思います。 既存バッチやテーブル構成を読み解き、正しくリプレイスすることが求められましたので、集計SQLを作り既存と差分が出た場合はどちらがが正なのか、社内の有識者に確認したり、難しい場合はコードの背景やドメイン知識からあるべき仕様を考えてPdMに提案する形を取り、プロジェクトを推進しました。

5~9人のスクラムでチーム開発をしていました。 具体的な業務内容としては、旧管理画面がRoRで作られていたのを、フロントはReact・ TypeScript、バックエンドはGoへリプレイス作業を担当しました。 苦労した部分・工夫した部分は、リプレイス対象の仕様理解のためのコードリーディングや、仕様変更を行う際の影響範囲調査です。 リプレイス対象の仕様理解で工夫した点は、仕様の理解が曖昧だと正しくリプレイスできないので、コードリーディングから現仕様を読み解きドキュメントにまとめてチームに共有・レビューしてもらう形で、チーム全体進捗の貢献を図りました。苦労した点は、コードが読みにくく量も多いので理解に苦労しました。ただ、苦労した分、人の書いたコードや意図を推測する力は鍛えられたと思います。 影響範囲調査で工夫した点は、リプレイスを進めていく上で明らかな技術的負債・仕様の負債は解消したかったので、仕様を変更した時の影響範囲調査をコードベース、DBのデータ構造、有識者への確認など柔軟に進めて、プロダクトオーナー・チームで意思決定しました。苦労した点は合意を取る上で情報を正しく分かりやすく伝えないといけないため、ドキュメントのまとめ方や粒度、仕様の提案の仕方、議論をするための前提情報のインプットなど、勉強になることが多かったです。 上司の「エンジニアは難しいことを簡単にする仕事だ」と言った言葉は今も大切にして、意識しています。

具体的にはgemのアップデート、バージョンアップの影響で動かなくなった古いコードのリプレイスなどです。 gemの依存関係や、既存のサービスの動きを壊さないようにコードを書き換えるなど、勉強になることが多かったです。バックエンドは主に1人で担当させてもらえたので、貴重な経験になりました。 バージョンは、Ruby2.2.2→3.0.1、Rails4.2.3→6.1.4に上げました。 プロジェクト外でやっていた基本業務は以下です。 要件定義・基本設計・詳細設計 実装・リリース・障害対応 開発環境改善(Docker化) API設計・開発 RDBを使用したデータモデル設計 Redisを用いたキャッシュ対応・性能改善 Elasticsearchを使用した検索エンジンの最適化 ActionCableを使用したアバター機能の実装