既存システムの一部をGo言語へ段階移行する方法

なぜ「段階移行」が現実的なのか（全部作り直さない選択）

既存システムを一気に作り直す（フルリプレイス）計画は、理想的に見えて失敗しやすい方法です。理由は単純で、動いている業務を止められないからです。特に中小企業や大企業の情シスでは「止められない」「担当者が限られる」「運用ルールが複雑」「ベンダーや他部署の調整が多い」といった制約が重なり、完成までの間に要求が変わってしまうことも珍しくありません。

そこで有効なのが、既存の一部から順に置き換える段階移行です。段階移行なら、現行を動かしながら新しい技術（ここではGo）を導入でき、投資対効果も説明しやすくなります。「まずは遅いバッチだけ」「障害が多いAPIだけ」など、狙いを絞って成果を作れるため、社内の合意形成にも強いです。

Go（Golang）はサーバーサイドの実装に向いた言語で、単体のサービスとして切り出して動かすのが得意です。並行処理（同時に複数の処理を進める）や、単一の実行ファイルとして配布できる運用のしやすさもあり、「レガシーの一部を切り出して置き換える」設計と相性が良いのが特徴です。

この記事では、開発の専門知識がなくても判断できるように、段階移行の進め方を「目的の整理→切り出し方→移行の手順→運用→失敗回避」の順に、業務シーンの例を交えて解説します。

移行の対象を選ぶ：Goに向いている領域・向いていない領域

段階移行で最初にやるべきは、「どこから移すと効果が出やすいか」の棚卸しです。ここを間違えると、難しい部分に手を出して頓挫したり、効果が小さく「移行する意味がない」と見られたりします。

Goに向いている（成果が出やすい）例

• API（外部・社内アプリ向けのデータ提供）：アクセスが増えるほど性能改善が効きやすい。エラー原因の切り分けもしやすい。
• バッチ処理・ETL（データ集計、連携、夜間処理）：処理時間短縮がKPIにしやすい。失敗時の影響範囲も限定しやすい。
• 通知・ジョブ実行・キュー処理：メール/Slack/Push通知、非同期処理など。小さく作って既存と連携しやすい。
• 認証以外の周辺サービス：画像変換、ファイルアップロード、PDF生成など、単機能に分けやすい。

最初は避けたほうがよい（難易度が高い）例

• 中核の業務ロジックが密結合している部分：仕様が暗黙知で、移すと業務が止まりやすい。
• 画面（フロント）と一体の古い仕組み：画面改修まで巻き込むと影響範囲が大きい。
• 決済・会計など監査や規約が絡む部分：移行は可能だが、最初の成功体験としては重い。

判断のコツは「境界が切れるか」です。既存と新規がやり取りするデータが明確で、入力と出力が定義できる領域ほど、Goの小さなサービスとして独立させやすいです。逆に、あちこちのテーブルを直接参照している、画面から直接SQLが飛ぶ、仕様が文書化されていない、といった場合は、先に整理（可視化）してからが安全です。

段階移行の基本パターン：Strangler（首絞め）と並走の設計

既存を止めずに置き換える代表的な考え方が、いわゆるStranglerパターンです。植物が木に絡みつき、徐々に置き換えていくイメージで、現行の周辺から新サービスを追加し、少しずつ責務を移していきます。

よく使う3つの置き換えルート

• ルーティングで切替：入口（API Gatewayやリバースプロキシ）で、特定のURLだけGoの新サービスへ振り分ける。
• 機能フラグで切替：同じ画面・同じ操作でも、裏側の処理だけ新旧を切り替えられるようにする（段階的なユーザー展開に強い）。
• バッチ/非同期から切替：夜間処理やキュー処理を先にGoへ。利用者の操作に直結しないためリスクを抑えられる。

情シス・管理者目線で重要なのは、「戻せる設計（ロールバック）」を最初から用意することです。段階移行は、切替の瞬間よりも「切替後に不具合が出たときの復旧」が勝負です。入口で振り分ける方式や機能フラグは、切替を戻す操作が明確で、障害時の判断が速くなります。

もう一つのポイントがデータです。既存とGoのサービスが同じデータを触る場合、無秩序に共有すると不整合が起きます。そこで「どちらが正（マスター）か」を決め、段階に応じて以下のように設計します。

