Delphiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Delphiのシステム開発は、現行資産の棚卸しから始めて方式を選び、段階的に検証しながら進めます。

全体は6段階に分かれ、各段階で決めることを順に押さえると、業務を止めずに定着させられます。

▼全体ガイドの記事
・Delphiのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Delphiのシステム開発の全体像

Delphiは、Embarcadero Technologiesが提供するObject Pascal系の開発言語と統合開発環境です。Windows向けのVCLを中心に業務システムで利用されてきたほか、データベースや帳票、外部API、専用機器との連携にも対応しています。そのため、販売、在庫、受発注の業務をはじめ、物流や製造、医療、研究にも使われています。

VCLとFireMonkeyの使い分け

端末と業務の特性に合わせて、VCLとFireMonkey（FMX）を使い分けます。選ぶときは、公式情報を確認します（出典：エンバカデロ・テクノロジーズ「Delphi：製品エディション」、2026年確認）。

• VCL：Windowsのデスクトップ画面、入力検証、帳票、キーボード操作に対応し、大量入力の現場に適しています。
• FireMonkey（FMX）：Windows、macOS、iOS、Androidを単一コードベースで対象にできます。
• 製品構成：VCL、FMX、FireDAC、REST対応RAD Serverなどを組み合わせて使います。

ただし、既存のVCL画面をそのままスマートフォン画面へ変換できるとは限りません。そのため、端末ごとの操作性を早い段階で検証します。

クライアント・業務サービス・RDBの構成

典型的な構成は、VCLクライアント、業務APIまたはサービス層、RDBの3層です。RDBには、SQL Server、Oracle、PostgreSQLなどが使われます。

古いシステムでは、クライアントがデータベースへ直接接続し、業務ルールを画面側に持つ場合があります。短期の改修であれば、現行の構成を維持する方法もあります。

Web・モバイル連携や段階移行を見込む場合は、権限管理や監査ログも含めて、業務ロジックをサービス層へ切り出す計画が将来の変更に役立ちます。

Delphiのシステム開発の6段階の進め方

6段階は、要件整理、方式選定、設計・開発の順に始まり、テスト、稼働、定着へと続きます。この流れで進めると、技術の選択と業務の判断を切り分けて考えられます。

まず、全面刷新を前提にせず、現行資産の価値と将来の要件を並べて比べます。そのうえで、代表的な画面や連携をPoCで確かめてから次の段階へ進みます。

1. 要件整理：現行業務とDelphi資産の棚卸し

現行資産と業務の棚卸しでは、次の情報をまとめます。

• システム資産：画面、帳票、バッチ、外部連携、DB、ソース、ビルド手順
• 利用状況：利用者、拠点、業務の入力・判断・出力、Excelや紙の補助作業
• 開発環境：Delphiの版、第三者部品、購入済みライセンス、インストーラー

開発環境を再現できるかを見るには、購入済みのライセンスやコンポーネントのインストーラーが残っているかを確認します。実行ファイルとソースの版が一致するかも、あわせて照合します。

業務側には、誰がいつ何を入力し、何を判断して、どの帳票を出すかを聞き取ります。成果物には、構成図と機能・データ一覧をまとめます。課題一覧、用語集、優先順位表も作ります。

各機能には、「残す」「直す」「廃止する」「別システムへ移す」のどれにするかを書く判断欄を設けます。BDEや古いActiveX、独自DLL、DB直結、固定接続情報は、移行リスクとして管理します。

2. 選定：保守・段階移行・再構築の比較

まず業務継続性や利用端末などを踏まえ、Delphiを使うかどうかは決めずに、4つの進路を比べます。

• 保守・小改修：業務変更が少なく、Windows端末や専用機器との連携を維持したい場合
• 段階的モダナイズ：Delphi更新、64-bit化、部品交換、API分離を順に行い、業務を止めずにリスクを下げたい場合
• Delphiで新規開発：ネイティブの応答性や既存チームの知見を活かしたい場合
• 別技術へ再構築：ブラウザ利用、クラウドネイティブ、採用市場、外部公開APIを優先する場合

判断表では、業務継続性、コード再利用率、端末を比べます。オフライン要件、セキュリティ、採用性も記載します。さらに、5年分の保守費とデータ移行量も書き込みます。

標準化できる会計・勤怠・CRMなどはパッケージやSaaSを使い、在庫・製造・計算・機器連携など固有性の高い部分だけをDelphiまたは別技術で作る併用案もあります。

比べる範囲は目先の開発費にとどめず、5年間のライセンス、保守、教育、移行、障害対応まで広げます。

