モバイルバンキングシステム開発の完全ガイド

モバイルバンキングシステムは、アプリ、認証、API連携を含むチャネル基盤です。企画では、方式、進め方、運用のそれぞれを分けて決めていくと、全体を整理しやすくなります。

各テーマの詳細は、下の関連記事で確認できます。

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

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

画面の背後では複数の基盤やネットワークがつながります。

モバイルバンキングシステムは、スマートフォンアプリを通じて銀行取引を提供する仕組みです。利用者が見る画面はアプリですが、その裏側では認証基盤、APIゲートウェイ、勘定系・情報系システムが連携します。

さらに、決済ネットワークや本人確認サービス、通知も連携先になります。管理画面、監視、不正検知、サポート業務まで含めると、連携先はさらに増えます。そのため、画面の数だけで規模や費用を判断すると、重要な連携と運用の工数が抜け落ちます。

アプリ単体とチャネルシステムの違い

対象範囲によって、開発の中身と規模は次のように変わります。

アプリ単体の刷新：既存のインターネットバンキングやAPIを活用し、iOS・Androidの利用体験を改善する範囲。
チャネルシステムの再構築：認証、顧客・口座データ、取引処理、通知、監査ログまで新しくする場合。
勘定系の切り替え：移行計画と並行稼働から、障害時の復旧訓練まで含む別規模のプログラム。

対象範囲を最初に決めておけば、過大な投資と後からの追加費用を抑えられます。

主な機能と標準的な構成

アプリで使える機能は、大きく4つのまとまりに分けられます。

照会・取引：残高・入出金明細・口座情報、振込・振替、個人間送金
支払い・申込：税公金や各種料金の支払い、口座開設、住所変更、ローン申込
検索・問い合わせ：店舗・ATM検索、問い合わせ
本人確認：eKYC、生体認証、FIDO、マイナンバーカードを使う公的個人認証、ワンタイムパスワード、多要素認証

本人確認の方式は、取引のリスクに応じて組み合わせます。アプリの前段にはBFFかAPIゲートウェイを置き、認証・認可と入力検証をそこで行います。二重実行を防ぐ冪等性やタイムアウト、再送の扱いと、監査ログの取得も、この層で管理します。

モバイルバンキングシステムの種類と開発方式

方式を選ぶときは、機能数や残す既存資産、独自性を比べます。導入の速さや内製化の範囲、5年間の総保有コストも並べて見ます。標準機能に合うかどうか、制度変更や新しい認証方式を後から追加しやすいかも、初期費用と同じくらい重要です。

パッケージ・ホワイトレーベル型

標準機能を持つサービスに、金融機関のロゴや色、文言、接続先を設定する方式です。残高照会や明細、振込などの基本機能、通知や認証を短期間で始めやすく、共通機能の更新も取り込めます。

独自の業務ルールや画面遷移を大きく変えると、追加開発が増えます。そのため、標準機能に合わせる範囲と個別開発の単価は、契約前に画面単位・API単位で確認しておきます。

クラウド・SaaS型

クラウド・SaaS型は、サーバー構築や基盤運用の手間を減らせる方式です。ただし、採用前に確認しておきたい点もあります。

基盤運用：クラウド上の共通基盤を使うことで、金融機関側のサーバー構築や基盤運用の手間を減らせます。
負荷と環境：増減するアクセスに対応しやすく、環境構築の期間も短くできます。
共通利用：対面と非対面のチャネルを同じ基盤で扱う、公開された事例があります。
簡易な変更：ローコード機能や自動テストを使い、金融機関側で手軽に調整できるサービスもあります。
採用前の確認：データの所在や再委託、障害時の代替、終了時のデータ返却、監査ログの取得可否。

共同利用・API基盤型

複数の金融機関が、共通のAPI仕様や接続基盤を使って個別開発を減らす方式です。機能追加やセキュリティ対応を横展開しやすく、人員が限られる地域金融機関の機能拡張にも有効です。

2025年12月に公表された導入計画には、共通API基盤を使って銀行アプリを刷新し、2027年1月頃のサービス開始を予定する例もあります（出典: 金融機関によるシステム開発着手の公表資料、2025年）。独自の業務ルールを共通仕様に合わせる判断が必要です。

フルスクラッチ・クラウドネイティブ型

独自の顧客体験や商品、データ活用、内製化を重視し、アプリ・API・バックエンドを個別に設計する方式です。変更の速さや独自性を高められる一方で、金融業務の理解と、可用性・セキュリティを含む24時間運用を支える人材とプロセスが必要です。

