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

Tauriのシステム発注は、業務要件の整理、発注形態と契約形態の選択、見積の比較、委託先の選定という順に進めます。

Tauriの発注では、軽さよりも業務への適合性で判断します。業務要件や対応OS、オフライン同期などをRFPに書いて各社を比べるのが近道です。

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

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

Tauriのシステムを発注・外注する前に知るべき全体像

Tauriのシステムは、ReactやVueなどのWebフロントエンドとRustのコア処理を組み合わせ、Windows・macOS・Linuxなどへ配布します。設計の対象は、画面に加えて、RustによるOS連携、API、データベースです。

配布や認証、ログも含めて、一つの業務サービスとして設計します。バックアップやアップデートも設計に含めます。そのため、業務内容、端末、停止を避けたい運用条件を先に明確にしておく必要があります。

内製・部分委託・一括委託から選ぶ発注形態

発注形態は、社内の人材と、外部に任せたい範囲に応じて選びます。主な選択肢は次の三つです。

• 内製：社内にReactやVueの人材と業務知識がある場合に向きます。
• 部分委託：Tauri特有の技術領域を専門会社に任せます。
• 一括委託：要件定義から導入支援、保守まで依頼します。

部分委託では、画面やAPIは社内で作り、Rustのコア処理は専門会社に任せられます。コードレビューやOS別テスト、署名・自動更新も委託できます。既存のWeb資産を活かし、Tauri特有の難所へ予算を集中できる点が利点です。

一括委託では、業務フローの整理から任せられます。一方で、発注者が判断する機会が減り、完成後に現場と合わないリスクが高まります。

一括委託でも、発注者側に業務責任者と決裁者を置く必要があります。現場代表とデータ管理者も加わり、委託先と共同で仕様を決める体制を作ります。

軽量さより業務との適合性で見る判断

Tauri公式「What is Tauri?」（2026年7月更新）によると、標準搭載のWebViewを使うTauriは、最小構成で600KB未満になる場合があります。

この数値は最小構成の目安です。実際の業務システムには、画面や画像、Rust処理が加わります。さらに、データベース、インストーラー、ログ機能も必要になります。

案件の要件を聞かずに、最終的なアプリ容量やメモリ使用量を断定する会社には注意が必要です。

Tauriが業務に合うかは、利用環境と必要な端末連携から判断します。特に、次の観点を比べます。

• 活かしやすい用途：店舗・倉庫のオフライン入力、社内端末への常駐通知。
• 端末連携：バーコード、USB、プリンターとの接続。
• 比較対象：PWA、Electron、ネイティブアプリ。

公開サービスで常に最新のブラウザ互換性が必要な場合や、GPU性能に強く依存する場合は、別の方式も検討します。WebViewのOS差を許容できない高度なUIも、検討の対象になります。

RFPと要件整理でTauriのシステム発注条件を固める方法

見積を依頼する前に、現場業務とシステムの境界を整理します。RFPには、まず背景・目的と対象部門を書きます。業務フローや画面などの業務の中身も記載し、利用者数や端末、対応OSといった利用環境も加えます。

既存データと外部連携の条件を書くほか、納期や予算の考え方、保守の希望も記載します。たとえば、通信断や端末交換など、例外時の動作も書いておくと、見積条件が明確になります。

業務フローとデータの洗い出し

現場の業務とデータを洗い出し、入力や確定の流れを把握します。確認する対象は、工程ごとに並べて整理します。

• 既存の手段：紙、Excel、電話、メール、FAX、既存システムへの二重入力。
• 倉庫の工程例：入荷、検品、棚入れ、ピッキング、出荷、返品。
• 工程ごとの情報：入力者、入力内容、確定するデータ。

入力は一度で済ませる流れ、誤入力を追える流れ、承認者が判断しやすい流れを優先します。画面を増やすより、過剰なカスタマイズを抑えられます。

顧客や商品、拠点などのマスタについて、責任者をRFPに記載します。ユーザー、権限、税区分のマスタについても、責任者を決めます。

