BSS開発の発注/外注/依頼/委託方法について

BSS開発の発注は、対象業務を絞り、RFPと契約で責任を分け、段階的に移行する流れで進めます。これにより、請求精度と顧客体験の向上につながります。

発注形態の選び方から導入手順まで、各工程で決めることを順に説明します。全体像はBSS開発の完全ガイドもご覧ください。

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

BSSの発注・外注の意味と対象範囲

回線申込みが事業側と運用側の接点になります。

BSSの発注・外注とは、通信サービスの事業側を支えるシステムの企画、設計、開発、移行、運用を、外部のベンダーやSIerに任せることです。対象は企画から運用までの各段階に及びます。

対象には、顧客・商品・料金・注文の管理に加えて、利用量の収集、課金、請求、決済も含まれます。さらに、BSS単体で完結するとは限らず、OSS、CRM、会計、決済、本人確認、コンタクトセンターとの連携も範囲に含まれます。

BSSとOSSの責任範囲の分け方

BSSとOSSは担当する領域が異なり、回線申込みの場面で連携します。責任の線引きは、両者がどの業務を扱い、どこで受け渡すかを押さえたうえで行います。

BSS：顧客、契約、商品、料金、注文、売上など、事業側の業務を扱う
OSS：ネットワーク設備、開通、回線・リソース、障害など、運用側の業務を扱う
回線申込み：BSSが注文を受けてOSSに開通を依頼し、結果と利用実績を受け取ってから課金する

曖昧なままでは、障害時に責任の押し付け合いが起きます。そのため、この流れのどこを自社が担い、どこを委託先が担うかを、先に決めておきます。

BSS全体を一度に外注しない進め方

発注する領域は、BSS全体ではなく、抱えている課題に応じて機能単位で選べます。

委託範囲：商品カタログ、法人向け見積・CPQ、MVNOの申込みと課金などに分ける
新料金の投入速度：商品・料金管理から着手する
請求誤り：利用量の収集から請求確定までを優先する

機能を小さく区切ると、成果とリスクを確かめてから次の領域へ広げられます。そのため、全面刷新に比べて、発注側が意思決定しやすくなります。

BSSの発注形態の選び方

発注形態は、SaaSや既製パッケージを使うものから、フルスクラッチまで大きく分けられます。その間には、パッケージの設定や拡張、クラウド上の個別開発があります。

比べるのは初期費用だけではありません。料金変更の速さや、加入者数・イベント数が増えたときの拡張性も見ます。データ移行や既存OSSとの連携のしやすさも確認します。

こうした項目は、運用人材や契約終了後の移行性も含めた総保有コストで判断します。

標準業務に合わせやすいSaaS・パッケージ

SaaSやパッケージを選ぶときは、業務への適合性と継続費用の両方を確認します。

導入と運用：顧客管理、商品カタログ、請求、決済を早く立ち上げ、更新・監視・バックアップまで任せられる
標準機能との適合：特殊な料金計算や締め処理のルールを表現できるか確かめる
利用料と設定費：月額料金、初期設定、追加モジュール、API利用、環境数を見積もる
継続・解約費用：ログ保存、サポート、データ転送料、解約時のデータ返却費用も含めて判断する

クラウドネイティブ開発と段階移行の組み合わせ

段階的に入れ替えを進めるときは、サービス間で意味が揃う設計と運用かどうかを確かめます。

ただし、マイクロサービスを増やすだけで、自動的にうまくいくわけではありません。RFPの段階で、何を確かめるかを決めておくことが欠かせません。

連携と移行：商品、注文、課金、請求をAPIやイベントで連携し、領域ごとに入れ替える
データの整合：顧客ID、契約・注文状態、課金イベントの意味を揃え、不一致による突合の難化を防ぐ
RFPの確認事項：サービス境界、データ所有者、再送時の冪等性、監視、障害時の再処理を明確にする

差別化要件が明確な場合に限るフルスクラッチ

