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

Informixのシステム開発を発注・外注するなら、既存環境を残すのか、クラウドへ移すのか、他のデータベースへ移行するのかを先に決め、現行資産の調査から契約・受入テストまでを一つの計画にまとめることが重要です。

Informixは、受発注・在庫・会計などの基幹業務を長年支えている一方、Informix-4GL、ESQL/C、古いVisual Basic、独自バッチ、帳票、バックアップ手順が属人化しやすいデータベースです。この記事では、Informixのシステムを外部の開発会社へ依頼する際の発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法を、2026年時点の製品動向と移行事例を踏まえて解説します。

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

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

Informixのシステム開発では、単に新しい画面を作るだけでなく、データベース、アプリケーション、OS、帳票、外部連携、運用をまとめて扱います。発注前に「何を作るか」だけでなく、「何を残し、何を変え、どこまでを委託するか」を決めると、提案内容と見積金額を比較しやすくなります。

最初に比較する選択肢は、(1)既存Informixを保守しながらアプリを改修する、(2)サーバーだけをクラウドへ移す、(3)Linuxやコンテナへ寄せて段階的にモダナイズする、(4)Oracle・SQL Server・PostgreSQLなどへリプレースする、の4つです。現行システムに問題がないのに全面刷新すると、業務仕様の再定義やデータ変換の費用が膨らみます。一方で、古いOSや特定担当者に依存している場合は、保守継続だけでは将来の障害対応が難しくなります。

判断材料には、Informixのバージョン、稼働OS、DBサイズ、同時接続数、ピーク時間帯、停止可能時間、RTO・RPO、保守担当者、ソースコードの有無を使います。たとえば停止できない受発注システムなら、移行先を先に決めるのではなく、レプリケーション、並行稼働、切戻し手順を含めて選びます。移行先の製品名だけで判断せず、業務を止めずに検証できるかを評価することが大切です。

外注範囲は、現行調査、要件定義、基本設計、詳細設計、アプリ開発、DB設計、データ移行、インフラ構築、テスト、教育、運用保守に分けて記載します。特に現行調査と移行設計を開発会社に任せるのか、社内で行うのかによって、初期見積もりは大きく変わります。社内側には、業務上の優先順位、受入基準、個人情報の取り扱い、リリース承認者を残すのが基本です。

「Informixに詳しい会社」という一言だけでは委託先を判断できません。Informix本体の設定に強い会社、4GLやESQL/Cのソース解析に強い会社、AWSなどへのクラウド移行に強い会社、他DBへの変換に強い会社は、それぞれ得意領域が異なります。RFPでは、必要な成果物と担当範囲を明示し、同じ条件で提案を受けられるようにします。

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

発注形態は、開発会社にすべてを任せるかどうかではなく、変動する部分と固定できる部分をどのように分担するかで選びます。Informixのように現行仕様が見えにくいシステムでは、最初から全工程を固定価格にするより、調査と要件定義を先行して不確実性を減らす方法が適しています。

画面一覧、機能仕様、移行対象、テスト条件、納期が固まっている部分は、請負契約による一括発注が候補になります。納品物と完成条件が明確であれば、発注側は予算と納期を管理しやすく、受託側も必要な体制を組みやすくなります。新しいAPIや定型的な帳票を追加するなど、対象範囲が限定できる開発に向いています。

ただし、旧4GLの挙動解析、文字コードの確認、帳票の印字差異、実データを使った移行検証などは、着手前にすべての工数を確定できない場合があります。未確定の作業まで請負契約に含めると、追加費用の交渉や品質低下につながります。請負にする場合は、前提条件、対象外、変更管理、検収方法を契約書と仕様書に書き分けます。

現行調査、アーキテクチャ検討、移行可否の判断、性能検証は、準委任契約や時間・工数を基準にするラボ型が使いやすい領域です。発注側は、調査期間を2週間から2か月程度などに区切り、DB定義一覧、プログラム依存関係、移行課題一覧、PoC結果、次工程の見積もりを成果物として受け取ります。調査を有償にすると、開発会社も経験者を配置しやすくなります。

