変化を自分たちで作り出す（プロダクト探索）
変化を自分たちで作り出すためには、まず知ることから始めなければなりません。「ユーザー」「チーム」「プロダクト」の状況を捉え直す活動を始めましょう。活動の流れを示します。
最初に、むきなおりを経て「ユーザー」「チーム」「プロダクト」の探索目標を立てます。フレームはOKRを用いると良いでしょう。具体的な目標とその達成条件を、チームで合わせられるからです。探索目標は2つのパターンがあります。一つは状況把握、もう一つは課題解決です。
例えば、ユーザーの状況把握が半年前でストップしているようであれば、まずもって状況把握のアンケート、インタビュー、行動ログ分析から始める必要があるでしょう。一方、プロダクトについてはすでに作りとしてのボトルネックが特定されており、その解消にトライしていく必要があると分かっているならば、OKRにも具体的な課題解決をあげることになります。
いずれにしても、探索に臨むにあたっては、「ユーザー」「チーム」「プロダクト」に関する仮説を立てておきましょう。この3つについてチームがつかんでいる情報がゼロである、ということもかえって珍しいことです。これまでの「分かっていること」をもとに、状況や課題の仮説を立てましょう。この仮説立案には「仮説キャンバス」や「バリューストリームマップ」などを用います（これらのツールについての詳細な説明は割愛します。末尾で紹介する書籍などにあたってください）。
例えば、「ユーザー」に関して言えば、プロダクトのアクティベーションが低下傾向にあるのは、一定のニーズが満たされた後に再度プロダクトを利用しようとするモチベーションに不足が生じているのではないか。「チーム」で言えば、ふりかえりでProblemがあまり代わり映えしなくなっているのは、チーム自体が掲げる目標がイージーなものになってしまっているからではないか。といった具合に、仮説を立てます。
こうした仮説をもとに、具体的にどんな探索活動を行えば良いのかアクションをあげていき、さらにバックログとして整備します。探索活動もプロダクト開発同様にバックログ化することで、開発や運用で採用しているアジャイルなプロセスに乗せられるようにするのが狙いです。探索活動は、これまでの平時に比べると「余計なこと」として目に映るところがあります。「余計なこと」に費やす時間をどう捻出するか？という議論に寄ってしまい、それこそ時間を費やし判断も「探索しない」という易きに流れる可能性があります。
バックログに仕立てられるならば、開発や運用のプロセスを変える必要はなく、ただ、何にどのくらいの時間を割り当てるか、というポートフォリオ的な判断に寄せることができます。例えば、「次のスプリントでは10個のバックログアイテムのうち、2つは探索バックログにあてよう。ただし、その次の次のスプリントでは、また開発にフォーカスしよう」といった調整の動きが可能になります。
探索のコツは、まず1つのバックログをあげるところからです。また、「きちんと考えよう」を言い始めると、探索がそもそも始められず、一切進まなくなってしまいます。「分かっていないこと」を分かるための活動なのです。何をどのくらい探索すると良いのか、といった判断をいくら正確に行おうとしたところで、正解はありません。考えすぎて、立ち止まるくらいなら、一歩でも踏み出したほうがマシです。一歩踏み出せば、明らかに分かることが増えるからです。「踏み出したけど分からなかった」ということも分かったことです。別の方角に踏み出さなければならないと分かったのですから。
アジャイルなプロダクトづくりとは、開発プロセスが単にアジャイルなのかどうかではありません。探索を取り入れ、起きていることを探りに行く。さらには、自分たち自身に変化を意図的に作り出していく。そうした姿勢を織り込んだ営みのことを指すものです。
こうしたアジャイルなプロダクトづくりの参考となるように、『アジャイルなプロダクトづくり～価値探索型のプロダクト開発のはじめかた～』を著しました。皆さんの旅の一助となれば幸いです。
