AdonisJSのシステム開発を発注・外注するなら、フレームワーク名だけで会社を決めず、業務整理、RFP、契約、データ移行、保守までを一つの計画として比較することが重要です。
AdonisJSはNode.jsとTypeScriptを基盤に、認証、バリデーション、ORM、ルーティング、テストなどを規約に沿って組み立てやすいWebフレームワークです。本記事では、AdonisJSのシステムを外部へ委託する際の発注形態の選び方、要件の整理方法、契約形態、費用相場、委託先と見積書の比較ポイントを、2026年時点の情報を踏まえて解説します。
▼全体ガイドの記事
・AdonisJSのシステム開発の完全ガイド
AdonisJSのシステムを発注する前に知っておきたい全体像

AdonisJSを採用するかどうかは技術の好みだけでなく、データをどのように管理し、誰が何年保守するかで判断します。発注者が最初に整理すべきなのは、フレームワークの機能一覧ではなく、現場の業務、利用者、既存データ、外部連携、運用上の責任分界です。
AdonisJSはどのようなシステムに向いていますか?
AdonisJSは、顧客、商品、案件、受注、在庫、請求などのリレーショナルデータを扱う業務システムと相性が良いです。社内ポータル、申請・承認ワークフロー、CRM、受発注管理、予約管理、SaaSの管理画面、モバイルアプリ向けAPIなど、認証と権限を持つWebアプリケーションで採用を検討しやすいです。
ルーティング、Controller、バリデーション、Lucid ORM、認証、メール、キュー、ファイル保存などを公式パッケージで揃えやすいため、担当者ごとに構成がばらばらになるリスクを抑えられます。一方で、業務要件が複雑な場合は標準機能だけで完了するわけではなく、承認履歴、監査ログ、帳票、CSV、既存基幹システムとの連携は個別設計が必要です。
AdonisJSを指定して発注する際の注意点は何ですか?
AdonisJSはMITライセンスのオープンソースであり、通常はフレームワークのライセンス購入費が発生しません。ただし、ライセンス無料は開発費無料という意味ではありません。要件定義、画面設計、データ移行、テスト、クラウド構築、脆弱性診断、運用監視、将来のNode.jsやAdonisJSの更新に費用がかかります。
また、2026年に公開されたAdonisJS v7はNode.js 24以上を必要とし、公式ブログではStarter KitやTypeScriptの開発体験、公式パッケージの更新が案内されています。新規開発ならv7を候補にできますが、委託先には「v7で本番運用した実績があるか」「Node.jsの更新を誰が担当するか」「v6から移行する場合の影響範囲」を確認しておくと安心です。
AdonisJSのシステム発注・外注形態はどれを選びますか?

発注形態は、発注者側に要件を決める人材がいるか、開発会社にどこまで任せたいか、仕様変更が起きる可能性がどれほどあるかで決まります。固定価格で全部を任せる方法だけが正解ではなく、企画段階と開発段階で契約を分ける方法も有効です。
一括請負はどのような会社に向いていますか?
一括請負は、要件、納期、成果物、検収条件をある程度決めてから、設計・開発・テスト・リリースまでまとめて委託する方法です。社内にシステム開発の専任者が少なく、プロジェクト管理も含めて任せたい場合に向いています。責任の所在を整理しやすい反面、契約後に「この機能も必要だった」と判明すると、追加見積もりや納期変更になりやすいです。
請負で発注するなら、画面数だけでなく、業務ルール、権限、帳票、CSV、既存データの移行対象、外部API、同時利用者数、性能、バックアップ、納品物までRFPに記載します。「システム一式」のような曖昧な表現では、完成の基準をめぐって発注者と受託者の認識がずれるためです。
準委任・ラボ型開発はどのような場合に向いていますか?
準委任やラボ型開発は、月単位・期間単位でエンジニアやプロジェクトチームの稼働を確保し、優先順位を変えながら開発する方法です。AdonisJS v7の検証、既存システムとの連携、段階的なMVP開発など、開始時点で仕様を固めきれない案件に適しています。発注者が日々の優先順位を決め、受託者とバックログを更新できることが前提です。
この形態では、成果物の完成責任だけでなく、誰がプロダクトオーナー、PM、QA、インフラ担当になるかを明確にします。アサインされた人がAdonisJSに詳しくても、業務の意思決定者が不在なら進行が止まります。月の稼働時間、途中交代のルール、コードレビュー、引き継ぎ、未消化タスクの扱いも契約書と運用ルールに記載します。
企画と開発で発注先を分ける方法もありますか?
あります。最初に業務整理と要件定義だけをコンサルタントや上流に強い会社へ依頼し、その成果物を使って複数の開発会社から見積もりを取る方法です。発注者が要件を整理できていない場合でも、開発会社の提案力だけで比較するより、評価条件を揃えやすくなります。
ただし、上流会社と開発会社を分けると責任分界が増えるため、要件の解釈、設計書の著作権、変更管理、障害対応の窓口を決めておく必要があります。AdonisJSの技術選定も、上流で決めたまま固定せず、開発候補会社による短期PoCで認証、DB、帳票、外部連携を検証すると失敗を減らせます。
AdonisJSのシステム発注を成功させる要件整理とRFPの作り方

