Delphiのシステム開発の発注/外注/依頼/委託方法について

Delphiのシステムを発注するときは、現行資産の棚卸し、方式と契約の比較、調査・PoC、本開発の順に進めます。この順で進めると、業務を止めずにリスクを抑えやすくなります。

その詳しい内容は、発注形態、RFPと要件、費用相場、委託先の選び方の順に見ていきます。

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

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

Delphiのシステムを発注・外注する前の全体像

Delphiのシステム開発では、「何を作るか」と同時に「何を残し、何を変えるか」を決めておく必要があります。ソースコードやDB、帳票、外部連携、担当者の知識の状態によって、同じ機能でも発注方法と費用が大きく変わります。

発注前の既存資産の棚卸し

発注先と現行の状態を共有するため、既存資産を次の観点で一覧にします。

• 開発環境：Delphiのバージョン、VCLかFireMonkeyか、32ビットか64ビットか
• 依存資産：第三者コンポーネント、BDEなどの方式、データベースの種類、帳票ツール
• 連携先：バッチ、外部API、EDI、専用機器との接続

ソースコードがあっても、開発環境や部品のライセンス、ビルド手順、テストデータがなければ、すぐに改修へ入れるとは限りません。画面一覧に加えて、利用者、拠点、ピーク時間、手作業、Excelや紙との二重管理、障害時の復旧方法も整理します。

長期運用のDelphiでは、設計書にない業務ルールが画面イベントや担当者の経験に埋め込まれていることも珍しくありません。棚卸しの成果物は、発注先へ渡せる現行資産一覧と、機能を「残す・改善する・廃止する」に分けた一覧です。

残す・更新する・作り直すの判断

現場端末や既存ロジックを生かすか、利用形態に合わせて別の方式を選ぶかを整理します。

• 現行保守・更新：Windows端末、専用プリンター・バーコードリーダー、オフライン、高速大量入力と既存ロジックが重要な場合
• 別技術への再構築：ブラウザ、スマートフォン、クラウド運用、採用性、API連携を最優先する場合
• パッケージ・SaaS併用：会計や勤怠など標準化しやすい領域は製品を使い、Delphiを固有業務に限定

古い部品を置き換え、DBへの直接接続をAPIやサービス層へ段階的に分ければ、画面を一度に廃棄せず、セキュリティと連携性を高められます。

再構築先には、.NET、Java、Web技術などが候補になります。発注先からは、現行保守、段階的なモダナイズ、別技術への再構築の3案を、同じ要件で比較した提案としてもらいます。

Delphiのシステムの発注形態

発注形態は、業務側の関与度、要件の確定度、既存資産の不確実性、責任範囲で選びます。人手の提供、成果物の完成、現行調査からの伴走のどれを頼むのかが曖昧だと、見積もりと責任の境界が崩れやすくなります。

請負型の完成物と責任範囲

請負型は、成果物と責任範囲を決めてから発注する形で、新規開発や対象範囲が明確な改修に適しています。

• 成果物：要件定義書、設計書、プログラム、テスト結果、移行手順
• 向く案件：画面数、帳票数、連携先、OS、性能、検収条件が固まった開発
• 発注側の役割：業務判断と受け入れ試験を担うことを契約書に明記

古いDelphiの解析結果が契約前に分からないとき、全工程を固定価格にすると、部品交換やソース解析が追加変更になりがちです。そのため、現行調査と基本構想を先に請負で発注し、その結果から本開発の見積もりを更新する二段階方式が安全です。

準委任型の調査・保守・伴走

準委任型は、一定期間の作業や専門知識の提供に対して報酬を支払う形で、作業量を確定しにくい業務に向いています。

• 調査・分析：ソース読解、環境再現、障害調査、更新影響の分析
• 要件定義支援：作業量を契約時点で決めにくい上流工程
• 技術顧問：担当者退職や社内にDelphi経験者がいない場合

時間を使ったことを成果とみなさないよう、月次報告には作業対象、判明したリスク、設計資料、次月計画を含めてもらいます。

常駐かリモートか、担当者のスキル、月の稼働時間を確認します。緊急対応の取り決めや、成果物の著作権と利用権も確認します。最後に、終了時の引き継ぎも決めておきます。

保守では、問い合わせや障害への対応を、軽微改修、制度対応、大規模改修と分けて扱うと、追加費用を管理しやすくなります。

二段階発注による不確実性の抑制

第一段階では現行調査、業務整理、PoCを行い、第二段階で本開発または移行を発注します。PoCでは、代表画面・帳票とDB接続を小さく検証します。さらに、認証やログ、外部連携、性能も確かめます。

