案件の打ち合わせで「Delphiで作り直すつもりはないんです」と言われ、フリーランスとして業務委託で入るなら、長く支えてきた経験は役に立たないのかと思いかけました。そこで相手が続けます。「ただ、この画面のボタンを押したときに裏で何が起きているのか、説明できる人がいなくて」。Delphiの経験は、画面の裏にある業務の決まりを読み出せる経験です。この記事では、その経験をどう言い直せば案件の話が進むのかを、OSの更新と仕様の復元という二つの入口から整理します。

1. Delphiの経験が通じにくく見える理由

古い言語という印象と、手元にある経験のずれ

Delphiは、Object Pascalという言語でWindowsの画面を作る道具として知られています。フォームの上にボタンや入力欄を置き、操作ごとの処理を書いていく作りで、業務アプリを長く動かしてきた現場があります。

ところが、案件の一覧や打ち合わせで先に目に入るのは、新しく作る話のほうです。Delphiで新しく作る案件は少なく見えるため、「古い言語」「Windowsの画面」「新規開発が少ない」という印象が先に立ちます。この記事では、その印象を経験が通じない証拠としては扱いません。

先にお断りしておくと、この記事はDelphiそのものについての統計や資料を使っていません。後ほど出てくる公的資料にもDelphiという語は出てこないため、Delphiの業務アプリを課題の一例として当てはめる部分は、筆者の見立てです。

図の作成：Remogu編集部。筆者の見立てを整理したもので、統計データではありません

書く力より読む力が働く場面

経験の長い人の手元にあるのは、「Delphiが書けます」という力よりも、「このアプリはこう動いているはずだ」と読み解く力のほうです。ボタンを押したときのイベント処理から業務の流れをたどり、データベースとのやり取りで何が書き込まれるかを追います。入力チェックと帳票の出力には、業務の決まりが形になって現れます。長く動かしてきた運用の癖まで含めて、画面の裏を知っています。

一方で、打ち合わせは「何を作れるか」から始まりやすく、読み出せることは自分から言わなければ伝わりません。実績の欄に「Delphi」とだけ書くと、古い言語という印象とそのまま重なります。筆者の見立てでは、書いた画面の数を並べるより、「仕様書のないアプリの動きを説明できる」という形で経験を示すほうが、相手の困りごとに届きます。

この見立てが当たるかどうかは、相手の側に困りごとがあるかで決まります。次の節では、公的な資料に書かれた課題を手がかりに、保守が特定の人に頼る状態を見ていきます。

2. 業務アプリの保守が特定の人に頼る状態

自由記述に挙がった人材と技術継承の課題

IPAは「2025年度ソフトウェア動向調査」の自由記述を整理した資料を、2026年3月10日に公表しています。2026年2月9日時点の回答結果362件をもとに、自由記述の設問の主要な意見が整理されています¹。

社会全体の共通課題として解決してほしいものを尋ねた自由記述では、人材育成・スキル継承の項目に、技術や業務の属人化、ナレッジ継承の難しさ、特定個人に依存した運用体制の課題が挙がっています¹。割合や件数は示されておらず、意見の整理です。

ここで注意したいのは、この362件が自由記述の件数ではなく、調査全体の回答結果の件数であることです。「多くの企業がそう答えた」といった読み方はできません。資料から言えるのは、保守や運用が特定の人に依存しているという課題が、意見として挙がっていることまでです。

レガシーシステムの項目と、筆者の見立て

同じ整理資料のレガシーシステムの項目には、OSやハードのサポート切れによるシステム更新コストと、機能は十分でもサポート切れなどによりシステム更新が必要になる、という意見が挙がっています¹。

これらの意見は、どの言語で作られたシステムの話かまでは書いていません。そのうえで、Delphiで作られた業務アプリは、機能は十分に動いていても、知っている人が限られる状態の一例になりうる、というのが筆者の見立てです。