マスタが整わないまま開発を進めると、テストデータと本番データの差が大きくなります。その結果、リリース後の修正が増えます。

データ移行では、移行の対象、欠損値の扱い、重複の判定を決めます。更新権限と履歴の保存期間も定め、発注者と委託先の担当範囲を明確にします。

非機能要件に含めるOS・オフライン・セキュリティ

機能要件と同じく、非機能要件も発注時に決めます。OSや端末の条件を具体化したうえで、性能や周辺機器なども書き添えます。

• 端末環境：対象OSとバージョン、画面解像度、最低端末性能。
• 利用条件：同時利用者数、起動時間、画面応答時間。
• 周辺環境：印刷先、フォント、ファイル保存先。

Windowsだけか、macOSやLinuxも含めるかを明記します。Tauriは、OS標準のWebViewを使います。Windowsで使うのはWebView2、macOSはWKWebView、Linuxはwebkitgtkです。

そのため、それぞれのWebViewの差を実機で確かめる工程を、計画に組み込みます。

オフライン対応では、通信断でも使える操作、ローカル保存するデータ、復旧後の同期時期を決めます。複数端末で同じデータを変更した場合の採用ルールも定めます。

端末紛失時の遠隔無効化や、ローカルDBの暗号化、キャッシュの有効期限も要件に含めます。さらに、未送信データの再送や、同期失敗時の管理者通知も要件にします。

実端末を使ったPoCによる採用可否の検証

本開発の契約前に、1画面から数画面のPoCを依頼する方法もあります。案件のリスクが高い機能を、一連の操作で試します。

• 接続・保存：ログイン、API接続、ローカル保存。
• 端末機能：印刷、ファイル操作、通知。
• 更新：アップデートと、その失敗時の挙動。

起動速度の確認に加えて、現場の端末とネットワークも再現します。通信断やスリープ復帰、強制終了を確かめ、端末再起動や更新失敗も試します。

成果物には、実行ファイルに加えて検証条件と測定値を含めます。未解決の制約、採用しなかった案、量産開発への引き継ぎ事項も残します。

PoCを安く作ること自体を目的にすると、本開発で調査をやり直すことになります。契約前の判断材料を得る工程として、対象範囲と終了条件を文書で決めます。

Tauriのシステム開発を発注してから納品するまでの進め方

発注後は、企画から保守までを一続きの工程として管理します。前半は企画と要件定義、中盤は設計と開発、後半はテストと導入に進み、そのあとに保守へ移ります。

画面を作り終えてからRust側の権限やOS連携の問題が見つかると、設計変更の影響が大きくなります。そのため、実機と実データに近い条件で、リスクの高い部分から早めに確かめます。

企画・要件定義での対象業務と成功条件の確定

企画では、Tauriを採用する理由を業務の成果に結びつけます。現場業務の改善をKPIとして定め、軽量化はその手段のひとつとして扱います。

• 入力・転記：入力時間の短縮、転記ミスの削減。
• 通信・帳票：通信断時の作業継続、紙帳票の削減。
• 方式比較：SaaS、既存パッケージ、PWA、Electron、ネイティブアプリ。

各KPIは、何分短縮するか、ミスをどの程度減らすか、紙をどこまで減らすかまで決めます。そのうえで、Tauriで必要な要件と、他方式でも満たせる要件を分けます。

要件定義書には、画面一覧、権限マトリクス、API一覧を含めます。データ項目や帳票、エラー処理も記載します。

ログとバックアップ、移行の扱いも確定します。教育とサポート窓口も決めます。

優先度は、必須、できれば必要、将来候補の三つに分けます。納期や予算が変わったときにも、判断しやすくなります。

設計・開発でのフロントエンドとRustの責任範囲

一般的な構成では、Rustコアをsrc-tauri配下に置きます。そのうえで、認証・業務API、クラウドDBまたはSQLiteと組み合わせます。

設計書では、フロントエンドとRustの責任範囲や呼び出し境界を明確にします。次の五つの項目について、役割と確認事項を整理します。