競争力の中心が独自の料金体系にある場合、個別開発が候補になります。パートナー精算、ネットワークAPI、法人向けSLA課金が中心でも同じです。標準製品に業務を合わせられない場合に、検討の対象になります。

顧客・契約・商品・注文の基本モデルは、標準製品を基盤にして使うのが現実的です。そのうえで、差別化の部分だけをAPIやマイクロサービスで追加します。

フルスクラッチでは、保守人材や障害対応、技術的負債を予算に含めます。ベンダーを交代する際の引き継ぎも見込んでおきます。

ポイント

発注形態は、初期費用だけでなく、料金変更の速さや拡張性、総保有コストで比べます。契約終了後に別の委託先へ移せるかも、あわせて確かめておくと判断しやすくなります。

BSSのRFPと要件整理で決めること

4領域をそろえると提案条件の抜けを見つけやすくなります。

RFPは開発会社に提案を求める文書です。また、自社の課題を整理する道具にもなります。

RFPには、機能名よりも担当者や業務を書きます。データや品質水準も、あわせて記載します。

規模を示すには、加入者数や1日・ピーク時の注文数を書きます。そのうえで、課金イベント数と請求締め時刻も示します。

連携先の数や移行件数、目標復旧時間も数値にしておくと、各社の見積条件を比べやすくなります。

機能より先に決める目的とKPI

「BSSを刷新する」という目標だけでは、完成したかどうかを判定できません。そこで、事業成果に置き換え、販売開始までの期間や手戻り件数などをKPIにします。

料金プラン：企画から販売開始までを2週間以内にする
注文と開通：手戻りを月間何件以下にするか定める
請求訂正：確定後の訂正を何時間以内に検知するか決める

たとえばMVNOでは、申込みから本人確認、回線開通、初回請求までを対象にします。法人ネットワークでは、見積から契約、注文、開通、SLA課金までを一連のKPIとして扱います。

データ項目とAPIの責任分界表

扱うデータ項目とAPIごとに、誰が何を受け持つかを決めておきます。

データ項目：顧客、契約、回線、商品、料金、注文を一覧にする。利用量、請求、決済、返金、パートナー精算も一覧に含める
責任分界：各情報の発生元、正本データ、更新者、保持期間、参照先を明記する
標準と固有要件：TM Forum Open APIや標準的なデータモデルに寄せる部分と、自社固有の要件を分ける
APIの確認：標準API対応の説明だけで安心せず、エラーコード、バージョンアップ、再送、認証方式、監査ログを確認する
連携テスト：実際の連携テストを提案に含め、仕様と運用時の責任範囲を双方で確かめる

非機能要件と移行条件の明確化

24時間運用のBSSでは、非機能要件と移行条件もRFPに含めておく必要があります。

運用要件：可用性や性能、拡張性を定める。監視、バックアップ、災害復旧、脆弱性対応も含める
管理要件：権限管理、監査ログ、サポート時間を定める
移行範囲：顧客・契約・請求履歴の移行件数、欠損や重複の扱い、新旧システムの並行稼働期間を決める
移行完了条件：データ移行だけでなく、新旧システムの請求金額、税、割引、日割り、返金が一致することも確認する

ポイント

RFPには、機能名よりも担当者や業務、データ、品質水準を書きます。規模を表す数値と目的KPIをそろえて示すと、各社の見積条件を比べやすくなります。

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

BSSは企画段階で仕様が固まりにくい一方で、請求や決済には誤りが許されにくいという特徴があります。そのため、工程ごとに契約形態を分ける方法が検討されます。

たとえば、要件整理は準委任、仕様が決まった後の開発は請負、運用は準委任やSLA付き契約とする例があります。ただし、実際の契約締結では、個別の法務判断について専門家に確認が必要です。

要件が変わる工程での準委任

作業しながら前提を明らかにしていく工程では、準委任が適する場合があります。現状分析や業務整理、PoCなどがその例で、データクレンジングやアジャイル開発も含まれます。

準委任では、月ごとの成果物と稼働する専門家を、発注側が明確にします。会議体、意思決定の期限、作業時間の上限も決めておきます。準委任でも品質は問えます。

