GeneXusのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

GeneXusのシステム開発は、業務の項目・画面・ルールをナレッジベースに整理し、データベースやアプリケーションを生成しながら段階的に稼働させる進め方が基本です。

「ローコードだから短期間・低価格で作れる」と考えて、いきなり画面を作り始めると、既存データの扱い、例外業務、外部連携、権限、テストの抜けが後から費用と遅延として表れます。本記事では、GeneXusのシステム開発を要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分け、各段階で決めること、確認する成果物、見積もりで確認すべきポイントを実務向けに解説します。

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

GeneXusのシステム開発の全体像

GeneXusは、既製の業務画面を設定するだけのSaaSではありません。ユーザービューと呼ばれる業務上の項目、伝票、画面、ルールを入力し、そこからデータベースとアプリケーションを推論・生成する「ソフトウェアを作るソフトウェア」です。したがって、成功の鍵は生成操作の速さだけでなく、現場の知識を矛盾なくモデル化し、変更をナレッジベースへ戻せる体制にあります。

まず、顧客、商品、受注、在庫、担当者のような業務上の対象を定義し、項目や関係、登録・更新のルールを整理します。GeneXusは入力された情報を基にテーブルや画面、処理を生成します。公式の製品説明でも、業務内容を記述してデータベースとプログラムを自動生成し、Webやモバイルなどへ展開できる仕組みと説明されています（出典: GeneXus公式「GeneXus」概要、2026年8月確認）。

この方式では、画面数だけを数えて要件を決めると不十分です。たとえば受注画面が10画面でも、締め処理、返品、分納、在庫引当、権限別の承認、会計連携が加われば、業務ルールとテストケースは大きく増えます。初期段階で「誰が、どのデータを、どの条件で、どの順番に処理するか」を決めることが、後工程の手戻りを抑えるポイントです。

GeneXusが向くのは、販売、在庫、生産、物流、金融、自治体など、データ項目と業務ルールが明確で、将来も制度変更や現場改善が見込まれる業務です。既存のC/SやAS/400の業務をWeb化したい場合も、データベースのリバースエンジニアリングや外部サービス連携を利用して、すべてを一度に捨てずに刷新する選択肢になります。公式サイトには約600画面のC/SシステムをWeb化し、生成先をC#からJavaへ変更した事例も掲載されています（出典: GeneXus公式「GeneXus」概要、2026年8月確認）。

一方で、業務が頻繁に変わるのに意思決定者が不在の場合、例外処理をすべて個別対応する場合、または見た目の表現を最優先する小規模なキャンペーンサイトの場合は、別の技術が適する可能性があります。標準SaaSで足りる非差別領域、GeneXusで競争力を出すコア業務、APIでつなぐ周辺サービスという分け方も検討します。GeneXusを採用すること自体を目的にせず、業務の再利用性と変更への対応力を評価します。

GeneXusのシステム開発の進め方｜6フェーズ

おすすめの進め方は、要件整理、パートナー・方式の選定、設計開発、テスト、稼働、定着の6フェーズです。GeneXusは動くプロトタイプを早く作りやすい一方、初期のモデルが曖昧なまま生成を繰り返すと、誤った業務ルールを速く増やすことになります。各フェーズで完了条件を置き、次へ進む判断を記録してください。

最初に、現行業務を担当者への聞き取りだけでなく、帳票、Excel、既存DB、操作ログ、規程、月次締めの手順まで並べて棚卸しします。業務フローには通常処理だけでなく、返品、取消、差戻し、データ修正、障害時の手作業も書き込みます。ここで「システム化する業務」「標準化してからシステム化する業務」「当面は残す業務」を分けると、GeneXusのナレッジベースに入力する対象が明確になります。

成果物は、業務一覧、用語集、現行データ項目表、権限マトリクス、外部連携一覧、帳票一覧、非機能要件、移行方針です。チェックでは、同じ「顧客」でも営業と経理で定義が違わないか、コード体系と桁数が決まっているか、履歴をどの期間保持するかを確認します。画面数ではなく、エンティティ、トランザクション、連携本数、ユーザー数、ピーク時の処理量で規模を説明できる状態が完了条件です。

次に、GeneXusの適用範囲、生成先、データベース、クラウドまたはオンプレミス、開発体制を決めます。パッケージは汎用業務を短く始めやすく、SaaSは運用負荷を下げやすく、フルスクラッチは自由度が高いという違いがあります。GeneXusは独自業務をモデルとして保持しながら生成技術を更新できるため、既存資産を生かした基幹刷新や、標準化しにくい業務に向く中間的な選択肢です。