3. 設計・開発：業務ルールと技術境界の決定

画面を作る前に、業務ルールと権限を決めておきます。データの正しさや例外処理、連携方式も、設計の段階で決めます。基本設計書には、次の内容を記載します。

• 画面・帳票：画面遷移と帳票レイアウト
• 業務・データ：データ項目と状態遷移
• 制御・連携：権限表、外部連携、エラー時の扱い

再利用する計算や承認ルールは、Delphiの画面側だけに置かず、APIまたはサービス層へまとめます。これにより、将来Web画面やスマートデバイスを追加しやすくなります。

納品物には、ソースや設計書、DB定義を明記します。テスト仕様と結果、ビルド手順、部品・ライセンス一覧、運用手順も含めます。

認証・認可、最小権限、暗号化を、設計段階で決めます。監査ログや秘密情報の外部管理、部品の脆弱性確認も、同じ段階で決めます。

IPAが2026年3月に公開したガイドは、開発者と利用者に対策項目の把握を求めています（出典：IPA「製品開発者向け・製品利用者向けガイド」、2026年公開版）。

4. テスト：業務シナリオと移行データの検証

テストでは、画面が開くことだけでなく、次の対象まで確かめます。

• 単体：計算、入力制御、例外処理
• 結合：DB、帳票、API、CSV、メール、機器連携
• 総合：受注から出荷、請求、月次締め、訂正、取消、権限変更、障害復旧

Delphiを更新するときは、古い帳票や印刷機、Windowsの表示の差分を見落とさないよう、実機と本番に近いデータを用意します。

移行テストでは、件数が一致するかだけでなく、金額合計や在庫数量を照合します。日付、コード変換、過去履歴、重複、欠損も確かめます。

合格条件は、主要業務の処理時間が現行比で許容範囲内か、重要帳票の差分が承認済みかなどで定めます。たとえば、移行後の残高が一致することや、バックアップから復元できることも条件に含めます。

不具合一覧には、再現手順と影響範囲、優先度を書きます。修正期限と再テスト結果も記録します。

5. 稼働：切り替え方式と戻し方の決定

業務停止の許容度に応じて、次の切り替え方式から選びます。

• 一斉切り替え：対象をまとめて切り替える
• 段階切り替え：停止できない販売・在庫・受発注では拠点や部門ごとに稼働する
• 並行稼働：安心感がある一方、二重入力や差分確認が増えるため、期間と終了条件を限定する

切替計画には、責任者と開始・終了時刻、バックアップ、最終移行を書きます。権限、接続、利用者連絡、窓口、障害時の判断者も記します。そして、旧環境へ戻す条件を明記します。

切り替え前に復元の訓練を行い、誰が何を見て、何分以内に元へ戻すかを決めておきます。そうすれば、現場の混乱を抑えられます。

6. 定着：運用体制と改善サイクルの整備

運用を続けるには、次の作業ごとに担当者を決めます。

• 日常管理：マスタ更新、権限申請、バックアップ確認、障害受付、データ訂正
• 定期運用：月次締め、バージョンアップ、ログ確認、ユーザー追加、帳票設定
• 利用者支援：業務別手順書、問い合わせ先、障害の一次切り分け

導入の前後で、処理時間や差し戻し件数を比べます。

月次または四半期ごとに、未利用機能や入力ミス、問い合わせを確認します。処理時間、障害、追加要望も、あわせて確認します。

小改修は、バックログとして一覧にし、業務への影響と費用で優先順位を付けます。ソース、設計、テスト、ビルド、運用の情報は、一つにまとめて管理します。年に1回は別の担当者がビルドと復元を試し、退職時のベンダーロックインを抑えます。

Delphiのシステム開発にかかる費用相場と内訳

Delphiだけを対象にした公的な開発費の統計は確認できません。そこで、公開相場の記事と費用の変動要因を組み合わせた目安を示します。

実際の金額は、画面数や帳票数、既存コードの状態で変わります。さらに、データ移行や外部連携、テスト範囲、保守体制によっても変わります。

開発費、Delphiのライセンス費、インフラ費、移行・教育費を分けて確認します。

規模別の費用レンジと目安

Delphi案件の規模別の参考レンジは、次のとおりです。比べるときは、改修内容と連携範囲をそろえます。

• 小規模改修：帳票追加や不具合対応で50万〜300万円程度
• 部門向け新規開発：業務アプリや既存連携で300万〜1,000万円程度
• 中規模システム：販売・在庫・受発注で500万〜2,000万円程度
• 大規模基幹再構築：3,000万円から1億円超に広がる可能性

