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

Informixのシステムを発注する流れは、現行資産を調査して移行方針と委託範囲を決め、そのうえで契約と受入条件を固めることです。

この順で進めると、追加費用や業務停止のリスクを抑えやすくなります。全体像は、Informixのシステム開発の完全ガイドにまとめているので、あわせてご覧ください。

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

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

Informixのシステムを外注する前に決めること

Informixの開発では、データベース、アプリ、OS、帳票、外部連携、運用を一体で扱うことになります。そのため、残すものと変えるもの、委託範囲を先に決めておくと、提案と見積もりを比べやすくなります。

既存Informixを残すか移行するかの決定

最初に決めるのは、どの方向へ進むかです。候補は次の4つで、既存環境の保守改修から別DBへの移行まで、残す範囲がそれぞれ違います。

• 既存環境を改修：Informixを残したまま、アプリを直す進め方。
• サーバーを移設：データベースを維持したまま、クラウドへ移す形。
• 段階的に近代化：Linuxやコンテナへ、段階を踏んで寄せる形。
• 別DBへ移行：Oracle、SQL Server、PostgreSQLなどへ移す形。

問題のないシステムを全面刷新すると、業務仕様の再定義やデータ変換の費用が膨らみます。一方で、古いOSや特定の担当者への依存があると、保守を続けるだけでは将来の障害対応が難しくなります。

判断には、Informixのバージョンや稼働OS、DBサイズに加えて、同時接続数やピーク時間帯も使います。停止可能時間やRTO・RPOは、障害時にどこまで止められ、どのデータ時点まで戻すかを決める数値です。

保守担当者とソースコードの有無も、あわせて確認します。停止できない受発注システムでは、移行先を先に決めず、レプリケーションや並行稼働、切戻し手順も評価します。製品名だけでなく、業務を止めずに検証できるかも見ます。

委託範囲と社内に残す責任の切り分け

委託範囲を決めるには、工程ごとの担当と、社内に残す判断を整理します。特に、現行調査と移行設計の担当が初期見積もりを左右します。

• 委託候補：現行調査、要件定義、基本設計が候補です。詳細設計、開発、移行も含まれます。基盤構築とテスト、教育と保守も対象に入ります。
• 社内の責任：業務の優先順位、受入基準、個人情報の扱い、リリース承認。

Informix本体、4GLやESQL/Cの解析、AWSなどへの移行、他DBへの変換では、会社ごとに得意な領域が違います。そのため、RFPに成果物と担当範囲を明記し、同じ条件で提案を受けます。

Informixのシステム開発に適した発注形態

発注形態は、変動する部分と固定できる部分の分担で選びます。仕様が見えにくいInformixでは、調査と要件定義を先行させ、不確実性を減らしてから本開発へ進みます。

要件が固まった範囲の請負契約による発注

画面一覧や機能仕様など、テスト条件や納期まで固まった範囲は、請負契約による一括発注が候補です。納品物と完成条件が明確なら、予算と納期を管理しやすくなります。

新しいAPIや定型帳票など、対象を限定できる開発に向いています。一方、旧4GLの挙動解析や文字コード、帳票の印字差異は、着手前に工数を確定できない場合があります。実データでの検証も、同じように工数を確定しにくい作業です。

未確定の作業まで請負に含めると、追加費用の交渉や品質低下につながります。そのため、前提条件と対象外を契約書と仕様書に記載し、変更管理や検収方法もあわせて定めます。

現行調査とPoCの準委任・ラボ型での進め方

現行調査や性能検証には、準委任契約や時間・工数基準のラボ型が使いやすい形です。調査期間は、たとえば2週間から2か月程度に区切ります。

• 調査成果物：DB定義一覧、プログラム依存関係、移行課題一覧。
• 検証成果物：PoC結果と次工程の見積もり。

調査を有償にすると、開発会社も経験者を配置しやすくなります。PoCでは匿名化した実データを使い、接続やSQLの動きを確かめます。文字コードや日付、NULL、DECIMAL、BLOBなど型に関わる扱いも確認します。

トランザクションとロック、帳票、ピーク時性能も検証対象です。AIや自動変換ツールを使う場合も、変換後のSQLと業務結果は人が照合します。

不明点はPoCで洗い出し、その後に本開発を請負へ切り替えると、見積もりの精度を上げられます。

複数会社に分ける場合の責任分界の決め方

