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

Expoのシステム開発を発注・外注するなら、Expoの利用可否だけで会社を決めず、要件整理、バックエンド連携、ストア申請、SDK更新、リリース後の保守まで含めて委託範囲と責任分界を先に定義することが重要です。

ExpoはiOSとAndroidのアプリを効率よく開発できる一方、業務データを保存するAPIやデータベース、権限管理、監査ログ、運用体制まで自動で用意してくれる製品ではありません。本記事では、Expoのシステム開発を外注するときの発注形態の選び方、RFPと要件の整理方法、契約形態、費用相場、委託先の選定と見積比較のポイントを、発注担当者が社内で説明できる順番で解説します。

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

Expoのシステム開発を外注する前に知る全体像

Expoの発注では、アプリの画面を作る費用だけを比較すると判断を誤りやすくなります。スマートフォン側のアプリ、業務ロジックを担うバックエンド、管理者向け画面、クラウド環境、ストア公開、運用監視を一つのサービスとして捉えることが出発点です。

Expoは、JavaScriptまたはTypeScriptとReactを使ってiOS・Androidアプリを開発するためのフレームワークとツール群です。React Nativeが共通のUIとロジックを動かす土台であり、Expo SDKがカメラ、通知、位置情報、ファイルなどの機能を扱いやすくし、EASがビルド、ストア提出、更新の作業を支援します。発注時には「Expoで作る」という一言だけでなく、Expo SDKのバージョン、Expo Routerの採用、EAS Build・Submit・Updateの利用範囲、ネイティブモジュールの追加方法まで確認する必要があります。

特にExpo Goは学習や簡単な動作確認に便利ですが、実案件で独自のネイティブ機能を組み込む場合はdevelopment buildを使う場面が増えます。Expo Goで動く試作品を見せられただけでは、実際の端末、認証、プッシュ通知、カメラ、オフライン処理を含む本番品質を確認したことになりません。委託先には、開発ビルドから本番ビルドまでの手順を実機で説明してもらいます。

業務用のExpoアプリでは、ログイン、権限管理、顧客・商品・案件・在庫の検索と登録、写真添付、バーコード、位置情報、プッシュ通知、承認、CSV、管理者画面などがよく求められます。これらのデータはアプリ内だけに保存せず、認証、業務ロジック、データベース、監査ログをバックエンド側で管理する設計が基本です。アプリの画面数だけで見積を依頼すると、API設計、データ移行、管理画面、帳票、障害監視が後から追加される可能性があります。

発注前に、委託先へ依頼する作業を「企画・要件定義」「UI・UX設計」「アプリ開発」「API・管理画面開発」「クラウド構築」「テスト」「ストア申請」「運用保守」に分けます。自社が用意するものは、業務ルール、マスタデータ、承認者、既存システムの仕様、アカウント、受入担当者です。双方の分担を文書化すると、安い見積に見えた会社が実は多くの作業を対象外にしていたという事態を防げます。

Expoは、iOSとAndroidに同じ業務フローを提供したい案件、カメラ・通知・位置情報・ファイルなどを使う案件、短期間でMVPを検証したい案件と相性がよいです。共通コードを活用できるため、2つのOSを個別に開発するより、画面や業務ロジックの重複を抑えやすくなります。ただし、共通化できる割合は機能やライブラリによって変わり、要件定義やテストの費用まで半分になるわけではありません。

特殊な端末SDK、重い3D・動画処理、厳しいバックグラウンド制御、OS固有の高度な機能が中心なら、Swift・Kotlinによるネイティブ開発や、Expoとネイティブを組み合わせるBrownfieldも比較します。委託先には「Expoで作れるか」だけではなく、「Expoを採用しない方がよい機能は何か」「追加モジュールを誰が保守するか」を質問します。採用を先に決めず、代表機能で技術検証を行ってから契約することが安全です。

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

発注は、会社探しから始めるより、社内の課題と成果を整理してから候補会社へ同じ資料を渡す方が比較しやすくなります。おすすめは、業務棚卸し、発注形態の決定、RFP作成、提案・見積比較、技術検証、要件定義、開発、受入、リリース、保守という流れです。案件の規模に応じて工程をまとめても、判断の順番は大きく変えないことが大切です。

