GeneXusのシステム開発は、業務の知識をナレッジベースに定義し、そこからDBやプログラムを生成して進める方式です。
既存資産の刷新か、新規業務の開発か、複数チャネルへの展開かによって、業務に合う使い方が変わります。
▼関連記事一覧
・GeneXusのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・GeneXusのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・GeneXusのシステム開発の見積相場や費用/コスト/値段について
・GeneXusのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
GeneXusのシステムの概要
GeneXusは、業務をモデル化するための開発基盤です。完成済みの業務画面を使うSaaSとは違い、業務の定義からシステムを生み出す仕組みになります。
業務知識を入力すると、実現方法を推論してDBやプログラムを生成します。そのため、ノーコード製品とスクラッチ開発の中間に位置づけられます。
業務知識をナレッジベースに定義する仕組み
業務担当者と開発担当者が、管理対象と処理条件を確かめながら、ナレッジベースに知識を蓄積していきます。そのうえで、顧客や商品などの項目情報を、画面やルールと合わせてモデル化します。
- 項目情報：顧客、商品、受注、在庫、請求など
- 業務の要素：入力画面、伝票、業務ルール
定義した関係をもとに、データベース構造や標準的な処理を生成します。特に、同じ業務知識をWebやモバイルなど複数の提供形態へ展開しやすい点が特徴です。
公式の説明では、業務内容の記述からデータベースとプログラムを生成できます。また、生成先のOS、アプリケーションサーバー、データベース、開発言語に合わせた維持も可能とされています（出典: GeneXus公式「GeneXus」、2026年確認）。
入力するモデルの品質が、出力されるシステムの品質を左右します。曖昧な業務ルールや未整理の例外処理は、自動で正しく解決されるとは限りません。
「ソフトウェアを作るソフトウェア」という捉え方
GeneXusは、業務モデルからアプリケーションを生み出す仕組みです。完成品を購入する製品とは違い、生成先やチャネルを変えても、業務ロジックを中心に据えられます。
- 生成先の変更：Javaや.NETなどへの展開
- 複数チャネルへの展開：Webとモバイルを併用
- 業務ロジック：中心となる知識はナレッジベースに置く
技術基盤の更新に合わせて再生成できるため、特定のフレームワークを手書きで長期保守する負担を減らせます。一方で、生成コードだけでなく、ナレッジベースや設計書なども管理する必要があります。
生成条件、テスト資産、データ移行手順まで含めて管理するため、変更できる人と範囲を決めておく必要があります。採用時は、開発速度だけでなく、業務知識を自社に残せるかも判断材料になります。
GeneXusのシステムの種類と向いている業務
GeneXusは業種別に完成したパッケージではなく、データと業務ルールがある領域に幅広く適用できます。販売管理や在庫・生産管理、物流、金融などが対象になります。自治体や申請・承認、人事にも適用できます。
代表的な用途は、既存資産を活かすモダナイズ型、新規業務を短期間で作る型、複数チャネルへ展開するマルチエクスペリエンス型です。
既存のレガシーシステムをWeb・モバイル化する型
既存システムを刷新する際は、段階的に進めます。
- 対象資産：AS/400、メインフレーム、古いC/Sシステムの業務知識
- 進め方：既存DBへの接続やリバースエンジニアリングを活用
現行業務と新しい利用環境との差分を確かめながら進められます。ただし、古いデータに重複や欠損がある場合は、移行の前にクレンジング方針を定めておく必要があります。
公式例には、約600画面のC/SシステムをWeb化し、生成先をC#からJavaへ変更した事例があります（出典: GeneXus公式「GeneXus」、2026年確認）。
規模は画面数だけで見積もらず、データ項目、夜間バッチ、帳票、外部連携、権限、締め処理、障害時の手作業まで洗い出します。
新規業務やWeb・モバイルの短期開発への適用
利用者の意見を取り入れながら改善していく業務では、早い段階で試作品を見せる進め方が役立ちます。現場向けの業務や、Web・モバイルで使う業務が候補になります。
- 対象業務：申請、点検、日報、在庫照会、営業支援
- 利用環境：Webとモバイルを同じ業務モデルから展開
事務所と現場で入力場所が分かれていても、同じデータを中心に設計できます。一方で、業務が標準化されていて独自の差別化が要らないなら、既製のSaaSやパッケージのほうが早い可能性があります。
柔軟性が求められ、将来の変更や技術更新も見込まれる業務では、GeneXusの価値が出やすくなります。また、全社を同じ方法で開発するのではなく、標準化できる業務と独自性の高い業務を分けて判断します。
GeneXusのシステム開発のメリットと注意点
GeneXusの効果は、「自動生成だから安い」という単純な話で片づけられるものではありません。
業務モデルの再利用、変更影響の追跡、試作品による早期確認が組み合わさると、開発から保守までの総コストを抑えられます。加えて、テスト自動化や内製化、既存資産の活用も、総コストを抑える要素になります。
ただし、業務が整理されないまま着手すると、生成できても使いにくいシステムになる可能性があります。
開発と変更のサイクルの短縮
業務要件をオブジェクトとして管理しておくと、変更の影響を確かめ、試作品を使った現場確認も早く進められます。
- 影響の追跡：項目やルールの変更が、DBや画面に与える影響
- 早期の修正：試作品で、入力順や検索条件、承認経路を見直す
小さく分けてリリースするアジャイル型とも相性がよく、優先度の高い業務から順に価値を届けられます。
公式の導入案内には、開発速度の平均で30%以上の向上、開発コストで40%以上の削減という事例値があります（出典: GeneXus公式「はじめての方へ」、2026年確認）。
結果は、再利用できる既存資産、要件変更の頻度、テスト自動化、社内の業務知識の有無によって変わります。この数値は、どの案件にも当てはまる保証値ではありません。
モデル品質と生成後の品質保証
部門間で商品コードの意味が違う場合や、締め処理の例外が口頭でしか共有されない場合、権限が担当者の経験で決まる場合は、先に業務を標準化しておきます。自動生成しても、誤った定義が正しい業務に変わるわけではないためです。
誰がどのデータをいつ登録し、どの条件で承認し、修正履歴をどこまで残すかは、文書にして明確にしておきます。生成後には、単体テストや結合テスト、総合テストが必要です。性能やセキュリティ、移行リハーサルのテストも欠かせません。
画面の表示だけでなく、月末や繁忙期の負荷にも耐えるかを確かめます。通信障害時の再実行や二重計上の防止、権限外データの遮断も、テストで見ておきます。また、生成後コードのレビュー担当と障害時の切り分け担当は、開始時に決めておきます。
GeneXusのシステム開発の進め方
GeneXusの開発では、最初から全機能を作り切ろうとせず、業務の優先順位と検証の単位を決めて小さく進めます。
開発は、要件定義、モデル化、試作を軸に進めます。そのうえで、設計と生成、テスト、移行とリリースを反復し、ナレッジベースを育てていきます。
レガシー刷新では、旧システムを残しながら新システムを段階導入する計画が現実的です。
要件定義とPoCによる対象業務の絞り込み
代表業務をPoCで検証するために、要件定義では対象の範囲と処理量を把握し、仕様を決める関係者を揃えておきます。
- 対象と環境：業務、利用者、拠点、データ量、現行システム、外部連携
- 機能・処理量：帳票、権限、法令、稼働時間、業務エンティティとトランザクション、日次・月次・年次の処理量
- 意思決定者：各担当者を早い段階で集め、誰の要望を標準仕様に採用するかを決める
PoCは2〜8週間程度を目安に、代表的な登録や検索、承認、帳票、API連携を実装します。確認するのは、生成速度や使いやすさ、既存DBへの接続です。加えて、ピーク性能や権限、テスト、ナレッジベースの引継ぎも見ておきます。
見栄えだけで判断しないよう、難しい例外処理を1つ含めて検証します。
モデル化とイテレーションによる現場とのずれの抑制
PoCで確認した業務は、ナレッジベースに整理します。データモデルやトランザクション、ルール、画面、権限を定義します。一度の承認ですべてを確定させず、動く画面を見た利用者の意見をモデルに反映します。
変更理由と採否は記録しておき、個別の要望が全体の整合性を損なわないよう管理します。開発の単位は、たとえば受注登録から在庫引当、出荷、請求までの業務の流れで区切ります。
関連するマスタや権限、帳票も同じイテレーションで確認し、連携だけが後に残る事態を避けます。新旧システムを並行稼働する場合は、二重入力の期間や正とするデータ、照合方法、切替条件を事前に決めておきます。
本番前のテスト・移行・教育
テストでは、正常系だけでなく、それ以外の状況も扱います。変更後に再実行できるよう、準備しておきます。
- 異常・例外系：入力ミス、権限不足、在庫不足、締め後の修正
- 連携・競合：外部API停止、通信切断、同時更新
- 再実行の準備：代表データと自動テストを整備
公式事例では、約3,000件の自動テストを導入し、開発期間・コストを25%最適化した例があります（出典: GeneXus公式「導入事例」、2026年確認）。ただし、これは特定案件の実績であり、テスト設計なしに同じ効果が得られるわけではありません。
移行では、件数や欠損、重複を確かめ、コード体系や日付・金額の形式、履歴の保持期間も確認します。移行は複数回リハーサルするのが基本です。
稼働後に備えて、操作教育や問い合わせ窓口、障害時の連絡網を整えます。モデル変更の担当者も、あらかじめ決めておきます。
ベンダーへの全面的な依存を避けるため、ナレッジベースとテスト資産は、自社でも読める状態にしておきます。
GeneXusのシステム開発費用の目安
GeneXusの開発費用は、利用形態や開発者数、生成先、周辺製品、保守範囲によって変わります。公開された一律の価格だけでは、判断できません。
公式のPlans and Pricingには複数のプランがあります。実際の見積では、ライセンス、開発、基盤、保守を分けて確認します。
ここで示すのは、公示価格ではなく、業務システム一般の規模別相場とGeneXusの生産性効果を踏まえた、2026年時点の概算です。
▶ 詳細はこちら：GeneXusのシステム開発の見積相場や費用/コスト/値段について
▶ 詳細はこちら：GeneXusのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：GeneXusのシステム開発の発注/外注/依頼/委託方法について
規模別の費用と期間の目安
規模別の費用目安は次のとおりです。小規模の業務システムは、登録・検索・承認を中心に作られます。
- 部門内PoC・簡易アプリ：100万〜300万円
- 小規模業務システム：300万〜800万円
- 中規模：複数部門、API、権限、帳票、移行を含む基幹・業務統合は800万〜3,000万円
- 大規模：レガシー刷新や多数拠点、高可用性の案件は3,000万円〜1.5億円以上の場合あり
開発期間は、PoCが2〜8週間、小規模が2〜6か月、中規模が6〜12か月、大規模が12〜24か月以上と見ることができます。
金額と期間は、業務の複雑さや移行データの品質によって変わります。連携本数や利用者数、旧新並行期間も影響します。画面数だけで比べるのではなく、見積に含まれる範囲をそろえて比べます。
ライセンスだけでなく移行・保守まで含めた比較
見積を比べるときは、費用の種類ごとに対象範囲と計上方法を確認します。
- 開発工程：要件定義、業務整理、モデル化・画面設計・生成、連携、移行、テスト、教育・リリース、予備費
- 別計上の費用：開発者ライセンス、チーム開発・版管理、認証・監査、自動テスト、基盤、監視、バックアップ、年間保守
- 保守費：初期開発費の年15〜25%程度を仮置きし、含まれる範囲を確認
- 保守の対象：法改正、OS・DB等の更新、脆弱性、問い合わせ、障害、性能改善
- 見積書の区分：初期費用、毎年の固定費、利用量連動費、任意の追加費用を分ける
公式の「ランタイム費用なし」という説明は、関連製品や構成で追加費用が生じないという意味ではありません。
GeneXusとパッケージ・SaaS・スクラッチの使い分け
業務によって、向く方式は変わります。標準化された業務はSaaSやパッケージ、独自性が高く変更も多い業務はGeneXus、特殊な処理や既存技術との密接な連携はスクラッチが候補になります。
業務単位で方式を選ぶと判断しやすくなります。また、複数の方式をAPIでつなぐハイブリッド構成も選択肢になります。
標準化できる業務に向くパッケージ・SaaS
会計や人事、勤怠などの共通業務を大きく変えずに運用できるなら、既製のパッケージやSaaSが候補になります。初期開発を抑えられるうえ、提供側の更新も利用できます。
独自業務に合わせたアドオンや個別運用が増えると、かえって複雑になります。そのため、データの持ち出しや外部連携、利用停止時のエクスポート、契約終了後の移行費も確認しておく必要があります。
標準機能に合わせて業務を変えられるかは、部門ごとに判断します。標準化で改善できる業務はSaaS、競争力に直結する業務や複雑な既存資産を維持する業務は、個別開発を検討します。
独自業務と将来変更を重視する場合のGeneXus
方式ごとの違いを踏まえて、業務の特性と将来の変更を見て選びます。
- フルスクラッチ：自由度が高く、特殊処理や既存の標準に対応できる一方、設計・実装・保守の負担は増えがちです
- GeneXus：業務固有のモデルを保ったまま、生成先や画面展開を変えて技術更新に対応
- 再生成が判断材料となる業務：変更が多く、複数チャネルやDBを将来使い分けたい
ただし、モデル設計や例外処理、移行の工数が大きければ、総額は増えます。非機能要件や教育、保守の工数が大きくなる場合も、総額に響きます。
評価は、初期費用だけでなく、5年間の変更、保守、移行の費用と、社内に残る知識を含めたTCO（総保有コスト）で行います。
GeneXusのシステムにおけるセキュリティと運用設計
認証・認可、監査ログ、通信の設計は、設計の初期段階から扱います。秘密情報やバックアップ、脆弱性対応も、早い段階で扱う項目です。認証できることと、必要なデータだけを見られることは別です。
利用者や組織、役割、業務の状態ごとに権限を定義します。あわせて、管理者権限の付与や変更、剥奪を記録しておきます。
認証・認可と監査ログの業務要件化
認証製品を使う場合でも、業務上の権限と記録対象は利用者側で設計します。外部認証との連携や、監査ログの範囲も決めておきます。
- 認証・権限：GeneXus Access Managerなどの利用時も、利用者側で権限を設計
- 認証連携と運用：社内SSO、OAuth 2.0、SAML、二要素認証、再発行、退職者の停止
- 監査ログ：ログインのほか、閲覧・変更・削除、権限変更、出力、承認者・時刻を記録するかを決める
個人情報を扱う場合は、委託先の安全管理措置や事故報告の期限を契約で確認します。再委託先とデータの範囲、監査権限も、契約で定めておきます。
個人情報保護委員会の通則ガイドラインでも、委託先の選定や契約、取扱状況の把握、必要に応じた監査が示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年6月改訂）。
クラウドを使う場合は、保存地域やアクセス権、バックアップ、削除の証跡も確認します。
生成先・クラウド・保守の責任分界
生成先は、自社の運用体制や人材、クラウド標準を踏まえて選びます。選定時には、DBや周辺製品との互換性も確かめます。
- 生成先：Web、モバイル、Java、.NET、Angularなどから、運用体制・人材・クラウド標準を踏まえて選択
- 互換性：利用するジェネレーター、DB、周辺製品が現行環境で保守されるかの確認
GeneXus 18 Upgrade 12は2025年3月に公開され、Android 15、Xcode 16、Angular 19への対応や、安定性・セキュリティ強化が示されています（出典: GeneXus公式ドキュメント「GeneXus 18 Upgrade 12」、2025年）。
運用設計では、監視項目や障害の一次切り分け、復旧時間、目標復旧時点を決めます。定期保守や更新検証環境も、あわせて決めておきます。開発会社、自社、クラウド基盤側の担当範囲は、責任分界表にまとめます。
ナレッジベース、生成コード、設定ファイル、CI/CD、テストデータについては、引渡しの形式も契約書に明記します。
GeneXusの開発会社・ベンダーの選び方
開発会社は、ツールを使えるかだけでなく、業務整理から移行・テスト・運用まで責任を持てるかで選びます。
確認するのは、同業・同規模の実績や要件定義の範囲、生成先とDBです。認証・監査ログ、テスト自動化、内製化教育、保守体制も、同じ質問票でそろえて確認します。
業種・規模・難易度を揃えた実績の確認
「導入実績が多い」という説明だけでは、判断材料として不十分です。販売管理、金融の統制、現場モバイル、レガシー移行では、必要な経験が異なるためです。
確認するのは、対象業務と期間、規模です。規模は、画面やAPI、拠点の大きさで見たうえで、移行の有無と本番後の保守範囲も確かめます。可能であれば、匿名化した設計サンプルやテスト計画の説明も受けます。
提案書に実績を載せた人が本番まで参加するかを確かめます。あわせて、要件定義とモデル設計、生成、テスト、移行の責任者を確認します。再委託がある場合は、作業範囲やアクセスするデータ、品質管理、事故時の連絡経路も明らかにします。
納品物・契約・保守条件の事前整理
見積、納品、契約の条件は、項目ごとにそろえて確認します。
- 見積依頼の規模：対象業務、利用者数、拠点数、既存DB、データ件数
- 見積依頼の要件：連携本数、帳票数、ピーク負荷、可用性、権限、監査ログ、移行、教育、保守、SLA
- 工程と条件：「開発一式」だけでは追加費用の範囲が分からないため、工程と前提・除外条件を明記
- 納品物：ナレッジベース、コード、DB定義、画面・API仕様、テスト、移行、環境構築、監視・バックアップ、教育資料
- 契約と引継ぎ：移管、ライセンス、コード権利、再委託、秘密保持、脆弱性対応、事故報告期限
▶ 詳細はこちら：GeneXusのシステム開発でおすすめの開発会社/ベンダー6選と選び方
2026年時点の最新動向と導入前の確認事項
2026年に新しく導入する場合は、ローコードという言葉だけでなく、生成技術の更新やクラウドネイティブ対応、モバイルOS、テスト自動化、AI機能を確認します。
AIや自動生成が提案を補助する場合は、個人情報や機密情報を入力してよいか、出力を誰がレビューするかを決めます。変更履歴と監査証跡を残せるかも、あわせて確認します。
製品ロードマップと互換性の案件ごとの確認
導入時は、最新版を採用すること自体を目的にせず、互換性と更新条件を案件ごとに確認します。
- 更新情報：公式ドキュメントのUpgrade 12以降や次のアップグレード情報の確認
- 互換性：生成先、OS、DB、端末、ブラウザー、周辺製品の組み合わせの確認
- 更新コストと支援：KB変換、回帰テスト、停止時間、サポート終了、脆弱性修正の提供方法、ライセンス変更の見積もり
既存のKBの移行方法も確認します。あわせて、自社の技術標準と合わない場合に生成先を変えられるか、別方式へデータを移せるかも、PoCで確かめます。
PoCの実測値による効果の判断
PoCでは、評価項目と終了条件を定めておきます。費用削減を目指す場合は、5年間の費用も試算します。
- 開発・品質：画面作成・要件変更時間、テスト再利用率、移行エラー率、性能、権限、操作時間を測定
- 5年間の試算：変更、保守、教育、移行費用を含める
- 自社での継続：ナレッジベースを読み、変更を加え、テストを再実行して障害原因を追える
- データと移管：データを出力でき、契約終了後の移管方法を説明できる
条件を満たさない場合は、本開発の範囲を縮小するか、別方式と比較し直します。
GeneXusのシステムに関するよくある質問
GeneXusのシステム開発を検討するとき、よく寄せられる質問を取り上げます。導入の可否は、ライセンス価格だけでなく、業務モデルや既存資産、社内体制、セキュリティ、保守条件を合わせて判断します。
GeneXusなら必ず開発費が安くなりますか？
必ず安くなるとは限りません。効果は、業務の標準化やモデルの再利用、変更の頻度、テスト自動化、内製化、既存資産の活用によって変わります。そのため、PoCで工数と品質を測ります。
ライセンス、開発、移行、教育、保守を含む総額で比較します。
既存のデータベースや古いシステムと連携できますか？
連携できる可能性があります。既存DBの構造を調べたうえで、API、Webサービス、バッチ、ファイル連携などから方式を選びます。
古いデータの品質や文字コード、日付・金額の形式が障害になる場合もあります。処理順や夜間バッチの依存関係も、問題になることがあります。そのため、PoCで実データに近い条件を検証します。
自社開発・内製化はできますか？
できますが、教育と伴走支援を組み合わせる方法が現実的です。業務担当者がモデルを理解し、情報システム部門がバージョン管理やテスト、リリースを運用できる体制を作ります。
ナレッジベースやテスト資産の引渡し、研修、レビュー、障害対応の分担を契約前に確認します。
個人情報を扱う業務でも利用できますか？
利用できますが、安全性は製品名だけでは判断できません。認証・認可、監査ログ、暗号化、アクセス制御を要件に定めます。バックアップや脆弱性対応、委託先・再委託先の監督は、契約で取り決めます。
保存地域や事故時の報告、データの返却・削除の証跡も確認します。必要に応じて、セキュリティ担当や法務担当を交えて判断します。
GeneXusのシステム開発を成功させるポイントまとめ
GeneXusは、業務データ、画面、ルールをナレッジベースに定義し、複数の技術基盤へアプリケーションを生成するローコード開発の選択肢です。
試作による早期確認、業務モデルの再利用、レガシー資産の活用、技術更新への対応が強みです。加えて、テストや内製化による継続性も挙げられます。
業務と総保有コストによる判断
採用前に、現行業務とデータを洗い出します。そのうえで、代表業務のPoCや費用の分解、移行・連携・非機能要件の確認を行います。
「ローコードだから安い」と決めつけず、標準化や再利用、自動テスト、内製化で、どの工数を減らせるかを測ります。
個人情報を扱う場合は、認証・認可と監査ログに加え、委託先・再委託先、クラウド、事故対応も確認します。
最初に行う対象業務と検証条件の明文化
RFPや相談資料には、まず対象業務と利用者・拠点、既存DB、データ量を書きます。連携や帳票、権限、ピーク負荷も記載します。加えて、移行や教育、保守、納品物も盛り込みます。
候補企業には同じ条件を示し、実績や担当者、PoCの方法、契約終了時の引継ぎを比べます。最終的には、自社の業務変化と運用体制に合うかを、検証結果で判断します。
▼関連記事一覧
・GeneXusのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・GeneXusのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・GeneXusのシステム開発の見積相場や費用/コスト/値段について
・GeneXusのシステム開発の発注/外注/依頼/委託方法について
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。