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

Grailsのシステム開発は、要件整理、技術検証、契約と移行の順に進めると、業務と技術の両面でリスクを抑えやすくなります。まず業務の要件を言葉にして揃え、次にGrailsの技術を小さく検証します。そのうえで、契約と移行へ進む流れです。

発注形態、契約と費用、RFPと見積もりの比べ方は、この流れのなかで決めていく項目です。

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

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

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

Grailsは、Apache Groovyを使ってJVM上で動作するオープンソースのWebアプリケーションフレームワークです。Spring、Hibernate、RDBなどのJava系資産と組み合わせやすいのも特徴です。

発注時は、技術要件に加えて業務の流れと運用責任も決めておく必要があります。Grailsは設定より規約、DRY、スカッフォールディングを重視するため、この前提を発注者と委託先で共有しておくことが大切です。

Grailsが向いているシステムと向いていないシステム

画面、CRUD、バリデーション、権限、帳票、API連携を組み合わせる業務Webシステムには、Grailsが向いています。

• 業務画面：社内ポータル、ワークフロー、顧客管理に使えます。
• 業務管理：販売・在庫管理、予約、文書管理が例です。
• データ業務：入力・検索の業務、帳票、API連携を扱う場面です。

Grailsは短期間で試作しやすい点も特徴です。JavaやSpringの知識があれば、既存の資産を活かしやすくなります。

複雑なデータ移行、秒単位の処理性能、災害対策、長期保守が必要な場合は、別途設計が要ります。Grailsが大規模トランザクションや厳格な監査へ自動で対応するとは限らないためです。

委託先は、DB設計とトランザクション境界を先に固め、性能試験、ログ保存、復旧目標を定義しておくと、後から直すことになりにくくなります。

会計や勤怠のように標準SaaSで足りる業務を、あえてスクラッチで作る場合は、Grailsを使わない選択肢も比べます。

2026年の新規発注で確認するGrailsのバージョン

新規発注と既存システムの更新では、同じGrailsでも確認する技術条件が異なります。現行版の表示を基準にしつつ、新規開発と既存環境それぞれの確認項目を分けて見ます。

• 現行版：2026年8月9日時点で表示される版は7.2.2です。Grails 7は2025年10月18日に正式リリースされています。
• 新規開発：利用予定の技術構成と、RDBを含む実装経験を見ます。
• 既存システム：版、依存関係、テストの有無を一覧にします。

Grails 7は、Apache Software Foundationのもとでリリースされました。Spring Boot 3.5系、Spring Framework 6.2系、Groovy 4系などを基盤としています（出典: Apache Grails公式ドキュメント、2026年／Apache Grails 7.0.0リリース発表、2025年）。

「Grails対応」という表記だけでなく、Grails 7.2系、Java 17以降、Groovy 4の実装経験を確かめます。加えて、Spring Boot 3系、GORM、Gradleでの実装経験も見ておきます。

既存環境では、Grails 2から6のどの版か、Javaやプラグインの依存関係、テストの有無を一覧にします。

Grails 6から7では、名前空間、依存関係、Spring Securityなどが変わります。そのため、全面改修と段階移行の案を比べることになります。

新規開発では、先に挙げた版と技術構成の経験を、提案の段階で具体的に示してもらいます。

Grailsのシステムの発注形態の選び方

発注形態は、目的と社内に残したい能力によって選びます。業務の整理からリリースまで任せたい場合は、一括請負が候補になります。

仕様を発注側と一緒に詰めるなら準委任、技術判断だけを補うならスポット支援が候補になります。要件定義は準委任で進め、確定した機能の開発は請負に分ける方法もあります。

一括請負で任せるケース

一括請負は、成果物と完成条件を合意したうえで、決めた範囲のシステムを完成させる形態です。選定の際は、範囲と納期を確かめ、変更条件と検収内容も見ておきます。

