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

GeneXusのシステム開発を発注・外注するなら、ローコードだから安いと決めつけず、業務整理からデータ移行、連携、テスト、保守までを含めた総額と責任分担で委託先を選ぶことが重要です。

本記事では、GeneXusのシステム開発を外部へ依頼する際の発注形態、RFPと要件のまとめ方、契約形態、2026年時点の費用相場、委託先の選び方、見積書の比較ポイントを実務の順番に沿って解説します。既存のAS/400やC/Sシステムを刷新したい企業、社内にGeneXusの経験者が少ない企業が、提案依頼から稼働後の引き継ぎまで準備できる内容です。

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

GeneXusのシステムを発注・外注する前に知っておきたい全体像

GeneXusは、完成済みの業務パッケージを設定する製品ではなく、業務データやルールをナレッジベースに定義し、データベースとアプリケーションを自動生成する開発プラットフォームです。そのため、発注の成否はツールの操作スキルだけでなく、現行業務を正しくモデル化し、生成後のコード、データ、運用まで管理できる体制に左右されます。

販売管理、在庫管理、生産管理、物流、金融、自治体など、企業ごとの差が大きい業務を対象にする場合、GeneXusはパッケージとフルスクラッチの中間に位置する選択肢になります。画面や帳票を一つずつ手書きするだけでなく、項目、トランザクション、業務ルールを定義して複数の画面や処理へ反映できるため、将来の技術基盤変更や機能追加をモデル中心に進めやすい点が特徴です。

一方で、要件が曖昧なまま発注すると、曖昧な業務ルールや例外処理まで自動的に正しくなるわけではありません。生成先をJava、.NET、Angular、モバイルのどれにするか、既存データベースをどう移行するか、外部APIを何本つなぐかによって、工数と見積金額は大きく変わります。

外注を検討する理由は、単純な人手不足だけではありません。GeneXus固有の設計、レガシー資産のリバースエンジニアリング、GAMによる認証・認可、GXtestなどを使ったテスト、クラウドや監視の設計を一度に経験できる会社へ、失敗しやすい工程を任せることに意味があります。特に基幹システムでは、発注先が作業を完了することより、社内担当者が将来の変更を説明できる状態を作ることが重要です。

2026年の企業IT動向では、IT予算の増加理由として既存システムの更新や値上げなどの不可避的要因が大きく、複雑な開発で品質・コスト・納期を守るために内製と外部委託を使い分ける動きが示されています（出典: 一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2026」、回答企業957社）。GeneXusの発注でも、上流の業務判断は自社が握り、専門性が必要な実装や移行を外注する分担が現実的です。

発注形態はどれが適していますか？

発注形態は、要件の確定度と変更の多さで選びます。要件が固まった部分を成果物単位で委託するなら請負、現場と対話しながら優先順位を変えるなら準委任やアジャイル型、将来の内製化を重視するなら伴走型の混成が適しています。最初から全工程を一つの契約に押し込めると、変更時の責任と追加費用が不明確になりやすいです。

請負契約では、委託先が合意した成果物を完成させ、発注者が検査して対価を支払う形が基本です。画面一覧、帳票、API仕様、移行対象、性能基準などを確定できる小規模な業務システムや、要件定義後の開発・テスト工程に向いています。見積の「一式」に含まれる作業を、機能、画面、帳票、連携、環境構築、テスト証跡という単位で分解しておくと、完成の認識をそろえやすいです。

ただし、業務を使ってみてから要件が固まるGeneXus案件で、全期間を固定価格にするのは危険です。検収条件にない追加画面や例外処理が発生すると、変更契約の交渉が増え、納期を優先するために品質を下げるおそれがあります。請負にする範囲と、別契約で柔軟に扱う範囲を分ける考え方が安全です。

準委任では、決められた期間に専門人材が業務を支援し、成果物の完成を一律に保証するのではなく、合意した作業を遂行します。現場ヒアリング、業務モデルの改善、プロトタイプ、短いイテレーションでのリリースなど、発注者と委託先が一緒に判断する工程に適しています。GeneXusは画面を動かしながら業務ルールを見直しやすいため、最初の要件定義やPoCを準委任で進める方法も有効です。