この状態で任される仕事は、新しい機能を足すことより先に、いま何がどう動いているのかを説明することかもしれません。画面の裏を読み出せる人がいれば、特定の一人に頼っていた説明を、取引先全体で共有できる形に近づけられます。

整理資料の項目ごとの意見

整理資料で挙がった意見を、項目ごとに並べています。左が整理資料の項目、右が自由記述に挙がった意見です。数字として示されているのは回答結果362件（2026年2月9日時点）だけで、各意見の件数や割合は資料にありません。

整理資料の項目	挙がった意見
人材育成・スキル継承	技術や業務の属人化／ナレッジ継承の難しさ／特定個人に依存した運用体制の課題
レガシーシステム	OSやハードのサポート切れによるシステム更新コスト／機能は十分でもサポート切れなどによりシステム更新が必要になる

表の内容は、2026年2月9日時点の回答結果362件の自由記述を整理したものです。割合ではありません¹。では、サポート切れの話は、OSの更新を通じて業務アプリにどう関わってくるのでしょうか。

3. OSのサポート終了と、上で動くアプリの確認

IPAの呼びかけが述べていること

IPAは「Windows 10 のサポート終了に伴う注意喚起」で、2025年10月14日（米国時間）にWindows 10のサポートが終了したことを伝えています²。利用者には、後継製品または代替製品への移行などの対応が望まれるとしています。

同じ注意喚起は、対象OS上で稼働するアプリケーションもサポートが順次終了していくため、対策が必要だとしています²。OSだけでなく、その上で動くアプリにも目を向けるよう促す内容です。

ただし、この呼びかけの相手は、ソフトウェア製品の利用者です。開発者や保守を担う人に向けた文書ではなく、Delphiという語も、Windows 11で動くかどうかも書かれていません。Delphiで作ったアプリの動作の可否を、この文書から読み取ることはできません。

OSを替えるときに問われること

とはいえ、OSを替える場面では、その上で動いている業務アプリを誰が確かめるのか、という問いが残ります。これは筆者の見立てです。画面を開き、入力し、帳票が出るまでの一連を、どの条件で確かめれば「前と同じ」と言えるのかは、仕様書が残っていなければ、動かしてきた人の記憶に頼ることになります。

動作確認と影響の洗い出しは、新しいものを作る仕事ではありません。画面ごとの処理とデータベースとのやり取りを読み出し、OSの更新で影響を受けうる場所を並べていく仕事です。Delphiの経験が、書く側ではなく読む側で生きる場面です。

図の作成：Remogu編集部。IPAの注意喚起（2026年6月26日最終更新）をもとにした概念図で、統計データではありません

OSの更新に向けて確かめた画面と処理の内容は、そのまま仕様を書き起こす材料にもなりえます。次の節では、仕様が見えないまま残ったシステムが、なぜ次の検討に進みにくいのかを見ます。

4. 仕様が見えないまま残ったシステム

委員会が整理した現実のギャップ

ソフトウェアモダナイゼーション委員会の2025年度報告書（2026年3月24日）は、現実のギャップの1つとして、日本の企業や公共機関ではレガシーシステムが依然として残り、維持・運用が課題になっていると整理しています³。

同じ報告書は、ブラックボックス化したシステムはAIやデータ活用に適応しにくく、運用コストの増大や業務効率・競争力の低下を招いていると整理しています³。委員会の見解です。

報告書はDelphiに触れておらず、どのシステムがブラックボックスかも名指ししていません。仕様書が残っていないアプリに限れば、この見解が当てはまりうる、というのが筆者の見立てです。

文書に戻す仕事が入口になりうる理由

仕様書が無く、知っている人が限られるシステムは、移行もデータ連携もAIの活用も、検討に入りにくくなります。そこで先に必要になるのが、画面とコードから業務の決まりを読み出し、文書に戻す仕事です。Delphiの経験者にとっての入口になりうる、というのが筆者の見立てです。