• 向く条件：画面一覧、業務フロー、外部連携、受入条件、納期が比較的明確な場合です。
• 発注側の体制：社内調整に割く時間が少ない場合も候補です。
• 変更への備え：契約後の要件追加は費用や納期の変更につながりやすいので、変更の条件を取り決めておきます。

「開発一式」だけの見積もりは避けます。工程別の内訳には、要件定義、基本・詳細設計、実装を含めてもらいます。テストは単体、結合、総合に分けてもらいます。移行、教育、リリース支援も、工程ごとに分けて書いてもらいます。

各工程の完了条件は、契約書に明記しておく必要があります。受入テストで不合格になったときに、どこまでを修正の範囲とするか、どこからが仕様変更にあたるかを、契約前に確認します。

準委任・ラボ型で伴走してもらうケース

準委任は、決めた期間と体制で業務を進めてもらう形態です。要件が変わりやすい工程で候補になります。

• 利用場面：新規サービスや段階的な業務改善、既存Grailsの調査や更新が対象です。
• 発注側の役割：責任者を置き、毎週の優先順位を決められる体制を用意しておく必要があります。
• 契約で定めること：月ごとの稼働人数とスキルに加え、会議体と成果物を決めます。課題管理、稼働報告、品質指標も含めます。

完成機能数や納期は、契約だけで保証しにくい形態です。一方で、外部のGrails専門家に設計レビューを頼み、知識移転やコードレビューを依頼することもできます。テスト自動化や運用手順の作成まで頼めるため、委託先への依存を抑えられます。

技術支援・内製化支援として依頼するケース

社内にJavaやSpringの開発者がいて、Grails特有の設計や移行だけを補いたい場合は、技術支援を依頼できます。

• 移行診断：Grails 6から7への移行を調べる支援です。
• 互換性確認：プラグインとGORMのクエリが、新しい版で動くかを確かめる作業です。
• クエリ改善：GORMのクエリを確認する支援です。
• 技術改善：Spring Securityの設計、性能ボトルネックの調査、CI/CDの支援が含まれます。

Object Computing, Inc.は、Grailsコア開発チームによる商用サポートやコンサルティングを公開しています。

コア技術の相談先を探すときには、この公開情報を比較の基準にできます（出典: Object Computing, Inc.公式サービス情報、2026年確認）。

依頼の前に現行版への対応可否を確かめ、相談の前には現状資料と質問を渡します。相談のあとには判断の記録を残してもらい、助言が実装に反映されたかも確かめます。

発注側は、コード、依存ライブラリ、ログ、テスト結果を共有できる環境も整えておきます。

海外のコアチームへ依頼する場合は、時差や英語での仕様共有を確認します。機密情報の扱い、契約通貨、障害時の連絡手段も確かめます。

Grailsのシステムを発注・外注する進め方

発注の成否は、提案書の見栄えより、発注者と受託者が同じ業務像を持てるかで決まります。特に、画面開発を先行させると、権限、データ移行、外部API、監査ログ、運用監視が後から加わります。

そのため、業務、技術、契約の順に固めます。要件整理とRFP、PoCとMVP、本開発とテストを、段階を踏んで進めます。

要件整理とRFPの準備

現行業務の担当者からは、誰が、いつ、何を入力し、誰が承認するかを聞き取ります。さらに、どのデータを次の業務へ渡すかも確かめ、見積もりの前提情報をそろえます。

• 業務と利用者：業務フロー、利用者、権限、繁忙期の件数を書き出します。
• データと運用：データ項目、帳票、外部連携、移行対象、停止可能時間を確かめます。
• 優先度：「必須」「できれば必要」「将来検討」に分け、見積条件を揃えます。

RFPには、背景・目的、対象業務・ユーザー、必要機能、非機能要件を記載します。希望日程や予算の考え方、発注範囲、提出物、選定基準も書きます。

Grails 7系を前提とするか、既存版の保守を優先するかも明記します。Java、Groovy、Spring Boot、DB、クラウド、認証基盤の制約も伝えます。

