はじめに
はじめまして。株式会社TOKIUMのプロダクト開発の部署でエンジニアリングマネージャ(以下、EM)をしている、西川です。
長く運用しているサービスほど使用技術の「バージョンアップって本当に大変だよな〜」と感じる瞬間がたくさんありますよね。
特に Ruby のようにメジャーアップデートが続く言語では、後回しにしていたツケが一気にまわってきたり、依存ライブラリが足を引っ張ったり、、、と、頭を抱えることばかりです。
弊社のメインプロダクトは2016年にサービスを開始し、もうすぐ10年を迎えようとしております。
これまでに幾度となくRubyのアップグレードを行ってきましたが、直近のアップグレードにおいて行った改善について、簡単ではありますが、記録的な意味も込めてご紹介いたします。
1 これまでは
これまでのアップグレードを振り返ると下記のような状態で行っておりました。
-
一気に大きくバージョンアップしようとしてきた
- 大跳躍を試みたため、変更点が増えすぎて、必然的に対応をリリースするまでのリードタイムが長くなっていました。
-
既存開発の優先度が高い時期と重なり、特定技術領域に継続的に専念できる体制を十分に確保できていなかった。
- 挙動の差分調査や依存関係の読み解きにどうしても時間がかかってしまいました。
-
意思決定の責任者が不明確
- 意思決定の責任者が不明確なことにより、足踏み状態となり、時間のロスが発生していました
-
プロダクト開発スピードがとても早く、複数チームによるコードが更新が活発
- アップグレード用ブランチとメインブランチの差分がどんどん広がり、追従が非常に困難になりました。
2 今回のアップグレードはどのように進めたのか？
過去の経験を踏まえて、今回は「段階的アップグレード」と「PJチーム体制」に重点を置いて取り組みました。
2.1 段階的アップグレードを選択した理由
今回は一気にまとめて大きくバージョンを上げることをやめ、細かいバージョンアップを繰り返し行うことにしました。
段階的にアップグレードする方針を選択した最大の理由は、
「差分の小さいリリースを繰り返すことで、影響範囲を明確にし、品質を担保するため」 です。
一度に大きくバージョンを上げてしまうと、どの変更がどの不具合を引き起こしたのかという問題の原因が Ruby 側なのか、gem 側なのか、その他要因なのかが切り分けにくくなります。
そこで今回は、各段階で発生しうる影響を事前に調査したうえで、「小さく進めて、すぐにフィードバックを得る」というアプローチに切り替えました。
2.2 PJチームの再構築
これまでの課題として
- 特定技術領域に継続的に専念できる体制を十分に確保できていなかった。
- 意思決定の責任者が不明瞭
があり、今回は次のような体制で臨みました。
- Rubyのアップグレードに詳しいメンバーを中心に専任のコアチームを組成。
- プロジェクト進行の基本的な意思決定はチームメンバーに裁量を持たせ任せる。
- チームメンバーが負えないレベルの意思決定、関連部署や他開発チームとの各種調整は私(EM)が担う。
この体制を取ったことで、専門性に裏打ちされた判断と、集中できる環境を両立し、安定して前に進めるチームでPJをこれまで以上に推進することができました。
2.3 メインプロダクトの開発スピード
今回のアップグレードは、プロダクトの状況的にもちょうど良いタイミングでした。
これまでと比較するとプロダクトが成熟してきていることもあり、メインプロダクトの開発スピードが少し落ち着いており、新機能開発とアップグレード作業が衝突しにくい状況でした。
2.4 テストコードの拡充
今回のアップグレードを安全に進めるうえで助けになったのが、昨今のAIの隆盛の恩恵もあり、AIを活用したテストコードの拡充です。
これまでテストコードが存在しなかった 1,300 を超えるソースコードファイルに対して、AI を用いて短期間でテストを生成し、約2週間でテスト実装を完了しました。
その結果、プロダクト全体のテストカバレッジは従来の 90% 台から 96% 台へと大きく向上。
アップグレードによる影響を検知できる範囲が広がり、作業の安全性と安心感が格段に高まりました。
3 印象的だった対応
今回のアップグレードの際にも大変なことは色々とあったのですが、印象的だったことは下記にようなことです。
3.1 テストコードがカバーしていない箇所で不具合が見つかった
上述したとおり、もともとカバレッジは90%台あったため、「きっと大丈夫だろう」と思っていたところ、最初のアップグレード版のQAチームによるテストにて、テストコードでカバーできていない箇所で不具合がみつかり、これを機に急遽テストコードのカバレッジを上げるために、1,300 を超えるソースコードファイルに対してテストコードを追加しました。
3.2 CSV出力用のフォーマットファイルの人力での動作確認
弊社プロダクトでは、CSV 出力用のフォーマットファイルが約 3,500 ファイル存在しており、これらは仕様上テストコードの実装が困難で、AIを利用してもその解決は一筋縄ではいかず、テストによる安全網を十分に確保できなかったため、上述の3.1の不具合の発覚を受け、すべてのファイルの人力による手動での動作確認を行いました。
4 成果
- 対応期間
- 2025/8/1 〜 2025/12/9
- 本番環境へのアップグレードリリース回数
- 3回
- 関与メンバー
- PJチーム: 3名
- EM: 1名
- QAチーム: 複数名
5 まとめ
今回の段階的アップグレードでは、技術的にも組織的にも多くの学びがありました
5.1 小さく刻んでアップグレードする重要性
まず、一気に上げるのではなく 小さく刻んでアップグレードする重要性 を強く実感しました。差分が小さくなることで、影響範囲の特定や障害時の切り戻し判断がしやすくなり、結果として品質とスピードの両方を高めることができました。
5.2 テストコードの存在がアップグレード成功率を劇的に引き上げる
AIの活用によって1,300ファイル超のテストファイルを短期間で整備できたことは、テストコードの存在がアップグレード成功率を劇的に引き上げる という示唆を強く残しました。
また、それと同時に人力確認を余儀なくされた 約3,500 のフォーマットファイルについては、
「AIによる自動でのテスト実装が困難な領域をどう解決していくか。」という課題を突きつけられました。
5.3 適切な責任分担は技術的難易度の高いプロジェクトの成功を支える
Rubyを深く理解するメンバーを中心にコアチームを組成し、チームには裁量を、EM である私が上位調整と最終判断を担うという体制は、適切な責任分担は技術的難易度の高いプロジェクトの成功を支える という、組織運営の面での学びにつながりました。
6 これから・・・
今後は下記を計画しています。
- 使用しているRuby on Railsのアップグレード
- 実装が困難であるフォーマットファイルへのテスト拡充
最後に
以上が今回のアップグレードに際して行った改善の概要とそれを通じて得た学びや教訓になります。
同じような取り組みを進める方々にとって、少しでも参考になれば幸いです。
引き続きプロダクトの品質や開発者体験の向上に向けて改善を続けてまいります。
Discussion