新規に業務アプリを作る場合は、MVPの範囲を切り出して初期開発を依頼します。既存のReact NativeアプリをExpoへ寄せる場合は、まず依存ライブラリ、ネイティブコード、署名鍵、ストア公開環境を調査する移行診断を発注します。アイデア段階で不確実性が高い場合は、カメラ、通知、オフライン、既存API連携などの難所を2〜6週間程度の技術検証として切り出し、その成果を本開発の見積に反映させる方法が有効です。

すべてを一括で委託する一括請負は窓口を一本化しやすい一方、要件が曖昧なままでは追加費用の調整が難しくなります。自社が業務設計と優先順位を持ち、委託先と短いサイクルで作る場合は準委任やラボ型が向きます。発注形態は会社の得意不得意ではなく、要件の確定度、社内にプロダクトオーナーがいるか、変更がどの程度発生するかで決めます。

要件定義では、誰が、どの場面で、何を入力し、どの判断を行い、どんな結果を残すのかを業務フローで表現します。例えば訪問先で写真を撮影する業務なら、撮影枚数、圏外時の保存、再送、位置情報の扱い、上長の承認、削除期限、管理画面での検索まで決めます。「写真を登録できる」という一文だけでは、実装範囲もテスト範囲も確定しません。

受入条件には、正常系だけでなく、通信断、権限不足、重複送信、端末の再起動、OSアップデート、ストア審査差し戻し時の対応を含めます。画面単位の完成ではなく、現場担当者が業務を最後まで完了できることを受入の単位にします。納品物はアプリのソースコードだけでなく、API仕様書、画面仕様、テスト結果、環境構築手順、EAS設定、署名鍵の管理手順、運用マニュアルまで明記します。

開発は、画面の見た目を確認するプロトタイプ、APIと主要業務をつなぐMVP、現場を含む受入テスト、段階リリースの順に進めます。iOSとAndroidの両方で、機種差、画面サイズ、権限ダイアログ、通知、通信速度、電池消費を確認します。委託先から週次でデモを受け、課題、変更、判断待ちを一覧で共有すると、完成間際に業務上の大きな手戻りが発生しにくくなります。

EAS UpdateでJavaScriptやアセットを配信できる場合でも、ネイティブコード、権限、SDK、ランタイムに関わる変更は新しいストアビルドが必要です。production用のchannelとruntime version、更新承認者、段階配信、ロールバック手順を決めておきます。ストアへの提出は納品日に一度行えば終わりではなく、審査差し戻しやOS更新を含む運用工程として見積に含めます。

Expoの外注でRFP・要件整理に書く内容

RFPは、委託先から同じ条件の提案と見積を受け取るための資料です。長い機能一覧だけではなく、事業目的、現場の課題、対象ユーザー、期限、予算の考え方、既存環境、期待する成果、提案してほしい範囲を記載します。Expoを指定する場合でも、採用理由と変更可能な条件を分けて書くと、技術的に無理のない提案を受けやすくなります。

まず、利用者を管理者、営業担当、現場作業者、顧客などに分け、それぞれが使う端末と権限を定義します。次に、紙やExcelをなくす、入力時間を短縮する、承認漏れを減らす、在庫の最新状態を共有するなど、導入後に測る成果を決めます。成果指標があると、便利そうな機能を無制限に追加するのではなく、MVPに含める機能と後回しにする機能を判断しやすくなります。

機能一覧には、優先度をMust、Should、Couldなどで付けます。ログイン、ユーザー・権限、マスタ、検索・登録、通知、写真、帳票、CSV、管理画面、外部API連携などを、画面数ではなく業務シナリオで整理します。既存のERP、CRM、会計、在庫、勤怠などと連携する場合は、APIの有無、データ項目、更新頻度、エラー時の再送、連携元の責任者もRFPに含めます。

