2022年6月ふりかえり
2022年6月のふりかえりです。 引き続き B 社(週4〜4.5日)にて Rails 製の EC サイトの開発業務と Engineering Manager / Scrum Master 業務に携わっています。
6 月はマネジメント 5 割、プレイヤー 5 割といった割合で対応していました。
マネジメント系
- エンジニア育成
- 引き続き Code Complete を読み進めていく育成カリキュラムをチームメンバー全員でやりました。
- 上巻が完了したところで一旦終了して。
- 最近 RESTful API についての話が各所ででるようになっていたので、「Webを支える技術」を読みました。
- 内容的にはちょっと古い部分が多かったので補足しながら読み進めました。
- 続いて Google の 「API設計ガイド」 を読み進めています。
- こちらは内容は現代的ですが、 gRPC の話が混ざっているところがあるのでそのあたりを補足しながら読み進めています。
- 引き続き Code Complete を読み進めていく育成カリキュラムをチームメンバー全員でやりました。
- ソフトウェア検証関連
- 三ヶ月経過して、定常業務がまわる状況になっています。
- QA としての KPI づくりを開始しています。
- そろそろシステム全体のリグレッションテストを回せるようになりたいので、そのための進め方の相談を行ったり、システムから取れるデータを確認したりしていました。
- 最終的にはすべての機能あるいはストーリーのテストが揃っていて、都度取捨選択しながら必要なリグレッションテストが回せる、が最終ゴールという想定を置きつつ、既存システムの機能群をリストにするだけでも大分厳しい環境なので、Datadog RUM を活用して実際の業務での使われ方を洗い出しましょうという進め方になっているためデータを出したりしていました。
- TechLead 業務
- ひきつづき各エンジニアの成果物のレビューや、設計方針の相談・レビューなど、かなりの時間を各エンジニアとのやりとりに割いた一ヶ月になりました。
- 既存コードベース側の React.js の書き方を最近の普通の React として書いていくように進めており、みな徐々に馴染み始めています。
- ひきつづき各エンジニアの成果物のレビューや、設計方針の相談・レビューなど、かなりの時間を各エンジニアとのやりとりに割いた一ヶ月になりました。
プレイヤー系
- Developer Productivity Engineering 関連
- E2E で使用している技術の刷新がおこなわれました(他メンバーの対応)
- 従来は Cucumber や Webdriver IO を使っているレガシーな環境でしたが、今月から Playwright + TS な環境へ移行完了しました。
- IE11 の終了のタイミングでもあったので、クロスブラウザテストの範囲も含めてローカルで実施できるようになったこと、3〜5倍程度高速化できていること、あたりがとても改善されました〜!
- Datadog の課金ポイントが増える連絡があり、 Ingested Span の削減を行う作業をおこないました。
- Datadog の RUM のサンプリングレートを上げる対応をおこないました。エンドユーザー側のフロント面のサンプリングレートを 1% => 5% まで上げてある程度の範囲のユーザーの挙動確認ができる状態にしたのと、同時に、RUM を Annually 課金対象にしました。
- 各所で Open API による API 仕様の記述を行うようになっており、また、既存環境側では Open API を使わずに API 仕様の記述をおこなったりもしているため、そろそろ型を決める頃合いかな〜という状況になってきています。
- 基本的には Open API に寄せる前提です。個々の API の定義に重複が発生しやすいことがわかってきているのでそのあたりも型として決めていきたいと考えています。
- Audit Trail 系の基盤を構築中です(他メンバーの対応)
- 実装がはじまっています。今後の要素技術の相談をしたり、既存環境の要素技術のレクチャをおこなうなどしました。
- E2E で使用している技術の刷新がおこなわれました(他メンバーの対応)
- 検索関連
- 検索関連の開発から構築する想定であった、新 API サーバー群の構築を進めました。
- API GW + Lambda 等、GW の後ろに様々なバックエンドを置くことができるようにする前提でアーキテクチャ改善をすすめる想定です。
- Strangler Fig Pattern を意識しています。レガシーな Rails 環境を抱えており、そのレガシーを大きいまま改善しようとしても抜本的な改善が進まないという課題を 2 年ほど経験したのでアプローチを変えることにしました。
- GW の後ろに Lambda および内部向けの API GW および既存 Rails 環境から提供している API を接続する想定であり、その前提を踏まえた AWS CDK での構築の型を決めたり細かい部分の調整を行ったりしていました。
- 新 API サーバー群は既存 Rails 環境からの移行先でもあり、Rails からの移行を進めつつ、Rails を解体していこうという想定です。基本的に、今後は大きいサイズの Rails を作ることは無いという想定にしています。
- また、新規の API が必要な状況になった際には Lambda での実装をファーストチョイスにする想定です。
- API GW + Lambda 等、GW の後ろに様々なバックエンドを置くことができるようにする前提でアーキテクチャ改善をすすめる想定です。
- Lambda + Ruby な環境における実装で、Datadog の Lambda 対応がいまいちで色々なバグを踏み抜きつつ、ワークアラウンドを投入するのにかなり時間を取られました…
- 検索関連の開発から構築する想定であった、新 API サーバー群の構築を進めました。
- IE11 終了対応
- IE11 がついに終了したので、後続でどのような対応が必要になるかの検討をおこないました。
- webpack 設定、browserslist 設定、既存コードベースの古くなっていて捨てて良い記述の洗い出しなどをおこないました。
- Rails の View 側の Vanilla JS も IE に合わせなくてよくなるので、後続でガイドラインを更新する予定です。
- IE11 がついに終了したので、後続でどのような対応が必要になるかの検討をおこないました。
おわり