まずAPIとチャネルを分離し、勘定系の機能は一度に置き換えず、段階的に移していきます。残高照会や各種申込から移すと、障害時の影響範囲を管理しやすくなります。

ポイント

既存資産を残すかどうか、独自性をどこまで求めるかで方式は変わります。迷ったときは、5年間の総保有コストと標準機能への適合度を並べて比べると判断しやすくなります。

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

前工程の成果を次の設計や判断へ引き継ぐ流れです。

開発は、画面デザインより先に、目的と取引範囲、現行システムを整理します。リスクや運用体制も、同じ段階で押さえておきます。

企画からリリースまでを一つの納品物と見なさず、工程ごとの成果物と意思決定を定めておきます。セキュリティや法務、コンプライアンスの担当者と業務部門には、早い段階から参加してもらいます。

企画・現行調査・要件定義

経営課題のままでは、機能の形が決まりません。そこで、若年層との接点づくりや店舗事務の削減、非来店で完結する口座開設などを、利用者の行動に置き換えます。

利用KPI：ダウンロード数だけでなく、月間アクティブ率、ログイン継続率、送金・申込完了率を測ります。
業務・不正KPI：問い合わせ件数や事務時間、不正検知・阻止率も対象にします。
棚卸し対象：勘定系、顧客管理、認証が対象です。インターネットバンキングや外部決済、コールセンター、店舗業務も対象になります。
整理する内容：連携方式、データの正本、障害時の手作業。

UX設計・API設計・実装

残高照会や振込、本人確認、申込などの業務シナリオごとに、操作を分けて考えます。正常系の画面に加えて、通信切断や二重タップ、認証失敗のときの画面も設計します。さらに、メンテナンスや送金保留、上限超過のときの画面も設計します。

APIでは、認証・認可と入力値の要件に加え、取引状態や冪等キーの扱いも明文化します。タイムアウトやリトライ、監査ログについても、要件を決めておきます。

取引ルールはアプリ側に持たせすぎず、サーバー側で一貫して検証できるようにしておきます。そうすると、OS更新や画面変更の影響を抑えやすくなります。

テスト・移行・リリース・改善

テストからリリース後の改善までは、次の順で進めます。

単体・結合テストに加えて、端末とOSの組み合わせや性能、負荷、障害復旧を確認し、脆弱性とペネトレーション、操作性やアクセシビリティも検証します。
業務受入では、送金や口座開設を実際の手順で確認します。障害時に誰が利用者へ案内するかも、あらかじめ決めておきます。
対象の顧客や機能を絞って段階的に広げ、エラー率や離脱、問い合わせの状況を見ながら改善を進めます。

▶ 詳細はこちら：モバイルバンキングシステム開発の進め方

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

対象範囲が広い区分ほど、予算と計画期間も大きくなります。

銀行向けの公開定価は少ないため、以下に示すのは2026年時点の予算策定用の推定レンジです。

この金額は、入札価格や特定サービスの公式価格ではありません。機能範囲や既存APIの状態、認証の方式で変わるほか、テストや運用、移行の前提でも変動します。特に「アプリだけ」と「勘定系や共通基盤も含む」案件は、同じ言葉でも桁が変わります。

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

初期費用と期間の目安は、対象範囲によって次のとおり異なります。

限定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や公的個人認証、不正検知と監視、災害対策も含めます。

見積もりに含めるべき費用

見積もりは、企画・要件定義、UX、アプリ実装に分けて提示してもらいます。さらに、API・バックエンドと外部接続、管理画面、テストも区分してもらいます。加えて、移行や教育、PM、セキュリティ審査も別々に示してもらいます。

概算では、要件定義・基本設計が10〜20%、実装が30〜40%、テスト・移行・リリース準備が20〜30%という分け方が使え、残りがPM・セキュリティ・予備費にあたります。案件固有の前提も併記します。

両OS対応や接続先の数、eKYC、FIDOが加わるほど、費用は上振れします。JPKIや24時間監視、端末試験と災害対策、データ移行が加わると、さらに上振れします。

5年間のTCOによる比較

初期費用に加えて、運用・保守やサービス利用の費用も、5年間で積み上げて比べます。

運用費：クラウド利用料、監視・SOC、脆弱性診断、OS更新
その他の継続費：証明書・認証、問い合わせ、制度改正、障害対応、追加開発
保守・改善費：初期開発費の年10〜20%程度を暫定予算として見込めます。金融向けの冗長化・監査・復旧訓練は個別見積もりです。
ホワイトレーベル・SaaS：初期導入は500万〜2,000万円程度の場合もあります。月額・年額の利用料や接続、ブランド変更、個別機能も含め、総額で比べます。