• 最初：既存DBを読み取り中心で利用（新サービスは参照のみ）
• 中盤：新サービスが一部の更新を担当（更新対象を限定）
• 終盤：新サービスのDBに移行し、既存側への依存を減らす

この「依存を減らす順序」を設計図として持つだけで、移行は計画的になります。

進め方の手順：要件整理→切り出し→並走→切替→撤去

段階移行をプロジェクトとして進める場合、技術よりも手順の管理が成果を左右します。以下は、現場で再現性が高い進め方です。

要件整理（業務の“困りごと”をKPIにする）

「Goにしたい」では社内が動きません。代わりに、次のような業務KPIに落とし込みます。

• バッチ処理が朝まで終わらず、出社後の作業が遅れる → 処理時間を何分短縮したいか
• ピーク時にAPIが遅くなり、コールセンターに問い合わせが増える → 応答時間の目標
• 障害対応が属人化している → 監視・ログで原因特定にかかる時間を短縮

「何をどれだけ良くするか」が決まると、移行対象と優先順位が決まります。

切り出し（境界を定義し、インターフェースを固定する）

Goへ移す部分は、入出力を固定します。非エンジニア向けに言うと、「受け取る伝票」と「返す結果」を先に決めるイメージです。APIならリクエスト/レスポンス、バッチなら入力ファイル/出力テーブル、などです。ここが曖昧だと、開発中に「結局ここも必要」と範囲が膨らみます。

並走（新旧の結果を比較して品質を作る）

いきなり切り替えず、同じ入力に対して旧システムとGoの新サービスを動かし、結果を比較します。これにより、仕様の抜けや例外パターンが見つかります。特に会計・在庫・請求などは、端数処理や例外条件が潜みやすいため、並走期間が品質を決めます。

切替（小さく始めて段階的に広げる）

切替は「いきなり全ユーザー」ではなく、段階を踏みます。例としては、社内ユーザーだけ→一部拠点だけ→全体、または、トラフィックの1%→10%→50%→100%といった形です。問題が出ても影響が限定的になり、説明責任も果たしやすくなります。

撤去（旧機能の停止とコスト回収）

最後に重要なのが、旧側の機能を確実に止めることです。段階移行は「新しいものを足す」フェーズは進みますが、「古いものを消す」フェーズが後回しになりがちです。旧機能が残ると、保守費・監視費・セキュリティ対応が二重になります。撤去の完了条件（いつ、何を消すか）を最初から合意しておくと、投資が回収できます。

技術の肝：API設計・データ移行・互換性をどう担保するか

段階移行を成功させるための技術要点は、専門用語を減らすと「つなぎ目を壊さない」ことに尽きます。Goで新サービスを作っても、既存システムや周辺ツール（BI、RPA、他部署の連携）が期待する動きが変われば、現場が混乱します。

APIは「互換」を最優先にする

新旧で同じ機能を提供するなら、まずは既存APIの振る舞いを踏襲します。ここでいう互換性には、データ項目だけでなく、エラーの返し方、タイムアウト、並び順、文字コードなども含まれます。利用側が修正不要な状態を目標にすると、移行のスピードが上がります。

ただし、既存仕様が明らかに問題（例：曖昧なエラー、巨大なレスポンス）なら、互換のまま改善しきれない場合があります。そのときは「互換API（現行同等）」と「改善API（新仕様）」を並立させ、利用側が切り替えられる期間を設けます。

データは「二重更新」を避け、責任範囲を決める

最も危険なのは、旧システムとGoサービスが同じデータを勝手に更新し、整合性が崩れることです。対策として、以下のいずれか（または組み合わせ）を選びます。

• 更新担当を分ける：例えば「顧客マスタの更新は旧」「通知履歴は新」など、テーブルや機能で責任を切る。
• イベント連携：旧で起きた更新を「変更通知」として新へ伝え、同期する。
• 段階的なDB移行：まず参照、次に一部更新、最後に完全移行。

情シスが押さえるべきは、「どのデータを、どのシステムが正として持つか」を図にして合意することです。これがあるだけで、ベンダー間・部署間の認識齟齬が減ります。

Goの運用設計：ビルド・配布・設定管理

