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

Apache Derbyのシステム開発を発注・外注するなら、Derbyを使う前提で見積もりを集めるのではなく、既存資産の延命、代替データベースへの移行、新規システムの再構築を比較できるRFPを用意することが重要です。Apache Derbyは2025年10月10日にプロジェクトが退役し、開発やバグ修正、新しいリリースが終了しているため、2026年時点では将来の保守責任と移行費用まで含めて委託先を選ぶ必要があります。

この記事では、Apache Derbyのシステムを発注・外注するときの発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較ポイントを順番に解説します。EmbeddedとNetwork Serverの違い、JavaやJDBCの互換性、バックアップやセキュリティまで整理するため、既存Derby環境の保守を任せたい企業にも、これからJava業務システムを作る企業にも役立つ内容です。

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

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

Apache Derbyのシステム発注では、最初に「何を作るか」だけでなく「Derbyを今後も使い続けるのか」を決めます。新規開発と既存システムの保守では適切な発注先も契約の進め方も異なり、ここを曖昧にすると、開発の途中でデータベース移行が追加されて見積もりと納期が大きく変わります。

新規の業務システムを作る場合は、Derbyの機能だけでなく、今後も修正を受けられるデータベースか、Javaの更新に追随できるか、障害時に相談できる窓口があるかを確認します。Apache公式のDownloadsページでは、2025年10月10日に退役して読み取り専用になり、配布物も現状有姿で提供されると案内されています（出典: Apache Derby Downloads、2025年）。そのため、Derbyが必須でない新規案件では、PostgreSQLやMySQL、商用データベース、クラウドのマネージドデータベースを第一候補にして、Derby採用を例外扱いにする方が発注後のリスクを説明しやすいです。

一方、既存Derbyシステムでは、すぐに移行できない業務上の理由があるかもしれません。その場合は、現行環境の調査、短期延命、段階移行、全面再構築の4案を並べ、各案の初期費用、停止時間、保守期間、移行期限を見積もってもらいます。「Derbyを知っている会社」だけでなく、「Java/JDBCの調査と代替DB移行を説明できる会社」を探すことが大切です。

DerbyのEmbedded構成は、データベースエンジンと業務アプリケーションを同じJVMで動かす方式です。インストールや構成が小さく、単一製品のローカルデータストアや検証用途には向きますが、同じデータベースファイルを複数のJVMや複数ホストから直接共有する前提ではありません。発注時には利用者数だけでなく、同時接続数、起動するJVMの数、障害時の復旧方法を伝えます。

Network ServerはDerbyをサーバー側JVMで起動し、別のJVMやクライアントからネットワーク経由で接続する方式です。複数ユーザーの業務システムには候補になりますが、認証、TLSなどの暗号化、ファイアウォール、SQL権限、監視、バックアップを別途設計しなければなりません。Derby公式セキュリティガイドは、初期状態ではネットワーク通信が平文で流れること、権限が強すぎること、容量が無制限に増え得ることなどを注意点として挙げています（出典: Apache Derby Security Guide、10.17）。この確認を見積もりの対象外にしないことが重要です。

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

外注の方法は、最初から開発全体を一社へ任せる方法だけではありません。Derbyの退役によって技術調査の不確実性が高まっているため、最初の契約を小さく切り出し、調査結果をもとに本開発や移行の発注へ進む方式も有効です。自社に残す判断と外部へ任せる判断を、業務知識、技術知識、運用責任の3軸で決めます。

要件、画面、外部連携、移行対象、検収条件が固まっている場合は、要件定義から設計、開発、テスト、リリースまでを一括して請負契約にする方法が向いています。発注者側の窓口を一本化しやすく、納期や成果物を管理しやすい反面、Derbyの現行仕様が不明なまま一括発注すると、想定外のSQL差分やデータ不整合が変更費用になりやすいです。

一括請負を選ぶ場合でも、最初に現行調査と要件定義だけを準委任で依頼し、その成果物を確認してから開発を請負に切り替える二段階方式を検討します。契約を分けると発注管理は増えますが、調査結果を見ずに数百万円から数千万円規模の本契約を結ぶリスクを抑えられます。

既存Derbyのバージョン、JDK、JDBCドライバー、アプリケーションサーバー、OS、データ量が分からない場合は、2〜6週間程度の技術検証を先行させます。検証内容は、EmbeddedとNetwork Serverの起動確認、Java 21環境での互換性確認、主要SQLの実行、データのエクスポートと代替DBへの投入、バックアップ復元、代表的な業務処理の性能測定です。