技術を断定できない場合は、Grailsを第一候補とし、代替案と比較理由を提案してもらいます。

PoCとMVPによる技術・業務の検証

Grailsの経験が社内に少ない場合は、全機能を一度に発注せず、小さなPoCで技術と業務を検証します。

• PoCの対象：ログイン、主要な登録・検索、代表的な権限、外部API連携を含めます。
• 検証範囲：認証・認可、データモデル、エラー処理、テスト、デプロイ、ログを確かめます。
• MVP：業務価値に直結する最小機能を決め、申請・承認・検索・履歴確認などを先行します。

MVPでは、細かな帳票や高度な分析をバックログへ分ける例があります。PoCの目的は、短い検証で解消できる技術リスクを、本開発の高額な変更リスクへ持ち越さないことです。

業務システム一般の整理では、要件定義を急ぐと、工数や費用が当初の1.3〜1.5倍に膨らむ可能性が示されています（出典: NotebookLM「業務システム全般_18」Q&A、2026年）。

この倍率は、予算に余裕を持たせるための参考値です。そこで、優先順位と変更ルールを合意し、追加機能を無制限に含めないようにします。

設計・開発・テスト・リリースの段階化

基本設計から実装、テスト、リリースまで、工程ごとの確認事項を決めて進めます。

1. 設計：業務フロー、権限、データモデル、連携、非機能要件を確定します。
2. 実装：Controller、Service、GORMの責務を分け、ドメインロジックを画面へ埋め込みすぎないようにします。
3. テスト：単体、結合、総合、性能、セキュリティ、移行リハーサルを行います。
4. リリース判定：検索時間、ロール別権限、障害復旧、バックアップ復元を受入条件にします。

実装の責務を分けておくと、将来のAPI化や画面変更にも対応しやすくなります。

ソースコードに加え、DB定義、環境構築手順、CI/CD設定、テスト仕様も納品物として管理します。

Grails 7.2系公式ガイドは、ユニット、統合、機能テストを分けて説明しています（出典: Apache Grails 7.2系公式ドキュメント、2026年）。Testcontainersを使うコンテナ化ブラウザテストも案内されています。検索時間の測定は、実データに近い件数で行います。

Grailsのシステム発注で選ぶ契約形態と契約条項

契約形態は、機能の確定度と変更の多さで選びます。社内に残す責任やリスク分担も判断材料になります。請負は成果物の完成を、準委任は専門人材による業務遂行を重視します。

要件が固まっていない工程を請負で発注していないか、確かめます。完成条件が明確な工程を準委任にしていないかも見ます。

請負と準委任の工程ごとの使い分け

工程の確定度に合わせて契約を使い分けるため、変更が多い工程と完成条件が明確な工程を分けておきます。

• 調査・検証：成果物を決めたうえで、準委任や小さな個別契約から始める方法があります。
• 確定した開発：機能と受入条件が固まった基本設計以降は、請負に切り替えられます。
• 追加機能：改善を準委任で進めるという組み合わせもあります。

工程を分けるなら、前工程の成果物を次工程の前提とする条件を明記します。契約書では、作業範囲、成果物、納期、検収を確認します。加えて、不具合、再委託、秘密保持、個人データ、損害賠償、終了時の引き継ぎも取り決めます。

準委任では、善管注意義務、報告、稼働時間を定めます。担当交代や成果物の扱いも決めておきます。一方で、請負では、仕様変更の承認と、追加見積もりの期限を定めます。

ソースコード・設計書・知的財産権の引き渡し

保守を続けるには、ソースコードに加えて必要な成果物と利用権を、契約で定めておく必要があります。

• 納品物：設計書、画面・API仕様、DB定義、移行関連の資料が入ります。テストやCI/CD、IaC、環境変数管理、監視・復旧手順、運用FAQも、納品物に含めます。
• 利用・移管：改変、第三者への再委託、別会社への保守移管を想定して、権利の範囲を合意します。
• OSS管理：Grails、プラグイン、依存ライブラリのライセンス、著作権表示、脆弱性修正の担当を分けて書き出します。