この形態では、月ごとの稼働時間だけでなく、スプリントの目的、レビュー参加者、作業報告、決定事項、成果物の保管場所を明記します。委託先に任せきりにして稼働時間だけが積み上がる事態を防ぐため、業務担当者が毎週確認する受け入れ条件や、次の期間へ持ち越す課題を合意しておくことが重要です。

外注しながら社内に知識を残したい場合は、企画・業務優先順位・受け入れ判断を自社が担当し、GeneXusのモデル設計、生成、移行、テスト自動化を委託先と共同で進めます。社内担当者をレビュー、環境構築、障害対応に参加させ、ナレッジベース、ソースコード、設計書、テストケースを共有すると、将来の別会社への切り替えや一部内製化に備えられます。

GeneXus公式の導入事例でも、少人数の内製化、既存システムのオープン化、アジャイル開発、テスト自動化など、外部パートナーの支援を受けながら社内の運用力を高める例が紹介されています。発注時に「納品後は保守契約を継続する」だけで終わらせず、何人を何か月教育するか、社内でどの問い合わせまで対応するかを見積項目に含めると、外注依存を管理しやすくなります。

RFPと要件整理はどこまで準備しますか？

RFPは、製品名や画面数だけを並べる書類ではありません。なぜ刷新するのか、どの業務をいつまでに、どの品質で使えるようにするのかを委託先へ同じ条件で伝える資料です。候補会社から比較可能な提案を得るには、少なくとも現行業務、対象範囲、データ、連携、非機能、体制、納期、予算の考え方を一つの資料にまとめます。

最初に、現行システムの機能一覧、利用部門、利用者数、ピーク時間、帳票、バッチ、マスタ、外部連携、障害履歴を整理します。AS/400、メインフレーム、古いC/Sシステムからの刷新では、画面を再現するだけではなく、現場が手作業で補っている例外処理や、担当者しか知らない締め処理を聞き取ることが欠かせません。

移行対象データは、件数、保持期間、欠損や重複の有無、コード体系、移行後の参照方法まで確認します。既存データベースをそのまま使うのか、新しいモデルに変換するのかで、GeneXusの設計とテストの工数が変わります。RFPには「データ移行は委託先が実施する」とだけ書かず、クレンジング、変換、照合、リハーサル、本番切り替えの責任者を分けて記載します。

機能要件には、登録・検索・更新・承認・取消・締め・権限・通知・帳票という業務の流れを記載します。正常系だけでなく、返品、分納、赤伝、在庫不足、承認者不在、連携先停止など、現場で実際に起きる例外を挙げることが大切です。GeneXusは業務知識をモデルに反映するほど効果を発揮するため、例外を後回しにすると、後工程でのモデル変更と再テストが増えやすくなります。

生成対象もRFPに明記します。Webだけでなくモバイルが必要か、Javaと.NETのどちらを採用するか、Angularを使うか、データベースやクラウドを何にするかを候補会社へ確認します。GAMによる認証・認可、監査ログ、API、帳票、バッチ、外部認証との連携などの周辺要件を落とすと、見積の後半で追加費用になりやすいです。

非機能要件には、同時利用者数、応答時間、処理件数、稼働時間、障害時の復旧目標、バックアップ世代、監視、ログ保存期間、アクセス権限、個人情報の扱いを入れます。金融、人事、販売などの個人情報を扱う場合は、委託先の再委託、クラウドの保存場所、管理者権限、ログの閲覧者、退職者のアカウント停止手順まで確認します。

2026年のJUAS調査では、DX推進課題の上位に人材・スキル不足が挙げられ、レガシーシステムや情報漏えいへの懸念も確認されています（出典: 一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2026」）。外注するから安全になるのではなく、発注者がアクセス権限とリスクを把握し、委託先がどの証跡を残すかを要件にすることが必要です。

