モバイルバンキングシステム開発の発注/外注/依頼/委託方法について

モバイルバンキングシステムの発注は、現行調査、要件と責任分界の明文化、提案と見積の比較の順に進めると、安全性と運用性を備えた導入につながります。発注形態の選び方、RFPと要件整理、契約と費用、委託先の選定を、この順に解説します。

▼全体ガイドの記事
・モバイルバンキングシステム開発の完全ガイド

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

モバイルバンキングシステムの概要と構成

モバイルバンキングシステムは、スマートフォンから銀行サービスを届けるチャネルシステムです。残高照会や振込、口座開設、本人確認、各種申込を非対面で扱います。

アプリだけを見て発注すると、背後の接続先や運用の作業が抜けがちです。そのため、アプリの外側まで含めて一つのサービスとして捉えます。APIゲートウェイや認証基盤、勘定系・情報系が中心になり、外部決済や管理画面、監視まで対象に入り、不正検知や顧客サポートも含みます。

アプリとバックエンドの役割分担

アプリは利用者の操作を受け付け、バックエンドは金融取引を安全に処理します。アプリの実装方式には、Swift、Kotlin、Flutterなどの選択肢があります。

• 取引ロジック：残高や送金の業務ロジックは、アプリに持たせません。
• API・バックエンド：認証・認可、冪等性、再送、監査ログを統制する役割を担います。
• エラー情報：画面へ返す内容と、タイムアウト時の扱いの取り決め。

振込ボタンが二度押されても、同じ取引が二重に実行されない仕組みが要ります。さらに、通信が途切れた後でも、取引の実行状況を確認できるようにしておきます。

この要件をRFPに書かず、「銀行アプリを開発してください」と依頼すると、画面は完成しても安全性や復旧性が足りなくなるおそれがあります。

対象範囲とKPIの事前決定

まず、既存アプリの刷新か、APIチャネルの新設か、勘定系を含むデジタルバンク基盤の刷新かを決めます。この判断で接続範囲が定まります。

残高・明細・通知だけのMVPなら、既存APIを活用できます。一方で、口座開設やeKYC、振込まで含めると、接続先と審査・テストの範囲が広がります。ことら送金、税公金、ローンまで入れると、その範囲はさらに大きくなります。

成果指標には、ダウンロード数に加えて、利用継続と業務成果を測る指標を組み合わせます。

• 利用：月間アクティブユーザー率、振込完了率
• 申込・業務：口座開設完了率、窓口手続きの削減時間、問い合わせ件数
• 安全・継続：不正検知率、障害からの復旧時間

参考として、マネーフォワードエックスの2025年発表では、BANK APPの総ダウンロード数は40万件超、年間平均MAU率は83％でした（出典: マネーフォワードエックス「BANK APP導入金融機関における利用実績」、2025年）。利用継続と業務成果を発注時からKPIに含めておけば、納品後に導入効果を評価できます。

発注形態の選び方

発注形態は、機能の独自性に加えて、金融機関がどこまで運用能力を持ちたいか、どれだけ速く変更したいかで選びます。方式ごとに得意な範囲は異なります。

• ホワイトレーベル・SaaS：標準機能を短い期間で導入できます。
• 共同利用・大手SI：既存資産や大規模な勘定系連携を重く見る方式です。
• スクラッチ・クラウドネイティブ：独自の体験づくりや内製化を優先する方式です。

ホワイトレーベル・SaaSが向く場合

ホワイトレーベル・SaaSを使うかどうかは、標準機能と独自要件のどこに差があるかで判断します。

• 共通機能：認証、残高照会、振込を提供し、通知と各種申込も含みます。
• 導入効果：自社ブランドで展開しながら、ゼロから作る工数を抑えられます。
• 適する場面：若年層との接点づくりや、複数行での共通利用が該当します。
• 独自機能：業務ルールや特殊な商品に加えて、分析や画面遷移も個別開発になります。

