LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）として業務システムの開発・保守を受託

車検期限・見積・整備記録簿——手作業の整備業務が抱える課題

整備工場やディーラーの現場では、入庫した車両の情報、顧客とのやり取り、見積や請求、作業の指示、そして点検整備記録簿や車検（継続検査）の期限といった多くの情報を、日々並行して扱います。ところが、その管理は表計算ソフトの台帳や紙の作業伝票、ベテラン担当者の記憶に頼りがちです。入庫台数が増えるほど情報が分散し、抜け漏れが起こりやすくなります。とりわけ整備業務は道路運送車両法に基づく点検整備や検査に関わる領域であり、記録の不備がそのまま業務品質の低下につながりかねません。

手作業の管理で起こりやすい課題は、大きく3つに整理できます。1つ目は、顧客ごとの車検満了日や定期点検の時期を台帳で追いきれず、案内や入庫の機会を逃してしまうことです。2つ目は、見積・作業指示・請求が紙や別々のファイルに散らばり、どの車両にどの作業を行い、いくら請求したのかを後からたどりにくいという課題があります。3つ目が、点検整備記録簿の作成と保存です。整備の内容をその都度手で書き写し、法定の保存期間まで管理する運用では、記載の抜けや保存の不備が生じやすくなります。

これらは単なる事務作業の煩雑さにとどまりません。国土交通省は、定期点検整備を行った際は点検整備記録簿に記載し、一定期間保存することを求めています^*1。記録簿の保存期間は、3か月・6か月点検の対象車で1年、1年点検の対象車で2年とされています^*1。つまり整備業務の管理は、日々の効率だけでなく、点検・検査に関わる記録を漏れなく残せる仕組みが問われる領域だといえるでしょう。入庫が少ないうちは属人的な運用でしのげても、台数や顧客が増えるほど、工場全体で一元的に把握する必要性が高まります。

自動車整備システムとは——整備工場の車検・見積・整備記録を束ねる仕組み

自動車整備システムとは、整備工場やディーラーの整備業務に必要な情報を一つのデータベースにまとめて扱うソフトウェアを指します。具体的には、(1)車両情報と顧客情報、入庫の受付、(2)見積・請求と作業指示、(3)点検整備記録簿と車検（継続検査）・定期点検の期限管理、(4)部品在庫やOBD検査・電子車検証への対応、といった機能を束ねる考え方です。紙や表計算ソフトに分散していた情報を集約し、車検満了日が近づくと担当者へ知らせる、といった運用を支えます。

ここで押さえておきたいのが、整備業務が道路運送車両法に基づく点検整備や検査と切り離せない点です。国土交通省は、車検（自動車の検査）について、検査時点で保安基準に適合しているかを国が必要最小限確認するものであり、検査証の有効期間内の状態を保証するものではないと説明しています^*2。検査に合格したことをもって点検整備を省略できるものではない、とも明記されています^*2。整備工場は、車検とは別に日常点検・定期点検を担い、その結果を点検整備記録簿として残す役割を担っているわけです。

自家用乗用車の場合、日常点検は走行距離や運行状態などから判断した適切な時期に行い、定期点検は1年ごと（29項目）と2年ごと（60項目）に実施することとされています^*1。バスやトラックなどの事業用自動車では、1日1回運行前の日常点検に加え、3か月ごと（51項目）と12か月ごと（101項目）の定期点検が求められます^*1。車種によって点検の区分や頻度が異なるため、車両ごとに区分を持ち、期限を管理できる仕組みが要になります。自動車整備システムが注目される背景には、こうした点検・検査の記録を漏れなく残し、車検・点検の期限を取りこぼさずに顧客へ案内したいという実務の要請があります。

汎用の顧客管理・見積管理との違い——「整備工場の車検業務」への特化

業務システムには、汎用の顧客管理（CRM）や見積管理、在庫管理といった仕組みもあります。名前だけを見ると自動車整備システムと重なる部分がありますが、両者は対象や前提が異なる仕組みです。導入の狙いを取り違えると、期待した整備業務の効率化や記録管理の効果が得られないため、役割の違いを整理しておきましょう。

