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

Apache Derbyの発注は、現行調査、継続か移行かの判断、契約、検収の順に進めると、保守責任や移行費用を把握できます。Derbyは2025年10月に退役しているため、保守責任と移行費用は発注前に確かめておく必要があります。

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

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

Apache Derbyのシステム発注・外注で最初に決める全体像

発注では、作るシステムの中身だけでなく、Derbyを今後も使うかどうかを決めます。新規開発と既存保守では、適切な発注先や契約が異なります。加えて、将来の保守責任や移行費用も含めて発注先を選びます。

新規開発と既存Derby資産の保守の区分

新規開発と既存保守では、確認する点と発注の方針が異なります。

• 新規案件：DBの保守が続くか、Java更新に追随しているか、障害時の相談窓口があるかを見ます。
• Derbyが必須でない案件：PostgreSQL、MySQL、商用DB、クラウドのマネージドDBを第一候補にし、Derbyの採用は例外として扱います。
• 既存システム：現行調査、短期延命、段階移行、全面再構築の4案を比べ、初期費用、停止時間、保守期間、移行期限を見積もります。
• 委託先：Derbyの知識に加え、Java/JDBCの調査と代替DB移行を説明できる会社を選びます。

Apache公式Downloadsページによると、Derbyは2025年10月10日に退役しました。開発、バグ修正、新しいリリースも終了しています。さらに、読み取り専用となり、配布物は現状有姿で提供されます（出典: Apache Derby Downloads、2025年）。

EmbeddedとNetwork Serverの外注対象の確認

構成によって利用方法と運用上の確認事項が異なるため、対象とする方式を発注先に伝えます。

• Embedded：DBエンジンと業務アプリを同じJVMで動かし、単一製品のローカルデータストアや検証に使う方式です。
• Network Server：サーバー側JVMでDerbyを起動し、別のJVMやクライアントがネットワーク経由で接続します。

Embeddedは構成が小さい一方で、同じDBファイルを複数のJVMやホストから直接共有する方式ではありません。発注時は、利用者数、同時接続数、JVM数、障害時の復旧方法を伝えます。

複数のユーザーが使う業務システムでは、Network Serverが候補になります。その場合は、認証とTLSによる暗号化を別途設計します。

ファイアウォールの設定とSQL権限の整理、監視、バックアップも、設計の対象です。公式セキュリティガイドは、初期状態の平文通信、強すぎる権限、無制限に増える可能性がある容量を注意点に挙げています（出典: Apache Derby Security Guide、10.17）。これらも見積もりの対象に含めます。

Apache Derbyのシステムで選べる発注形態

外注には、開発全体を最初から一社に任せる方法のほかに、段階的に任せる方法もあります。技術調査の不確実性が高いときは、初回契約を小さく切り出し、結果を見て本開発や移行を発注します。

どの方法を選ぶにしても、自社に残す業務知識、技術知識、運用責任と、外部へ任せる範囲を先に決めます。

要件が固まっている案件での一括請負

要件や画面が固まり、外部連携、移行対象、検収条件も決まっていれば、要件定義からリリースまでを一括請負にできます。窓口を一本にまとめられるため、納期や成果物を管理しやすい方法です。

現行仕様が分からないまま一括で発注すると、想定外のSQL差分やデータ不整合は追加費用の原因になります。そこで、現行調査と要件定義を準委任で先行させ、成果物を確認してから開発を請負にする二段階方式も検討します。

契約の管理は増えますが、調査の前に数百万円から数千万円規模の本契約を結ぶリスクを抑えられます。

PoCや調査の先行外注

Derbyのバージョン、JDK、JDBCドライバーが不明なら、2〜6週間程度の技術検証を先行させます。アプリケーションサーバー、OS、データ量が不明な場合も、この技術検証の対象です。

この検証では、移行を決める前に動作と移行の可否を確かめます。

1. EmbeddedとNetwork Serverを起動し、Java 21環境との互換性を見ます。
2. 主要SQLを実行し、データをエクスポートして代替DBへ投入します。
3. バックアップ復元と代表的な業務処理の性能を測定します。

成果物には、実行できなかったSQL、型変換で失われる可能性があるデータ、必要なアプリ改修を含めます。さらに、性能の測定条件と残るリスクも書きます。「動いた」という報告だけでは不十分です。