PoCでは「動いた」という報告だけでなく、実行できなかったSQL、型変換で失われる可能性があるデータ、必要なアプリ改修、性能の測定条件、残るリスクを成果物に含めてもらいます。PoCの結論が「移行しない」であっても、継続利用の条件と移行開始のトリガーが明確になれば、発注者にとって価値のある成果です。

業務部門が現場のルールを説明し、外注先がJava、JDBC、データ移行、クラウド、テストを担当する分担も現実的です。特にDerby固有の運用手順やデータの意味を社内担当者が把握している場合、業務知識を発注者側に残すことで、移行後のベンダーロックインを抑えられます。

ただし、役割分担を口頭で済ませると、障害やデータ不整合が起きた際に責任の押し付け合いが起きます。要件定義書には、設計、実装、データ移行、バックアップ、監視、障害一次対応、リリース承認、問い合わせ窓口の担当者を明記し、RACI表などで責任分界を確認します。

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

RFPは、会社を選ぶための依頼書であると同時に、発注後の認識違いを減らす要件整理の道具です。Apache Derbyの案件では、単に「データベースを移行したい」と書くのではなく、現行資産、業務上の制約、セキュリティ、運用、将来の保守を一つの文書にまとめます。

最初に、Derbyのバージョン、JDKの種類とバージョン、JDBCドライバー、接続方式、データベースの保存場所、起動と停止の手順を一覧化します。次に、テーブル、主キー、外部キー、インデックス、ビュー、トリガー、ストアド処理、LOB、日付や数値型、文字コード、予約語を確認します。`ij`、`dblook`、`sysinfo`などの付属ツールを使った調査を依頼する場合は、実行結果と調査日も納品物に含めます。

データ量は現在値だけでなく、月次の増加量、保存期間、削除ルール、バックアップ容量まで書きます。個人情報や機密情報が含まれる場合は、サンプルデータの匿名化方法、開発環境への持ち出し制限、アクセスログの扱いもRFPに入れます。調査対象を先に指定すると、会社ごとに違う前提で見積もる事態を防げます。

機能要件には、利用者、権限、画面、帳票、バッチ、外部API、CSV入出力、検索条件、登録や更新のルールを記載します。移行案件なら、どのデータを新DBへ移し、どのデータを参照用に残し、移行後にどの期間だけ旧環境を保持するかも決めます。業務担当者が確認できる受入テストのシナリオを先に用意すると、完成イメージをベンダーと共有しやすくなります。

非機能要件には、同時接続数、レスポンスタイム、処理件数、稼働時間、障害復旧時間、目標復旧時点、バックアップ世代、監視、ログ保存期間、暗号化、脆弱性対応、データ保持期間を含めます。Derbyは構成によって責任範囲が大きく変わるため、「高可用性」「安全に運用」といった言葉だけでは不足します。例えば、障害から何時間以内に復旧するか、最大何分のデータ損失まで許容するかを数値で示します。

見積もりを比較する際は、開発費だけでなく、現行調査報告書、要件定義書、基本設計書、詳細設計書、DDL、データ移行手順、テスト仕様書と結果、運用手順書、監視設計、障害対応手順、ソースコード、ビルド手順の有無を確認します。特に、Derbyの継続利用を選ぶ場合は、起動停止、バックアップ復元、容量監視、JDK更新時の検証手順がなければ、担当者の退職後に運用が止まる可能性があります。

成果物の著作権や利用権、第三者OSSのライセンス表示、リポジトリへのアクセス権、アカウントの返却、保守終了後の問い合わせ方法も契約前に確認します。納品時点で動けばよいのではなく、別会社へ保守を移せる状態を納品条件にすることが、ベンダーロックインを防ぐ実務的な方法です。

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

契約形態は、成果物と範囲が明確な工程には請負、調査や要件変更が多い工程には準委任を組み合わせると整理しやすいです。重要なのは契約名だけでなく、何をもって完了とするか、仕様変更の費用をどう決めるか、障害が起きたときの責任をどこまで負うかを文書化することです。

現行調査やPoCは、調査を進めなければ作業量が確定しないため、準委任契約で専門家の稼働を確保する方法が適しています。作業時間、担当者、調査項目、週次報告、成果物、上限金額を明確にします。準委任だから成果物が不要なのではなく、調査報告書や課題一覧、移行候補比較など、次の意思決定に使う成果を定義します。

