TMSのリニューアルのPoC・プロトタイプ・モックアップ開発について

TMSのリニューアルとは、配車計画の立案・運賃計算・車両動静管理という機能そのものを作り替えるのではなく、ドライバーが日々操作する配車・運行管理アプリの画面、運行管理者が状況を確認するダッシュボード、荷主が配送状況を確認するポータルといった「利用者が直接触れる操作体験（UX/UI）」を刷新する取り組みを指します。技術的な刷新手法の妥当性を検証する「TMSのモダナイゼーション」のPoC、経営層の投資判断材料としての「TMS刷新」のPoC、期限内での技術的実現性を確認する「TMS更改」のPoCとは異なり、本記事群が扱うPoC・プロトタイプ・モックアップは、「実際にドライバーがストレスなく操作できるか」「配車担当者が一目で状況を把握できるか」という、利用者の操作体験そのものを検証することが目的である点が大きな特徴です。

本記事では、TMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、それぞれの位置づけと使い分け、Figma等を用いたデザインプロトタイピングの進め方、ドライバーアプリ・配車ダッシュボード・荷主ポータルという対象別のユーザビリティ検証のポイント、失敗パターンとその回避策、そして検証にかかる期間と費用感までを、具体的な検証項目とともに体系的にお伝えします。デザイン刷新の効果をどう事前検証すればよいか悩んでいる物流部門・情報システム部門の方にとって、実務的な進め方が身に付く内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・TMSのリニューアルの完全ガイド

TMSのリニューアルにおけるPoC・プロトタイプ・モックアップの位置づけ

TMSのリニューアルにおけるPoCを正しく設計するには、何を検証したいのかという目的を、隣接する記事群と切り分けて理解しておく必要があります。同じ「PoC」という言葉でも、検証したい対象がまったく異なるためです。

「TMSのモダナイゼーション」のPoCは、リホスト・リプラットフォーム・リビルドといった技術的アプローチが既存データ・連携先で問題なく動くかという技術的実現性を検証します。「TMS刷新」のPoCは、限られた予算で最も課題の大きい拠点にトライアル導入し、投資判断の材料となる効果を実証することが目的です。「TMS更改」のPoCは、期限内に完遂できるかという時間的制約のもとで、省略可否も含めて検討される契約更新リスクの検証です。これらに対して本記事が扱うTMSのリニューアルのPoC・プロトタイプ・モックアップは、技術的に動くかどうかではなく、実際にドライバーが操作でき、配車担当者が一目で状況を把握できるかという「使い勝手そのもの」を検証することが目的です。検証の主役はエンジニアではなく、実際にその画面を毎日操作する現場の利用者である点が、他の記事群のPoCとの最大の違いです。

UX/UI起点のリニューアルでは、モックアップ・プロトタイプ・PoCという3つの検証手法を、段階ごとに使い分けることが重要です。モックアップは、画面のレイアウトや配色を静的に再現した見本で、デザインの方向性について関係者間で目線を合わせるために使います。プロトタイプは、Figmaなどのツールで実際にタップ・クリックできる画面遷移まで再現したもので、操作の流れが自然かどうかを検証するために使います。そしてPoCは、実装した最小限の機能を実際の業務フローの中で一定期間試験運用し、現場で本当に定着するかを検証するために使います。この3段階を踏まずにいきなり本実装に進んでしまうと、公開後に大きな手戻りが発生するリスクが高いため、限られた予算の中でもモックアップとプロトタイプの検証だけは省略しないことが推奨されます。

デザインプロトタイピングの進め方（Figma等の活用）

実際のコードを書き始める前にプロトタイプで検証することは、手戻りを防ぎコストを抑えるうえで極めて効果的です。ここでは具体的な進め方と、現場を巻き込むうえでの狙いを見ていきます。

デザインプロトタイピングは、いきなり精緻な画面を作るのではなく、段階的に精度を上げていく進め方が基本です。まず、画面に何をどの順番で配置するかという骨組みだけを示したワイヤーフレームを作成し、無駄なステップや迷いやすい箇所を洗い出します。次に、色・フォント・アイコンといった視覚要素を加えたモックアップを作成し、デザインの方向性についての合意を取ります。最後に、Figmaなどのツールでボタンを押したときの画面遷移まで再現したクリッカブルなプロトタイプを作成し、実際のスマートフォンやPC上で現場のキーマンに操作してもらいます。この3段階を経ることで、開発前の時点でUIの課題を発見・修正でき、後工程での大規模な仕様変更という手戻りコストを未然に防ぐことができます。

プロトタイプ検証には、UIの不具合を発見するという機能面の目的に加えて、現場の心理的な抵抗を和らげるチェンジマネジメントとしての役割もあります。ベテラン配車担当者は「自分の職人スキルが奪われる」と自己存在意義の危機を感じ、ドライバーは「操作が増えて監視されているように感じる」と抵抗を示すことが少なくありません。要件定義の初期段階からプロトタイプを見せながら現場の意見を取り入れることで、「自分たちも設計に関わった」という当事者意識を持たせることができ、これが公開後の受け入れやすさを大きく左右します。プロトタイプを一方的に見せるだけでなく、現場からの指摘を実際に反映して再提示するというキャッチボールを1〜2往復挟むことが、視覚的合意形成の質を高めるポイントです。

対象別ユーザビリティ検証のポイント

ドライバー向けアプリと配車ダッシュボードでは、利用シーンも検証すべき項目もまったく異なります。それぞれに適した検証設計が必要です。

