プロンプトと前提コンテキスト
過密都市向けの駐車ソリューションを設計してください。チームには12週間の期間と、2つの商業地区でパイロットを実施するのに十分な運用リソースがあります。自治体から路上規制データは提供されますが、リアルタイムの満空情報は一部のエリアに限られ、情報が古い可能性があります。提携する1社の駐車場事業者が予約枠を提供できます。面接官は、ユーザー、課題、プロダクトの境界、MVP、指標、および事業拡大の判断基準を適切に選択することを求めています。
これは面接用の架空のケーススタディです。12週間、2つの地区、データカバレッジ、駐車場の提携などは前提条件であり、実在する都市に関する記述ではありません。近年のプロダクトセンス面接では、あえて「駐車ソリューションの設計」のような広範なプロンプトが出題されます。一方で、公共交通機関の実際の施策を見ると、現実の駐車プロダクトは規制ルール、空き状況、経路案内(ウェイファインディング)、予約、需要管理を複合的に組み合わせていることが分かります。この問いがプロダクトマネジメントの本質である理由は、誰の成果を改善し、プロダクトがどのような約束を誠実に果たせるかを選択することが中心課題であり、データやソフトウェアアーキテクチャはその選択に従うものだからです。
明確な回答を組み立てるため、自治体のパイロット目標を「2つの対象地区におけるうろつき運転(駐車場探しの周回)と違法停車の削減」と仮定します。初期ターゲットユーザーは、時間に追われながら反復的に停車を行う商業配送ドライバーとします。通勤者、一時的な訪問者、ライドヘイル(配車サービス)のドライバー、アクセシブル(障がい者等用)駐車スペースを必要とする人々も重要なセグメントですが、12週間の単一MVPですべてを対象にすると、適用されるルール、走行パターン、リスク許容度が混在してしまいます。
面接官が評価するポイント
第1の評価ポイントは、機能のアイデアを挙げる前に曖昧さを排除して絞り込めるかどうかです。「ドライバー」は単一のセグメントではなく、「駐車場を探す」という行為も、出発前の計画、法的に利用可能な荷捌きゾーンの特定、駐車スペースの確保、支払い、利用時間の延長、路上駐車ポリシーの取り締まりなど、多様な意味を含みます。優れた回答は、単一のセグメント、利用シーン、達成すべき成果を論理的に結びつけます。
第2の評価ポイントは、供給(インベントリ)の不確実性に対する誠実さです。路上の規制ルールは「その車両が特定の日時にその場所を使用してよいか」を示すものであり、「そこが空いているか」を証明するものではありません。センサーの観測結果は古延化しているか不正確な場合があります。予測はあくまで確率に過ぎませんが、確定した駐車場の予約はより強い確約を提供できます。すべてのデータソースを一律に緑色の「空車」ピンとして表示すると、誤った確信を与え、直前での危険な急なルート変更を誘発します。
第3の評価ポイントは、情報提供、確約(予約)、需要管理のトレードオフを適切に選択できるかです。経路案内は幅広い供給をカバーできますが、到着時の空きは保証できません。予約は管理可能なスペースに対して確実性を提供しますが、キープ(確保)による枠の遊休やノーショー(無断キャンセル)が発生します。価格設定(ダイナミックプライシング)は需要を分散できますが、自治体の権限や公平性に関するポリシーが必要であり、価格がボトルネックであるという十分な証拠が求められます。優れた候補者は、選定したジョブを解決するための最小限の約束から始めます。
最後に面接官が求めるのは、エンドツーエンドのプロダクトループです。信頼できるデータソースのラベリング、運転中の安全を考慮したジャーニー、供給パートナーへのインセンティブ、アプリのエンゲージメントではなく実際の成果を示す指標、適法性と公平性のガードレール、そして複数のドライバーが同じ路上スペースを奪い合う現実を認識したパイロット設計が網羅されているかを評価します。
回答前に確認すべき論点
- 自治体または事業部門が求めている成果は何か? 周回運転の削減、パーキングメーター収入の増加、配送の定時性向上、障がいを持つドライバーの支援など、目標によって優先順位やガードレールが異なります。本回答では「探索開始から短時間での適法な駐車」をパイロットの成果と定義します。
- 対象の路上スペースを利用できるユーザーと車両の条件は何か? 一般乗用車、商業用荷捌き、ライドヘイルの乗降、アクセシブル駐車、バス専用ゾーン、一時的な交通規制などを汎用的な1つの空き情報として扱うことはできません。ランキングを行う前に、利用資格を判定する必要があります。
- 各データソースは何を保証しているのか? 規制データは許可された用途を定義し、センサーは占有状況を推定し、駐車場システムは予約枠を確定します。データの鮮度、カバレッジ、エラー履歴に応じて、プロダクトが表示すべきなのが「ルール」なのか「確率」なのか「確約」なのかが変わります。
- ユーザーはいつプロダクトを操作するのか? 出発前の計画段階であれば比較検討が可能です。運転中の操作は音声中心かつ最小限に抑える必要があります。目的地の直前で画面の注視やタップを強いる設計は重大な安全リスクを生みます。
- 特定の車室を予約できるのか、それとも施設全体の枠のみか? オフストリート(路外)施設であれば入場管理と収容台数の制御が可能です。一般的な路上(オンストリート)スペースは、自治体の施策や取り締まりがない限り特定車室の確保が困難であるため、「路上ピンを予約する」というアプローチは実現不可能な約束となるリスクがあります。
- 駐車の成功をどのように検知・観測するのか? センサーによる検知、駐車場への入庫、決済、ドライバーの報告、手動の現地調査では、それぞれカバー率やバイアスが異なります。指標には明確なエビデンスの階層が必要です。
- どのような権限とパートナーインセンティブが存在するか? 自治体は路上ルールを管轄し、駐車場事業者は民間スペースを保有し、ドライバーはフィードバックを提供します。データアクセス権、取り締まり、収益配分、サポート体制が、コンセプトの運用実現性を左右します。
30秒での回答フレームワーク
「まず、パイロットの目標が周回運転と違法停車の削減であることを確認した上で、通勤者、訪問者、配送ドライバー、ライドヘイル、アクセシビリティ対応などのセグメントに分類します。2地区・12週間のパイロットでは、反復的かつ時間にシビアな停車を行い、荷捌きゾーンのデータとも合致する商業配送ドライバーを初期ターゲットとします。MVPでは車両の利用資格を判定し、最新の規制ルールとソース別の空き信頼度を統合し、総トリップコスト順に少数の合法的な選択肢をランキング提示し、フォールバック(代替案)を備えた音声案内を提供します。路上の予測空き情報と確約された駐車場予約は明確に区別し、古いデータを空車として提示することは避けます。主要指標は『探索エリア進入から5分以内に適法な停車場所に到達できた対象トリップの割合』とします。これに探索時間のパーセンタイル、誤案内率、違反、運転負荷、歩行負荷、ノーショー、パートナーの収益性、プライバシー、アクセシビリティのガードレールを組み合わせます。ドライバー同士がスペースを奪い合うため、地区および時間帯単位でパイロットを実施し、カバレッジ、信頼性、ユーザー成果、運用コストが事前定義した基準を満たした場合にのみ拡大します。」
ステップごとの詳細回答
地図の描画からではなく、ジョブ(課題)から始めます。パイロットの目標は、「商業配送ドライバーが、目的地周辺で適法な停車場所を選択し、予測可能な探索時間で到達できるように支援すること」です。成果はアプリの起動数やピンのクリック数、駐車セッション数の最大化ではありません。交通、安全性、公平性の問題を引き起こすことなく、適法な停車場所の探索を完了させることです。
初期の突破口(ウェッジ)を選択する前に、市場全体をセグメンテーションします:
| セグメント | 主なジョブ | 固有の制約 |
|---|---|---|
| 日常通勤者 | 長時間駐車の前に価格と空き状況を予測する | 目的地の固定、価格感度、長時間の滞在 |
| 一時的訪問者 | 不慣れなルールを理解し、適法な場所を見つける | 土地勘の不足、利用頻度の低さ |
| 商業配送ドライバー | 短時間の適法な荷捌き場所を反復して見つける | 時間的プレッシャー、車両資格、多数の停車 |
| ライドヘイル運転手 | 交通を妨げずに乗降を行う | 数秒〜数分の短い停車、乗客位置の変動 |
| アクセシブル駐車を必要とするドライバー | 目的地近くの利用資格に合った駐車スペースを見つける | 誤案内の重大な影響、厳格な利用資格 |
第1弾のパイロットとして商業配送ドライバーを選択します。走行頻度が高いため迅速な学習サイクルを回すことができ、荷捌きゾーンに絞ることでルールセットが限定され、2つの高密度商業地区という運用境界にも合致します。これはパイロットとしての選択であり、彼らのニーズがアクセシブル駐車より優先されるという意味ではありません。アクセシブル専用スペースは一般的なレコメンデーションから保護される必要があります。アクセシブル向け機能は、対象ユーザーとの共同設計を行い、十分な信頼性を持つインベントリと経路バリアフリーデータが揃った段階で個別にリリースすべきです。
選択したユーザーのジャーニーを整理します:停車の計画、対象地区への接近、適法な選択肢の比較、ナビゲーション、到着、利用可能かの確認、駐車またはリカバリー、配送作業の完了、出発。ペインポイントは単に「ピンがない」ことだけではありません。到着直前の不確実性(時間帯によるルールの変更、空いているように見えた場所が埋まること、適法な場所が配達先の入口から遠すぎることなど)にあります。
インターフェースを設計する前に、情報の真実性(確からしさ)を3つのレベルに定義します:
- 利用資格あり(Eligible): 最新の規制データに基づき、到着および滞在予定時間帯において当該車両と用途が法的に認められている。
- 空車見込み(Likely available): 観測日時とカバレッジが明らかなデータソースに基づき空きが推定されるが、確保はされていない。
- 規約内での確約(Guaranteed within terms): パートナー事業者が予約可能な施設枠を確認しており、確保、猶予期間、料金、キャンセル規約が適用される。
プロダクト上でこれらを単一の「空車」ステータスに統合してはなりません。路上スペースの空車見込みには、信頼度スコアと最終観測日時を表示します。信頼度が不十分な場合は、空き状況を主張せず「適法な選択肢」としてのみ表示します。確約された駐車場については、施設名、到着可能時間枠、車両制限、歩行距離、料金、キャンセル条件を明記します。なお、一時的な工事、イベント、道路清掃、規制変更は過去の占有トレンドデータよりも優先されます。
3つのプロダクト戦略を比較します:
| 戦略 | メリット | 制約・課題 | パイロットでの採用 |
|---|---|---|---|
| ルール提示と確率的案内 | 最大の潜在的カバレッジ、インベントリ確保リスクなし | 到着時の空きを保証できない | 採用(信頼度と代替案を提示) |
| 駐車場予約 | 到着時の確約性が高く、入庫の確認が可能 | 提携カバレッジの限界、キープによる枠の遊休 | 明示的な代替選択肢として採用 |
| 動的な路上価格設定 | 時間帯や場所の需要をシフト可能 | 行政権限が必要、価格感度の高い層への負担 | 初期のMVPからは除外 |
MVPの入力インターフェースでは、走行前または配車管理システムとの連携により、目的地、到着予定時刻、滞在時間、車両・許可証種別を取得します。まず違法な選択肢をフィルタリングし、最大3つの選択肢を提示します:最も可能性の高い路上ゾーン、近隣の適法な代替ゾーン(フォールバック)、利用可能な場合は予約可能な駐車場です。各選択肢には、歩行距離、適用ルール、信頼度または保証タイプ、予想料金、主要な制限事項を表示します。ユーザーは最終アプローチに入る前に選択し、移動中の更新は音声ガイダンスで行います。
ランキングは単なる直線距離ではなく、トリップ全体を反映すべきです。評価スコアは、運転時間、歩行時間、料金、法的適合性、スペース発見確率、予測が外れた場合のリカバリーコストを組み合わせます。これらの重み付けは検証すべきプロダクト方針であり、固定値ではありません。時間にシビアな配送の場合、信頼度の低い5分近い場所よりも、少し離れた予約枠の方が適している場合があります。価格や近さを理由に、適法性や保護スペースの利用資格を妥協してはなりません。
リカバリー経路の設計はコア機能の一部です。推奨された路上スペースが埋まっていた場合、ワンタップまたは単一の音声コマンドで「満車」を報告し、事前に計算された代替案へと即座に再ルーティングします(リストから選ばせる操作はさせません)。単一ユーザーの誤認や悪意を考慮し、ソース品質チェックを経た後にのみ信頼度スコアを引き下げます。駐車場のノーショーに対しては、明確な猶予期間、リマインダー、キャンセル手順、および自動枠開放ルールを設けます。車両走行中の画面操作に対してインセンティブを与えてはなりません。
データ品質の管理もプロダクトの重要な領域です。ゾーンおよびデータソースごとに、カバレッジ、観測データの鮮度、キャリブレーション状況を維持します。センサーやパートナーのデータを、現地調査や確定した駐車実績と照合します。特定の道路形状で機能したデータソースであっても、別のエリアで同等の信頼度を無条件に引き継ぐことはできません。規制ルールが非構造化テキストで管理されていたり、スナップショット更新しか行われない場合は、その制約を明示し、ルール検証ワークフローを優先して、適法性が不確かなゾーンの推薦をブロックします。
12週間を4つのフェーズに分けた段階的パイロットを実施します:
- 第1〜3週:データの真実性とワークフロー検証。 規制ルールのマッピング検証、対象ゾーンの現地調査、ドライバーへのインタビューおよび同乗観察、エビデンス階層の定義、ハンズフリープロトタイプのテスト。
- 第4〜6週:シャドーモード運用。 ドライバーに直接指示を出さずに推薦ロジックをバックグラウンド実行。観測された適法性、占有状況、実際の到着結果、配車担当者の判断と照合し、信頼度スコアを調整して危険なゾーンを除外。
- 第7〜10週:限定的な実環境パイロット。 固定のドライバーグループと特定時間帯に対象を絞って提供。サポート体制を配備し、即時停止スイッチを用意した上で、誤案内を日々モニタリング。
- 第11〜12週:再現性の確認と展開判断。 パフォーマンスの低かった条件下での再検証、パートナーの運用負荷やプライバシーへの影響を評価し、事前定義した基準に照らして拡大、縮小、改善、または終了を決定。
主要指標は、「探索エリア進入から5分以内に適法な停車場所に到達できた対象トリップの割合」と定義します。5分という数値は仮の基準値であり、ベースライン調査および自治体のサービス水準目標に基づいて調整します。成功率だけでなく、探索時間のp50およびp90もトラッキングします。副次指標には、レコメンデーション受容率、エビデンスタイプ別の駐車成功数、配送完了時間、フォールバック利用率、対象ドライバーのリピート率、駐車場の予約転換率、データソースのカバレッジを含めます。
ガードレール指標として、違法または資格外の路上への案内件数、高信頼度と判定した場所の誤案内率、二重駐車や交通違反、事故や運転中の脇見報告、過剰な歩行負荷、アクセシブル専用スペースの不正利用、駐車場のノーショー・キャンセル率、ドライバーの苦情件数、パートナーの稼働率とサポートコスト、位置情報の保持期間、地区間・ドライバーグループ間での成果の偏りを監視します。アプリのエンゲージメントは診断用データに過ぎず、駐車の成功結果の代替にはなりません。
トリートメント群(施策群)とコントロール群(対照群)のドライバーが同一の駐車スペースを取り合う環境では、単純なユーザー単位のA/Bテストを実施してはなりません。推薦によってトリートメント群の需要が特定ゾーンに集中すると、コントロール群の空き状況に干渉するためです。地区×時間帯のクラスター分割やスイッチバック設計を採用し、交通量やイベントの比較可能性を確認し、エリア間の流出入を記録します。干渉を完全に排除できない場合は、ユーザー単位の厳密な因果関係ではなく、パイロット全体のエビデンスとして結果を記述します。
事業拡大のための判定基準(ゲート)をあらかじめ設定します。規制ルールの精度が合意されたエラー許容値内に収まっていること、高信頼度予測のキャリブレーションが正確であること、代表的な時間帯において主要成果指標とテールの探索時間が改善していること、安全性・適法性・プライバシー・アクセシビリティの各ガードレールをクリアしていること、パートナーのサポートコストが再現可能な運用モデルに収まっていることを確認します。隣接地区や他セグメントへの展開は、1度に1つの変数を変えながら進めます。駐車場予約のみで成果が出ている場合は、都市全体の路上空き予測ではなく「予約ソリューション」としての有効性が検証されたと解釈すべきです。
高品質な回答例
「まず目標を明確にします。今回の自治体の狙いは、単なる駐車料金収入の増加ではなく、2つの商業地区における周回運転と違法停車の削減にあると定義します。市場を通勤者、訪問者、配送ドライバー、ライドヘイル、アクセシブル駐車の利用者にセグメンテーションします。12週間のパイロットでは、反復的かつ時間にシビアな停車を行い、荷捌きゾーンのデータ連携が可能な商業配送ドライバーから着手します。このスコープにおいて、一般ドライバーがアクセシブル専用スペースを利用することは認めません。
プロダクトが提供できる約束の強さはデータソースに依存します。規制データは『その時間に法的に停車できるか』を示し、直近のセンサーデータは『空いている確率』を提示するに留まります。提携駐車場は『利用規約に基づく予約の確約』を提供できます。これらを一律の緑のピンにするのではなく、『利用資格あり』『空車見込み』『確約』と明確に区別してラベリングします。
MVPでは、最終進入の前に目的地、到着時刻、滞在時間、車両区分を取得します。違法な選択肢を排除した上で、空車見込みの路上ゾーン、適法な代替フォールバック、利用可能な場合は予約可能な駐車場の最大3つを提示します。各項目には歩行距離、料金、制限事項、および観測鮮度付きの信頼度スコアまたは予約条件を表示します。ドライバーは最終ブロックに入る前に選択し、移動中の変更は音声で案内します。路上スペースが埋まっていた場合は、ワンアクションで代替ルートへ案内します。
初回のリリースにはダイナミックプライシングを含めません。価格設定には行政権限と公平性の検証が必要であり、初期の最大リスクは『信頼できる案内を提供できるか』にあるためです。最初の3週間をルールの検証と現場の行動観察、続く3週間をシャドーモード、4週間を限定ライブパイロット、最後の2週間を課題条件の再検証と拡大判断に充てます。
主要指標は『探索エリア進入から5分以内に適法な停車場所に到達できた対象トリップの割合』とし、探索時間のp50およびp90を併せて追跡します。誤案内、交通違反、脇見運転、歩行負担、アクセシブルスペースの不正利用、プライバシー、駐車場のノーショー、パートナーコスト、地区間の公平性をガードレールとして監視します。ドライバー間でスペースの競合が発生するため、個々のユーザーをランダムに割り振るのではなく、地区×時間帯のクラスター化またはスイッチバック検証を行います。
ルールの正確性、信頼度のキャリブレーション、駐車成果、テールの探索時間、ガードレール、サポートコストが事前設定した基準をクリアした場合にのみ拡大します。成果が予約可能な駐車場のみに起因している場合は、路上空き予測が機能したと誤認せず、予約プロダクトとしての拡大に舵を切ります。」
よくある失敗・落とし穴
- 空車スペースを示す地図の描画から始める → ピン表示はユーザー属性、適法性、データの鮮度、保証レベルを隠蔽してしまう → セグメントを1つ選び、データソースに応じた約束の強さを先に定義する。
- すべてのドライバーを同一のユーザーとして扱う → 通勤、配送、乗降、アクセシブル駐車では、目的も適用ルールも全く異なる → 初期ターゲットを1つに絞り、対象外としたセグメントの保護策を明記する。
- センサーの出力を安易に「空車」と呼ぶ → 到着までに状況が変わるか、誤検知の可能性がある → キャリブレーション済みの確率とデータの鮮度を表示し、「確約」という表現は管理可能な枠のみに限定する。
- 距離の近さだけでランキングする → 最寄りの場所が違法であったり、満車でリカバリーが困難、あるいは危険な場合がある → トリップ全体と失敗時のリカバリーコストを考慮して適法な選択肢を順位付けする。
- 管理権限のない公共の路上スペースを「予約」させる → 他のドライバーに占有された場合、約束を果たせない → 路上は空き予測に留め、予約は物理的・システム的に確保可能なスペースのみに限定する。
- 最初からダイナミックプライシングを導入する → データの信頼性や価格が制約要因であるかの検証ができておらず、公平性を損なうリスクがある → まず案内の信頼性を検証し、導入には行政の許可と公平性レビューを必須とする。
- 案内のクリック数を最適化する → クリックしても実際には周回運転や違法停車をしている可能性がある → 適法な駐車の達成結果と探索時間の分布を計測する。
- 運転中のドライバーにアプリ上での報告を求める → フィードバック収集が脇見運転のリスクを生む → 音声入力や停車後の確認を用い、走行中の画面操作に報酬を与えない。
- 共有スペースに対して個々のドライバー単位でA/Bテストを実施する → 施策群の行動が対照群の直面する空き状況に影響を与える → 地域・時間帯ごとのクラスター、スイッチバックテスト、波及効果の検証を行う。
- 1社の提携成功をもって全体を拡大する → 駐車場の予約枠の成功は、路上の空き予測の成立を意味しない → どの供給タイプが有効であったかを明確にし、機能したモデルのみを拡大する。
想定される追加質問と回答アプローチ
追加質問1:自治体にリアルタイムの満空センサーがない場合、何をリリースしますか?
リアルタイムの空き状況を無理に推測するのではなく、ルールベースのプロダクトを提供します。適法な場所、利用可能時間帯、料金、歩行距離、提携駐車場の収容能力、およびキャリブレーションされ明示された過去の傾向信頼度を表示します。シャドーモード、手動の現地調査、決済やパートナーのイベントデータ、停車後のフィードバックを活用してデータを蓄積します。路上の空きを確実に判別できない場合は、判別できると偽らずに、ユーザーが計画を立て安全にリカバリーできる支援に徹します。
追加質問2:ドライバーが最上位の推薦を無視しています。何を調査しますか?
選択された選択肢と拒否された選択肢を、適法性、歩行距離、料金、進行方向、信頼度、配達口の位置、車格、過去の失敗履歴などの観点から比較します。意思決定の瞬間にドライバーへインタビューを実施し、プロダクトが重要な制約を見落としていないか、あるいは間違ったジョブを最適化していないかを確認します。受容率の低さは必ずしもUIの問題ではなく、ランキングの評価関数、データの信頼性、または選択したセグメントの不一致が原因である可能性があります。
追加質問3:駐車場の予約でノーショーが多発している場合、どう対処しますか?
ノーショーの原因が、不正確な到着予測、キャンセルのしづらさ、隠れた手数料、ルート変更、またはリスクのない投機的なキープによるものかを分析します。原因を特定した上で、リマインダーの送付、短い猶予期間の設定、簡単なキャンセル手順、キャンセル待ち枠の開放、適切なデポジット設定などを検証します。ドライバーの利用完了率と遊休枠の推移を追跡します。条件を厳しくしすぎると稼働率は改善しても、正当な理由で遅れたドライバーを排除してしまうリスクに留意します。
追加質問4:このケースでユーザー単位のランダム化比較が危険な理由は何ですか?
駐車スペースは共有リソースだからです。トリートメント群のドライバーが特定のエリアへ誘導されると、その場所の空き状況、周辺交通、価格が変動し、コントロール群のドライバーに直接影響を及ぼします。波及効果が限定的な場合は地区×時間帯のクラスター化を行うか、同等の期間で施策を交互に切り替えるスイッチバック設計を採用します。境界を越えて移動したドライバー、突発イベント、天候、道路規制を記録します。干渉が無視できない場合は、ユーザー単位の因果効果を主張せず、パイロットの限定的エビデンスとして報告します。
追加質問5:自治体から一般の乗用車ドライバー全員への対応を求められました。何を変更しますか?
配送向けのMVPをそのまま流用してはなりません。一般の乗用車トリップを通勤、イベント、短時間訪問、アクセシビリティなどのニーズに再分類し、自治体の目的を再確認した上で、異なる滞在時間や決済行動を調査し、関連するスペースとルールのみを追加します。配送向けのベースラインを維持しつつ、1つの地区で1つの追加セグメントに絞ってパイロットを実施します。拡大は新たなプロダクト仮説の検証であり、初期コホートからの安易なスケールではありません。
追加質問6:アクセシブル駐車を必要とするドライバー向けにはどのように設計しますか?
対象となる当事者やアクセシビリティ推進団体と共同設計を行います。許可証や専用スペースのルール、歩道の段差(カーブカット)、移動経路のバリアフリー状況、車両の高さ・幅制限、障害物の有無、データが古延化していた場合のリスクの大きさを検証します。保護されたスペースは、一般向けの推薦や価格実験から除外します。データソースのカバレッジとエラー処理が確実な約束を提供できる水準に達した段階でのみリリースし、目的の場所への適法な到着率、移動・歩行の追加負担、誤案内率、報告された物理的障壁を測定します。
追加質問7:駐車場の売上は伸びたものの、周回運転が減っていない場合はどう判断しますか?
ビジネス指標は改善したものの、パイロットの本来の目標は達成されていません。予約者がもともと駐車場を利用していたドライバー層に偏っていないか、路上を探すドライバーにとって料金や歩行距離が受け入れられない水準でないか、あるいは案内によって探索を減らすことなく単に交通を移動させただけではないかを調査します。売上はパートナー指標として維持しつつも、適法な駐車と探索時間の短縮が達成されない限り、プロダクトが成功したと結論づけてはなりません。ターゲットセグメント、提供価値、供給の構成を見直すか、パイロットを中止します。