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

UIKitのシステム開発を外注するなら、UIKitで作るiPhone・iPadアプリだけでなく、API、認証、管理画面、データ連携、配布、保守までを一つの発注範囲として定義することが重要です。画面の数だけで見積を比べると、後から連携や運用の費用が膨らみやすくなります。

この記事では、UIKitのシステム開発を発注・外注・依頼・委託するときの進め方を、発注形態の選択からRFPと要件整理、準委任・請負などの契約形態、2026年時点の費用相場、委託先の選び方、見積比較のポイントまで順番に解説します。既存のUIKitやObjective-C資産を引き継ぐ場合、現場でオフライン利用する場合、社内向けに配布する場合にも使えるように整理します。

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

UIKitのシステムを発注する前に全体像を確認します

UIKitは、AppleのiOS・iPadOSアプリの画面や操作を構築するためのUIフレームワークです。Apple Developer Documentationでは、ビュー、コントロール、テーブル、ナビゲーション、入力部品などがアプリの画面と操作を組み立てる要素として説明されています。したがって「UIKitのシステム」は業務システム製品の名称ではなく、UIKitを使った端末アプリを中心に、業務の裏側まで含めた構成を指す検索語として捉えると発注範囲を整理しやすくなります。

発注前に最初に分けるべきなのは、端末アプリと業務システム全体です。端末側には、ログイン画面、一覧・詳細・登録画面、カメラ、バーコード、QRコード、位置情報、Bluetooth、プッシュ通知、ファイル保存などが含まれます。一方で、サーバー側には業務API、データベース、認証基盤、権限、管理画面、バッチ、通知、監査ログ、バックアップなどが必要です。

例えば点検アプリで写真を撮影するだけならUIKitの画面開発が中心になりますが、点検結果を顧客・拠点・設備と結び付け、承認し、帳票にして基幹システムへ戻す場合はAPIとデータモデルの設計が中心になります。どこまでを外注するかを「アプリ開発一式」と表現せず、画面、端末機能、API、管理画面、データ移行、インフラ、テスト、公開・配布、保守に分解することが見積比較の出発点です。

要件整理では、端末の種類より先に、誰がどこで何を完了させるシステムなのかを定義します。営業が訪問先で商談記録を登録するのか、倉庫担当者が入荷時にバーコードを読むのか、工場担当者が通信の弱い場所で点検するのかによって、必要な画面、入力方法、同期方式、端末管理が変わります。現状の紙、Excel、電話、二重入力、承認待ちといった業務も図にすると、UIKitで作るべき機能と業務を変えるべき部分が見えてきます。

目的は「アプリを作ること」ではなく、入力時間を短くする、入力漏れを減らす、処理状況を可視化する、承認を早めるなどの業務成果です。Appleの業務向け導入事例では、Ash CloudのiPhone・iPad向けカスタムアプリが生産ラインの効率を30%以上高めたと紹介されています。ただし、この事例はUIKit採用を証明するものではないため、発注時には技術名の採用実績だけでなく、対象業務でどのKPIを改善したかを確認します。

発注形態はどれを選ぶとよいですか？

発注形態は、開発会社に一括で任せる方法、発注者と開発会社が共同で進める方法、パッケージ・クラウド・ローコードを使う方法、まず小さく検証する方法に分けられます。最適な形は、社内のIT人材、既存システムの複雑さ、iPhoneだけかAndroidも必要か、業務の独自性、公開後の保守体制によって変わります。

社内にアプリ開発やプロジェクト管理の経験が少ない場合は、現状調査、要件定義、UI設計、UIKit実装、API開発、テスト、App Storeまたは社内配布、運用保守までを一社にまとめて依頼する方法が現実的です。窓口が一つになるため、画面とAPIの責任分界を調整しやすく、障害時の切り分けも進めやすくなります。

一括発注でも、発注者が業務判断まで任せてよいわけではありません。対象ユーザー、現場の例外処理、個人情報の扱い、既存システムの正解データ、受入担当者、優先順位は発注者が決める必要があります。要件が曖昧なまま一括で請負契約を結ぶと、見積に含まれない追加開発として課題が戻ってくるため、初期の調査・要件整理だけを別工程にする選択肢も検討します。

