プロダクトオーナーに入門する

この記事はRecruit Engineers Advent Calendar 2017の5日目の記事です。 4日目はy_kabutoya先輩の環境依存情報をコードから分離するというエントリーでした。

本エントリーは「プロダクトオーナーとは何ぞや」という話の整理になります。 認定プロダクトオーナー研修の内容をもとに、社内有志でディスカッションした内容に基づいております。

前提

スクラムとPO

スクラムとはプロジェクトの現状を把握するためのフレームワークである。

yuzutas0.hatenablog.com

スクラムには3つのロールがある。

• チーム
• スクラムマスター（以下SM）
• プロダクトオーナー（以下PO）

POはROIの最大化に責任を持つロールである。

ROI(投資対効果)

ROIは「R」（＝Return）と「I」（＝Investment）で構成される。

POはROIを最大化するために、あらゆる場面で「R」と「I」を見極めなければならない。

• その意思決定によって得る「R」は何か？
• その意思決定のために費やす「I」は何か？
• 本当にその選択肢が「R」/「I」を最大化するのか？
• もっと良い選択肢はないのか？

ManageとControll

	Return = Manageするもの	Investment = Controllするもの
性質	"結果オーライ"の世界	"厳密な制御"の世界
具体例	"売上を実際に得られるか"は結果を見ないと分からない	売上を得るために"xx円で広告を出稿する"という行動は選べる
難易度	相対的にはInvestよりも取り扱いが困難	相対的にはReturnよりも取り扱いが容易（注：あくまでも相対的には）

POは第一歩としてInvestmentをコントロールできるようにならなければならない。

なお、投資（Investment）は以下のプロセスを経る。

1. 情報収集
2. 選択肢の洗い出し・比較検討
3. 意思決定

特に重要な「情報収集」のために、POは四方八方を歩き回ることになる。

InvestmentのコントロールによるROI最大化

POは他者を誘導することでInvestmentをコントロールする。

• 案件のスコープや受け入れ基準 → チームを誘導する
• 交渉 → ステークホルダーを誘導する

コントロールするからと言って、そのやり方が「一方的な指示出し」になるとは限らない。 「言われたことをやれ」といった押し付けは、チームの反発を招き、逆効果になるだろう。 結果としてROIを悪化させてしまう。それではコントロールできているとは言えない。

いかに相手を尊重するか、いかに影響力を及ぼすか、どうやって誰のどういった行動をコントロールするかが重要となる。

人を動かす 文庫版

チーム

スプリントセレモニーでのROI最大化

スクラムでは定期的なセレモニーによってチームの再計画がなされる。

Whatのセレモニーでは、プロダクトを改良するための再計画を行う。

	スプリントプランニング	スプリントレトロスペクティブ	スプリントレビュー
セレモニーの概要・特徴	- 製品を実現するための短期計画を立てる場 - 会議の内容が重視されるため、往々にして長引きやすい	- 製品の今後についての長期計画を立てる場 - 不確実な将来の話なので内容よりも時間を優先する - 取り扱うトピックはマーケット課題やリリース戦略、技術課題など	- 現在のプロダクトの状況を踏まえて再計画する場 - 実際に動いているプロダクトを全員で触りながらアイデアを出す
POとして求められる観点	長引きがちな会議時間（というInvestmentを減らす）	ロードマップについての合意形成の手間（というInvestmentを減らす）	製品仕様についての合意形成の手間（というInvestmentを減らす）
工夫例	- 簡潔に期待事項・意図を伝える - 手戻りや認識齟齬が生じないように業務背景や利用者の声を伝える - 案件の複雑度を下げるためにスコープを調整する	- 後から「こっちを先にやってよ」と捻じ込まれないようにステークホルダーを同席させる - チームの開発作業を安定化できるように技術課題の詳細を聞き出す - チームが案件意図を理解できるようにマーケットの現状を共有する	- 後から「この挙動はおかしい」と騒ぎ立てられないようにステークホルダーを同席させる - POではなくチームが主体となって製品の改善案を出せるように意見を聞き出す

