多くの企業は、処理能力が無限にあるという誤った認識に陥っています。 たくさん働けば、その分たくさん稼ぐことができると信じています。 タイムカードと勤務評価でどれくらい働いているかを測ります。 私たち全員が一生懸命働いているなら、業績は必ずよくなるはずですよね？ そう正当化するのです。 誰もが望むものをすべて納品できれば、すべてがうまくいくでしょう。 企業側は絶えず「どうすればチームの作業がもっと速くなるのか？」と考えています。 残業はその課題を解決するためのデフォルトの方法になります。 解決策は、チームに対して無限に納品し続けるよう圧をかけることだと信じて疑いません。 しかし、価値を高めるためのより良い答えがあるのです。それは最大の効果を得るためにプロダクトオーナーと連携することです。
アジャイル企業は仕事ではなく価値を重視
賢明なアジャイル企業は、仕事ではなく価値に焦点を当てています。 そういった企業は、個人、チーム、または事業の処理能力が無限ではないことを理解しています。 したがって、そういった企業や個人は、より多く働く 代わりに、現在の作業能力で、より多くの価値を生み出します。 速度、ROI、および欠陥率を測定します。 限られた処理能力で価値を最大化できるように、優先順位を付けます。 彼らは効率だけでなく、仕事の有効性に焦点を合わせています。
こういった企業は、「チームが提供している仕事の価値をどのように高めることができるか」ということを、常に考えています。 準備が整っていれば、チームが仕事をこなせるということを理解しています。 彼らが次にする仕事が、最も価値あるものになるようにするには、どうすればいいのでしょうか？
すべてのドルが同じではない
こんなふうに考えてください：すべてのドルが同じではない 。 あなたの事業が１ドル獲得したとして、そのドルを得るために、何かを費やしています。 賃金、材料、生産時間が費やされています。 何ドルかを稼ぐために、20セントを費やしたとします。 80セントの場合もあるでしょう。 つまり、１ドルあたりの購買力は同じでも、その１ドルを得るためのプロセスから得られるビジネスの価値は異なるのです。
最大限に価値を引き上げることは、どのドルを追求するかを選択することです。 これは、あなたが研究または非営利団体であり、ドルが価値の主要な尺度ではない場合でも当てはまります。 あなたが仕えている人々にとってすべての結果に等しく価値があるわけではありません。
プロダクトオーナーは価値最大化の核である
プロダクトオーナーは、チームが生み出す製品の価値を最大限に引き上げるうえで中心的な役割を果たします。 チームが最も価値のあるものを一番最初に提供できるようにするため、プロダクトオーナーはバックログに優先順位を付けます。 プロダクトオーナーは、価値がさまざまな形をとるということも理解しています。
バックログにあるほとんどの項目は、顧客が喜んでお金を払う機能です。 しかし、リスクを軽減するために対処するべき 技術的負債の項目もあります。 テクノロジースタックと最新セキュリティのサポートを保証する計画されたアップグレードもあります。 さらに、テストやデプロイの自動化など、チームの価値を提供する能力を高めるための内部的な改善もあります。
プロダクトオーナーの役割は、組織の価値にとって非常に重要なので、 他の人は、彼らと連携し、彼らを支える方法を理解する必要があります。 プロダクトオーナーと連携して最大の効果を得るということか、どんな組織にとっても不可欠です。
プロダクトオーナーは、 バックログ（ひいてはチームが提供する価値）の優先順位付けに単独で責任を負いますが、これを単独で行うわけではありません。 他の役職が、プロダクトオーナーと最もいい形で関わり合うにはどうしたらいいでしょうか？
スクラムマスター
スクラムマスターは、さまざまな方法でプロダクトオーナーをサポートします。 まず、プロダクトオーナーの役割が、どのようにチームや組織に適合するかについて指導することができます。 また、さまざまな優先順位の付け方（たとえばWSJF＜重み付けされた最短の作業から着手する＞、バリューマトリクスなど）を理解する手助けもできます。
チームの見積もり予測と利用の手助けをすることもできます。 スクラムマスターは、これらの予測を最新の状態に保ち、プロダクトオーナーの作業量を一部軽減することもできます。 スクラムマスターはチームに仕えるリーダーであり、チームにはプロダクトオーナーもいます。
スクラムマスターは、コーチングだけでなく、組織がプロダクトオーナーを最適にサポートする方法を学ぶ手助けもします。 これには、経営陣、開発者、および内部のステークホルダーが含まれます。
スクラムマスターは、チームを守るためにプロダクトオーナーの役割をサポートします。 たとえば、誰かが開発者に作業を要求する場合、スクラムマスターが介入して、チームはバックログから優先順位に従って作業をしていくことを丁寧に伝えます。 そして、バックログにアイテムを追加するための窓口はプロダクトオーナーであることをその人に教えます。 これにより、チームは急な要求に応える必要がなくなります（したがって、スプリントが守られます）。 また、プロダクトオーナーが、情報に基づいた優先順位の決定を下すために、最も多くの情報を得るのにも役立ちます。 プロダクトオーナーの知識やインプットなしに、他からチームにワークフローが流れると、価値を最大化することは困難です。
また、スクラムマスターは、デイリースクラムやレトロスペクティブなど、チームの日々の営みに必ずプロダクトオーナーが参加できるようにします。 経験則として、プロダクトオーナーは一日の半分をチームに、残りの半分をステークホルダーのために費やす必要があります。 プロダクトオーナーの意見は重要であると同時に、他の人の考え方を聞いて認識しておく必要もあります。
最後に、これは意外かもしれませんが、スクラムマスターは、開発者がプロダクトオーナーに反発してもいいということを理解してもらうようにします。 この反発は、チームに過度の負担がかかっていたり、プレッシャーにさらされていたり、あるいは処理能力が無限だという誤った認識からくる場合があります。
彼らはチームがもっと働くように圧をかけたり、納期を早めるために品質を少し低下させたりするかもしれません。 スクラムマスターは、長期的にはこれらのやり方がベロシティを低減させることを知っています。 スクラムマスターは、持続可能なペースを維持し、高品質の製品を提供するために、プロダクトオーナーとのバランサーとして機能します。 システムを「押し」のシステム（チームに作業を強制する）ではなく、「引き」のシステム（チームが、提供できると感じる分の作業を取り込む）とすることで、持続可能なペースを維持できます。 スクラムマスターは、チームが、すべてのメンバーにとって有益な、慎重な協議に基づいた共通理解へと導く会話を促します。
開発者
ここでは、『スクラムガイド』と同じように「開発者」という言葉を使用します。 開発者は、プロダクトオーナーが達成したい価値を実装することで、製品（ソフトウェアである必要はない）を生み出す責任を負います。 つまり、高品質を維持し、技術的負債を低く抑えることで、プロダクトオーナーを助けることにもなります。
高品質の製品は、メンテナンスと将来の作業を容易にします。 これにより、将来、価値を提供するためのコストが削減されます。 チームはまた、プロダクトオーナーが対処する必要のある問題に対する技術的解決策に責任があり、顧客のニーズを満たすための代替方法を提案する場合もあります。
開発者は、プロダクトオーナーが優先順位を付けるために使用する作業の相対的な工数の見積もりを提供しなければなりません。 たとえば、顧客が２つの機能を要求し、両方に対して同じ金額を支払う意思があるとします。 チームが、機能Ｂは機能Ａの半分の労力だと見積もった場合、機能Ｂに、より価値があり（顧客にとっては同じメリットで、労力は少ない）、機能Ａよりも優先する必要があるという分析情報をプロダクトオーナーに提供します。
また、プロダクトオーナーと協力する開発者は、機能に関するスプリント全体を通して協働し、フィードバックを早期かつ頻繁に求めることでフィードバックループを短縮します。 スプリントレビューの時点では、プロダクトオーナーは完了した作業をすでに承認しています。
経営陣
経営陣がプロダクトオーナーをサポートする方法の１つは、彼らの決定を尊重することです。 いつも、全員を満足させる決断を下すことは不可能です。 プロダクトオーナーの決断によっては、経営陣から反対される場合もあります。 プロダクトオーナーの意見を覆さないでください！
経営陣がプロダクトオーナーの意見を何度も覆すということは、プロダクトオーナーの役割である優先順位付けの権限がなくなるということです。 そうなるとプロダクトオーナーは、委員会の代理人になって、複数の人が、一つ一つの優先順位に関するの疑問を見直していくことになります。 プロダクトオーナーが１時間で回答できる疑問でも、チームが回答を受け取れるまでに１週間はかかるようになります。 このような状況では、価値の提供がすべて遅くなります。 多くの場合、彼らに任せて価値提供を高水準に保つのが得策です。 遅延は高くつきます！
常に決定を覆したり、プロダクトオーナーが権限を持たない状況は、運営委員会や変更審査委員会という名前が付いている場合があります。 製品の方向性について話し合うグループがいることは許容されます。 プロダクトオーナーの意思決定がグループを通じて行われたり、グループが行動を指示したりする必要がある場合、１人のプロダクトオーナーの代わりに委員会が存在することになり、同じ遅延コストを支払うことになります。
経営陣はまた、プロダクトオーナーが責任過多にならないようにすることで、彼らを支えます。 プロダクトオーナーは、チームと協働し、顧客と対話し、さまざまな選択肢のある価値を評価する必要があります。 これらはすべて時間のかかることです。 プロダクトオーナーに「もう１つだけちょっとした役割を引き受けさせる」ようなことをして、チームの価値を下げないでください。
経営陣は、チームに直接業務を与えるのではなく、優先順位を付けさせることで、プロダクトオーナーを支えます。 開発者は、誰い給与をもらっているか、知っています。 経営陣の誰かが入ってきて、何かをするように頼んだ場合、彼らは大抵「やります」と言うでしょう。 プロダクトオーナー以外のどこかから作業が与えられたとします（「ファントムワーク」（作業の亡霊）と呼ばれることもあります）。 その場合、プロダクトオーナーは、顧客と組織にとっての価値に基づいて優先順位を付けることはできません。
また、個々の開発者の上にいったい何人の上司がいるのでしょうか？ 層が厚い場合、何人もの上司たちが、彼らにさまざまなことを求めくる可能性があります。 こういった場合では、開発者にとって最後に与えられた要求、最優先になります。 この恣意的な方法でチームの価値に影響を与えたいですか？
ステークホルダー
あなたが社内のステークホルダーだったり、何らかの形で顧客を代表している場合（販売、マーケティングなど）、プロダクトオーナーは間違いなくあなたを必要としています。 プロダクトオーナーは、顧客に最高のサービスを提供する方法、直面する問題、および何が彼らの１日を楽にするかを知りたいと考えています。
ステークホルダーは、プロダクトオーナーと協力して、顧客にとって合理的な期待値を設定。 プロダクトオーナーは、日程とスコープを伝える前に承認する必要があります。 また、ステークホルダーとしてのあなたにとって最優先事項は、他のすべての人にとって同じではないかもしれないことを理解してください。
また、ステークホルダーはチームのスプリントレビューに参加し、率直なフィードバックをする必要があります。 スプリントレビューは、スプリントの作業を検査するための作業セッションです。 機能に関するフィードバックは、バックログに影響します。 これにより、チームは可能な限り最高の製品を顧客に提供できます。
フィードバックは、スプリントレビューに限定する必要はありません。 チームから、まだ作成中のものを見るように求められる場合があります。 フィードバックループが短いほど、最終的なソリューションに到達するためのコストが低くなります。
プロダクトオーナーとの連携：すべての役割が重要です
役割に関係なく、プロダクトオーナーとのやり取りの方法は、価値を最大化する助けになります。 プロダクトオーナーのビジョンと意思決定をサポートすると、驚くようなことが起こる可能性があります。 これらのやり方は習慣になり、コラボレーション文化の一部になります。
限られた処理能力を最大限に活かしたいとお考えですか？ ぜひ ご連絡ください。 評価、トレーニング、コーチング、メンタリングなどのアジャイルサービスでお手伝いいたします。
