プロダクトオーナーに必要な知識と手法

今日はスクラム開発の中の役割のプロダクトオーナーについて語ってみようと思います。

プロダクトオーナーはマネージャではありません。

スケジュールも考えますが、製品の品質として
必要な機能や重要な機能を定義すること
不要な機能や利用頻度の低い機能を開発させないこと
が重要なミッションです。

一番やってはいけないのはどの機能も重要という結論です。
これはどれも重要ではないと言っているのと同じです。
必ず開発する機能は１から順番に優先順をつけることが必要です。
これがなかなか難しく、かなり情報が必要で、判断と決断を何度も迫られる作業です。
開発チームはこの順番通りの開発を行います。
重要でない機能が順番の後になるはずなので、スケジュールどおり行かなくても影響が少ないはずです。
もし、他に大きな影響を与えてしまう遅延が起きてしまったら、それはプロダクトオーナーの責任も大きいです。

そして、もっとも重要なものはプロダクトのビジョンを描くことです。
プロダクトの将来像、理想像、こうなったら市場はこう変わる！ユーザはこんな風に喜んでくれる！
そうやって楽しそうに語る姿を見るからこそ、それを実現するために開発チームはモチベーション高く開発ができます。

必要な機能って何でしょうか？

ユーザやクライアントの要望が多いものは可能性が高いです。
ですが、全ての機能を作っていては開発リソースはとても足りません。
リソースが足りれば開発してよいのでしょうか？
いいえ。多機能なシステムはそのシステムの職人のような人が居なければ使いこなせないものになってしまいます。

必要な機能とはシンプルでユーザが間違うことなくシステムの意義や意図を理解して使うことが出来るシステムです。

そのためには一部のユーザの言うことを聞くのではなく、大多数のユーザが満足するシステムを作る必要があります。

必要な知識

まずはユーザの声です。ユーザの声も重要な情報の１つです。プロダクトオーナーは開発チームの中に閉じこもっていてはいけません。

次に市場です。現在の市場の状況はもちろん、半年後、１年後、将来、どのような変化が起きるのかをイメージするだけの知識が必要です。

これは細かく理解する必要はないですが会計の知識も必要です、市場の変化を見るときのキャッシュフローと心理の関わりや開発チームのリソースとプロダクトの作れるものの限界を理解しながら、そのコストの中で最大の価値を生む機能は何なのかを考える必要があります。壮大な開発項目を作ってもお金が足りずに機能として稼働できない途中のものが出来てもプロダクトとしては価値を生みません。コストとリソースのバランスを見ながら作るべきものを定義する必要があります。

そして、プロダクトのビジョンを開発チームに正しく伝えるための知識が必要になります。どんなにプロダクトの将来ビジョンを正しく伝えることが出来なければ良いものは出来ませんし、開発チームに描いた夢を実現させようという気持ちが乗ることはありません。

プロダクトオーナーの手法

アイデアの手法

• ブレインストーミング
• シックスハット法
• オズボーンのチェックリスト
• KJ法
• マンダラート
• なぜなぜ法 (なぜを繰り返して深く考える)

リサーチ分析

• カスタマージャーニーマップ
• ユーザエクスペリエンスマップ
• ロジカルシンキング
• マインドマップ
• メンタルモデルダイアグラム

伝える手法

• グラフィカルファシリテーション
• 伝え方言い方
• プレゼンテーションの手法 話すスピード 高橋メソッドなど
• コーチング

伝わるUI/UX (デザイナほどではないが使われ方を知っておく)

• 色の表現と特徴
• レイアウトと人の視線
• 伝わるコピー
• デザインの流行り (マテリアルデザイン、フラットマップ）
• 人を引きつける物の動き

プロダクトオーナーとは

プロダクトオーナーは広い知識と情報収集に関する手法やアンテナが必要であり、それを分析し、実現するための方法論を学び、現実のコストやリソースと闘い調整する方法が必要です。
プロダクトオーナーは何の権限もなく、作るのは全て開発チームです。イメージしたプロダクトをうまく実現するために、正しく伝えるための方法を沢山知っていなければなりません。
そして、何が良いものか、悪いものかを見極める感性が必要です。
開発チームのように技術に深く知識を必要しないかわりに、広い知識が必要なのです。
決して思いつきのアイデアを言うだけの役割ではありません！

スクラム認定の講師の中には複数人のプロダクトオーナーが必要だという人も居るくらいです。
カスタマージャーニーマップなどをちゃんと作る時間があるでしょうか？
国内、海外の競合の情報を常に集め、機能を比較しているでしょうか？
常に市場に合わせたプロダクトの機能の優先順を定義できているでしょうか？
常にプロダクトのインパクトのある価値のアイデアを考えているでしょうか？
考えたアイデアを分析して、よりよい実現方法、タイミングを考えているでしょうか？
確かに、片手間では務まらないかもしれません。

プロダクト開発の中で兼務にしてしまうと、残念ながら手を抜いても開発が進めることが出来てしまうものが多いのです。
しかし、問題があった時に作った後に気がついてもダメージが最も大きいものでもあります。

• 作った機能は競合に存在して、競合の機能のほうがいいものだった。
• ニーズがなく市場で使われないものだった。
• ユーザが非常に使いにくい機能だった。

失敗したときにはとても取り返しが付かないものばかりです。

何かを開発している場合には、あらためてプロダクトオーナーの役割を定義してみてはどうでしょうか。