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

料金管理システムの発注・外注費は、料金ルール、連携範囲、導入方式によって、数百万円から数十億円以上まで変わります。

金額の幅を読むには、発注する範囲と契約の形を先に決めておくことが欠かせません。全体像は料金管理システム開発の完全ガイドにまとめています。

▼全体ガイドの記事
・料金管理システム開発の完全ガイド

料金管理システムを発注・外注する前に知るべき全体像

料金管理システムの発注範囲を機能・データ・運用の3層に分けた図解。
各層の対象をそろえると、見積もりの抜けを見つけやすくなります。

料金管理システムは、BSS(Business Support System)の中核に位置する基幹システムです。料金計算だけを切り出した単機能ツールとして捉えると、周辺との境界が抜け落ちがちです。

「請求機能を作ってほしい」とだけ伝えると、契約・回線・SIM・サービスオーダーの境界があいまいなまま進みます。利用明細、決済、会計との境界も同じようにあいまいになるため、後から追加費用がかかりがちです。

請求ライフサイクルを一つの業務として捉える考え方

請求の範囲は、料金プランの企画から会計連携までを一つの流れとして見ると、全体を把握しやすくなります。

  • 前工程:加入受付、本人確認、契約成立、開通
  • 計算工程:利用実績の収集、正規化、料金計算
  • 回収工程:請求、決済、入金消込、滞納、返金、会計連携

計算工程の中心は、メディエーションとレーティングです。

発注前に、どの業務を自社で持ち、どの機能を外部サービスやMNOに任せるかを決めておきます。さらに、料金管理システムに保存するデータまで決めておくと、RFPの範囲がはっきりします。

日鉄ソリューションズも、MVNO向けの契約・課金管理を一連の基幹業務として説明しています。対象は、料金プラン設定、加入受付、サービスオーダー、請求根拠データです。

請求データ作成と回収管理まで含むため、発注範囲は請求書の発行画面よりも広く見る必要があります。

機能・データ・運用の3層で見る発注範囲

見積の抜け漏れを防ぐには、機能・データ・運用の3層に分けて、それぞれに含まれるものを確認します。

  • 機能:顧客、契約、課金、請求、決済、会計連携
  • データ:加入者数、明細件数、保持年数、移行、外部連携
  • 運用:料金プラン追加、訂正、監視、問い合わせ、リリース承認

機能の範囲には、顧客・法人アカウント、契約・回線・SIM、商品カタログを含めます。料金条件では、基本料、従量課金、段階課金、割引を確認します。キャンペーンや家族割、法人一括請求も対象です。

請求の締めや返金、督促から、会計連携までも機能の対象に含めます。

データの範囲では、月間の加入者数、利用明細の件数、過去データを保持する年数を確認します。そのうえで、移行の対象、外部連携の方式、リアルタイム性も決めておきます。

運用では、法令や制度の変更への対応、バックアップ、リリースの承認までを決めておく必要があります。

3層に分けておくと、「開発一式」に含まれない作業を具体的に質問できます。たとえば、旧システムとの請求額の突合、データ移行、性能試験は、別料金になることもあります。また、決済失敗時の再処理や運用担当者向けマニュアルも、別料金かどうかを確認します。

発注形態の選び方

料金管理システムの4つの発注形態と、それぞれの特徴を並べた図解。
共通機能の活用範囲と独自要件の大きさが方式選びの分かれ目です。

発注形態は、標準設定、パッケージ拡張、スクラッチ、ハイブリッドで比べます。

適した方式は、料金ルール、加入者の増加見込み、MNOや決済との連携によって変わります。さらに、会社の規模だけでなく、サービス開始時期と5年後の変更頻度も判断材料になります。

パッケージ・クラウド型が向く場合

まず、共通機能をどこまで活用できるかと、標準仕様との差分を見極めます。

  • 活用範囲:商品カタログ、顧客・契約、課金、請求、決済
  • 運用範囲:料金プラン追加を設定画面で行えるか
  • 確認範囲:5年分の料金、復旧、データ取り出し条件

通信向けパッケージやクラウド型BSSは、共通機能を活用しやすい方式です。ゼロから品質を作り込む範囲が減るため、導入を進めやすくなります。

