加入者管理システム開発の発注/外注/依頼/委託方法について

加入者管理システムの発注・外注は、顧客情報を登録する画面だけでなく、契約受付からSIM/eSIMの開通、認証、料金連携、停止・解約、監査までの責任範囲を定義して進めることが成功の条件です。

本記事では、通信事業者やMVNO、ローカル5G・IoT事業者が加入者管理システムを委託する際に、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、検収と運用移管までを実務の順番に沿って解説します。

▼全体ガイドの記事
・加入者管理システム開発の完全ガイド

加入者管理システムは何をどこまで発注するものですか？

加入者管理システムの発注範囲は、BSS型の契約・顧客管理を中心にするか、通信コアの加入者データ管理まで含めるかで大きく変わります。最初に範囲を分けずに見積を依頼すると、各社が異なる前提で金額を提示し、安い提案を選んだ後に機能不足や追加費用が発生しやすくなります。

BSS型は、契約者情報、料金プラン、注文、請求、問い合わせ、SIM在庫、管理者向け画面など、事業運営に近い機能を扱います。一方、通信コア型は、加入者の認証・認可、ネットワーク接続可否、APN、QoS、ローミング条件、在圏やセッションに関わるデータを扱います。4GではHLR/HSS、5GではUDMとUDRが中心となるため、後者は一般的な顧客マスタよりも可用性とリアルタイム性の要求が高い領域です。

発注書やRFPには、「契約者・回線・SIM/eSIMを管理するBSS範囲」「MNOや通信コアと接続するプロビジョニング範囲」「HLR/HSS/UDM/UDRを自社で保有するか」「料金計算・請求を既存システムに任せるか」を明記します。加入者管理という一つの名称でまとめず、業務機能、ネットワーク機能、外部接続の三層に分けると、提案内容を比較しやすくなります。

MNOやフルMVNOは、加入者データとネットワーク接続を自社の責任で管理する範囲が広くなります。IIJの解説では、フルMVNOはHLR/HSSを自ら運用し、MNCやIMSIを保有する事業形態と説明されています（出典: IIJ「フルMVNOとは」、2019年、2026年閲覧）。この場合は、回線開通の電文、SIM/eSIMの発行、障害時の切り分け、ローミング、認証鍵までを含めて委託先と責任分界を定めます。

ライトMVNOや通信機能を外部サービスに任せる事業者は、契約・料金・顧客画面と、MNOが提供する開通APIの連携が中心になる場合があります。ローカル5GやIoTでは、利用者が従業員や機器であるため、電話番号よりも端末識別子、拠点、SIM在庫、利用許可、閉域接続、機器交換の履歴が重要になります。自社の事業区分とデータの正本を先に決めることが、外注費を抑える出発点です。

発注・外注前に決めるべき業務とデータは何ですか？

RFPを作る前に、現場の業務を「契約受付、本人確認、SIM/eSIM発行、開通、プラン変更、利用停止、再開、解約、請求、問い合わせ、障害対応」というライフサイクルで並べます。各工程で誰が操作し、どのデータを更新し、どの外部システムにいつ連携し、失敗時に何を戻すのかを決めると、画面一覧だけでは見えない要件が明らかになります。

たとえば新規契約では、本人確認が完了した後に契約番号を採番し、SIMまたはeSIMの識別子を割り当て、料金プランと利用制限を登録し、開通要求を送信します。外部側が成功を返した場合だけ顧客画面を「利用中」にするのか、タイムアウト時は「確認中」に留めて再送するのかまで決めておく必要があります。二重開通や、画面上は開通済みなのにネットワークでは未登録という不整合を防ぐためです。

停止・再開・解約も同じように、即時処理か予約処理か、未払い・不正利用・本人申請のどれが起点か、請求を先に止めるか通信を先に止めるかを整理します。業務部門だけでなく、ネットワーク運用、請求、カスタマーサポート、情報セキュリティの担当者を要件定義に参加させると、後工程の手戻りを減らせます。