レビュー基準や成果物の定義は、契約書や個別仕様書に記載します。課題管理や報告方法も書き込んでおくと、作業内容を確認しやすくなります。

完成条件が明確な部分の請負範囲の切り出し

完成物と受入条件を定義できる部分は、請負契約の対象として切り出せます。画面やAPI、バッチ、帳票、料金計算ロジックなどがその例です。

外部サービスの仕様変更や旧データの品質問題は、後から判明することがあります。そのため、前提条件と変更管理の方法を契約に記載します。追加費用が発生する条件や、納期を再協議する条件も書いておきます。

連携先の仕様や移行データの欠損を調べないまま固定価格だけを求めると、予備費や変更請求が膨らむ可能性があります。

契約書に入れるSLAと出口戦略

契約では、サービス水準と委託体制、契約終了時の扱いを具体的に定めておきます。

SLA：稼働率、障害検知・一次回答・復旧、課金イベント再処理、誤請求訂正、パッチ、データ復旧の目標を定める
委託体制：再委託先、国外クラウドの所在、監査権、事故連絡、損害対応と連絡責任を確認する
返却と消去：顧客・契約・商品・請求履歴、設定、ソースコード、API仕様、運用手順、ログの返却形式と消去時期を決める

出口戦略がないまま委託すると、将来のベンダーロックインを招くおそれがあります。

ポイント

完成条件を定義できる部分は請負の対象にし、前提を明らかにしながら進める工程は準委任に分けます。連携先の仕様や移行データが未調査のまま固定価格にすると、変更請求が膨らむおそれがあります。

BSS開発を外注する費用相場の目安

BSS専用の国内向け一律の価格表は公開されていません。そのため、ここに示す数字は実際の見積ではなく、要件整理や基幹システムの公開相場、通信事業者向けの機能・連携・可用性を踏まえた計画レンジです。

金額を左右するのは、加入者数やピーク時の課金イベント、料金ルールです。さらに、モジュール数やデータ移行、旧新並行稼働の期間も影響します。一般的な基幹システムの中規模は500万〜3,000万円、大規模は3,000万円〜数億円です。

人月単価は50万〜200万円程度が目安です（出典：株式会社ripla「基幹システム開発の見積相場や費用／コスト／値段について」、2026年確認）。BSSでは、通信特有の要件も加味して見積もります。

スコープ別の計画レンジ

対象規模ごとの費用と期間は、計画を立てる際の目安として使えます。

調査・PoC：料金計算の検証は500万〜2,000万円程度、1〜3か月
単一モジュール：既存BSSへの追加・交換は1,000万〜8,000万円程度、3〜9か月
小〜中規模ISP・MVNO：顧客、契約、課金、決済、会計、ネットワーク連携を含むクラウドBSSは3,000万〜1.5億円程度、6〜18か月
中堅通信事業者：複数料金体系・チャネル、OSS・会計・CRM連携、移行を伴う場合は1億〜5億円程度、12〜30か月
大規模刷新：複数ブランドの段階刷新は5億〜30億円超、2〜5年程度。全面フルスクラッチは10億〜数十億円以上、3〜7年程度

これらは試算で、発注前に予算の幅を置くために使います。市場価格を断定するものではありません。

初期費用以外も比べる見積の内訳

見積は費用の種類ごとに区切ってもらい、初期費用と継続費用の両方を比べます。確認する区分は下の4点です。

初期の作業と製品：要件定義や業務設計、製品ライセンスやSaaS利用料を分けて示してもらい、設定や開発、API・ETL・OSS連携の費用も区分して確認する
移行と切替の準備：データクレンジングや移行リハーサル、性能・請求精度テストが見積に含まれるかを確かめ、教育や切替、並行稼働、運用設計も対象かを見る
クラウドの継続費用：環境数と従量課金が継続して発生し、ログや監視、バックアップ、災害復旧、サポート、データ転送料も継続費用として見込む
パッケージとスクラッチの将来費用：パッケージではライセンスと保守が将来のコストになり、スクラッチでは保守人材と技術的負債を考慮に入れる