GeneXusのシステム開発はどの契約形態で委託しますか？

契約書では、契約の名称だけでなく、何を納品し、誰が判断し、どの条件で受け入れ、変更時にどう精算するかを具体化します。要件定義、PoC、開発、移行、教育、保守を工程ごとに分け、固定価格で確定できる部分と、作業量を調整する部分を切り分けると、GeneXus案件の不確実性に対応しやすくなります。

要件定義では業務フロー、機能一覧、データモデル、非機能要件、移行方針、RFP更新版を成果物にします。開発ではナレッジベース、生成物、設定、ソースコード、画面・帳票、API、テスト仕様書と結果を対象にします。リリースでは手順書、教育資料、運用設計、障害時の連絡網を含めます。成果物のファイル形式、保管先、更新期限、レビュー回数を決めると、納品後の「聞いていたものと違う」を減らせます。

受け入れは、画面が表示されることだけでなく、業務シナリオを最後まで完了できることを基準にします。たとえば受注から出荷、請求、返品までの一連の業務を代表ケースと例外ケースに分け、テストデータと期待結果を合意しておきます。性能、権限、監査ログ、外部連携停止時の復旧など、非機能要件の検査方法も検収条件へ含めます。

GeneXusでは、生成されたプログラムだけでなく、業務知識が記録されたナレッジベースが将来の変更に関わります。契約前に、ナレッジベースを誰が所有・利用できるか、開発環境のライセンスを誰が持つか、生成物やソースコードを発注者が取得できるか、別会社が保守できるかを確認します。委託先だけが開ける場所に資産を置くと、契約終了時の移管が難しくなります。

再委託がある場合は、再委託先の会社名、担当工程、アクセスするデータ、秘密保持、監査方法、事故時の連絡責任を把握します。個人情報保護委員会のガイドラインでも、委託元が委託先の取扱状況を把握し、必要な監督を行う考え方が示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」）。契約書と実際の運用が一致するよう、権限一覧とデータフローを添付する方法が有効です。

保守費用を毎月支払うだけでは、期待する支援を受けられません。障害の重要度ごとの受付時間、一次回答と復旧の目標、休日対応、問い合わせ回数、軽微な改修の範囲、法改正対応、脆弱性対応、OS・データベース・GeneXusのアップグレード責任を明記します。クラウドを使う場合は、インフラ障害とアプリケーション障害の切り分けも決めます。

運用開始後に別会社へ切り替える可能性があるなら、移管期間、資料の更新義務、アカウント返却、バックアップの引き渡し、未解決課題の一覧化を契約に入れます。特定ベンダーへの依存を避けるには、契約終了時の出口を先に決めておくことが最も効果的です。

GeneXusのシステム開発の費用相場はいくらですか？

GeneXusの日本向けライセンス価格は、利用形態や開発体制などによって変わり、公開ページに一律の定価として示されているわけではありません。そのため、以下の金額はGeneXus専用の公示価格ではなく、2026年に公開された国内の業務システム開発相場と、GeneXusの導入事例で示された生産性向上の情報を踏まえた、発注予算を考えるための目安です。実際の見積では、ライセンス、開発、移行、基盤、保守を分けて確認します。

PoCや部門内の小さな業務アプリなら、対象業務を絞った検証として100万〜300万円程度、簡易な申請・日報・在庫などの小規模システムなら300万〜800万円程度が一つの目安です。複数部門、既存データ移行、外部API、権限、帳票を含む中規模の業務統合では800万〜3,000万円程度、全社基幹やレガシー刷新では3,000万円〜1.5億円以上になる場合があります。期間は、PoCで1〜2か月、小規模で2〜6か月、中規模で6〜12か月、大規模で12〜24か月以上を見込む考え方です。

このレンジは、2026年公開の業務システム相場情報で示されている小規模100万〜300万円、中規模300万〜800万円、中・大規模800万円以上という幅と整合するよう整理しています（出典: ノーコード総合研究所「業務システム開発の費用相場｜規模別の目安・内訳とコストを抑える方法 2026年最新」、SIA株式会社「システム開発の費用・相場 2026年版」）。GeneXusを使えば必ずこの下限になるわけではなく、業務の複雑さ、連携数、移行難易度、品質要求で上限側へ動きます。

