運賃請求管理システム開発の完全ガイド

運賃請求管理システムは、受注から入金・支払までの運賃データを一つの流れで管理するシステムです。

導入は、業務の整理、機能と導入形態の選定、検証、本番展開の順に進めると、請求根拠を確認できる運用につながります。

▼関連記事一覧
・運賃請求管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・運賃請求管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・運賃請求管理システム開発の見積相場や費用/コスト/値段について
・運賃請求管理システム開発の発注/外注/依頼/委託方法について

運賃請求管理システムの概要

請求書を整えるだけのツールとは、役割が異なります。運賃請求管理システムは、受注から入金までを一つの流れで管理します。

中心となる役割は、運行実績を請求金額へ正しく変換し、計算根拠と承認履歴を残すことです。さらに、紙や表計算で分断されたデータをつなぐと、請求漏れや二重請求、実績と請求額の不一致を見つけやすくなります。

請求書発行ツールや会計システムとの違い

請求書発行ツールは、取引先、品目、金額、税率を入力して帳票を発行します。一方で、運賃請求管理システムは、貨物や出荷地、納品先、車種、重量、距離から明細を作ります。運行日や待機時間、荷役なども、その材料になります。

会計システムが売上や債権を処理するのに対し、運賃請求管理システムは、売上が確定する前の現場データを整えます。ただし、帳票の変更だけなら、請求書発行ツールで足りる場合があります。

特に、荷主別の運賃表や複数の割増条件、傭車支払、配車実績との突合まで扱う場合は、運送業務の前工程とつながる仕組みが必要です。

導入が向く事業者

自社車両の運送会社に加え、利用運送、3PL、倉庫と配送を一体管理する事業者、協力会社や傭車を多く使う企業にも適します。荷主ごとに料金条件が異なる場合、手作業の負担やミスが増えやすくなります。

  • 運賃条件:荷主ごとに使い分ける距離・個数単価、車建、最低保証
  • 追加料金:時間帯割増、待機料、荷役料、再配達料
  • 複数担当者:月末や締め日前の日報と請求書の照合

経理や配車担当者、運行管理者が同じ案件番号を見られると、確認の電話や再入力を減らせます。ドライバーや協力会社も加わると、同じ番号を使う範囲が広がります。

運賃請求管理システムに必要な機能とデータ連携

共通キーを中心に案件番号、荷主、運行日、車両、納品先を結んだ図です。
共通キーが各データを同じ案件へ結びつけます。

必要な機能は、画面の数よりも、受注から入金・支払までデータが途切れず流れるかで判断します。初期導入で全部を揃えなくても、将来の連携に備えて共通キーを設計しておく必要があります。

共通キーは、案件番号を軸に同じ案件のデータをそろえる仕組みです。荷主、運行日、車両を同じ番号に結びつけ、乗務員と納品先もそろえます。

受注・配車・運行実績を一つにつなぐ機能

受注では、荷主、出荷地、納品先を登録し、品目と数量、重量も入力します。車格と希望時間、温度帯も入力します。さらに、納品条件も入力します。受注は配車計画と運行指示へ渡し、実績データを取り込みます。

実績の取得元は、ドライバーのスマートフォンやGPS、デジタコです。ETCや納品完了報告も取得元になります。こうした情報を使うと、予定と実績の差を追跡できます。

通信途絶時の再送、同一データの重複取込、遅れて届く納品情報への対応も、要件に含めます。そのうえで、計算前の実績と適用運賃表を確認できると、請求額の説明に役立ちます。加えて、変更者と承認者、確定時刻も確認できるようにします。

運賃マスタ・例外料金・請求処理

運賃マスタは、荷主別、区間別、車種別の条件を組み合わせて管理します。重量別、距離別、個数別の条件も使います。通常運賃に加えて追加料金を設定すると、手修正を減らせます。

  • 割増・実費:深夜・休日割増、高速代、燃料サーチャージ
  • 作業・追加運賃:待機料、荷役料、集荷料、中継料、再配達料、温度帯料金