ホワイトレーベルやSaaSの初期導入額は、公開情報と金融案件の構成をもとにした推定です（出典: 一般的なスマートフォンアプリ開発費の公開情報と金融案件の構成をもとにした推定、2026年）。

▶ 詳細はこちら：モバイルバンキングシステム開発の見積相場・費用

ポイント

費用は、対象範囲を先に決めてから見積もると比べやすくなります。画面数だけでなく、接続先や認証、運用の範囲を揃えて比べ、5年間の運用費まで含めて判断します。

開発会社・サービスの選び方

候補は、知名度や資料の見栄えだけで決めず、同じ質問票で比べます。比べる観点は、自行と同規模・同勘定系・同運用条件の実績と、金融業務への理解です。加えて、障害時の責任分界、安全性の説明力、5年TCOも、同じ基準で見ていきます。

個社名の順位は付けず、候補を評価する観点を示します。

金融業務と既存システムの実績

「アプリを作った実績」だけでなく、どの領域を担当したかを聞きます。残高や取引の正確性、口座開設・本人確認、振込や決済が対象です。さらに、勘定系連携や障害復旧、監査対応も確認します。

同規模の金融機関では、利用者数や接続先、開発期間を確認します。加えて、運用時間や重大障害の対応体制、現在の保守担当も聞いておきます。固有名詞を出せない場合は、匿名化した構成図や役割、テスト範囲、SLAの実例が判断材料になります。

認証・安全対策・運用の説明力

候補会社には、次の対策に加えて、各機能の実装・運用・責任者を確認します。

認証：FIDO、生体認証、公的個人認証、eKYC
不正対策：不正検知、端末リスク判定
運用管理：特権アクセス管理、監査ログ、脆弱性診断、SOC、災害復旧

金融機関等コンピュータシステムの安全対策基準・解説書は、2026年3月に第14版が公表されました。AIやサイバーセキュリティ、耐量子計算機暗号、システム障害事例などが反映されています（出典: FISC「金融機関等コンピュータシステムの安全対策基準・解説書」第14版、2026年）。

提案会社が、この基準をRFPの要件や設計レビュー、受入テストにどう落とし込むかを説明できるかが重要です。

契約・内製化・TCOの比較

契約では、完成後に金融機関側で変更できる範囲と、ソースコードや設計書の帰属を確認します。加えて、データの持ち出しや再委託先も確認します。

料金変動：月額利用型は初期費用を抑えられる一方、利用者数や取引量に応じて費用が増える場合があります。
契約形態：請負・準委任・ライセンス・SaaSから組み合わせを決めます。
個別条件：追加変更の単価、障害対応時間、制度改正の範囲を契約書と別紙に記します。
比較：5年間の総額と出口戦略を並べ、判断材料にします。

契約終了時の移行支援を含め、データやシステムを引き継げる条件を確認します。

▶ 詳細はこちら：モバイルバンキングシステム開発でおすすめの開発会社6選と選び方

ポイント

候補は、同じ質問票と同じ条件で比べます。実績は同規模の金融機関での担当範囲まで確かめ、契約ではデータの持ち出しと終了時の移行条件を押さえておく必要があります。

発注・外注・委託を成功させる方法

金融システムを外注する場合も、銀行側が要件と優先順位を持っていなければ、判断を委託先に丸ごと預けることになります。

発注前に、RFPと評価基準を整えます。そのうえで、段階契約や受入条件、SLAについて合意しておきます。さらに、インシデント報告や再委託管理のほか、データ移行、契約終了時の出口も決めておきます。

RFPに書くべき項目

RFPには、利用条件・セキュリティ・非機能要件を記載します。

利用条件：対象顧客・取引、現行システムとAPI一覧、データの正本、利用者数・取引量。対応端末、稼働時間、目標可用性、RTO・RPO。
セキュリティ・運用：認証方式、監査ログ、暗号化、脆弱性診断。障害時の手作業、移行対象、教育、保守窓口。
非機能要件：性能、セキュリティ、アクセシビリティ、監視。バックアップ、テスト、運用引き継ぎ。

非機能要件を分けると、提案会社ごとの比較がしやすくなります。

契約形態と段階発注の使い分け

契約形態は、要件が固まった実装部分か、調査や仕様変更が多い部分かによって使い分けます。

請負：要件が固まり、成果物と検収条件を定義できる実装部分に適します。
準委任：調査・企画・専門支援や、仕様変更が多い部分に適します。
SaaS・ホワイトレーベル：利用規約、サービスレベル、データ利用、価格改定、終了時の移行を確認します。
段階発注：全工程を一括で発注せず、現行調査・構想、MVP、段階展開のゲートで区切ります。前工程の成果を見てから、次の投資を決めます。

