スクラムにおけるプロダクトオーナーの特徴
うさぎくんのチームでは、現状はプロダクトオーナー（以下、PO）がマネージャーも兼任している状態でした。スクラムを導入するうえで、責任をもつポイントがどう変わるのかを整理してみました。
POがやるべきこと
- プロダクトの価値を最大化することに責任を持つ
-
プロダクトバックログの管理に責任をもつ
- ユーザーに提供したい価値である、プロダクトバックログアイテム（PBI）の優先順位を管理する
POがやらないほうがいいこと
-
プロジェクトマネジメント
- いつごろなにを提供したいかを決めることはPOの責任だが、それをどのようにつくっていくかは開発者の責任。
- 「要件Aに工数がかかるなら要件Bで」といったトレードオフはしてもいいが、作り方に関して指示をしてはいけない。（意見や疑問を言うのはOK！）作り方を考え、実現するのは開発者の役割。
-
経営層や上司などから言われたことを納得せずに、そのままPBIとして組み込んでしまう
- プロダクトバックログの管理責任はPOにある。人から言われたとおりにPBIを動かすのは、POがプロダクトバックログを管理しているとはいえない。
-
周りの話を聞かずに独断で決めてしまう
- 上とは逆に、PBIの管理責任はPOにあるからという理由から独断で施策を決めてしまう
- スクラムでは、POは特に開発者と密接に連携する。PBIの作成、分割を通じて要件や価値を明確化し、開発者がより価値の高い作業ができるようにする。
スクラムの開発者
うさぎくんのチームは、基本的にエンジニアで構成されています。
エンジニアはもちろんスクラムにおける「開発者」です。しかし、スクラムの「開発者」という言葉の定義は、思っているものよりもっと広いです。
スクラムの開発者は、いわゆるエンジニアだけでなく、デザイナー、リサーチャーなどプロダクトの作成に必要なあらゆる人のことを指します。ひとつのスクラムチームだけで、プロダクトの作成に必要なスキルのすべてが完結できていることが望ましいです。
しかし、開発者が制作に必要なすべてのスキルを得ることはなかなか難しいものです。例えば、デザインまわりはできるだけパーツ化してもらうなどして、スクラムチームだけで起案からリリースまでが完結できるような工夫をしておくことをお勧めします。
スクラムチームだけで完成させることにこだわる理由は、チーム外に頼まないとできないことがふえるほど不確定要因が増え、「いつまでにどんな価値が提供できるか」という見通しが悪くなってしまうという理由もあります。
スクラムにおける開発者がやるべきこと
- 製品の完成に必要なすべてのこと
-
スプリントゴールを成し遂げるために、どのような方法で、どのような作業が必要かを決めること
- スプリントゴール（そのスプリントで達成したい価値）と開発計画がずれそうになった時、やるべきことの見直しと修正を行う
-
タスクが「完了」となった状態はどのようなものであるかを定義し、それを必ず守ること
- これを「完了の定義」とよぶ。チームによって必要な定義は異なるが、チームメンバーのレビューをうけていること、自動テストをパスしていること、といった定義が多い。
スクラムにおける開発者がやらないほうがいいこと
-
他のチームとの兼任
- スクラムチームの仕事だけに集中できる状態が望ましい
-
ほかの開発者が困っていたり、非効率な行いをしたりしているときに助けない
- スクラムの開発者は、個々の存在ではなくひとつの生き物に例えられる。チーム開発で自分だけの利益追求をしても得られるものはない。
- 開発者全体で100％のパフォーマンスが発揮できる状態をめざすことは、プロダクトの価値向上のスピードを上げることに繋がる。
まとめ
今回は、開発者やPOという役割はスクラム導入前でもありましたが、こうしてスクラムにおいてどんな意味をもつ役割なのか整理しました。それぞれの役割を明確化することで、うさぎくんのチームにおけるスクラムマスター、PO、開発者の責任範囲やポジションがはっきりしました。
これは、チームでスクラムを行う上で全員に理解してもらいたい大切なポイントです。
次回は、スクラムイベントのコツ、スクラムのアンチパターンとその打開策など、さらにスクラムを上手に使いこなしていくための方法について解説します。