データ項目は、契約者ID、回線ID、IMSI、MSISDN、ICCID、eSIMプロファイル、料金プラン、利用量、速度制御、APN、QoS、ローミング許可、認証情報、請求プロファイル、端末識別子、在圏・セッション情報などに分けて棚卸しします。そのうえで、どのシステムが正本を持ち、誰が参照・更新でき、更新結果をどのAPIやメッセージで伝えるのかを決めます。

接続先には、CRM、注文管理、料金計算、請求・決済、本人確認、SIM在庫、MNO、HLR/HSS/UDM/UDR、監視、データ分析などが含まれます。インターフェース一覧には、通信方式だけでなく、認証方式、タイムアウト、再送回数、冪等性キー、エラーコード、監査ログの保存先を記載します。これらが見積の前提に入っていない提案は、開発後に連携費用が増える可能性があります。

加入者数だけでなく、通常時とキャンペーン時の新規開通件数、認証要求のピーク、同時接続数、許容応答時間、稼働率、RTO、RPO、データ保持期間、監視時間帯を数値化します。通信コアを含む場合は、平常時の性能だけでなく、片系障害、ネットワーク分断、外部APIの遅延、データベース復旧、再送が集中する場面の合格条件も必要です。

個人情報、通信の秘密、本人確認記録、認証鍵を同じ権限で扱わないことも重要です。携帯音声通信事業者には、本人確認記録を役務提供契約の終了日から3年間保存する義務があります（出典: e-Gov法令検索「携帯音声通信事業者による契約者等の本人確認等及び携帯音声通信役務の不正な利用の防止に関する法律」、2026年現行法）。発注時点で、最小権限、管理者の多要素認証、鍵の保管方式、操作ログの改ざん防止、再委託先のアクセス、バックアップ暗号化、退職者の権限削除を要件と検収項目に落とし込みます。

発注形態はパッケージ・クラウド・スクラッチのどれがよいですか？

発注形態は、初期費用の安さだけで決めず、標準機能で事業要件を満たせるか、加入者数や取引量の増加に耐えられるか、自社が運用責任を担えるかで選びます。BSSだけを作るのか、通信コアと24時間運用まで委託するのかによって、適切な組み合わせも変わります。

通信キャリア向けの製品やパッケージは、HLR/HSS、UDM/UDR、認証、プロビジョニング、冗長化などの標準機能と導入実績を活用しやすい方式です。通信コアをゼロから作るより、標準準拠や障害対応の知見を取り込みやすく、短期導入を目指す案件に向きます。ただし、ライセンス、加入者数、CPU、接続先、保守時間、追加モジュールによる料金体系を確認しなければ、初期見積だけでは総額を判断できません。

パッケージを選ぶ場合は、デモ画面よりも、実際の契約変更、開通失敗からの再送、4Gと5Gの併存、地理冗長、データ移行、監査ログを確認します。標準機能に合わせて業務を変えられる部分と、カスタマイズが必要な部分を分け、カスタマイズの保守責任と将来のバージョンアップ方法まで提案書に書いてもらいます。

クラウドやマネージドサービスは、設備調達と一部の監視運用を外部に任せ、事業の立ち上げを早めやすい方式です。加入者数の増加に応じてリソースを拡張しやすい一方、データの保管場所、鍵管理、MNOとの接続方式、通信遅延、障害時の責任分界、サービス終了時のデータ返却を契約前に確認します。

「クラウドだから安全」「マネージドだから運用不要」と考えると、監査証跡や権限管理が不足します。誰が加入者プロファイルを変更できるのか、ベンダーの運用担当者が本番データに触れる条件は何か、緊急変更をどう記録するかを、SLAやセキュリティ付属文書に含めます。料金も、基本利用料だけでなくAPI呼び出し、データ転送、監視、バックアップ、検証環境、サポートの追加料金まで確認します。

