なぜ人はレガシーを選び続けるのか──現場で見た選定のリアルと向き合い方

## 1. はじめに
最近、Qiitaで技術記事を書くようになり、他の方の記事を読む機会も増えました。
その中で特によく目にするのが 「モダン技術」「レガシー技術」という言葉です。

最初はなんとなく使われている印象でしたが、記事を書く立場になると
「これはモダンなのか？」「この記事は古いと見なされるのでは？」
といった意識が自然と強くなってきました。

SNSや技術系メディアでは、レガシー技術がまるで“時代遅れで悪いもの”のように扱われている場面も多く、少し違和感を覚えることもあります。
現場ではレガシー技術に支えられている部分も多く、モダン技術に乗り換えるにも理由や背景があります。

今回は、私自身が記事作成や現場経験を通じて感じた
「モダン技術」と「レガシー技術」への向き合い方について、正直な考えを整理してみたいと思います。


## 2.モダン技術とレガシー技術の定義（私見）

モダン技術、レガシー技術という言葉は、SNSやQiitaでもよく見かけるワードですが、
あまりに多く使われすぎていて、定義があいまいなまま独り歩きしていると感じています。

### 世間一般でのイメージ
私が見てきた中では、世間的な「モダン技術」とは、
- 最近話題になっている（トレンド技術）
- 技術系メディアやSNSで取り上げられている
- 企業や個人が積極的に導入している

といった特徴を持つものが多いように感じます。

例えばWeb系であれば、
Rubyであれば Rails、JavaScriptであれば React、Next.jsなどは、
「モダン技術」として語られることが多く、記事数も多く人気があります。

### 自分なりの定義
一方で、私自身はもう少し視点を変えてこう考えています。

#### モダン技術とは：
- 流行っているだけではなく、世間で求められ、継続的に改善・選ばれている技術や設計思想。
- 時代に合わせて改善されている
- 新しい働き方や考え方に適応できる
- 使う側が増えている or 新しい使われ方が生まれている

代表例で言えば、AWSのようなクラウドサービスはその典型です。
単に新しいだけでなく、世界中の開発者や企業が支える巨大なエコシステムと進化の連続があるため、
“モダンさが持続している”技術だと感じます。

#### レガシー技術とは：
「古い技術＝レガシー」ではなく、“変化に適応できない構造・思想”を指すのではないかと思います。
- 時代や運用に合っていない設計
- 外部連携や自動化に適さない
- ドキュメント・ノウハウが属人化している
- 変えたくても変えられない“構造的な硬直性”を持っている

極端な例で言えば、FAXやCOBOLなどはレガシーの象徴と言えるかもしれません。
（特にCOBOLは業務基幹系で“変えられない”事情があり、技術的よりも構造的なレガシーと言えます）

### 補足：技術だけじゃなく「思想」も含めて評価したい
私がレガシーを避けたいと思うのは、
単に「古いから」ではなく、「新しい挑戦を拒む設計」や「属人化の温床になる仕組み」だからです。
逆に、古くても柔軟に変化できる設計や思想を持っていれば、十分“モダン”だと考えています。

#### 実際の現場での例
- Excelやメモ帳文化 → 連携性・保守性の欠如
- SMBはレガシーっぽい技術に見えるかもしれませんが、家庭内用途や、限定的な社内ネットワーク内でのファイル共有においては、今でも実用的で現実的な選択肢です。
>ちなみに、以前の記事（[SMB導入記事](URL)）でも書いた通り、私はRaspberry PiでSMBを導入しています。
その際、以下の点を重視していました：
> - Windowsとの親和性が非常に高く、エクスプローラーで簡単に接続できる
> - 小規模な環境では運用コストが低く、すぐに使い始められる
> - SMBv2以上を適切に使えば、一定のセキュリティも保てる
>
> ただし、企業規模が大きくなり、ユーザー管理・セキュリティ・リモートアクセスが求められるようになると、NextcloudやSharePoint、Google Workspaceなど、よりモダンなソリューションへの移行が望ましくなります。

#### 自分は“使い捨て”ではなく“育てられる技術”を選びたいと思っています。

## 3.レガシー技術の価値と功罪
モダン技術が注目される一方で、私はレガシー技術を単なる「過去の遺物」として否定することには慎重であるべきだと考えています。
なぜなら、レガシー技術には「現場を支えてきた事実」と「学びの糧になる構造的特徴」があるからです。