PoCの結果、移行しない結論になることもあります。その場合でも、継続利用の条件と移行開始のトリガーが明確であれば、発注者にとって価値があります。

自社の業務知識と外部の技術力の組み合わせ

業務知識と外部の技術力を分担するため、担当範囲と責任は文書に残しておきます。

• 業務部門：現場ルールを説明し、Derbyの運用手順やデータの意味を共有します。
• 外注先：Java・JDBCの技術面とデータ移行を担当し、クラウドやテストも受け持ちます。
• 担当の分け方：設計、実装、移行、バックアップ、監視の担当を決めます。さらに、障害一次対応、リリース承認、問い合わせ窓口の担当も決めます。

業務知識を社内に残しておけば、移行後のベンダーロックインを抑えられます。分担は口頭で済ませず、要件定義書やRACI表などに書いて確かめます。

RFPと要件整理でApache Derbyの外注範囲を明確にする方法

RFPは会社選びの依頼書であり、発注後の認識違いを減らす要件整理の道具でもあります。そこで、現行資産と業務上の制約を含め、セキュリティや運用、将来の保守までを一つの文書にまとめます。

現行環境と移行対象の洗い出し

見積もりの前提をそろえるため、現行環境と移行対象を次の観点で洗い出します。

• 実行環境：Derby・JDKのバージョン、JDBCドライバー、接続方式、DBの保存場所、起動停止手順を一覧にします。
• DB資産：テーブル、主キー、外部キー、インデックス、ビュー、トリガー、ストアド処理、LOB、日付・数値型、文字コード、予約語。
• データ：現在量、月次増加量、保存期間、削除ルール、バックアップ容量。
• 情報管理：個人情報・機密情報、サンプルの匿名化、開発環境への持ち出し制限、アクセスログ。

`ij`、`dblook`、`sysinfo`などの付属ツールで調べた場合は、実行結果と調査日も納品物に含めます。また、調査対象を指定しておけば、各社が異なる前提で見積もってしまう事態を防げます。

機能要件と非機能要件の記載の分け方

機能と運用品質を分けて、それぞれの要件をRFPに記載します。

• 機能要件：利用者、権限、画面、帳票、バッチ、外部API、CSV入出力、検索、登録・更新のルール。
• 非機能要件：接続数、応答時間、処理件数、稼働時間、復旧時間・時点、バックアップ世代、監視、ログ保存期間、暗号化、脆弱性対応、データ保持。

移行案件では、新DBへ移すデータと参照用に残すデータを分けて決めます。移行後に旧環境を保持する期間も、あわせて決めておきます。業務担当者が確認できる受入テストのシナリオを用意すると、完成像を発注先と共有できます。

Derbyは構成によって責任範囲が変わります。そのため、「高可用性」や「安全に運用」といった言い方では、要件として不足です。たとえば、障害から何時間以内に復旧するか、最大何分のデータ損失を許容するかを数値で示します。

RFPに入れる成果物と引き継ぎ条件

納品物と引き継ぎ可能な状態は、開発費と合わせて確認します。

• 設計・開発資料：調査報告、要件定義、基本・詳細設計、DDL、ソースコード、ビルド手順。
• 移行・運用資料：移行手順、テスト仕様と結果、運用・監視・障害対応の手順。
• 権利・アクセス：著作権・利用権、第三者OSSの表示、リポジトリ権限、アカウント返却、保守終了後の問い合わせ方法。

Derbyを継続する場合は、起動停止、バックアップ復元、容量監視、JDK更新時の検証手順が必要です。これらが欠けると、担当者の退職後に運用が止まる可能性があります。

納品時に動くだけでなく、別の会社へ保守を移せる状態を納品条件にしておくと、ベンダーロックインの回避につながります。

Apache Derbyのシステム外注で選ぶ契約形態と検収方法

範囲と成果物が明確な工程は請負、調査や要件変更が多い工程は準委任として組み合わせます。そのうえで、完了条件、仕様変更の費用、障害時の責任を文書に残すことが大切です。

調査・要件定義の準委任と、確定した開発の請負

工程の不確実性と成果物の確定度に合わせて、契約の形を選びます。