料金プランを設定画面で追加できれば、小さな改修の依頼や、投入までの時間を減らせます。一方、国内固有の請求書様式、日割り、割引の順位が標準機能に合わない場合は、追加開発が必要になります。

法人一括請求、MNOとのファイル連携、会計の勘定科目も、標準機能との差分になります。

費用面では、ライセンス、利用量課金、バージョンアップ費、データ保存場所を5年分で確認します。障害時の復旧時間と、ベンダーを変える際のデータ取り出し条件も確認したうえで採用します。

スクラッチ・ハイブリッド型と差別化要件の見極め

独自性の高い範囲だけを作り込めるか、運用の人材を確保できるかで判断します。

  • 自由度:独自料金モデルや特殊な利用実績に対応
  • 維持責任:計算、監査ログ、性能、再請求を継続管理
  • 段階導入:共通部分と差別化要件を分けて開発

スクラッチ開発では、複数サービスをまたぐポイントやキャンペーンにも対応できます。

一方で、レーティングエンジン、請求額の再現性、監査ログは、自社で維持し続ける必要があります。性能試験や障害時の再請求も、自社仕様として管理しなければなりません。

料金計算の正しさを検証できる人材を、運用開始後も確保できるかが判断の基準になります。

ハイブリッド方式では、顧客・契約・請求・決済の共通部分をパッケージやクラウドで賄い、独自サービスや社内業務との接続部分だけを追加開発します。

短期で立ち上げる場合は、標準機能を優先し、差別化要件は第2段階に分けます。たとえば、大量加入者への移行やリアルタイム課金を後段に回すと、初期投資とリスクを抑えられます。

要件定義を先行発注する方法

現行システムや連携仕様が整理できていない場合は、本開発を急がず、まず要件定義を先行させます。

  • 現状整理:現状分析、業務フロー、データ項目
  • 要件整理:非機能要件、製品比較、概算見積
  • 再見積:成果物を使い各社の前提をそろえる

現行仕様が整理できていなければ、要件定義だけを先に発注する方法があります。その成果物を使って本開発を再見積もりすれば、各社の前提条件をそろえられます。

IPAのシステム開発委託モデルに関する資料でも、要件定義は業務内容に大きく依存すると整理されています。この整理は、ユーザーが作成し、ベンダーが支援する準委任契約を前提としたものです。

要件が固まらない段階で請負契約にすると、変更管理や責任の範囲で対立が起きやすくなります。そのため、フェーズごとに発注方法を変える設計が有効です。

ポイント

発注形態は、料金ルール、加入者の増加見込み、MNOや決済との連携で選び分けます。サービス開始時期と5年後の変更頻度も含め、会社規模だけで決めないことが大切です。

RFPと要件整理に書く内容

RFPに記載する事業と料金ルール、処理量と連携仕様、SLAとセキュリティ、移行と検収の4項目を示す図解。
同じ前提を各社へ渡すことで、提案や見積もりの差を読み解けます。

RFP(提案依頼書)は、機能一覧だけを並べる文書ではありません。事業の背景、対象範囲、処理量を伝えます。品質条件、納品物、見積の前提と提案期限も書き込みます。料金ルールの例外と外部連携を具体化しておくと、会社ごとの見積の差を説明しやすくなります。

事業と料金ルールの記載内容

RFPの冒頭では、事業形態と現在の課題を明らかにします。

  • 対象事業:音声、データ、SMS、固定回線、IoT、法人回線
  • 事業形態:MNO、MVNO、ISP、CATV、新規立ち上げ、既存刷新
  • 現在の課題:料金追加、締め処理、請求根拠の追跡

料金ルールには、基本料、従量単価、段階課金、無料枠、上限到達後の扱いを書きます。日割りや割引、キャンペーン、家族割、法人一括請求も、対象に含めます。

契約変更から休止・再開、解約までの流れと、返金から再請求までの順番まで記載します。

「料金プラン追加に数週間かかる」のように、現在の課題を業務上の言葉で示します。あわせて、割引Aと割引Bの優先順位や、月途中のプラン変更の例を3〜10件用意します。