日立は2025年、「Branch in Mobile」をAWS上で運用するSaaS型サービスとして提供を始めました。金融機関側の環境構築の負担を抑える仕組みです。同社は、対面と非対面をつなぎ、簡易な追加や変更を金融機関側で内製化できるとしています（出典: 日立製作所「Branch in Mobileをクラウドサービスとして提供開始」、2025年）。

ただし、個別開発が増えるほど、標準サービスの価格面での優位は小さくなります。提案を受けるときは、標準機能の一覧に加えて、設定変更と個別開発の境界を確かめます。

共同利用・API基盤で既存システムを活用する利点と確認点

共同利用型を選ぶときは、共通化で得られる利点と、自行で決められる範囲を分けて確かめます。

• 共通利用：共通API基盤を使ったうえで、自行固有の部分を設定や拡張で合わせます。
• 共有できるもの：接続仕様、運用ノウハウ、セキュリティ対策が該当します。
• 判断上の注意：独自要件は、標準の仕様に合わせる必要が出てきます。
• 優先順位：機能追加は、自社の判断だけで進められない場合があります。

共通化によって、単独で構築する場合に比べてリスクと費用を抑えられます。筑波銀行は2025年12月、TSUBASA FinTech共通基盤を使った銀行アプリの刷新に着手し、2027年1月頃のサービス開始を発表しました。

同基盤は、外部事業者が共通の仕様で銀行システムに接続しやすくするオープンAPI基盤です（出典: 筑波銀行「TSUBASA FinTech共通基盤の利用およびスマートフォンアプリの刷新」、2025年）。比べるときは、参加行の標準仕様に自行の業務を合わせられるかどうかを、現行業務一覧と照らし合わせます。

独自性と変更速度を優先するスクラッチ開発・クラウドネイティブの場合

独自性と変更速度を重く見る場合は、スクラッチやクラウドネイティブが候補になります。

• 自由度：独自UXや商品設計に加えて、データ活用と内製化にも対応しやすくなります。
• 運用責任：認証や可用性から障害対応、勘定系連携まで、自行で理解し続けます。
• 段階導入：残高照会と通知から始め、口座開設や送金を後から追加できます。

外部に委託する場合でも、銀行側にプロダクトオーナー、業務責任者、セキュリティ責任者を置いておきます。

方式を比べるときは、導入期間と初期・月額費用、独自要件を並べて見ます。さらに、データの帰属や障害時の代替手段、終了時の移行可否も、同じ条件でそろえます。

モバイルバンキングシステム発注の進め方

発注は、段階を踏んで進めるものです。要件は一度に固めて会社へ渡す作業ではなく、現行調査からMVPを決め、要件と非機能、移行、運用を文書にまとめる中で詰めていきます。そのうえで提案と見積を比べ、契約に進みます。

企画から移行まで、各段階で銀行側の判断事項を残しておくと、外注プロジェクトの品質を安定させられます。

企画と現行調査による発注前提の整理

発注の前提は、企画、現行環境の確認、成果物の順にそろえていきます。

• 対象顧客と課題：既存インターネットバンキングとの役割、提供地域、取引上限、時期、KPI
• システム構成：勘定系、情報系、顧客管理の一覧
• API連携：参照と更新の範囲、ピーク時の性能、障害時の動きで見積が変わる
• 構成図と業務フロー：データ連携・認証方式の一覧、障害時の手作業、保守契約、OS更新制約
• 現行仕様の確認期間：現行の情報が得られない場合にRFPへ設ける期間

認証やATM、外部決済に加え、eKYCやコールセンター、監視も一覧に加えます。また、調査のあとに見積を更新できる段階契約も、検討の対象です。

要件定義とRFPによる提案条件の統一

各社の提案条件をそろえるため、RFPに要件と評価情報をまとめておきます。