PoCでは、匿名化した実データを使って接続、SQL、文字コード、日付、NULL、DECIMAL、BLOB、トランザクション、ロック、帳票、ピーク時の性能を確認します。AIや自動変換ツールを使う場合も、変換後のSQLと業務結果を人が照合する必要があります。PoCで不明点を洗い出してから本開発を請負に切り替えると、見積もりの精度を上げられます。

InformixのDB保守会社、クラウド基盤会社、アプリ開発会社を分ける発注も可能ですが、障害時の責任分界を明確にしなければなりません。たとえばAPIの応答が遅いとき、DBのSQLチューニングが原因なのか、クラウドのI/Oなのか、アプリの接続プールなのかを切り分ける必要があります。契約前に、監視項目、ログの共有方法、一次窓口、二次対応、復旧目標を決めます。

一社にまとめる場合は窓口と責任が一本化されますが、特定ベンダーへの依存が強まるおそれがあります。分離発注の場合は専門性を組み合わせやすい反面、全体設計を統括する社内PMまたはプライムベンダーが必要です。社内にPMを置けない場合は、要件定義と全体テストだけを統括会社へ依頼する方法も検討できます。

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

RFPは、開発会社に希望を伝えるだけの文書ではなく、各社から同じ前提の提案と見積もりを受けるための比較基準です。Informixでは仕様書だけに頼ると、実際には使われているバッチや手作業、例外処理が漏れやすいため、運用担当者へのヒアリングとログ確認を組み合わせます。

現行環境には、Informixの製品名とバージョン、CSDKやJDBCなどのクライアント、OS、サーバー構成、DBサイズ、表数、バックアップ方式、HA・DR構成、接続元、同時接続数、ジョブの実行時間を記載します。アプリ側には、Informix-4GL、ESQL/C、C、Visual Basic、Java、.NETなどの言語、ソースコードの保管場所、コンパイル手順、外部DLL、帳票エンジンを含めます。

業務要件は、「在庫を管理する」のような抽象表現で終わらせず、締め処理の時刻、同時に処理する件数、許容される在庫差異、再処理の方法、担当者の承認、休日運用まで書きます。画面や帳票の一覧に加えて、夜間バッチ、手作業で補正しているデータ、障害時に電話で確認している業務も対象にします。現場だけが知っている例外処理こそ、移行後の障害原因になりやすい部分です。

非機能要件には、可用性、性能、セキュリティ、バックアップ、障害復旧、監査、運用保守を含めます。たとえば「速く表示する」ではなく、通常時とピーク時の応答時間、1時間あたりの処理件数、同時接続数、月間停止許容時間を指定します。RTOは障害から復旧までの目標時間、RPOはどの時点までのデータを復元できる必要があるかを意味します。

個人情報や取引情報を扱う場合は、権限管理、操作ログ、通信の暗号化、バックアップの暗号化、委託先の再委託、データ持ち出し、削除方法を要件に入れます。Informix 15.0では、クラウドバックアップやKubernetesへのHelm Chart展開などの選択肢がありますが、機能があることと、自社の運用要件を満たせることは別です。HCL公式ドキュメントでもAmazon S3へのバックアップには利用料金や契約条件があると説明されているため、クラウド費用を見積もりに含めます。

出典として、HCL Informix 15.0の公式ドキュメントでは、15.0.0でクラウドバックアップの強化とHelm Chart展開が追加されたこと、15.0.1系でライセンス、JDBC、wire listenerの変更が案内されています。詳しくはHCL Informix 15.0の新機能を確認してください。発注時は、現行バージョンからのアップグレードで再コンパイルが必要になる機能があるかを、採用するクライアントライブラリ単位で確認します。

成果物は、要件定義書、現行資産一覧、基本設計書、DB定義書、移行設計書、テスト計画書、テスト結果、運用手順書、ソースコード、ビルド手順、教育資料、障害時の連絡網に分けて記載します。受入基準は、画面が表示されるかだけでなく、受注から出荷、請求、締め処理までの業務シナリオを端から端まで確認できるようにします。

移行案件では、件数一致だけでは不十分です。残高、在庫、金額、日付、文字化け、桁あふれ、関連キー、帳票の合計値を旧システムと照合し、差異が出た場合の判定責任者を決めます。データの移行対象外を明示し、対象外にした理由と保管期間も成果物として残します。

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