社内にプロダクト責任者やIT担当者がいる場合は、発注者が優先順位と業務仕様を持ち、委託先がUIKit・Swift、API、テスト、設計レビューを担う共同開発が向いています。既存のUIKitやObjective-Cアプリを改修する案件では、コードの所有者と保守担当を社内に残しながら、特定画面の刷新やSwiftUIとの段階的な併用を外部に任せる形も選べます。

共同開発では、ソースコードをどのリポジトリで管理するか、レビューのルール、開発環境の権限、ドキュメントの形式、担当者交代時の引き継ぎを契約前に決めます。単に人月を買うのではなく、画面仕様、API仕様、テストコード、リリース手順を成果物として残すと、委託先への依存を抑えられます。

業務が標準化されており、カメラ、GPS、オフライン入力、通知などを設定中心で実現できる場合は、SaaSやローコード製品を先に比較します。iOSとAndroidを同時に展開したい場合はFlutter、React Native、Kotlin Multiplatformなども候補になりますが、端末固有機能、既存UIKit資産、細かな操作性、長期のOS対応を優先するならSwift/UIKitのネイティブ開発が有力です。技術の優劣ではなく、端末と業務の条件で選びます。

要件がまだ仮説段階なら、最初から全社展開を発注せず、1業務・1拠点・少数画面のPoCを依頼します。PoCでは画面の完成度だけでなく、通信断からの復帰、同期の重複防止、権限拒否、API障害、現場の入力時間を確認します。PoCの成果物を本番開発へ引き継げるか、検証後の追加費用とソースコードの扱いも見積書に記載してもらいます。

RFPと要件整理はどのように進めますか？

RFPは、開発会社へ画面一覧を渡すだけの資料ではありません。なぜ開発するのか、誰が使うのか、現行業務はどう流れているのか、どのデータと連携するのか、いつまでに何を使える必要があるのかを示し、各社が同じ前提で提案・見積できるようにする文書です。発注者が目的と制約を示し、委託先には方式、体制、リスク、費用の前提を説明させます。

まず、利用者を管理者、現場担当者、承認者、閲覧者などに分け、利用開始から完了までの業務フローを描きます。ログイン、対象データの検索、登録、写真添付、下書き、申請、差し戻し、承認、確定、帳票出力、修正履歴までを一連のシナリオにします。画面数を先に決めるのではなく、1回の操作で何を入力し、どの状態へ変わり、誰が次に処理するのかを明確にします。

既存のExcelや紙帳票をそのままアプリ画面へ置き換えると、不要な入力や例外処理まで固定されることがあります。必須項目と任意項目、マスタの管理者、重複登録の判定、取消・訂正の扱い、履歴の保存期間を業務担当者と確認します。UIKitの画面設計では、片手操作、屋外の明るさ、手袋、iPadの横向き利用、文字サイズ変更など、現場の使い方を受入条件に含めることが大切です。

端末要件には、iPhoneだけかiPadも使うか、対応OSの下限、画面サイズ、会社支給端末か私物端末か、カメラ・GPS・Bluetooth・バーコードリーダーの有無を記載します。通信要件には、常時オンラインを前提にできるか、圏外で登録したデータをいつ再送するか、同じデータを複数人が更新した場合の競合解決、端末紛失時の遠隔消去を含めます。

認証はメールアドレスとパスワードだけでよいのか、SSOや多要素認証を使うのか、退職・異動時に権限をどう止めるのかを整理します。APIのTLS通信、端末内のKeychain等を使った秘密情報の保護、最小権限、管理操作ログ、バックアップ、脆弱性対応、データ保持期間もRFPに入れます。位置情報、写真、従業員情報、顧客情報を扱う場合は、個人情報保護法と社内規程に沿った目的、同意、利用範囲、削除手順を法務・情報システム部門と確認します。