RFPは、開発会社へ提案と見積もりを依頼するための資料です。分厚い仕様書を最初から作る必要はありませんが、現状の課題、対象業務、利用者、データ、希望時期、予算の考え方、提案してほしい範囲を同じ形式で渡すことが大切です。発注者が知らない技術仕様まで断定するより、業務上の目的と制約を具体的に書く方が、提案の質を比較しやすくなります。
最初に業務・データ・利用者を棚卸しします
まず、現場が使っているExcel、紙、メール、チャット、FAX、既存システムを業務の流れに沿って並べます。受注から請求までの担当者、承認者、入力項目、例外処理、締め日、保存年限を確認し、商品コードや顧客名の表記揺れも調べます。マスタデータが整っていないまま移行を始めると、AdonisJSで画面を作っても検索や集計が正しく動かないためです。
RFPには、利用者数だけでなく、管理者、一般社員、取引先、外部委託先などのロールを記載します。部署ごとに見えるデータが異なるのか、承認を代理できるのか、退職者のアカウントをいつ停止するのかまで決めると、認証と認可の設計が具体化します。個人情報を扱う場合は、利用目的、保存期間、削除方法、委託先のアクセス範囲も要件に含めます。
機能要件と非機能要件を分けて書きます
機能要件には、ログイン、顧客登録、検索、承認、通知、CSV入出力、帳票、外部APIなど、システムでできることを書きます。非機能要件には、同時利用者数、画面の応答時間、稼働時間、バックアップ、復旧目標、監査ログ、アクセス権限、アクセシビリティ、障害時の連絡体制を書きます。たとえば「速い画面」ではなく「通常検索は3秒以内、同時利用者は100人」のように、検証できる表現にします。
AdonisJSの構成もRFPの確認事項にします。Edgeでサーバーサイドレンダリングするのか、InertiaとReactまたはVueを使うのか、API専用にして将来モバイルアプリと接続するのかで、必要な設計とテストが変わります。データベース、ファイル保存、メール、キュー、監視、CI/CD、クラウド環境については、指定する項目と提案を求める項目を分けて記載すると、会社ごとの提案力を比較できます。
Must・Should・Couldで優先順位を付けます
要望をすべて初回リリースに入れると、費用と納期が膨らみます。そこで、業務を止めないために必須のMust、初期リリース後でもよいShould、効果を検証してから判断するCouldに分けます。たとえば受注登録、権限、CSV、請求データ連携をMustにし、高度なダッシュボードやAIによる予測をCouldにする、といった整理です。
優先順位は経営者だけで決めず、実際に入力・承認・確認をする現場と合意します。現場を無視してトップダウンで要件を決めると、導入後にExcelへ戻る、二重入力が増える、例外処理だけ手作業になるといった問題が起きます。RFPに優先順位と判断理由を残せば、見積もり削減が必要になったときも、重要な業務を守りながら調整できます。
AdonisJSのシステム開発を発注してから納品するまでの進め方

