指示しないリーダー像：プロダクトオーナーは舵取り役：開発チームを改善するためのスクラムTips（6）（2/2 ページ）

　実は、この「プロダクトオーナーの選定」は、スクラムを始めるときに多くのエンジニアが戸惑う問題の1つです。

誰がプロダクトオーナーに向いているか？

●これまでのリーダーがなる

　 一般的なチームリーダーやマネージャは、もともとチー ムのタスクを把握しているでしょうから、プロダクトオー ナーになるのはそう難しくないと思います。

　もしあなたが チームリーダーで、プロダクトオーナーとして振る舞う場 合、チームが自律的に仕事をするという点に注意して、「 指示ではなく情報をチームに提供する」ように心掛けましょう。また、予算確保やレポーティングなど、チームにとって必要なリソースを確保する活動にも力を発揮できると思います。

　常にチームの外側に目を配り、的確な情報をつかみ、最善の選択肢を考え、チームに提供することを心掛けましょう。また、チームの健康に気を配るスクラムマスターをチーム内外から探すと良いでしょう。スクラムマスターについては次回紹介しますが、プロダクトオーナーがスクラムマスター役までこなそうとすると、全権を握る「旧来型のボス」 と同じになってしまいますので、なるべく避けるべきです 。

●顧客側にオーナーになってもらう

　受託開発案件では、顧客の担当者にプロダクトオーナーになってもらう場合もあります。

　もともと、業務要件や、利用者の事情などをよく知っていれば、良いプロダクトバックログが書ける可能性が高いです。一方、開発チームと距離があるため、開発チームの状況や技術的要件をふまえた現実的なバックログにできるかどうか、注意が必要でしょう。

　プロダクト開発では、製品企画担当（プランナー、プロデューサー）がプロダクトオーナーにふさわしいでしょう。一方、プレゼンテーションやパワーポイントの技術に走り、「開発なんて他人事」と考えてしまう人がいることも確かです。

　その場合は、「プログラミング言語は分からなくても、エンジニアは人間」と発想を転換してみましょう。もともと製品企画担当は、顧客や経営層を観察するため、人間観察のスキルが高いはずです。開発チームからも、チームの状況や技術情報をきちんと説明し、優先順位づけを促していくとよいでしょう。製品に対する共通認識を増やすことがポイントです。

情熱にあふれたプロダクトオーナーを探せ

　経験豊富で情熱にあふれたプロダクトオーナーがいれば、チームが生み出す価値が飛躍的に高まります。逆に、プロダクトオーナーが十分な仕事ができなければ、チームにとって最大のボトルネックになってしまいます。

　プロダクトオーナーは素早い判断が必要なため、もし複数人で分担する場合にも、最終的な責任者（チーフ）は1人であるべき、とスクラムでは推奨されています。

成果物（アウトプット）は最少に、成果（アウトカム）を最大に

　プロダクトオーナーに求められる成果は、「少ない手数で最大の成果を得ること」です。

●目標は成功体験、そしてビジネス上の成功

　なるべく多くのソフトウェアを生み出すことが目的ではなく、その先――顧客やエンドユーザーにとって「この製品が欲しかった」「助かった」「仕事が効率的になった」「ビジネスがうまくいった」「また使いたい！」といった成功体験、その結果としてのビジネス上の成功が目標です。

●プロダクトが役立つかを各方面に説明する役割

　そのため、プロダクトオーナーは、その製品がどのようにユーザーにとって役に立つのかを、さまざまな形で説明できる必要があります。

• 投資家や経営者に説明して資金や人を確保する
• 顧客に説明して購入を促す
• エンドユーザーに説明して利用を促す
• 開発チームに説明して、よりニーズに即したソフトウェアの検討を促す

　このように、さまざまなステークホルダに説明を行って、プロダクトの成功に最短距離で向かう能力が求められるのです。

●製品の機能を無駄なくそぎ落としていく役割

　より少ない開発工数で、目標とするプロダクトができるのなら、それ以上の工数はムダです。

　最低限利用できる、販売やベータ版など当初の目的を達せられる最低限の機能を持った製品を、MVP（Minimal Viable Product : 最低限生存可能な製品）といいます。

　そこに向かって、製品の機能をそぎ落としていくのも、優れたプロダクトオーナーのスキルです。MVPな製品がうまく行くことが確認できたなら、さらに追加の価値をリリースして製品を育てていきます。

　次回は、スクラムマスターについて説明します。