CodeZine(コードジン)

特集ページ一覧

プロダクトマネジメントの罠「ビルドトラップ」とは? アジャイルや組織改革の専門家、吉羽龍太郎氏が解説

12月開催ProductZineウェビナー「プロダクトマネジメントの“罠”を回避しよう」レポート

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/02/15 11:00

 プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。

目次

大事なのはアウトプットではなく、アウトカムとインパクト

 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師としても勤務。『SCRUM BOOT CAMP THE BOOK』(翔泳社)をはじめ、専門領域に関する著書も数多く手がけている。

吉羽龍太郎氏
吉羽龍太郎氏

 セッションはまず「アウトプットとは何か」という問いかけから始まった。「アウトプットに似た言葉として、アウトカムやインパクトといった言葉がある。まずこれらの関係性を整理したい」と吉羽氏。

 アウトプットは「人や機械、組織が作ったものの『かたまり』や『量』を示すもの」。プロダクト開発におけるアウトプットとは、リリースしたプロダクトの機能やこなしたタスク、書いたコードの量ということになる。

 アウトカムはアウトプットを受けて発生したものである。例えば顧客が抱える問題の解決や行動の変容を指す。そしてアウトカムから生まれた組織に与えたビジネス的、金銭的な影響をインパクトという。

 つまりプロダクトマネジメントで最も重要なのは「アウトプットではなく、顧客が抱える問題を解決し、ビジネス的な成果、インパクトを与えること。アウトプットに偏重すると、リリース自体をゴールと捉えてしまうことが多くなるので要注意です」と吉羽氏は指摘する。

 ビジネス側が顧客にプロダクトやサービスを提供して、顧客の抱える要望や課題を解決することで、それに見合ったお金がビジネス側に返ってくる。これを書籍『プロダクトマネジメント』の中では、「価値交換システム」と呼んでいる。ユーザーにとっての価値はプロダクトやサービス自体ではなく、そのプロダクトやサービスによってユーザーが抱えている問題やニーズを解決することにあるからだ。

なぜビルドトラップに陥るのか?

 プロダクト開発は「解決したい問題を見つける」→「問題とソリューションの仮説を評価する」→「ソリューションを作る」→「ソリューションを評価する」→「スケールする」という流れをたどる。この流れは一方通行ではなく、例えば「問題とソリューションの仮説」の評価が良くなければ、また問題を見つけるフェーズに戻るといった形で、フェーズをぐるぐる回りながら進んでいく。

 この流れの中で、「ソリューションを作るところやスケールするところに注力することで、典型的なビルドトラップが起こってしまう」と吉羽氏は語る。

 例えばソリューションに注力しすぎると、機能をたくさん作るかもしれない。だが「たくさん機能を作っても、すべての機能が使われるとは限りません」と吉羽氏は言い切る。続けて吉羽氏が示したのは、米の調査機関であるスタンディッシュグループが2002年に実施したアンケート。「少し古いデータですが、このアンケートによると64%の機能がほとんど、もしくは全く使われていないという結果でした」(吉羽氏)

 多くの機能は使われないだけではない。使わない機能はユーザー体験を阻害するためユーザーの満足度も下げることになるという。

Creating Passionate Usersより引用
Creating Passionate Usersより引用

 プロダクト開発において大事なのは、人がほしがるものを作ることなのである。それがわかっていたとしても、プロダクト開発をプロジェクト化して進めていくことで、ビルドトラップに陥ることがあるという。それは「プロジェクトマネジメント型の指標で物事を測るようになるケース」と吉羽氏は言う。

 プロジェクトマネジメントでは期日までに予算通りに作ることが重要になる。プロダクトマネジメントにおける製品価値の検証は継続して行うが、プロジェクトマネジメントの製品価値の検証は事前に行う。また成功の基準もプロダクトマネジメントはビジネス価値の実現だが、プロジェクトマネジメントは予算と期限とスコープの達成である。このようにプロダクトマネジメントとプロジェクトマネジメントでは、指標が大きく異なるため、プロダクト開発に「プロジェクトマネジメント型の指標」を適用した際にはビルドトラップに陥ってしまう。

 ビルドトラップに陥っているかどうかを見分けるにはどうすればよいのか。以下がビルドトラップの兆候であると吉羽氏は7つのケースを挙げた。

  • 約束されたロードマップ、長すぎるバックログ
  • 競合他社との機能比較
  • 必要性のわからない機能
  • 生産性やベロシティに対する課題ばかりが表出
  • ステークホルダーの干渉
  • 権限のないプロダクトチーム、意思のないプロダクトチーム
  • 役に立たないKPI

  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 中村 仁美(ナカムラ ヒトミ)

     大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

バックナンバー

連載:ProductZineウェビナーレポート

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5