• 目的と利用者：機能の範囲、画面数、対象ユーザー
• 基盤の要件：可用性や認証、ログ、監査の要件
• 性能と障害対応：RTO・RPO、応答時間、同時利用者数、障害通知時間
• 取引条件：FIDO・生体認証を使う取引、端末変更時の再確認、振込限度額を業務シナリオに沿って示す
• 不正対策：フィッシングや不正端末の検知方法、監査ログの保存年数

OSや外部連携、ユーザー数、ピーク取引数も書きます。バックアップと災害対策、移行、教育、保守も含めます。診断範囲と再委託管理も決めておきます。

FISC第13版は2025年3月発行で、金融庁のサイバーセキュリティガイドラインやオペレーショナル・レジリエンスを反映しています（出典: 金融情報システムセンター「金融機関等コンピュータシステムの安全対策基準・解説書 第13版」、2025年）。

運用準備としての設計・テスト・移行

運用準備として、設計から移行、銀行側のリリース判断までを順に決めます。

• 責任範囲：アプリ、BFF、APIゲートウェイ、認証と勘定系連携、通知
• 試験項目：単体・結合、実機・OS、性能、長時間稼働と障害復旧
• 試験シナリオ：送金の二重送信、タイムアウト、通信断
• 訓練：問い合わせや本人確認の失敗、ロック解除、障害告知、手作業への切替
• 移行の基準：移行項目、欠損時の扱い、照合件数、戻し方

脆弱性やペネトレーション、業務受入もテストに含めます。メンテナンスや取消・組戻しは試験シナリオに、インシデント報告は訓練に加えます。管理画面や監視、バックアップの担当も定めたうえで、銀行側の業務責任者が承認できる基準にします。

RFPと要件整理で決める事項

RFPは、価格を得るための資料であると同時に、自行が決めること、委託すること、受け入れることを社内で合意する文書です。

候補会社から同じ粒度の回答を得るために、現状、目的、範囲、前提をまとめます。必須要件や提案依頼事項、評価方法、契約条件も入れます。

利用者の行動と銀行内の処理による業務要件

業務要件は、対象業務ごとに、利用者の操作から銀行内の管理まで具体的に書きます。

• 振込：個人顧客が登録済みの振込先へ送り、通知で取引結果を確認する流れ
• 振込時の例外：限度額超過と残高不足の扱い
• 口座開設：申込、eKYC、審査を含む流れ
• 管理画面の担当：お知らせ、ユーザー状態、取引照会、権限、監査ログ、コンテンツ更新、障害告知

メンテナンスや組戻し、問い合わせも定義の対象です。口座番号通知やカード送付、本人確認失敗後の再申請も含みます。

担当が曖昧なままだと、銀行職員が変更できず、変更のたびに保守費がかかってしまいます。

数値と証跡で比べる非機能要件

非機能要件は、数値と確認方法をセットにして比べます。

• 可用性：計画停止の扱い、冗長化の単位、切替時間を定めます。
• 性能：平均応答時間や繁忙時の同時利用者数、取引ピークを指定します。負荷試験も求めます。
• セキュリティ：脆弱性や委託先管理、報告を要件に含めます。復旧訓練とログ監視も要件です。

金融庁のサイバーセキュリティガイドラインは2025年7月に一部改正され、組織改編に伴う技術的な修正が行われました（出典: 金融庁「金融分野におけるサイバーセキュリティに関するガイドラインの一部改正」、2025年）。あわせて、提案書の対応箇所、テスト証跡、契約上の担当主体を回答してもらいます。

RFP段階での受入基準と変更管理

RFPには、受け入れる成果と変更の管理方法を明記します。

• 業務の受入基準：業務シナリオの完了、正しいエラー案内、監査ログ、復旧手順、対象端末・OSでの動作
• 納品物：テスト結果、脆弱性診断報告書、性能試験、移行照合結果、運用手順書
• 変更管理：制度改正やAPI変更に備えた、受付から見積、承認を経てリリースまでの流れ
• 要件の区分：必須、優先、将来の区分、MVPの納期と機能追加、決定ログ