納品時には、ソースを発注者のリポジトリへ移し、第三者が開発環境を再現できるかを確かめます。著作権譲渡の契約では、第27条・第28条の権利を含むかを確認します。著作者人格権、受託者の汎用部品、OSSの範囲は、分けて記載します。

個人データと再委託の管理条件

顧客情報や従業員情報を扱う場合は、認証と認可だけでなく、委託先の管理条件も定めておく必要があります。

• 取扱条件：アクセス範囲と保存場所、ログ、事故連絡の方法を決め、返却・消去の扱いも示します。
• 再委託：再委託先の会社名や国・地域、担当、アクセス範囲を記し、事前報告・承認と監査方法も明らかにします。
• 技術管理：権限の分離や秘密情報の扱い、脆弱性スキャン、監査ログ、バックアップの暗号化を揃えておきます。

そのうえで、委託先の取扱いを継続して見ておきます。ガイドラインでは、安全管理措置の事前確認、契約への反映、取扱状況の定期把握が示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

クラウド運用会社や海外の開発会社へ委託する場合も、同じ条件で管理します。

Grailsのシステム発注にかかる費用相場とコスト内訳

Grails専用の国内価格統計は、公開情報では確認できません。そのため、以下の数字は、業務システム一般の2026年の目安や、要件の複雑さ、技術支援料金から推定した予算の仮説です。

RFPを作成する際の参考として使い、正式な見積もりとは分けて扱います。オープンソースであっても、設計や実装、テスト、移行、クラウド、保守には費用がかかります。

規模別の初期費用と開発期間の目安

費用と期間は、規模や連携範囲によって変わります。次に示すのは、要件から算出した推定レンジです。

この推定は、Grails特化の公的統計ではありません（出典: NotebookLM「Grailsのシステム」リサーチノート、2026年）。

• 小規模：PoC・部門ツールは100万〜500万円で、期間は1〜3か月です。数画面、CRUD、単一DB、限定ユーザーを想定します。
• 部門業務：ワークフロー、権限、帳票、マスタ、初期移行を含み、500万〜1,500万円、3〜6か月程度です。
• 複数部門：SaaS・API連携、移行、監査ログ、性能試験を含み、1,500万〜5,000万円、6〜12か月程度です。
• 基幹刷新：複雑な業務ルールや段階移行、高可用性、災害対策を伴う場合は、5,000万円〜1億円超、12〜24か月以上となる可能性があります。

人月単価と工数による見積もりの読み方

見積もりは、役割ごとの人月単価と人数、期間から読みます。以下の参考値は、Grails専用の相場ではありません。

• PG：単価の目安は50万〜90万円程度です。
• SE・PM：SEは65万〜110万円、PMは90万〜150万円程度です。
• 会社規模：中小の開発会社は80万〜120万円、大手SIerは150万〜200万円程度と整理されています。

単価は、実績や難易度、契約範囲によっても変わります（出典: NotebookLM Q&A「業務システム全般_18」、2026年）。

たとえば、平均100万円/人月の4人チームを6か月投入すると、体制だけで約2,400万円になります。

さらに、要件定義や移行、受入支援、クラウド、監視、診断を加えると、総額は2,500万〜4,000万円前後になる可能性があります。工程ごとの人月と、レビュー・テストの工数も確かめます。

初期費用以外に見込むランニングコスト

運用費は、サービス構成と保守範囲によって変わります。そのため、月額や年額の前提条件を、項目ごとに確かめておきます。

• 基盤費：コンピュート、DB、ストレージ、通信が対象です。バックアップ、監視、ログ、メール、認証も対象に含まれます。
• 保守費：初期費用の年15〜25％を仮置きする方法がありますが、これは規模やサービス水準の目安です。
• 別予算：Grails 6以前からの更新や、Java・Spring更新、脆弱性対応、クラウド監視は、別の予算として分けます。

