大事なのはアウトプットではなく、アウトカムとインパクト
吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師としても勤務。『SCRUM BOOT CAMP THE BOOK』（翔泳社）をはじめ、専門領域に関する著書も数多く手がけている。
セッションはまず「アウトプットとは何か」という問いかけから始まった。「アウトプットに似た言葉として、アウトカムやインパクトといった言葉がある。まずこれらの関係性を整理したい」と吉羽氏。
アウトプットは「人や機械、組織が作ったものの『かたまり』や『量』を示すもの」。プロダクト開発におけるアウトプットとは、リリースしたプロダクトの機能やこなしたタスク、書いたコードの量ということになる。
アウトカムはアウトプットを受けて発生したものである。例えば顧客が抱える問題の解決や行動の変容を指す。そしてアウトカムから生まれた組織に与えたビジネス的、金銭的な影響をインパクトという。
つまりプロダクトマネジメントで最も重要なのは「アウトプットではなく、顧客が抱える問題を解決し、ビジネス的な成果、インパクトを与えること。アウトプットに偏重すると、リリース自体をゴールと捉えてしまうことが多くなるので要注意です」と吉羽氏は指摘する。
ビジネス側が顧客にプロダクトやサービスを提供して、顧客の抱える要望や課題を解決することで、それに見合ったお金がビジネス側に返ってくる。これを書籍『プロダクトマネジメント』の中では、「価値交換システム」と呼んでいる。ユーザーにとっての価値はプロダクトやサービス自体ではなく、そのプロダクトやサービスによってユーザーが抱えている問題やニーズを解決することにあるからだ。
なぜビルドトラップに陥るのか？
プロダクト開発は「解決したい問題を見つける」→「問題とソリューションの仮説を評価する」→「ソリューションを作る」→「ソリューションを評価する」→「スケールする」という流れをたどる。この流れは一方通行ではなく、例えば「問題とソリューションの仮説」の評価が良くなければ、また問題を見つけるフェーズに戻るといった形で、フェーズをぐるぐる回りながら進んでいく。
この流れの中で、「ソリューションを作るところやスケールするところに注力することで、典型的なビルドトラップが起こってしまう」と吉羽氏は語る。
例えばソリューションに注力しすぎると、機能をたくさん作るかもしれない。だが「たくさん機能を作っても、すべての機能が使われるとは限りません」と吉羽氏は言い切る。続けて吉羽氏が示したのは、米の調査機関であるスタンディッシュグループが2002年に実施したアンケート。「少し古いデータですが、このアンケートによると64％の機能がほとんど、もしくは全く使われていないという結果でした」（吉羽氏）
多くの機能は使われないだけではない。使わない機能はユーザー体験を阻害するためユーザーの満足度も下げることになるという。
プロダクト開発において大事なのは、人がほしがるものを作ることなのである。それがわかっていたとしても、プロダクト開発をプロジェクト化して進めていくことで、ビルドトラップに陥ることがあるという。それは「プロジェクトマネジメント型の指標で物事を測るようになるケース」と吉羽氏は言う。
プロジェクトマネジメントでは期日までに予算通りに作ることが重要になる。プロダクトマネジメントにおける製品価値の検証は継続して行うが、プロジェクトマネジメントの製品価値の検証は事前に行う。また成功の基準もプロダクトマネジメントはビジネス価値の実現だが、プロジェクトマネジメントは予算と期限とスコープの達成である。このようにプロダクトマネジメントとプロジェクトマネジメントでは、指標が大きく異なるため、プロダクト開発に「プロジェクトマネジメント型の指標」を適用した際にはビルドトラップに陥ってしまう。
ビルドトラップに陥っているかどうかを見分けるにはどうすればよいのか。以下がビルドトラップの兆候であると吉羽氏は7つのケースを挙げた。
- 約束されたロードマップ、長すぎるバックログ
- 競合他社との機能比較
- 必要性のわからない機能
- 生産性やベロシティに対する課題ばかりが表出
- ステークホルダーの干渉
- 権限のないプロダクトチーム、意思のないプロダクトチーム
- 役に立たないKPI