独自の料金制度、特殊な加入形態、既存CRMや請求基盤との複雑な連携がある場合は、スクラッチ開発やパッケージへの拡張が候補になります。ただし、通信コアの認証、標準インターフェース、高可用性、性能試験、鍵管理までを全面的に自作するのは、開発後の責任も大きくなります。独自性が必要な業務層だけを作り、コア機能は実績ある製品やサービスを組み合わせる方が、リスクと費用を抑えやすいケースがあります。

通信コア製品ベンダー、国内SI、MVNO運用に詳しい事業者を分けて選定し、共同提案を依頼する方法もあります。その場合は、代表窓口、設計責任、障害時の一次切り分け、ライセンス契約、再委託、ソースコードや設計書の帰属を一つの責任分界表にまとめます。複数社体制でも、発注者が全体の受入責任を負うことを忘れないことが重要です。

加入者管理システム開発を外注する進め方はどうなりますか？

外注は、いきなり本開発を一括発注するより、現行調査と要件整理を先行させ、技術的な不確実性をPoCで確認してから本開発へ移る進め方が安全です。特にMNO接続、既存HSSとの共存、eSIM開通、請求連携、ピーク性能は、資料だけでは判断しにくい項目です。

自社に業務とネットワークの情報が集まっていない場合は、現行調査・業務整理・RFP作成だけを準委任で発注する方法があります。成果物は、業務フロー、システム関連図、データ項目一覧、連携先一覧、非機能要件、移行方針、運用体制、概算予算、提案依頼書とします。これにより、本開発の見積を同じ前提で複数社から取得できます。

RFPには、対象範囲だけでなく、加入者数、月間・ピーク時の開通件数、認証要求数、4G/5Gの対象範囲、既存システム、MNO接続仕様、データ移行件数、希望稼働時期、運用時間、SLA、RTO/RPO、セキュリティ基準を記載します。提案者に「含むもの・含まないもの・前提条件・追加費用」を分けて回答してもらうことが、見積比較の土台になります。

要件定義では、機能一覧を作るだけでなく、成功条件をテスト可能な形にします。たとえば「新規契約を処理できる」ではなく、「本人確認完了後に契約番号を採番し、指定時間内にSIM/eSIM情報を登録し、MNOまたは通信コアへの開通要求を一度だけ送信し、応答を監査ログに残す」と書きます。失敗時の再送、取消、手動復旧も同じ粒度で定義します。

PoCでは、実データを匿名化したうえで、開通・停止・再開・プラン変更、認証失敗、外部APIのタイムアウト、重複要求、片系障害、データ復旧を確認します。5Gの加入者データは、UDMが加入者データや認証データを利用し、UDRにデータを保管できる構成が標準で整理されています（出典: ETSI TS 23.501 V19.5.0、3GPP Release 19、2026年1月）。技術検証の費用と成果物を本開発前に合意すると、後から大規模な設計変更が起きにくくなります。

本開発は、契約・加入者マスタと管理画面、開通・停止・プラン連携、請求・CRM連携、5G・ローミング・IoTなどに分けると、優先順位を付けやすくなります。新規事業なら、最初から全機能をそろえるのではなく、限定した加入者数と料金プランでMVPを稼働させ、開通処理と監査を確認してから対象を広げる方法が現実的です。

既存サービスを移行する場合は、旧HSSや既存のBSSを止めずに、新しいUDM/UDRや契約管理を並行稼働させる方式を検討します。Nokiaの移行資料でも、既存のHSS/HLRや4G向けデータベースを残し、5G向けUDRを並行導入する選択肢が整理されています（出典: Nokia「5G Non-Standalone to 5G」、2026年閲覧）。移行単位、切替条件、ロールバック、旧システムの廃止時期を契約書と受入計画に含めます。

受入試験は画面の操作確認だけで終わらせず、契約受付から開通、課金、停止、解約、監査までを通したシナリオで実施します。性能試験ではピーク時の開通と認証、障害試験では外部接続断、データベース障害、片系停止、バックアップ復旧、監視通知を確認します。テストデータ、試験環境、実施者、合格基準、障害修正の期限を発注段階で決めます。