Howのセレモニーでは、POはゲストの立場で参加して情報収集を行う。

	デイリースクラム	スプリントレトロスペクティブ
POが収集情報をする観点	チームのコンディションを把握する	チームが抱えるムダ・ムラ・ムリを排除する
例	どういうバックログの切り方だとチームは困るか	どういうAC（受け入れ条件）だとレビューの手戻りを減らせるか

なお、方法論はSMの責任範囲となる。 POとしてROIを向上（＝まずはInvestmentを削減）するために何ができるかSMに相談するのが望ましい。

プロダクトバックログでのROI最大化

プロダクトバックログ

POが操作できる唯一のアイテムがプロダクトバックログ（以下PBL）となる。

• PBLとはプロダクトの将来像を描くものである
• プロダクトとはマーケットが抱える課題を解決するものである

	要求 = マーケット課題	要件 = 解決案・改善案
主体者	チーム外 = 受益者	チーム内 = 提供者
特徴	スクラムが直接扱う範囲の外にある	1つのマーケット課題に対して複数の解決案がある（1対nの関係）
注意点	- スクラムはプロジェクトの現状を把握するためのフレームワークであり、マーケットの現状を把握するフレームワークではない - マーケットの現状を把握するフレームワークの例が"リーンスタートアップ"や"デザイン思考"（注：解釈・異論の余地あり）	- 1つ1つの解決案が1つ1つのプロダクトバックログアイテム（以下PBI）に該当する - 1つの解決案に見えるものでも、さらに細かい解決案に分解することができる（PBIは分割可能）

PBI→PBL→プロダクト→Return

スクラムチームはプロダクトによってReturnを得る。

• PBIはタイトルと受け入れ条件（以下AC）で構成される
• PBLは複数のPBIに優先順位を付けることで表現される
• チームはPBLの順番にしたがってPBIを実現する = マーケット課題の解決案を提供する = Returnを生み出す

PBI

POはPBIの書き方を工夫することでスコープを調整し、Investmentをコントロールする。

• タイトルとACを簡潔・具体的・過不足なく記入することで、認識齟齬・合意形成・レビューのコストを下げる
• ACとして禁止事項・制約を設けることで、チームが想定スコープを超えて過剰に開発することを防ぐ

PBIを（POではなく）チームが起票することは、ROI最大化におけるベストプラクティスの1つである。

• チームの考えが分かる = 貴重な情報源となる = Investmentを減らすための判断が正確になる
• チームに納得感・主体性が生まれやすい = 自発的にムダ・ムラ・ムリを軽減できる = Investmentを減らせる
• 施策として実現可能性が極めて高い = Investmentをコントロールしやすい
• 案件創出の負荷が減ることで、POとしてROI最大化（Investmentコントロール）に専念しやすくなる

※また、PO単体ではなくチームとして学びを得ることができるようになるので、不確実なマーケットに対するRの確度が上がるのではないか。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

PBL

PBLを構成するPBIはいずれかの状態になっている。

1. Accepted = ACを満たしている状態（リリース済みを含む）
2. 詳細にタイトルとACが書かれている状態 = チームが着手可能 = 直近2-3スプリントで扱う範囲
3. 粗めにタイトルとACが書かれている状態 = まだ着手できない
4. まだまだ雑な状態 = 当面着手しない

2つ目（詳細なPBI）が増えるほど将来の見通しが立てやすくなり、Investmentのコントロールが容易になる。 そのため、POにとってはPBIをなるべく細かく分けることが重要になる。

チームの成熟度にもよるが「XX機能をユーザーが使えること」といった大雑把な粒度ではなく「XX機能のデモを社内関係者が確認するためのテスト環境を構築してHello Worldを出力すること」といった細かい粒度のPBIに切り出すのが望ましい。

ACとDD