予算の仮置きでは、要件定義・業務整理を10〜15%、モデル設計と画面・処理の開発を35〜45%、連携・データ移行・テストを25〜35%、教育・リリース・予備費を10〜20%程度に分けると、抜け漏れを確認しやすくなります。これは特定案件の標準配分ではなく、見積を分解するための確認用レンジです。会社ごとに工程の定義が違うため、割合だけで優劣を決めず、各金額に含まれる作業を確認します。

特に忘れやすいのが、ライセンス、開発・チーム管理環境、GAM、GXtest、監査ログ製品、クラウド、監視、バックアップ、脆弱性診断、データ移行リハーサル、操作教育です。GeneXus公式の導入案内では、導入企業の中に開発コストを40%以上削減した事例があると紹介されていますが、これは全案件に適用される割引率ではありません（出典: GeneXus公式「はじめての方へ」）。削減効果を期待するなら、PoCでモデル化の速度、再利用、テスト工数、教育負担を自社業務で実測します。

運用費は、アプリケーション保守、インフラ、監視、バックアップ、問い合わせ、障害対応、法改正、バージョンアップに分けます。一般的な業務システムでは初期開発費の年15〜25%程度を保守の予算目安に置くことがありますが、GeneXusのライセンスや周辺製品、クラウド構成、SLAによって変わるため、固定的な相場として断定できません。見積書では初年度だけでなく、2年目以降の年間費用と更新条件を確認します。

利用者数だけで月額を比べると、開発者ライセンスや実行環境、データ量、監視要件を見落とします。GeneXus公式のPlans and Pricingでも、スターター、ISV、エンタープライズなど利用目的に応じたプランが案内されています。自社の利用人数、開発者数、生成先、環境数、本番・検証の分離を伝え、ライセンス見積と開発見積を別々に受け取ると、価格の根拠を追いやすくなります。

委託先の選定と見積比較は何を見ればよいですか？

委託先は、GeneXusを使えるかだけでなく、自社と似た業務、規模、移行難易度、運用環境を経験しているかで選びます。公式パートナー一覧や公式導入事例は候補を探す入口になりますが、掲載実績が自社案件の成功を保証するものではありません。提案内容を同じRFPで比較し、担当者の経験と契約後の体制を確認します。

候補会社には、GeneXusのバージョン、生成先、データベース、周辺製品、担当した工程、稼働後の保守年数を聞きます。AS/400やメインフレームからの刷新なら、現行資産の解析と段階移行の経験を、金融や人事なら、権限、監査ログ、個人情報、障害時の証跡を確認します。外部APIやモバイルを含むなら、実機テスト、通信障害、認証連携、アプリ配布まで提案できるかを見ます。

公式導入事例には、ペット保険の基幹刷新で年間2,800時間の業務工数を削減し、スマートフォンから加入できる機能を約4か月でリリースした例や、りそなホールディングスの事例でGXtestによるテスト自動化により期間・コストを25%最適化した例があります（出典: GeneXus公式「導入事例」）。ただし、成果数値は案件固有の条件で生まれたものです。候補会社には数値だけでなく、自社案件で再現する条件と、再現できないリスクを説明してもらいます。

見積書を並べるときは、総額の安い順に並べるのではなく、対象機能、画面・帳票数、API本数、移行データ量、テスト範囲、教育回数、稼働後の支援をそろえます。「要件定義一式」「開発一式」「移行一式」のような表記は、内訳と前提が別紙にあるか確認します。安い見積が、移行や性能試験を含めていないだけということもあります。

比較表には、初期費用、ライセンス、クラウド、保守、追加変更単価、納期、体制、再委託、引き渡し資産、契約終了時の移管費を記載します。見積条件として、発注者が準備するデータや業務担当者の稼働、検収の遅れ、既存システムの仕様不明部分も明示します。候補会社からリスクと予備費の考え方を聞ける提案ほど、後からの追加請求を管理しやすいです。