パートナーへは同じRFPを渡し、要件定義から保守までの担当範囲、GeneXusの認定・経験年数、同規模の事例、再委託先、生成コードのレビュー方法、ナレッジベースと設計書の引き渡し条件を確認します。特に「GeneXusを使えます」という説明だけでなく、既存DB移行、外部API、GAMによる認証・認可、監査ログ、性能試験、障害対応を誰が担うかを質問します。2〜8週間程度の小さなPoCを提案してもらい、技術だけでなく説明責任と引き継ぎ姿勢も見極めます。

設計では、先に全画面の見た目を確定させるより、データモデルと業務ルールの骨格を作ります。顧客や商品などの共通マスタ、受注や入出庫などのトランザクション、承認状態、採番、エラー処理を整理し、優先度の高い一業務から動くプロトタイプを作ります。現場が実際に操作し、用語や入力順を直し、その結果をナレッジベースへ反映する反復が重要です。

設計開発のチェック項目は、生成先のJavaや.NETなどの選択、DBの文字コード・照合順序、APIの認証方式、バッチの再実行方法、ログの保存期間、権限の最小化、バックアップとリストア手順です。生成されたコードを無条件に編集すると再生成時に差分管理が難しくなるため、標準オブジェクトで表現できるものと拡張が必要なものを分け、拡張部分のルールを文書化します。

テストは稼働直前にまとめず、モデルとプロトタイプを作った時点から始めます。単体テストでは入力チェックや計算、結合テストでは受注から在庫・請求までの連携、総合テストでは現場の一連の業務を確認します。さらに、権限外データが見えないこと、同時更新で在庫が二重に引き当たらないこと、外部APIがタイムアウトしたとき再送できることを検証します。

テストケースは正常系だけでなく、空欄、桁あふれ、重複、取消、日付の境界、締め後の修正、通信断、バッチ失敗を含めます。公式のりそなホールディングス事例では、GeneXusとGXtestで約3,000件の自動テストを導入し、開発期間・コストを25％削減したと紹介されています。ただし、これは特定プロジェクトの実績であり、すべての案件に同じ効果が出る根拠ではありません。自社では再利用するテストデータと合格基準を先に決め、効果をPoCで測定します（出典: GeneXus公式「はじめての方へ」および導入事例、2026年8月確認）。

稼働前には、移行リハーサル、切り戻し条件、利用者アカウント、権限付与、監視、バックアップ、問い合わせ窓口を整えます。全社一括で切り替えると原因の切り分けが難しくなるため、部門、拠点、業務のいずれかを絞って段階稼働し、旧システムとの並行期間を設ける方法が安全です。並行稼働では、どちらを正とするか、差分を誰がいつ照合するか、終了条件を何にするかを決めておきます。

移行リハーサルでは、件数だけでなく金額合計、在庫残高、未処理伝票、マスタの有効期間を旧新で照合します。個人情報を扱う場合は、本番データを開発環境へ不用意に複製せず、マスキングやアクセス制御を適用します。リリース当日は、停止時間、最終バックアップ、移行担当、承認者、緊急連絡先を時系列の手順書にし、実施者以外でも判断できる形にします。

稼働後は、使い方の問い合わせを減らすことだけでなく、業務が標準化されたか、入力漏れが減ったか、処理時間が短くなったかを計測します。現場の改善要望をそのまま個別改修にせず、共通ルール、部門固有ルール、将来検討へ分類し、ナレッジベースの変更管理とリリース計画に載せます。週次の小さな改善と、四半期ごとの大きな見直しを分けると、安定運用と改善速度を両立しやすくなります。

引き継ぎでは、ナレッジベース、生成コード、ビルド手順、環境定義、テスト資産、移行スクリプト、障害履歴、ライセンス情報を一覧化します。担当者が退職しても、別の開発者がローカルでビルドし、テスト環境へリリースできることを確認してください。GeneXusの公式サイトでは、ナレッジベースやオブジェクト単位のバージョン管理が説明されていますが、実際の契約でどの資産を誰が保有するかは別途確認が必要です。

GeneXusのシステム開発の費用相場とコスト内訳

GeneXusのライセンス定価と開発会社の作業費は、契約形態、開発者数、生成先、関連製品、クラウド構成によって変わります。公開情報だけで一律の価格を決めることはできないため、以下はリサーチノートが参照した2026年の業務システム相場と、GeneXusの導入範囲を組み合わせた目安です。特定案件の見積もりではなく、初期予算を置くためのレンジとして利用してください。