DB保守、クラウド基盤、アプリ開発を別々の会社へ発注することもできますが、その場合は障害時の責任分界を決めておく必要があります。たとえば、API応答が遅いときは、原因がSQL、クラウドのI/O、アプリの接続プールのどこにあるかを切り分けます。

契約前に、監視項目やログ共有の方法、一次と二次の窓口、復旧目標を決めておきます。一社にまとめると窓口と責任が一本化されますが、特定のベンダーへの依存が強まるおそれがあります。

分離発注は専門性を組み合わせやすい反面、全体を統括する役割が必要で、社内PMかプライムベンダーが担います。社内にPMを置けない場合は、要件定義と全体テストだけを統括会社へ頼む方法もあります。

RFPと要件整理でInformixの現状を見える化する方法

RFPは、各社から同じ前提で提案と見積もりを受けるための比較基準です。仕様書だけでは漏れやすいバッチや手作業、例外処理は、担当者への聞き取りやログ確認で補います。

RFPに記載する現行環境と業務の事実

RFPでは、Informixの構成情報と、実際の業務条件や例外処理を分けて整理します。

• DB・基盤：Informixの製品名と版、CSDK・JDBC、OS、サーバー構成、DBサイズ、表数、バックアップ方式、HA・DR構成。
• アプリ資産：Informix-4GL、ESQL/C、C、Visual Basic、Java、.NETなどの言語。
• 業務条件：接続元、同時接続数、ジョブ実行時間、締め時刻、同時処理件数、許容在庫差異、再処理方法、承認、休日運用。
• 業務の実態：画面・帳票、夜間バッチ、手作業のデータ補正、障害時の電話確認も対象です。

ソースの保管場所やコンパイル手順、外部DLL、帳票エンジンも整理します。さらに、現場だけが知る例外処理は、移行後の障害原因になりやすいため確認します。

非機能要件の数値指定

性能や可用性などの条件は、数値を入れた具体的な要件として書きます。

• 性能・可用性：通常時とピーク時の応答時間を、可用性や復旧、監査、運用保守とあわせて定めます。
• 処理・復旧の数値：1時間あたりの処理件数、同時接続数、月間の停止許容時間。
• 情報保護：個人情報・取引情報の権限、操作ログ、通信とバックアップの暗号化、再委託、持ち出し、削除方法。
• 製品機能：Informix 15.0.0では、クラウドバックアップ強化とKubernetesへのHelm Chart展開が案内されています。
• 更新時の確認：現行版からの更新で再コンパイルが必要か、採用するクライアントライブラリ単位で確認します。

RTOは障害から復旧する目標時間、RPOは復元するデータ時点の目標です。

機能があることと、運用要件を満たすことは別の話です。HCLの説明では、Amazon S3へのバックアップには利用料金や契約条件があるため、費用を見積もりに含めます。

15.0.1系ではライセンス、JDBC、wire listenerの変更が案内されています。詳しくはHCL Informix 15.0の新機能を確認してください。

成果物と受入基準の事前の決定

納品物と、業務・移行データの受入条件は、開発会社と事前にそろえておきます。

• 成果物：要件定義書、現行資産一覧、基本設計書、DB定義書、移行設計書、テスト計画・結果。
• 運用引き継ぎ資料：運用手順書、ソース、ビルド手順、教育資料、障害連絡網を記載します。
• 業務受入：画面表示だけでなく、受注から出荷、請求、締め処理までのシナリオを端から端まで確かめます。
• 移行照合：件数に加え、残高、在庫、金額、日付、文字化け、桁あふれ、関連キー、帳票合計を照合し、差異の判定者を決めます。
• 対象外データ：移行しないデータと理由、保管期間を成果物に残します。

Informixのシステム開発で選ぶ契約形態と進め方

契約形態は、発注側の不確実性と受託側の完成責任のバランスで選びます。契約と予算は、調査から設計・開発まで、移行・切替から保守までの節目で分けると管理しやすくなります。

請負・準委任・ラボ型の使い分け

契約形態は、成果物や完成条件が固まっているか、作業内容が変わるかで選びます。

• 請負：合意した成果物を完成・納品します。範囲と完成条件が固まった開発に向きます。
• 準委任：専門家の作業や支援を頼みます。現行解析、要件定義、性能改善、運用支援に向きます。
• ラボ型：一定期間・体制で優先順位を調整する継続開発です。API化や段階的な画面刷新に適しています。

契約には、成果物の権利や、OSSと変換ツールのライセンスを書きます。秘密保持、再委託、個人情報の扱いも記載します。