検証では、現行コードを現行版でビルドできるか、古い部品を代替できるか、業務ルールを再現できるかを確かめます。これにより、実装後に見積もりが大きく増えるのを抑えられます。

第一段階の終了条件には、資産一覧と重要画面の依存関係を含めます。加えて、移行方式、代表データでの性能、主要リスクと対策も設定します。Delphiを残さない場合でも、判断材料が残るため、委託先の提案に流されにくくなります。

RFPと要件整理で伝える内容

RFPは、開発会社に提案と見積もりを依頼する資料です。目的、対象範囲、現行環境を、各社が同じ粒度で読める形で渡します。さらに、業務上の制約や希望時期を書き添え、予算の考え方と提案内容も示します。

「Delphiで販売管理を作りたい」とだけ伝えると、各社の前提がばらばらになります。既存システムの問題点は隠さずに書き、不明点は未確定事項として明記しておくと、後の追加請求を減らせます。

RFPに記載する基本項目

RFPには、発注背景と目的、対象業務、利用者と拠点を記載します。あわせて、現行構成や対象の画面・帳票・バッチ・外部連携を示し、改善課題、必須機能、将来対応、希望稼働時期も書きます。

既存Delphiについては、バージョン、VCLまたはFMX、ソースコードの有無を示します。さらに、開発環境や部品、DBも書き添えます。ソースと設計書の保管場所、保守会社、障害履歴も示します。

提案条件には、現行保守・段階更新・再構築の比較と、調査範囲を含めます。期間と前提、標準機能と追加開発の区分、成果物と検収方法も入れます。見積もりは、一式ではなく工程別に依頼します。

• 工程：調査、要件定義、設計、開発、テスト
• 付帯費用：移行、教育、インフラ、ライセンス、保守

非機能要件とセキュリティ

機能以外の品質と安全性も、次のように要件へ含めます。

• 性能・稼働：同時利用者数、応答時間、稼働時間
• 継続性：バックアップ頻度、復旧目標、保存期間
• セキュリティ：認証、権限、監査ログ、暗号化、個人情報

「快適に動く」のような曖昧な書き方は避け、通常操作の大半を何秒以内に表示するか、障害から何時間以内に復旧するかを決めます。DBへの直結や接続情報のハードコードがある場合は、改修対象とリスクをRFPで開示します。

IPAは2026年3月に製品利用者向けガイドを公開しました。そのガイドでは、委託開発を含むシステム・サービスの委託先に求めるセキュリティ対策を確認できます（出典: IPA「製品開発者向け・製品利用者向けガイド」、2026年）。

そのうえで、脆弱性情報と依存部品、秘密情報の扱いを、提案書と契約書に明記するよう開発会社に求めます。さらに、ビルド環境、ログ保管、インシデント報告期限も対象にします。

納品物と引き継ぎ条件

納品物は、設計・実装資料とテスト・運用資料に分けて指定します。

• 設計・実装：要件定義書、画面・帳票一覧、設計書、DB定義、API仕様、ソースコード
• 検証・運用：テスト仕様と結果、移行計画、操作・運用・復旧・ビルド手順

Delphiでは、第三者部品の名称・バージョン・ライセンスも引き渡しの対象です。インストーラーや証明書、環境変数、設定ファイルの管理方法も、同じく含めます。

将来の発注先変更に備えて、ソースと設計書の利用権、リポジトリ管理者、環境再現方法を決めておきます。あわせて、問い合わせ履歴、担当者退職時の引き継ぎ、契約終了時のデータ返却も決めます。

自社で保守できる体制や、再委託先とその管理方法も確認します。自社または第三者が再ビルドしてテストできることを検収条件にしておくと、ベンダーロックインを抑えられます。

Delphiのシステムの契約形態と費用相場

Delphi専用の公的な開発費統計は見当たらないため、相場は予算取りの目安です。

金額は人件費、工数、ライセンス、インフラで決まります。要件定義の精度によっては、費用が倍以上に動く場合もあります（出典: イー・ジーシステム「システム開発の費用相場と見積書の読み方」、2026年）。

既存Delphiの解析と移行では、画面数だけでなく、古い部品とデータ品質も工数を左右します。

規模別の費用と期間の目安

規模別の初期検討レンジは、機能範囲と前提をそろえてから比べます。

• 小改修：帳票追加・項目変更・不具合対応・限定OS対応。ソースと環境がある前提で50万〜300万円、2週間〜3か月程度
• 部門アプリ：10〜40画面で300万〜1,000万円、3〜8か月程度
• 中規模業務システム：販売・在庫・受発注など。500万〜2,000万円、4〜12か月程度の場合
• 移行・再構築：旧版更新や64ビット化などを含む場合、500万〜3,000万円程度