契約形態は、発注側が負う不確実性と、受託側が負う完成責任のバランスを決めるものです。Informixのシステムでは、現行調査から本番切替までを一つの契約に詰め込まず、調査・要件定義、設計・開発、移行・切替、保守の節目で契約と予算を分けると管理しやすくなります。

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

契約書には、成果物の権利帰属、OSSや変換ツールのライセンス、秘密保持、再委託、個人情報、脆弱性対応、損害賠償の範囲、検収期間、瑕疵対応、契約終了時の引き継ぎを記載します。Informixの保守では、古いミドルウェアや特定の開発ツールが残ることがあるため、納品後に発注側が再構築できるかを確認します。

最初のゲートは現行調査の完了です。DBとアプリの依存関係、移行対象、停止条件、リスクが一覧になっていなければ、本開発の固定見積もりへ進めません。次のゲートはPoCと基本設計の完了で、性能、データ整合性、切替方式、運用監視が確認できた時点で本番開発を承認します。

切替前には、総合テスト、ユーザー受入テスト、移行リハーサル、バックアップからの復元テスト、障害訓練を行います。切替当日に問題が出た場合の判断を担当者の経験に委ねず、何分以内に復旧しなければ旧環境へ戻すか、どのデータを再連携するかを決めます。Claranetが2026年5月に公開したInformix移行事例でも、Solaris・SPARCからUbuntu Linux・AWSへ移し、12.10から14.10へ更新しながら、Enterprise Replication、監視、ロールバックの選択肢を組み合わせています。

この事例は自社案件の金額や期間を示すものではありませんが、サーバー移設だけではなく、データベースのバージョン、複製、監視、運用手順を一体で設計する必要があることを示しています。詳細はClaranetのInformix移行事例で確認できます。RFPには、自社で必要な範囲を「必須」「できれば」「将来検討」に分けて記載します。

開発が終わった後に、誰がInformixのパラメータを管理し、誰がバックアップを確認し、誰が障害時の一次対応をするのかを決めます。保守契約には、問い合わせの受付時間、障害の重要度、初動時間、復旧目標、定期点検、パッチ適用、バージョンアップ、SQLチューニング、月次報告を分けて記載します。

引き継ぎでは、運用手順書を納品して終わりにせず、発注側の担当者がバックアップ復元、ユーザー追加、ログ確認、ジョブ再実行、障害連絡を実際に行います。属人化を解消するため、ソースコードだけでなく、環境構築手順、設定値、監視閾値、データ修正の承認手順、問い合わせ履歴を残します。

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

Informixのシステム開発費は、DBのライセンス、開発規模、旧資産の解析、データ移行、停止時間の短縮、クラウド基盤、保守体制で大きく変わります。Informix製品の商用ライセンスには、エディション、コア数、OS、環境数、サポート契約などの条件があるため、公開情報だけで一律の価格を断定できません。以下は業務システム全般の相場と、Informixの移行・連携で発生しやすい工程を組み合わせた概算です。

接続確認や小規模PoCであれば、環境構築、接続、数本のSQL、性能確認を含めて、概算0万円から100万円程度、期間は2週間から2か月程度が一つの目安です。無償版や開発者向けエディションが利用できる場合でも、利用条件と本番ライセンスは別に確認します。

既存Informixを使った小規模なWeb・API化は、150万円から500万円程度、1か月から3か月程度が概算のレンジです。受発注や在庫など中小規模の業務システム連携は、500万円から1,500万円程度、3か月から6か月程度が目安になります。要件定義、画面やAPI、マスタ移行、外部連携、教育を含むかで変動します。

4GLや旧Visual Basicを残した段階的モダナイズ、クラウド移行、HA・DR構築を含む場合は、1,500万円から5,000万円程度、6か月から18か月程度のレンジで検討します。大規模な基幹刷新や他DBへのリプレースは、5,000万円から数億円、1年から3年程度になることがあります。これらはInformix固有の定価や特定企業の実績ではなく、要件が未確定な段階での業務システムの概算です（出典: NotebookLM「業務システム全般_10」、2026年作成のリサーチノート）。