月額費用は、利用者数やデータ量、可用性、ログ保存期間によっても変わります。保守の範囲では、障害対応時間、一次切り分け、脆弱性対応、軽微な改修、定例報告を分けて考えます。

OCIの時間単位の相談や支援パッケージは、コア開発チームの技術支援料金です。日本の開発会社への一括委託の相場ではありません（出典: Object Computing, Inc.公式サービス情報、2026年確認）。個別の保守範囲を確かめたうえで、予算に組み込みます。

RFP・見積比較・委託先選定で確認するポイント

金額の合計だけでは、提案の中身の違いが見えにくくなります。要件の解釈や前提、除外事項、体制を同じ形式で並べて比べます。続けて、工程、成果物、リスク、保守範囲も揃えて見ます。

Grails 7の対応可否と、Java・Spring・DB・クラウドの設計力は、別々に評価します。

RFPに含めるべき情報

提案の前提をそろえるため、RFPには業務・利用条件と非機能要件を記します。

• 業務情報：目的、課題、範囲、利用者数、拠点数を含めます。業務量、フロー、画面・帳票、権限も書きます。
• 移行・体制：連携、移行対象、希望時期、社内体制を記載します。
• 非機能：稼働・応答時間、同時利用者、可用性を示します。バックアップや復旧、ログ、セキュリティ、監査、個人情報も含めます。

提案依頼には、Grailsの採用理由と想定版、代替技術との比較を含めます。体制や担当者の経歴も書いてもらい、過去のGrails・Groovy・Java案件や、テスト・移行・運用引き継ぎの方針も確かめます。

見積書では、要件定義、設計、実装、テストを分けます。移行、教育、保守、クラウドも分けて、作業量の単位と前提を記載してもらいます。

開発会社を比較する5つの評価軸

提案内容は、技術の実績から保守体制まで、5つの軸で比べます。

• Grails経験：Grails 7系の新規開発と、6以前からの移行経験。
• 技術設計：Java・Spring・Hibernate・GORMの基盤、RDB、API、クラウドの設計力。
• 体制・移行：要件定義から運用までの責任者、データクレンジング、リハーサル、切り戻し計画。
• 品質・安全：認証・認可、監査ログ、脆弱性対応、バックアップ、障害対応。テスト自動化、CI/CD、レビュー、品質指標も確かめます。
• 継続・引き継ぎ：ソース、設計書、IaC、運用手順の引き渡しや、担当者・会社変更への備えです。保守SLAと再委託条件も含みます。

安い見積もりに潜むリスク

見積額の差は、含まれる作業と前提をそろえてから見ます。

• 安い見積もり：要件定義、レビュー、移行、受入支援、セキュリティ試験、文書が除外される可能性があります。
• 高い見積もり：管理費や予備費の内訳が不明なら比較できません。
• 金額差：同じ質問を各社に送り、結果を機能、工数、体制、リスク対応に分けて比べます。

「Grails対応」が、Grails 2だけを指すのか、Grails 7.2系を本番で扱えるのかも確かめます。「移行込み」とする場合は、設計、クレンジング、変換、リハーサル、検証、切り戻しのどこまでが範囲かも尋ねます。

提案の段階で具体的な質問をする会社は、発注後のリスクを早めに見つけられる可能性が高いです。

セキュリティの受入条件と見積もりの項目

「対策済み」という説明を受け取るだけでなく、確認方法そのものを受入条件に含めます。確認項目は、認証や権限、アプリの対策、運用の確認に分けて考えます。

• 認証・権限：認証方式、パスワードや多要素認証、ロールとテナントの分離。
• アプリ対策：CSRF・XSS、入力値検証、CORS、秘密情報の管理。
• 運用確認：監査ログ、依存ライブラリの脆弱性スキャン、受入テスト。