部門向けアプリは、RDB、権限、CSVやAPI連携、帳票を含む想定です。いずれも調査範囲と前提を伴う参考値です。

Delphi 7などからの更新や64ビット化を含む場合は、移行・再構築の幅まで広がる可能性があります。部品交換、API分離、回帰テストについても、同じように範囲を確認します。

複数拠点や履歴移行、並行稼働を含む基幹再構築は、教育やIBM i連携も含めて、数千万円から1億円超まで幅があります。PoCと段階発注によって、不確実性を分けて扱います。

これらは、Delphi開発関連記事と業務システム一般の2026年相場を組み合わせた編集上の目安です。特定案件の価格を保証するものではありません。

ライセンス・移行・保守費の別枠

Delphi 13の2026年4月1日適用価格は、開発作業・移行・運用保守の費用と分けて確認します。

• Professional：保守1年付き、税別23万円
• Enterprise：保守1年付き、税別56万円
• Architect：保守1年付き、税別86万円
• 別途見積もり：開発会社の作業費、移行、インフラ、運用保守
• 追加確認：必要なエディション・人数、RAD ServerやDBの追加ライセンス

各価格は開発者1人分のIDEと保守の価格です。要件定義、設計、開発、テストは含まれず、移行、インフラ、運用保守も含みません（出典: エンバカデロ・テクノロジーズ「エンバカデロ製品価格表」、2026年）。

ランニングコストには、DelphiやDBの保守更新、クラウドやサーバーが含まれます。さらに、監視、バックアップ、脆弱性対応、問い合わせや障害対応、軽微改修も入ります。

保守費は初期開発費の10〜20％程度を目安とする考え方がありますが、対応時間や対象範囲、改修量によって変わります。そのため、年額だけで判断しないようにします。

旧環境の並行稼働や教育、データクレンジング、切り戻し訓練も、別項目で計上してもらいます。

契約書の変更・検収・知財の扱い

契約書では、範囲や責任、変更と検収に関わる条件を確認します。

• 契約の前提：対象範囲、前提条件、成果物、納期、再委託、秘密保持、個人情報
• 変更・検収：仕様変更手続き、検収期間、不具合対応、遅延連絡
• 権利・責任：知財、ソース利用権、損害賠償の範囲

請負では、検収基準を明確にしてから納期を決めます。準委任では、作業報告、体制、時間外対応、成果物の著作権を定めます。

追加要望は、口頭のまま着手せず、変更内容と画面・データ・テストへの影響を整理します。そのうえで、追加費用と納期への影響も含めて、双方で承認します。

検収では、画面表示だけでなく、権限や帳票、性能を確認します。加えて、データ件数、障害復旧、操作手順、再ビルドも見ておきます。後から説明できるよう、契約の透明性を優先します。

Delphiの委託先選定と見積比較のポイント

Delphi対応会社でも、得意分野は異なります。現行保守、旧版移行、新規業務アプリ、Delphi/400とIBM iの連携、.NETやWebへの再構築では、必要な経験が変わります。

今回に近い資産・業務・移行の経験は、担当者の説明と成果物サンプルで確かめます。会社名や言語名で選ぶ前に、ここを見ておきます。

委託先への質問による実力の確認

候補会社には、Delphiの経験と今回の資産に近い技術対応を質問します。

• 旧版・部品：Delphi 7やXEの読解、BDEや第三者部品の扱い
• 画面・基盤：VCLとFireMonkeyの使い分け、64ビット化
• データ移行：SQL ServerやOracleなどのDB移行経験
• 体制・実績：提案後の担当継続、調査・テスト・移行の担当と成果物

Delphi 13.1では、Windows on Armのネイティブコンパイラや最新モバイル環境への対応が案内されています。同じリリースには、VCLとFireMonkeyの品質改善も含まれます（出典: Embarcadero「RAD Studio 13.1 Florence 提供開始のお知らせ」、2026年）。

新機能の話だけでなく、現行資産を安全に更新するための検証方法も聞いておきます。あわせて、業務担当者と協議する頻度も確認します。

設計書やテスト仕様、移行リハーサル、保守引き継ぎについて、実例を説明できるかも確認します。

IBM iやRPG資産がある場合は、Delphi/400、RPG、5250画面の経験を、別々に確認します。

公開事例の進め方と体制

事例を見るときは、金額だけでなく、対象範囲や期間、既存ロジックの再利用を確かめます。さらに、利用者側の体制や移行後の保守体制も見ます。

ミガロ．が公開する日綜産業の事例では、出荷・返却・レンタルの主要基幹システムを開発しました。Delphi/400を使い、RPGのロジックを活かしてGUI化を進めました。

