マイクロジョブとは何か

マイクロジョブ（Micro Jobs）は、ある特定のサービスにおける体験設計をする際に、時間軸ごとに点在する行動（= ジョブ）を連続的な線として捉えるための基準または思考法です。利用者の心理状態や障壁を連続的に捉えることで、より実際の利用状況にフィットした細やかな設計が可能になります。

この思考法は、僕がサービスデザインをする上で大きな影響を受けている、スタンフォード大学のBJ Foggが提唱するFogg Behavior Modelを土台としています。Behavior Modelは、消費者の行動はMotivation（動機）、Ability（能力や難易度）、Prompts（促す要素）の3つに起因し、いずれかの要素が欠けていたりバランスが悪い場合には行動は起こらない、としたものです。マイクロジョブはこのBehavior Modelをベースに、以下の二点を加え再解釈したものです。

・一連の体験の時間軸の中で連続的に捉える
・Behavior Modelでは内包される要素として登場するReward（報酬）をMotivationを増減させる重要な要素として切り出す

「友人に車で駅まで送ってもらうお願いをする」という日常的な出来事に例えるのであれば、以下のように整理することができます。

🎁 Reward : 後日食事をごちそうする
🙌 Motivation : 食事をおごってもらえる、友人から自分への与信
💀 Ability : 車で送るために使う時間や体力、事前に入れていた予定の調整
👉 Prompts : 自分から友人にお願いのLINEを送る

結果的にAbilityの総量をMotivationの総量が上回り、その状態でPromptsが起これば晴れて車で駅まで送ってもらうことができる、と考えるのがBehavior Modelの基本的な考え方です。そこへRewardによるMotivationの増幅や、数時間後に「帰りの送迎もお願いする」ための連続的な設計を加味するのがマイクロジョブの考え方になります。

実務上の活かしどころとしては、前述の通りサービスの体験設計をする際や、マーケティング訴求の設計で「どんな期待値やきっかけを作れば行動されるか」を体験のゴールから逆算的に設計する際に使用でき、すべて顧客接点における発想の起点として用いることができます。

既存の体験設計フローが抱える課題

体験設計をする際の手法として、ジャーニーマップやサービスブループリントなどがあります。これらは俯瞰的に全体の流れを捉えながら、チーム内での大まかなコンセンサスを取りたい時などに用いられることが多く、その要素を具体的な体験設計やUI設計に活かすには、デザイナーの経験に基づいた仮説や解釈が必要になります。

このデザイナーの個に閉じた解釈は主観的でブラックボックスになりやすく、「なぜユーザーが行動するのか？」という仮説が不透明なまま、もっともらしい画面や遷移設計に落とし込まれているケースが多く、品質を評価しづらいグレーな部分としてチーム内の聖域になりがちです。

これらの体験設計フローの行間にあるブラックボックスを少しでも明確にし、施策の評価やメンバー間の連携をスムーズにする目的でも、マイクロジョブは有効に機能します。例えば、マイクロジョブの共通理解が醸成されているチームでは、こんなコミュニケーションが頻繁に生まれるかもしれません。

また、別の課題として、実際のデザインの現場では以下のようなケースを散見することも多く、これらを解決する手段のひとつとしてもマイクロジョブは有効に作用します。

❌ 個別の体験ごとに閉じた設計をしてしまい、連続した体験としての前後関係が考慮されていない
❌ UIや機能を組み合わせるだけの無機質な設計をしており、利用者の感情の変化が考慮されていない

マイクロジョブの設計

マイクロジョブは前述のBehavior ModelのReward（報酬）、Motivation（動機）、Ability（能力）、Prompts（促す要素）を単一時間軸の最小単位として、それらを時系列で並べて俯瞰できる形に整理します。

チームでマイクロジョブの前提さえ共有されていれば、必ずしも何かしらのドキュメントにアウトプットする必要はありません。仮にドキュメント化する場合の型に定めはありませんが、最低限含めるべき要素としては「時間軸の中でMotivation,Ability,Promptsの3要素を1単位としてプロットされている状態」を表現できていれば充分です。RewardはMotivationの総量を押し上げる必要がある時にのみ含めます。

重要なのは「行動の仮説を立て、連続的な体験設計に落とし込むこと」であり、美しいドキュメントを作ることでは有りません。

実践A : プッシュ通知の許諾ダイアログ

実践的なケースとして、モバイルアプリのプッシュ通知許諾に関わる設計を例に見てみます。まず許諾ダイアログそのものを単一の時間軸で切り取った場合、以下のようなマイクロジョブの構成要素に分けられます。Abilityについてはユーザビリティや心理的なハードルを複合的に加味するため、図上の記載はありません。

次に、時間軸を逆に進む形で、ダイアログより前の体験について考えます。ダイアログ時点で付与している「5000円割引クーポン」というRewardは、それ以前の文脈によってMotivationへの影響が変わるため、いくつかの選択肢を考えることが出来ます。例えば、ダイアログより前に同額のクーポンが付与されているの場合や、すでにRewardを必要としないMotivationの総量が期待できる場合は、敢えてRewardを付与する必要がなく、利用者は期待通りの行動をしてくれると仮定します。逆に、Motivationの総量が足りないと思われる場合には、そのままReward付与を検討します。

当然、金銭報酬をRewardとして付与し続ければ、利用者は行動し続けてくれますが、ROIが合わず事業としては成立しなくなります。そのため、Rewardとしては非金銭報酬を軸に設計し、適切なタイミングで金銭報酬を用いることが、持続的なサービスを作る上で重要な設計指針になってきます（このあたりはまた別記事で書きます）

実践B : ファネル分析への応用

Motivationの総量が一定ラインを下回ると、利用者はサービスの利用意欲が低下しサービスからの離脱につながります。当然、利用者は設計者の期待する次ステップへ進むことはありません。前述のプッシュ通知の例では、受け取るボタンをタップするためのMotivationを作ることができず、そのまま離脱されてしまうケースです。それはつまり、Motivationを醸成する適切な設計が出来ていないということになります。

離脱の考え方は、ファネル分析でドロップ率を見る際のWhy探る手段としてとても有効です。行動仮説と照らし合わせながら、なぜドロップしたのかを思考します。また、離脱が発生したタイミングのみに原因があることは稀で、累積的に増加した負のMotivationが閾値を超えたのが離脱タイミングだった、と考えるのほうが人の心情の変化としては自然です。その場合、対処すべきはそれ以前の体験であり、入り口の時点で間違っている可能性も含めた再設計が必要です。

よくある質問

Q. モチベーションやアビリティは仮説で進めるのか？事前または事後リサーチは行わないか？

チームの状況（メンバーや予算）にもよりますが、基本的には仮説のみで進めます。それは、基本スタンスとして「クイックに高い精度の体験設計をすること」を目的とするため、多くのジョブに対してユーザー心理を検証する目的でのリサーチをすることは、費用対効果が合わないと考えているからです。他方で、体験全体を行動ファネルなどの定量分析で評価することは必ず行い、数字の裏側にあるWhyをマイクロジョブで設計した仮説と並べて検証します。

Q. 設計するにあたり適したドキュメントのフォーマットはありますか？

基本的にドキュメントは作りません。あくまで実戦の中で使う思考法なので、スピードが阻害される冗長なプロセスはなるべく排除します。動機や障壁で構成される塊（点の設計）とそれらが連続した一連の流れ（線の設計）を素早く行うことに重点を置いています

次回予告

企業が求めてやまない「すごい」デザイナーについて、求められている責務や職能、実際の母数の推測、採用する上での勘所あたりを考えてみます。