画面やデータ移行の範囲、テスト条件、受入基準が固まった後は、請負契約で工程ごとの成果物と検収日を設定できます。ただし、既存データの欠損や未知のSQLが後から見つかる場合に備えて、前提条件、除外範囲、変更管理の単価、追加見積もりの承認手続きを契約書と別紙に残します。

Apache Derbyの移行や外注では、画面が表示されても、データの件数や金額が一致していなければ業務システムとして完成していません。検収条件には、移行前後の件数照合、合計値照合、文字化け確認、日付とタイムゾーン確認、LOBの読み書き、権限別の操作、主要バッチ、バックアップ復元、障害時の再実行を含めます。

本番切替の検収では、切替リハーサルの所要時間、停止可能な時間、差分データの取り込み、切戻しの判断基準と手順も確認します。受入テストを発注者の業務担当者が実施し、ベンダーはテスト環境、データ準備、結果の記録を支援するという役割分担にすると、現場で使えるかどうかを判断しやすいです。

退役したDerbyでは、一般的な保守契約のように新機能や修正リリースを期待できません。委託先へ確認する内容は、問い合わせ受付時間、障害の一次切り分け、JDKやOSの更新検証、脆弱性情報の調査、バックアップ復元支援、代替DBへの移行計画、保守を終了する条件です。Derby専用の現行商用サポートをうたう会社は限られるため、対応できない領域を明確にしておく必要があります。

保守を年単位で契約する場合も、3〜5年のTCOを作成します。1年目の保守費が安くても、Java更新や障害調査のたびに高額なスポット費が発生するなら、早期移行の方が合理的な場合があります。逆に、短期間で廃止予定のシステムなら、延命と移行準備を分けた契約が適することもあります。

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

Apache Derby単体の開発費や保守費について、公的に統一された価格表はありません。以下の金額は、リサーチノートにある2026年の類似Java業務システム相場、工程、データ移行の難易度から推定したレンジです。画面数、外部連携、データ量、停止可能時間、セキュリティ、冗長化、利用者数によって変わるため、予算取りの目安として使い、最終判断はRFPに対する個別見積もりで行います。

技術検証や小規模PoCは、JavaとJDBCの接続確認、EmbeddedとNetwork Serverの比較、簡易性能試験、移行可能性の確認を含めて50万〜150万円程度が一つの目安です。社内向けの小規模業務システムなら150万〜500万円程度、複数業務や外部連携を含む部門向けシステムなら500万〜1,500万円程度が推定レンジになります。いずれもDerby公式の価格ではなく、類似するJava業務システムの開発作業からの推定です。

既存DerbyのDB移行は、現行調査、SQLやJDBCの差分修正、スキーマ変換、データ移行、並行稼働、切替リハーサルを含めて300万〜1,200万円程度、基幹連携や高可用性、監査ログ、複数拠点を含む刷新は1,000万〜3,000万円超となる可能性があります。相場の根拠として、2026年の業務システム開発の公開情報でも、小規模スクラッチは100万〜300万円、中規模は300万〜800万円、中〜大規模は800万〜数千万円とされます（出典: 業務システム開発の費用相場、2026年）。Derby案件では、退役後の調査と移行準備が加わる分を別項目で確認します。

Apache License 2.0のOSSであるため、Derby本体のライセンス購入費が発生しないケースでも、システムの運用費が無料になるわけではありません。クラウドのVM、ストレージ、バックアップ、監視、ログ保管、ネットワーク、障害対応、JDK更新検証、セキュリティ評価、移行準備を分けて見積もります。小規模なクラウド運用の仮置きとして月額5万〜30万円程度、24時間監視や冗長化を含む場合は月額30万〜100万円以上を想定することがありますが、環境とSLAによって大きく変わります。

年間保守は初期開発費の10〜20％程度を仮置きする一般論がありますが、これはDerby専用の公式相場ではありません。Java関連の参考情報として、NTTデータのTERASOLUNAフレームワークサポートでは、2025年6月の価格改定後に運用時サポートの基本契約30万円／年やCPUコア単価が掲載されています（出典: NTTデータ TERASOLUNA フレームワークサポート料金表、2025年）。この金額をDerby保守費と読み替えず、Java基盤のサポート費用を比較するときの参考値として扱います。