例外処理を自動化しすぎると、現場で使われない場合があります。そこで、自動計算、担当者入力、上長承認の対象を分け、変更理由と証憑を残します。

確定後の訂正では、元の明細を消さずに、取消、再発行、差額請求として追跡できる状態にします。

傭車支払・会計連携・採算分析

協力会社や傭車への支払明細も作る場合は、同じ運行実績から売上請求と支払を計算できる仕組みが必要です。売上と傭車費を、便別、車両別、案件別に集計すると、利益が残らない便を見つけやすくなります。

会計・販売管理との連携では、勘定科目や部門コードを確認します。売上、未収、消費税に加えて、傭車費、燃料費、高速代も確認の対象になります。

CSV、API、EDIのどれを使うかは、請求件数や締め頻度で決めます。エラー時の再処理や既存システムの仕様も、判断材料にします。連携エラーを画面で追えるようにし、毎回手作業で探す設計は避けます。

ポイント

画面の多さより、案件番号でデータがつながり続けるかが、導入する機能の範囲を決める目安になります。全部を一度に揃えなくても、共通キーの設計だけは先に固めておくと、後から連携を足しやすくなります。

運賃請求管理システムの種類

SaaS・パッケージ型、クラウド設定・セミオーダー型、スクラッチ開発の特徴を3枚のパネルで示しています。
標準機能から個別設計へ、調整できる範囲が広がります。

請求業務を標準化できる企業なら、SaaSが候補になります。既存連携や荷主別帳票が多い企業は、クラウド設定・拡張が適します。独自運賃や業務が競争力に直結する企業は、個別開発が候補です。

車両台数だけでなく、例外処理や連携数を見ます。拠点数や法改正への追随責任も見ます。

SaaS・パッケージ型の特徴

SaaSやパッケージ型は、初期投資と導入期間を抑えやすい形式です。法改正やセキュリティ更新を、自社だけで担わずに済みます。

製品が受注から支払までの流れを想定していれば、短期間で運用を始められます。

独自タリフや特殊な締め日が標準機能にない場合、追加費用や運用変更が発生します。荷主別帳票やデジタコ、会計との連携も、標準機能になければ費用や運用の変更が生じます。デモでは、実際の請求明細と例外料金も確認します。

クラウド設定・セミオーダー型の特徴

標準機能を土台に、運賃マスタや帳票を自社向けに調整する方法です。権限、承認、データ連携も、自社向けに調整します。

スクラッチより短い期間で、SaaSより柔軟に調整できます。複数拠点や荷主があり、業務の基本形を変えたくない企業が候補になります。

設定変更と個別開発の境界は曖昧になりやすいため、見積書では、標準設定と追加開発、外部連携を分けます。移行や保守、将来変更も、区切って見ます。仕様変更時の単価や納期も確認します。

スクラッチ開発の特徴

スクラッチ開発では、独自の運賃計算や共同配送に合わせて設計できます。傭車精算や拠点別権限、既存基幹との統合も、業務に合わせて組めます。業務の優位性を残したい場合に有効です。

要件定義から保守まで、担う範囲と責任が大きくなります。開発後も、契約変更や税制対応に継続して対応します。連携先の仕様変更や端末更新も、その範囲に入ります。

最初から全社を対象にせず、1拠点・1荷主・1締めサイクルで検証する進め方が安全です。

ポイント

請求業務を標準化できるならSaaS、既存連携や荷主別帳票が多いならクラウド設定・拡張、独自運賃が競争力に直結するなら個別開発を候補にします。判断では車両台数だけでなく、例外処理や連携数も見ます。

運賃請求管理システム開発の進め方

現状業務の棚卸しから要件明文化、PoC、データ移行、本番展開へ進む5段階の図です。
例外を確かめてから本番運用へ進む構成です。

まず、画面より先に、請求額が確定するまでの業務ルールとデータの流れを固めます。現場の例外を拾い出し、必須のMUSTと導入後のWANTを分けたうえで、段階導入の範囲を決めます。その後に方式を選びます。

▶ 詳細はこちら:運賃請求管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 現状業務とデータの棚卸し