発注後は、要件定義、設計、実装、テスト、移行、リリース、保守の順で進めます。ただし、工程を一度きりのリレーにせず、重要な業務を小さな試作で確認しながら進めることが大切です。特にAdonisJSを初めて採用する場合は、早い段階で技術と業務の両方を確認します。
要件定義では何を成果物にしますか?
要件定義では、業務フロー、画面一覧、権限一覧、データ項目、外部連携一覧、移行方針、非機能要件、受入条件を成果物にします。画面の見た目だけでなく、入力したデータがどの状態を通り、誰が変更でき、どの時点で通知や帳票が出るのかを確認します。設計に入る前に業務担当者がレビューし、承認者を明確にすることが重要です。
データ移行は、開発の終盤に一度だけ行う作業ではありません。抽出、名寄せ、不要データの判断、変換、テスト移行、本番移行、移行後の照合までを計画します。旧システムのIDを新システムでどう扱うか、履歴を何年分残すか、移行できない添付ファイルをどう保管するかを決めないと、リリース直前に大幅な追加費用が発生します。
小さなPoCで何を検証しますか?
PoCでは、実際に難しそうな機能を一つの流れとして動かします。ログインとロール別権限、Lucid ORMによるデータ登録、ファイルアップロード、帳票、外部API、メール通知、CI/CD、監視を候補にします。5画面の見本を作るより、最も不確実な連携や権限を検証した方が、発注後のリスクを早く見つけられます。
PoCの目的は、そのまま本番コードを完成させることではありません。AdonisJS v7とNode.js 24の実行環境、開発メンバーの技術力、既存システムとの接続可否、応答性能、運用担当が扱えるログの粒度を確認することです。PoCの成果物、検証期間、含める機能、失敗した場合の扱いを、契約前に書面で合意します。
テストとリリース判定をどのように行いますか?
テストは、単体テストだけでなく、機能間の結合テスト、業務シナリオによる総合テスト、権限テスト、移行データの照合、性能テスト、脆弱性診断までを計画します。受託会社が用意するテスト仕様書だけでなく、現場担当者が実際の一日を再現できる受入テストを用意します。注文登録、承認差戻し、請求確定、退職者の権限停止など、通常系と例外系の両方を含めます。
リリース判定には、未解決の不具合の基準、バックアップ取得、ロールバック手順、問い合わせ窓口、初期サポート期間を含めます。納品したソースコードが手元にあるだけでは運用できないため、デプロイ手順、環境変数一覧、DBマイグレーション手順、監視項目、障害時の連絡先も引き渡し対象にします。
AdonisJSのシステム開発で選ぶ契約形態と責任分界

契約形態は、費用だけでなく、仕様変更の扱い、瑕疵対応、知的財産、情報管理、途中解約、保守への移行を左右します。法務担当や顧問弁護士にも確認しながら、開発会社のひな形をそのまま受け取らず、案件の実態に合わせて調整します。
請負契約と準委任契約はどのように使い分けますか?
請負契約は、合意した成果物を完成させ、検収することを軸にします。要件が固まった開発や、決められた範囲の追加機能に向いています。準委任契約は、専門家の業務遂行を依頼する形で、月次の稼働やチーム支援に向いています。探索的なPoCや段階的な改善では準委任、仕様と検収条件が明確な本番開発では請負、という使い分けが一般的です。
両者を組み合わせる場合は、要件定義・PoCを準委任で行い、仕様が固まった後の開発を請負にする方法があります。契約を分ける場合も、成果物の再利用、ソースコードの権利、未完成部分の引き継ぎ、次工程へ進まない場合の精算方法を事前に定めます。
納品物とソースコードの権利を決めます
納品物には、ソースコード、設計書、画面仕様、API仕様、DB定義、テスト仕様書と結果、移行手順、デプロイ手順、運用マニュアル、環境構築手順を含めます。Gitリポジトリの管理者、クラウドアカウントの名義、CI/CDの設定、外部サービスの契約者も発注者側で確認します。納品時にファイルを受け取るだけでは、別会社への保守移管が難しくなるためです。
ソースコードの著作権、オープンソースの利用条件、第三者ライブラリの一覧、発注者が改変・再委託できる範囲を契約に記載します。AdonisJS本体や公式パッケージのライセンスだけでなく、採用するUI、帳票、監視、認証関連のライブラリにも確認が必要です。再委託先がある場合は、再委託先の国、アクセス可能な情報、秘密保持、終了時の削除方法も明らかにします。
保守契約ではどこまでを含めますか?
保守契約では、問い合わせ対応、障害復旧、軽微な修正、OS・Node.js・AdonisJSの更新、依存パッケージの脆弱性対応、バックアップ確認、監視、定例報告を分けて記載します。月額保守に含まれない大規模改修や新しい業務機能は、別途見積もりにするのが通常です。障害の重要度ごとの初動時間、復旧目標、受付時間、休日対応も確認します。
AdonisJS v6からv7へ移行する場合は、Node.jsの実行環境、暗号化ドライバー、依存パッケージ、テスト、デプロイ設定の確認が必要です。将来のバージョンアップを誰が判断し、検証環境で何をテストし、更新費用をどの予算から出すかを決めておくと、保守会社に任せきりになる状態を防げます。
AdonisJSのシステム開発費用・相場と見積もりの内訳

