2021年5月のふりかえりです。 引き続き B 社(週5日)にて Rails 製の EC サイトの開発業務と Engineering Manager / Scrum Master 業務に携わっています。

5 月はマネジメント2割、プレイヤー8割といった割合で対応していました。

マネジメント系

  • 今の開発チームとして、約半年ぶりにスキルアセスメントを実施しました。
    • アセスメントを採取すると同時に全員と 1on1 を行い、歴史を紐解きつつ未来についてディレクションするなどしました。
    • 5 月からの参画メンバーとの初 1on1 という意味もあり、一旦の立ち上がりはうまくいってそうな感触がつかめてグッドでした。
  • 採用
    • デザイナー採用を開始しました。
      • JD 作成、候補者ピック・評価などを行っています。
    • エンジニア採用は一旦落ち着いていますが、リファラルプールの作成を開始しています。
      • ビジネスサイドの規模拡大と歩調を合わせてエンジニアを採用していく想定なのですが、それの布石と行ったところです。
  • エンジニアリングマネジメント業務の整理
    • 今の開発チームは PdM/EM/SM の役割を僕ふくめ 2 人でやっているのですが、より明確に PdM 張り付き一人と EM/SM 張り付き一人(こちらが僕)という整理にしました。
    • 僕はもうひとりから採用・組織設計面を引き取った感じです。
    • もうひとりがより PdM 業務に集中する、同時に、ビジネスサイドのタスク・ロールを巻き取っていくという狙いになります。
      • 従来の体制のまま継続していくと中期的にビジネスサイドの事業拡大スピードが頭打ちになることが見えていて、最大のリスクになると考えているのでそこを埋めに行くイメージで変更しました。

プレイヤー系

  • 静的解析強化
    • 4 月から引き続きで Rubocop の Metrics cop を一般的な Rails プロジェクト並にキツめの設定に変えていく作業を継続して完了しました。
    • ESLint や SlimLint などを Github Actions で実装して CI に組み込みました。もともと ESLint についてはローカル実行・Codacy実行をやっていましたが、明確に CI でエラーにするようにして、コードベース品質の安定化を行う方向に修正しました。
  • もの日対応、TV対応、マーケ施策対応など
    • TV 放映があるという情報が直前に入り、急遽サーバー増強するなどしました。実際にはちょっとしか放映に乗らなかったのでアクセス微増な感じで終えました。
    • 上記のTVも含め、5月の前半はもの日期間にあたるため、EC2 の微調整を頻繁に行っていました。
    • マーケチームによる新施策がいくつか試された期間で、トラフィック的に明確なスパイクが発生する状況になっていました。事業的にはひとつ上のステージが見えてきた感じがしました。
  • ECS 対応を開始
    • ECS + Fargate なクラスタを準備しました。
    • ヘルスチェックに応答するだけの小さな Rails コンテナを作って Github Actions でのデプロイを実現しました。
    • RDBMS は Aurora MySQL にしています。
    • その他、モニタリング・ログ・エラーまわりの検討を行っています、実装はこれからです。
    • ECS 対応をすすめるに当たって、既存の EC2 で動かしているアプリケーションの整理をしないといけなくてその対応も引き続き継続しています。
      • /public ディレクトリの整理など
  • ID 基盤
    • 今期の中長期計画の一部として ID 基盤を実装していく予定で、それに着手を開始しました。目的としては大枠で以下となります。
      • 既存システムを拡張していくにあたってのウィークポイントである認証・認可部分の刷新
      • 今後の API サーバー群で利用するトークンシステムとして
      • 既存ユーザープールを分解・整理して、データとして取り回しやすくする
    • 上記の ECS 対応の第一弾アプリケーションでもあります
      • 既存をいきなり ECS 対応するのはシステムの変化のジャンプが大きいので、こちらで小規模に既存システムに組み込んでいくイメージですね。
  • 緊急対応系
    • ちょっとした緊急対応系の案件をいくつか対応していました(ここには書けないやつですね)
      • その一つで、API Gateway + Lambda + Ruby な API サーバーを作りました。REST じゃなく HTTP API で作ったのでちょっとめんどくさいというか癖が強い感じはしました。
        • 昔 Lambda いじってたときも感じましたが、Lambda の IAM の設定変更の反映までがめちゃタイムラグがあって混乱しますよね。AWS さん、はよ修正して欲しい…
        • API Gateway と Lambda のメトリクスを Datadog の Timeboard に追加したりもしました。
    • メール配信まわりの社内からの問い合わせが結構ありました
      • CS やマーケがまだ内製なシステムに依存していてちょっとガタがきてるなぁというところです。
      • そろそろ Zendesk や Marketo を使う頃合いなのかなぁと考えたり話を進めたり、という状況になってきました。
  • delayed_job => Sidekiq 移植
    • 5 月中に delayed_job 完全撤去まで行けるかなと思っていましたが少しはみ出ました。
    • 残件は delayed_job 関連コード等の削除と deploy からの撤去になります。既存ジョブの Sidekiq 化は終わってます。
  • RDS => Aurora 移行
    • 現在運用しているサービスでは RDS MySQL 5.6 系を使っていますが、これが 8 月頭に EOL を迎えるので Aurora に移行する計画を実行中です。
      • パフォーマンス面・メンテナンス面の懸念から元々 Aurora へ移行する想定だったので、このタイミングにあわせて実施しちゃうことにしました。
    • 大枠の移行方法の検討は終わっていて、設定周りのマイグレーションの検討、実際の移行作業の実験をちょいちょいと進め始めています。
    • 6 月中に完遂したい気持ちですが、6 月にも小規模ながらもの日があるので難しいかもしれません。
  • エラー通知の整理
    • エラー通知先として Sentry や Slack のいくつかのチャネルがある状況、かつ、ノイズが多い状況でした。
    • この状況によって 5 月から参画していたメンバーが、デプロイによってエラーが発生した！と勘違いしてしまい切り戻すという課題が出てしまいました。(申し訳ない〜)
    • これを受けて、Slack のチャネルのエラー通知のノイズを大きく減らして、確実に対応が必要なものだけを通知するように変更しました。昔から課題という認識はありつつダラダラと先延ばししてしまった点を反省した感じでした。

おわり