newmo 技術ブログ

技術で地域をカラフルに

タクシーの給与計算のDX

newmoでsoftware engineerとして働いているtazoeと言います。この記事では、最近(2025年12月現在)取り組んでいるタクシー会社のDXにおける給与計算のチームのドメインや背景などについてご紹介します。

給与計算のドメイン

私達のチームでは、給与計算のドメインを扱っています。タクシー会社は、乗務員さんが安心して、そしてできるだけ効率よく働ける環境を整えることで、会社全体の収益を高めていく、という特徴を持つ業態です。そのため、給与計算の関連ドメインの重要性は高く、ロジックも複雑になりがちです。以下では、そのように重要で複雑な一方でミスの許されないドメインに対して私達がどのように取り組んでいるかをご紹介させてください。

給与計算は、具体的には以下のようなサブドメインから構成されます。

  • 勤怠
    • 乗務員さんの出勤時刻、退勤時刻、休憩時間などを管理します
  • 日報
    • 乗務員さんの出庫時刻、入庫時刻、運行履歴・売上情報などを管理します
  • 未収管理
    • 乗務員さんの未収の集計と消込業務などを行います
  • 給与計算
    • 売上情報と勤怠情報を集計し、基本給や歩合給、残業手当などを計算します
    • また、乗務員さんの教育に伴う手当などを計算します

勤怠は、タクシー会社に限らず管理システムが広く利用されていてイメージしやすいと思います。ここでは、タクシー固有の要素の多い日報・未収管理・給与計算について紹介します。

日報

日報とは、法律上管理が義務付けられている記録で、勤務時間・走行距離・実車/空車・休憩・売上金額などを毎日まとめる必要があります。従来はこれを紙で手書きして記入していたのですが、最近では車載のタクシーメーターが自動で運行情報を記録し、出力する自動日報が一般的です。

私達のシステムでは、この自動日報や配車アプリの履歴などを収集し、日報としてデータをまとめて、後の未収管理や給与計算で利用可能なようにデータを整備しています。

未収管理

タクシーの清算時にクレジットカードを利用した場合、タクシー会社には後日クレジットカード経由でお金が支払われることになります。未収(=売掛金)とは、このように決済時は現金の受け渡しがないが後日支払われる仕組み全般のことです。元々はタクシー業界では未収=タクシーチケットでしたが、近年ではクレジットカードや各種交通IC、アプリ経由での支払いなどが増えたこともあり売上における割合が増えてきています。 未収管理では、タクシーメーター上に記録された未収の合計と後日実際に支払われる金額が一致している必要があり、そのために決済履歴や各種チケットやレシート類などを集計し、金額を検証する作業を行なっています。私達のシステムでは、これらのデータを自動で集計したり、フィルタリングしたりするオペレーションを整理して、人が必ずしも目視で全てのデータを確認しなくて済むようにするような機能を開発しています。

また、未収管理の過程でメーター操作の誤りなどが見つかることも多くあり、給与計算に向けた売上の確定処理的な意味合いもあります。

給与計算

タクシー会社は多くの会社が歩合制を採用しており、売上高に応じて乗務員さんの給与が変動します。シンプルに言えば、売上に一定の比率をかけて歩合給を計算するだけ、であれば実装は簡単ですが、実際には基本給などの固定給や、アプリ利用時の手当や控除、残業代の計算や、休日出勤による割増の計算、有給管理、各種教育の手当の支給などかなり多くの要素が各社存在します。

エンジニアリング視点での各社対応と共通機能の整理

newmoにはグループとして複数のタクシー会社があり、エンジニア視点で見れば、このような複雑なドメインで、各社固有のロジックを実装するのは開発コストが高く、できれば避けたいです。一方で、現場の業務や導入している決済手段、給与の規定などは簡単に統一できるものではないため、全ての実装を共通化することはできません。

そこで、現時点では、以下のような割り切りをしています。

  • 勤怠・日報では各社固有の対応はしない。勤怠区分など、各社毎に異なる部分はユーザー定義マスターとして各社ごとに設定を分けられるようにして対応する
  • 未収管理・給与計算は各社固有のロジックを実装する。データだけじゃなくてロジックそのものが各社独自なので、割り切って各社ごとに対応を行う

現時点では、最近オープンした夢洲交通へ導入しており、今は他のグループ会社への導入を進めているという状態です。

なぜ取り組んでいるのか?

ここまで話を読むと、結構大変そう・・・、と思った方が多いのではないでしょうか?実際給与という重要なドメインを扱っているため、責任も重く、大変な部分が多いのですが、その分会社をよくできる余地も大きいと考えています。以下は筆者がパッと書いた例ですが、意図を持って開発しています。

  • 勤怠管理の仕組みを一貫して作ることで、乗務員さんが無理なく働ける体制づくりを支え、結果として欠勤による稼働率の低下も防ぎやすくなるような仕組みを提案できないか?
  • 日報データを詳細に解析してより売上が伸びやすいようにデータ分析できないか?
  • 未収管理や給与管理の業務を統一して業務を楽にできないか?

エンジニア視点でも業界固有のドメインの理解や現場感が求められる点、事業自体への改善などを提案したり、考えたりする機会が多い点が面白い点ではないかと思います。

(ここで宣伝になりますが・・・) PdMの方をnewmoでは絶賛募集中です!ご興味のある方は以下のリンクから応募ください!

herp.careers