AdonisJS固有の国内受託価格表は公開情報が限られるため、次の金額は業務システム一般の2026年公開目安と、AdonisJSのライセンス費が通常発生しない点を踏まえた見積もり前のレンジです。特定の会社が提示する料金ではなく、画面数、連携数、データ移行量、セキュリティ要件、チーム構成で大きく変わります。
規模別の費用相場はいくらですか?
小規模な社内申請、日報、マスタ管理であれば、初期費用は100万〜300万円、期間は2〜4か月が一つの目安です。ログイン、権限、5〜15画面程度の登録・検索、CSV、簡易帳票を想定したレンジです。単一業務のカスタムシステムについて、2026年公開の費用情報でも100万〜500万円程度の目安が示されており、要件の深さによって幅が出ます(出典:SIA株式会社・Cataly Design、2026年)。
CRM、受発注、案件管理など標準的な業務支援システムは300万〜800万円、期間は4〜8か月程度が目安です。20〜50画面、複数ロール、承認、検索、帳票、外部API、テスト、クラウド構築を含む想定です。複数部門の在庫・販売・案件管理なら800万〜2,000万円、基幹連携やレガシー移行を含む大規模スクラッチなら2,000万〜5,000万円以上になる場合があります。いずれもAdonisJSだけの価格ではなく、業務システム開発全体の推定です。
見積書ではどの工程の費用を確認しますか?
工程別の目安は、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%、製造・単体テスト30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%です。これは固定ルールではなく、比較のための目安です。開発費だけが安くても、要件定義やテスト、移行が別料金なら、総額では高くなることがあります。
見積書では、人件費のほかにクラウド、ドメイン、メール、監視、バックアップ、ストレージ、外部API、脆弱性診断、負荷試験、データ移行、教育、リリース立会いを確認します。個人情報、決済、医療、自治体、24時間運用では、WAF、冗長化、DR、SLA、監査ログなどが増え、初期費用と月額費用が上振れします。
運用保守費用はどの程度を見込みますか?
運用保守は、初期開発費の年10〜20%程度を予算化する方法があります。初期開発800万円なら、単純計算で年間80万〜160万円、月額約6.7万〜13.3万円が目安になります。ただし、これは軽微な修正や問い合わせ、定期更新を想定した試算であり、24時間監視、休日対応、脆弱性診断、大規模な機能追加、クラウド利用料を含むかで変わります。
費用を抑えるには、初回リリースを単一業務のMVPに絞り、モジュール型のモノリス、マネージドPostgreSQLまたはMySQL、S3互換ストレージ、Docker、CI/CDなど、運用しやすい構成から始めます。最初から全社ERP、複雑なワークフロー、全履歴移行、AI、マイクロサービスを同時に求めると、AdonisJSの開発効率より要件の複雑さが費用を決めます。
AdonisJSの委託先選定と見積比較で確認するポイント