見積書では、現行調査、要件定義、設計、アプリ改修、DB改修、データ移行、インフラ、テスト、教育、切替支援を分けます。さらにInformixのライセンス、OSやクラウドVM、ストレージ、バックアップ、監視、ネットワーク、証明書、外部サービスを初期費用と月額費用に分けます。工数だけを比較すると、ある会社が含めている移行や保守が、別の会社では別見積もりになっていることがあります。

ランニングコストには、クラウド利用料、商用ライセンスとサポート、監視、バックアップ保管、通信、障害対応、定期パッチ、OSやミドルウェアの更新が含まれます。業務システム全般では、年間保守を初期開発費の10%から20%程度で見ることがありますが、24時間監視、休日対応、バージョンアップ、現地対応を含むかで変わります（出典: NotebookLM「業務システム全般_10」、2026年作成のリサーチノート）。この割合をInformixの確定価格と見なさず、サービスレベルごとに提示してもらいます。

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のシステム開発会社と委託先の選び方

委託先を選ぶときは、Informixの経験年数や会社規模だけでなく、自社と似た構成を最後まで支援できるかを見ます。4GLのソース解析、SQLチューニング、データ移行、クラウド設計、業務テスト、運用引き継ぎのどこまでを自社で担当するのかを確認します。

提案会社には、過去の案件でどのバージョン、OS、開発言語、データ量、停止条件を扱ったかを確認します。守秘義務で顧客名を出せない場合でも、現行解析の手順、移行前後の照合方法、テスト件数、切替方式、障害対応の体制は説明できるはずです。実績紹介の文章だけでなく、サンプルの移行計画書、テスト計画書、運用設計書の目次を見せてもらうと、提案の具体性を判断できます。

「Informixに対応可能」という回答には、どの作業を指すのかを聞き返します。DBのインストールだけなのか、4GLやESQL/Cの修正までできるのか、古いコードを再コンパイルできるのか、OracleやSQL Serverへの変換後の業務テストまでできるのかで、必要な会社は変わります。経験者が提案段階だけ参加し、開発や保守は別チームになる場合もあるため、担当者の役割と稼働期間を確認します。

候補会社には、まず現行調査の進め方を質問します。どの資料を受け取り、どのログやソースを確認し、何週間でどの成果物を出すのかを聞きます。次に、データ移行のサンプル、文字コードや日付の扱い、性能試験、バックアップ復元、切替と切戻し、障害時の連絡体制を確認します。

さらに、提案会社が想定する発注側の作業を確認します。業務ヒアリングへの参加者、データの匿名化、テストデータの準備、受入担当者、夜間切替の立ち会い、運用教育の時間を誰が負担するのかを聞きます。発注側の作業が見積もりに含まれていないと、社内の実負担や納期が想定を超える可能性があります。

見積比較では、合計金額の安さだけで決めません。現行調査が含まれているか、移行対象と対象外が書かれているか、ライセンスとクラウド費用が何年分か、テストと切替が何回分か、保守の受付時間が何時から何時までかをそろえます。極端に安い提案は、要件定義、データ照合、教育、障害対応が別料金になっている場合があります。

比較表を作る場合は、工程、成果物、想定工数、単価、外部費用、前提、対象外、発注側の作業、納期、リスクを同じ列にします。評価点は価格だけでなく、Informixの技術適合性、業務理解、移行品質、体制、保守性、セキュリティ、引き継ぎで分けます。提案会社に評価表を共有して、金額ではなく条件の違いを説明してもらうと、後からの追加請求を減らせます。

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

Informixのシステム開発で大きな失敗につながるのは、技術選択そのものより、移行対象の漏れ、テスト不足、切替計画の不在、運用責任の曖昧さです。セキュリティもデータベースだけを見るのではなく、アプリ、接続ドライバ、REST、OS、ネットワーク、バックアップまで含めて確認します。

他DBへ移行する場合、表と列を変換するだけでは終わりません。Informix固有のSQL、外部キー、トランザクション、ロック、日付や数値の型、ストアドプロシージャ、ユーザー権限、バッチ、帳票、アプリのエラー処理が変わる可能性があります。変換ツールを使う場合も、自動変換率を品質の根拠にせず、業務シナリオの実行結果で判定します。