汎用の顧客管理や見積管理は、業種を問わず使えるように作られており、顧客情報や見積・請求といった共通の業務を扱います。汎用の在庫管理も、商品や部材の入出庫を一般的な形で管理する仕組みです。これらは幅広い業種に対応できる反面、整備工場に固有の要素、たとえばナンバーや車台番号を軸にした車両管理、点検整備記録簿の様式、車検（継続検査）や定期点検の期限、作業指示と整備の工数といった要素は、そのままでは持っていません。これに対して自動車整備システムは、顧客と車両を結び付けて管理し、整備の作業指示から点検整備記録簿の作成、車検・点検期限の管理までを、整備業務の流れに沿って扱う点に特化します。

両者は排他的ではなく、組み合わせて使う場面もあります。たとえば全社の顧客情報は既存のCRMで持ちながら、整備の作業指示や点検整備記録簿、車検期限は自動車整備システム側で扱う、という切り分けが考えられます。すでに汎用の見積管理を導入していても、整備の作業指示や記録簿の様式に対応しきれていなければ、整備業務に特化した仕組みを別途補う意義は大きいはずです。自社が何を管理したいのかを起点に、どの仕組みが必要かを見極めるとよいでしょう。

自動車整備システムの機能要素——車両顧客・見積作業指示・整備記録車検期限・部品OBD

自動車整備システムを検討する際は、次の4つの機能要素をどの程度満たすかを見比べると判断しやすくなります。自社の入庫台数や取り扱う車種、指定工場・認証工場の別に照らして、必要な要素に優先順位を付けていきましょう。

車両・顧客管理と入庫——ナンバー・車台番号を軸に履歴をつなぐ

基礎になるのは、顧客と車両を結び付けて登録できることです。顧客の連絡先に加え、ナンバー、車種、車台番号、初度登録、車検満了日といった車両情報を持ち、来店・入庫のたびに整備履歴を積み上げます。1人の顧客が複数台を保有する場合や、1台の車両の所有者が変わる場合にも、車両を軸に履歴を追える設計が実務的です。この台帳が整っていれば、後述する見積や点検整備記録簿、期限管理も、車両情報を軸に展開できます。紙の顧客カードや個別の表計算ソフトに散らばった情報を、まず一つの台帳へ集約することが出発点になるでしょう。

見積・請求と作業指示——見積から整備、請求までを一本の流れに

2つ目は、見積・請求と作業指示です。入庫した車両に対して点検・整備の見積を作り、顧客の了承を得たうえで整備士へ作業指示を出し、完了後に請求へつなげる、という一連の流れを一本化します。部品代と工賃を分けて積算する、過去の整備履歴から見積を呼び出す、といった整備業務ならではの機能が要点です。手書きの伝票を後から転記する運用に比べ、記載の抜けや転記ミスを抑えやすくなります。見積・作業指示・請求が同じ車両データにひも付いていれば、どの整備にいくらかかったのかを後から追いやすくなるでしょう。

点検整備記録簿・車検期限管理——満了日を起点に案内と保存を支える

3つ目が、点検整備記録簿の作成と、車検（継続検査）・定期点検の期限管理です。国土交通省は、定期点検整備を行った際に点検整備記録簿へ記載し、3か月・6か月点検の対象車で1年、1年点検の対象車で2年保存することを求めています^*1。自動車整備システムで記録簿の様式を持てば、点検項目の記載から保存期間の管理までを一貫して扱えます。あわせて、車検証の有効期間満了後も使用する車両は継続検査を受ける必要があり、継続検査は有効期間の切れる2か月前から受けられます^*3。車検満了日を車両ごとに登録し、満了が近づくと担当者へ知らせる仕組みがあれば、案内や入庫の機会を取りこぼしにくくなります。車検を通したから期間中は問題ない、とは言い切れないため^*2、車検・定期点検・日常点検の区分をそれぞれ管理できると、整備業務の実態に沿った運用につながります。

部品在庫・OBD検査／電子車検証対応——制度と仕組みの変化に合わせる

4つ目は、部品在庫の管理と、OBD検査・電子車検証といった新しい仕組みへの対応です。整備に使う部品の在庫や発注、仕入れを管理できると、欠品による作業の停滞を抑えやすくなります。加えて近年は、車載式故障診断装置を用いたOBD検査が、令和6年10月1日（輸入車は令和7年10月1日）以降の車検で始まりました^*4。対象は令和3年10月1日（輸入車は令和4年10月1日）以降の新型車とされています^*4。また車検証は2023年1月4日から電子化され、A6サイズ程度の台紙にICタグを貼り付ける方式となっています^*5*6。整備システムが、こうしたスキャンツールや電子車検証の読み取り結果を扱えるか、少なくとも記録項目として持てるかは、これからの整備業務で見ておきたい観点です。どこまでを一つのシステムで扱うかは、自社の業務範囲しだいで優先順位を付けるとよいはずです。