図の作成：Remogu編集部。委員会報告書（2026年3月24日）の整理をもとにした概念図で、統計データではありません

どこまで文書が残っているかによって、任される仕事の範囲は変わります。その違いは【保守の案件】文書がどこまで残っているかで任される仕事が変わる理由で整理しています。

では、AIがコードを読めるようになったとき、人には何が残るのでしょうか。

5. AIがコードを読めても、人に残る判断

報告書が書く「人間主導+AI支援」

委員会の報告書は、AI駆動開発にはレガシーシステム解析やモダナイゼーションの加速が期待されている、と書いています³。古い業務アプリの解析にAIが使われる場面が増えていく、という見通しです。

同じ記述は、構造はあくまで「人間主導+AI支援」であり、最終的な判断や工程全体の管理は人が担っているとも述べています³。報告書は、期待と人の役割を対立するものとして並べてはいません。AIの支援を受けながら、判断と管理を人が持つ形が、現状の記述です。

ただし、この報告書は、どの作業をAIに任せ、どの判断を人が持つのかを一覧にしてはいません。AIがレガシーシステムを解析できる、とも書いていません。次に示す作業ごとの分け方は、この記述を手がかりにした筆者の見立てです。

作業ごとの任せどころと、人が持つ判断

古い業務アプリに手を入れる作業を、コードの要約・書き換え・テスト・移行の区切りに分け、AIに任せやすいところと人が持つ判断を並べています。左の列は作業、中央が下書きまでなら任せやすい部分、右が人に残る判断です。報告書の記述にある「判断は人が担う」という線を、現場の作業に当てはめた見立てで、資料に載っている分類ではありません。

作業	AIに任せやすいところ	人が持つ判断
コードの要約	処理の説明の下書き	その動きが業務の決まりか、昔の不具合の名残か
書き換え	別の言語への書き換え案	どこまで変えてよいか
テスト	テストの下書き	何をもって前と同じと見るか
移行の区切り	なし	区切りと検収の線

表の中で、人の側に残るのは、業務の決まりを知っていなければ決められない判断です。画面の裏の処理が、取引先の決まりごとを守るためのものなのか、昔の不具合をよけるために入れた回り道なのかは、コードの文面だけでは見分けがつきません。長く保守してきた経験が、ここで使われます。

一方で、下書きの段階はAIの支援を受ける余地があります。処理の説明やテストの案を下書きとして受け取り、業務の決まりに照らして直す。この流れなら、「AIが読めるから人は要らない」とはなりません。むしろ、下書きの良し悪しを見分ける人が必要になる、というのが筆者の見立てです。

では、こうした仕事をリモートで受けるとき、案件に入る前に何を決めておけばよいのでしょうか。

6. リモートで受ける前に決めておくこと

ソースと開発環境の受け渡し

この節は、資料ではなく筆者の見立てで書いています。古い業務アプリを遠隔で扱う案件では、画面を開く環境そのものが、最初の取り決めになります。

まず、ソースコードと開発環境をどのように受け取るかです。Delphiのような開発ツールは、利用権をどちらが用意するのかで、作業の始め方が変わります。委託元が用意するのか、受注する側が手配するのかを、参画前に決めておきたい点です。

次に、動作確認に使う端末とOSです。OSの更新に向けた確認を頼まれた場合、どの版のOSで、どの端末で確かめるのかが決まっていなければ、確認の結果が「前と同じか」を比べられません。

さらに、本番データを手元に持つかどうかも決めます。データベースとのやり取りを読み出す作業では、実際のデータに近いものが手元にあると確かめやすくなる反面、持ち出しの扱いは取引先の事情に左右されます。接続の方法と作業の記録の残し方もここで決めます。

成果物の形と区切り

決めておくことと、その例を並べています。左が決めること、右が参画前に取引先と合わせておきたい中身の例です。あくまで筆者の見立てで、この一覧がすべてを網羅しているわけではありません。案件によって、足す項目も外す項目も出てきます。