• 構成：React・Vue・Svelte、Rust、認証・業務API、クラウドDBまたはSQLite。
• フロントエンド：画面表示と入力制御を担う。
• Rust：ファイル操作、暗号化、帳票、印刷、USB、トレイ、オフラインキューを担う。
• invoke境界：入力検証、エラー形式、タイムアウト、再実行、監査ログを定める。
• 品質管理：レビュー、テスト、依存クレート更新、脆弱性時の連絡先を確認する。

業務ロジックの安全性は、言語の選択に加えて、レビューと呼び出し境界の設計で支えます。

テスト・配布・導入で再現する現場の失敗

テストと配布では、現場での失敗を再現し、OSごとの条件とリリース手順を確かめます。

• テスト：OS別結合、業務シナリオ、権限、負荷、障害復旧を確認する。
• 実機検証：フォント、パス、印刷、通知、スリープ復帰、WebView差を試す。
• 配布準備：署名証明書の所有者、秘密鍵の保管者、配布場所を決める。
• 更新・納品：更新トリガー、ロールバック、旧版サポート、ビルド・署名・更新・復旧手順を定める。

Windows、macOS、Linux向けは、実機または本番に近い環境で確認します。テスト仕様書には、期待結果と証跡の保存方法を記載します。

Tauri公式には、Windows、macOS、Linux向けの配布・署名案内があります。iOSとAndroid向けの案内もあります。

OSごとに、証明書やストアの条件が異なります。審査や端末条件も、OSによって違います。

Tauriのシステム発注で選ぶ契約形態と成果物

契約形態は、完成責任を重視するか、要件の変化に対応するかで選びます。Tauriの案件では、技術検証と業務要件の不確かさが同時に生じやすい傾向があります。

企画・PoCと本開発を同じ条件で一括契約するより、フェーズごとに分けるほうが双方に合う場合があります。

請負契約の完成物と検収条件

請負契約は、委託先が合意した成果物を完成させ、発注者が検収する形に向いています。契約書や仕様書には、次の三つの条件を記載します。

• 成果物・範囲：画面、機能、対応OS、納品物。
• 検収：テスト項目、性能条件、検収期間。
• 変更・保守：瑕疵対応、再委託の可否、納品後の保守。

検収では、「軽量」「高速」「安全」といった言葉を、測定できる条件に置き換えます。たとえば、起動時間やアプリサイズ、許容エラー率があります。対応端末も条件に含めます。

発注者の確認やデータ・APIの提供が遅れると、納期や費用に影響します。そのため、発注者の協力事項、仕様変更の手続き、追加費用の算定方法も定めます。

伴走型の要件整理や改善に使う準委任契約

準委任は、一定期間の作業や専門支援を依頼し、要件の変化に合わせて進める契約です。対象業務と管理方法を、あらかじめ決めます。

• 依頼内容：初期要件整理、Electron移行調査、Rustレビュー、OS別調査、継続改善。
• 契約基準：作業時間や体制を定め、完成物の一方的な保証を求めない。
• 月次運営：計画、報告、レビュー、優先順位、バックログ管理者を決める。
• 意思決定：仕様変更の承認者と月次成果の確認方法を定める。

発注者側にも、意思決定の速さが求められます。PoCと要件定義は準委任で、本番開発の一部は請負とする組み合わせもあります。

契約前に確認する納品物と知的財産権

ソースコードに加えて、設計・テスト・運用に必要な資料も納品物に含めます。保守を別の会社へ移せるように、管理記録も引き渡します。

• 設計・検証：要件定義書、画面・API・DB設計書、テスト仕様と結果。
• 運用：操作マニュアル、環境構築、CI/CD、SBOM、依存ライブラリ一覧。
• 引き継ぎ：署名・更新・ロールバック手順、リポジトリ、Issue、チケット、設計判断。

コードは、既存OSSとTauri本体、委託先の共通部品、新規コードに分けて確認します。著作権の帰属、利用許諾、第三者ライセンスの表示義務も契約に記載します。

