スクラムで、プロダクトオーナーとスクラムマスターの役割を組み合わせるべきではないのはなぜですか？
私が取り組んだ従来のプロジェクトでは、プロジェクトマネージャー（大規模なプロジェクトでは、1人の担当者が不在の場合はアソシエイト/代理/アシスタントプロジェクトマネージャーがいる場合があります）が顧客とのコミュニケーションを担当し、プロジェクトを受け取ります。正常性とステータスの更新、スケジュールと予算の決定、プロセスの管理、チームがタスクを完了するために必要なものを確保するなど。
ただし、スクラムでは、これらの責任はプロダクトオーナーとスクラムマスターに分割されます。プロダクトオーナーはお客様の声です。彼らは顧客と直接対話し、ユーザーストーリーを作成し、製品のバックログ、および問題に直面している他のユーザー/顧客を整理して優先順位を付けます。スクラムマスターはプロセスを処理し、ミーティング（見積もりと計画を含む）を監督し、障害を取り除き、プロジェクトの全体的な状態を監視し、必要に応じて調整を行います。
私は複数のソース Wikipediaを含む を読んで、スクラムマスターとプロダクトオーナーの役割は2人の異なる人が持つ必要があると述べています。私は読んだだけでなく、両方の活動が1人の個人によって処理される、成功した「伝統的な」スタイルのプロジェクトに取り組みました。実際、1人から3人がプロジェクト（人事/人事を含む）とプロセスレベルのタスクを担当することは、密接に関係していることが多いため、より理にかなっています。プロセスの変更は、スケジュール、予算、品質、およびその他のプロジェクトレベルの目標に影響を与え、プロジェクトの変更はプロセスに影響を与えます。
なぜスクラムは、これらのアクティビティを2つの役割に分離することを求めているのですか？これには実際にどのような利点がありますか？プロダクトオーナーとスクラムマスターが同じ個人である成功したスクラムプロジェクトに参加した人はいますか？
それらは1人で組み合わせることができ（多くの場合）、これを行うことができます（結局、これに対するルールはありません（結局のところ、そのスクラム））。
[〜＃〜] but [〜＃〜] 2つの役割には競合する事項と議題があるため、違いの責任のバランスを慎重にとる必要があります（また、両方を同時に行うには特別な人が必要です）。 。私は多くの試みを見てきましたが、長期間にわたってそれを引き離すものはほとんどありませんでした（そのストレスの多いポジション）。
SMになるには、POよりも技術的な知識が必要です（開発チームの編成を支援するため）。製品の詳細を製品のバックログからSpringのバックログにプルするには、詳細な知識が必要です（逆効果になる可能性があるため、上位の「n」アイテムをプルできない場合もあります）。
POは、SMよりも方程式のユーザー側をより深く理解する必要があります。これは技術的である必要はありませんが、製品が実際にどのように使用されるか、および顧客が製品を取りたい方向性についての知識が必要です。
両方の役割を果たすことができる人を見つけることができれば、これを防ぐ理由はないと思います。
顧客がPOを一方向に引っ張っているときに問題が発生する可能性があり、開発者に大きな争いを引き起こしています（最初に他のインフラストラクチャを構築する必要があるため）。 SMの仕事は、顧客の気まぐれに従うのではなく、開発者を気まぐれから保護することです。これを客観的に引き離すのは難しい。
私は専門家ではありませんが、スクラムマスターはチームの擁護者/促進者である必要があります。お客さまの声は、お客さまの利益を中心に考えるべきです。スクラムマスターは、チームがスプリントを成功させるために必要なものを手に入れるのを手助けすることについてすべてであるべきです。
また、ほとんどの場合、一度に1人の顧客で作業しているわけではないことに注意してください。プロダクトオーナーは複数の顧客を管理してビジネスのその部分に集中でき、スクラムマスターはプロジェクト開発に集中できます。
多くの人が言ったように、両方の役割には明確な関心がありますが、共通の目標とそれを取得するためのスキルセットは異なります。
同じ人物が開発チームとユーザー/顧客を代表している場合、異議申し立てをする唯一の手段は契約を調べることです。最終的にはこれになるかもしれませんが、同等の権力を持つ双方の代表者が合意を練ることができれば、あなたのほうがよいでしょう。
プロダクトオーナーとスクラムマスターの役割を持つ人々は、2人のランダムプログラマー以上に、相反する欲望、目標、要件、制約を抱えている可能性があります。人間は、相反する目的を等しく評価することができる場合とそうでない場合があり、相反する目的に直面すると、判断を誤ってしまう可能性が高くなります。焦点またはバイアスがわずかに異なる2人の人が一緒に判断すると、同じエラーまたは同じ程度のエラーを起こす可能性が低くなります。
2人は、問題/プロジェクトのそれぞれの異なる側面（たとえば、2つの異なる役割の目標）に焦点を合わせるためにより多くの合計工数を割り当てることもできます。