PoCや部門内アプリは100万〜300万円程度、1業務で既存DB連携が少ない小規模業務システムは300万〜800万円程度が目安です。複数部門、API、帳票、権限、データ移行を含む中規模の業務統合は800万〜3,000万円程度、複数拠点・複雑な移行・高い可用性が必要な大規模刷新は3,000万円〜1.5億円以上になる可能性があります。期間は順に1〜2か月、2〜6か月、6〜12か月、12〜24か月以上が目安ですが、要件の確定度と移行・連携の難易度で変わります。

このレンジはGeneXus専用の公示価格ではありません。リサーチノートに記載された業務システム一般の小規模300万〜1,000万円、中規模1,000万〜5,000万円、大規模5,000万〜1億円以上という相場観を土台に、PoCや生成による生産性を考慮して編集した予算検討用の幅です（出典: リサーチノート「GeneXusのシステム」、2026年8月確認）。実際の発注では、ライセンス見積、開発見積、移行・連携見積、保守見積を分けて取得します。

初期費用は、要件定義・業務整理、モデル設計、画面・帳票・バッチ開発、外部連携、データ移行、テスト、教育、リリースに分けます。予算を仮置きする際は、要件整理10〜15％、モデル・画面・生成を含む設計開発35〜45％、連携・移行・テスト25〜35％、教育・リリース・予備費10〜20％という比率を使うと、見積書の偏りを見つけやすくなります。これは一般的な比較のための仮置きで、個別案件の確定比率ではありません。

別建てで確認する項目は、開発者ライセンス、チーム開発・バージョン管理環境、GAM、GXtest、WorkWithPlus、クラウド基盤、監視、バックアップ、データ転送、教育、年間サポートです。GeneXus公式の日本語サイトでは、基本的なランタイム費用はないとしつつ、GXflowやGXqueryはランタイムが必要と説明されています。製品や構成による例外があるため、「ランタイム無料」という一文だけで総額を判断せず、対象機能ごとのライセンス表を取り寄せます。

保守運用費は、初期開発費の年15〜25％程度を比較の仮置きにできますが、法改正、OS・DB・ジェネレーター更新、脆弱性対応、問い合わせ、障害対応、性能改善のどこまで含むかで変わります。月次の稼働監視だけを含む契約と、業務改善や緊急対応まで含む契約では、同じ年額でも範囲が異なります。見積書では、平日日中対応か24時間対応か、目標復旧時間、バックアップ保持期間、リリース回数を確認します。

2025年3月公開のGeneXus 18 Upgrade 12では、Android 15、Xcode 16、Angular 19への対応や安定性・セキュリティ面の強化が示されています（出典: GeneXus公式ドキュメント「GeneXus 18 Upgrade 12」、2026年8月確認）。公式ドキュメントの更新一覧にはUpgrade 15やUpgrade 16（Preview）も掲載されているため、2026年時点の計画では、採用するUpgradeとサポート期限を個別に確認します。利用するジェネレーター、DB、OS、モバイルSDK、クラウドサービスが保守対象かを確認し、更新検証の工数を予算に入れます。技術更新に強い仕組みでも、検証を省略すれば業務停止のリスクが残ります。

GeneXusの見積もりを取る際のポイント

見積もりの精度は、GeneXusの知識だけでなく、発注側が業務の境界と品質基準をどこまで示せるかで決まります。「販売管理を作る」と伝えるだけでは、締め処理、返品、承認、帳票、移行、他システム連携の有無が会社ごとに違うためです。RFPでは、対象業務、利用者、データ、連携、性能、セキュリティ、納品物、保守を同じ様式で記載します。

RFPには、対象業務と対象外業務、拠点・部門数、同時利用者数、ピーク時の取引件数、画面・帳票・バッチ・APIの概数、既存DBの種類とデータ量、移行履歴、外部システム名、認証方式、権限階層、監査ログの要件を記載します。さらに、目標応答時間、稼働率、障害時の復旧時間、バックアップ、保存地域、スマートフォン対応、旧システムとの並行期間も具体化します。

納品物も「システム一式」と書かず、ナレッジベース、生成ソース、拡張ソース、DB定義、API仕様、画面仕様、テスト仕様書・結果、移行手順、運用手順、教育資料、環境定義、ライセンス情報に分けます。各成果物の形式、更新時期、受け入れ基準、権利・利用範囲を記載すると、ベンダー変更時の引き継ぎリスクを下げられます。