委託先は、AdonisJSという単語を掲載しているかだけでなく、業務システムを本番運用まで支えられるかで選びます。公開実績が少ない技術だからこそ、実績の有無を質問し、担当者との技術面談やPoCで確かめることが大切です。
AdonisJSの実績はどのように確認しますか?
「AdonisJSに対応できます」という説明だけでなく、本番稼働しているシステムの規模、利用者数、画面数、AdonisJSの担当範囲、採用バージョン、Node.jsのバージョン、障害対応の経験を確認します。顧客名を開示できない場合でも、匿名化した画面、構成図、テスト方針、課題と解決方法を説明できるかを見ます。MindKが公開するCEMAsysの事例では、AngularとNestJSを中核にしつつ、レポート・計画領域のマイクロサービスでAdonisJSを使ったと説明されています。採用範囲を具体的に説明できる事例は、技術の使いどころを見極める材料になります。
面談では、認証と認可の設計、権限変更の監査ログ、トランザクション、CSVの大量処理、帳票、ファイル保存、外部APIのリトライ、バッチ、テスト、監視について質問します。フレームワークの機能を列挙するだけでなく、業務ルールをServiceやドメインロジックにどう分け、将来の変更をどう安全に行うかを説明できる会社が望ましいです。
見積もりは金額以外に何を比較しますか?
見積比較では、総額、期間、体制、前提条件、対象外、支払い条件、検収、保証、保守、納品物を横並びにします。開発会社ごとに画面数、テスト範囲、移行件数、外部連携、クラウド費用の含め方が異なるため、安い見積もりが同じ品質を意味するとは限りません。RFPには、業務範囲、画面数、利用者数、既存DB、外部連携、データ移行、希望納期、予算、SLAを同じ条件で書きます。
見積書の内訳が「開発一式」だけなら、作業分解を依頼します。要件定義、UI設計、バックエンド、フロントエンド、データ移行、テスト、インフラ、教育、リリース、保守を分けてもらい、削減する場合にどの品質や機能が変わるか確認します。担当者の経験年数や稼働率、再委託の有無、会議の回数、レビューの方法も、完成度と費用に影響します。
セキュリティと運用体制は誰が担いますか?
AdonisJSが安全な機能を提供していても、設定、実装、クラウド、運用のすべてが自動的に安全になるわけではありません。認証、認可、CSRF、CORS、レート制限、パスワードのハッシュ化、秘密情報の管理、HTTPS、最小権限、操作ログ、バックアップを要件に含めます。AdonisJS公式ドキュメントでも、レート制限はログインの総当たり攻撃や高負荷APIの乱用を抑えるために利用できると説明されています。
IPAの「安全なウェブサイトの作り方」は、SQLインジェクション、クロスサイト・スクリプティング、CSRF、アクセス制御の欠落などを代表的な確認項目として挙げています。SQLを文字列連結で組み立てず、入力値を適切に検証・エスケープし、認証済みであることと権限があることを別々に確認する設計を依頼します(出典:IPA「安全なウェブサイトの作り方」)。個人情報を扱う場合は、個人情報保護委員会の安全管理措置を踏まえ、委託先のアクセス範囲と漏えい時の連絡手順も契約に記載します。
AdonisJSのシステム発注で起こりやすい失敗と対策