ドライバー向けアプリの検証では、実際のスマートフォンやタブレット端末を使い、運転の合間や作業用の手袋をしたままでも押しやすいボタンの大きさ・配置になっているかという「タップのしやすさ」、屋外の直射日光下や夜間の車内でも文字が読みやすいコントラスト・フォントサイズになっているかという「視認性」、そして「帰社後に30分かかっていた手書き日報が数回のタップで完了する」といった、日々の入力量に無理がないかという「入力負荷の最小化」の3点を重点的に確認します。高年齢層のドライバーが多い現場では、マニュアルを読まなくても直感的に操作できるかどうかが定着の鍵を握るため、検証には可能な限り実際の年齢層・ITリテラシーに近いドライバーに参加してもらうことが望ましいといえます。

配車ダッシュボードの検証では、トラックの現在地や遅延状況、荷待ち時間などの運行データが地図やガントチャート上で直感的に把握できるかという「リアルタイム情報の視認性」、異常発生時のワーニング表示が目立つように設計されているか、ドラッグ＆ドロップによる配車の組み替えがExcelやホワイトボードでの作業より速く・簡単に行えるかという「操作の効率性」、そして必要な実績データへ迷わず素早くアクセスできるかという「情報へのアクセス性」を検証します。荷主向けポータルでは、到着予定時刻やトラブル状況の通知が分かりやすいか、問い合わせをせずとも必要な情報にたどり着けるかという、社外の利用者視点での検証が中心になります。いずれも、机上の資料やプロトタイプだけでは見えない部分が多いため、実際の業務フローに近い環境での検証が欠かせません。

PoC実施における失敗パターンと回避策

UX/UIのPoCは、実施すること自体が目的化してしまうと本来の効果を得られません。ここでは代表的な2つの失敗パターンと、その回避策を見ていきます。

プロトタイプやPoCを実施しても、「触ってもらって好評だった」という定性的な感想だけで終わらせてしまうと、本格導入後に想定外の課題が噴出するリスクが残ります。PoCを実施する前に、SUS（System Usability Scale）によるスコア目標や、特定の操作を何秒以内・何タップ以内で完了できるかというタスク成功率の基準、入力ミスの発生率の許容範囲といった定量的な評価基準をあらかじめ設計しておくことが重要です。評価基準を事前に決めておくことで、検証後の「良かった・悪かった」という主観的な議論を避け、Go/No-Goの判断を客観的な材料に基づいて下せるようになります。

限られた期間・少人数で実施した短期PoCがうまくいったとしても、それがそのまま全社展開の成功を保証するわけではありません。PoCに参加するのは業務に協力的で操作にも慣れやすいメンバーが選ばれがちで、実際に全社展開した際には、ITリテラシーにばらつきのある幅広い層のドライバー・配車担当者が対象になります。また、PoC期間中は検証への意識が高く丁寧に操作してもらえても、日常業務に組み込まれた後は雑な操作や自己流の運用が発生しやすくなります。この罠を避けるには、PoCの対象者を意図的に多様な年齢層・ITリテラシー層から選定すること、そして本番展開後も一定期間は現場定着率をモニタリングし続けることが有効です。

PoC・プロトタイプ検証にかかる期間と費用感

実務上の計画に落とし込むために、検証にかかる期間と費用の目安、そして体制づくりのポイントを整理しておきます。

モックアップとクリッカブルプロトタイプの作成・検証には、対象接点の数にもよりますが2〜4週間程度が目安です。プロトタイプの方向性が固まった後、一部の拠点や特定業務に絞った最小限のシステム（MVP）を開発するフェーズには、数週間〜3ヶ月程度を要します。MVPが完成した後、実際の運用に近い形でトライアル運用を行い、現場定着を評価するPoCフェーズには、さらに3〜6ヶ月程度を見込んでおくのが現実的です。操作性や入力負荷は資料だけでは見えにくいため、この期間を短縮しすぎず、実際の日常業務の中で配車担当者・ドライバーが無理なく使えるかを見極めることが、後の全社展開の成否を左右します。

モックアップ・プロトタイプ作成の費用は、デザイナーの工数を中心に数十万円〜100万円台が一般的な相場で、MVP開発まで含めると数百万円規模になることもあります。体制面では、情報システム部門だけで検証を進めるのではなく、各拠点で影響力のあるベテラン配車担当者やドライバー代表をプロジェクトの初期段階から巻き込み、検証の設計自体にも意見を反映させることが重要です。あわせて、経営層に対しては「操作性の検証だから遅くて当然」と軽視されないよう、定着失敗による手戻りコストと比較したPoCの投資対効果をあらかじめ説明しておくことで、検証に十分な期間と予算を確保しやすくなります。

まとめ

本記事では、TMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、その位置づけと使い分け、Figma等を用いたデザインプロトタイピングの進め方、ドライバーアプリ・配車ダッシュボード・荷主ポータルという対象別のユーザビリティ検証のポイント、失敗パターンとその回避策、そして検証にかかる期間と費用感を体系的に解説しました。モックアップ・プロトタイプ・PoCという3段階を踏み、SUS・タスク成功率といった定量的な評価基準をあらかじめ設計しておくことが、UX/UI起点のリニューアルを成功させる鍵となります。検証を「動くものを見せて終わり」にせず、多様な年齢層・ITリテラシー層の現場を巻き込みながら本番展開後の定着まで見据えて進めることが、TMSのリニューアルにおけるPoCの最大の論点です。物流現場のユーザビリティ検証に実績のあるパートナーに早めに相談することをお勧めします。

▼全体ガイドの記事
・TMSのリニューアルの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。