RFPには、背景・目的、対象範囲、対象外、利用者数、端末とOS、現行システム、連携先、データ移行、セキュリティ、性能、可用性、導入時期、予算の考え方、保守期間、納品物、提案期限、見積様式を記載します。各社に、UIKitネイティブかクロスプラットフォームかの理由、既存コードの引き継ぎ方法、開発体制、再委託の有無、公開後の保守窓口も回答させます。

受入基準は「画面が表示される」では不十分です。例えば、100件の点検データを検索できる、通信断で登録したデータが復帰後に一度だけ送信される、権限のない利用者には対象データが表示されない、指定OSと端末サイズで操作できる、API障害時に利用者へ再試行方法を表示できる、といった検証可能な条件にします。同じ業務シナリオとサンプルデータで2〜3社のデモを比較すると、提案書の言葉だけではわからない差を確認できます。

契約形態はどのように使い分けますか？

UIKit案件では、要件整理、設計・開発、検収、運用保守のすべてを同じ契約条件にする必要はありません。要件が変わりやすい調査・企画は準委任、完成条件を定義できる開発は請負、継続利用するクラウドや保守はサービス利用・保守契約というように、工程ごとに責任と支払いの条件を整理します。契約の名称より、作業、成果物、完成条件、変更時の扱いを確認します。

準委任契約は、専門家による調査、助言、設計、開発支援などの役務を依頼する工程に向いています。現行UIKitコードの調査、Objective-CからSwiftへの移行方針、端末・OSの検証、API連携の調査、RFP作成支援、PoC、業務部門との合意形成など、進めながら論点が具体化する作業に適しています。

準委任でも、作業計画、稼働時間、会議体、調査報告、画面仕様、課題一覧、設計書などの提出物を明記します。成果物を作る場合も、完成を保証するのか、専門家として作業・報告するのかを分けます。月次の稼働報告だけで判断せず、何が決まり、何が未決で、次に誰が判断するのかを見えるようにします。

請負契約は、合意した成果物を完成させ、発注者が検査・検収する開発工程に向いています。UIKitの画面、API、データベース、管理画面、バッチ、テスト結果、操作マニュアル、リリース手順、ソースコード、設計書を納品物として列挙し、受入期限と不具合修正の扱いを決めます。

「ログインできる」「一覧を表示できる」といった表現だけでは、認証エラー、権限、通信断、空データ、重複登録、入力途中の離脱、端末回転、文字サイズ変更まで含むのか判断できません。対象端末、対応OS、サンプルデータ、性能条件、エラー時の動作を検証項目に落とし、検収後に見つかった不具合と追加要望を分けられるようにします。

契約書や仕様書では、データの所有権と利用範囲、秘密保持、個人情報の委託、再委託、知的財産権、ソースコードの引き渡し、OSSや第三者SDKのライセンス、障害時の連絡、損害賠償、契約終了時のデータ返却・消去を確認します。既存システムと新アプリをつなぐ場合は、APIの仕様と変更通知、旧ベンダーからのデータ抽出、新ベンダーの変換、発注者の照合を工程表に分けます。

保守契約では、OSアップデート対応、App Store審査の再申請、脆弱性対応、クラッシュ調査、クラウド監視、問い合わせ、軽微な改修を基本料金に含める範囲と、別見積にする範囲を決めます。障害の重要度ごとの一次応答・復旧目標、休日対応、保守対象外の端末や外部サービスも確認します。初期費用だけでなく、契約期間中の総額と担当者交代後の引き継ぎ費用で比較します。

UIKitのシステム開発の費用相場はどのくらいですか？

UIKit専用の全国一律な料金表はないため、以下はiOSアプリ開発の公開相場と、業務システムの連携・認証・管理画面・保守を含めたリサーチノートの整理から作る予算検討用のレンジです。実際の費用は、アプリの画面数よりも、サーバー連携、既存データ、オフライン同期、端末数、セキュリティ、テスト、保守範囲で変わります。特定の金額を発注額として断定せず、同じ前提条件で見積を取ります。