プロダクトは2つの品質を備えることでReturnを生み出す。

	製品品質	テクニカル品質
概要	マーケット課題をどの程度解決するか	製品特性において最低限備えるべき品質
具体例：子供向け野菜カレー	国内の野菜嫌いの小学生のうち10%が月に1回の頻度で食べる → 1日に必要な野菜を摂取している（結果として年間売上xx円）	有害物質が含まれておらず国が定める安全基準を満たしている
リリースとの関係	リリース後に結果が分かる	リリース条件として目標達成が必要となる
施策間の差分	施策によって解決する課題が異なるので指標も変わる	施策横断である程度共通の指標が必要となる
連動する概念	AC（受け入れ条件）	DD（完了の定義）

※注：「完了の定義」（Definition of Done）は「サービスレベル」に依存するのではないか。

yuzutas0.hatenablog.com

リリース戦略でのROI最大化

QCDSの関係性

POはPBLによるS（スコープ）の操作を通してリリースタイミングを調整することになる。 イテレーション開発においてQCDのトレードオフは生じ得ないからだ。

	Q（品質）	C（費用）	D（速度）
特徴	DDで定義されているため固定	- Dを改善する有料ツールなどは採用するのが望ましい - ソフトウェア開発で最も大きいコストになりがちな人件費は安易に増やせない* - 最終的には札束で解決できない問題がボトルネックとなる	- ムダ・ムラ・ムリを排除することで改善される - プロダクトの成長と複雑化に伴って悪化しやすくなる
備考	製品品質は不確実なのでコントロール対象ではない（ACはスコープ調整の手段）	*前提として知識労働における安易な人員増加はS・Q・Dの悪化を招くので非推奨	チームの能力を超えた速度を出そうとすると - 正常系動作の実装を優先して異常系動作の確認を徹底しないといった形でS→Qを犠牲にする - 過剰労働（＝会社から労働者へのCの押し付け）が発生する → 結果として障害・炎上によってDが悪化する。

エクストリームプログラミング

リリースの方程式

以下の方程式から「残スプリント数」を導出すると実現可能なリリース予定が分かる。

リリース対象PBIの完了に必要な残ポイント ≦ 期待されるベロシティ ＊ リリースまでの残スプリント数

Investmentコントロールの打ち手は以下の通り。

• 見積もり精度を上げる
  • PBIを細かく分割する
  • ベロシティを採用する（高精度：単位制約がない、幅を持たせている、実績に基づいている）
• 期待ベロシティを向上させる
  • ムダ・ムラ・ムリを排除する

見えにくいUndone（ムダ・ムラ・ムリ）を排除する

Investmentコントロールの観点では、Undoneの取り扱いに注意しなければいけない。

Undoneとは後回しにされた作業のことだ。 本来やるべきなのに出来ていない作業は少なからず存在する。

• ソフトウェアを扱うスクラムチームの中には、負荷テストや脆弱性検査、依存ライブラリのアップデートを毎回実施できていないところもあるのではないか
• その場合、月に（もしくは四半期に）1回、あるいは大型リリース前に慌ててテストを実施することになりかねない
• 結果：テスト待ちの在庫が溜まる → 作業バッチサイズが肥大化 → ムダ・ムラ・ムリ（手順確認、予期せぬ作業、承認待ち、手戻り）の多発 → リリース計画が乱れやすい → Investmentをコントロールできなくなる

Undoneはチームが主体となって対応することになる。 ここでは狭義のDevOpsプラクティスが活きる。

	チーム	PO
暫定対応	PBIを起票してこまめに実施する	- 安易にリジェクトせずに優先順位を示す - 作業価値を認めて焦らずにじっと待つ
恒久対応	毎回の開発工程に組み込む・自動化する	チームの改善活動を適切に評価する

いずれにせよPOは機能要件を並べてチームを急き立てるだけではInvestmentをコントロールできないということだ。

アイデアを出すことが企画だと思ってる奴は100万回死んでいい 島国大和のド畜生