契約形態と責任分界の決め方

工程の性質に合わせて契約を組み合わせるのが現実的です。たとえば、調査や企画は準委任、仕様と成果物が明確な実装と検収は請負が候補になります。

標準サービスはSaaS契約で、認証やeKYCなどの外部サービスは利用規約と個別契約を確かめます。

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

契約は、要件がどれだけ確かかと、工程の性質に合わせて組みます。

• 準委任：専門人材の稼働や、調査・設計、アジャイル支援を任せる契約です。
• 請負：要件と成果物、検収条件、納期が固まった機能に向きます。

準委任は、完成の責任を一括で負わせません。その代わり、稼働時間や担当者、報告を別に定めます。成果物と品質基準も、契約で別に決めます。

仕様が曖昧なまま請負を結ぶと、変更費用や追加納期をめぐる争いが生じがちです。

実務では、現行調査と要件定義を準委任で行い、基本設計の後に見積を更新します。そのうえで、実装やテストは請負や段階契約へ移せます。

契約を分けるときは、成果物の権利と、次工程を受けない場合の引き継ぎ、既存ベンダーとの協力範囲を決めておきます。

SLA・セキュリティ・インシデント対応の契約条項

SaaSやクラウドを継続して運用する場合、契約でサービス水準と責任の境界を決めます。

• サービス水準：提供時間、計画停止、障害重要度、一次報告の時間、復旧目標
• 再委託と監査：再委託、監査権限、脆弱性対応の期限
• ログ確認と文書化：ログ確認者の決定、責任分界表の契約書と設計書への添付
• 障害時の取り決め：障害告知、取引照合、二重処理の確認
• 訓練の頻度：長期委託での、インシデント対応訓練の年間回数と、結果を改善へ結びつける方法

補償、バックアップ、データ所在も確かめます。基盤対策に加えて、アプリの脆弱性と認証設定、API権限の担当も定めます。監督当局や関係機関への連絡、再発防止の期限も含まれます。

データ・ソースコードと契約終了時の出口

契約終了時に返却するものを確認し、各項目の管理責任を明記します。対象は、ソースコードや設計書、API仕様、インフラ設定、監視ルールです。テストコードやログ、データ、アカウント、暗号鍵も含みます。

標準SaaSでソースコードを取得できない場合は、標準形式でのデータ出力と、移行支援の費用や期間、並行稼働の方法を定めます。

再委託先の追加や国外拠点、仕様変更を想定します。料金改定や買収、事業撤退も想定に含めます。さらに、運用継続に必要な管理者教育と文書更新も、契約に含めます。

モバイルバンキングシステムの費用相場

統一された価格はほとんどないため、ここで示すのは2026年時点の予算策定用の推定レンジです。

費用は、機能数や勘定系・API接続、認証の範囲で変わります。テストや移行、24時間運用、災害対策の範囲も費用を大きく動かします。見積を比べるときは、前提と除外項目をそろえておきます。

スコープ別の初期費用と期間の目安

初期費用と期間は、導入範囲ごとの推定レンジで見ておきます。

• 限定MVP：1,500万〜3,000万円、6〜9か月
• 標準的な銀行アプリ：3,000万〜8,000万円、9〜15か月程度
• 本格導入：8,000万〜1億5,000万円超、12〜24か月程度
• 基盤刷新を含む場合：1億5,000万円から数億円以上、18〜36か月以上の可能性

限定MVPは、残高・明細や通知、ログインと生体認証を中心に、既存API連携も含めます。送金や口座開設は後段に分けます。

標準的なアプリでは、iOS・Androidへの対応や振込・振替、管理画面が含まれます。認証強化や複数API、総合テストが加わります。

本格導入では、口座開設やeKYC、送金・決済、ローンを含みます。不正検知やFIDO、JPKIも加わり、監視と災害対策まで範囲に入ります。