銀行側の責任者と受入基準

委託先との責任分担を明確にし、銀行側でも運用を担える体制を整えます。

責任者：経営判断、業務プロダクトオーナー、システム、セキュリティ・コンプライアンス、現場代表の各分野を担う人を置きます。
意思決定：毎週の進捗確認に加えて、誰が何を決めるかを明確にします。仕様変更やリスク受容、リリース延期、障害時の公表判断が対象です。
受入基準：機能完了や重大脆弱性ゼロ、性能目標、復旧時間を含めます。監査ログや運用手順、問い合わせFAQ、訓練完了も含め、検収後に運用できる状態を定義します。

▶ 詳細はこちら：モバイルバンキングシステム開発の発注・外注・委託方法

ポイント

外注しても判断は銀行側に残るため、要件と優先順位、受入基準は発注前に定めておきます。段階発注にしておくと、前工程の成果を見て次の投資を決められます。

セキュリティ・法規制・2026年の最新動向

利便性を上げるほど不正利用の入口も増えます。法令や業界基準を確認し、利用者のリスクに応じた認証や取引監視、障害・不正時の連絡、委託先管理を、一体で設計します。

2026年は、AIの安全な利用やサプライチェーン、耐量子計算機暗号、レジリエンスを初期要件に含めておきます。

取引ごとの認証と不正送金対策

ログイン時の本人確認と、高額送金や新しい端末からの操作を、同じ強度にそろえる必要はありません。生体認証やFIDOでログインの負担を減らしつつ、端末変更や送金先追加、限度額変更、初回取引などでは、追加認証や取引内容の確認を求める設計が現実的です。

検知ルールだけに頼らず、利用者への通知や取引保留、コールセンターの確認を、一つの業務フローにまとめます。証跡保存や補償・調査手順も、同じ流れに含めます。

FISC・金融庁ガイドラインの要件への落とし込み

銀行法や個人情報保護、犯罪収益移転防止法上の本人確認の要件を確かめます。機能に応じて資金決済法や金融商品取引法なども、法務・コンプライアンスの担当者と確認します。

FISCの安全対策基準は法令そのものではありませんが、開発・導入・運用の安全対策を検討する実務上の基準です。金融庁のサイバーセキュリティガイドラインでは、委託先やサードパーティを含む管理も論点になります。

RFPに「対応済み」と書かせるだけでなく、脅威モデルや設計書、テスト証跡を納品物に含めます。さらに、インシデント報告や再委託管理表も、納品物として扱います。

AI・共通基盤・内製化の動向

AI・共通基盤・内製化を検討するときは、次の動向と要件を確かめます。

AI・安全対策：FISC第14版は2026年3月に公表され、AIやサイバー対策、耐量子暗号、障害事例を反映しています。
AI利用要件：問い合わせや審査補助、運用分析では、機密性や誤回答への対策を定めます。モデル変更、出力監査、人の最終確認も決めておきます。
共同化：金融機関どうしで共通APIやホワイトレーベルを使い、機能や安全対策を持ち寄る動きが続いています。

公開実績では、2025年5月末までの2年間に累計ダウンロード40万件、年間平均MAU率83%を記録した事例も公表されています（出典: 地域金融機関向けバンキングアプリの利用実績公表、2025年）。ダウンロード後の継続利用を測ることの重要性が分かります。

導入後のKPIと運用・保守

リリース後は、利用者の行動と業務成果を改善していきます。ダウンロードは入口の指標であり、取引の完了や事務削減、不正抑止も含めて見ます。顧客満足や安定性も、そこに加えて評価します。

月次のKPIレビューと四半期ごとの機能・セキュリティ・TCOレビューを運用に組み込むと、追加開発の優先順位を説明しやすくなります。

事業成果を測るKPI

事業成果は、利用状況や取引の指標に、業務と不正対策の指標を組み合わせて測ります。

利用状況：登録率、月間・週次アクティブ率、ログイン継続率、機能別利用率、通知開封率
取引：振込開始から完了までの成功率、送金先登録率、口座開設の本人確認完了率、申込離脱率
業務：窓口・コールセンターへの問い合わせ削減、事務処理時間、ペーパーレス化件数
不正対策：検知率、誤検知率、保留からの復旧時間、被害額
若年層の獲得：年齢層別の継続利用や預金・取引の変化を見て、ダウンロード数だけで評価しない

運用・保守の役割分担

運用・保守では、監視や障害対応を、定期作業や復旧訓練と連動させます。