一方で、技術的課題の解消施策については、安易に優先順位を下げてはならないが、安易に優先順位を上げてもいけない。 ありとあらゆる観点から物事を考慮してROIを判断するのがPOの責務となる。

※注：ソフトウェアエンジニア出身者以外がソフトウェアのPOを担うのは難しいのではないか。

ステークホルダー

クライアントとPOは異なる

クライアントはInvestmentをコントロールしていない。

• クライアントは仕事を依頼する立場である
• クライアントはお金を支払う立場である
• クライアントはBudget（予算）を持つ立場である
• クライアントは結果だけを聞く立場である

あくまでもPOはスクラムチームのInvestmentをコントロールする立場である。

ビジネス部門と開発部門が分かれている場合、ビジネス部門はクライアントであってPOではないことが多い。 その場合は開発チームのリーダーに当たるソフトウェアエンジニアがPOに該当することになるだろう。

チーム以外は全てがマーケット

例えば「上司」をマーケットとして解釈することができる。

• アプリの利用者にとっては役に立たない機能であっても、上司が喜ぶことでBudgetを確保できる（こともある）。
• そのBudgetによってアプリ利用者の役に立つ施策が実現できる（こともある）。これが「R」に該当する。
• だとすると、上司を喜ばせるための機能追加は、必要な投資だと判断できる（こともある）。これが「I」に該当する。

他には、提携先とコラボするためだけのコンテンツ追加や、マーケティング部門がCMで売り出すためだけの目玉機能追加、といった例も同じだ。 世の中に価値を提供するために、一見してプロダクトのためにならないようなことであっても、やらなくてはならないだろう。 つまりは、あらゆる観点を踏まえてROIを判断することが求められるのである。

関係者といかに交渉するか

交渉は「相手との関係が重要か」「取引の中身が重要か」によって4種類に分類される。

	取引の中身が重要である	取引の中身は重要ではない
相手との関係が重要である	Collaboratyion (協調)	Accommodation (譲歩)
相手との関係は重要ではない	Competition (対立)	Avoidance (回避)

特にテクニックが必要となるのは「取引の中身が重要である」ケースだ。

	協調型交渉	対立型交渉
概要・手法	1. 互いの得たい利益と守るべき制約を整理して争点を明らかにする。 2. 「この利益が得られるならこの制約は外せる」といったトレードオフを検討する。 3. 争点を軌道修正してWin-Winの解決策を探る。	- 相手が許容可能なギリギリの線を見極めて落としどころを探る。 - 最初に高い値段を出してから「譲歩します」と言って適正値+αを提示する。 - 相手の主張の根拠となる前提条件を会話の中で崩す。
エピソード	2人の姉妹が1個のオレンジを奪い合っている。一見すると半分に分けるのが早い解決策のように思える。ところが、妹はジャムを作りたいのでオレンジの皮を欲しがっており、姉はジュースを作りたいのでオレンジの身を欲しがっていた。きちんと話し合って、必要な部位を分かち合ったほうが、お互いにオレンジを丸々1個分使うことができるので、利益は大きくなる。	不動産の売買では互いの狙っている金額が事前にあった上で、土地・建物の状態を踏まえて契約価格のすり合わせがなされる。都心湾岸地域は今後値上がりしますよ（なので高い値段で買ってください）という売り手と、豊洲市場やオリンピックが不安ですね（なので安い値段で売ってください）という買い手のぶつかり合いになる。

なお、交渉ゲームで不利にならないためには、以下の2点が最低限必要となる。

• 情報収集の徹底：互いの利害関係を読み取ること。
• BATNAの用意：交渉決裂時の代替手段があること。

だが、これらの準備に掛かる負担（＝Investment）は小さくない。 交渉ゲームにコストを割くこと自体がROI観点で望ましいとは言えないだろう。

