Scrum Inc.認定スクラムマスターの局です。
従来の開発（主にウォーターフォール開発）に慣れていたチームが、アジャイル開発（多くはスクラム開発）に取り組むとき、チームのかたちや各自の役割に困惑するという話をよく聞きます。
その理由のひとつとしてプロジェクトをリードするポジションの名称や役割の違いが挙げられますが、なぜ同じシステム開発でも手法によってそうした違いがあるのでしょうか？
目次
プロジェクトマネージャーとプロダクトオーナー、スクラムマスターは別物
従来の開発ではPM（プロジェクトマネージャー）やPL（プロジェクトリーダー）という役割があります。その名の通り、プロジェクトの管理やリード役を担うポジションです。
一方、アジャイルでは従来型の開発とまったく同じ役割を担う管理者はおらず、PO（プロダクトオーナー）やスクラムマスターが重要なポジションを担います。
プロジェクトマネージャーという言葉はある程度一般にも認知されていて、名称からも役割をイメージしやすいので、いちいち説明しなくてもPMの役割をプロジェクトメンバーに理解してもらえるのではないでしょうか。
一方で、プロダクトオーナーやスクラムマスターという言葉は一般的ではなく、アジャイル開発の経験がない限り、それぞれの役割を理解できている人は少ないと思います。
結論からいえば、「従来型の開発でPMがやる仕事＝アジャイルでPOやスクラムマスターがやるべき仕事」ではなく、これらは期待される役割がまったく異なります。
このPMとPO、スクラムマスターが果たすべき役割の違いが開発プロジェクト全体にとってとても大切なのですが、関係者が正しくその違いを理解していないと、次のような問題が起こりがちです。
- POやスクラムマスターを務める人が、本来やるべき仕事ではなく従来型の開発で慣れた役割（PMの仕事）をやろうとしてしまう
- メンバーがPOやスクラムマスターにPMと似た役割を期待してしまう（応じてもらえないと不満に感じる）
全員がPMとPO、スクラムマスターの違いをよく理解せずアジャイル開発（スクラム開発）をはじめてしまったために「POやスクラムマスターって何をやる人なの？」「誰がPMの役割を担うの？」とメンバーが迷ってしまい、チームに悪影響が出てしまうケースも多いようです。
では、具体的にはPMとPO、スクラムマスターにはどんな違いがあるのでしょうか。
次に、もう少し詳しくこれらの違いを見ていきます。
プロジェクトマネージャーとは？
まず、PM（プロジェクトマネージャー）の役割を簡単に整理してみましょう。
最も基本的なPMの役割はプロジェクトのQuality（品質）、Cost（コスト）、Delivery（納期）を管理する・守ることでしょう。
プロジェクトマネジメントに関するノウハウや手法を体系立ててまとめたPMBOK（Project Management Body of Knowledge）では、QCD以外にもリスク管理や要員の管理、コミュニケーションの管理なども対象とされています。
なお、PMBOKではプロジェクト自体を次のように定義しています。
プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施される有期的な業務である
PMBOK
つまり、プロジェクトマネージャーとは、独自のプロダクト、サービス、所産を創造するための業務において、品質やコスト、納期、リスク、要員、コミュニケーションなどを管理するのが主な仕事だといえます。
プロジェクトリーダーとは？
次にPL（プロジェクトリーダー）についてです。
PLというポジションが用意されないプロジェクトも多いようですが、PMとPLの両者がいる場合は、PMよりも責任を負う範囲が限定的で、管理よりも業務の推進に重きを置いてチームをまとめるのがPLの役割だと考えるのが良いと思います。
ここまでは従来の開発で登場するPMやPLの話なので、それぞれの役割は理解しやすいのではないでしょうか。
続いて、本題であるアジャイルのPOやスクラムマスターの役割を見ていきます。
プロダクトオーナーとは？
アジャイル開発の代表的な手法のひとつであるスクラム開発には、その基本的な指針をまとめた公式ガイド「スクラムガイド」というものがあります。
そもそもスクラムとは何かを理解しないと、PO（プロダクトオーナー）やスクラムマスターを理解するのも難しいところはありますが、この記事ではそこまでは踏み込まずにスクラムガイドでPOの役割がどう定義されているのか、要点だけ紹介させていただきます。
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
・プロダクトゴールを策定し、明⽰的に伝える。
・プロダクトバックログアイテムを作成し、明確に伝える。
・プロダクトバックログアイテムを並び替える。
・プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。
いずれの場合も、最終的な責任はプロダクトオーナーが持つ。スクラムガイド
「最終的な責任はプロダクトオーナーが持つ」と説明されているのでPOが非常に重要なポジションであることはわかりますが、責任を持つ対象は「プロダクトの価値を最⼤化すること」です。
従来型の開発でPMが責任を負っていたコストや納期の管理とはだいぶ目的が異なることがわかります。
スクラムマスターとは？
スクラムマスターの定義もスクラムガイドを参照します。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
スクラムマスターは、さまざまな形でスクラムチームを⽀援する。
・⾃⼰管理型で機能横断型のチームメンバーをコーチする。
・スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できる
よう⽀援する。
・スクラムチームの進捗を妨げる障害物を排除するように働きかける。
・すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックス
の制限が守られるようにする。スクラムマスターは、さまざまな形でプロダクトオーナーを⽀援する。
スクラムガイド
「スクラムを確⽴させることの結果に責任を持つ」や「さまざまな形でプロダクトオーナーを⽀援する」という説明から、スクラムマスターも重要なポジションであることがわかりますが、ここにもコストや納期の管理は出てきません。
責任を持つ対象が「スクラム」に限定されていることや、「⾃⼰管理型で機能横断型のチームメンバーをコーチする」という説明のとおり、管理者ではなく⽀援者と呼ぶべき立場であることも重要です。
過程の管理よりも成果物の価値を重視
このように、「従来型開発のPMやPL」と「アジャイル開発のPOとスクラムマスター」は責任を持つ対象も、管理や支援をするべき範囲も全く異なります。
中でも、従来型開発とアジャイル開発でチームのかたちや各自の役割がどう違うのかを知るために重要なポイントは、「誰が管理役を担うのか」だといえます。
POやスクラムマスターは、従来PMが担っていた「プロジェクト進行の管理役」を担うわけではないのです。
では、PMのような「管理役」がいない場合、誰がそこに責任を持つのか？
スクラムでは「チーム全員で管理する」という考えが前提となっており、従来の開発ではPMやPLが担っていたタスクを、みんなが自律的・協調的にやることになっているのです。
その結果、POやスクラムマスターは「管理」ではなく、プロジェクトから生み出される成果物（製品）の「価値を高めること」に重点を置いた活動ができるのです。
とはいえ、従来型の開発でPMやPLを務める人も「価値を高めること」を意識していないわけではありません。特に近年多いデジタルトランスフォーメーション（DX）の文脈にあるプロジェクトでは、従来型のPMやPLというポジションであっても「価値を高めることへの貢献」が期待されることが増えてきていると感じます。
しかし、現実的な問題としては、日々の作業が従来どおりの管理系タスクで埋め尽くされていると、価値を高めるための稼働は割きにくいと言わざるを得ません。
簡単にまとめると
- 「成果物をつくる過程を管理する」のがPMで、「成果物の価値を高める」のがPO
- POはPMのような管理者ではない。スクラムマスターもPMのような管理者ではない。
という違いがあります。
この大きな違いにより、ウォーターフォール開発に慣れていたチームが、PMとPO、スクラムマスターの違いをよく理解せずにアジャイル開発（スクラム開発）に取り組んでしまうと混乱を生んでしまうのです。
成果物の価値を大切にするNCDCのシステム開発
本記事ではPMとPO、スクラムマスターの違いからアジャイル開発（スクラム開発）の特徴を説明してきましたが、決してウォーターフォールよりアジャイルの方が優れているというような主張をしたいわけではありません。
ウォーターフォールの方が適しているプロジェクトもたくさんあるでしょう。
ただ、ITシステムが高度化して「成果物の価値」がより重視されるようになってきた時代において、従来型のPMやPLもQCDを中心とした管理タスクだけを重視していればよいのかどうか、再考する必要はあるかもしません。
その点において、過程の管理よりも成果物の価値を重視し、QCDの管理は全員が自発的に取り組むというスクラムの考え方は、採用する開発手法がなんであれ参考になるのではないでしょうか。
NCDCではウォーターフォールかアジャイルかという手法の違いではなく、「成果物の価値」に拘った開発を行なっています。アプリ開発のご相談などありましたら、お気軽にお問い合せください。
