導入部

こんにちは！テックリードの皆さん、今日も良いアーキテクチャ描いてますか？

今回からいよいよ、架空のプロジェクト「SampleProject」を舞台に、生々しい技術選定の裏側を解説していきます。
このプロジェクトの最大のミッションは、「稼働から十数年が経過し、スパゲッティ状態になったレガシーシステム（VB6 / ClassicASP）を、最新の.NET環境へ移行してGoogle Cloud（GCP）に載せること」です。

当時の私は、クラウド移行と聞いて「最新技術のオンパレードにできる！」とワクワクしていました。しかし、アーキテクトである上司が下した決断は、一見すると非常に「保守的」なものでした。

今回は、なぜ最新技術の採用が見送られ、一見泥臭く見える構成が「最適解」として選ばれたのか、その思考プロセスに迫ります。

【対象となる前提環境】

移行前：VB6, ClassicASP, Windows Server, SQL Server（オンプレミス）
移行後：.NET 8 (C#), Google Cloud (GCP)
対象読者：中級エンジニア、技術選定やアーキテクチャ設計に悩んでいる方

1. 巨大マイグレーションの重圧と「全部入り」の誘惑

【起結】⏱ 10秒まとめ：本章の結論

技術選定の罠は「理想を追い求めすぎること」です。古いコードを最新言語に書き換えること自体が巨大なリスクであり、同時にインフラも最新にしようとするとプロジェクトは高確率で炎上します。

【承】🌩 課題：こんなこと困るよね。難しいよね。

システムの刷新プロジェクトが立ち上がると、エンジニアなら誰しもこう思いますよね。
「せっかくGCPを使うんだから、Webサーバーはコンテナ化してCloud Runで動かしたい！」
「DBも高額なライセンスとおさらばして、超高速なAlloyDB（PostgreSQL互換）に乗り換えよう！」

しかし、現場のコードベースを見て現実に引き戻されます。
何百個もあるVB6の画面、謎のビジネスロジックが詰まったClassicASP、Windowsの特定のフォントや描画エンジンにがっつり依存した帳票出力機能……。これらを最新の .NET 8 に書き換えるだけでも、数え切れないほどのバグが出ることが容易に想像できます。

【転】💡 解決策：採用理由と他の選択肢

この状況で、アーキテクトはどのようにスコープを切るべきか。ADR（アーキテクチャ・ディシジョン・レコード）の観点ではこうなります。

選択肢A：インフラとアプリの同時フルリプレース（見送り）
- 見送り理由： レガシーコードを別言語に翻訳するバグに加えて、インフラ環境の変化（OSの違いやDBの違い）によるエラーが同時に発生する。問題が起きた際に「コードが悪いのか、インフラ設定が悪いのか」の切り分けができなくなり、泥沼化するため。
採用案：アプリのモダン化に全集中し、インフラのパラダイムは変えない
- 採用理由： 「絶対に失敗できないレガシーの書き換え」にリスク予算を全振りするため。まずは既存のオンプレミス環境とほぼ同じ構成をクラウド上に用意し、「プログラムの書き換えエラー」だけを純粋に追跡できる安全な土台を作る。

【結】💻 具体例：アーキテクチャ変遷のロードマップ

技術選定の会議で上司がホワイトボードに描いたロードマップ（イメージ）です。一度にゴールを目指すのではなく、フェーズを分けることでリスクをコントロールしています。

[Phase 0: 現状 (オンプレミス)]
  ・アプリ: VB6 / ClassicASP
  ・インフラ: 物理Windows Server + 物理SQL Server

[Phase 1: 今回のスコープ (安全な着陸)]
  ・アプリ: .NET 8 (モダン化成功！)
  ・インフラ: GCP Compute Engine (Windows) + Cloud SQL for SQL Server
  ※ アプリの書き換えに集中するため、インフラは「リフト＆シフト」にとどめる。

[Phase 2: 未来の構想 (真のクラウドネイティブへ)]
  ・アプリ: .NET 8 (Linux対応済)
  ・インフラ: GCP Cloud Run + AlloyDB
  ※ アプリが整理された後で、満を持してインフラをモダン化する。

【補足】🔰 初心者向け解説：マイグレーションとリフト＆シフトとは？
「老朽化した一軒家」からのお引っ越しに例えましょう。

マイグレーション（移行）： 古い家を壊して、最新の建材（.NET 8）で新しい家を建てること。

リフト＆シフト： とりあえず家具をそのまま段ボールに詰めて、別のマンション（クラウドのVM）にお引越し（Lift）し、引っ越した先でゆっくり家具を最新家電に買い替えていく（Shift）手法。一番安全なお引っ越しのやり方です。

2. アーキテクトの前に並んだ「3つの選択肢」と決断

【起結】⏱ 10秒まとめ：本章の結論

技術選定とは「最高の技術を選ぶこと」ではなく、「限られたリスク予算をどこに使うか」を決めることです。「ビッグバン・リリース」を避けることが、最大の防御になります。

【承】🌩 課題：こんなこと困るよね。難しいよね。

お客さんや経営層からはよくこう言われます。
「どうせ作り直すなら、後から2回工事しなくていいように、最初から一番良い（ランニングコストが安い）クラウドの形にしてよ」

お財布を握る側からすれば当然の要望です。しかし、第0回で解説した通り、Cloud Run（コンテナ）は「Linux」でしか動かず、AlloyDBは「PostgreSQL」ベースです。もし一発でこの環境へ移行しようとすると、既存の「Windows向けに作られた帳票ツール」などの資産が全滅し、ライセンス費用の削減額を遥かに超える莫大な再開発コスト（と炎上リスク）が降り掛かってきます。

【転】💡 解決策：採用理由と他の選択肢

これらを踏まえ、上司が作成した意思決定の記録（ADR）のコアとなる部分です。

選択肢A：Cloud Run ＋ AlloyDB の採用（見送り）
- 見送り理由： ライセンス費用はゼロになるが、帳票機能のLinux向け再構築、SQLの全面書き換えが発生する。レガシー移行と同時に行う「ビッグバン・リリース」となり、プロジェクトの頓挫リスクが許容値を超えるため。
選択肢B：Cloud Run ＋ SQL Server の採用（見送り）
- 見送り理由： DBのリスクは減るが、依然としてWebサーバーのLinuxコンテナ化が必要。Windows用の帳票ツールが動かない問題が解決しないため。
採用案：Compute Engine (Windows VM) ＋ Cloud SQL for SQL Server の採用
- 採用理由： 既存のWindows資産とSQL Serverの機能（Entity Framework等のコード資産）を100%活かす。ライセンス費用は残るが、システム停止によるビジネス損失リスクと、炎上時のデバッグ修正費用を考慮すれば、トータルコストが最も安く、確実な選択であると判断したため。

【結】💻 具体例：ADR（アーキテクチャ・ディシジョン・レコード）の書き方

現場で実際に書かれるようなADR（意思決定記録）のMarkdown記述例です。なぜその技術を選んだのか、チーム全体で納得感を持つための重要なドキュメントです。

# ADR: Webサーバーおよびデータベースのホスティング環境選定

## ステータス
承認済み (202X-XX-XX)

## コンテキスト
VB6/ClassicASPから.NET 8へのマイグレーションに伴い、GCP上のホスティング環境を選定する。
レガシーコードの書き換えリスクが非常に高いため、インフラ側の構成変更リスクは最小限に抑える必要がある。

## 決定
* Webサーバー: Compute Engine (Windows Server 202X) を採用する。
* データベース: Cloud SQL for SQL Server を採用する。

## 理由
1. 既存の帳票出力ライブラリがWindowsのGDI+に依存しており、Linuxコンテナ（Cloud Run）への移行は現時点で工数が見合わないため。
2. アプリの書き換えエラーとインフラエラーの切り分けを容易にするため。

## 影響
* Cloud Runの自動スケーリングの恩恵は受けられない。
* SQL Serverの商用ライセンス費用が継続して発生する。
* (将来への展望) アプリケーションの.NET化が完了し安定稼働したPhase2において、帳票ライブラリのLinux対応とCloud Runへの移行を再検討する。

【補足】🔰 初心者向け解説：ビッグバン・リリースとは？
文字通り、宇宙の始まりのように「すべての機能を一気に爆発的に新しくして公開する」手法です。
車に例えると、「高速道路を走りながら、エンジンとタイヤとハンドルを同時に最新パーツに交換する」ようなものです。もし車が止まってしまった時、エンジンのせいなのか、タイヤのせいなのか原因が全く分からなくなりますよね。だから、プロは「まずはエンジンだけ変えて様子を見る（段階的リリース）」を好むのです。

単語一覧 (Glossary)

ビッグバン・リリース (Big Bang Release): システムのハードウェア、ソフトウェア、ネットワークなどを一斉にすべて新しく切り替えること。リスクが非常に高く、現代の開発ではアンチパターンとされることが多い。
技術的負債 (Technical Debt): 「とりあえず今は動くから」と、場当たり的な古い設計やコードを放置し続けること。後になって機能追加やクラウド移行をする際に、利子となって莫大な改修コストがのしかかってくる。
ADR (Architecture Decision Record): チーム内で「なぜこの技術を採用したか（あるいは見送ったか）」という意思決定の背景を記録するドキュメント。未来の開発者が「なんでこんな設計にしたんだ？」と迷わないための道しるべになる。

いかがでしたか？最新技術の誘惑に打ち勝ち、プロジェクトを確実に成功へ導くための「リスク予算の配分」こそが、アーキテクトの真骨頂です。

次回、第2回では、今回見送られた「Cloud Run（コンテナ）」の壁について、さらに技術的にディープに掘り下げます。「コンテナにすれば何でも動くわけじゃない」という厳しい現実と、Windows資産との戦いをお届けします。お楽しみに！