脆弱性対応や損害賠償、検収期間、瑕疵対応、終了時の引き継ぎについても、契約で定めておきます。特に、古いミドルウェアや開発ツールが残る場合は、納品後に発注側で再構築できるかを確認します。

工程ごとの判断ゲート

工程ごとに承認条件を決めておくと、情報がそろわないまま固定見積もりや本番開発へ進むことを防げます。

1. 現行調査：DBとアプリの依存関係、移行対象、停止条件、リスクを一覧にします。
2. PoC・基本設計：性能、データ整合性、切替方式、運用監視を確認します。
3. 本番切替の準備：総合テスト、受入テスト、移行リハーサル、復元テスト、障害訓練を行います。

現行調査の一覧がそろわなければ、本開発の固定見積もりへは進みません。PoCと基本設計が終わった段階で、性能や整合性を確かめてから本番開発を承認します。

切替時の判断を経験だけに頼らないよう、何分以内に復旧できなければ旧環境へ戻すかと、どのデータを再連携するかを決めておきます。

Claranetが2026年5月に公開した事例では、Solaris・SPARCからUbuntu Linux・AWSへ移行しています。さらに、Informix 12.10から14.10へ更新し、Enterprise Replication、監視、ロールバックの選択肢も組み合わせています。

この事例が示すのは、DB版、複製、監視、運用手順を一体で設計する必要性です。金額や期間は自社案件のものとして扱えません。詳細はClaranetのInformix移行事例で確認できます。

RFPでは必要な範囲を「必須」「できれば」「将来検討」に分けます。

運用保守と引き継ぎを含む契約

開発後に、Informixのパラメータ、バックアップ確認、障害の一次対応を誰が担うかを決めます。保守契約には、受付時間、障害重要度、初動時間、復旧目標を記します。

定期点検やパッチ、バージョンアップ、SQLチューニング、月次報告は、範囲を明記しておきます。引き継ぎでは、復元やユーザー追加、ログ確認などを、担当者が実際に行います。

属人化を避けるため、ソースに加えて、環境構築手順、設定値、監視閾値を残します。データ修正の承認手順と問い合わせ履歴も、引き継ぎの資料に含めます。

Informixのシステム開発にかかる費用相場

開発費は、規模や旧資産の解析、データ移行、停止時間で大きく変わります。DBライセンスやクラウド基盤、保守体制の条件でも変動します。

商用ライセンスの価格は、版やコア数、OS、環境数、サポート契約によって異なるため、一律の金額は示せません。下の概算は、業務システム全般の相場に、Informixの移行・連携で発生しやすい工程を組み合わせたものです。

ケース別の初期費用と期間の目安

費用と期間は、接続確認から基幹刷新までの規模と対象範囲によって幅が出ます。下の金額は、Informix固有の定価ではなく、要件が未確定の段階での概算です。この数字は、NotebookLMのリサーチノート「業務システム全般_10」（2026年作成）を参考にしています。

• 接続確認・小規模PoC：0万円から100万円程度、2週間から2か月程度。
• 小規模Web・API化：150万円から500万円程度、1か月から3か月程度。
• 中小規模の業務連携：受発注や在庫など。500万円から1,500万円程度、3か月から6か月程度。
• 段階的近代化・クラウド移行：1,500万円から5,000万円程度、6か月から18か月程度。
• 大規模刷新・他DB移行：5,000万円から数億円、1年から3年程度になることがあります。

小規模PoCの費用には、環境構築や接続、数本のSQL、性能確認を含む想定です。無償版や開発者向け版を使える場合でも、利用条件と本番ライセンスは別に確かめます。

Web・API化の費用は規模で変わります。業務連携では、要件定義や画面・API、マスタ移行、外部連携、教育を含むかどうかで変動します。

近代化の見積もりには、4GLや旧Visual Basicの維持、HA・DR構築が含まれる場合もあります。大規模移行の金額は、特定の企業の実績をもとにしていません。

見積もりの工程別と継続費用への分解

初期開発の工程と、稼働後に継続して発生する費用を分けて見ます。

• 開発工程：まず現行調査、要件定義、設計を分けます。
• 初期・月額費用：ライセンス・基盤費を、初期と月額に分けて見積もります。
• 継続費用：クラウド利用料、商用ライセンスとサポート、監視、バックアップ保管、通信、障害対応、定期パッチ、OS・ミドルウェア更新。
• 保守費の目安：業務システム全般では年間保守が初期開発費の10%から20%程度となる場合があります。Informixの確定価格ではありません。