受注から採算分析まで、工程を一つずつ分けて書き出します。工程は、受注、配車、運行、納品の順に並びます。その後に、実績確認と運賃計算、請求、入金・支払、採算分析が続きます。各工程で、担当者や使用する帳票・画面、確定時期、確定データを記録します。

対象は、電話やFAX、紙の日報、Excel、既存システム、メール添付です。通常のケースより例外を優先して拾い、特に複数車両での運送や複数納品先、待機料を確認します。異なる荷主と請求先、傭車への別単価も確認します。

例外を把握しないまま要件を固定すると、本番後も手作業が残ります。

2. 運賃ルールと要件の明文化

運賃ルールは、荷主、車両、区間の条件を、マスタと計算ルールにします。重量、個数、距離、時間帯、割増を、計算の条件として含めます。

付帯作業、締め日、回収サイト、税区分も、同じマスタに入れます。適用期間と優先順位、変更の申請者と承認者、過去明細への影響も決めます。

必須のMUST、導入後に追加したいWANT、現段階で対象外の項目に分けます。AI配車や高度な予測分析まで最初から含めると、請求の正確性という目的がぼやけます。まず請求前の実績突合と運賃計算を安定させ、効果を確認してから拡張します。

3. 1拠点・1荷主でのPoC

本開発の前に、1拠点、1荷主、1回の締めサイクルを対象にして検証します。検証では、実際の受注や日報、納品証跡、請求明細を使います。導入前と同じ指標を記録し、効果を数字で比べます。

  • 作業・精度:請求締め時間、手入力回数、実績不一致件数
  • 請求品質:差戻し率、請求漏れ、訂正件数

きれいなサンプルデータだけでなく、欠損のある日報も使ってテストします。複数車両や待機料、再配達も検証します。遅着情報と確定後の訂正も、テストに加えます。

現場担当者が無理なく入力できるか、経理担当者が計算根拠を説明できるかを同時に見ます。

4. データ移行と並行運用の設計

移行と切替では、対象データと並行運用の条件を整理します。

  • 移行対象:顧客、荷主、請求先、運賃表、車両、乗務員、協力会社、未収残高、過去請求書
  • 対象期間:全履歴ではなく、検索・監査・入金確認に必要な期間
  • 移行前の整理:表記ゆれ、重複荷主、古い運賃表の終了日の整理
  • 並行運用:一定期間、紙や既存の表計算と併用する方法

国土交通省の物流デジタル化資料では、請求確認の依頼から確定、請求書の生成までを、デジタルツール上で完結させた事例があります(出典: 国土交通省「中小物流事業者における物流業務のデジタル化実証」、2025年)。

並行運用では、終了日と判定基準を先に定めます。そうしないと、二重入力が長引くおそれがあります。

5. 本番展開と現場定着

本番展開では、利用準備と稼働後の管理方法を整えます。

  • 操作説明:管理者向けの説明と、ドライバーが短時間で完了報告や待機時間を入力できる画面
  • 入力環境:入力項目の多さと、通信圏外での一時保存の可否
  • 端末・窓口:紛失時の利用停止方法と問い合わせ先の明確化
  • 週次確認:請求差戻し、入力漏れ、連携エラー、手修正、問い合わせの確認
  • 変更管理:運賃マスタの申請・承認制と変更者・日時の記録、現場の声の画面改善への反映(無断変更の防止が目的)

ポイント

まず例外を洗い出せているかが、進め方の判断の目安になります。最初は1拠点・1荷主で検証し、効果を確かめてから範囲を広げると、本番後の手作業を減らしやすくなります。

運賃請求管理システムの費用相場とコストの内訳

費用は、請求のみか、配車・運行・会計まで統合するかで変わります。たとえば、公開料金のあるクラウド例では、初期費用0円、月額1万1,000円〜5万2,800円(税込)の複数プランがあります。

複数拠点の設定や移行、外部連携を加えると、別途の導入費が発生します。教育を加える場合も、別途の費用がかかります。ここに示す金額は、2026年時点の公開料金と業務システム開発の見積傾向による目安です。