1. 調査・PoC：作業量が読みにくいため準委任とし、稼働、調査項目、報告、成果物、上限金額を決めます。
2. 調査の成果：報告書、課題一覧、移行候補の比較など、次の判断に使う成果物。
3. 範囲確定後の開発：請負にして、工程ごとの成果物と検収日を設定する。

既存データの欠損や未知のSQLに備えて、前提条件と除外範囲を契約書や別紙に残します。変更管理の単価と、追加見積もりの承認手続きも、同じ書類に書いておきます。

画面、業務、移行を含めた検収条件

検収条件は、画面表示に加えて、データと業務運用も含めて定めます。

• 移行データ：移行前後の件数・合計値、文字化け、日付・タイムゾーン、LOBの読み書きを照合します。
• 業務・運用：権限別操作、主要バッチ、バックアップ復元、障害時の再実行。
• 本番切替：リハーサル時間、停止可能時間、差分取込み、切戻しの基準と手順。

業務担当者が受入テストを行い、委託先が環境とデータ準備、結果の記録を支援する形にすると、現場で使えるかを判断できます。

保守契約の対応範囲と終了条件

退役済みのDerbyでは、新機能や修正リリースを期待できません。そのため、保守の範囲と費用の見通しを、次の観点で確認します。

• 対応範囲：受付時間、障害一次切り分け、JDK・OS更新検証、脆弱性調査、復元支援、移行計画、終了条件。
• 中期費用：年単位の金額でも3〜5年のTCOを作り、更新や障害調査のスポット費を含めて比べます。
• 契約期間：短期廃止予定なら、延命と移行準備を分けた契約も検討します。

Derby専用の現行の商用サポートを掲げる会社は限られます。1年目の保守費が安くても、Java更新や障害調査のスポット費が高ければ、早期の移行が合理的な場合があります。

Apache Derbyのシステム開発・移行を外注する費用相場

Derby単体の開発費や保守費には、公的な統一価格表がありません。次に示すのは、リサーチノートにある2026年の類似Java業務システムの相場、工程、移行難易度から推定したレンジです。

費用は、画面数、外部連携、データ量などで変わります。停止可能時間、セキュリティ、冗長化、利用者数も変わる要因です。そのため、このレンジは予算取りに使い、最終判断は個別見積もりで行います。

作業規模別の費用レンジ

Derbyの外注費は、PoCから全面刷新までの作業規模や、DB移行の有無で幅が変わります。

• 技術検証・小規模PoC：50万〜150万円程度。
• 小規模な社内業務システム：150万〜500万円程度。
• 複数業務・外部連携を含む部門向け：500万〜1,500万円程度。
• 既存DerbyのDB移行：300万〜1,200万円程度。
• 基幹連携などを含む刷新：1,000万〜3,000万円超となる可能性。

技術検証には、Java/JDBC接続、EmbeddedとNetwork Serverの比較、簡易性能試験、移行可能性の確認が含まれます。ただし、各レンジはDerby公式の価格ではありません。

移行費には、現行調査、SQL/JDBC差分の修正、スキーマ変換を含みます。さらに、データ移行、並行稼働、切替リハーサルも対象です。刷新では、基幹連携や高可用性、監査ログ、複数拠点が費用に関わります。

2026年の業務システム開発公開情報では、小規模スクラッチ100万〜300万円、中規模300万〜800万円、中〜大規模800万〜数千万円とされています（出典: 業務システム開発の費用相場、2026年）。一方で、Derby案件では、退役後の調査と移行準備を別項目で確認します。

ランニング費用とライセンス費の内訳

ライセンス費と運用費を分けて、必要な費目を見積もります。

• 運用環境：クラウドVM、ストレージ、バックアップ、監視、ログ、ネットワーク、障害対応、更新検証、セキュリティ評価、移行準備。
• クラウド運用：小規模は月額5万〜30万円程度、24時間監視や冗長化を含む場合は月額30万〜100万円以上のことがあります。
• 年間保守の仮置き：初期開発費の10〜20％程度とする一般論があります。

Derbyは、Apache License 2.0のOSSです。ライセンス購入費がない場合も、運用費は無料ではありません。費用は環境とSLAで大きく変わり、年間保守の割合も、Derby専用の公式相場ではありません。

2025年6月改定後、基本契約は30万円／年です（出典: NTTデータ TERASOLUNA フレームワークサポート料金表、2025年）。CPUコア単価も掲載されていますが、これはDerby保守費ではなく、Java基盤の参考値です。