大規模案件には、複数拠点や複雑なデータ移行、IBM i連携、教育、並行稼働が含まれることがあります。金額は、個別の条件によって変わります。

参考にした比較ビズの記事では、小規模Webアプリは100万〜300万円とされています（出典：比較ビズ「delphi開発が得意なシステム会社22選」、2025年11月12日更新）。

同じ記事の目安では、中規模の業務システムが500万〜2,000万円、大規模の基幹システムが数千万円〜1億円以上です。

これらは一般的な見積もりの要素も踏まえた参考値です。Delphi固有の公式統計ではないため、予算の確定値とはせず、同じ要件書をもとに2〜3社から見積もりを取ります。

ライセンス費と保守費の切り分け

2026年4月1日適用の価格表によると、Delphi 13のIDE価格は次のとおりです（出典：エンバカデロ・テクノロジーズ「製品価格改定のお知らせ」および価格表）。

• Professional：保守1年付きで税別23万円。Enterpriseは56万円、Architectは86万円。
• 価格は開発者1人分で、設計、実装、テストの費用は含みません。移行、サーバー、教育、保守の費用も、この価格には含まれません。
• ランニング費用：Delphi保守更新、第三者製部品、OS・DBの更新
• 運用費：サーバー・クラウド、バックアップ、監視、脆弱性対応、問い合わせ、軽微改修

見積では、開発者数、利用エディション、保守期間、既存契約の更新条件を、それぞれ見積項目として分けます。

年間保守は、初期開発費の10〜20%程度をたたき台にする場合があります。ただし、対応・受付時間や障害の定義、含まれる改修量によって変わるため、率だけで比べるのは避けます。

費用を押し上げる要因：画面数より未整理の複雑さ

画面数が少なくても、部署別の締め処理や例外的な割引があると、工数は増えます。過去データとの互換性や外部EDI、古い部品、複雑な権限、帳票も、工数を押し上げる要因になります。

業務ルールを標準化し、不要な画面とデータを廃止したうえで、代表的な画面のPoCを行うと、見積もりの不確実性を下げられます。

見積の段階で「調査・分析」と「確定した開発」を分けると、ブラックボックスの調査費が開発費に紛れにくくなります。

Delphiのシステム開発で見積もりを取るポイント

良い見積もりは、合計金額だけでなく前提条件や作業範囲が分かるものです。成果物、除外事項、検収条件、保守範囲も読み取れます。

「対応できます」という回答を受けたら、実際のDelphiバージョンとコンポーネントを見せてもらいます。あわせて、どこまで調査した価格なのかを確かめます。

見積依頼書の機能・非機能・移行の分け方

見積依頼書では、要件を次の3領域に分けて記載します。

• 機能要件：画面、帳票、検索、登録、承認、CSV、API、バッチ、通知、権限、マスタ、履歴
• 非機能要件：同時利用者数、応答・稼働時間、バックアップ世代、復旧目標、監査ログ、暗号化、保存期間、端末、ネットワーク
• 移行要件：対象データ・期間、コード変換、クレンジング、照合方法、リハーサル回数、旧システムの参照期間

Delphiのバージョンや、VCLかFMXか、BDEや第三者部品の有無を確認します。DLL・ActiveXも、あわせて確認します。

DBの種類と版、ソースとビルド環境を確認します。帳票エンジンや外部機器、API・EDIも、あわせて確かめます。

認証、ログ、バックアップ、テストデータ、利用拠点も、見積条件に含めます。

これらが埋まっていないまま金額だけを比べると、後から追加費用が発生しやすくなります。

開発会社への質問：実装力より引き継ぎ可能性

引き継ぎを想定して、候補の会社には次の点を質問します。

• 技術対応：Delphi 7、XE、現行版の範囲とBDE・古い部品の置き換え方
• 担当体制：実案件の担当者と自社エンジニアの設計レビュー参加
• 引き継ぎ：ソース、設計書、テスト結果、ビルド環境の納品と担当交代時の方法
• 保守・検証：PoCの可否、保守終了や緊急障害の連絡条件

得意な領域は会社ごとに分かれています。たとえば、古いDelphiの読解や保守、SQL ServerやOracleの業務アプリ、公共・計算・GISなどです。

また、IBM i・RPGとDelphi/400の連携や、C#・Web・クラウドへの段階移行に強い会社もあります。

公開されている実績に加えて、自社のバージョンや業種、移行方針に近い担当者を確認します。

PoCと契約条件による不確実性の抑制

