非IT系物流企業が挑んだ車両管理システム導入の舞台裏：東都物流Cさんのユースケース
はじめに：物流業界の課題とシステム導入の必要性
全国に30拠点を持つ中堅物流会社・東都物流では、手書きやエクセル管理で車両点検と配車スケジュールを運用していました。急な配車変更や点検漏れが原因で、月に数件の遅延トラブルや事故リスクが発生。IT部門を持たない同社では、外部の力を借りて「システム 開発会社 選び方」から予算策定、費用相場の確認、発注までを社長のCさん自らが主導しました。本記事では、Cさんが車両管理システム導入を決意してから納品・定着までの全工程をストーリー形式で追体験していただきます。
ユースケース紹介：東都物流代表Cさんの挑戦
Cさん（45歳）は、ITに詳しくない非IT系経営者です。
-
業務課題：配車スケジュールの二重登録、点検漏れによるダウンタイム発生
-
導入ゴール：システム化で業務工数を30％削減し、事故リスクを半減
-
制約条件：初期予算は500万円以内、稼働開始は6か月後
Cさんはまず、自社の業務フローを紙に書き出し、「何をどこまで自動化すべきか」を整理。これにより要件定義のベースができ、開発会社との認識ずれを防ぐ大きな一歩となりました。
開発会社選定のプロセスと評価基準
CさんはWeb検索と知人紹介で5社をリストアップし、以下の4つの評価軸で比較検討しました。
-
実績・事例：物流業界向けシステム開発経験の有無
-
技術力：モバイル対応やクラウドサービス利用の実務スキル
-
コミュニケーション：担当者の日本語対応力と報告頻度
-
コスト透明性：見積もり内訳の細かさと比較可能性
各社に同じフォーマットでRFP（提案依頼書）を送り、フェーズごとの工数と単価を提示してもらうことで、「費用 相場」が見えづらかったCさんも、どの工程にコストがかかるのかを明確に把握できました。最終的に、物流向けモバイルアプリ実績が豊富なB社を選定しました。
予算策定と費用交渉のポイント
B社から提示された初回見積は総額600万円。Cさんは社内稟議を通すため、以下のポイントで交渉を実施しました。
-
フェーズ分割：要件定義〜プロトタイプ 200万円、開発〜検証 300万円、保守予備費 100万円に区分
-
オフショア活用：単価が低いフィリピン拠点での簡易実装工数を20％分割引
-
成果物定義：画面ワイヤーフレームやAPI仕様書の完成を完了条件として明文化
-
リスク予備：全体予算の10％分を要件変更リスク予備費として確保
これらの交渉により、総予算を500万円以内に収めつつ、予備費を含む形で稟議を通すことに成功しました。Cさんはここで、「発注」段階での予算交渉がプロジェクト成功の鍵だと実感しています。
プロジェクトキックオフと体制構築
B社との契約締結後、Cさんは東都物流社内のキーマンと開発チームの顔合わせを行うキックオフを開催しました。
-
社内からはCさんを含む経営層、物流担当マネージャー、現場ドライバー代表1名
-
B社からはプロジェクトマネージャー、アーキテクト、モバイルエンジニア、バックエンドエンジニア
-
役割分担、コミュニケーションルール（Slackと週次定例）、リスクエスカレーションフローを明文化
この段階で「システム 開発会社 選び方」で確認したコミュニケーション体制を再確認し、全員が同じゴールを共有。初動の意思決定スピードを高めました。
要件定義とプロトタイプレビュー
要件定義フェーズでは、自社業務フローをもとに画面イメージをモックアップで提示し、Cさんとマネージャーがレビューを実施しました。
-
画面遷移図とサンプルデータを揃え、現場ドライバーにも動作イメージを確認
-
プロトタイプは1週間以内に完成し、ステークホルダーから早期フィードバックを取得
-
要件の優先度をMoSCoW（Must/Should/Could/Won’t）で整理し、予算内でのフェーズ分割を決定
この手法により、後工程での仕様変更を最小限に抑え、開発コストのブレを制御できました。
本開発フェーズで直面した課題と対応策
開発が進む中、モバイルアプリのGPS連携で位置ズレが頻発する問題が発生しました。これを解決するために、以下の対応を実施。
-
端末別のGPS取得精度をテストし、位置補正アルゴリズムをアルファ版で動作検証
-
オフライン時のキャッシュ機能を追加し、ネットワーク途切れ時でも配車データを参照可能に
-
B社と連携して、ライブラリバージョンアップによる不具合修正を定期的にパッチ適用
これらの改善により、ドライバーからのクレームが70％減少し、追加費用の発生も抑えられました。
テスト・検証フェーズの工夫
テストは単体テストと結合テストに加え、物流現場でのレゴリグテストを実施しました。
-
ユニットテスト：自動化ツール（Jest, PHPUnit）を用い、開発工数の15％でカバー
-
結合テスト：API連携とUI操作をシナリオ化し、自動テストをCIパイプラインに組み込み
-
現地検証：実際のトラック車内でアプリを試験利用し、走行中の操作性をチェック
現地検証で得られた改善点を短期間で反映し、リリース品質を高めることで、納品後のサポート工数を大幅に削減しました。
モバイルアプリ配車機能のUX改善
本番リリース直前、ドライバーから「地図表示が見づらい」「操作が煩雑」という声が上がりました。CさんはB社と協議し、UX改善スプリントを追加実施。
-
地図ライブラリをGoogle Maps SDKからMapboxに変更し、地図タイル描画速度を50％向上
-
配車タスク完了ボタンを大きめに配置し、操作ミスを30％減少
-
ナビゲーション連携を強化し、ワンタップでナビアプリ起動を実現
これらの改修により、ドライバー満足度が大きく向上し、運用開始後1カ月で導入効果が明確になりました。
運用・保守体制の整備
リリース後はB社との保守契約を締結し、以下の体制で運用を開始しました。
-
月次メンテナンス：バグ修正と小規模機能追加（上限10時間/月）
-
SLA：平日9時～18時のリアルタイム対応、障害時は2時間以内の初動
-
モニタリング：Datadogでアプリエラー率とAPI応答時間を24時間監視
この体制で、初期運用トラブルを最小化し、追加見積もりなしでプロジェクトを安定稼働へ導きました。
導入後の効果測定とKPI改善
システム導入から3カ月後、東都物流では以下のKPI改善が確認されました。
-
配車業務工数：月間120時間削減（30％工数削減）
-
遅延・トラブル件数：月5件→1件に減少（80％削減）
-
車両稼働率：平均稼働時間が20％向上
-
ドライバー満足度：アンケートで平均4.2点（5点満点）
これらの成果をもとに、Cさんは次年度予算に車両管理システムの追加機能開発を盛り込み、さらなる業務効率化を図る計画を立てています。
Cさんが得た教訓と次のステップ
本プロジェクトでCさんが得た主な教訓は以下の通りです。
-
要件定義で現場の声を必ずプロトタイプに反映し、早期フィードバックを得る
-
「発注」時にRFPで詳細なフェーズ分割とリスク予備費を明記する
-
開発会社選びではコミュニケーション体制と運用ノウハウを重視する
-
テスト・現地検証を組み合わせ、納品後の追加コストを抑制する
-
保守SLAとモニタリング体制を事前に整備し、トラブル対応コストを最小化する
次のステップとして、CさんはAIによる配車最適化機能の実装を検討中です。PoCフェーズで小規模に試し、「費用 相場」を踏まえた本格開発を予定しています。
