スクラムでは、プロダクトオーナーとスクラムマスターの役割を組み合わせてはならないのはなぜですか？

私が取り組んできたより伝統的なプロジェクトでは、プロジェクトマネージャー（および、大規模なプロジェクトでは、1人の担当者が利用できない場合、アソシエイト/代理/アシスタントのプロジェクトマネージャーが存在する可能性があります）は、プロジェクトと顧客とのコミュニケーションの責任者ですヘルスとステータスの更新、スケジューリングと予算の決定、プロセスの管理、チームがタスクを完了するために必要なものを確保するなど。

ただし、スクラムでは、これらの責任はプロダクトオーナーとスクラムマスターの間で分割されます。製品所有者は顧客の声です。顧客と直接やり取りし、ユーザーストーリーを作成し、製品バックログやその他のユーザー/顧客が直面する問題を整理して優先順位を付けます。ScrumMasterはプロセスを処理し、会議（推定と計画を含む）を監督し、障害を取り除き、プロジェクトの全体的な健全性を監視し、必要に応じて調整します。

Wikipediaを含む複数の情報源で、ScrumMasterとプロダクトオーナーの役割は2人の異なる人物が担うべきだと読みました。私は読んだだけでなく、両方のアクティビティが1人の個人によって処理される、成功した「伝統的な」スタイルのプロジェクトに取り組みました。実際、1人から3人の人々がプロジェクト（人事/人員を含む）とプロセスレベルのタスクを処理する責任があることは、彼らがしばしば手をつないで行くので、より理にかなっています。プロセスの変更は、スケジューリング、予算編成、品質、およびその他のプロジェクトレベルの目標に影響を与え、プロジェクトの変更はプロセスに影響を与えます。

スクラムがこれらのアクティビティを2つの役割に分離する必要があるのはなぜですか？これは実際にどのような利点を提供しますか？プロダクトオーナーとスクラムマスターが同じ個人であるスクラムプロジェクトで成功した人はいますか？

それらは、単一の人によって結合され、実行されることがあります（そしてしばしばそうです）（これに対するルールはありません（結局そのスクラム））。

しかし、あなたは二つの役割が競合すると議題を持っている（と、それは同時に両方を行うことができるように特別な人を取る）として慎重に差責任のバランスを取る必要があります。私は多くの試みを見てきましたが、長期にわたってそれをやってのける人はほとんどいません（ストレスの多い立場です）。

• SMになるには、POよりも技術的な知識が必要です（開発チームの編成を支援するため）。製品のバックログから春のバックログに物事を引き出すには、製品の詳細な知識が必要です（これは逆効果になる可能性があるため、上位の「n」アイテムを引き出すことができない場合があります）。

• POには、SMよりも方程式のユーザー側の理解が必要です。これは技術的なものである必要はありませんが、実際の世界で製品がどのように使用されるか、そして顧客が製品を取りたい方向についての知識が必要です。

両方の役割を行える人を見つけることができれば、これを防ぐ理由はわかりません。

POが顧客によって一方向に引っ張られ、開発者に大きな争いを引き起こしているときに問題が発生する可能性があります（他のインフラストラクチャを最初に構築する必要があるため）。SMの仕事は、顧客の気まぐれに従うのではなく、開発者を気まぐれから保護することです。これを客観的に引き離すのは難しいです。

私は専門家ではありませんが、スクラムマスターはチームの擁護者/ファシリテーターになるべきだと思います。顧客の声は、顧客の関心を中心に持つ必要があります。スクラムマスターは、チームがスプリントを成功させるために必要なものを手に入れるのを支援することについてすべてである必要があります。

また、たいていの場合、一度に1人の顧客に取り組んでいないことに留意してください。プロダクトオーナーは複数の顧客を管理し、ビジネスのその部分に集中できます。スクラムマスターはプロジェクト開発に集中できます。

多くの人が言っているように、両方の役割には明確な関心がありますが、それを獲得するための共通の目標と異なるスキルセットがあります。

同じ人が開発チームとユーザー/顧客を代表している場合、あなたが紛争で持っている唯一の頼みは契約を見ることです。最終的にはこうなるかもしれませんが、平等な力を持つ両側の代表者が合意に達することができれば、あなたはより良いです。

プロダクトオーナーとスクラムマスターの役割の人々は、2人のランダムプログラマー以上に相反する欲求、目標、要件、制約を持っている場合があります。人間は、対立する目標を等しく等しく評価することができる場合とできない場合があり、対立する目標に直面した場合に判断を誤る可能性が高くなります。焦点やバイアスがわずかに異なる2人の人は、同じエラーまたは同じ程度のエラーを一緒に犯す可能性が低くなります。

また、2人の人が問題/プロジェクトのそれぞれ異なる側面（2つの異なる役割の目標など）に集中するためにより多くの総工数を割り当てることができます。