私がこれまでに仕事をしてきたすべての組織に、それが存在する。誰も触りたがらないシステムだ。それは給与計算や顧客ファイル、あるいは基幹取引を処理しており、致命的な障害を起こすことなく20年間稼働し続けてきた。そのシステムを構築した人々は、まだ在籍しているか、あるいは最近退職したばかりだ。システムの刷新は、誰も始めたがらない予算争いを意味するため、決定は翌年へと先送りされる。そして、その翌年へと。
以前の私は、これをテクノロジーの問題であり、CIO（最高情報責任者）が自ら選んだスケジュールで解決すべき事案だと考えていた。しかし、今は違う。先送りとは、技術的な判断を装ったリーダーシップ上の決定にほかならない。そして、業務の継続性やコンプライアンス、組織の知見に責任を持つエグゼクティブこそが、問題のシステムを一度も開いたことがあろうとなかろうと、そのリスクを背負っている張本人なのだ。
このパターンが最も顕著に現れるのが、公共部門の近代化だ。そこでは先送りのサイクルが数十年にわたり、公衆の面前にさらされながら繰り返される。だからこそ私は、Software Solutionsで営業・マーケティング担当バイスプレジデントを務めるグラント・ハルシー（Grant Halsey）に話を聞いた。同社は、まさにこの種の近代化に取り組む地方自治体を支援している。ここから得られる教訓は、「まだ動く」システムを抱えているすべての創業者や経営層にも、そのまま当てはまる。ハルシーとの対話から学んだ、思考が破綻するポイントを以下に紹介する。
1. 先送りは予算の問題ではなく、ガバナンスの欠落である
システム刷新の決定を、予算編成のたびに深く考えずに先送りできる単なる「予算項目」の問題として扱いがちだ。ハルシーは、なぜそのような考え方が定着してしまうのかを説明した。「決定を先送りしても、組織は通常、明日も機能し続ける。そのため、『今年はこれで乗り切り、来年また考えよう』と言うのが非常に簡単になる。これが危険な非対称性を生む。保守契約をもう1年更新したからといって誰も責められないが、大規模なシステム移行が失敗すれば、誰もがそれを記憶にとどめるからだ」
このインセンティブ構造は数字にも現れている。IBMの2025年の調査によると、各組織はIT予算全体の17〜27%を、新たな開発ではなく技術的負債への対処に費やしていると見積もっている。調査対象となったエグゼクティブの4分の3が、ハルシーが指摘したのと同じ根本原因を挙げた。つまり、ITがコストセンターとして扱われ、そもそも負債を防ぐことよりも、問題を先送りすることを促すようなインセンティブ設計になっていることだ。
彼の言葉を借りれば、発想の転換は単純だ。「このシステムはまだ動くか」と問うのをやめ、「このシステムは、組織が5年後や10年後にあるべき姿になるのを今も助けているか」と問い直すことだ。それこそが、保守の決定という行為の裏に隠された、リーダーシップの本質的な問いである。
2. レガシーシステムのリスクは、コードと同等に「人」を通じて増大する
目に見えるリスクは技術的なものだ。時代遅れのアーキテクチャ、脆弱なシステム連携、セキュリティの穴。だが私が過小評価していたのは、人に関わるリスクだった。ハルシーは、はるかに定量化しにくい機会費用を指摘した。優秀な社員が古い技術を補うために費やす1時間は、顧客対応、情報分析、そして組織を実際に前進させる問題解決といった、より高付加価値な業務に充てられなかった1時間なのだ。
この損失は、机上の空論にとどまらない。2020年、数十年前に開発されたプログラミング言語で構築されたニュージャージー州の失業保険システムは、パンデミック時の申請急増によって機能不全に陥った。同州は、この言語を扱えるボランティアを公に募集する事態に追い込まれた。最も重要な局面において、システムを十分に理解し、対応できる人材がほとんど残っていなかったのだ。
これこそが、ハルシーの指摘するパターンだ。組織が先延ばしにする期間が長くなるほど、場当たり的な回避策（ワークアラウンド）が積み重なり、ベテラン社員の退職とともに組織内の知見が消えていく。そして、現状の能力と現代のテクノロジーとの乖離は広がっていく。「なぜそのシステムがそのように動くのか」を理解している人々が去るとき、組織が独自のスケジュールでシステムを近代化する能力もまた、彼らとともに失われる。
3. 所有権がIT部門だけに留まるとき、近代化は失敗する
最初の2つのポイントを理解しているリーダーであっても、この点を見誤ることが多い。予算を承認し、ベンダーを雇い、プロジェクトをIT部門に丸投げする。そして、なぜプロジェクトが途中で頓挫するのかと首を傾げるのだ。問題の一因は構造的なものだ。ハルシーの説明によれば、このような決定は同時に複数のグループに関わってくるからだ。IT部門は技術的な問題を捉え、財務部門はコストを監視し、各部門のリーダーは旧システムが引き起こす日々の摩擦を肌で感じている。これほど多くのステークホルダーが関与していると、全員が意思決定の一部に関わりながら、誰も最終的な成果に責任を持たないという状況に陥りやすい。
この問題に対するハルシーの処方箋は明快だ。「最も健全な組織では、リーダーシップ層の誰かが、単なるソフトウェアの選定だけでなく、より大きな問いに答える責任を負っている。それは『わが社が今後10年間に必要とする能力は何か、そして、現在それを手に入れる妨げになっているものは何か』という問いだ」
この責任は、ベンダー選定委員会に委ねることはできない。システムの稼働時間（アップタイム）も含め、組織がどこに向かっているのかに責任を持つ人物が引き受けなければならないのだ。
もしあなたが経営層としてこの記事を読み、まさに私が書いたような古いシステムを思い浮かべているなら、自分が先延ばしにしてきた議論が何であるかをすでに理解しているはずだ。こうしたシステムは、静かに壊れていく傾向がある。決定を先送りすることが安全な選択肢であるかのように見せかけるだけの、最低限の機能性を保ち続けるが、ある日突然、それが安全ではなくなる。この事態を未然に防ぐリーダーは、誰かに求められる前に自ら主導権を握り、将来にわたって組織が必要とするものと、現在その行く手を阻んでいる障害とを天秤にかけて判断している。