決めること	例
ソースコードと開発環境の受け渡し	どの形で受け取るか、開発ツールの利用権をどちらが用意するか
動作確認に使う端末とOS	確認に使う版と端末を、先に決めて共有する
本番データの扱い	手元に持つかどうか、持つ場合の範囲と期間
接続の方法と作業の記録	接続の手段、作業の履歴の残し方
成果物の形	調査報告、仕様書、修正のうち何を納めるか
区切りと検収	どこまでを一区切りとし、何をもって検収とするか

成果物の形は、受ける仕事の種類によって変わります。現状を調べて報告するのか、仕様書に書き起こすのか、コードを直すのかで、検収の線も変わります。区切りを先に決めておけば、「どこまでやれば完了か」を取引先と協議しながら進められます。

では、ここまでの取り決めを踏まえて、案件に入ってから何をどの順で進めればよいのでしょうか。

7. 案件に入る順番

動く環境の確認から引き継ぎまで

これまでの節で見てきた入口を、案件に入る順番に並べ直します。順番は筆者の見立てです。最初に確かめるのは、動く環境とソースコードの所在です。動かせない環境では、画面の裏を読み出す作業が始まりません。

図の作成：Remogu編集部。筆者の見立てを整理したもので、統計データではありません

仕様の書き起こしは、画面とコードから業務の決まりを読み出して文書に戻す作業です。動作確認と影響範囲の洗い出しは、その文書を手がかりに進めると、確かめ漏れが起きにくくなります。順番は前後することもありますが、仕様が見えていないまま移行の判断に入ることは避けたい流れです。

移行か維持かの判断そのものは、また別の仕事です。判断の材料をどう作るかは、COBOLの案件は移行と維持のどちらか？判断の材料をどう作るかで決まる進め方で整理しています。本記事の役割は、その手前にある、仕様を文書に戻す仕事までです。

画面の裏を読み出す経験を、案件で言い直す

冒頭の打ち合わせに戻ります。「Delphiで作り直すつもりはない」と言われても、経験が数えられないわけではありません。相手の困りごとは、画面のボタンの裏で何が起きているのかを説明できる人がいないことでした。

Delphiの経験は、画面の裏にある業務の決まりを読み出せる経験です。実績には、書いた画面の数ではなく、仕様書のないアプリの動きを説明できること、OSの更新に向けて確かめる場所を洗い出せることを書きます。経験の長い人ほど、この読み出す力が厚くなっています。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の経験に合う条件を確かめてみてください。説明できる人を探している取引先との話は、そこから始まります。

8. よくある質問

Delphiで新しく作る案件はありますか

この記事は件数を示せる資料を使っていないため、多いか少ないかは言えません。筆者の見立てでは、入口になりやすいのは新しく作る仕事よりも、保守・移行・調査の仕事です。打ち合わせでは、作る話か読む話かを最初に尋ねると、受ける仕事の形が見えます。

Delphi以外の言語も覚え直したほうがよいですか

覚え直しが前提とは限りません。筆者の見立てでは、移行先の言語のコードを読める程度から始めれば足ります。書き換えの判断に加わるには、元のアプリの決まりを知っていることと、移行先の書き方を読めることの両方が役に立つためです。

リモートで古い開発環境を使うときに確かめることは何ですか

筆者の見立てでは、開発ツールの利用権をどちらが用意するか、接続の方法、使う端末の扱いの3点です。参画前に決めておくと、作業が始まってから環境の用意で止まる事態を避けられます。個別の条件は案件によって異なるため、取引先と協議して決めます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」（2026年3月10日・2026年10月確認）
＊2 独立行政法人情報処理推進機構「Windows 10 のサポート終了に伴う注意喚起」（2026年6月26日・2026年10月確認）
＊3 ソフトウェアモダナイゼーション委員会「2025年度 ソフトウェアモダナイゼーション委員会報告書」（2026年3月24日・2026年10月確認）