この事例では、開発期間、GUI移行の割合、利用企業の関わり方を確認できます。

• 開発期間：主要基幹システムを2017年から段階開発し、2023年に終了
• 移行実績：日々使うアプリの約7割以上を新しいGUI画面へ移行
• 体制：RPGロジックを活用し、利用企業も開発と保守人材育成に参加

移行割合の出典は、ミガロ．「日綜産業株式会社 RPGのビジネスロジックを流用しユーザー・インターフェースを刷新」（2024年公開）です。費用は公開されていないため推測できません。

既存ロジックを活かし、利用頻度の高い領域から進める方法は、Delphi外注時の検討材料になります。

見積書の比較条件と工程別内訳

各社には同じRFPと現行資産一覧を渡し、前提条件をそろえます。工程と付帯費用を分けて比べると、総額の差を確認できます。

• 開発工程：要件定義、基本設計、詳細設計、開発・単体テスト、結合・総合テスト
• 付帯項目：データ移行、教育、インフラ、ライセンス、保守

2026年の見積解説でも、開発一式ではなく、工程・人月・付帯費用に分けて、総額より内訳の透明性を見ることが推奨されています（出典: イー・ジーシステム、2026年）。

極端に安い見積もりは、要件の解釈が狭い、テストが薄い、調査を省略しているなどの可能性があります。さらに、移行が別料金だったり、保守が含まれていなかったりすることもあります。一方で、高額な見積もりでも、工数と作業内容が分からなければ比較できません。

各社には、含むものと含まないもの、画面・帳票数を表にしてもらいます。加えて、テストデータ、移行対象、受け入れ条件、追加変更単価、保守の応答時間も、同じ表に書いてもらいます。

提案は価格だけでなく、技術適合性、業務理解、移行リスクで評価します。担当経験や体制、セキュリティ、納品物、保守継続性も、評価の対象にします。

最終候補には、代表画面か帳票の技術検証を依頼し、見積もりの前提と成果物を照合します。必要に応じて評価表に配点し、業務部門と情報システム部門が同じ基準で比べます。

よくある質問（FAQ）

Delphiの発注前に多い質問を並べます。委託先へ相談する前に社内で整理しておくと、調査範囲と見積もりの前提を合わせやすくなります。

古いDelphiでも外注できますか？

外注はできますが、バージョンや部品、DBを確認してから依頼します。ソースコードやビルド環境、テスト資産もあわせて確認します。Delphi 7やXEでも、現行環境で再現できるとは限りません。

最初に現行調査や代表画面のPoCを発注し、改修の可能性と移行方針を確認しておくと安全です。

Delphiのシステムを外注する費用はいくらですか？

小改修は50万〜300万円程度です。部門向けの新規業務アプリは300万〜1,000万円程度で、中規模の販売・在庫・受発注システムは500万〜2,000万円程度が、初期検討の幅です。

Delphiのバージョンアップやデータ移行を含むと、数千万円以上になる場合もあります。複数拠点や外部連携、並行稼働、教育を含む場合も、その範囲に応じて費用が変わります。

Delphi専用の公的な統計はないため、費用はRFPと現行調査に基づく個別見積もりで確定させます。

Delphiに強い開発会社はどう選びますか？

対応実績だけでなく、業務領域や旧版解析の経験を確認します。さらに、DB・帳票・外部機器連携、移行、保守、引き継ぎの経験も見ておきます。

たとえば、ミガロ．のDelphi/400による日綜産業の事例は、既存ロジックを活用し、利用者側も保守に参加した公開事例です。

提案担当者が開発や保守にも関わるか、成果物と相見積もりの前提を説明できるかを確かめて選びます。

まとめ

発注前に決めること

現行資産を棚卸ししたうえで、現行保守、段階的なモダナイズ、別技術への再構築、パッケージ併用を比べます。

要件と成果物が固まった部分は請負、調査や保守のように作業量が読みにくい部分は準委任、判断に必要な調査は二段階発注と、契約形態を使い分けます。

見積比較の確認項目

比較の前提となるRFP項目と委託先の確認軸をそろえます。

• RFP：Delphi環境、資産、非機能要件、セキュリティ、移行、納品物
• 委託先：資産解析、業務理解、移行・テスト、引き継ぎ、保守継続性

調査から保守までの内訳と前提をそろえて比較します。Delphiを残すかどうかは、技術の新旧だけでなく、業務資産や利用形態を含めて考えます。加えて、セキュリティ、人材、移行リスク、将来の運用費も合わせて見ます。

委託先は、提案担当者が開発・保守にも関わるか、実績と成果物を説明できるかも確かめます。

まず代表画面と代表データで現行調査や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を創業。