金額は、車両台数や請求件数、拠点数で変わります。運賃計算の複雑さや連携方式、サポート範囲でも変動するため、予算策定の初期レンジとして使います。

▶ 詳細はこちら:運賃請求管理システム開発の見積相場や費用/コスト/値段について

クラウド導入の費用目安

クラウド料金は初期・月額・追加設定の範囲を分けて確認します。

  • 費用目安:初期0〜150万円、月額1万〜30万円超。標準機能のみなら初期費用が小さい場合もあります。
  • 初期設定:荷主・請求先登録、運賃マスタ、帳票調整、研修、過去データ移行で費用が増えます。
  • 公開料金例:初期設定費5万円、月額1万2,000円からの運輸向けサービスがあります。
  • 追加料金:車両・アカウント、帳票変更、サポート、連携ごとの料金

料金例は2026年7月に公開ページで確認したものです(出典: 運輸業向けクラウドサービスの公開料金ページ、2026年7月確認)。

連携・移行・教育にかかる費用

連携・移行・教育は、費用が変わる要因を分けて見積もります。

  • 外部連携:会計、販売管理、デジタコ、GPS、ETC、電子請求、EDIは追加300万〜1,500万円程度の場合があります。
  • データ移行:移行費は件数だけでなくデータ品質でも変わります。
  • 利用者教育:集合研修、マニュアル、動画、拠点別の伴走、問い合わせ対応期間

連携費は、会社や案件によって変わります。この金額は類似システムからの推定で、内訳にはAPI・CSVの仕様調整、マスタ変換、移行のほか、エラー監視とテストも含まれます。

表記ゆれや区間コードの不統一を整える場合は、移行前のクレンジング費が発生します。終了した運賃表や欠損のある日報を整えるときも、移行前のクレンジング費がかかります。

個別開発・スクラッチ開発の費用目安

運賃計算や複数拠点、傭車精算を含む個別開発は、3,000万〜8,000万円程度、9〜18か月が推定レンジです。会計・車両システムとの統合や権限・監査、バックアップも含んだ数字です。

全社基幹刷新まで広げる場合は、8,000万〜3億円超、12〜24か月以上となる可能性があります。金額は画面数より業務ルールと連携の複雑さに左右されます。

要件定義と設計、開発、テスト、移行を工程ごとに分けて見積もります。教育や保守、クラウド、監視、バックアップ、法改正対応も、見積もりに含めます。契約前には、請負・準委任の区分や仕様変更、納品物、ソースコードとデータの所有権も確認します。

導入後のランニングコスト

月額利用料のほかにも、継続してかかる費用があります。ユーザーや車両の追加、帳票変更、API、電子請求や郵送代行などです。SMSやストレージ、サポートも、継続してかかります。さらに、保守と脆弱性対応、バックアップ、教育費も、継続してかかります。

年間費用を比べ、3年分の総保有コストで判断します。費用を抑えるには、機能より先に対象拠点と連携範囲を絞ります。

実績突合と運賃計算を先行し、採算分析や高度な配車最適化を後から加える方法があります。現場で使われず毎月の手修正が残れば、低価格でも期待した効果は得られません。

ポイント

導入範囲の違いが費用の差に表れるため、候補を比べるときは、初期費用だけでなく、連携や移行、教育を含めた年間費用と3年分の総保有コストで判断します。

運賃請求管理システムの開発会社・ベンダーの選び方

機能数や導入社数だけでなく、自社の運賃計算と現場運用を再現できるかを確認します。得意な範囲は、標準機能や業務システム連携、個別開発、移行などで事業者ごとに異なります。

運賃計算と例外処理の適合性

匿名化した実データを使い、基本運賃や重量・距離・個数の条件で計算してもらいます。待機料や荷役、再配達も、同じデータで計算対象にします。さらに、燃料・高速代、複数車両、締め日違いも含めます。

計算根拠の明細表示、手修正への承認、確定後の訂正履歴も確認します。「対応できます」だけでなく、標準機能、設定、追加開発、運用回避に分けて回答を求めます。

荷主追加や運賃改定のたびに個別開発が必要となる設計でないかも確認します。