金額は、一般的なアプリ開発費を金融案件の要件に置き換えて推定したものです。入札価格や公式価格ではありません（出典: 本稿の予算策定用推定、2026年）。

工程とリスクで見る見積の内訳

工程ごとの内訳と配分例を並べ、専門人材の単価も含めて見積を確かめます。

• 前工程：要件定義・基本設計、UX・画面設計、アプリ、API・バックエンド、外部接続が該当します。
• 後工程：テストや移行、リリース準備、PM、セキュリティ、運用設計です。
• 配分例：要件定義等10〜20％、実装30〜40％、テスト等20〜30％、残りはPM等
• 2026年の一般単価：iOS・Androidは月80万〜130万円、バックエンドは月70万〜120万円、PMは月80万〜140万円

配分は案件ごとに変わるため、比率だけで良し悪しを判断するのは避けます。人月単価についても、要員の範囲と専門工程を確かめます。

金融案件では、業務設計やセキュリティ、性能試験の専門人材が必要になります。監査対応や障害訓練の専門人材もいります。一般アプリの単価をそのまま当てはめず、安い見積では専門工程が除かれていないかを確かめます。

5年TCOによる初期費用と運用費の比較

5年TCOには、初期費用に加えて、継続費と終了時の移行費を含めます。ただし、初期費用が低くても、継続費が高ければ長期的な負担は大きくなります。

• 継続費：利用料やクラウド、監視・SOC、診断、OS更新、問い合わせにかかる費用です。
• 追加費：制度改正への対応や追加開発、外部認証、バックアップ、DR、教育の費用です。
• 5年TCO：初期開発、移行、ライセンス、月額・年額、保守、追加開発を合わせた額です。
• 運用・終了：監視や診断、障害対応、契約終了時の移行費を指します。

保守・改善費は、初期開発費の年10〜20％程度を暫定の予算として見ておきます。

クラウド費用と24時間運用費は、別建てで見積もります。金融向けの冗長化や監査、DRを含むクラウド費は、一般アプリの月額目安より上振れする前提で考えます。

窓口業務や紙・郵送の削減、不正被害の抑制なども、KPIと金額の両面で試算しておくと、経営会議で説明しやすくなります。

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

委託先は、知名度や総額よりも、導入実績や認証・不正対策の内容で比べます。API接続や24時間運用、障害時の責任分界、5年TCOも比較の対象です。

内製化の支援や、契約終了時の出口も質問票で確かめます。さらに、失敗条件と前提を率直に開示しているかも評価します。

担当範囲まで確認する金融実績

金融実績は、担当範囲と自社の要件に合うかを具体的に確かめます。

• 担当範囲：勘定系への接続が参照のみか更新までか、口座開設や送金の受入経験
• 運用の実績：運用行数、ユーザー数、障害や制度改正への対応、提案チームと運用チームが同じかどうか
• 候補の会社：共同利用型SI、クラウド型チャネル、総合アプリ、本人確認、ホワイトレーベル、組込型金融の会社

前提と除外項目をそろえた見積比較

各社の見積は、前提をそろえ、内訳を確かめたうえで、評価と再見積の順に比べます。また、「別途」と書かれた作業は、実行前に内容と単価、上限を確認しておきます。

• 対象範囲：ユーザー数、取引量、OS、画面数、API数、テスト端末、移行量、稼働時間
• 費用項目の並べ方：要件定義、アプリ、バックエンド、外部サービス、セキュリティ、性能、移行、教育、保守、予備費を横並びにする
• 見積の回答：必須と任意の要件を分け、標準機能、設定変更、個別開発、外部サービス費を別々に
• 評価項目：要件への適合、金融知識、セキュリティ、運用、品質、納期、変更対応、内製化、TCO
• 事後の確認：診断や障害訓練の有無、同じ前提での再見積と差額の理由

丸投げを避ける社内体制

意思決定の役割は銀行側に置き、調査や選定の段階から継続して管理します。