同じ条件で各社が試算できるため、見積の差を比べられます。

処理量と連携仕様の示し方

現在の数字だけでなく、3年後の処理量と連携方法もRFPに記載します。

  • 処理量:加入者、明細、請求、同時ログイン、締め時間
  • 連携先:CRM、MNO、決済、会計、顧客ポータル
  • 連携仕様:API、SFTP、CSV、キュー、再送、重複排除

加入者数、日次・月間・ピーク時の明細件数、請求件数を記載します。同時ログイン数、締め処理時間、リアルタイム残高照会の件数も、あわせて必要です。

月間100万明細でも、締め日に集中する場合は、バッチ性能と再実行性能が重要になります。

連携先は、注文管理、本人確認、在庫・SIM、ネットワーク、メディエーションまで洗い出します。決済代行、会計、データ分析、顧客ポータルも対象になります。

送受信側の責任、エラー通知、休日の処理も、連携仕様に含めます。連携先が8システムか2システムかで、機能数が同じでも工数は大きく変わります。

SLA・セキュリティ・移行・検収の先行定義

非機能要件と移行・検収の条件は、画面機能とは別に定義します。

  • 品質条件:稼働、停止、RTO・RPO、応答、監視、災害対策
  • 移行条件:対象年数、欠損・重複・名寄せ、リハーサル回数
  • 検収条件:料金一致、請求突合、再処理、設計書・手順書

非機能要件には、バックアップ頻度、アクセス権限、操作ログ、暗号化を含めます。さらに、脆弱性診断や第三者認証、委託先・再委託先の管理も明記します。

画面の速さだけでなく、締め処理が指定の時刻までに終わるかも確認します。また、請求額を後から再現できることも、料金管理システムの重要な品質条件です。

顧客、契約、回線、料金プランの移行年数を決めます。未収、入金、明細、請求履歴の年数も決めます。欠損・重複・名寄せの扱いと、移行リハーサルの回数も記載します。

検収では、代表的な料金ケースで期待額と実際の計算額が一致するかを確かめます。旧システムと新システムの請求額の突合や、エラー時の再処理も確認します。

運用手順書と設計書の納品も、検収条件に含めます。

ポイント

RFPには、事業の背景や処理量、連携仕様、移行と検収の条件を書きます。料金ルールの例外や連携先を具体化すると、会社ごとの見積の差を説明しやすくなります。

請負と準委任の使い分け

要件の不確実性が高い工程と、完成物を検収する工程は、分けて契約します。

  • 請負契約:成果物と検収条件を明確にする
  • 準委任契約:専門家の作業や支援を依頼する
  • クラウド契約:完成機能を月額やライセンスで利用する

上流工程と開発・テストを同じ契約に詰め込まないことが、リスク管理につながります。

要件定義・調査の準委任と成果の定義

準委任では、作業内容と期待する成果を契約書で具体的に決めます。

  • 依頼業務:現行調査、製品評価、プロジェクト管理、技術助言
  • 成果物:業務フロー、要件定義書、Fit&Gap、移行方針
  • 契約事項:稼働時間、会議体、報告、守秘、セキュリティ

要件定義の支援も依頼対象に含め、調査報告書を成果物として定めます。移行方針や概算見積も成果物に含め、稼働時間と担当者を明記します。

準委任でも、ベンダーは責任を負います。IPAのモデル契約に関する資料では、適切な支援を怠ると債務不履行責任が生じ得ると整理されています。

「相談に乗ってもらう」という形にとどめず、作業範囲と期待成果を定めておきます。

開発・受入の請負と変更管理の設計

完成物と検収条件を明確にできる工程は、請負契約に向きます。

  • 対象工程:設計、設定・開発、テスト、移行、リリース
  • 検討事項:検収、瑕疵対応、保証、遅延、再委託
  • 権利関係:知的財産権とソースコードの利用範囲

機能・非機能要件、設計書、テスト仕様書、検収基準を確認します。そのうえで、瑕疵対応や保証期間、遅延時の扱い、再委託も契約に含めます。