納品物には、設計書、API仕様、データ移行手順、監視項目、障害時の切り分け表、バックアップ・復旧手順、鍵と証明書の更新手順、脆弱性対応方針、運用教育資料を含めます。運用開始後にベンダーへ問い合わせるだけの体制ではなく、一次対応、二次対応、MNOやクラウドへのエスカレーション、重大障害の報告時間をSLAに書きます。

契約形態は準委任と請負をどう使い分けますか？

加入者管理システムでは、要件が固まっていない工程と、納品物と合格基準を決められる工程が混在します。そのため、全工程を一つの契約形態にそろえるより、要件整理は準委任、本開発の一部は請負、運用改善は準委任というように、成果の確定度に合わせて使い分ける方法が適しています。

準委任は、専門家の知見や作業の提供を受ける契約で、現行調査、業務整理、RFP作成、アーキテクチャ検討、PoC、PMOなど、状況に応じて検討を深める工程に向きます。加入者数やMNO接続仕様がまだ確定していない段階で、完成品の納品を前提に請負契約を結ぶと、前提変更のたびに追加契約や責任論が起きやすくなります。

ただし、準委任にすれば成果物が不要になるわけではありません。月次の業務フロー、課題一覧、設計判断記録、PoC結果、RFP案、リスク管理表などを成果として定義し、稼働時間、担当者、報告方法、秘密保持、再委託、知的財産の扱いを決めます。作業の進め方に発注者が関与する場合も、責任範囲を曖昧にしないことが必要です。

請負は、合意した仕様に基づくシステム、設計書、テスト結果、移行ツールなどを納品し、検収する工程に適しています。ただし、「加入者管理機能一式」のような抽象的な成果物では、どこまで完成すれば合格か判断できません。機能ごとの受入シナリオ、性能値、可用性、ログ、セキュリティ試験、移行件数、未解決障害の許容範囲を検収基準にします。

仕様変更が起きたときの変更管理も契約に含めます。変更要求の受付、影響範囲、追加工数、納期変更、承認者、緊急時の判断を決めておくと、口頭依頼が無制限に積み上がることを防げます。特に料金プランや本人確認のルール、MNOの接続仕様が変わる場合は、標準機能の変更なのか追加開発なのかを切り分けます。

通信コアや本人確認を含む場合は、元請会社だけでなく、製品ベンダー、クラウド事業者、運用会社、テスト会社など複数の委託先が関与することがあります。再委託の事前承諾、再委託先の所在地とアクセス範囲、秘密情報の管理、監査への協力、契約終了時のデータ削除・返却を定めます。認証鍵や本人確認記録を扱う担当者の身元確認と権限レビューも確認項目です。

障害時は、誰が一次受付を行い、何分以内に重大度を判定し、どの条件でMNOやクラウドへ連絡し、何時間以内に暫定復旧と報告を行うかを決めます。システムの不具合だけでなく、開通処理の不整合、誤ったプラン反映、認証鍵の更新失敗、データ移行の欠損も重大障害として扱う必要があります。契約書と運用手順書の内容を一致させることが大切です。

加入者管理システムの費用相場はいくらですか？

加入者管理システムの費用は、BSSだけなら数百万円から、MNO接続や通信コア、24時間運用、大規模移行まで含めると数千万円から数億円まで広がります。公開された一律の価格表はほとんどないため、以下は2026年時点の一般的な開発相場と、通信基盤特有の負荷を組み合わせた計画用の推定です。実際の見積は、加入者数、ピーク処理量、対象世代、接続仕様、移行件数、SLAで変わります。

現行調査・要件整理・RFP作成は150万〜500万円程度、小規模なBSS型で契約・加入者マスタ、管理画面、CSV/API連携に絞る場合は500万〜1,500万円程度が計画上の目安です。クラウド型の加入受付・プロビジョニングMVPは1,000万〜3,000万円程度、MVNO向けにHLR/HSS連携、BSS/OSS、課金、監視、移行、総合試験まで含める場合は3,000万〜1億円程度を見込むことがあります。