そこで「信頼残高」が重要になってくる。 相手から自分への「信頼残高」があれば一部の工程をスキップできる可能性が高まる。 相手が譲歩したり、探り合いなしで協調型交渉をスムーズに開始できる。 ステークホルダーとの協力関係を構築・維持することは、無駄な交渉ゲームを回避するための投資なのである。

ハーバード流交渉術 (知的生きかた文庫)

関係者との協力関係をいかに構築するか

失点を抑えながら、相手に価値を提供し続けることで、徐々に信頼は構築される。

内容だけでなく物事の進め方やコミュニケーションの取り方にも注意を払うことが望ましい。 「20点でいいから1日で持ち込む人間」と「100点にしてから1週間後に持ち込む人間」どちらが信頼を得やすいか。 答えは相手と状況によって変わる。

ソーシャルスタイル理論を軸にして適切な対応を探るのが常套手段の1つだ。

	自己主張（小）	自己主張（大）
感情表現（小）	Analytical	Driving
感情表現（大）	Amiable	Expressive

自己評価や内面性ではなく実際にどのような言動を取っているかで判断する。 心の中では主張を持っていても、質問されるまで自分の意見を言わなければ左側になる。 たとえ感情を大切にしていても「それで結論は？」という聞き方をするなら上側になる。

デザイナーと働くなら知っておきたい4タイプのデザイナー像 | ベイジの社長ブログ

各タイプへの適切な対応方法は以下となる。

	Driving	Expressive	Amiable	Analytical
適切な接し方	論理的に・簡潔に	楽しそうに・熱心に	穏やかに・共感しながら	詳しく・丁寧に
適切な時間の流れ	目標優先・効率的に	迅速に・勢い良く	じっくり考えてもらう	じっくり（ただし納期は厳守）
適切な意思決定の促し方	本人に決めてもらう	インセンティブを示す	リスクや不安を一緒に解消する	納得に必要な材料集めを手伝う

これらは単純化のための四象限なので取っ掛かりに過ぎない。 相手の反応を見ながら迅速・的確に対応方法をチューニングすることが、協力関係を築きInvestmentを削減するための第一歩となる。

苦手なタイプを攻略するソーシャルスタイル仕事術

要するに、人間に対する振る舞いの改善サイクルを回すということだ。

SREや狭義DevOpsにおけるシステム改善と同じだ。 この考え方がなければUndoneは解消できない。 PBLによるInvestコントロールができない。

リーンスタートアップにおけるマーケット仮説検証と同じだ。 この考え方がなければ市場要求に応えられない。 PBLによるReturnマネジメントができない。

同様にPOはチームやステークホルダーを動かすことでROIを最大化するのである。

注意点

以上の話は「スクラム」というフレームワークにおける「PO」というロールについて述べている。

あくまでもフレームワークはフレームワークであり、ロールはロールである点に注意したい。 スクラムというフレームワークを使うことは目的ではない。 POというロールを演じることが正解とは限らない。

むしろPOとしての良し悪しを語ること自体がナンセンスだという場面の方が多いのではないか。 この記事の内容に振り回されて、手段を目的化するようなことは望ましくないだろう。

トドメのポエム

ただ「限られた資源のなかで投資対効果を最大化する」という志向は、経済の基本原理でもある。

• 「家族との団欒」というReturnのために「会社の出世コースを外れる」というInvestment
• 「会社での出世」というReturnのために「家庭でのコミュニケーションが減る」というInvestment
• 「家庭と仕事の両立」というReturnのために「時間とエネルギーを割いて働き方や日々の生活を見直す」というInvestment

チーム活動やプロダクト開発における優先順位付けだけではない。 1人の人間として幸福を追求するならば、意識的であれ無意識であれ、必然的にROIを心のうちで勘定するだろう。 人は誰もが皆、自分の人生のプロダクトオーナーなのだ。

そういった意味では、ROIの最大化に責務を持つ「PO」というロールの思考法を学ぶことは、あらゆる活動を豊かにする一助となるのかもしれない。

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術 (早川書房)

めでたしめでたし。