システム刷新の成否は、いつ判定されるのか

基幹システムの刷新は、切り替え当日に成功か失敗かが決まるように見える。実際には、その日は測定を開始する日にすぎない。旧環境の指標を新環境が下回るまでには、しばしば年単位の時間がかかる。

いつ測るかで結論が変わる

刷新プロジェクトの評価時点を切り替え直後に置けば、多くの案件は成功と記録される。予定された機能が動き、旧システムは停止した。だが同じ案件を18か月後に評価すると、障害対応の件数、変更を届けるまでの日数、インフラ費用のいずれかが悪化している例は珍しくない。

これは測定の恣意性ではなく、移行という現象の性質である。新環境の運用知識は蓄積に時間がかかり、旧環境で暗黙に処理されていた例外系は、しばらく経ってから表面化する。

老朽化は放置の結果ではない

米国会計検査院（GAO）は2016年の報告書 GAO-16-468 で、連邦機関が運用する主要な IT システムのうち相当数が数十年にわたって稼働しており、更新計画が定まっていないものがあると指摘した。2019年の後続報告 GAO-19-471 でも、同種の課題が継続していることが示されている。

ここで注意したいのは、老朽化が単なる怠慢の産物ではないという点だ。稼働し続けているシステムは、稼働し続けている限りにおいて、置き換えの必要性を主張しにくい。刷新の予算は、事故が起きるか、保守要員が退職するか、規制が変わるかしたときに初めて動く。

一括か、漸進か

Martin Fowler が2004年に記述した Strangler Fig パターンは、旧システムを稼働させたまま、機能単位で新システムへ処理を移し、最終的に旧システムを取り除く方式である。イチジクの一種が宿主の木を覆いながら成長する様子に由来する。

この方式の利点は、各段階で切り戻しが可能であり、失敗の影響範囲が限定されることにある。欠点も明快で、移行期間中は二つのシステムを同時に運用しなければならない。この二重運用の費用と、一括置換の失敗リスクを、どちらが大きいかで比較することになる。

• 一括置換：移行期間が短い。失敗時の切り戻しがほぼ不可能。
• 漸進置換：切り戻しが可能。移行が長期化し、完了しないまま放置される事例がある。

漸進置換が「完了しない」というのは、実務上の主要な失敗様式である。残った旧システムの機能が周辺的すぎて、誰も移行の予算を取れなくなる。

反論：複雑性は移せない

Fred Brooks は1986年の「No Silver Bullet」で、ソフトウェアの複雑性を本質的なもの（essential）と偶有的なもの（accidental）に分けた。偶有的複雑性は道具の改善で削減できるが、本質的複雑性は問題そのものに由来するため、表現手段を変えても残る。

刷新の議論では、この区別がしばしば省略される。「古い言語で書かれているから複雑なのだ」という診断は、偶有的複雑性の存在を正しく指摘している。だが、業務規則そのものが数十年の例外処理を蓄積している場合、新しい言語で書き直しても規則の数は減らない。減らすには業務側の合意が要る。

一方で、この指摘を理由に刷新を退けるのも行き過ぎである。偶有的複雑性が本質的複雑性を覆い隠している状態では、そもそもどの規則が必要なのかを判別できない。刷新の第一段階は、しばしば規則の棚卸しそのものになる。

完了の定義を先に置く

刷新を評価可能にする方法は、単純ではあるが実行されにくい。着手前に、完了を判定する量を宣言しておくことである。配送性能の四指標のように既に確立した枠組みがあるなら、それを使えばよい。旧環境で同じ指標を測っておくことが前提になる。

測っていない環境から測っていない環境への移行は、原理的に成否を判定できない。そして多くの老朽システムは、測るための計装を持たないまま運用されている。刷新の前にまず観測を入れる、という順序は、基盤側の投資と同じ理由で後回しにされやすい。目に見える成果が出ないからである。