古いソースや部品の状態が不明な場合は、本開発の前に、代表画面、帳票、DB接続、認証、外部連携、ビルドを対象としたPoCを依頼します。

PoCでは、次の内容を確かめます。

• 成果物：動くサンプル、技術課題、交換部品、性能結果、残作業、概算工数、移行可否
• 発注条件：価格と期間、本開発へ進まない場合の扱い

契約では、ソースや設計書の権利、第三者部品のライセンスを確認します。さらに、再委託、データ、秘密保持、脆弱性対応を確かめます。障害時のSLA、検収、仕様変更、担当交代時の引き継ぎも、同じ契約で確認します。

開発会社の環境でしかビルドできない状態を避けるため、環境構築の手順と必要なライセンスを納品範囲に含めます。

Delphiのシステム開発でよくある質問

Delphiのシステムは、技術が新しいか古いかだけでなく、業務停止の許容度や既存データ、利用端末、保守人材を合わせて判断します。発注前によく寄せられる4つの質問に答えます。

Delphiは2026年時点でも業務システムに使えますか？

使えます。ただし、言語の名前だけで安全性や将来性を判断せず、バージョンやOS対応、部品を確認します。認証、DB接続、テスト資産、保守担当者も確かめます。

たとえば、VCLでWindows業務を保ちながら、APIやサービス層を追加し、Web・モバイルと連携する方法もあります。

古いDelphi 7をすぐに別の言語へ移行すべきですか？

すぐに全面移行する必要はありません。まず現行コードと業務ルール、データを棚卸しし、部品やOS依存、担当者も確認してから、複数の進路を比べます。

候補は、保守の継続、現行Delphiの更新、段階的なAPI分離、.NET・Webへの再構築です。業務ルールの再発見やデータ移行に失敗すると、リスクが高まります。そのため、代表画面のPoCと段階移行を組み合わせます。

Delphiのシステム開発費用はどのくらいですか？

既存Delphiの小改修は50万〜300万円、部門向け新規開発は300万〜1,000万円が参考レンジです。

中規模業務システムは500万〜2,000万円、大規模基幹再構築は3,000万円〜1億円超が目安です。

これは公開相場と案件条件をもとにした目安で、Delphi専用の公的統計ではありません。比べるときは、データ移行や帳票、連携、テストを含めて、同じ条件でそろえます。並行稼働、教育、保守も、この条件に入れます。

Delphiに対応できる開発会社はどのように探しますか？

対応の表示だけでなく、自社のバージョンやVCL・FMX、DBに近い実績を確認します。帳票、BDEや第三者部品、移行先の実績も確かめます。

実案件の担当者、ソースとビルド環境の引き渡し、テストとデータ移行の担当を質問します。保守SLAや引き継ぎ方法も、あわせて質問します。可能であれば、PoCの後に本契約へ進みます。

Delphiのシステム開発の進め方まとめ

まず、現行資産と業務の依存関係を一覧にし、技術の好みだけで判断しないようにします。6段階に分けて各段階に成果物と合格条件を置くと、担当者の経験だけに頼らず判断できます。

残すか移行するかを決める4つの観点

判断の観点は、業務の独自性、資産の再利用価値、将来の端末や連携、保守体制の4つです。Windowsネイティブや専用機器が重要な場合は、Delphiの保守や段階的な更新を検討します。

IBM iやRPGの資産が重要な場合は、Delphi/400を含むモダナイズを検討します。ブラウザやクラウド、採用性を優先するなら、Webや.NETへの再構築が候補です。標準化できる業務には、パッケージの併用もあります。

どの進路でも、認証、権限、監査ログは、設計段階から押さえておく必要があります。進路を選んだあとも、バックアップ、脆弱性対応、ソースとビルド環境の引き渡しを確かめておきます。

• バックアップ：障害時に元へ戻せるかどうか
• 脆弱性対応：使っている部品の脆弱性を確認し、対応を決める
• ソースとビルド環境の引き渡し：開発会社の環境に頼らずにビルドできる状態にする

最初の一歩：棚卸しシートとPoCの準備

Delphiの版やソース、部品、DBを一覧にし、画面や帳票、外部連携、利用者、障害履歴も書き出します。そのうえで、残す機能と変える機能を分けます。

代表画面、重要帳票、DB接続、認証、外部連携のPoCで、費用や期間、移行リスクを具体的につかみます。業務担当、情報システム部門、開発会社が同じ資料を見ると、過去のノウハウを次の運用へつなげやすくなります。

▼全体ガイドの記事
・Delphiのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。