移行やバージョンアップで意識している5つのこと

はじめに

こんにちは、株式会社CARTA ZERO所属エンジニアのたいせい(to_meito)です。普段は大量のトラフィックをさばく10年来の広告配信システムの開発・運用を行っています。

システム移行やバージョンアップは、ソフトウェアエンジニアであればどこかで向き合う機会がある仕事です。実際に一度はこれらを経験し、手順通りに進めることはできるようになった、という方も多いのではないでしょうか。

一方で、いざ自分が主となって進める立場になると、「この進め方で本当に良いのか」「何を基準に判断すればいいのか」と迷う場面も少なくありません。技術的な手順は調べられても、考え方の拠り所が見つからない、という感覚です。

私もCARTA ZEROで働く中で、こうしたシステム移行・バージョンアップの仕事と向き合ってきました。直近では、EC2で長期間稼働していたバッチ群をECS Fargateへ移行したり、Aurora MySQLのメジャーバージョンアップなどを主導したりしてきました。

本記事では、私がこれまでシステム移行やバージョンアップに携わる中で、意識してきた考え方や判断の軸を整理します。

前提を疑う
既存の知見を考えの素材にする
どうやって戻すかを意識する
属人化を避ける・再現性をつくる
作業や確認を自動化する

書いてある内容自体はどれも特別なものではなく、当たり前に感じられるかもしれません。それでもこの記事を通して、移行やアップデートに向き合う際の当たり前の水準が少しでも上がるきっかけになれば幸いです。

前提を疑う

移行・バージョンアップのプロジェクトが立ち上がる計画の初期段階において、まず向き合うべきなのが前提を疑うことです。

移行・バージョンアップのありがちな落とし穴は、やること自体が目的になってしまうことです。

サポート期限の終了や、最新バージョンの登場といった外的要因によって移行すべきと判断されるケースは多くあります。

しかし、それをそのまま鵜呑みにしてしまうと、移行そのものが目的化してしまうことがあります。その結果、既存システムが抱えていた課題や、チームの制約（人員・スケジュール・コストなど）を十分に考慮しないまま、新しい環境に同じ問題を持ち込んでしまうことになりかねません。

そのため私は、どんな移行計画においてもまずやらない選択肢を含めて検討するようにしています。

バッチのECS移行を進めた際も、単に Fargate に乗せ替えるという方針に飛びつくのではなく「既存の EC2 環境を延命できないか」「段階的に移行することはできないか」といった観点を含めて議論しました。

このように、技術的な正しさだけでなく、組織やシステム全体の制約を踏まえて決断することが重要です。

最終的にどの選択を取るにしても、なぜその道を選んだのかを説明できる状態をつくることも重要です。それが、移行やバージョンアップといった仕事を、個人、あるいはチームとして納得感のある意思決定へと変えてくれると考えています。

既存の知見を考えの材料にする

具体的な方針を検討する調査の段階で、先人の知恵である既存の知見を積極的に参照します。

移行やバージョンアップには、すでに多くの事例や知見が存在します。公式ドキュメントや技術記事、他社の事例など、参考にできる情報は数多くあります。

しかし、こうした既存の知見をそのまま自分たちのシステムに当てはめることはアンチパターンです。一般論としては正しく見える手法でも、チームの規模やシステムの成り立ち、運用体制によっては最適とは限らないからです。

重要なのは、なぜその方法が有効なのかを理解した上で、自分たちの状況に照らして判断することだと思っています。 既存の事例は答えではなく、考えるための素材として扱うことで、現実的で納得感のある意思決定につながります。

どうやって戻すかを意識する

いよいよ詳細な手順を固める準備段階で私が最も神経を使うのが、どうやって戻すかという視点です。

移行やバージョンアップにおいて、絶対に失敗しないような計画を目指していないでしょうか？

もちろん失敗しないのが一番いいですが、どれだけ綿密に準備しても想定外の事態は起こりえます。私はその前提に立ち、問題を起こさないことではなく、問題が起きても戻せることを重視しています。

例えば、Auroraのバージョンアップを担当した際は、Blue/Green Deploymentの採用や、新旧環境の並行稼働期間を設けたりすることで、早い段階で問題に気付き、切り戻せる状態を作りました。

完全に安全な移行計画というものは存在しません。しかし、戻せる設計をしておくことで、たとえ予期せぬ問題が発生しても冷静に対処でき、結果として安全に移行を終えることができるようになります。

移行やアップデートのような業務こそ、こうした戻れる仕組みを意識して設計することが、プロジェクトを安定して前に進めるための鍵だと考えています。

もちろんここから先は後に引けない、といった段階もあるので、どこまで戻せる状態を作るか？といったところは腕の見せ所です。

属人化を避ける・再現性をつくる

実際の移行作業、そしてその後の運用を見据えたとき、欠かせないのが再現性の担保です。

移行やバージョンアップの作業は、できることなら一度きりで終わらせたい仕事です。同じ課題が何度も発生する状態は、チームにとって健全とは言えません。

一方で、実際の開発や運用の現場では、システムやインフラに対して日々小さなアップデートが積み重なっていくのが現実です。前提条件や周辺環境が変われば、過去に対応したはずの課題が、別の形で再び顔を出すこともあります。

その意味で、移行やアップデートを完全に終わらせることは、簡単ではありません。だからこそ私は、こうした業務に取り組む際、次に同じ状況が発生しにくくなる仕組みを作ることと、それでも発生したときに迷わず対応できる状態を残すことの両方を意識しています。

再発を前提に諦めるのではなく、現実的な制約の中で起きにくくしつつ、備えるという考え方です。ここで重要になるのが、属人化を避けるという視点です。個人の経験や勘に依存したやり方は、短期的には効率が良く見えても、時間が経つにつれて再現性を失い、チーム全体のリスクになります。特定の人だけが判断できる状態を避け、判断や対応を仕組みとして残すことが、継続的な改善につながります。

また再現性を残すとは、単に作業手順を記録することではありません。なぜその判断に至ったのか、どのような制約や背景があったのかといった、意思決定の文脈を共有することがあって初めて、次に似た状況に直面したときの助けになります。日々の小さな変更を前提にしながら、大きな失敗を繰り返さないための仕組みを積み重ねていくプロセスこそが、個人の経験をチームとして使える資産に変えていくのだと考えます。