候補会社を絞れないときは、重要業務を一つ選び、2〜8週間程度のPoCを依頼します。検証するのは画面が早くできるかだけではありません。現行データをどの程度モデル化できるか、複雑な例外を表現できるか、想定ピークで応答できるか、外部APIがつながるか、権限と監査ログを確認できるか、社内担当者が変更できるかを見ます。

PoCの成果物には、試作画面、ナレッジベースの構成、採用した生成先、データ移行の課題、テスト結果、残課題、本番化した場合の見積条件を含めます。PoC後に本契約を結ぶ場合も、評価基準と本番移行の判断者を先に決めます。GeneXusの価値は短期間の生成だけでなく、業務変更を継続的に反映できることにあるため、引き継ぎと保守の再現性まで評価することが重要です。

よくある質問

GeneXusのシステム開発を発注するときに、担当者が迷いやすい点をまとめます。費用を下げることだけでなく、要件変更、ライセンス、保守、引き継ぎに関する不安を事前に解消する視点で回答します。

必ず安くなるとはいえません。業務モデルの再利用、標準化、テスト自動化、内製化によって初期開発や将来改修の負担を下げられる可能性がありますが、複雑な移行、外部連携、厳しい性能・監査要件があれば費用は増えます。ライセンスと開発、保守を含む総所有コストで比較し、PoCで自社業務における効果を確かめることが適切です。

発注できます。最初からGeneXusの内部仕様を書く必要はなく、現行業務、解決したい課題、対象範囲、利用者、データ、連携、納期、セキュリティ、運用体制を整理すれば、候補会社から技術提案を受けられます。生成先や周辺製品は候補会社に提案を求めつつ、ナレッジベースやソースコードの引き渡し、将来の保守体制は発注者側の条件として明記します。

比較可能な提案を得るには、同じRFPを3〜5社程度へ渡す方法が現実的です。社数を増やしすぎると質疑応答と評価の負担が大きくなるため、公式パートナー実績、同業の経験、移行・保守体制、契約条件で候補を絞ります。最終的には価格だけでなく、前提条件、リスク、担当者、引き継ぎ、稼働後の責任を含めて評価します。

契約と資産管理を適切に設計すれば移管できます。ナレッジベース、生成物、ソースコード、設計書、テストケース、環境構成、アカウント、障害履歴を発注者が取得できる契約にし、定期的にバックアップと資料更新を行います。さらに、別会社が保守できる構成か、ライセンスの名義や利用権が移管を妨げないかを契約前に確認することが重要です。

まとめ

GeneXusのシステム開発を発注・外注するときは、ローコードの導入効果だけで委託先を決めず、業務モデル、既存データ、生成先、外部連携、権限、テスト、保守、引き継ぎまで含めて計画します。要件が固まった工程は請負、変更が多い工程は準委任やアジャイル、将来の内製化を重視する工程は伴走型というように、契約を使い分けることがポイントです。

費用はPoCで100万〜300万円程度、小規模で300万〜800万円程度、中規模で800万〜3,000万円程度、大規模では3,000万円〜1.5億円以上というレンジを参考にできます。ただし、これは一般的な業務システム相場を基準にした目安で、GeneXusのライセンスや周辺製品を含む個別見積ではありません。候補会社には同じRFPを渡し、機能、移行、テスト、教育、保守、除外項目、追加変更の条件をそろえて比較します。

まずは、刷新効果が大きく、現場担当者が参加できる一つの業務を選び、現行業務とデータを棚卸しします。そのうえで、2〜8週間程度のPoCにおける検証項目、成果物、社内の判断者を決め、複数社へ同じ条件で提案を依頼します。納品後に自社や別会社が運用できるよう、ナレッジベース、ソースコード、設計書、テスト証跡、ライセンス、保守の出口まで契約に含めれば、GeneXusを長く使える発注になります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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