自動車整備は「予約が取れた＝段取り完了」ではありません。現場が詰まるのは、入庫した瞬間にピットが空いていない、部品が揃っていない、追加整備の承認待ちで止まる、の三つが重なるからです。 この状態で電話や紙の作業指示に頼ると、誰が何を待っているのかが見えなくなり、結果として回転率が落ちます。
整備の流れを一言で「作業」と呼ぶと、管理が崩れます。実務では、次の工程が独立していて、それぞれにボトルネックがあります。
予約フォーム側で「適合確認」や「メニュー別の枠」を先に揃えると、入庫後の詰まりが減ります。持込取付やタイヤ交換の前提整理は タイヤ交換・持込取付の予約フォーム設計 が参考になります。
「タイヤ交換」「車検」「オイル交換」といったメニュー名は、受付側には便利ですが、ピット側には曖昧です。 ピット割当と所要時間を安定させるには、メニューをタスクに分解し、必要な条件（設備・部材・資格）とセットで持たせます。
| メニュー | タスク分解（例） | 条件（例） |
|---|---|---|
| タイヤ組替 | 脱着→組替→バランス→増締→試走 | TPMS対応、ランフラット、低扁平 |
| 車検 | 点検→整備→検査ライン→書類 | 代車、部品交換見込み、外注の有無 |
| ブレーキ | 点検→交換→エア抜き→試走 | 部品在庫、追加整備の可能性 |
入力項目が増えすぎる場合は、送信後に必要なものだけ追加入力で回収する方が運用が続きます。追加情報の回収設計は 不足情報を後から取り切る方法 の考え方が使えます。
現場が困るのは「どこまで終わったか」よりも、「何待ちで止まっているか」です。 そのためステータスは、工程の羅列より待ち要因を優先して設計します。
ステータスは増やしすぎると更新されません。設計の基礎は ステータス運用の決め方 を土台にし、期限の扱いは 優先度・期限の運用ルール と合わせると破綻しにくいです。
「全部自動割当」は現場に合わないことが多いです。急な入庫、設備の空き、担当者の得意分野があるため、現実は混在になります。 おすすめは「自動で候補を出し、最終決定は手動」という構成です。割当の考え方は 担当者割当ロジック を整備向けに置き換えると整理しやすいです。
「部品待ち」が厄介なのは、入荷予定日が曖昧なときです。 入荷日が曖昧だと、顧客連絡もできず、ピット計画が崩れます。運用上は、部品待ちを二段階に分けるだけで変わります。
「部品待ち」を期限で回すために、案件一覧に“予定日”を持たせると実務が楽になります。集計や一覧のカラム設計は 問い合わせ管理ダッシュボードのカラム設計 の考え方を流用できます（整備の案件管理に置き換えるだけです）。
追加整備の承認待ちは、放置されると滞留の温床になります。 ここは「いつ・誰が・何を連絡するか」を固定化し、テンプレートも持っておくと強いです。 確認メールの情報整理は 確認メールに入れるべき情報 をベースに、整備向けに置き換えると抜けが減ります。
自動車販売・整備・タイヤショップ全体の設計方針（予約〜案件管理〜将来拡張）を俯瞰するなら、自動車販売・整備・タイヤショップ向け を入口に要件を整理すると、場当たりで機能追加しにくくなります。
整備の詰まりは「作業が遅い」より「待ちが見えない」ことが原因になりがちです。メニューをタスクに分解し、部品待ち・承認待ちをステータスで表現し、ピット割当は自動候補＋手動確定の混在で回す。 入荷予定日と連絡期限を持たせるだけでも滞留は大きく減ります。