工程と工数の内訳による比較

見積もりは一式の金額ではなく、工程と工数の内訳を同じ条件で比べます。

• 工程：現行調査、要件定義、設計、アプリ改修、DB設計、移行、テスト、脆弱性確認、インフラ、切替、教育、保守。
• 工数・前提：人日または人月、担当ロール、単価、前提条件、除外事項。
• 比較基準：成果物と受入基準をそろえ、値引き率より作業範囲で比べます。

安い移行見積もりでは、データ照合や切替リハーサルが除外されている場合があります。一方で、高い見積もりにSQL差分調査、復元、引き継ぎ、3回のリハーサルが含まれているなら、同じ条件にそろえると差が縮むこともあります。

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

委託先の評価は、Java/JDBC、SQL差分、データ移行、セキュリティ、クラウド、運用の実績を組み合わせて行います。Derbyの利用経験は、その判断材料の一つです。

公開情報からDerby専用のサポートを確認できる企業は限られます。「正式にサポートできる」と答える会社には、対応範囲と根拠を具体的に質問します。

Derby名より移行と運用の実績

確認したいのは、Derby名よりも移行と運用に関わる経験や体制です。

• 技術経験：Derbyの版とJDKを伝え、同じ構成の調査、代替DB移行、Java更新、照合、切替リハーサルを尋ねます。
• 実績条件：データ量、停止時間、同時接続数、外部連携、可用性要件、納品物を、実績と照らして確認します。
• 候補企業：Java業務システムや大規模DB移行のSIer、モダナイゼーション会社、クラウド移行・運用会社。

NTTデータ、IBM、SCSK、富士通、NEC、日立製作所なども比較の対象になります。ただし、これらの会社がDerbyを正式に保守しているわけではありません。対応の可否、移行先DB、保守終了の条件は、会社ごとに確認します。

提案書の3案の同条件での比較

提案の3案は、同じ条件で並べて比べます。

• 選択肢：現行Derbyの短期延命、段階的な代替DB移行、業務アプリを含む再構築。
• 費用・期間：初期費用、期間、停止時間、3〜5年の保守費を比べます。
• リスク・実現性：障害、社内作業、移行余地、検証方法、移行できない場合の代替案を確認します。

「PostgreSQLへ移行可能」という説明だけでは不十分です。予約語、NULL、日付型、採番、LOBの扱いを確認します。さらに、トランザクション分離、例外コード、インデックス、帳票、バッチについても、検証方法を尋ねます。

サンプルデータの実演やPoCがあれば、見積もりの根拠を確かめられます。

避けたい見積もりと提案の特徴

提案の説明、除外項目、担当者の技術理解を、それぞれ確かめます。

• 根拠のない断定：「OSSなので保守費不要」「JAR交換だけで移行可能」など、範囲や検証条件がない説明。
• 未担当の作業：要件定義、照合、復元、切替リハーサル、運用教育の除外と発注者側の担当。
• 技術説明：構成差、JDK 21以上が前提の10.17.1.0、通信・権限リスク、移行先DBの設計理由。

10.17.1.0の対象は、Java SE 21以上、JDBC 4.2です（出典: Apache Derby 10.17.1.0 Release、2023年）。Java 21未満はサポート外のため、古いJDKでも問題ないという断定は、改めて確認します。

発注後にApache Derbyのシステム開発を進める手順

委託先が決まったら、工程を分けて進めます。要件定義と設計に続いて開発・移行とテストを行い、切替と保守引き継ぎへ進みます。

工程ごとに終了条件を定めたうえで、週次または隔週の定例で課題、リスク、変更を確認します。予算と納期も、同じ場で見ます。技術課題は業務データの確認にも関わるため、業務担当者も開発担当者と一緒に定例会へ参加します。

要件定義での移行判断と運用責任の確定

要件定義の終わりに移行方針を決め、未決事項には担当者と期限を設けます。

• 移行方針：Derby継続、短期延命後の移行、今回の開発での移行から選びます。
• 継続利用：保守終了リスクの責任者、JDK検証周期、脆弱性確認担当、移行開始条件を記録します。
• 移行実施：候補DB、移行方式、データ照合方法、切替日、切戻し条件を決めます。
• 未決事項：担当者と期限を定め、設計後の大きな仕様変更を避けます。