SIA株式会社の「iOSアプリ開発の費用相場 2026年版」では、単機能・社内ツールの目安を200万〜500万円、業務システムと連携する本格的なアプリを500万〜1,500万円、会員・決済・リアルタイム通信を含む大規模サービスを1,500万円以上と整理しています（出典：SIA株式会社、2026年）。単一業務のログイン、一覧、登録、小規模API、基本的な実機テストであれば小規模帯を検討し、権限、管理画面、写真・QR、通知、複数端末、業務APIが加わると中規模帯に近づきます。

現場でのオフライン同期、ERP・WMSなどの基幹連携、SSO、監査ログ、MDM、複数拠点の展開、過去データ移行まで含める場合は、1,500万〜3,000万円超を仮説に置きます。複数アプリや基幹刷新、24時間運用、厳格な非機能要件まで含めると、3,000万円から数億円規模になる可能性もあります。これらはUIKitの画面だけの料金ではなく、業務システム全体に必要な作業を含む推定レンジです。

費用の内訳は、現状調査・要件定義、UI/UX設計、UIKit実装、API・データベース、管理画面、外部連携、インフラ、テスト、データ移行、リリース、操作説明、保守準備に分けて提示してもらいます。リサーチノートでは、初期説明の比率として要件定義10〜15%、UI/UX設計10〜20%、実装40〜50%、テスト15〜20%、申請・リリース約5%を置いています。ただし、これは業務システムの構成を考えるための参考配分であり、全案件に当てはまる固定比率ではありません。

見積書に「アプリ開発一式」「連携一式」「テスト一式」が多い場合は、画面数、API本数、外部システム数、データ件数、実機台数、テストケース数、移行リハーサル回数を質問します。開発会社の人月単価は、公開情報では100万〜150万円程度が目安として示されることがありますが、役割、経験、契約期間、作業場所、管理費の含み方で変わります。単価だけでなく、何人が何か月担当するかと成果物を確認します。

開発後は、サーバーやデータベース、監視、バックアップ、ログ保管、MDM、外部API、端末、問い合わせ、OSアップデート、脆弱性対応、追加改修が継続的に発生します。一般的な業務システムの目安として年間保守を初期開発費の10〜20%程度と仮置きすることがありますが、障害対応や改修をどこまで含むかで大きく変わります。初期費用1,000万円なら年100万〜200万円程度という計算もできますが、これは予算仮説であり、契約金額の断定ではありません。

App Storeで配布する場合、Apple Developer Programの年会費は99米ドルです（出典：Apple「Apple Developer Program」、2026年確認）。社内向けのCustom AppsはApple Businessを通じて組織へ非公開配布でき、App Store Connectで申請し、承認後に対象組織へ割り当てる運用ができます（出典：Apple Support「Learn about Custom Apps in Apple Business」、2026年確認）。料金だけでなく、審査、MDM、アカウント管理、テスト端末、配布手順を保守見積に含めます。

委託先の選定と見積比較では何を確認しますか？

委託先は「iOSアプリに対応している」という一文だけで選ばず、UIKit・Swift・Objective-Cの既存資産、業務API、管理画面、オフライン同期、端末機能、セキュリティ、配布、公開後保守を確認します。会社の知名度や見積総額だけでなく、今回の業務と近い案件で、どの範囲を自社で担当し、どの範囲を再委託したのかを質問します。

候補会社には、UIKitの新規画面だけでなく、既存UIKitやObjective-Cコードの保守・改修、SwiftUIとの混在、OSアップデート対応、実機テストの実績を確認します。業務アプリであれば、API・認証・権限・管理画面・帳票・データ移行・監査ログまで設計した事例があるかも重要です。事例紹介に会社名や機能名があっても、今回の案件と同じ難しさがあるとは限らないため、担当範囲と成果を具体的に聞きます。

提案時には、プロジェクトマネージャー、UIKit実装者、バックエンド担当、QA、インフラ・セキュリティ担当を誰が担うかを示してもらいます。面談で説明した担当者が本番も参加するのか、急な離脱時の代替体制があるのか、再委託先の管理方法はどうかを確認します。納品後に質問できる窓口と、軽微な修正の対応速度も選定基準に含めます。