見積書は、現行調査、要件定義、基本設計、詳細設計、アプリ改修、DB設計、データ移行、テスト、脆弱性確認、インフラ構築、切替、教育、保守に分けてもらいます。各工程で人日または人月、担当ロール、単価、前提条件、除外事項を示してもらうと、金額が安い理由や高い理由を判断できます。

例えば、A社が移行費を低く見積もっていても、データ照合や切替リハーサルが除外されているかもしれません。B社が高く見えても、SQL差分調査、バックアップ復元、運用引き継ぎ、3回のリハーサルまで含んでいれば、同じ条件に直して比較すると差が縮まる場合があります。値引き率ではなく、同じ成果物と同じ受入基準にそろえて比較することがポイントです。

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

委託先は、Apache Derbyの利用経験だけでランキングするのではなく、Java/JDBC、SQL差分、データ移行、セキュリティ、クラウド、運用の実績を組み合わせて評価します。公開情報だけでDerby専用サポートを確認できる企業は限られるため、提案時に「Derbyを正式サポートできます」と言い切る会社ほど、対応範囲と根拠を具体的に質問することが大切です。

候補会社には、DerbyのバージョンとJDKを伝えたうえで、同じ構成の調査、代替DBへの移行、Javaのバージョンアップ、データ照合、切替リハーサルを経験しているかを質問します。実績を確認する際は、会社名や導入社数だけでなく、どの程度のデータ量、停止時間、同時接続数、外部連携、可用性要件だったか、どの成果物を納品したかを聞きます。

候補になり得るのは、Java業務システムや大規模なDB移行を扱うSIer、Javaモダナイゼーションを支援するコンサルティング会社、クラウド移行と運用を一体で行う会社です。NTTデータ、IBM、SCSK、富士通、NEC、日立製作所なども比較対象にはなりますが、各社がApache Derbyを正式に保守するという意味ではありません。Derby対応の可否、移行先DB、保守終了条件を個別に確認します。

見積比較では、(1)現行Derbyの短期延命、(2)Derbyを段階的に代替DBへ移行、(3)業務アプリを含めて再構築、の3案を同じ前提で提示してもらいます。各案について、初期費用、期間、停止時間、3〜5年の保守費、想定される障害、必要な社内作業、将来の移行余地を並べると、安い案ではなく自社に合う案を選びやすいです。

提案書の技術説明では、単に「PostgreSQLへ移行可能」と書かれているだけでは不十分です。予約語、NULLの扱い、日付型、採番、LOB、トランザクション分離、例外コード、インデックス、帳票、バッチをどう検証するか、移行できない場合の代替案まで記載されているか確認します。サンプルデータを使った実演やPoCの提案がある会社は、見積もりの根拠を確かめやすいです。

「OSSなので保守費は不要」「JARを差し替えれば移行できる」「テストは納品前に実施する」といった説明だけで、調査範囲や検証条件を示さない提案には注意します。また、最安値を出すために、要件定義、データ照合、バックアップ復元、切替リハーサル、運用教育を除外している場合があります。除外項目が明記されていること自体は問題ではありませんが、発注者側で誰が担うのかを決めないまま契約してはいけません。

担当予定者との打ち合わせで、DerbyのEmbeddedとNetwork Serverの違い、JDK 21以上に対応する10.17.1.0の前提、平文通信や権限設定のリスク、移行先DBの設計理由を説明できるか確認します。Apache公式の10.17.1.0リリース情報では、Java SE 21以上とJDBC 4.2が対象で、Java 21未満はサポートしないとされています（出典: Apache Derby 10.17.1.0 Release、2023年）。このような公式情報を踏まえず、古いJDKのまま「問題なく使える」と断定する提案は再確認が必要です。

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

委託先が決まった後は、要件定義、設計、開発・移行、テスト、切替、保守引き継ぎを工程として区切ります。工程ごとの終了条件を決め、週次または隔週で課題、リスク、変更、予算、納期を確認します。Derby案件では、技術的な問題が業務データの確認に直結するため、開発担当者だけでなく業務担当者も定例会に参加させます。

要件定義の終わりには、Derbyを継続利用するのか、短期延命後に移行するのか、今回の開発で移行まで実施するのかを決めます。継続利用なら、保守終了のリスクを受け入れる責任者、JDK更新の検証周期、脆弱性情報を確認する担当、移行開始の条件を記録します。移行するなら、候補DB、移行方式、データ照合方法、切替日、切戻し条件を確定します。