秘密情報、退職者や再委託先のアクセス権、署名鍵の返却・廃棄も定めます。これらは、納品後のトラブルを抑えるための確認事項です。

Tauriのシステム開発を外注する費用相場と内訳

Tauriに限った日本の受託開発の価格表は、公開情報が限られています。そのため、以下の金額は、業務システム全般の相場にTauri特有の作業を加えた企画用の推定です。

対象作業には、Rust実装とOS別検証があります。そのほか、署名や配布、オフライン設計も含みます（出典: NotebookLMリサーチノート「Tauriのシステム」、業務システム全般のQ&A整理）。

金額は2025〜2026年時点の推定で、正式な見積ではありません。実際の金額は、機能数や利用者数、端末数で上下します。外部連携やデータ移行、SLAによっても変わります。

規模別の費用相場の幅（150万円〜1億円超）

費用レンジは、規模と含める機能によって変わります。各レンジの想定条件も合わせて確認します。

• 技術検証・小規模PoC：150万〜400万円程度。
• 部門向け業務アプリ：500万〜1,200万円程度。
• 現場システム・業務基盤：800万〜1,800万円、または1,500万〜4,000万円程度。
• 大規模システム：4,000万円〜1億円超となるケースもあります。

PoCは1画面から数画面、API接続またはSQLite、Windows中心の配布を想定します。部門向けアプリは、ログインや権限、一覧・入力を含む想定です。加えて、CSVや帳票、クラウドAPIも含みます。

部門向けでは、WindowsとmacOSの検証も想定します。これらは、初期予算の計画に使う目安です。Tauri専用の公開価格ではありません。

現場システムの800万〜1,800万円は、ローカルDBと同期・競合解決を含む想定です。バーコードやファイル連携、監査ログ、端末運用も含みます。

業務基盤の1,500万〜4,000万円は、複数部門と複数OSに対応する想定です。SSOや複数サービス連携、自動更新も含みます。

大規模スクラッチ開発やERP・WMSとの連携を含むと、4,000万円〜1億円超のケースもあります。データ移行や冗長化、24時間運用も、金額を左右する条件です。厳格な監査やSLAも、金額に関わる条件になります。

個別要件がない段階では、金額は断定できません。機能と運用の範囲を明確にしてから、見積もります。

見積書の工程別内訳（要件定義・実装・テスト・導入）

業務システムの見積では、工程ごとの費用配分が過不足を判断する材料になります。

• 要件定義：10〜15%。
• 設計：15〜20%。
• 実装：30〜40%。
• 結合・総合テスト：15〜20%。
• 移行・導入：5〜10%。

比率は業務システム開発工程の一般目安です（出典: NotebookLMリサーチノート「Tauriのシステム」、業務システム開発工程の一般目安）。

Tauri案件では、Rustとフロントエンドの境界設計と、OS別の実機テストを別項目として分けて見ます。署名やインストーラー、自動更新も、個別に確認します。権限設定やセキュリティ診断も、見積に含まれているかを見ます。

「開発一式」の見積では、含まれない作業が見えにくくなります。そのため、画面数や帳票数、API本数を一つずつ数えます。外部サービス数、対応OS、テスト端末も確かめます。

移行件数や教育回数、打ち合わせ回数は、各社で数量を揃えて見ます。保証や交通費、クラウド費用の扱いも確認します。納品物と検収についても、同じRFPに基づいて各社を比べます。

必須要件と提案要件を分けると、各社の見積を比べやすくなります。

保守費用と配布基盤のランニングコスト

保守費用は、初期開発費の年15〜20%程度を検討目安にできます（出典: NotebookLMリサーチノート「Tauriのシステム」、業務システム保守の一般目安）。

保守契約は、含まれる作業によって費用が変わります。そのため、保守の範囲と配布基盤の費用を分けて、次の項目を確認します。