アプリの使いやすさだけでなく、同時利用者数、対応OSと端末、通信できない場所での動作、表示速度、稼働時間、バックアップ、復旧目標、ログ保存期間、データ保持期間を定義します。例えば「現場では圏外になる」と書くだけでなく、圏外で登録できるデータ、端末に保持する期間、再接続時の同期方法、競合が起きた場合の優先ルールまで確認します。

個人情報や機密情報を扱うなら、TLS、最小権限のAPI認可、管理者の多要素認証、端末紛失時のセッション失効、操作・ログイン・データ出力の監査ログ、バックアップと復旧テストを要件にします。トークンや秘密鍵をソースコード、ログ、AsyncStorageに置かないこと、端末側の秘密情報はOSの保護領域を利用することも確認します。委託先の再委託、国外のクラウドやサポート拠点、脆弱性対応の期限もRFPに明記します。

納品物には、ソースコード、リポジトリの履歴、画面・API・DBの設計書、環境変数一覧、テスト仕様書と結果、既知の課題、EASのプロジェクト設定、ストア申請情報、運用手順書を含めます。GitHubやExpoの組織アカウント、Apple Developer、Google Play Console、クラウドの契約者と所有者を誰にするかも決めます。委託先のアカウントだけで運用を始めると、契約終了時に移管できないリスクがあります。

保守では、OS対応、Expo SDK更新、依存ライブラリ更新、ストア審査、障害一次対応、監視、バックアップ、軽微改修を分けて、月額に含む範囲と別見積の範囲を定めます。問い合わせの受付時間、一次回答、復旧目標、緊急時の連絡先、リリース承認者も契約書やSLAに記載します。開発費が安くても、毎回のOS対応が都度見積になる場合は、数年分の総費用で比較する必要があります。

Expoのシステム開発で選ぶ契約形態と責任分界

契約形態は、完成させる成果物を重視するのか、専門人材の稼働と継続的な改善を重視するのかで選びます。名前だけで判断せず、契約対象、成果の定義、変更管理、検収、知的財産、再委託、秘密保持、損害賠償、終了時の引き継ぎを確認します。法務や情報システム部門とも相談し、案件の実態に合う契約にすることが大切です。

請負契約は、合意した成果物を完成させ、検収を受ける形に向いています。画面、API、管理画面、テスト、ストア公開などの納品範囲と、いつ何をもって完成とするかを具体化できる案件で使いやすい契約です。要件が固まっていれば予算を管理しやすい一方、開発中に業務ルールが大きく変わると、変更が追加契約になりやすい点に注意します。

Expo案件では「iOSとAndroidのアプリを納品する」だけでは不十分です。対応OS、対象端末、ログインや通知などの受入シナリオ、APIのエラー処理、ストア申請の回数、ソースコードの納品、EASと署名鍵の移管を成果物に含めます。検収後に見つかった不具合の無償修正期間と、仕様変更との区別も契約書や個別仕様書で明らかにします。

準委任契約は、専門家の知識や作業を一定期間提供してもらう形に向いています。要件を一緒に整理しながら優先順位を変える案件、既存アプリの調査や移行、継続的な改善、社内チームとの共同開発で使いやすい契約です。稼働時間、担当者の役割、会議体、成果の共有方法、作業報告を定め、完成責任と混同しないようにします。

準委任でも品質管理が曖昧になってよいわけではありません。スプリントごとの目標、コードレビュー、テスト結果、未解決課題、次の判断事項を成果として共有します。作業時間だけを管理すると、API仕様の不足やテスト漏れが発見しにくくなります。発注側にもプロダクトオーナーと意思決定者を置き、回答の遅れでチームが待機しないようにします。

全工程を一つの契約にせず、初期の要件定義や技術検証を準委任、本開発の確定した範囲を請負、リリース後を保守契約とする組み合わせも現実的です。これにより、難所を確認してから固定価格を決められます。ただし、契約を分けると境界の引き継ぎが問題になるため、設計書、議事録、リポジトリ、課題管理、決定事項を次の工程へ正式に渡します。