---
### レガシー技術のメリット
#### 1. 経験値が蓄積されている
多くのエンジニアが使ってきたことでノウハウが豊富。
問題が起きても「調べれば誰かが通った道がある」。

#### 2. 導入・維持のコストが低い
インフラや設計を“ゼロから考え直す必要がない”ため、現場での即戦力として機能しやすい。

例：SMB、VBA、Windows Serverなどの既存インフラにそのまま乗せられる。

#### 3. 汎用性が高く、長く使われてきた実績
「生き残っている」ということ自体が、ある種の信頼性の証明。

現場目線で言えば、「わかっているものを使う安心感」も重要なファクター。

---
###  レガシー技術のデメリット
#### 1. 技術的な停滞を引き起こす
「今まで動いていたからこのままでいい」という空気が生まれやすい。

改善のモチベーションや好奇心が奪われ、「変えるリスクを恐れて何もしない」状態に陥りがち。

#### 2. 構造上の限界がある場合、それ自体がボトルネックになる
例：VBAで組まれた巨大なExcelツール。構造が複雑すぎて誰も触れず、属人化が進行。

FAX、COBOL、オンプレ限定の共有ドライブなども、運用スケールが変わると途端に破綻しやすい。

#### 3. 学習・再設計の阻害要因になりやすい
「レガシーからの移行経験がない」まま過ごすと、将来の設計判断力に差がついてしまう。

モダン技術への橋渡しになる“移行設計”に触れないまま、キャリアが進んでしまうリスクも。

---

### 両義的な特徴：レガシー技術は「教材」になり得る
構造的な問題や非効率さを抱えているレガシー技術は、技術を学ぶ上では最高の素材でもあります。

- 「なぜこの構成で限界がきたのか？」
- 「どうすれば改善できたのか？」

という視点で分析すれば、モダン技術を“便利そうだから使う”のではなく、意味を持って選び取る姿勢を育てることができます。

これは、単なる技術選定力だけでなく、「後輩に説明できる」「改善提案ができる」視点にも直結します。


## 4. 実際にレガシー技術に触れてみて感じたこと（現場での実体験）

現在私は、医療系システムの現場に常駐しています。
これまでに2社のIT系業務を経験してきましたが、その中で率直に感じているのは、
「レガシー技術そのものよりも、それを取り巻く“技術に対する姿勢”が問題」だということです。

### 1. 管理方法がバラバラで業務効率が悪い
現場では、作業や障害対応の進捗管理が次のようにバラバラな媒体で行われている状態です：

- Webツール（独自の管理画面）

- Salesforce

- Excelファイル（複数）

その結果、日々の業務では複数のツールを行き来して確認する必要があり、認識のずれや工数の浪費が発生しています。
こういった状況に対して「統一して管理する発想がない」のではなく、「バラバラでもなんとか回っているからそのまま」という空気が存在しています。

### 2. マニュアル化・自動化が進んでいない
もう1つ強く感じたのが、事務レベルの作業にすら手順書やマニュアルが存在しないことです。

- 新人への教育は口頭伝達のみ

- 簡単な手順も「自分でメモを取って覚えてね」というスタイル

- 定型作業にも自動化の発想がない

これは技術の問題というより、“技術以前の問題”でありながら、長く放置されている構造的課題だと感じています。
改善提案をする土台も整っておらず、属人的な方法が常態化してしまっているのが現状です。

### 3. 技術を取り入れる姿勢そのものが希薄
最後に、現場の空気として強く印象に残っているのは、
AIやクラウドなどの新しい技術に対する無関心さです。

「ChatGPTってすごいらしいね」と言いつつ実際には触れていない

「AIで仕事が奪われるって聞いたよ」くらいの温度感

現状維持が最善という空気が強く、未来に対する不安や準備がない

私は、こうした空気に触れるたびに、自分はこのままではいけないという危機感を持つようになりました。
自分自身が「技術を活かして改善できる人間でありたい」と思うようになったのは、
ある意味、こうした“停滞の空気”にさらされてきたからこそかもしれません。