• 保守作業：脆弱性修正、OS・WebView・依存更新、監視、障害対応。
• 日常支援：端末交換、軽微改修、問い合わせ、リリース作業。
• 配布基盤：サーバー、DB、ログ、バックアップ、署名証明書、ストア、端末管理。

年額の割合に加えて、対応時間や月間作業時間を確認します。緊急連絡の方法とSLAも押さえます。配布基盤の各項目は、別途費用となる可能性があります。

2026年6月、Tauri関連サービスのCrabNebula Cloudが無料化されました。案内には、未使用リリースの削除と利用量のフェアユースも示されています（出典: CrabNebula公式発表、2026年6月）。

特定のサービスが無料でも、配布と保守の責任は残ります。そこで、代替手段とデータの持ち出し方法を決めておきます。

Tauriのシステム委託先を選び、見積を比較するポイント

委託先は、Tauriの知識だけでなく、業務システムを運用までつなげる力で選びます。候補会社には、経験や体制を具体的に質問します。

• 技術：Tauri 2、Rustレビュー、Reactなどの経験。
• システム：API・DB設計、OS別実機テスト。
• 運用：署名、自動更新、オフライン同期、セキュリティ、納品後の保守。

技術と運用の証拠による実績の確認

実績は、公開画面の見え方よりも、証拠を見て判断します。可能であれば、技術、テスト、運用の証拠を見せてもらいます。

• 設計：匿名化したアーキテクチャ図、Rust側の責任範囲。
• 安全性：Capabilitiesの設定例、テスト計画。
• 運用：リリース手順、障害対応の実例。

過去の顧客に問い合わせできる場合は、仕様変更への対応と、バグの説明を聞いておきます。引き継ぎや保守時の応答も確認します。納期だけで判断しません。

2025年度のIPA未踏IT人材発掘・育成事業では、ReactフロントエンドとRustバックエンドをTauriで統合した組版システムが公開されています（出典: IPA「簡単な操作で高度な組版を行える文書作成システム」、2025年度）。

これは、Tauriが専門的なデスクトップシステムにも使われる国内の事例です。ただし、受託開発の価格や納期を示す資料ではありません。事例の技術適合性と、発注先の契約・保守実績は、分けて評価します。

金額・範囲・前提条件を揃えた見積比較

見積は、合計額とあわせて、見積条件と作業範囲を揃えて比較します。次の四つの観点で、金額差と発注者に残る責任を確認します。

• 前提条件：機能、OS・端末、データ移行量、API連携数。
• 工程別費用：要件定義、設計、実装、テスト、導入、教育、保守。
• 金額差が出る項目：同期、権限・監査、印刷、署名・更新、OS別テスト、移行、復旧。
• 曖昧な項目：「別途相談」などは採用時の単価や作業量を質問する。

安い見積が必ずしも悪いとは限りません。重要なリスクが発注者側に残っていないかを確認し、価格と責任範囲を合わせて判断します。

権限・脆弱性・保守責任の分界の確認

Tauri 2のCapabilitiesは、ウィンドウやWebViewの権限を設定し、フロントエンドからOS機能への露出を制限します。

公式は、緩すぎるスコープや不安全なRustコードを自動では防げないと説明しています。未修正のWebView脆弱性や、開発環境のサプライチェーン攻撃にも注意が必要です（出典: Tauri公式「Capabilities」、2026年確認）。

EU向けに販売・配布する場合は、Cyber Resilience Actを確認します。欧州委員会の2026年の情報では、報告義務は2026年9月11日、主要義務は2027年12月11日から適用予定です。

日本国内の社内利用が直ちに対象になるとは断定できないため、販売先や役割に応じて、法務・セキュリティ担当と整理します。

委託先や社内の担当者と決める対策は、次の三つに分けて確認します。

• 権限：ファイル・シェル権限の理由と不要権限の検査方法を確認する。
• EU対応：販売有無、提供者等の役割、サポート期間、報告担当を整理する。
• 国内運用：アクセス制御、ログ、バックアップ、端末紛失、退職者、再委託、脆弱性対応をRFPに記す。