UDM/UDRを含む5G基盤、4Gとのデュアルモード、冗長化、認証、複数ネットワーク機能、データ移行、災害対策、24時間運用まで含めると、5,000万〜3億円以上が予算枠になることがあります。キャリア規模の多地域・多ネットワーク刷新では、1億〜5億円以上を想定する場合もあります。これらの通信コアの金額は直接の公開価格ではなく、一般的なシステム開発相場と高可用性・専門人材・ライセンス・試験の負荷から算出する推定です。

一般的な2026年版の市場解説では、システム開発の人月単価はスキルや地域で60万〜200万円程度、複雑な基幹システムや業界特化システムは数千万円から億単位になる場合があるとされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。加入者管理では通信プロトコル、移行、24時間運用などの専門工数が加わるため、単純な画面数だけで相場を判断しないことが重要です。

見積書では、要件定義・アーキテクチャ設計、アプリケーション開発と連携、基盤・ライセンス・クラウド、データ移行、性能・障害・セキュリティ試験、教育・運用設計を分けて記載してもらいます。特に通信コアでは、HSMまたは同等の鍵保護、検証環境、バックアップ、地理冗長、監視、証明書更新、MNO接続試験が別費用になっていないかを確認します。

ランニング費用には、クラウド利用料、製品ライセンス、加入者数や処理量に応じた従量料金、24時間監視、保守、脆弱性対応、バックアップ、回線・SIM/eSIM、検証環境、問い合わせ窓口が含まれます。初期費用の年15〜25％程度を保守・更新の仮置きにすることはできますが、製品やSLAによって変わる推定値です。5年間の総保有コストで比較し、加入者が増えた場合の単価も試算します。

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

委託先は、知名度や見積総額だけでなく、同じ通信方式、同じ規模、同じ移行条件で成果を出せるかを確認します。通信コア製品ベンダー、BSS/OSSを統合する国内SI、フルMVNOやSIM運用に詳しい事業者では得意領域が異なるため、単独提案と共同提案を同じ評価軸で比べることが必要です。

実績確認では、「通信業界の経験があります」という説明だけで終わらせず、4G/HSS、5G/UDM/UDR、MNO接続、フルMVNO、ローカル5G、IoT、SIM/eSIM、料金・請求、24時間監視のどこを担当したかを聞きます。加入者数、ピーク処理量、移行件数、障害対応の体制、運用開始後の保守期間も確認し、可能なら匿名化された構成図やテスト項目のサンプルを提示してもらいます。

公式事例では、EricssonとSwisscomがPacket Core、UDM、IMSを含む環境でクラウドネイティブなDual Mode Coreを導入し、ネットワーク機能の展開を従来の数週間・数か月から数日単位に短縮する方向を示しています（出典: Ericsson「Swisscom and Ericsson driving performance partnership」、2025年）。このような事例も、導入効果をそのまま自社に当てはめず、対象範囲、移行条件、運用体制が自社と一致するかを確認して評価します。

比較表には、要件定義、設計、開発、ライセンス、基盤、連携、移行、試験、教育、運用設計、保守、追加変更の単価を並べます。各項目について、作業内容、工数、人月単価、期間、担当会社、成果物、除外事項、前提条件、再委託の有無を記載します。合計金額の低さだけでなく、必要な作業が抜けていないかを確認します。

提案内容の評価では、機能適合性、通信・セキュリティの専門性、移行計画、性能と可用性、運用体制、プロジェクト管理、費用、契約条件を分けて点数化すると判断しやすくなります。たとえば価格だけで30点を配分すると、安いが運用や移行が弱い提案を選びやすくなります。自社の失敗リスクが大きい項目に高い配点を置くことが大切です。

見積が相場より大幅に安い場合は、通信コアのライセンス、性能試験、データ移行、24時間運用、セキュリティ、障害時の再送や復旧が除外されていないかを確認します。反対に高い見積でも、製品費や人月が一式になっていて、加入者数が増えたときの追加料金や保守範囲が不明なら、将来の予算を判断できません。