開発工程は、そのあとアプリ・DB改修と移行に進みます。基盤とテストを経て、教育と切替支援を行います。

月額には、クラウドVM、ストレージ、バックアップの費用を含めます。監視やネットワークの費用も加え、証明書や外部サービスの費用もあわせて見積もります。

工数だけで比べると、移行や保守が別見積もりに分かれている場合があります。

保守費は、24時間監視や休日対応、更新、現地対応の有無で変わります。サービス水準ごとに見積もります（出典：NotebookLM「業務システム全般_10」、2026年作成のリサーチノート）。

2025年7月のIBMセキュリティ速報では、Informix Serverの12.10および14.10を対象に、同梱IBM Javaの更新を案内しています（出典：IBM Security Bulletin、2025年7月28日）。DBだけでなく、JDBCやJava、REST listener、OS、コンテナも継続して確認します。

セキュリティ対応を保守費から外すと、後で予算化しにくくなります。契約時には、IBMのInformix向けセキュリティ速報を参照して、対象版と修正版、対応範囲を明示しておきます。

Informixのシステム開発会社と委託先の選び方

委託先は、経験年数や会社規模だけでなく、自社に近い構成を最後まで支援できるかで選びます。そのうえで、4GL解析やSQL調整、移行、クラウド、業務テスト、運用引き継ぎのうち、どこを担当するかを確かめます。

技術名ではなく成果物で見る実績の確認

過去案件について、Informixの版やOS、言語、データ量、停止条件を聞きます。顧客名を出せない場合でも、現行解析や移行前後の照合、テスト件数、切替方式、障害対応については説明を求めます。

移行計画書やテスト計画書、運用設計書のサンプルや目次から、提案の具体性を判断します。「Informixに対応可能」が、どの作業を指すのかも確かめます。

DB導入や4GL・ESQL/C修正、旧コードの再コンパイル、他DB変換後の業務テストでは、必要な能力が異なります。あわせて、提案担当が本番まで参加するかを確かめ、担当者の役割と稼働期間も確認します。

候補会社への質問の順番

現行調査については、受け取る資料や確認するログ・ソース、所要週数、成果物を質問します。続けて、移行サンプルや文字コード・日付の扱い、性能試験を確かめます。

バックアップの復元や切替・切戻し、障害時の連絡体制についても聞きます。発注側の作業では、ヒアリング参加者や匿名化、テストデータの準備、受入担当を確認します。

夜間切替の立ち会いや運用教育を、誰が担うかも確かめます。発注側の作業が見積もりに入っていない場合は、社内の負担や納期が想定を超える可能性があります。

見積書の比較は金額より前提条件から

各社の金額を比べる前に、見積もりの対象範囲と計算条件をそろえておきます。

• 見積もりの前提：調査、移行対象と対象外、ライセンスやクラウド費用の年数、テストと切替の回数、保守の受付時間。
• 費用の抜け：安価な提案では要件定義、データ照合、教育、障害対応が別料金の場合があります。
• 比較表：工程、成果物、工数、単価、外部費用、前提、対象外、発注側の作業、納期、リスクを並べます。
• 評価軸：価格に加え、技術適合性、業務理解、移行品質、体制、保守性、セキュリティ、引き継ぎを評価します。

評価表を提案会社と共有し、条件の違いを説明してもらうと、後の追加請求を減らせます。

発注時に確認したいInformixの移行・セキュリティリスク

大きな失敗につながりやすいのは、移行対象の漏れやテスト不足、切替計画の不在、運用責任の曖昧さです。セキュリティは、DBだけでなくアプリやドライバ、REST、OSまで見る必要があります。ネットワークやバックアップも対象に入ります。

移行前のデータとアプリの差異の検証

他DBへ移行する場合は、DBやアプリの仕様差を、クラウド移行では移行後の運用条件を事前に確かめます。

• DBの互換性：Informix固有SQL、外部キー、トランザクション、ロック、日付・数値型の扱い。
• アプリの互換性：ストアドプロシージャ、権限、バッチ、帳票、エラー処理の差。
• クラウド基盤：サーバー性能、ストレージ、バックアップ時間、通信経路、監視、可用性ゾーン、復旧、ライセンス条件の確認。

変換ツールを使う場合も、自動変換率だけで判断せず、業務シナリオの結果で品質を見ます。

HCLの情報では、ON-BarとPrimary Storage ManagerでS3へバックアップできます。ただし、料金と契約条件は利用者側の責任になります。月額は、バックアップ世代数と復元時の通信も含めて試算します。