個人情報や顧客情報、図面などを扱う国内業務でも、これらの対策が必要です。設計、実装、テスト、保守の各工程に責任を割り当て、その作業を見積に含めます。

よくある質問

発注時に迷いやすい点をまとめます。費用や納期は要件で変わるため、回答は固定値ではなく判断の考え方としてご覧ください。

Tauriのシステム開発費用はいくらですか？

費用は、PoCのような小規模な検証から大規模案件まで幅があります。区分ごとに、金額の目安と含まれる作業の違いを示します。

• 技術検証・小規模PoC：150万〜400万円程度。
• 部門向け業務アプリ：500万〜1,200万円程度。
• 現場システム：ローカルDB、同期・競合解決、端末運用などを含み、800万〜1,800万円程度。
• 業務基盤：複数部門・複数OS、SSO、複数サービス連携などを含み、1,500万〜4,000万円程度。
• 大規模システム：大規模スクラッチ、ERPやWMS連携などを含み、4,000万円〜1億円超のケースもあります。

オフライン同期や複数OS、基幹連携などの条件で、費用は変わります。厳格な監査や24時間運用も、費用に影響する条件です。

個別要件がない段階では、金額は断定できません。Tauri専用の公定価格ではないため、同じRFPで複数社に見積を依頼して比べます。

社内にRustエンジニアがいなくてもTauriを発注できますか？

発注はできますが、納品後の保守体制まで設計しておく必要があります。委託先には、Rustレビューや依存クレート更新を依頼します。脆弱性対応やOS別テスト、引き継ぎ教育も含めます。

社内には、業務仕様と運用判断を担う人を置きます。将来内製するなら、ソースコードに加えて設計判断やテスト手順を受け取ります。CI/CDや障害対応の記録も必要になります。

既存のElectronアプリをTauriへ移行する費用はどれくらいですか？

既存フロントエンドを再利用できれば、新規開発より短くなる可能性があります。ただし、金額は一概には言えません。

企画用の初期仮説は300万〜1,000万円、2〜4か月程度です。Node.js依存、子プロセス、ネイティブモジュールを調べて再見積します。

ファイル・シェル権限、署名、各OSの回帰テストも確認します。公開サービス事業者の短期移行の目安は、業務システム全体の納期とは分けて扱います。

Tauriで作る前にSaaSやPWAを検討したほうがよいですか？

会計、勤怠、CRMなど標準化しやすい業務では、まず既存SaaSやパッケージを比較します。

端末上のファイルや印刷、USBといった、ブラウザだけでは難しい要件があれば、Tauriを検討できます。常駐通知やオフライン入力、ローカル処理も判断材料になります。

選ぶ基準は、業務の独自性よりも、必要な端末連携と通信条件です。

まとめ

発注では、アプリの軽さよりも、現場業務を安全に動かし続けることを目指します。内製、部分委託、一括委託のなかから、社内体制に合う形を選びます。

RFPには、業務フローとデータ、対象OSを書きます。オフライン条件や権限、ログも記載します。そのうえで、バックアップや署名・更新、保守も含めます。

発注前に確認する要点

見積では、総額とあわせて、各工程と運用の項目が含まれているかを確認します。対象項目を並べて比べます。

• 開発範囲：要件定義、Rust実装、OS別テスト、データ移行。
• 運用・安全：同期、セキュリティ、署名、自動更新、教育、保守。
• 契約・検証：請負・準委任の責任、成果物、検収、権利、OSS、脆弱性対応、障害復旧。

最初から全機能を作るより、リスクの高い流れをPoCで検証してから本開発へ進むと、発注後の手戻りを抑えやすくなります。

相談時に共有するRFPと現場の制約

相談前には、対象業務と利用者数、端末とOSを一枚にまとめます。オフラインの有無や、既存のWebやElectron資産、API・DBも書き添え、保守の希望も伝えます。そのうえで、帳票・印刷や個人情報、希望時期も共有し、Tauriの採用判断から保守まで一貫して相談できる会社を選びます。

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

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