クラウド移行では、サーバーのスペックだけでなく、ストレージ性能、バックアップ時間、通信経路、監視、可用性ゾーン、障害時の復旧、ライセンスの持ち込み条件を確認します。HCLの公式情報では、S3へON-BarとPrimary Storage Managerでバックアップできますが、S3の利用料金や契約条件は利用者側の責任です。クラウドの月額は、平常時だけでなくバックアップ世代数と復元時の通信も含めて試算します。

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

REST APIを追加する場合は、TLS、認証、権限、CSRF対策、セッション、接続プール、監査ログ、ネットワーク制限を要件にします。データベースのポートをインターネットへ直接公開せず、APIの入力値検証と最小権限を設計します。個人情報を扱う場合は、開発・検証環境のデータを匿名化し、委託先の作業端末への保存期限と削除証跡も確認します。

Informix 15.0.1.13以降ではwire listenerの認証がデフォルトで有効になる変更が案内されています。バージョンアップで接続できなくなることを防ぐため、アプリとクライアントの認証設定を検証環境で確認します。新機能を採用しない場合でも、現在の設定が将来のバージョンでどう変わるかを保守会社へ確認します。

セキュリティ要件は「安全にする」と書くだけでは受入判定ができません。通信はTLS、管理者は多要素認証、権限は職務単位、ログは一定期間保管、バックアップは暗号化、脆弱性は月次確認というように、設定と確認方法まで決めます。適用法令はInformixという製品名ではなく、個人情報、会計、医療、製造など扱うデータと業務によって変わるため、必要に応じて法務・監査部門もRFP作成に参加させます。

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

Informixのシステムを発注する際は、開発会社の技術力だけでなく、現行資産と業務の不確実性をどこまで減らせるかが重要です。ここでは、発注前に特に相談されやすい質問へ回答します。

Informix本体、4GLやESQL/C、クラウド、他DB移行のすべてに強い会社が見つからない場合は、現行調査を専門会社へ依頼し、必要な技術領域を分けて発注する方法があります。候補会社には、過去のバージョン、OS、言語、データ移行、業務テストの経験を確認し、提案段階の担当者が本番まで参加するかを聞きます。

小規模な接続確認やPoCなら0万円から100万円程度、既存Informixを使った小規模なWeb・API化なら150万円から500万円程度が概算の目安です。クラウド移行や旧資産のモダナイズは1,500万円から5,000万円程度、大規模な他DB移行は5,000万円から数億円になることがあります。いずれもInformixの定価ではなく、規模、停止条件、移行範囲、ライセンス、保守によって変わるため、現行調査後に工程別見積もりを取得します。

クラウド移行だけで自動的に費用が下がるとは限りません。古い専用ハードウェアや保守人材への依存を減らせる一方、クラウドVM、ストレージ、バックアップ、監視、通信、冗長構成、ライセンスが新たに発生します。移行前後の月額だけでなく、障害リスク、保守性、バージョン更新、将来の拡張を含む総保有コストで比較します。

相談できますが、最初から本開発の確定見積もりを求めるのではなく、現行調査や要件整理を先行して依頼するのが安全です。Informixのバージョン、OS、DBサイズ、利用業務、困っていること、停止可能時間、保有資料だけでも整理すると、調査の提案を受けやすくなります。調査後に成果物と次工程の見積もりを受け取り、複数社で比較します。

まとめ：Informixのシステム発注は現行調査から始めます

Informixのシステム開発を発注・外注するときは、いきなり開発会社を決めるのではなく、現行のDB、4GLやESQL/Cなどのアプリ、バッチ、帳票、連携、運用を棚卸しします。そのうえで、既存Informixを使い続けるのか、クラウドへ移すのか、Linux・コンテナへモダナイズするのか、他DBへリプレースするのかを、費用だけでなく停止リスクと保守性で比較します。

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

RFPには、現行環境、業務範囲、非機能要件、移行対象、成果物、受入基準、発注側の作業、契約範囲を記載します。調査とPoCは準委任、要件が固まった開発は請負、継続的な改善はラボ型というように契約を使い分け、見積書は工程、ライセンス、クラウド、移行、保守を分けて比較します。Informixの経験だけでなく、現行解析からデータ照合、切替、運用引き継ぎまでを担当できる会社を選ぶことが、発注後の追加費用と業務停止リスクを抑える近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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