Goは単一バイナリとして配布できるため、運用がシンプルになりやすい一方、設定（接続先、鍵、環境変数）を適切に管理しないと、環境差分で事故が起きます。設定はコードに埋め込まず、環境ごとに外出しし、変更履歴が追えるようにします。また、ログは「検索できる形式」で出すと、障害対応が格段に楽になります。

以下は、APIサービスの最小構成イメージです（概念の例）。

# 例：環境変数で設定を管理（概念）
APP_ENV=prod
DB_DSN=...
LOG_LEVEL=info
HTTP_PORT=8080

失敗しやすいポイントと回避策（予算とスケジュールを守るために）

段階移行は万能ではありません。典型的な失敗パターンを先に知っておくと、予算超過や炎上を避けられます。

失敗：目的が「最新化」だけになり、途中で正当性が揺らぐ

「Goにすること」が目的になると、業務側から見ると価値が見えず、優先度が下がります。回避策は、最初に決めたKPI（処理時間、障害率、運用工数など）を、月次で追うことです。数字で効いたことを見せると、次の移行範囲の稟議が通りやすくなります。

失敗：境界が曖昧で、いつまでも“切り出し中”

「このデータも必要」「この画面も直したい」と増えていくのは自然です。だからこそ、インターフェース（入出力）を固定し、追加要望は次フェーズに送ります。段階移行は“完璧より前進”が鉄則です。

失敗：テストが不足し、切替後に業務が止まる

特にバッチや集計は、普段見ない例外で落ちます。回避策は、並走期間で結果比較を行い、差分が出たら「仕様の違い」なのか「バグ」なのかを分類することです。さらに、切替当日は復旧手順（戻し方）と連絡体制を決め、当番を置きます。

失敗：運用（監視・ログ・権限）が後回し

開発が終わっても、運用が整っていなければ「新しい障害ポイント」が増えます。監視（死活、エラー率、遅延）、ログ（検索できる形）、権限（誰が何を触れるか）をリリース前に揃えます。運用設計は機能の一部と捉えるのが重要です。

失敗：ベンダーや社内の役割分担が不明確

段階移行では、新旧システムの責任範囲が一時的に重なります。ここで「どこまでが既存ベンダー」「どこからが新規開発」「障害時の一次対応は誰か」を決めていないと、トラブル時に空白が生まれます。回避策は、RACI（責任分担表）に近い形で、判断者・実行者・連絡先を明確にすることです。

中小企業・情シス向け：社内説明に使える判断軸（費用対効果・リスク・体制）

技術そのものより、「なぜ今やるのか」を説明できるかが意思決定の肝です。Goへの段階移行を稟議・予算化する際に使える判断軸をまとめます。

• 費用対効果：処理時間短縮、障害対応工数削減、インフラ費削減（必要なら）を金額換算しやすい部分から始める。
• リスク：止められない領域は後回しにし、まずはバッチや周辺機能で成功体験を作る。
• 体制：社内にGo経験者がいなくても、外部支援＋運用手順の標準化で回る形を作る。
• 期限：移行完了を一気に目指さず、「四半期で1機能」のように小さな区切りを置く。

また、ベンダー選定の観点では「単にGoが書ける」だけでなく、既存環境（レガシー、現行DB、社内ネットワーク制約）を踏まえて、段階移行の設計と運用まで含めて提案できるかが重要です。ソースコードの品質以前に、切替・監視・復旧をどう設計するかで、現場負担が大きく変わります。

まとめ

既存システムの一部をGoへ段階移行する際は、「全部作り直す」よりも、境界が切れる領域から小さく始めるのが現実的です。まずはAPIやバッチなど成果が見えやすい場所を選び、Stranglerパターンで新旧を並走させながら、切替と撤去までを計画に含めます。

成功のポイントは、技術選定以上に目的（KPI）・境界（入出力）・ロールバック・運用を最初から設計することです。これにより、社内説明が通りやすくなり、予算とスケジュールを守りながら、レガシー依存を着実に減らせます。

「どこから移すべきか」「既存とのつなぎ目をどう作るか」「運用まで含めて安全に切り替えたい」といったお悩みがあれば、現状の棚卸しから段階移行のロードマップ策定まで、伴走支援が可能です。