Multiple Tasks
一つの走行に、複数の作業が含まれる
位置・速度・時刻を見ながら、一つのGPSログを複数の作業へ分割できるようにした。
02Decide What to Build
調査と事業課題から、
作るべきものと順序を決める
シードスタートアップの一人目プロダクトデザイナーとして、日報業務のリサーチから課題定義、UX・UI、開発ロードマップまでを担当した。16人の業務を観察し、GPSデータからシステムが下書きを作る体験を設計。100件以上の要望を、事業の成長順序に整理した。
調査対象16人
整理した要望100+件
導入効果日報提出率UP
事業成果他業種へ展開
01 Discovery
16人が帰宅するまで、
日報業務を観察する
Context
農業から除雪、ごみ収集などへ事業を広げるため、車両を使う現場の日報を標準化する構想があった。社内には多くの機能要望があったが、何から作るべきかは決まっていなかった。
要望を画面に並べる前に、農作業の終了から事務所への集合、日報の記入・提出、全員の帰宅までを観察した。
Insight
問題は紙ではない。
一日の終わりに、記憶から日報を作る業務そのものだった。
Observed
- 作業終了は20時23分、解散は22時31分
- 一日の行動を記憶から思い出して記入
- 時間の丸め方が人によって異なる
- 運転中のメモの内容と粒度が揃わない
- 全員が書き終わるまで待機
- マネージャーが16人分を再集計
02 Product Decision
人が書くのではなく、
システムが事実を下書きする
Decision
レポサクには、車両がいつ、どこを走ったかを示すGPSデータがある。そこで入力フォームを作るのではなく、GPSデータから日報の下書きを自動生成することにした。
入力しやすい日報フォームではなく、入力そのものを減らす業務フローを設計した。
Before
記憶から一件ずつ入力手書きをスマートフォン入力に変えても、作業者は一日の行動を思い出し、時刻と内容を入力しなければならない。入力項目を増やせば、データは詳しくなっても提出の負担は増える。After
システムが作った下書きを承認 GPSの位置と時間を基準に、必要な部分だけを分割・修正する
03 Roadmap
100件以上の要望を、
事業の成長順序に変える
社内の機能要望と調査から得たアイデアを合わせると、改善候補は100件を超えた。すべてを同時に作るのではなく、現場がすぐ使える状態から、分析や他業種展開に耐えられるデータ基盤へ成長する順序を定義した。
個別の機能要望を優先順位づけするのではなく、プロダクトと事業が成長する順序を設計した。
Phase 1: まず提出できる
GPSデータから、スマートフォンで日報を作成・提出できる。
Phase 1.1: 継続して使える
提出状態、代理提出、修正、ヘルプなど、実運用に必要な体験を整える。
Phase 2: 事業に活かせる
集計、CSV、請求、分析、他業種展開に耐えられるデータ品質へ広げる。
04 Product Structure
現場の例外を、
異なる業種でも破綻しない構造へ
例外を機能として足すのではなく、異なる現場を受け止められる共通構造として設計した。
Multiple People
一台の車両に、複数人が乗る
ログを個人へ固定せず、会社全体のデータから自分の作業を選べる構造にした。
Without GPS
GPSデータがない日もある
事務や整備の日も、GPSがある日と同じ導線で手動提出できるようにした。
05 Impact
記憶から書く日報を、
事実を確認する業務へ
Operational Impact
日報の正確性と提出率が向上
GPSログのタイムスタンプを基準にすることで、手書きよりも時間情報の誤差を抑え、日報データの信頼性を高めた。日報作成の半自動化によって提出率も向上している。
Business Impact
分析への活用と、他業種への展開
蓄積した日報データは、請求や業務分析への活用が進んでいる。さらに、日報業務の共通構造を捉えたことで、農業だけでなく、ごみ収集や除雪など、車両を使う他業種への採用にもつながった。