OWASPは2025年に、ASVS 5.0のリリース候補を公開しました。検証項目を洗い出す際の参照枠として使えます（出典: OWASP Foundation、2025年）。

個人データを扱う場合は、脆弱性診断に加えて、委託先のアクセス権限と、開発・検証環境へのデータ持ち出しを確認します。ログ保存、事故報告の期限、再委託先の管理も確かめます。

発注者が環境を監査できるかを決め、障害時の判断者と連絡先も定めておくと、稼働後の責任の線引きがはっきりします。

よくある質問（FAQ）

Grailsの発注では、技術や会社の継続性、移行、費用、契約、保守を並行して検討する必要があります。発注前によく寄せられる質問に答えます。

Grailsのシステム開発は2026年に外注しても問題ありませんか？

2026年時点でも新規開発の選択肢になりますが、版と周辺技術は委託先に確かめます。公式ドキュメントの現行版表示は7.2.2です。

Grails 7系は、Java 17以降、Groovy 4系、Spring Boot 3.5系などを基盤としています。そのため、現行版の開発や更新、保守を担当できるかを確かめます。

Grailsのシステム発注費用はどのくらいですか？

費用は要件によって大きく変わるため、推定レンジを参考にします。

• 小規模・部門：PoC・小規模部門ツール100万〜500万円、部門業務システム500万〜1,500万円。
• 複数部門・基幹：API連携型1,500万〜5,000万円、基幹刷新5,000万円〜1億円超。
• 見積もり：Grails専用の公開価格統計はありません。画面数だけでなく、利用者、権限、移行、連携、性能、保守を示したうえで、複数社に依頼します。

Grailsの経験がない会社へ発注しても大丈夫ですか？

Grailsの実績がなくても、Java、Spring、Hibernate、GORMに近い技術力とPoCの検証計画があれば候補になります。

提案書では、Grails 7系の互換性やプラグインを調べる計画が示されているかを確かめます。GSPやJSON Views、GORM、Spring Security、Gradle、テスト方法も、調査の対象になります。

重要な部分では、第三者レビューやコアチーム支援を組み合わせます。その判断の記録は、発注者側にも残しておきます。

既存のGrailsシステムは作り直すべきですか？

全面刷新の前に、Grailsの版やJava、プラグイン、依存ライブラリを一覧にします。テスト、DB、外部連携も洗い出します。

業務価値が高く変更の少ない機能は保守しながら、脆弱性や性能のリスクが高い機能から、Grails 7系へ段階的に移行する方法もあります。

既存と新システムをAPIで疎結合にし、機能単位で切り替える案を複数比べます。

まとめ

委託先は、知名度や総額だけでなく、業務の性質に合わせて選びます。まず業務をSaaS・パッケージ・スクラッチに分け、Grailsを使う範囲を定めます。

比べる観点は、Grails 7系や既存版の移行、Java・Spring・DBの設計力、要件定義から保守までの体制です。

発注前に決めること

まず、目的、対象業務、利用者、権限、データをRFPに整理します。さらに、連携、非機能要件、移行対象、希望時期、予算の前提も、RFPに書き出します。

変わりやすい要件は準委任やPoCに、完成条件が明確な部分は請負に分けます。そのうえで、検収、変更、成果物、知的財産権、再委託、保守SLAは、契約に反映します。

金額は、工程や役割、工数、除外事項まで分けて比べます。

委託先との長期運用

長期にわたって運用するには、成果物の引き渡しと、更新・保守の継続的な管理が必要です。

• 引き継ぎ：ソース、設計書、テスト結果、DB定義を受け取ります。CI/CD、監視、バックアップ、運用手順も引き継ぎの対象です。
• 継続管理：Grailsはオープンソースですが、更新、脆弱性対応、業務変更、クラウド費用の管理が必要です。

社内や別会社でも保守できる状態を作っておきます。RFPと契約を整え、現実的な範囲から始めることで、発注後の予算超過と保守停止を防ぎます。

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

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