ソースコード、デザイン、API仕様、ドメイン、クラウド、AppleとGoogleの開発者アカウント、Expo組織、署名鍵の所有者は発注側に置くことを基本にします。委託先が管理する場合は、アクセス権限、保管方法、退職者の削除、契約終了時の返却・移管期限を決めます。第三者ライブラリのライセンス、オープンソースの表示義務、生成物の権利も納品条件に含めます。

Expoのシステム開発費用相場と見積の内訳

Expoを用いる業務アプリの外注費は、画面数だけでなく、バックエンド、既存システム連携、端末機能、オフライン同期、個人情報、テスト、ストア対応、保守の範囲で大きく変わります。公的な「Expo開発会社の平均価格」は確認できないため、以下は業務システム一般の相場と、Expo・React Nativeで共通化できる部分を踏まえた推定レンジです。提案依頼では、必ず自社の要件に置き換えてもらいます。

小規模MVPや社内検証で、主要5〜10画面、ログイン、簡易API、iOS・Androidビルドまでなら、初期開発費は300万〜800万円程度が一つの推定レンジです。10〜30画面に権限管理、通知、写真・検索、管理画面、外部API連携を加える標準的な業務アプリでは、800万〜2,000万円程度が目安になります。要件定義の深さ、デザイン、データ移行、テストの範囲で上下します。

複数業務との連携、オフライン同期、決済、監査、負荷試験、既存アプリからの移行を含む顧客向け・複雑なアプリでは、2,000万〜5,000万円超になる可能性があります。ERPやWMSなどの基幹連携、複数組織、24時間運用、段階移行まで含む大規模案件は、5,000万円から数億円規模になることもあります。これらは市場の統計値ではなく、業務システム相場を基にした推定です（出典: NotebookLMリサーチノート「Expoのシステム」、2026年）。

見積を比較するときは、総額より工程別の配分を見ます。業務システム一般の目安として、要件定義は総額の10〜15%、設計は15〜20%、開発は30〜40%、結合・総合テストは15〜20%、移行・導入は5〜10%程度という整理があります（出典: NotebookLMリサーチノート「Expoのシステム」、2026年）。Expo案件でも、アプリの共通化による効率だけでなく、API、管理画面、端末検証、ストア対応を別工程として確認します。

見積書には、画面数、API本数、外部連携数、対応OS・端末、テスト端末、デザイン、データ移行、ストア申請、プロジェクト管理、ドキュメント、予備工数を明示してもらいます。「一式」と書かれた項目は、含まれる作業、回数、前提、対象外を質問します。自社の確認待ちや既存システム側の改修が別料金なら、その条件も総額と一緒に並べます。

EASの料金は、開発会社の人件費とは別に発生します。Expo公式料金表では、Freeは月額0ドル、Starterは月額19ドルで45ドル分のBuild credit、Productionは月額199ドルで225ドル分のBuild creditが含まれ、超過利用は従量課金です。FreeはAndroid・iOSそれぞれ月15ビルドまで、Productionは月5万MAUまで更新を送信できると説明されています（出典: Expo公式料金表、2026年8月確認）。ただし、料金と条件は改定されるため、契約時に公式ページを再確認します。

このほかにApple・Googleの開発者アカウント、クラウド、データベース、監視、クラッシュ分析、メール・通知などの外部サービス、端末購入、保守費がかかります。保守は初期開発費の年10〜20%程度を一つの目安にできますが、OS・SDK対応、障害対応、監視、軽微改修、セキュリティ診断をどこまで含むかで変わります。月額だけでなく、1年目から3年目までの総保有コストを比較します。

Expoの委託先選定と見積比較のポイント

委託先を選ぶときは、会社の知名度や「React Native対応」という表記だけでなく、ExpoとEASを使った実案件の深さを確認します。提案書に書かれた技術名より、担当者が難所を質問し、できないことや追加費用の条件を説明できるかを重視します。見積の安さは評価項目の一つですが、品質、運用、移管まで含めたリスクも同じ重さで比較します。

