TMSのリニューアルにおけるPoC・プロトタイプ・モックアップは、利用者が直接触れる画面の操作体験（UX/UI）を検証する手法です。
実際のドライバーや配車担当者が、ストレスなく操作できるか、状況を一目で把握できるかを確かめます。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・TMSのリニューアルの完全ガイド
- PoC・プロトタイプ・モックアップの位置づけと使い分け
- Figma等を使ったデザインプロトタイピングの進め方
- ドライバーアプリ・配車ダッシュボード・荷主ポータルごとの検証ポイント
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMSのリニューアルにおけるPoC・プロトタイプ・モックアップの位置づけ
同じ「PoC」という言葉でも、検証したい対象は大きく異なります。そのため、TMSのリニューアルでPoCを正しく設計するには、何を検証したいのかという目的を、ほかの種類のPoCと切り分けて理解しておく必要があります。
TMS開発・モダナイゼーション・刷新・更改におけるPoCとの違い（UX検証という目的）
「TMSのモダナイゼーション」のPoCは、リホスト・リプラットフォーム・リビルドといった技術的なアプローチが、既存データや連携先で問題なく動くかを検証します。「TMS刷新」のPoCは、限られた予算で最も課題の大きい拠点にトライアル導入し、投資判断の材料になる効果を実証することが目的です。
「TMS更改」のPoCは、期限内に完遂できるかという時間的制約のもとで、省略の可否も含めて契約更新のリスクを検証するものです。一方で、本記事で扱うPoC・プロトタイプ・モックアップは、技術的に動くかではなく、ドライバーが実際に操作でき、配車担当者が一目で状況を把握できるかという使い勝手そのものを検証します。
検証の主役は、エンジニアではなく毎日その画面を操作する現場の利用者です。この点が、ほかのPoCとの最大の違いです。
モックアップ・プロトタイプ・PoCの使い分け
UX/UI起点のリニューアルでは、モックアップ、プロトタイプ、PoCの3つを段階ごとに使い分けることが大切です。モックアップは、画面のレイアウトや配色を静的に再現した見本で、デザインの方向性について関係者の目線を合わせるために使います。
プロトタイプは、Figmaなどのツールで、実際にタップやクリックができる画面遷移まで再現したものです。操作の流れが自然かどうかを確かめるのに使います。最後に、PoCは、実装した最小限の機能を実際の業務フローの中で一定期間試験運用し、現場に本当に定着するかを検証するものです。
この3段階を踏まずに本実装へ進むと、公開後に大きな手戻りが起きやすくなります。このため、限られた予算の中でも、モックアップとプロトタイプの検証だけは省略しないことが推奨されます。
デザインプロトタイピングの進め方（Figma等の活用）
実際のコードを書く前にプロトタイプで検証すると、手戻りを防ぎ、コストを抑えることができます。また、現場の意見も、開発に入る前に取り入れられます。
ワイヤーフレーム〜モックアップ〜クリッカブルプロトタイプの3段階
デザインプロトタイピングは、段階的に精度を上げていくのが基本です。まず、画面に何をどの順番で配置するかという骨組みだけを示したワイヤーフレームを作成し、無駄なステップや迷いやすい箇所を洗い出します。
次に、色・フォント・アイコンといった視覚要素を加えたモックアップを作成し、デザインの方向性について合意を取ります。最後に、Figmaなどのツールでボタンを押したときの画面遷移まで再現したクリッカブルなプロトタイプを作成し、実際のスマートフォンやPC上で現場のキーマンに操作してもらいます。
この3段階を経ることで、開発前にUIの課題を見つけて修正できます。さらに、後工程での大規模な仕様変更による手戻りも、未然に防げます。
現場キーマンを巻き込んだ視覚的合意形成（チェンジマネジメント）
プロトタイプの検証には、UIの不具合を見つける目的に加えて、現場の抵抗を和らげるチェンジマネジメントとしての役割もあります。ベテランの配車担当者は、「自分の職人スキルが奪われる」と感じ、自分の存在意義が危ぶまれることがあります。一方、ドライバーは「操作が増えて監視されているように感じる」と抵抗を示すことが少なくありません。
要件定義の初期段階からプロトタイプを見せて現場の意見を取り入れると、「自分たちも設計に関わった」という当事者意識を持ってもらえます。この当事者意識が、公開後の受け入れやすさを大きく左右します。
プロトタイプを一方的に見せるだけでなく、現場からの指摘を実際に反映して再提示するというやり取りを1〜2往復挟むことが、視覚的合意形成の質を高めるポイントです。
対象別ユーザビリティ検証のポイント
ドライバー向けアプリと配車ダッシュボードでは、利用するシーンも、検証すべき項目もまったく異なります。そのため、対象ごとに検証の設計を分ける必要があります。
ドライバー向けアプリの実機ユーザビリティ検証（タップしやすさ・視認性・入力負荷）
ドライバー向けアプリの検証では、実際のスマートフォンやタブレットを使い、タップのしやすさ、視認性、入力負荷の3点を重点的に確認します。タップのしやすさでは、運転の合間や作業用の手袋をしたままでも押しやすい、ボタンの大きさと配置になっているかを見極めます。
視認性では、屋外の直射日光下や夜間の車内でも文字が読みやすいコントラストやフォントサイズになっているかを確かめます。さらに、入力負荷では、「帰社後に30分かかっていた手書き日報が数回のタップで完了する」といった具合に、日々の入力量に無理がないかを確認します。
高年齢層のドライバーが多い現場では、マニュアルを読まなくても直感的に操作できるかどうかが、定着の鍵を握ります。そのため、検証には、実際の年齢層やITリテラシーに近いドライバーに参加してもらうことが望ましいといえます。
配車ダッシュボード・荷主ポータルのユーザビリティテスト
配車ダッシュボードの検証では、トラックの現在地や遅延状況、荷待ち時間といった運行データを、地図やガントチャート上で直感的に把握できるかを確かめます。異常発生時のワーニング表示が目立つか、ドラッグ＆ドロップによる配車の組み替えが、Excelやホワイトボードでの作業より速く簡単に行えるかも見ます。
さらに、必要な実績データへ迷わず素早くアクセスできるかも見ます。荷主向けポータルでは、社外の利用者の視点での検証が中心になります。到着予定時刻やトラブル状況の通知が分かりやすいか、問い合わせをしなくても必要な情報にたどり着けるかを確かめます。
いずれも、机上の資料やプロトタイプだけでは見えない部分が多いため、実際の業務フローに近い環境での検証が欠かせません。
PoC実施における失敗パターンと回避策
UX/UIのPoCは、実施すること自体が目的になってしまうと、本来の効果が得られません。代表的な失敗パターンは2つあり、それぞれに回避策があります。
「動くものを見せて終わり」にしないための評価基準設計
プロトタイプやPoCを実施しても、「触ってもらって好評だった」という感想だけで終わらせると、本格導入後に想定外の課題が噴出するリスクが残ります。そこで、PoCを実施する前に、定量的な評価基準をあらかじめ設計しておくことが重要です。
評価基準には、SUS（System Usability Scale）のスコア目標、タスク成功率、入力ミスの発生率の許容範囲があります。タスク成功率は、特定の操作を何秒以内・何タップ以内で完了できるかを基準にします。
評価基準を事前に決めておけば、検証後に「良かった・悪かった」と主観で議論するのを避けられます。そのうえで、Go/No-Goの判断を客観的な材料に基づいて下せます。
短期PoC成功が本番展開を保証しない罠
限られた期間と少人数で実施した短期PoCがうまくいっても、それが全社展開の成功を保証するわけではありません。PoCに参加するのは、業務に協力的で操作にも慣れやすいメンバーが選ばれがちです。一方、全社展開では、ITリテラシーにばらつきのある幅広い層のドライバーや配車担当者が対象になります。
また、PoC期間中は検証への意識が高く、丁寧に操作してもらえても、日常業務に組み込まれた後は、雑な操作や自己流の運用が発生しやすくなります。
この罠を避けるには、PoCの対象者を多様な年齢層やITリテラシー層から意図的に選ぶことが有効です。あわせて、本番展開後も一定期間は現場定着率をモニタリングし続けることが大切です。
PoC・プロトタイプ検証にかかる期間と費用感
実務の計画に使えるよう、検証にかかる期間と費用の目安、そして体制づくりの要点を示します。
期間の目安（モックアップ〜MVP〜トライアル運用）
モックアップとクリッカブルプロトタイプの作成・検証には、対象となる接点の数にもよりますが、2〜4週間程度が目安です。プロトタイプの方向性が固まった後は、一部の拠点や特定業務に絞った最小限のシステム（MVP）を開発します。この開発には、数週間〜3ヶ月程度を要します。
MVPが完成したら、実際の運用に近い形でトライアル運用を行い、現場定着を評価するPoCフェーズに進みます。このフェーズには、3〜6ヶ月程度を見込んでおくのが現実的です。
操作性や入力負荷は資料だけでは見えにくいため、期間を短縮しすぎないことが大切です。実際の日常業務の中で、配車担当者やドライバーが無理なく使えるかを見極めることが、後の全社展開の成否を左右します。
費用感と体制づくりのポイント
モックアップやプロトタイプの作成費用は、デザイナーの工数を中心に、数十万円〜100万円台が一般的な相場です。MVPの開発まで含めると、数百万円規模になることもあります。
体制面では、情報システム部門だけで検証を進めず、各拠点で影響力のあるベテラン配車担当者やドライバー代表を、プロジェクトの初期段階から巻き込むことが大切です。さらに、その人たちの意見を検証の設計にも反映させます。
経営層に対しては、「操作性の検証だから遅くて当然」と軽視されないよう、定着に失敗した場合の手戻りコストと比べたPoCの投資対効果を、あらかじめ説明しておきます。そうすると、検証に十分な期間と予算を確保しやすくなります。
まとめ
ここまで、TMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、位置づけから期間と費用感までを解説しました。
モックアップ、プロトタイプ、PoCの3段階を踏み、SUSやタスク成功率といった定量的な評価基準を事前に設計しておくことが、UX/UI起点のリニューアルを成功させる鍵です。検証を「動くものを見せて終わり」にせず、多様な年齢層やITリテラシーの現場を巻き込みながら、本番展開後の定着まで見据えて進めることが、PoCの最大の論点です。
物流現場のユーザビリティ検証に実績のあるパートナーに、早めに相談することをお勧めします。
▼全体ガイドの記事
・TMSのリニューアルの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。