• 社内の体制：プロダクトオーナー、業務・システム・セキュリティの責任者、法務・コンプライアンス、店舗・コールセンターの代表
• 判断と報告：提供時期、顧客説明、障害時の判断は金融機関が担い、課題は週次、経営には月次で報告
• 判断の補助：迷う場合は、現行調査とRFP作成の短期フェーズを設け、複数社の意見で必要な機能と不要なカスタマイズを分けます。
• 所有権と競争性：後続開発を同じ会社に頼む場合の調査成果物の所有権、競争性と見積比較の維持

よくある質問

費用や期間は、機能の数だけでなく、既存システムや認証・セキュリティ、移行、運用の範囲でも変わります。発注時によく寄せられる質問に、順に答えます。

モバイルバンキングシステムの開発費用はいくらですか？

2026年時点の推定レンジでは、限定MVPが1,500万〜3,000万円、標準的な銀行アプリが3,000万〜8,000万円です。本格導入は8,000万〜1億5,000万円超になります。

勘定系や共通API基盤まで刷新する場合は、1億5,000万円から数億円以上になる可能性があります。

公開された定価ではありません。RFPで前提をそろえたうえで、再見積します。前提の例は、機能や接続数、認証です。テストや移行、運用も前提に含めます。

既存の勘定系を残してアプリだけ外注できますか？

外注はできます。ただし、既存の勘定系に安全なAPIがあり、残高・明細・振込・口座開設などを連携できることが前提になります。

APIが不足している場合は、BFFやAPIゲートウェイ、データ連携、認証統合、障害時の照合が追加の範囲になります。

現行調査で、アプリだけの範囲とバックエンド改修を分けて見積もります。

FISCや金融庁の基準は発注時にどう使いますか？

FISC基準は法令そのものではありませんが、金融システムの開発・導入・運用で必要な安全対策を確かめる実務基準として活用できます。

発注時は、基準を確認項目に分けておくと、委託先に何を確かめるかが定まります。

• 確認の段階：RFP、設計審査、テスト、運用訓練、監査。
• 対象の範囲：認証や権限、ログ、脆弱性管理、委託先、バックアップ、復旧、インシデント報告。
• 整理の方法：要求と設計対応、証跡、担当主体を表にまとめます。

モバイルバンキングシステムの委託先はどう選べばよいですか？

委託先は、次の観点で比べます。

• 導入の規模：自行に近い規模で、同じ勘定系や認証、取引量を扱った経験があるかを確かめます。
• 体制：提案チームと運用チーム、障害対応、FIDO・eKYC・JPKIの経験を比べます。
• 契約条件：SLAや再委託管理、5年TCO、データとソースコードの帰属。
• 出口：見積の前提と除外項目を説明でき、契約終了時の移行も提案できる会社を選びます。

まとめ

発注や外注では、アプリ制作会社を探す前に、アプリ刷新、APIチャネル新設、勘定系を含む基盤刷新のどれかを決めます。ホワイトレーベル・SaaS、共同利用、スクラッチを、自社の変更速度と運用能力に照らして比べます。

発注前のRFP・契約・受入基準

RFPでは機能に加えて、認証や冪等性、監査ログ、性能、可用性を数値と成果物で示します。復旧、移行、再委託、障害報告、運用教育も同じように示します。

契約は、準委任・請負・SaaSを工程に応じて使い分けます。SLAや責任分界、データ・ソースコードの帰属、終了時の出口を明記します。

見積は初期費用だけでなく、5年TCOで比べます。5年TCOには、保守やクラウド、監視、診断、制度改正、追加開発を含めます。

小さく始める場合の運用と安全性

残高照会や通知などのMVPから始めて、送金や口座開設、eKYC、ローンを段階的に加えていく方法もあります。

将来の認証やAPI、監査、監視、データ移行を見据えた構成にします。銀行側に意思決定の体制を置き、同じKPIで安全性と業務成果を確かめます。

▼全体ガイドの記事
・モバイルバンキングシステム開発の完全ガイド

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