提案段階で質問への回答が担当営業だけに留まり、通信設計者や運用責任者が説明に参加しない場合も注意が必要です。契約前に、実際のプロジェクト責任者、技術リーダー、運用窓口、再委託先を確認し、担当者が変わる場合の引き継ぎ条件を決めます。RFPへの回答が曖昧な項目は、契約後の追加費用と納期遅延のリスクとして評価表に残します。

よくある質問（FAQ）

加入者管理システムを外注する際に、特に判断に迷いやすい質問をまとめます。自社がBSS中心なのか、MVNO開通基盤なのか、5Gコアの加入者データ基盤なのかを確認しながら、発注範囲と契約条件を決めてください。

同じではありません。顧客・契約・料金・請求を扱うBSS型も加入者管理に含まれますが、通信サービスではHLR/HSS/UDM/UDR、認証、開通、ネットワークポリシー、SIM/eSIMまで含む場合があります。RFPで対象範囲を分け、各システムの正本と連携責任を明記してください。

全工程を請負にする必要はありません。現行調査、RFP、要件整理、PoCは準委任、本開発や明確な移行ツールは請負、稼働後の改善や監視は準委任など、成果と責任が確定しているかで分けます。どの契約でも、成果物、作業範囲、検収条件、変更管理、障害対応を具体的に記載することが重要です。

まず、契約・加入者マスタ、開通、料金、通信コア、分析などを分け、事業開始に必要な最小範囲から段階導入します。標準機能やマネージドサービスを使える部分は活用し、独自開発が必要な業務だけをスクラッチにします。RFPで前提条件をそろえ、要件定義やPoCを先に行って手戻りを減らすことも、総額を抑える方法です。

外注はできますが、通信コア製品ベンダーやMVNO運用に詳しい会社との共同体制が望ましいです。SI会社には業務・請求・CRM・移行・PMOを担ってもらい、通信コアの標準準拠、認証、性能、冗長化、MNO接続は専門会社が責任を持つように分けます。元請会社が全体の責任分界と障害時の窓口を引き受けることを契約で確認してください。

まとめ

加入者管理システムを発注するときは、最初にBSS型の契約・料金管理と、HLR/HSS/UDM/UDRを含む通信コア型の範囲を分けます。次に、契約受付からSIM/eSIM開通、認証、課金、停止・解約、監査までの業務とデータの正本を整理し、加入者数、ピーク処理、SLA、RTO/RPO、移行、セキュリティをRFPへ記載します。

費用や納期の比較を始める前に、BSSと通信コアの境界、正本データ、外部接続、非機能要件、移行方式、運用時間を一枚の前提シートにまとめます。提案各社に同じシートへの回答を求めれば、見積の差が機能の抜けによるものか、方式や体制の違いによるものかを判断しやすくなります。

選定時は、提案書の機能だけでなく、障害時の連絡網、再委託先、鍵や個人情報へのアクセス、テストと移行の責任、検収後の保守を確認します。加入者管理は稼働後の変更と障害対応が続く基幹領域のため、納品時点ではなく、運用を含めた総保有コストと体制で発注先を決めることが重要です。

発注形態は、標準機能を使うパッケージ、運用負荷を抑えるクラウド、独自要件に対応するスクラッチ、専門会社を組み合わせる共同体制から選びます。要件整理とPoCは準委任、本開発や明確な移行成果物は請負など、工程の確定度に合わせて契約を分けると、変更と責任の混乱を抑えられます。費用は小規模BSSの500万〜1,500万円程度から、MVNO連携で3,000万〜1億円程度、5Gコアや大規模移行で5,000万〜3億円以上まで幅があるため、初期費用だけでなく5年間の運用総額で比較してください。

委託先を選ぶ際は、価格より先に、対象と同じ通信方式・規模・移行条件の実績、担当者の専門性、再委託先、24時間の障害対応、検収後の運用体制を確認します。見積書の前提、除外事項、追加単価、ライセンス、クラウド、試験、移行、保守を同じ項目で並べれば、加入者管理システムの発注判断を具体的に進められます。

▼全体ガイドの記事
・加入者管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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