3〜5年のTCOで比べる発注先

初年度の費用が安くても、追加ライセンスや独自カスタマイズ、運用要員の費用が高ければ、数年後の負担が増えます。障害対応や環境追加、データ抽出の費用も、あわせて確認します。

比べる際は、初期費用や月額・年額、従量課金、保守の費用を同じ前提でそろえます。改修単価や追加連携、教育、切替支援、契約終了時の移行費も含めます。

一般的な基幹システムでは、保守費を開発費の15〜20％／年程度と置く考え方もあります。BSSは24時間運用やサービスレベルによって保守費が変動しやすいため、各社の内訳を確認します。

ポイント

費用は、初期費用だけでなく、保守や追加変更、契約終了時の移行費まで含めて比べます。計画レンジは予算の幅を置くための試算として扱い、見積の内訳で差を確かめます。

BSSの委託先の選び方

委託先は、知名度や提示金額に加えて、実際の業務経験で比べます。確認するのは、通信業務への理解や、同規模の加入者・取引量での経験です。課金・請求の品質、移行力、国内運用体制、契約終了後の移行性も見ます。

成功事例の数字は、ベンダーの自己申告です。そのため、匿名化された実績の前提や顧客規模、対象モジュール、期間、発注側の体制を聞き取り、可能であればPoCや顧客紹介で検証します。

通信・MVNO・ISPの類似実績

通信・MVNO・ISPの案件では、経験と検証体制を確認します。

通信業務：従量・定額・日割り・割引、MNP、回線開通の経験を確認する。利用量の遅延、請求締め、未収、返金、パートナー精算の経験も確かめる
法人ネットワーク：見積・CPQ、複数拠点、SLA、従量課金、注文から開通までの連携実績を評価する
検証体制：同程度のピークイベント数、障害時の再処理、請求精度の検証方法を具体的に説明してもらう

移行・運用・障害対応の体制

移行・運用・障害対応では、責任者と手順を確かめます。

責任者：データ移行、テスト、リリース判定の担当者を確認する
障害対応：24時間の一次対応と、OSS・決済事業者を含む指揮系統を見る
切替手順：旧新システムの突合、段階切替、ロールバック、問い合わせ窓口、重大障害のエスカレーションを提案書に記載してもらう
発注側の役割：商品、料金、請求、顧客データの意思決定者を置く
業務判断：委託先へ任せきりにすると優先順位が決まらず、納期や費用が膨らみます

同じ条件にそろえた提案と見積の比較

複数社に依頼して見積を比べるときは、条件を先にそろえておきます。

回答形式：初期費用、ライセンス、月額、工数、連携数、移行件数を分けて提示してもらう
比較条件：テスト範囲、並行稼働、保守、追加変更の単価を示し、見積に含むものと含まないものを明記してもらう
安い見積：要件定義、移行、性能試験、運用引き継ぎ、障害対応が別途でないか確認する
高い見積：不要なフルスクラッチや過剰なカスタマイズが含まれていないか精査する

ポイント

委託先は、知名度や提示金額に加えて、通信業務の経験と、移行や障害対応の体制で比べます。実績の数字は自己申告のため、PoCや顧客紹介で裏づけを取ると判断材料が増えます。

BSSの発注から開発・リリースまでの進め方

現状把握から要件合意を経て発注準備へ移ります。

BSSの外注は、発注先を決めた後も続きます。現状診断から要件とデータの整理、方式選定、PoCまでを管理します。さらに、設計・開発から移行、テスト、段階切替、運用移管までが対象になります。

契約前にすべてを詳細化できなくても、各工程で決めることと次の工程へ進む条件を明らかにしておきます。そうすることで、変更を管理しやすくなります。

最初の90日での現状と優先順位の確定

90日間は、現状把握、要件合意、発注準備の順に進みます。各段階で用意するものを、ひとつずつ確かめていきます。

