10年以上前のシステムをモダナイズした話 — 技術選定で失敗しないための3つの問い

「もう10年以上前のシステムで、保守の限界が見えてきた」。刷新案件は、ほとんどがこの一言から始まります。ただ、技術選定から入ると失敗します。技術より先に決めるべきことが3つあって、その順番を間違えないかどうかが結果を分けます。実案件の判断プロセスを記録します。

技術選定から入ると失敗する

刷新案件の相談で最初に聞かれるのは、技術スタックの話です。「Javaから何に移すべきか」「クラウドはAWSかGCPか」。気持ちは分かりますが、技術選定はいちばん最後にやる仕事です。先に決めることが3つあります。

順番が逆だと、決めた技術に合わせて要件を曲げることになり、刷新の目的が見えなくなります。

問い1：なぜ今、刷新するのか

「もう古いから」では刷新の根拠になりません。古いシステムは動いているので、コストをかけて新しくする理由は別にあります。よくある理由を3つ挙げます。

(1) 事業の変化に追従できない：新しい商品や仕組みを足したくても、既存システムに組み込めない。事業判断に技術が追いついていない状態です。(2) 保守の人がいない：作った人が退職し、誰も触れない領域がある。属人化の限界です。(3) 運用コストが事業規模に合わない：売上に対してインフラ・ライセンス費用が重すぎる。

この3つのどれが主因かによって、刷新の規模も技術の選び方も変わります。

問い2：何を捨てて、何を残すのか

古いシステムには、使われている機能と使われていない機能が混ざっています。刷新で全部移そうとすると、現行と同じものが新技術で作られるだけで、コストに見合いません。

実案件で必ずやるのは 機能の利用ログ確認 です。直近6か月で使われていない画面・帳票は、移行対象から外す候補にします。「念のため残したい」と言われやすいですが、移行範囲が広がると失敗確率が上がります。判断材料を出すのは技術側の仕事です。

問い3：どの順番で切り替えるのか

移行をどう進めるかで、リスクの大きさが変わります。代表的な戦略を整理します。

移行戦略の選択肢

実案件で採用が多いのは ストラングラー です。新機能や改修したい機能から新システムで作り、旧の機能を順次置き換えます。並走期間中の運用は重くなりますが、各段階で切戻しできる安心感が大きい。基幹業務を抱える企業にはこの戦略を勧めることが多いです。

技術選定はその後

3つの問いに答えが出ると、技術選定は機械的に進みます。事業変化に追従するならクラウド・マイクロサービス寄り、保守性重視なら型のある言語・フレームワーク、コスト最優先ならマネージドサービス活用、といった具合に方針が決まるからです。

逆に言えば、技術の議論が紛糾しているうちは、3つの問いのどこかが詰まっていない可能性が高い。技術論を一旦止めて、上流に戻ったほうが早く着地します。