見出し画像
Photo by dongmu

「最小工数で最大のアウトカムを生む」ためにできることを考えてみた

vanilla.dev

はじめに

こんにちは。
僕はスクラムにおける開発チームでプロダクトオーナーをしています。
現在勤めている職場では肩書としてのプロダクトマネージャーがいないため、スクラムのプロダクトオーナーとして、越境してプロダクトマネジメントを勉強し実践しています。
プロダクトマネジメント関連の書籍を読んでいると共通して書かれていることがあります。

それは、「プロダクト開発では、アウトプットではなく、アウトカムを生み出せ」ということです。
アウトプットとはあくまで成果物であり、その成果物を通して、ユーザーの世界を変えることこそ、開発チームの求めるべきものである、ということです。

突き詰めて考えると、理想なのは、最小工数で最大のアウトカムを出すことです。最小工数で最大のアウトカムを出すためにはどうしたらよいかを考えてみようと思います。

アウトプットありきの考えからの脱却

以前読んだ、O,Reilly の ユーザーストーリーマッピング 第 2 章「作るものを減らすためのプラン」にこう書かれていました。

システム内部の機能を決めるためには、
まずシステムの外側で起きてほしいことを考えよ。

Jeff Patton (2015). ユーザーストーリーマッピング
O,Reilly

まさに上記の通りで、開発チームが自分たちが作る機能自体にフォーカスするのではなく、ユーザーが触れて、体験する実際の成果に目を向けるのにシフトできるかが 1 番の鍵かなと思います。
アウトプット（= 機能）ではなく、アウトカム（= ユーザーに提供したい実際の成果）から考えるところから始めるべきです。

例えば、「分析レポートを作る」というアウトプットではなく、「データを視覚的に一目でわかるようにしたい」というアウトカムから考え始めた場合、折れ線グラフで表示させようとか、円グラフで表示させようといった具体的な機能について考えが思い浮かびます。これらは手段の一つですが、それより良い方法が見つかるかもしれません。
大事なのは、機能それ自体を作ることではなく、価値をどう提供すべきかの手段について考えられるようになることです。

ユーザーストーリーを明確に伝える

ユーザーストーリーとは、「誰が」「なぜ」「何をしたいのか」という形でユーザーの要求を整理するものですが、このユーザーストーリーを開発チーム全員が理解できているかが大切だと考えます。
プロダクトオーナーとして、開発チームへプロダクトバックログで達成したいこと、このバックログがなぜ必要なのかを理解してもらうために、ユーザーストーリーの書きぶりや正しく伝えるように意識しています。
このバックログを達成することでだれが喜ぶのか、誰が今何に苦しんでいるのかを明確に伝える努力をしています。

開発チームを早い段階で議論に巻き込む

以前は、ステークホルダーと会話して、決めた内容を開発チームへ受け渡す、みたいなフローで仕事をしていましたが、どうやらこれは間違っていたことに気づきました。
最近では、開発チームを早い段階から議論に巻き込むようにしています。

直近読んだ本で、上記のヒントになったことを列挙します。


いいなと思ったら応援しよう！