複数社へ見積もりを依頼する場合は、同じRFP、同じデータサンプル、同じPoC範囲を渡します。比較表には、初期費用、ライセンス、クラウド、移行、連携、テスト、教育、保守、予備費を分けて記載し、作業項目の「一式」には内訳を求めます。安い提案を選ぶのではなく、未計上の作業がないか、前提条件が自社の想定と一致するかを確認します。

評価は価格だけでなく、要件定義の具体性、業務担当者との進め方、GeneXusのモデル設計力、既存資産の移行経験、テスト自動化、セキュリティ、保守体制、内製化支援、成果物の引き渡しで行います。パートナーの実績は公式パートナーリストや公式導入事例で確認し、掲載されている事例と自社案件の規模・業種・品質要件がどの程度近いかを質問します。

人事、顧客、従業員、取引先の情報を扱う場合は、機能見積もりだけでなく委託先管理を確認します。個人情報保護委員会の通則ガイドラインでは、委託先の安全管理措置を事前に確認し、契約で個人データの取り扱いを定め、取り扱い状況を把握することが示されています。再委託がある場合は、再委託先、業務内容、データの扱い、事前報告または承認、監査方法を契約に入れます（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

見積もり段階では、誰が本番データへアクセスするか、開発・検証環境でマスキングするか、海外リージョンや海外の再委託先があるか、ログを何年間保持するか、脆弱性対応の責任者は誰かを確認します。GAMによる認証・認可、監査ログ製品、TLS設定、秘密情報の保管、バックアップの暗号化を機能要件・運用要件へ落とし込みます。費用を削るために監査や教育を外すと、稼働後に追加費用とリスクが発生しやすくなります。

GeneXusのシステム開発でよくある質問

GeneXusは、導入前の期待値を正しく設定し、業務・データ・運用まで確認してから採用することが重要です。ここでは、相談時に特に多い疑問へ、判断材料を短く回答します。

必ず下がるとはいえません。業務の標準化、モデルや部品の再利用、テスト自動化、既存資産の活用、内製化ができる案件では、開発や変更の効率化を期待できますが、複雑な移行、個別帳票、外部連携、厳しい非機能要件があれば費用は増えます。ライセンス、開発、移行、保守を含む総額で比較し、PoCで効果を実測してください。

重要業務を一つ選び、業務モデルの作りやすさ、プロトタイプの操作性、既存DBまたはAPIとの接続、代表的な帳票、権限、ピーク時の性能、テストの再実行、ナレッジベースの引き継ぎを検証します。成功条件は「画面が表示できた」ではなく、現場が業務を完了でき、変更を加えた後もテストと再生成ができることです。2〜8週間程度の範囲と成果物を先に固定すると、本開発へ進む判断がしやすくなります。

内製化できますが、ツール操作の研修だけでは定着しません。業務オーナー、GeneXus担当者、インフラ・セキュリティ担当者を決め、モデル設計、レビュー、テスト、リリース、障害対応を実案件で一緒に経験します。パートナー契約には、研修、ペア開発、コード・ナレッジベースの引き渡し、問い合わせ対応の縮小計画を含め、外部会社がいなくても小さな変更をリリースできる状態を目標にします。

移行できますが、既存データをそのまま移せるとは限りません。まず現行DBの項目、コード、重複、欠損、履歴、締め状態を調べ、移行するデータとアーカイブするデータを分けます。GeneXusの公式情報にも、既存DBのリバースエンジニアリングや約600画面のC/SシステムをWeb化した例がありますが、自社の移行難易度はデータ品質と連携仕様で決まります。移行リハーサルを複数回行い、件数だけでなく業務上の残高を照合してください。

まとめ｜GeneXusのシステム開発は段階移行が成功の鍵です

GeneXusのシステム開発は、要件整理、方式・パートナー選定、設計開発、テスト、稼働、定着の順に、各フェーズの完了条件を確認しながら進めます。業務を正しくモデル化し、既存DBや外部連携を先に把握し、動くプロトタイプと自動化したテストを小さく積み上げることが、納期と品質の両方を守る基本です。

発注前は、対象業務と対象外業務、ユーザー数とピーク負荷、既存DB・データ移行、APIと帳票、認証・認可、監査ログ、バックアップ、テスト合格基準、段階稼働、切り戻し条件、ライセンス、保守範囲、再委託、成果物の所有・引き渡しを一つずつ確認します。特に費用は、初期開発費だけでなく、ライセンス、クラウド、教育、保守、技術更新、追加改修を含む3年程度の総額で比較します。

まずは対象業務を一つ選び、業務フロー、データ項目、例外処理、外部連携、受け入れ基準を整理してください。その資料を使って複数のパートナーへ同じ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を創業。