この段階で決め切れないものは、未決事項として担当者と期限を設定します。未決事項を「検討中」のまま設計へ進めると、後工程で大きな仕様変更になりやすいです。特に、RTOやRPO、バックアップの復元責任、個人情報の取り扱い、24時間運用の要否は、費用と契約の両方に影響します。

機能テストでは、登録、更新、検索、削除、帳票、バッチ、外部連携を確認します。移行テストでは、テーブル件数、主キー、関連付け、金額合計、日付、文字、LOBを移行前後で照合します。性能テストでは、通常時だけでなく月末や締め処理など、負荷が集中する時間帯を再現して、レスポンスタイムと処理件数を測定します。

障害テストでは、DB停止、アプリ再起動、ネットワーク断、ディスク容量不足、バックアップからの復元、移行処理の途中失敗を確認します。Network Serverを使う場合は、認証失敗、権限不足、TLS設定、ファイアウォール、ログの記録も対象にします。テストを省略して納品を早めるより、事前に失敗条件を見つけて本番停止のリスクを下げる方が、発注者にとって合理的です。

本番切替の前には、実データを匿名化したリハーサルを行い、バックアップ取得、初回移行、差分移行、アプリ接続、データ照合、利用者確認、切戻しまでの時間を測ります。切替当日の担当者、判断者、連絡先、作業ログ、作業を中止する条件を決めておくと、トラブル時にも判断が遅れにくいです。

引き継ぎでは、ソースコードや設計書を渡すだけでなく、担当者が実際にバックアップを復元し、監視アラートを確認し、障害対応手順を実行します。外注先の保守が終了しても運用を続けられることを確認してから検収を完了させると、退役DBを抱える期間のリスクを管理できます。

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

ここでは、発注前に特に相談されやすい質問へ回答します。Derbyは退役済みであるため、費用の安さだけでなく、今後の保守責任と移行のしやすさを判断軸にすることが共通のポイントです。

Derbyが必須でない新規システムでは、原則として現在も保守とセキュリティ対応が続く代替データベースを比較することをおすすめします。Apache Derbyは2025年10月に退役し、開発やバグ修正が終了しているため、採用する場合は、将来の脆弱性対応、JDK更新、移行費用を含むリスク承認を行い、利用範囲を限定します。

複数ユーザーがネットワーク経由で利用するなら、Network Server構成が候補になりますが、単純にデータファイルを共有する設計にはできません。認証、暗号化、権限、接続数、バックアップ、障害復旧、容量監視を要件に含め、実際の同時接続数と業務処理を使ったPoCを実施してから判断します。

類似Java業務システムからの推定では、技術検証が50万〜150万円程度、既存Derbyのデータ移行が300万〜1,200万円程度、基幹連携や高可用性を含む刷新が1,000万〜3,000万円超となる可能性があります。これは公式料金ではなく、データ量、SQL差分、画面数、外部連携、停止時間、テスト範囲で変動するレンジです。RFPで工程別の人日、成果物、除外事項をそろえて見積もりを比較してください。

Derby専業の会社名だけを探すのではなく、Java/JDBC、レガシーシステム刷新、RDB移行、クラウド運用、セキュリティを扱う会社へRFPを送り、Derbyのバージョンや構成を伝えて対応可否を確認します。公開実績の社名や費用を推測せず、現行調査の方法、代替DBの提案、データ照合、切替リハーサル、納品物を説明できるかで評価します。

まとめ

Apache Derbyのシステムを発注・外注するときは、Derbyを使うこと自体を目的にせず、既存資産の延命、代替DBへの段階移行、新規システムの再構築を比較するところから始めます。2025年10月にDerbyプロジェクトが退役したため、ライセンス費が不要という理由だけで採用を決めると、JDK更新、脆弱性調査、障害対応、移行準備の費用が後から発生する可能性があります。

発注前には、EmbeddedかNetwork Serverか、現行バージョンとJDK、データ量、利用者数、RTO・RPO、バックアップ、セキュリティ、外部連携をRFPに整理します。調査やPoCは準委任、範囲が固まった開発は請負など、工程に合わせて契約を使い分け、見積もりは工程別の工数と成果物で比較します。委託先には、Derbyの知名度だけでなく、Java/JDBC、データ移行、テスト、切替、運用引き継ぎまで任せられるかを確認してください。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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