何を残し、何を変えるか：オープン化の目的と移行方式の選び方
「保守費が高いのでオープン化したい」「技術者を確保しやすい言語に変えたい」「業務に合わなくなった仕組みを見直したい」。いずれもモダナイゼーションの出発点になりますが、必要な移行方式は同じではありません。
現行の動きをできるだけ変えずに移す方式に大幅な業務改革まで期待すると、目的と実施内容がずれます。逆に、保守期限への対応を急ぐ局面で、業務とデータを一度に全面再設計すれば、期限と予算の制約が厳しくなります。
方式を選ぶ前に決めたいのは、何を改善するために、どこまで変えるのかです。
「オープン化」を、投資の目的に言い換える
オープン化という言葉は、専用環境から汎用的な基盤へ移すこと、技術や接続方式を標準化することなど、異なる意味で使われます。本記事では、移行先のOSや言語を決めるだけでなく、保守・連携・調達の選択肢を広げる取り組みとして考えます。
その効果を評価するには、目的を観察可能な指標に言い換える必要があります。
優先したい目的 | 評価する指標の例 | 併せて確かめる条件 |
コストの適正化 | 同じ期間・対象範囲で比較した総保有コスト | 移行費、二重運用費、ライセンス、保守、教育、撤去を含める |
保守性の改善 | 変更の所要日数、影響調査の時間、テストの再現性 | 移行後のコードを誰が理解し、変更するか |
業務改革 | 入力の重複、承認の待ち時間、手作業の補正件数 | 業務ルールや部門間の役割も変更できるか |
継続性の確保 | 保守期限への対応、復旧時間、運用要員の確保 | 期限内に実現できる変更範囲はどこまでか |
これらをすべて同じ優先度にすると、方式を絞れません。「今回の移行では継続性を最優先し、業務改革は次の段階で進める」といった順序を明確にすることが、現実的な計画につながります。
三つの方式は、変える範囲が異なる
呼び方はベンダーやサービスによって異なります。リホスト、リプラットフォーム、リライト、リファクタリングといった名称だけで判断せず、業務・アプリケーション・データ・運用のどこを変更する提案なのかを確認します。
方式 | 主に残すもの | 主に変えるもの | 向いている条件 | 見落としやすい負担 |
既存資産をなるべく残す移行 | 業務ルール、画面や帳票、処理構造 | 実行基盤、ミドルウェア、必要な互換部分 | 現行業務が合っており、変更リスクや期限を重視する | 互換性検証、変換後資産の理解、専用ランタイムへの依存 |
設計を見直す移行 | 継承すべき業務ルールと取引データ | アプリケーション構造、データモデル、画面・連携 | 変更の難しさや業務上の制約が大きい | 要件の再確認、例外処理の再現、データ変換、受入テスト |
パッケージ・SaaSへの置き換え | 必要な業務結果と履歴 | 業務手順、画面、製品標準に合わせたデータ構造 | 業務を標準機能に合わせられる | 適合性確認、周辺連携、権限・帳票の差異、継続利用費 |
既存資産を残す移行でも、変換や検証は必要です。環境を移すだけで同じ動作になるとは限りません。一方で、設計を見直す移行でも、長年蓄積した契約条件や計上ルールまで捨てる必要はありません。残すべき知識と、改善すべき実装を分けて扱います。
AWSの移行評価ガイダンスも、事業上の要因と優先順位に合わせて方式の判断を見直し、アプリケーションの構成要素ごとに戦略を割り当てることを勧めています。方式を最初に一つ決めて、すべての資産に当てはめる進め方は避けたいところです。
AWS「移行戦略選択の見直し」(https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-7-rs-migration-strategy-selection.html)
コスト削減を狙うなら、移行後の運用まで計算する
移行費が安い提案と、運用を含めた総額が小さい提案は、同じとは限りません。比較期間をそろえ、初期費用に加えて、インフラ・ライセンス・監視・バックアップ・障害対応・教育・旧環境の撤去までを総額に含めます。
特に確認したいのは、旧環境をいつ停止できるかです。過去帳票の参照や、取り残された小さな連携のために旧基盤を維持すると、費用が二重にかかる状態が続きます。「主要機能の移行完了」と「旧環境の廃止可能」は、別の状態です。
クラウドやSaaSでも、利用量、接続方式、契約条件によって費用は変わります。単価だけで比較せず、通常月と繁忙期の使用量、データ保管量、運用体制をそろえた条件で試算する必要があります。
保守性を狙うなら、変換後のコードで評価する
言語を変えても、保守性が自動的に改善するとは限りません。複雑な依存関係や共有データへの直接更新がそのまま残れば、新しい言語でも変更は難しくなります。
自動変換を検討する場合も、変換できた行数だけで評価しないことが重要です。代表的な処理について、移行後の担当者が業務ルールを追えるか、変更箇所を限定できるか、テストとビルドを再現できるかを確認します。生成コードを直接保守するのか、元ソースから再生成し続けるのかでも、運用と教育の設計は変わります。
仮の例として、「得意先別の値引き条件を追加する」という変更課題を、新旧それぞれの構造で試してみます。影響範囲の特定、修正、テスト、リリース準備にどのような作業が必要かを比較すれば、言語名だけでは見えない保守負担を評価できます。
業務改革を狙うなら、現行踏襲の範囲を決める
パッケージへの置き換えでは、標準機能との差をすべて追加開発で埋めると、独自システムの複雑さを別の場所へ持ち込むことになります。ただし、製品標準に合わせるために、必要な内部統制や顧客との約束を切り捨てることもできません。
差異は、「事業上必要な独自性」「運用で吸収できる差」「過去の制約から生まれた慣習」に分けて判断します。たとえば独自帳票についても、レイアウトの完全一致が必要なのか、同じ情報を確認できればよいのかで、選択肢は変わります。
設計を見直す場合は、どの取引でどの情報を確定するか、訂正をどう残すか、どの部門が正本を更新するかまで確認します。画面をきれいに作り直すだけでは、業務の重複やデータの不一致は解消しません。
一つのシステムでも、方式は組み合わせられる
すべてを同じ方式で移行する必要はありません。競争力に関わる中核業務は設計を見直し、一般的な申請業務は標準製品に合わせ、安定した既存処理は当面活用する、といった組み合わせが考えられます。利用されていない機能は廃止候補、参照だけできればよい情報はアーカイブ候補として扱います。
ただし、方式を分けるほど、境界にあるデータ・認証・障害対応の設計が重要になります。部門ごとに別々の正本を作らないこと、連携エラーの処理責任を決めること、残した資産を次に見直す条件を定めることまで計画に含めます。
最初の検証では、簡単な画面だけを選ばず、外部連携、複雑な計算、締め処理など、方式の弱点が現れやすい対象を含めます。その結果を受けて、対象範囲、費用、工程を見直します。
株式会社Managetechが大切にするのは、技術の名称よりも、目的と変更範囲の整合性です。現行資産を残す理由、変える理由、廃止する条件を説明できることが、意思決定の質を高めます。
「何を選ぶか」が決まらないときは、製品比較に進む前に、今回の投資で必ず改善したいことと、維持しなければならない業務を整理するところから始めてみてください。
コメント