属性だけでは優先順位を決めない
「従業員の少ない会社の管理職」という人物像だけでは、どの機能を最初に作るか決まりません。月末の締め作業、急な欠員、上司への報告など、具体的なきっかけを重ねます。どの場面で今の方法を変えようとしたかを聞いてください。
ジョブを成果の言葉で書く
「ダッシュボードを使いたい」は手段です。「報告前に異常の原因を説明できるようにしたい」は達成したいことです。画面の形を固定しない言い方にすると、通知、レポート、担当者への確認など複数の解決方法を比較できます。
仮の人物像を事実で更新する
年齢や性格を想像で細かく埋めるより、実際の業務、関係者、判断基準、現在の代替手段を記録します。インタビューで共通しない特徴は削除し、例外の利用者を無理に同じ人物像に押し込まないようにします。
要件定義への渡し方
「対象者／発生する場面／達成したいこと／避けたいこと／現在の手段」の五項目を、一つの主要シナリオとして開発チームに渡します。機能の追加依頼が来たら、そのシナリオの達成に必要かで判断します。
参考資料と編集について
- サービスデザイン実践ガイドブック（β版）（内閣官房 情報通信技術（IT）総合戦略室） ↗
- Know Your Customers' "Jobs to Be Done"（Harvard Business Review） ↗
- Jobs to Be Done（Christensen Institute） ↗
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日