見積を比較するときは、総額の安い順に並べるのではなく、要件定義、デザイン、UIKit実装、API、管理画面、連携、移行、テスト、申請、研修、保守を同じ項目で並べます。各項目について、含む作業、含まない作業、前提条件、担当者、工数、期間、成果物、検収条件、追加単価を確認します。例えば一社だけデータ移行やMDMを含めているなら、その分を除いた小計で比べないと価格差を誤解します。

見積の安さが、要件定義やテストの省略、経験の浅い体制、保守対象外、再委託費の別計上によって生まれていないかを確認します。反対に高い見積でも、現場調査、移行リハーサル、セキュリティ診断、実機の組み合わせ試験、リリース立会いを含むなら、同じ範囲にそろえて評価する必要があります。提案書のリスク一覧に、発注者側の作業と判断期限が書かれている会社は、実行段階の認識合わせがしやすくなります。

候補を2〜3社に絞ったら、自社の業務シナリオと匿名化したサンプルデータを渡し、同じ条件でデモまたは短期PoCを依頼します。ログインから登録、承認、修正、検索、帳票出力までを操作し、現場担当者が迷わないか、権限が期待どおりか、通信断から戻ったときにデータが壊れないかを確認します。営業資料の画面ではなく、実際の端末と業務の組み合わせで評価します。

開発後の提案では、OSのメジャーアップデート、App Review Guidelines、Appleのプライバシー情報、第三者SDKの変更、脆弱性、クラウド障害、端末紛失にどう対応するかを聞きます。AppleのApp Review Guidelinesは2026年6月8日に更新され、プライバシーポリシー、データ収集、第三者との共有、同意などが審査・運用上の論点として示されています（出典：Apple「App Review Guidelines」、2026年）。初期開発の提案だけでなく、公開後に継続して対応できる体制を選びます。

セキュリティ・配布・受入テストはどう設計しますか？

UIKitのアプリは端末にインストールされるため、画面が動けば完了ではありません。個人情報や業務情報が、端末、API、データベース、管理画面、ログ、バックアップ、委託先のどこに存在するかを整理し、アクセスできる人と目的を定義します。実装の後でセキュリティと配布を考えると、設計変更や審査遅延が起きやすいため、RFPの段階から扱います。

カメラ、位置情報、写真、連絡先、顧客情報、従業員情報を扱う場合は、取得目的、同意のタイミング、保存期間、第三者提供、削除依頼への対応を定めます。アプリ内の権限要求文、プライバシーポリシー、App Store ConnectのApp Privacy情報、社内規程、APIのデータ項目を一致させます。Appleのガイドラインでは、アプリのプライバシーポリシーをApp Store Connectのメタデータとアプリ内のアクセスしやすい場所に提示することが求められています。

認証トークンや秘密情報を平文で保存せず、最小権限、多要素認証、TLS、Keychainなどの保護、管理者操作ログ、監査ログ、バックアップ、端末紛失時の停止を要件化します。ログに個人情報を残しすぎないこと、テスト環境へ本番データを持ち込まないこと、開発会社や再委託先が閲覧できる範囲を制限することも確認します。個人情報保護委員会のガイドラインQ&Aも参照し、業界固有の規制がある場合は法務・専門家に確認します。

一般公開ならApp Store、社内や特定顧客だけに配布するならApple BusinessのCustom Apps、社内端末を一元管理するならMDMを組み合わせる方法を検討します。Custom Appsは自社または外部開発会社が作った組織専用アプリを、Apple Businessを通じて非公開で配布できます。一般公開しないから審査が不要になるわけではなく、申請、テストアカウント、プライバシー情報、配布対象の管理を計画します。

配布方式を決めるときは、Apple Developerアカウントを誰が所有するか、証明書や署名を誰が管理するか、退職者のアカウントをどう停止するか、端末交換時の再インストールをどうするかを確認します。開発会社のアカウントだけで公開すると、契約終了時に更新できないリスクがあります。発注者の組織アカウント、リポジトリ、App Store Connect、MDM、クラウドの管理権限を、契約終了後も引き継げる状態にします。