最初の30日：業務フロー、システム構成、データ項目、連携先を洗い出す。障害履歴、請求誤り、運用コストも、あわせて把握する
次の30日：目的KPI、優先モジュール、発注方式、移行対象、非機能要件を合意する
最後の30日：RFP、評価表、PoCシナリオ、概算予算、契約方針を整える

商品カタログや課金イベントのサンプルも用意しておくと、候補会社の提案を実務に即して比べられます。

PoCで試す料金変更と障害時の再処理

PoCでは、料金と異常処理のシナリオを試します。画面の見た目を確認するだけでは、検証として十分ではありません。

料金処理：新しい料金プランの登録、割引の併用、日割り、上限超過、返金、請求締め
異常処理：利用イベントの遅延、同じイベントの再送、決済失敗、ネットワーク開通の失敗

処理速度に加えて、異常を検知する担当者と、参照するログを確認します。再処理データや二重請求の防止方法も、あわせて見ます。そのうえで、PoCの結果を本番導入の受入条件へつなげます。

ストラングラーパターンによる段階的な切替

旧システムと突き合わせながら対象を広げるストラングラーパターンが、現実的な方法です。

ビッグバン方式：一度に停止して新システムへ移すため、障害時の影響が大きくなる
段階移行：新ブランド、新料金、法人向けサービス、商品カタログなどから始め、旧システムと突合して範囲を広げる

Ericssonは2025年にIndosat Ooredoo Hutchisonの事例を公表しました。約1億のサブスクリプションを含む大規模なBSS変革で、段階移行の事例と説明しています（出典：Ericsson公開事例「Indosat Ooredoo Hutchison」、2025年）。

ただし、大規模事例をそのまま再現できるわけではありません。切替単位を小さくする考え方の参考になります。

2026年のBSS外注で注意する最新動向と安全要件

2026年のBSSでは、クラウドネイティブやAPIファーストの考え方が注目されています。統合データやリアルタイム課金、AIやエージェントによる業務支援などにも、関心が集まっています。

古いBSS・OSSや分断されたデータ、属人化した料金ルールが残っている企業もあります。AIを導入するだけでは、こうした問題は解消しません。

発注の際は、新技術を採用した実績よりも、業務データや権限、監査、失敗時に人が止められる設計を確かめます。

AI活用の権限・監査・停止条件のRFP記載

TM Forumは、2026年のOpen Digital Architecture資料で、従来のシステム境界を越えたリアルタイム判断を取り上げています。

自律性の高いエージェント型AIへの対応も扱っています（出典：TM Forum「Transformation 2.0: towards an AI-native Open Digital Architecture」、2026年）。

操作の管理：BSSでAIが実行できる操作を認可し、ポリシーと加入者の監督下で監査可能にする
RFPの条件：AIに料金変更、返金、契約変更を任せる場合は、対象データ、実行可能な操作、承認者、ログ、上限額、異常時の停止条件を記載する

個人情報と通信の秘密の共同管理

BSSで扱う情報と委託時の管理要件を整理し、発注時点の最新版を契約に反映します。個人情報保護委員会の公開ページには、電気通信分野のガイドライン解説について、2026年4月と5月の新旧対照表が掲載されています。さらに、通則編も2026年6月に一部改正されています（出典：個人情報保護委員会「特定分野ガイドライン」「通則編」、2026年）。

対象情報：氏名、連絡先、本人確認情報を扱う。契約、請求、決済、利用履歴も含まれる
適用ルール：個人情報保護法、電気通信分野の個人情報等保護ガイドライン、通信の秘密に配慮する
改正情報：発注時点でガイドラインの最新版を確認する
委託要件：利用目的や第三者提供、国外移転、再委託を定める。保存期間、削除請求、漏えい時の連絡も含める

運用手順と受入条件にするセキュリティ

RFPと受入テストでは、データ保護やアクセス制御、障害時の処理を確かめます。