### レガシーは技術だけではなく、「技術に向き合う姿勢」が問われている
これまで経験してきた2社ともに、規模や業種は違っても、技術に対する貪欲さ・改善への意欲が共通して欠けていたように思います。
だからこそ、私はこれから先、新しい技術に対してアンテナを立て、自分で使ってみて、発信していく姿勢を大切にしていきたいと強く感じています。

## 5.それでも改善をするなら…？
### ～レガシー環境でも、自分なりにできることを考えてみた～
レガシー環境の課題についていろいろと書いてきましたが、
「だからダメなんだよなぁ…」で終わってしまっては、ただの言い訳になってしまいます。
自分の立場や影響力が限られていたとしても、改善できる部分に目を向けて、小さく動くことは可能だと考えています。

### 前職での取り組み：通信施工管理の現場にて
前職（通信施工管理の現場）では、以下のような改善に取り組みました。

#### 1. Noteの導入による情報共有の効率化
メール・Excel・口頭とバラバラだった情報共有を、自分の裁量でNote（オンラインドキュメント）に整理。

手順・注意点・工事スケジュールなどを1か所にまとめることで、「教える手間」「記憶頼り」からの脱却を図りました。

#### 2. マニュアル作成による業務の標準化
そもそも存在していなかった業務マニュアルを作成。

「Noteの使い方」「定型業務の進め方」「よく使うExcel関数の使い方」などを自動入力・関数で簡略化。

自分の業務に関してはかなりの時間短縮とミス削減につながりました。

🤕 「会議減らせ」の逆風も…
改善を進める中で、

>「若い奴に会議減らすように言われなあかんのや」
>「代案お前は出せるのか？」

といった反発が来る未来が想像できてしまい、「根本改善ではなく“症状緩和型”の工夫」を選ばざるを得ない場面もありました。
それでも、「小さな改善の積み重ねが未来の自分の武器になる」と信じて取り組んでいました。

### 現職での現状と展望
現職（医療系システムの現場）でも、多少の自動化は自分が入る前に誰かが仕組んだものが部分的に残っているようです。
ただ、それを「誰がどう使っているか」「仕組みはどうなっているか」がほとんど共有されておらず、ブラックボックス化してしまっている印象です。

#### やってみたいこと（願望も含めて）
- 現存のExcel自動化・スクリプトの調査・再利用

- 社内共有用のNoteやNotionのような文書共有ツール導入提案

- 定型業務の手順書作成と簡単なフロー図（業務整理の第一歩）

- 自分の業務範囲から徐々に「自動化」「可視化」を広げていく

## 6.まとめ 〜レガシーもモダンも、結局は“どう向き合うか”〜
ここまで、私自身の現場経験や考え方を交えながら、「モダン技術」と「レガシー技術」について整理してきました。

率直に言うと、「レガシーだから悪い」とはまったく思っていません。

### Excelは本当に悪者なのか？
たとえばExcelは、技術界隈ではしばしば「古い」「非効率」と言われがちですが、
個人単位の用途においては今でも極めて実用的なツールだと私は思います。

- 家計簿や予算管理のように数字を扱う作業

- 単純な売上や数値推移をまとめて可視化する作業

- ローカル完結で高速・手軽に操作できる点

これらの用途では、「Excelで十分」どころか「Excelが最適」と言っても過言ではありません。

### 理想論 vs 現実論：みんながモダンを学ぶのは難しい
もちろん理想を言えば、誰もが技術に前向きで、
モダン技術を積極的に学び、共有し、改善提案できるような現場が望ましいと思います。

でも現実として、それはなかなか難しい。
特にIT業界では「業務としてやっている人」と「好きで技術を追い続けている人」の間に、
成長速度の差が広がりやすい構造があると感じています。

### 最後に：レガシーかモダンかよりも、“学ぶ姿勢”がモダンであれ
私が思うに、本当に大切なのは技術そのものではなく、
その技術にどう向き合い、どう改善しようとするかの姿勢ではないでしょうか。

少しうまいことを言うなら、

### 「技術がレガシーでも、学ぶ姿勢がモダンなら、それは十分に価値がある」

そんな風に考えながら、これからも自分なりに学び、試し、発信していこうと思います。

##  ご覧いただきありがとうございました！
もしこの記事を読んで、何か共感する部分や考えるきっかけになったとしたら嬉しいです。
今後も現場での学びや、試してよかったことなどを発信していきますので、よろしくお願いします。