RTO、RPO、バックアップ復元の責任、個人情報の扱い、24時間運用の要否は、費用と契約の両方に影響します。

データ・性能・障害の三方向でのテスト

機能、移行データ、性能、障害のそれぞれの条件を分けて検証します。

• 機能・データ：登録、更新、検索、削除、帳票、バッチ、外部連携と、件数、主キー、関連付け、金額、日付、文字、LOB。
• 性能：月末や締め処理など負荷が集中する時間帯を再現し、応答時間と処理件数を測ります。
• 障害：DB停止、アプリ再起動、ネットワーク断、容量不足、復元、移行途中の失敗を試します。

Network Serverでは、認証失敗、権限不足、TLS、ファイアウォール、ログ記録も対象になります。事前に失敗条件を見つけておくと、本番停止のリスクを下げられます。

開発の一部としての切替と引き継ぎ

切替と引き継ぎは次の順に進め、担当者が運用できるかどうかを確かめます。

1. 匿名化した実データでリハーサルし、バックアップ、初回・差分移行、接続、照合、利用者確認、切戻しの時間を測ります。
2. 切替当日の担当者、判断者、連絡先、作業ログ、中止条件を決めます。
3. 担当者がバックアップ復元、監視アラート確認、障害対応を実行して引き継ぎます。

外注先の保守が終わったあとも運用できると確かめてから検収を完了すれば、退役したDBを抱える期間のリスクを管理できます。

Apache Derbyのシステム発注・外注でよくある質問

発注前によく相談される質問に回答します。Derbyは退役済みのため、費用の安さだけでなく、将来の保守責任と移行のしやすさを判断の軸にします。

2026年に新規システムでApache Derbyを採用しても問題ありませんか？

Derbyが必須でない新規システムでは、現在も保守とセキュリティ対応が続く代替DBを比べることをおすすめします。

Derbyは2025年10月に退役し、開発とバグ修正が終了しました。採用する場合は、脆弱性対応とJDK更新、移行費用のリスク承認を行ったうえで、利用範囲を限定します。

Embedded構成のApache Derbyを複数人で使うシステムにできますか？

複数のユーザーがネットワーク経由で使うなら、Network Server構成が候補になります。一方で、同じデータファイルを単純に共有する設計にはできません。

認証、暗号化、権限、接続数を要件に含めるほか、バックアップ、障害復旧、容量監視も入れておきます。判断は、実際の同時接続数と業務処理によるPoCの後に行います。

Apache Derbyのシステム移行を外注するといくらかかりますか？

類似するJava業務システムからの推定では、技術検証は50万〜150万円程度、既存Derbyのデータ移行は300万〜1,200万円程度です。

基幹連携や高可用性を含む刷新は、1,000万〜3,000万円超となる可能性があります。このレンジは公式料金ではなく、データ量、SQL差分、画面数のほか、外部連携、停止時間、テスト範囲で変わります。

RFPで工程別の工数、成果物、除外事項をそろえ、見積もりを比べてください。

Apache Derbyを知っている開発会社が見つからないときはどう探せばよいですか？

Derby専業に絞らず、Java/JDBC、レガシー刷新、RDB移行、クラウド運用、セキュリティを扱う会社にRFPを送ります。その際は、Derbyのバージョンと構成も伝えます。

評価は、現行調査、代替DBの提案、データ照合、切替リハーサル、納品物を説明できるかで行います。公開実績の社名や費用は推測せず、確かめた情報で判断します。

まとめ

Apache Derbyの発注では、利用自体を目的にせず、既存資産の延命、代替DBへの段階移行、新規システムの再構築を比較します。

Derbyは2025年10月に退役しました。ライセンス費が不要という理由だけで採用すると、JDK更新、脆弱性調査、障害対応、移行準備の費用が後から発生する可能性があります。

発注前には、構成、バージョン、JDK、データ量、利用者数を確かめ、RFPに整理します。そのうえで、RTO・RPO、バックアップ、セキュリティ、外部連携の条件も含めます。

調査やPoCは準委任、範囲が固まった開発は請負など、工程に合わせて契約を結びます。さらに、工程別の工数と成果物を比べ、委託先がJava/JDBC、移行、テスト、切替、運用引き継ぎまで任せられるかを確かめます。

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

▼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を創業。