データとアクセス：データ分類、最小権限、特権ID管理、職務分離、保存時と通信時の暗号化、API認証を定める
不正・障害対策：レート制限や再送防止、料金変更と請求確定の改ざん防止ログを含める。脆弱性パッチの期限や、バックアップ、復旧目標、再委託先監査も盛り込む
受入テスト：権限のない担当者が料金変更できないこと、再処理で二重請求にならないことを確認する
監査ログ：変更者と承認者を追跡できることを検証する

セキュリティは開発後の検査で終わらせず、設計・契約・運用へつなげます。

よくある質問（FAQ）

BSSの発注では、費用や期間、委託範囲、開発会社の選び方について、多くの疑問が生まれます。発注前に特に確認されやすい質問に、順に答えます。

BSS開発の発注費用は数千万円で足りますか？

単一モジュールの追加やPoCであれば、数千万円以内に収まる可能性があります。一方で、顧客から決済までを含み、OSS連携や移行も扱う場合は、3,000万〜1.5億円程度から計画するケースがあります。

これはBSS専用の一律相場ではありません。そのため、加入者数や料金ルールなどの条件を示し、複数社から同じ前提で見積を取ります。連携数や移行件数も、あわせて伝えます。

BSSはパッケージとスクラッチのどちらがよいですか？

標準的な顧客・商品・注文・請求を早く導入するなら、パッケージやSaaSを基盤にし、差別化部分だけを追加する方法が有力です。

独自料金や精算、ネットワーク連携が競争力になり、標準機能に業務を合わせられない場合は、個別開発を検討します。モジュールごとに、標準化する領域と作り込む領域を分けます。

RFPがなくてもBSSの開発会社へ相談できますか？

相談できます。現状の課題や対象業務、加入者数、連携先を整理するほど、提案の精度が上がります。請求締めや移行件数、予算、期限も、早めに伝えておくと役立ちます。

詳細なRFPをすぐに作れない場合は、現状診断や要件整理を準委任で依頼できます。その成果を使って、本開発のRFPと見積を作ります。

相談時は、開発だけでなく、移行やテスト、運用、契約終了時のデータ返却についても確認します。

BSSの運用まで外注するべきですか？

24時間監視や障害の一次対応、定型的なリリース、バックアップは、外注しやすい領域です。一方で、商品・料金の最終承認や顧客データの利用目的、請求訂正、重大障害の経営判断は、発注側が担うことをおすすめします。

運用を委託する場合でも、サービスオーナーやデータ責任者、承認者、エスカレーション先は決めておきます。SLAと運用手順も、契約に含めます。

委託範囲を広げるほど、監査権と出口戦略も重要になります。

まとめ

BSSの発注では、全体を一括で委託せず、優先する領域を先に決めます。顧客や商品の管理から、課金、請求、決済まで、どこから始めるかが問われます。

SaaSやパッケージ、クラウド開発、スクラッチは、初期費用だけで比べず、3〜5年のTCOで判断します。移行やテスト、運用、保守、契約後の移行性も、その中に含めて考えます。

発注前のRFP・契約・受入条件のそろえ方

RFPには、目的KPIや加入者数、ピークイベント数を記載します。業務・データ・APIの責任分界、非機能要件、移行対象も書き込みます。請求精度、障害時の再処理、セキュリティ、SLAも含めます。

契約では、準委任と請負の範囲、追加費用の条件を明確にします。再委託や監査、データ返却、ソースや設定の引き継ぎも、あわせて明記します。

委託先については、通信・MVNO・ISPの類似実績と運用体制を確認します。そのうえで、同じ条件の見積を比べます。

最初の一歩は業務とデータの洗い出し

発注前の準備は、業務とデータの洗い出しから、PoC、移行条件、候補会社との前提合わせへと進みます。

顧客、契約、商品、料金、注文のデータを一覧にする。利用量や請求データ、連携先も含める
最も事業インパクトの大きい領域でPoCを行い、段階移行、旧新突合、ロールバック条件を決める
確認項目をRFPの評価表へ転記し、自社の業務責任者と候補会社で前提をそろえる

▼全体ガイドの記事
・BSS開発の完全ガイド

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