失敗の原因は、AdonisJSという技術そのものより、業務・データ・責任分界の整理不足にあることが多いです。発注前に起こりやすいパターンを知り、RFP、契約、会議体、受入テストに対策を組み込みます。
要望が膨らみ続ける場合はどうしますか?
要望が増えること自体は珍しくありませんが、すべてを初回リリースに積み上げると、予算超過と納期遅延が起きます。Must・Should・Couldの優先順位を定例会議で見直し、追加要望は影響する画面、データ、テスト、納期、費用を記録して承認します。小さなMVPを先に本番利用し、利用状況と現場の声を見ながら拡張する方が、過剰なカスタマイズを避けやすいです。
ベンダーロックインを防ぐには何を受け取りますか?
納品物不足によるベンダーロックインを防ぐには、ソースコードだけでなく、設計書、DB定義、API仕様、テスト結果、インフラ構成、環境変数の項目、デプロイ手順、監視設定、運用マニュアルを受け取ります。Git、クラウド、ドメイン、外部サービスの管理者権限を発注者側で管理し、開発会社の個人アカウントや担当者だけに依存しない構成にします。
契約終了時の引き継ぎ期間、資料の更新責任、問い合わせへの回答期限、データ返却と削除、第三者への再委託を契約で決めます。保守会社を変更する可能性を前提に、年1回は別の技術者が環境を再現できるか確認することも有効です。
現場に定着させるには何が必要ですか?
システムを導入しても、現場の手順やマスタが変わらなければ効果は出ません。業務責任者、現場のキーユーザー、情報システム担当、経理や法務などの関係者を早期に巻き込み、操作説明、移行リハーサル、問い合わせの受付方法を決めます。旧Excelをいつ停止するか、二重管理をいつ終えるかも経営判断として明確にします。
AdonisJSの採用判断は、開発会社だけに任せず、発注者側にも小さな技術窓口を置きます。Node.jsとTypeScriptの更新、脆弱性情報、ログの確認、バックアップの復元テストなど、保守で必要な判断をできる人を決めると、リリース後の運用が安定します。
よくある質問

AdonisJSのシステムを発注する際に、特に相談が多い疑問をまとめます。技術の可否だけでなく、費用、保守、セキュリティ、発注先選びの判断材料としてご確認ください。
AdonisJSのシステムは無料で開発できますか?
AdonisJS本体と公式パッケージはMITライセンスで、通常はライセンス購入費なしで利用できます。ただし、要件定義、設計、製造、テスト、クラウド、データ移行、保守の人件費は必要です。無料なのは技術基盤のライセンス費であり、システム全体の開発費ではありません。
AdonisJS v6からv7へ移行するシステムも外注できますか?
外注できますが、Node.js 24以上への対応、依存パッケージ、暗号化ドライバー、認証、ビルド、テスト、デプロイ環境の影響を調べてから計画します。既存コードの棚卸し、検証環境での移行、回帰テスト、本番切り戻し手順を含めた移行見積もりを依頼してください。単なるバージョン番号の置き換えとして扱うと、リリース後の障害を見落とす可能性があります。
AdonisJSの対応会社はどのように探せばよいですか?
AdonisJSの公開実績、担当者の本番経験、Node.js 24とv7への対応、業務システムの要件定義・移行・保守の実績を確認し、同じRFPで複数社へ相談します。実績を公開できない場合でも、構成、課題、テスト、運用体制を匿名で説明できるかを見ます。価格だけでなく、納品物、セキュリティ、将来の引き継ぎ、契約終了時の対応まで比較することが大切です。
まとめ

AdonisJSのシステムを発注・外注するときは、フレームワークの採用可否を先に決めるのではなく、現場の業務、データ、利用者、権限、外部連携、非機能要件を整理します。そのうえで、請負、準委任、PoCと本開発の分割など、案件の不確実性に合った発注形態を選びます。
発注前に確認するポイント
見積もりは、初期費用だけでなく、要件定義、データ移行、テスト、クラウド、保守、脆弱性対応まで含めて比較します。AdonisJSの実績は、掲載の有無ではなく、担当範囲、本番環境、バージョン、テスト、障害対応を確認します。ソースコード、設計書、テスト結果、運用手順、アカウント管理、引き継ぎ条件を契約に含めることが、将来のベンダーロックインを防ぎます。
最初の相談で準備するもの
最初の相談では、現行業務の流れ、画面や帳票の一覧、利用者と権限、既存データの件数、外部連携、希望時期、予算の幅、保守体制を準備します。要件が完全でなくても問題ありませんが、分からない項目を分からないまま明示すると、開発会社から必要な調査やPoCを提案してもらえます。複数社へ同じ情報を渡し、技術・業務・費用・契約・保守を総合的に比べてください。
▼全体ガイドの記事
・AdonisJSのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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