連携・移行・サポートの体制

連携実績を、デジタコやGPS、会計で確認します。販売管理、電子請求、EDIとの連携実績も見ます。データ項目の対応表、通信エラー時の再送、重複排除を確認します。

仕様変更の責任や、連携停止時の代替手順も確認します。移行では、移す項目と稼働後に登録する項目を分けて明示します。問い合わせ窓口、対応時間、障害通知、復旧目標も選定項目です。

バックアップ、データ返却、解約時の出力形式も、選定の項目です。クラウドは、保存場所や暗号化、アクセス権限、操作ログ、脆弱性対応、委託先管理をRFPに記載します。法令対応を任せきりにせず、自社の確認担当者も決めます。

見積と契約条件の比較

見積、契約、納品物を分けて、費用と責任の範囲を比べます。

  • 見積内訳:初期・月額、開発、移行、連携、教育、保守、クラウド、通信、帳票、郵送・電子請求ごとの金額
  • 追加条件:対象外作業、追加費用の条件、納期遅延時の扱い、検収基準
  • 契約条件:データ所有権・返却、再委託、秘密保持、障害責任、サービスレベル
  • 変更・終了:仕様変更、法令対応、保守終了、解約条件
  • 納品物:個別開発の場合の要件定義書、画面・API仕様、テスト結果、運用手順書

▶ 詳細はこちら:運賃請求管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら:運賃請求管理システム開発の発注/外注/依頼/委託方法について

ポイント

匿名化した実データで計算を試し、連携や移行の責任範囲と見積の内訳を比べて選びます。「対応できます」という回答は、標準機能か追加開発かまで確かめてから受け取ります。

インボイス・電子帳簿保存法とセキュリティの確認事項

請求管理システムは、住所や取引条件、単価に加えて、運行位置や入金情報も扱います。そのため、誰がいつデータを確定し、証憑とどう関連づけ、どの期間保存するかまで設計する必要があります。

適格請求書の記載と保存

請求書の記載と電子データの扱いは、項目ごとに確かめます。

  • 適格請求書:登録番号、取引日・内容、税率別金額と税率、消費税額、相手先名の記載(帳票または関連納品書)
  • 電子取引:検索等の要件、原本との関連、訂正履歴、権限。PDF印刷だけでは足りない場合もある

仕入税額控除に必要な請求書等は、原則、課税期間末日の翌日から2か月後を経過した日から7年間保存すると国税庁が示しています(出典: 国税庁「適格請求書等の記載事項」、2025年4月1日現在)。

売り手か買い手か、課税事業者かで処理が変わるため、税務担当者と確認します。電子取引データについては、検索や保存、改ざん防止、ダウンロード要件も対象です。

権限・ログ・バックアップ

権限は、拠点や役割、担当業務に加えて荷主の単位でも、最小限に設定します。運賃変更、請求確定、入金消込の担当は、それぞれ分けます。

  • 操作履歴:マスタ変更、修正、再発行、出力、ログインの記録
  • アクセス保護:多要素認証、暗号化、APIキー管理、紛失端末の停止
  • バックアップ:取得だけでなく、復旧できることの定期テスト
  • 障害時対応:紙・Excelへの切替、通信復旧後の再入力、二重請求防止、問い合わせ先、復旧目標時間

これらは、重要データを扱う業務システムの実務上の確認事項です。一律の法定方式ではありません。

導入効果を測るKPIとROIの考え方

導入効果は、締め作業や請求精度の変化で測ります。債権回収や便別採算、現場負担の変化も、測る対象になります。導入前1〜3か月の実績を記録し、導入後と同じ条件で比べます。

見るべきKPI

効果測定では、請求業務と経営の指標を組み合わせます。

  • 請求業務:締め時間、明細ごとの入力回数、実績不一致、差戻し率、請求漏れ
  • 処理状況:訂正・再発行、入金消込時間、未収残高、傭車費集計時間
  • 経営指標:荷主別売上、便別粗利、車両別稼働、待機料請求率、赤字便の割合