HCL Informixのクラウドバックアップ仕様を確かめたうえで、バックアップや復元、暗号化、保持期間、削除の実施者を、提案会社に回答してもらいます。

DB・ドライバ・API・OSをまとめた管理

REST APIを含む接続経路と、個人情報の扱い、版更新時の認証条件を、具体的に決めておきます。

• API・DB接続：REST APIを含む接続の認証、通信、権限の条件。
• 個人情報：開発・検証データを匿名化し、委託先端末の保存期限と削除証跡を確認します。
• 版更新：15.0.1.13以降、wire listener認証がデフォルトで有効になる変更が案内されています。設定は検証環境で確認します。
• 安全性の受入条件：通信TLS、管理者の多要素認証、職務単位の権限、ログ保管、暗号化バックアップ、月次の脆弱性確認。
• 適用法令：扱うデータや業務に応じて確認し、必要なら法務・監査部門をRFP作成に加えます。

REST APIでは、TLSや認証、権限を定めたうえで、CSRF対策やセッション、接続プールの扱いまで決めます。監査ログとネットワーク制限も、あわせて定めます。

DBポートは、インターネットへ直接公開しない前提で設計します。入力値を検証し、最小権限を与えるようにします。新機能を使わない場合でも、将来の設定変更は保守会社に確認しておきます。

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

発注時は、技術力に加えて、現行資産と業務の不確実性をどこまで減らせるかが重要です。よく寄せられる質問に順に答えます。

Informixを扱える開発会社が見つからない場合はどうすればよいですか？

Informix本体や4GL・ESQL/C、クラウド、他DB移行のすべてに強い会社が見つからなければ、現行調査は専門会社に頼み、技術領域ごとに分けて発注できます。

候補の会社には、過去の版やOS、言語、移行、業務テストの経験を確かめます。提案担当者が本番まで参加するかも、あわせて聞いておきます。

Informixのシステム開発費はどのくらい見ておくべきですか？

小規模な接続確認やPoCなら0万円から100万円程度です。既存Informixを使う小規模Web・API化なら150万円から500万円程度が概算の目安です。

クラウド移行や旧資産の近代化は1,500万円から5,000万円程度、大規模な他DB移行は5,000万円から数億円になることがあります。

いずれもInformixの定価ではなく、規模や停止条件、移行範囲、ライセンス、保守によって変わります。そのため、現行調査の後に工程別の見積もりを取ります。

Informixをクラウドへ移行すれば費用は下がりますか？

クラウド移行だけで費用が下がるとは限りません。専用機器や保守人材への依存を減らせる一方で、VMやストレージ、バックアップの費用が発生します。さらに、監視や通信、冗長構成、ライセンスの費用も加わります。

月額だけでなく、障害リスクや保守性、版更新、将来の拡張まで含めた総保有コストで比べます。

RFPがない状態でもInformixの開発会社へ相談できますか？

相談できます。最初から本開発の確定見積もりを求めず、現行調査や要件整理を先に依頼する形で進められます。

Informixの版やOS、DBサイズ、利用業務、抱えている課題、停止可能時間、保有資料を整理しておくと、調査の提案を受けやすくなります。調査後に成果物と次工程の見積もりを受け取り、複数社で比べます。

まとめ：Informixのシステム発注は現行調査が出発点

発注前に、DB、4GLやESQL/Cなどのアプリ、バッチ、帳票、連携、運用の一覧を作ります。既存Informixの継続、クラウド移行、Linux・コンテナへの近代化、他DB移行を、費用だけでなく停止リスクと保守性で比べます。

最初に行う現行調査と発注範囲の決定

現行仕様が見えないまま本開発を固定価格で頼むと、追加費用や納期遅延が起こりやすくなります。短期間の調査とPoCで、Informixの版、アプリの依存関係、データ品質、停止条件、移行方式を確かめます。そのうえで、調査の成果物をもとに本開発の範囲を固めます。

前提条件と運用までを含む見積もりの比較

RFPには、現行環境や業務、非機能要件、移行対象、成果物、受入基準を記載します。社内作業と契約範囲も、あわせて書いておきます。調査・PoCは準委任、確定した開発は請負、継続改善はラボ型と使い分けます。

見積もりは工程、ライセンス、クラウド、移行、保守に分けます。現行解析から照合、切替、運用引き継ぎまで担える会社を選ぶと、追加費用と業務停止リスクを抑えやすくなります。

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

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