テストでは、対応OSと画面サイズ、実機のカメラやバーコード、権限拒否、低電池、通信断、APIの遅延・停止、同期競合、重複送信、端末紛失、アカウント停止、バックアップ復元を確認します。現場の代表者が、通常の操作だけでなく例外処理を実際の端末で検証し、重大度ごとの不具合判定と修正期限を合意します。

全社一斉導入ではなく、まず1拠点や1チームでパイロット運用を行い、入力時間、エラー率、処理完了までの時間、利用率、問い合わせ件数を測ります。問題がなければ対象を増やし、旧運用をいつ止めるかを決めます。公開後に数字を追わないと、アプリが完成しても現場が使わない状態を見逃すため、開発会社の保守範囲と発注者の定着支援を分けて計画します。

よくある質問（FAQ）

最後に、UIKitのシステム開発を発注するときに特に多い質問へ回答します。技術選定、費用、契約、委託先の判断を自社の状況に当てはめて確認してください。

既存のUIKit・Objective-C資産を活かす、iOS専用で細かな操作性や端末機能を重視する場合はUIKitが有力です。新規画面をSwiftUIで作り、既存画面をUIKitで保守する併用も可能なため、会社全体で一方に統一するのではなく、資産、対応OS、チームの経験、保守期間で判断します。

画面だけを外注すれば初期費用を抑えられる可能性はありますが、API、認証、データ連携、管理画面、テスト、配布、保守を別に用意する必要があります。画面とバックエンドの責任分界が曖昧だと、動くデータがない、エラー処理が足りない、検収できないといった問題が起きるため、画面のみの契約でも接続仕様と受入条件を明記します。

作れますが、機能一覧だけでなく、業務フロー、利用者、端末、通信環境、既存システム、データ、セキュリティ、保守、受入条件を整理する必要があります。社内で技術要件を決めきれない場合は、開発会社や第三者へ現状調査・RFP作成支援を準委任で依頼し、その成果を使って複数社を比較します。特定の会社にそのまま本開発を決めず、調査段階の成果物と選定段階を分けると比較の公平性を保ちやすくなります。

UIKit・Swift・Objective-Cの実装だけでなく、業務API、認証、オフライン同期、端末機能、実機テスト、App StoreまたはCustom Apps、MDM、セキュリティ、公開後保守を一体で確認します。候補会社には、似た業務の実績、担当範囲、チーム構成、再委託、ソースコードとアカウントの引き継ぎ、障害時の対応時間を質問し、同じRFPとサンプルシナリオで提案・見積を比較します。

まとめ

UIKitのシステムを発注・外注するときは、UIKitの画面だけを依頼するのではなく、API、認証、管理画面、データ連携、オフライン同期、セキュリティ、配布、保守までを業務システムの範囲として整理します。発注形態は、一括外注、共同開発、パッケージ・ローコード、PoCを社内体制と要件の確かさで使い分けます。

RFPには、対象業務、利用者、端末とOS、通信環境、オフライン要件、既存システムとデータ、認証・権限、個人情報、配布方法、保守、検収条件を記載します。費用は、公開相場を起点にしながら、要件定義、UIKit実装、API、移行、テスト、配布、保守を同じ項目で分解して比較します。準委任で要件を整理し、請負で完成条件を定義するなど、契約形態も工程ごとに使い分けます。

最初の一歩は、作りたい画面を並べることではなく、現場の代表的な業務シナリオを一つ選び、利用者、データ、端末、通信、承認、例外処理、完了条件を一枚に整理することです。その資料をもとに2〜3社へ相談し、技術方式、体制、リスク、費用、保守を同じ条件で提案してもらうと、UIKitを採用する意味と外注範囲を判断しやすくなります。契約終了後もコード、アカウント、設計書、データを自社で扱える状態まで確認してから発注します。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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