候補会社には、直近のExpo SDKの採用案件、EAS Build・Submit・Updateの運用実績、development buildの利用経験、Config PluginsやExpo Modulesによるネイティブ拡張の経験を確認します。実績を見せてもらうときは、公開アプリの画面だけでなく、どのような要件をExpoで実現し、どこをネイティブで補い、SDK更新をどう行ったかを質問します。秘密保持のため詳細を見せられない場合は、匿名化した設計資料や説明でも判断材料になります。

2026年時点では、Expo SDK 55以降はNew Architectureを無効化できません。Expo公式ドキュメントでも、SDK 54以前は移行期間としてLegacy Architectureを選べる一方、SDK 55以降はNew Architectureが常時有効と説明されています（出典: Expo公式「React Native’s New Architecture」、2026年8月確認）。候補会社には、採用する第三者ライブラリが対応しているか、移行時のテストとロールバックをどう設計するかを確認します。

相見積では、RFP、画面イメージ、業務フロー、対象端末、既存APIの情報、希望時期を同じ資料で渡します。比較表には、要件定義、UI設計、アプリ、バックエンド、管理画面、テスト、ストア申請、移行、ドキュメント、保守を縦に並べ、各社の金額、工数、期間、担当、対象外を記録します。機能が同じでも、テスト端末が2台と10台、ストア申請が1回と審査完了まで、保守が月10時間と無制限では価格の意味が異なります。

見積差が大きいときは、単価よりも前提条件の差を探します。要件定義が含まれていない、管理画面が対象外、既存システム側の改修を発注側負担としている、テストやデータ移行を別料金にしている、ストア公開を支援しないといった違いが典型です。候補会社に同じ質問をし、回答を文書に残してから価格を比較します。

面談では、担当予定者が本番リリース後も関わるか、要件変更をどう管理するか、障害をどのように切り分けるかを質問します。「Expo Goで対応できますか」「独自ネイティブ機能が必要になったらどうしますか」「SDK更新でライブラリが動かなくなったら誰が調査しますか」「EASの署名鍵と本番環境を誰が所有しますか」といった質問は、技術力だけでなく責任分界も確認できます。

また、納期遅延、ストア審査の差し戻し、外部APIの遅延、データ移行の失敗、担当者の離脱、契約終了時の引き継ぎを想定した回答を求めます。リスクを「起きない」と言い切る会社より、起きた場合の検知、暫定対応、報告、復旧、再発防止を具体的に説明できる会社の方が、長期運用では信頼しやすくなります。

発注時に確認したいセキュリティ・ストア・保守

Expoを採用しても、セキュリティとストアの責任が自動で解決するわけではありません。個人情報保護法に関わる業務なら、組織的・人的・物理的・技術的な安全管理措置、委託先管理、クラウドのデータ保管場所、削除手順を要件と契約に落とし込みます。アプリ、API、管理画面、ログ、バックアップを一つのデータフローとして確認します。

Expo SDK、React Native、iOS、Android、Xcode、Google Playの要件は変化します。開発時点で動けば終わりではなく、更新前の検証環境、依存パッケージの一覧、互換性確認、リグレッションテスト、段階配信、問題時のロールバックを運用手順にします。とくにSDK 55以降はNew Architectureが常時有効であるため、古いネイティブライブラリを使う場合は採用前のPoCが重要です。

委託先には、SDK更新を保守費に含む回数と、メジャーアップデートや大幅なライブラリ変更を別見積とする条件を明示してもらいます。対応を先送りした場合のサポート期限、緊急のOS更新への対応時間、更新しない場合のリスクも説明を受けます。更新計画を毎年の予算とロードマップに置くことで、突然のストア提出不可を避けやすくなります。

Appleは、アプリと第三者パートナーが収集するデータをApp Store Connectで申告することを求めています。また、一定の第三者SDKには有効なPrivacy Manifestが必要で、無効なマニフェストを含む提出物は受け付けられない場合があります（出典: Apple Developer Documentation、2026年8月確認）。分析、広告、認証、クラッシュレポートなどのSDKを選ぶ段階で、収集データ、利用目的、プライバシーマニフェストの有無を台帳に記録します。