監視：可用性、応答時間、APIエラー、認証失敗、送金保留、通知遅延を確認
障害対応体制：重要度ごとの連絡先と復旧手順を決める
定期保守：OS・証明書の更新、脆弱性対応、外部サービスの仕様変更、制度改正に対応
障害時の連携：利用者告知、取引の再実行防止、残高・明細の整合性確認、行内・委託先への報告
復旧訓練：年に複数回実施し、手順を更新

改善ロードマップの段階化

初期リリースでは、利用頻度が高く、既存APIで安全に提供できる機能を優先します。ログインや残高・明細、通知などが、これにあたります。

次の段階では、振込・送金や口座開設、住所変更へ広げます。税公金やローン、資産管理も順に加え、取引データと問い合わせ内容をもとに改善します。

機能を追加するたびに、脅威モデルや権限、ログを再確認します。性能やアクセシビリティ、業務手順もあわせて見直します。短いリリース周期を保ちながら、金融水準の統制も両立させます。

ポイント

成果はダウンロード数だけでなく、取引の完了や事務削減、不正抑止の結果で判断します。月次と四半期のレビューに組み込むと、追加開発の優先順位を説明しやすくなります。

モバイルバンキングシステムに関するよくある質問

企画や発注で質問されやすい論点を並べます。費用と期間はスコープによって変わるため、各回答には前提条件を添えています。

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

費用の推定レンジは、開発のスコープごとに異なります。

限定MVP：1,500万〜3,000万円です。
標準的な銀行アプリ：3,000万〜8,000万円です。
本格型：8,000万〜1億5,000万円超が予算策定上の推定レンジです。
勘定系・共通基盤の刷新：1億5,000万円から数億円以上になることがあります。

画面数だけでなく、接続先や認証、テストを含めて比べます。さらに、監視や移行、5年間の運用費も含めて見ます。

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

できます。既存の勘定系やインターネットバンキングは残したまま、APIゲートウェイやBFFを介して新しいアプリを接続する方法があります。

ただし、APIが古い場合や、認証が画面に埋め込まれている場合、取引状態が不明確な場合には、アプリの改修だけでは安定しません。そのため、先に連携と認証、監査ログを調べておきます。

FIDOやeKYCは必ず導入すべきですか？

すべての機能に同じ認証を当てはめるのではなく、取引のリスクに応じて組み合わせます。対象は、ログインや端末登録、送金先追加のほか、送金や限度額変更などです。

FIDOや生体認証は利便性とフィッシング耐性の向上に役立ちます。eKYCや公的個人認証は口座開設や本人確認の強化に有効です。

導入前には、業務フローに沿って検証します。まず、対象取引や端末対応、本人確認書類を確かめます。さらに、失敗時の再試行やコールセンター対応、監査証跡も見ておきます。

開発期間はどのくらいかかりますか？

限定MVPは6〜9か月、標準的な銀行アプリは9〜15か月、本格型は12〜24か月が目安です。

現行調査やセキュリティ審査、勘定系の改修が必要な場合は、期間が長くなります。総合テストや移行リハーサルが加わると、期間はさらに延びます。MVPの取引範囲を絞り、段階リリースで安全に学ぶ計画が現実的です。

まとめ

モバイルバンキングシステムは、アプリだけでなく、認証やAPI、勘定系・情報系との連携を含む顧客チャネル基盤です。さらに、外部サービスや監視、不正検知、業務運用も含まれます。

まず、「アプリだけの刷新」「標準アプリの導入」「API・共通基盤や勘定系までの刷新」のどこを目指すかを決めます。そのうえで、KPIと5年TCOを基準に方式を比べます。

社内で最初に決めること

まず、対象顧客と解決したい業務課題、今回の取引範囲を決めます。次に、既存システムを残す範囲や認証と不正対策の方針、目標KPIを定めます。最後に、予算上限とリリース時期、運用責任者を決めておきます。

RFPでは機能・非機能・セキュリティ・テスト・運用・契約終了時の出口を分け、複数候補に同じ条件で回答してもらいます。

小さく始めて安全に広げる進め方

段階導入は、MVPで小さく始め、効果を測りながら機能を広げていく進め方です。

MVP：全機能を一度に作るのではなく、既存APIを活用して、利用者の行動と運用課題を確かめます。
段階展開：送金や口座開設、決済、ローン、資産管理へ広げ、投資判断とリスク管理を両立しやすくします。
効果測定：継続利用、取引成功率、事務削減、不正抑止、安定稼働を測ります。
継続改善：安全性と業務の統制を保ちながら続けることが、経営成果への近道になります。

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