システムを無駄にしない社会へ──レガシーITがつくる持続可能な未来【レガシー侍】

「未来を予測する最良の方法は、それを発明することだ。」
― アラン・ケイ

システムは「消費するもの」なのか

新しいシステムを導入する。数年使う。古くなったら、次のシステムへ置き換える。
ITの世界では、こうしたサイクルがごく自然なものとして受け入れられてきました。もちろん、技術は進歩します。
より高速なコンピュータが登場し、クラウドが普及し、SaaSが広がり、そして今は生成AIが企業ITのあり方を変え始めています。
新しい技術を取り入れることは重要です。

しかし、新しい技術が登場するたびに、これまで蓄積してきたものをすべて捨てる必要があるのでしょうか。
システムを「一定期間使ったら交換する製品」とだけ考えてしまうと、その中に蓄積された価値を見落としてしまいます。
これまでVol.1からVol.9まで、レガシーシステムについてさまざまな角度から考えてきました。

最終回となる今回は、少し視点を広げます。
企業のIT資産を、もっと長い時間軸で考えることはできないか。
そんな問いから始めたいと思います。

企業のシステムには、時間そのものが蓄積されている

長年使われてきたシステムには、単なるプログラム以上のものが残されています。
たとえば、

• 顧客との取引の歴史
• 商品やサービスの変化
• 法制度への対応
• 過去のトラブルから得られた教訓
• 現場で生まれた工夫
• 企業独自の判断基準

です。
システムには、その会社が事業を続けてきた時間そのものが刻まれています。
ある処理だけを見れば、不自然に思えるかもしれません。

しかしその背景を調べると、
「以前、こんな事故があったから追加された」
「この顧客との取引条件を守るために必要だった」
「当時の法改正に対応するためにつくられた」
といった理由が見えてくることがあります。

そこにあるのは、単なる古いコードではありません。企業が何年、何十年とかけて積み上げた意思決定の履歴です。
そう考えると、レガシーシステムは「古い設備」とは少し違って見えてきます。

「使い続ける」と「変え続ける」は両立できる

ここまでの連載で繰り返し触れてきたのが、「残すか捨てるか」という二択から離れることでした。
使い続けることは、何も変えないことではありません。
むしろ重要なのは、使い続けるために、変え続けることです。
建物を考えてみると分かりやすいかもしれません。長く使われている建物は、そのまま放置されているわけではありません。

• 屋根を修理する。
• 配管を交換する。
• 電気設備を更新する。
• 耐震補強を行う。

必要に応じて部分的に更新しながら、建物そのものは使い続けます。
ITも同じように考えることができます。すべてを一度に交換するのではなく、

• 残すもの
• 改修するもの
• 新しい技術に置き換えるもの
• 外部サービスに委ねるもの

を見極める。
Vol.6で取り上げた「更新可能性」という考え方は、ここにつながっています。
古くならないことを目指すのではありません。古くなっても、変えられること。それが長期運用の基本になります。

人材もまた、使い捨てにしてはいけない

持続可能性を考えるとき、システムだけを見ていてはいけません。
そこに関わってきた人の知識も重要な資産です。

IT業界では、新しい技術に詳しい人材が評価されやすい傾向があります。
クラウド。AI。データ。新しいプログラミング言語。
もちろん、これらを扱える人材は必要です。

一方で、数十年前の技術を知っている人にしか分からないこともあります。
COBOLやPL/Iといった言語そのものだけではありません。

• なぜ、このデータ構造なのか。
• なぜ、この順番で処理するのか。
• なぜ、この例外だけ別の扱いになっているのか。

そうした背景は、長年システムと向き合ってきた人が持っています。
これを「古い技術しか知らない」と片付けてしまえば、貴重な知識まで失われます。

一方で、ベテランの経験だけに依存していても、未来には進めません。
必要なのは、過去を知る人と、未来をつくる人をつなぐこと。
Vol.8で取り上げた知識継承やコミュニティの役割は、そのためにあります。

AIが広げる、レガシー資産の可能性

そして今、この流れにAIが加わりました。
Vol.9では、AIがレガシーシステムの「読む」「探す」「つなぐ」を支援できる可能性について考えました。
これは、レガシーITの価値を大きく変える可能性があります。
これまで、

• 「人が読まなければ分からない」
• 「担当者に聞かなければ分からない」
• 「資料が多すぎて調査できない」

とされていた領域に、AIが入れるようになってきたからです。
たとえば、

• 大量のソースコードから処理の特徴を抽出する
• 関連するプログラムを探す
• 古い資料を横断して情報を検索する
• 仕様のたたき台を生成する
• 人が気づきにくい関連性を提示する

