プログラミング サーバー フレームワーク 2026.05.22 33 既存システムのフレームワークを特定する方法 — フロント / バックエンド / インフラの調べ方 引き継いだ既存システムが「何のフレームワークで動いているのか」 分からない、というのはレガシー保守の最初の関門です。本記事では、ブラウザの DevTools、HTTP レスポンスヘッダ、Cookie 名、URL の拡張子、リポジトリのマニフェストファイル、特徴的なディレクトリ構成、Wappalyzer などのツール、そして AI に読ませる方法まで、フレームワーク特定の具体的な手順を整理します。 # フレームワーク # 保守 # レガシー
AI プログラミング ソフトウェア 2026.05.21 30 AI に古いコードを読ませる — レガシー保守の新しい入り口 AI コーディング環境の登場で、これまで「読み手がいない」「ドキュメントがない」と止まっていたレガシーコードの保守・移植が一気に動き始めました。AI に COBOL / Perl / VB6 を読ませて仕様を抽出する、テストを後付けで生成する、段階的に Python / Java へ移植する ── 新しい保守ワークフローと、AI に任せていい範囲と人間が必ず見るべき範囲を整理します。 # 保守 # レガシー # Claude Code
プログラミング ソフトウェア 2026.05.21 36 レガシー言語の市場価値 — COBOL / Perl / Delphi はなぜ稼げるのか COBOL は今も金融機関の基幹システムを動かし、Perl は出版・通信のテキスト処理で現役、Delphi は中小企業の業務 Windows アプリで生き残っています。需要は減っているのに、できる人がさらに減ったことで、給与は逆に上がる構造に。レガシー言語の市場価値、稼げる理由、参入の現実的なルート、注意点をまとめます。 # キャリア # レガシー # Perl
ソフトウェア プログラミング 2026.05.21 34 「枯れた技術」を選ぶ価値 — 新しい言語を追わない戦略 新しい技術を次々追いかける戦略には大きなコストがあります。一方で「枯れた技術」(Bash / sed / awk / cron / make / SQL / Vim / Apache HTTPD のように、もう新しい話題にはならないが、地味に動き続けている道具)を選ぶと、実績豊富・運用知見が広い・学習投資が長く効くなどのメリットが残ります。「主役を退いた」レガシー(COBOL / VB6 など)とも、「いまも本流の主役」(PostgreSQL / Linux / Python など)とも別物。3 つの違いを踏まえて、技術選定・キャリア・学習投資の軸を整理します。 # キャリア # レガシー # 運用
ソフトウェア 2026.04.14 50 古い業務システムを誰も触れなくなるのはなぜ？放置されやすい理由を整理 古い業務システムを誰も触れなくなる理由を、属人化、仕様の口伝、壊す恐怖、改修コストの不透明さ、業務優先で先送りされる構造から実務目線で整理した記事です。 # 保守 # ITプロジェクト # 古い業務システム