Google Playでは、Data safetyの申告をアプリの実際の収集・共有・暗号化・削除方法に合わせます。アカウント作成機能があるアプリは、アプリ内だけでなくWeb上にもアカウント削除を依頼できる導線が必要です（出典: Google Play Console Help「Understanding Google Play’s app account deletion requirements」、2026年8月確認）。ストア申請とプライバシーポリシーを最後に作るのではなく、要件定義時点でデータ項目と削除フローを決めます。

EAS Updateは、JavaScriptやアセットの修正をストア審査を待たずに配信できる場面があるため便利です。一方で、誤った更新が多くの端末へ広がる可能性もあります。本番channelへの公開者を限定し、レビュー、対象runtime version、段階配信、監視、停止、前バージョンへのロールバックを手順化します。ネイティブコードや権限変更をOTA更新で済ませようとしないことも重要です。

本番環境の秘密情報をアプリのバンドルに埋め込まず、環境変数やサーバー側の秘密管理を使います。EASの認証情報、Apple・Googleの署名鍵、クラウドの管理権限は、委託先の個人アカウントに依存させず、発注側の組織で管理します。誰が何を変更したかを追跡できる権限設計にすると、障害時の原因調査と契約終了時の移管が容易になります。

Expoのシステム開発を発注するときによくある質問

Expoの発注では、技術の選択と業務の委託条件を同時に考える必要があります。ここでは、候補会社への相談前に多く寄せられる質問を、費用、納期、運用の観点から回答します。

必ず安くなるわけではありません。iOSとAndroidで共通化しやすい部分は工数を抑えやすい一方、要件定義、バックエンド、既存システム連携、テスト、ストア申請、保守は残ります。画面数や機能だけでなく、業務の複雑さと運用範囲を含めた総額で比較します。

Expo Goは学習や簡易な検証には便利ですが、独自のネイティブ機能や本番に近い設定を含む案件ではdevelopment buildを使うのが一般的です。候補会社には、実機での開発ビルド、署名、通知、カメラ、認証、ストア提出までの手順を確認します。Expo Goでのデモだけを根拠に、本番の品質や費用を判断しないことが大切です。

任せられますが、契約と保守範囲に含める必要があります。更新前の互換性調査、development buildでの検証、iOS・Androidの回帰テスト、ストア提出、障害時のロールバックを誰が担当するかを決めます。SDK 55以降はNew Architectureが常時有効なため、第三者ライブラリの対応状況を採用前と更新前に確認します。

Expo SDKとEASの実績、業務要件定義の力、バックエンド・管理画面・既存連携の対応範囲、テストとストア申請、保守と移管の条件を総合的に比較します。見積は同じRFPで依頼し、作業項目、前提、対象外、担当者、期間、納品物をそろえて確認します。価格だけでなく、障害やSDK更新が起きたときの対応を具体的に説明できる会社を選びます。

まとめ

Expoのシステム開発を発注・外注するときは、Expoを使える会社を探す前に、業務課題、対象ユーザー、Mustの機能、既存システムとの連携、非機能要件、受入条件を整理します。そのうえで、新規開発、既存アプリの移行、技術検証のどれを依頼するかを決め、RFPで同じ前提の提案と見積を受け取ります。

費用は、小規模MVPで300万〜800万円、標準的な業務アプリで800万〜2,000万円、複雑な業務・顧客向けアプリで2,000万〜5,000万円超が推定レンジですが、要件と委託範囲によって変動します。請負、準委任、技術検証と本開発の組み合わせを使い分け、ソースコード、アカウント、署名鍵、EAS設定、SDK更新、ストア対応、障害時の責任分界を契約に含めます。

最終的な委託先は、Expo・EASの経験だけでなく、業務を理解して要件を定義し、現場受入から安全なリリース、OS・SDK更新、長期保守まで伴走できるかで選びます。まずは代表業務を一つに絞った技術検証またはMVPから始め、実際の利用結果を次の開発判断につなげることが、Expoのシステム開発を成功させる近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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