請負契約でも、新しい料金プランや制度変更を無償で追加できるとは限りません。変更要求から影響分析、追加見積、承認、リリースまでの流れを、変更管理票に落とし込みます。料金ルールの変更は、誰が承認するかも決めておきます。

保守契約には、月間の保守時間、障害の優先度、一次切り分けを含めます。あわせて、復旧目標や料金訂正の対応時間も確認します。

個人情報・再委託・障害時責任の契約条項

扱う情報と、どこまでを誰が受け持つかを、発注時点の要件と契約に落とし込みます。

  • 情報管理:個人情報、利用明細、決済情報のアクセス範囲
  • 再委託管理:会社、国、担当範囲、監査、データ消去
  • 責任分界:クラウド、決済、監視、運用BPOの役割

料金管理システムでは、氏名、住所、電話番号、契約内容を扱うため、利用目的、アクセス権限、保存期間、委託先の管理、漏えい時の協力範囲を要件として定めます。

カード情報を保持しない決済方式でも、トークン、ログ、バックアップに含まれる情報は確認が必要です。

再委託先の会社名や国、担当範囲、アクセスできるデータを確認します。監査と報告の方法、契約終了時のデータ消去も、あわせて定めます。

IPAが2026年4月に公開した実践情報でも、サプライチェーンの役割と責任を契約で明確にすることが示されています。クラウド、決済、監視、運用BPOを含めた責任の分担を一枚の図にまとめておくと、誰がどこを受け持つかが見えます。

ポイント

要件定義は準委任で作業と成果を定め、開発は請負で検収条件と変更管理を決めておくと、工程ごとの責任の所在がはっきりします。

料金管理システムの費用相場の目安

請求書作成だけであれば、数百万円から検討できます。加入者、契約、明細をつなぎ、課金、決済、回収、会計まで広げると、費用は大きくなります。

ここで示す金額は、公開統計ではなく、2026年時点の一般的な相場から組み立てた企画段階の推定です。

導入パターン別の初期費用の比較

初期費用は、標準導入、拡張、統合、全面刷新の順に大きくなります。

  • 標準導入:既存BSSや課金パッケージを設定中心で使う
  • 国内拡張:連携、割引、移行、総合テストを加える
  • 事業基盤:加入受付から顧客サポートまで統合する
  • 大規模刷新:キャリア向けにスクラッチ開発する

クラウド型や既存BSSを設定中心で使う場合は、1,000万〜3,000万円程度です。期間は4〜9か月が一つの目安になります。

国内業務、MNO、会計、決済に合わせて拡張する場合は、3,000万〜8,000万円程度です。メディエーション、複雑な割引、移行、総合テストを含めると、9〜18か月程度を想定します。

MVNOの新規事業基盤として統合する場合は、5,000万〜1.5億円程度です。加入受付、開通、在庫、MNO連携、請求、顧客サポートを含み、12〜24か月程度です。

大規模キャリア向けの刷新は、1.5億〜数十億円以上になる可能性があります。期間も、24〜48か月以上に及ぶ可能性があります。

加入者数、月次明細、料金プラン数、連携数、リアルタイム性、可用性によって、金額は変わります。

SIA株式会社の2026年7月の相場では、小規模は100万〜300万円、中規模は500万〜1,000万円です。大規模は1,000万円〜数千万円以上、人月単価は60万〜200万円程度とされています。出典はSIA株式会社「システム開発の費用・相場【2026年版】」(2026年)です。

料金管理では、通信固有のレーティングや外部連携、請求額の突合、24時間運用が加わります。

見積書の初期費用の内訳

見積は、作業量、単価、納品物、前提条件まで分解して確認します。

  • 開発前:企画、要件定義、業務分析、製品ライセンス
  • 構築:環境、設定、追加開発、API・ファイル連携
  • 移行・品質:移行、試験、診断、教育、リリース、引き継ぎ

クラウド環境、データ移行、テスト、性能試験、セキュリティ診断は、それぞれ分けて示してもらいます。教育やリリース、保守の引き継ぎまで含めて、何を納品するのかを確認します。

人月単価と工数は、並べて確認します。たとえば、8人月×60万円なら480万円です。

