一つの走行に、複数の作業が含まれる
位置・速度・時刻を見ながら、一つのGPSログを複数の作業へ分割できるようにした。
約300件の要望を、7つの開発テーマへ
シード期のスタートアップで一人目のプロダクトデザイナーとして、顧客から蓄積された約300件の要望と、経営・開発・営業・サポートが持つ構想を整理し、1年間の開発ロードマップを策定した。
優先テーマの一つとなった日報機能では、MVPと開発フェーズを定義した。
- 生の要望約300
- 機会領域16
- MVP候補9
- 開発テーマ7
- 4か月でリリース2機能
Context
開発の優先順位が不明瞭だった
レポサクには「北海道に無人農場を作る」という長期ビジョンがある一方、そこへ近づくための短期的な開発順序は定まっていなかった。
CEO、CTO、開発、営業、サポートが異なる構想を持ち、顧客要望も約300件蓄積していた。緊急度や声の大きさだけで個別要望へ対応すると、開発リソースが分散し、将来の分析や自動化に必要なデータ基盤が後回しになる。
そこで、顧客要望と各部門の構想を同じ粒度で比較し、会社として何に投資するかを決めるロードマップ策定をリードした。
Decision 1 — Roadmap
何に優先投資するか
Structure
散在する要望を、同じ評価軸へ揃える
顧客要望と各部門の構想は、「データ基盤」「便利な画面」「サポート工数」など粒度が異なり、そのままでは比較できなかった。
約300件の要望を16の機会領域へまとめ、対象ユーザー、業務上の変化、事業インパクト、必要なデータ、開発・運用負荷を同じ形式で整理した。
Evaluation
長期ビジョン、ジョブ、機能の関係を整理する
事業の北極星となる長期ビジョンを最上位に置き、その下に顧客が達成したいジョブ、さらにその手段となる機能を配置した。機能名ではなく、実現したい状態を基準に比較することで、似た目的を持つ案の統合や除外が可能になった。
Convergence
9つのMVP候補から7つの開発テーマを選定
9つのアイデアを簡易なプロトタイプで具体化し、手触り感を持って利用場面や運用負荷、実装工数を検討できるようにした。CEO・CTOとのレビューや顧客ヒアリングを通じ、7つの開発テーマと優先順位をロードマップ化した。
最終的な投資判断はCEO・CTOが担い、選定した7つの開発テーマを全体ロードマップへ反映した。
Decision 2 — Daily Report
優先テーマのMVPを定義する
Redefinition
要件定義
7つのテーマの中で、日報機能は、将来の自動化に必要なデータを生み出す基盤として最優先となった。
分析や自動化に必要なのは、「正確」かつ「抜け漏れのない」データを取得できること
01 Discovery
業務観察で課題の解像度を上げる
Context
農業法人の事務所に張り付き、16名の農家さんの実際の日報業務を観察した。
日報は農家さんにとって本来の業務ではなく、一日の作業を終えた後に正確な記録へ時間を割く動機が生まれにくかった。そのため、記載粒度のばらつきや、整合しない記録、提出漏れが発生していた。
Insight
紙をDXするだけでは、正確で抜け漏れのないデータ取得には至らない
Observed
- 一日の行動を記憶から思い出して記入
- 時間の丸め方が人によって異なる
- 提出漏れが頻発、どこが抜けているのかも追い切れない
- 「めんどくせぇ」「覚えてない」などの発話を多数確認
Options
入力負荷を下げ、全員が抜け漏れなく提出できる方法を検討
とにかく入力を簡単にするため、入力のUI自体をLINEや音声入力にしてみるなど幅広く検討した。
Product Roadmap
100件以上の要望から、要件を満たす体験を作る
古いバージョンの日報機能について、社内外からの改善要望は100件を超えていた。
正確で抜け漏れのないデータを取得するために、それらを整理し、現場で実際に全員に使ってもらえる体験設計を行った。
フェーズごとに要件を分け、段階的に事業が成長するようCEO・CTO・CSと優先順位を定義した。
Phase 1: 入力負荷が低くオンボードが容易
GPSデータから、スマートフォンで日報を作成・提出できる。
Phase 1.1: 継続して使える
提出状態、代理提出、修正、ヘルプなど、実運用に必要な体験を整える。
Phase 2: 事業に活かせる
集計、CSV、請求、分析、他業種展開に耐えられるデータ品質へ広げる。
02 Concept
システムが自動で下書きを作り、人がチェックして出すだけ
レポサクは、日報作成に必要なデータ（誰がどの車両で、どこでどのような作業をしたか）を示すGPSデータを取得できる。GPSデータからシステムが日報の下書きを自動生成し、農家さんはそれを承認するだけというシンプルな体験を設計した。
03 Product Structure
現場の例外を、異なる業種でも破綻しない構造へ
例外を機能として足すのではなく、異なる現場を受け止められる共通構造として設計した。
一台の車両に、複数人が乗る
ログを個人へ固定せず、会社全体のデータから自分の作業を選べる構造にした。
GPSデータがない日もある
事務や整備の日も、GPSがある日と同じ導線で手動提出できるようにした。
IMPACT
投資判断の土台とMVPの境界を定め、日報を事業のデータ基盤へ
最終的な投資判断はCEO・CTOが担った。私は、約300件の要望を比較可能な選択肢へ変え、全体ロードマップと、優先テーマである日報のMVPを定義した。
Decision 1 — Roadmap
約300件の要望を、7つの開発テーマと実行順序へ
16の機会領域から7つの開発テーマを選定し、実行順序を合意した。優先2テーマは、策定後4か月以内にリリースされた。要望対応の議論を、会社としての投資判断へ変えた。
Decision 2 — Daily Report MVP
入力負荷を抑え、分析に使える日報データの基盤へ
GPSログから自動生成することで、記憶や時間の丸めに依存していた日報を、記録された事実を確認・修正する業務へ変えた。
「車両を使う現場が、位置と時間から作業記録を作る」という共通構造として設計したため、ごみ収集や除雪など、車両を使う他業種への展開を可能にした。