といったことが考えられます。
これによって、これまで「調査コストが高すぎるために捨てるしかなかった資産」を、もう一度評価できる可能性が生まれます。AIは、古いものを自動的に新しくする魔法ではありません。

しかし、「分からないから捨てる」という判断を減らす技術にはなり得ます。
これは、レガシーITにとって大きな変化です。

企業の中だけで知識を閉じない

さらに視野を広げると、レガシーに関する知識は、一つの企業の中だけで考える必要はありません。
たとえば、ある企業では一人しか知らない技術でも、日本全体を見れば、同じ技術を経験してきた人が何百人、何千人といるかもしれません。
ある会社では初めて直面する問題でも、別の会社ではすでに経験済みかもしれません。
ここに、コミュニティの可能性があります。
企業の壁を越えて、

• 経験を共有する
• 技術を学び合う
• 若い世代へ知識を渡す
• 新しい技術との組み合わせを考える

ことができれば、一社では維持できない知識も、社会全体では残すことができます。
レガシーシステム対応を、それぞれの企業が孤立して抱えるのではなく、社会全体で知識を共有する。
これは、人材不足が進む中で、ますます重要になる考え方ではないでしょうか。

「100年使えるシステム」は可能なのか

「100年使えるシステム」と聞くと、非現実的に感じるかもしれません。
100年前の技術を、そのまま100年間使い続けるという意味なら、もちろん現実的ではありません。

しかし、100年間、変化しながら使い続けられる仕組みという意味なら、考える価値があります。
そのために必要なのは、一つの技術を100年間維持することではありません。
むしろ、

• 技術を交換できる
• データの意味を残せる
• 業務の背景を伝えられる
• 新しい人へ知識を渡せる
• 必要な部分を継続的に更新できる

といった能力です。
つまり、「100年使えるシステム」とは、一つの完成されたシステムではありません。
100年間、更新され続ける仕組みです。

この視点に立つと、サステナブルなITの意味も変わってきます。
電力消費や機器の廃棄だけではなく、知識、データ、システム資産を無駄にしないこともまた、ITにおける持続可能性の一つなのではないでしょうか。

レガシー侍が目指したい未来

「レガシー侍」という名前には、過去の技術を守る人という印象があるかもしれません。
しかし、本当に必要なのは、過去を守るだけの存在ではありません。過去を読み解き、価値を見極め、次の技術へ渡す人です。

• 古い技術を知る。
• 新しい技術も理解する。
• そして両者の間をつなぐ。

いわば、過去と未来の通訳者です。
これからのレガシー侍は、COBOLやメインフレームだけを扱う人ではないと考えています。
今日のクラウドも、SaaSも、ローコードも、AIも、いつか必ずレガシーになります。
だからこそ必要なのは、特定の技術に依存することではなく、技術が変わっても、企業の知識と価値を次へ渡せる能力です。
それを世代を越えて育てていくこと。そこに、レガシー侍コミュニティの一つの役割があるのだと思います。

おわりに：過去を資産にできる社会へ

Vol.1では、「全部捨てるDX」について考えました。
そこから、

• レガシーは本当に悪なのか。
• 標準化と独自性をどう考えるのか。
• ブラックボックスをどう理解するのか。
• 捨てない経営とは何か。
• 更新可能性とは何か。
• 安全とは何か。
• 属人化をどう乗り越えるのか。
• AIと人はどう共存するのか。

というテーマを追いかけてきました。

そして10回目でたどり着いたのは、とてもシンプルな問いです。
私たちは、これまで積み上げてきたものを、未来のために使えているでしょうか。
過去を何でも残せばよいわけではありません。古い技術に固執する必要もありません。役割を終えたものは、手放す。
標準化した方がよいものは、標準に委ねる。新しい技術を使った方がよいところは、積極的に変える。

しかし、その前に一度だけ、「ここに、未来へ残すべき価値はないか」と問いかけてみる。
その習慣があるだけで、システムとの向き合い方は変わるかもしれません。
技術は変わります。人も変わります。会社も変わります。

それでも、そこで生まれた知恵まで失う必要はありません。過去を残すのではなく、過去から価値を受け取り、次へ渡す。
それが、システムを無駄にしない社会への第一歩であり、レガシー侍がこれからも考え続けたいテーマです。

※免責・ご注意
本記事は、レガシー侍コミュニティにおける一般的なナレッジや議論をもとに、ChatGPTにより生成・編集された内容を含みます。
本記事は、特定企業の公式見解、サービス仕様、提供方法、プロジェクトの進行方法、成果物等を示すものではありません。また、記載内容を前提とした発注、見積依頼、契約上の条件としての利用を想定したものではありません。個別のシステムに関する判断や対応は、それぞれの状況、要件、リスクおよび契約条件に応じて検討する必要があります。