「課金機能一式」とだけ書かれた見積では、連携本数やデータ形式を質問します。エラー処理、試験ケース、会議回数が含まれるかも確認します。

安い見積ほど、移行、保守、ライセンス、クラウド、休日対応の含まれ方を確認します。

5年TCOによるランニングコストの比較

発注時は初期費用だけでなく、5年TCO(総保有コスト)を比べます。

  • 利用費:クラウド、ライセンス、サブスクリプション、決済手数料
  • 運用費:監視、保守、脆弱性対応、バックアップ、臨時対応
  • 将来費:プラン追加、制度変更、保存、従量課金、移行

料金プラン追加、制度変更、データ保存、障害時の臨時対応も、年ごとに並べて比べます。加入者や明細の従量課金は、現在の値と3年後・5年後で試算します。

パッケージは初期開発を抑えやすい一方で、更新費と製品仕様への依存があります。スクラッチは自由度が高いものの、品質を守る人材と改修費を継続して負担します。

候補会社には、初期費用、月額費用、追加改修の人月単価を、同じ様式で提示してもらいます。

障害対応費と製品終了時の移行費も並べておくと、将来の柔軟性を比べられます。

ポイント

費用相場は、導入パターンと連携・移行の範囲で大きく変わります。見積は人月単価と工数に分け、5年TCOまで並べて比べると、会社ごとの差を読み取りやすくなります。

委託先の選定と見積比較の確認事項

委託先は、価格や知名度よりも、料金業務の理解と運用体制で評価します。

  • 業務力:BSS、課金、請求、MNO、決済、移行の経験
  • 提案力:標準化、追加機能、連携、段階導入の設計
  • 継続力:品質管理、保守体制、担当者の継続性

候補には、通信課金パッケージに強い企業を含めます。MVNOや国内業務に詳しいSI、複数システムを統合できる大手SIも比較します。

自社業務に寄り添う開発会社を候補に混ぜると、提案の違いが見えやすくなります。

公開情報と提案内容に分けた実績の確認

実績は、会社紹介に載る件数だけでなく、担当範囲と運用後の体制まで確認します。

  • 担当範囲:顧客、契約、課金、請求、決済の分担
  • 案件規模:外部連携数、移行対象、加入者規模
  • 継続対応:稼働後の保守と自社運用の範囲

「通信会社に導入した」という会社紹介に加えて、提案内容も確認します。公開事例は参考になりますが、金額や期間をそのまま自社に当てはめることはできません。

日立ソリューションズのBSSsymphony公開事例では、決済業務の作業日数を約50%削減した事例があります。このほか、同じBSSsymphonyの公開事例で、MXモバイリングのMVNO事業や、オプテージの顧客管理システムの事例も紹介されています。

事例からは、標準化した業務、追加機能、自社運用の範囲を読み取ります。出典は日立ソリューションズ「BSSsymphony 事例」です。

見積比較表で並べる前提条件の差分

見積に含まれる範囲をそろえて比べると、表面上の安さだけでは見えない差が分かります。

  • 対象条件:製品、プラン数、例外、連携、移行年数
  • 品質条件:テスト、性能、SLA、保守時間、再委託
  • 費用条件:ライセンス、クラウド、教育、予備費

たとえば、A社は移行費を含み、B社は別見積、C社は請求額の突合をオプションにすることがあります。

各社には、同じ代表ケースを使った料金計算のデモを依頼します。あわせてエラー時の再処理のデモも頼み、画面の見栄え以外の中身を確認します。

月途中の変更、割引の併用、無料期間の終了、決済失敗のケースを確認します。返金、請求取消、再請求、通信明細の遅延到着も試します。

これらのケースを使うと、業務理解と製品の柔軟性を評価できます。

移行と段階リリースの計画

移行では、データの正確さと、切替後の復旧方法を提案に含めてもらいます。

  • 移行対象:顧客、契約、請求履歴、未収、決済状態
  • 検証方法:変換、請求計算、件数、金額、欠損、重複
  • 切替計画:切り戻し条件と旧システム参照期間

古い料金プランの扱い、利用明細の保存、旧新システムの請求額の突合を計画します。本番の切り替え前には、データ変換と請求計算を複数回リハーサルします。