開発を外注する前に確認したい点——データ移行・制度改正追従・システム連携

自動車整備システムを自社向けに開発して外部委託する場合、既製のパッケージをそのまま使うのとは違い、自社の業務手順や既存システムに合わせられる利点があります。一方で、要件のすり合わせが甘いと運用は定着しないものです。委託前に確認しておきたい点を挙げます。

第一に、既存の顧客台帳や整備履歴からのデータ移行です。多くの工場では、顧客と車両の情報が表計算ソフトの台帳や紙の作業伝票に散在しています。これらを新システムへ取り込む際、顧客・車両の名寄せや、車検満了日・点検期限の再計算をどこまで担ってもらえるかを確認しましょう。移行の設計は、導入初期の使い勝手を大きく左右する部分です。

第二に、制度や仕組みの変化への追従です。OBD検査の開始や車検証の電子化のように、整備業務に関わる制度や仕組みは変わり得ます^*4*6。点検整備記録簿の様式や記録項目、保存期間の要件が変わったとき、システム側の設定変更で対応できる設計になっているかを、要件定義の段階で確認しておくことが望ましいでしょう。制度の解釈そのものは自社や専門家の判断によりますが、記録項目や様式を柔軟に変えられる作りかどうかは、開発段階で決まってきます。

第三に、既存システムや外部機器との連携です。会計システムの請求データ、部品商のカタログ、OBD検査のスキャンツールや電子車検証の読み取り機器との連携ができれば、二重入力を避けられます。連携の範囲と方式は、開発の工数にも影響する部分です。加えて、担当者ごとに閲覧・編集できる範囲を分ける権限管理や、記録の書き換えを追えるログの残し方も、あわせて詰めておきたい観点になります。委託範囲を要件定義から設計・構築、運用・保守までのどこまでとするかを明確にし、元請（プライムベンダー）として一貫して担える体制かどうかを見極めることが、選び方の実質的な分かれ目になるでしょう。

まとめ：自動車整備システムを選ぶときの3つの視点

本稿では、自動車整備システムの役割と機能要素を、整備工場の車検・見積・整備記録という観点から整理しました。要点は次の3つです。第一に、自動車整備システムは車両・顧客管理と入庫、見積・請求と作業指示、点検整備記録簿と車検（継続検査）・定期点検の期限、部品在庫を一元管理し、手作業の台帳運用で起きがちな期限の見落としや記録の不備を抑える仕組みです。第二に、車検は保安基準への適合を検査時点で国が確認するものであり、有効期間内の状態を保証するものではないため^*2、点検整備記録簿の作成・保存^*1と車検・点検期限の管理が欠かせません。第三に、OBD検査^*4や電子車検証^*5といった制度・仕組みの変化に追従できる設計かどうかが、汎用の顧客・見積管理との違いを踏まえた選び方の核になるといえるでしょう。自社の入庫の実態と扱う車種を棚卸ししたうえで、必要な機能に優先順位を付けて検討することをおすすめします。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：国土交通省「点検整備の種類」（日常点検・定期点検の頻度／点検整備記録簿の保存期間）（ https://www.mlit.go.jp/jidosha/jidosha/tenkenseibi/tenken/t1/t1-2/ ）
2. *2　出典：国土交通省「点検整備の必要性」（車検と点検整備の関係）（ https://www.mlit.go.jp/jidosha/jidosha/tenkenseibi/tenken/t1/t1-1/ ）
3. *3　出典：国土交通省「車検の有効期間を更新するためには（継続検査）」（ https://www.jidoushatouroku-portal.mlit.go.jp/jidousha/kensatoroku/inspection/index.html ）
4. *4　出典：国土交通省「自動車の電子的な検査（OBD検査）について」（開始時期・対象車）（ https://www.mlit.go.jp/jidosha/jidosha_OBD.html ）
5. *5　出典：国土交通省「電子車検証特設サイト」（車検証の電子化・2023年1月4日）（ https://www.denshishakensho-portal.mlit.go.jp/ ）
6. *6　出典：国土交通省 報道発表資料「車検証を電子へ！～電子車検証の仕様に関する検討結果について～」（ICタグ方式・A6サイズ程度）（ https://www.mlit.go.jp/report/press/jidosha08_hh_003912.html ）

Tweet