国土交通省の物流DX資料は、請求確認や請求書生成をデジタルで完結させることを、効率化の要点として示しています(出典: 国土交通省「中小物流事業者における物流業務のデジタル化」、2025年)。

作業時間に加えて、確認の往復や請求根拠を探す時間も測ると、効果を把握しやすくなります。

ROIの試算方法

ROIは、削減できる人件費や郵送費、再発行・請求漏れの損失を合計します。回収の早期化や赤字便の発見による利益改善も加え、初期費用と一定期間の運用費と比べます。

月末作業が担当者4人で各2日かかるなら、導入後に減る時間に時給を掛けて試算します。

削減時間をすべて人員削減の効果にはせず、荷主対応や債権管理、採算改善へ充てられるかを定めます。運行品質への充当も、あわせて定義しておきます。説明可能性、監査対応、属人化解消も投資判断に含めます。

よくある質問

導入前の疑問に、費用やExcelとの併用、個別開発、法令対応の観点から答えます。自社の業務量や運賃ルールに照らして、要件整理に役立ててください。

小規模な運送会社でも導入できますか?

導入できます。請求・支払、運賃マスタ、日報実績の突合など、効果が出やすい業務に絞る方法があります。また、車両台数や利用者数に応じたクラウドから始める方法もあります。

初期費用や月額、初期設定を確認します。サポートやデータ出力の条件、荷主追加後の料金も、見積もりに含めます。

Excelを残したまま導入できますか?

段階的に残せますが、どのデータを正とするかは、事前に決めておきます。配車表をCSVで取り込み、請求書と支払明細だけをシステム化する方法もあります。

案件をExcelとシステムの両方に二重入力すると、更新漏れや請求額の不一致が起きます。そこで、対象業務とExcelの終了時期を定めて移行します。

運賃計算が複雑でもパッケージで対応できますか?

対応できる場合があります。標準機能、設定、追加開発、手入力運用を分け、実データでデモを依頼します。

デモでは、荷主別タリフや重量・距離・個数、最低運賃を含めます。待機料や付帯作業、再配達、傭車支払も含めます。計算結果だけでなく、適用ルールと修正履歴も確認します。

インボイスや電子帳簿保存法に対応できますか?

機能があっても、自社の取引と保存ルールに合うかを確かめます。適格請求書の記載や請求書・納品書の保存を、税務担当者と確認します。電子データの検索性や訂正・削除履歴、権限、出力方法も確認します。

制度改正時の更新範囲と、利用者側で設定変更が必要な項目も契約前に確認します。

まとめ

このシステムは、受注、配車、運行、納品をつなぎます。さらに、実績突合、運賃計算、請求、入金・支払、採算分析までを一つの流れにします。導入の成否は、自社の運賃表と例外処理を表現できるか、現場が入力し、経理が計算根拠を説明できるかで決まります。

導入前に押さえる三つのポイント

現行業務を受注から入金・支払まで分け、荷主別運賃や待機料、荷役、傭車などの例外を明文化します。次に、導入形態を総額で比べ、PoCで効果を測ります。

SaaS、クラウド設定・セミオーダー、スクラッチは、初期費用だけでなく、連携や移行、保守まで比べます。法令対応や出口条件も、比較の対象です。

PoCは1拠点・1荷主・1締めサイクルで行い、導入前後の締め時間や手修正を測ります。差戻しや請求漏れ、便別採算も、導入前後で測定します。

次に行うべきこと

直近の請求サイクルから、日報、配車表、納品証跡を集めます。運賃表、請求書、傭車支払明細も集め、転記と確認箇所を洗い出します。

必須機能や連携対象、移行範囲を、要件メモにまとめます。KPIと予算上限も書き加えて、複数候補へ同じ条件で相談します。請求を正確で説明可能な業務に変えるため、段階的な導入計画を作ります。

▼関連記事一覧
・運賃請求管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・運賃請求管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・運賃請求管理システム開発の見積相場や費用/コスト/値段について
・運賃請求管理システム開発の発注/外注/依頼/委託方法について

 

会社紹介

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

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

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

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

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

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