件数、金額、欠損、重複、エラーを確認し、切り戻しの条件を明記します。切替後に旧システムを参照できる期間も、提案に含めます。

Ericssonは2025年、Indosat Ooredoo HutchisonのBSS刷新事例を公開しました。初期段階で800万人、次の段階で8,300万人の加入者を移行したと説明しています。さらに、初回成功注文から開通までを70%短縮し、市場投入時間を60%削減したとされています。

出典はEricsson「Indosat Ooredoo Hutchison transforms IT with Ericsson」(2025年)です。

日本の案件では数字をそのまま転用せず、段階移行、統合カタログ、責任を一か所にまとめる進め方を参考にします。

ポイント

委託先は、料金業務の理解と運用体制で評価します。見積は前提条件と範囲をそろえ、同じ代表ケースの料金計算デモを依頼して比べます。

よくある質問

料金管理システムの発注では、費用だけでなく、責任範囲と検証方法も決めておく必要があります。運用開始後に誰が料金プランを変更するかも、発注前に確認します。

料金管理システムは小規模事業者でも外注できますか?

外注できます。最初は、事業開始に必要な最小限の範囲を決めておきます。

  • 初期範囲:請求書、顧客・契約、決済、会計連携
  • 将来条件:加入者数、料金プラン数、月間明細件数

既存のパッケージやクラウドを設定中心で導入する方法を検討します。また、将来条件をRFPに書いておけば、過剰な構成を避けながら、拡張性を評価できます。

料金管理システムの見積が会社によって大きく違うのはなぜですか?

対象範囲や料金ルールの例外、移行量などの前提が、会社ごとに異なるためです。

  • 構成差:パッケージ、連携本数、性能・可用性
  • 運用差:テスト、保守、ライセンス、移行データ

同じRFPと代表的な料金ケースを渡し、見積を前提条件から分解します。含むもの、含まないもの、追加単価、5年TCOまで比べると、価格差を説明できるようになります。

パッケージを導入すれば追加開発は不要ですか?

追加開発が要らないとは限りません。標準仕様との差分を、Fit&Gapで確認します。

  • 差分候補:請求書、会計、決済、本人確認、MNO連携
  • 料金条件:法人一括請求、日割り、割引の併用

標準仕様に合わない場合は、設定変更、周辺連携、追加開発が必要になります。追加機能がバージョンアップや製品変更でどう扱われるかまで、確認します。

外注先にセキュリティ対策をどこまで求めればよいですか?

個人情報、利用明細、決済情報の扱いは、契約と受入試験に落とし込みます。

  • 技術対策:暗号化、権限管理、操作ログ、脆弱性診断
  • 委託管理:バックアップ、報告、再委託、返却・消去

IPAの実践資料は、委託範囲の明確化と第三者検証による対策を扱っています。資料はサプライチェーン連携まで扱っており、チェックシートの確認だけで済ませず契約で役割を定めることが大切です。

出典はIPA「サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集」(最終更新2025年12月)です。

まとめ

発注前に決める請求ライフサイクルと方式

料金プランから回収・会計までを、請求ライフサイクルとして定義します。

  • 範囲:機能・データ・運用の3層
  • 方式:パッケージ、クラウド、スクラッチ、ハイブリッド

料金ルールの独自性、連携数、処理量、開始時期、5年TCOで方式を比較します。

前提条件をそろえた委託先と見積の比較

RFPには、料金の例外ケース、加入者数、明細件数、外部連携、移行対象を記載します。

  • 要件:SLA、セキュリティ、成果物、検収条件
  • 契約:要件定義は準委任、固まった開発は請負
  • 比較:前提、範囲、追加単価、5年TCO

フェーズに合わせて契約を組み合わせると、責任の分かれ目を整理しやすくなります。候補会社には、代表的な料金ケースとエラー時の再処理のデモを依頼し、中身を確かめます。

公開事例を自社の要件にそのまま当てはめないことで、請求ミスや追加費用を抑えます。ここまで整理してから発注すれば、事業の変化に追従しやすい料金管理システムを構築できます。

▼全体ガイドの記事
・料金管理システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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