recommendedこんにちは。スクラムに関してオンライン上でお悩み相談を頂きましたので私見を述べたいと思います。プロダクトオーナーと開発者の兼任は可能ですか?注意すべき点はなんですか?さて、この手の議論をする際にまず確認すべきは、スクラムガイドです。スクラムガイドには以下の記述があります。プロダクトオーナープロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。プロダクトバックログアイテムを明確に表現する。ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。開発チームが行う作業の価値を最適化する。し、スクラムチームが次に行う作業を示す。必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの意見を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。開発チームに作業を依頼できるのは、プロダクトオーナーだけである。開発チームもプロダクトオーナー以外から作業依頼を受け付けてはいけない。ここで分かるように、特に兼任については触れられていません。次に書籍「エッセンシャル・スクラム」の中身も確認してみましょう。ここでは、P175に以下の記述があります。1人の人間がプロダクトオーナーと開発チームのメンバーを兼任することはあるが、プロダクトオーナーとスクラムマスターを兼任するのはよくない。この2つの役割は相反しているので、利害関係の衝突を引き起こす可能性がある。いうことは?これらを見ると、兼任について明確に否定されていないことが分かります。いえ、実際にやってみると起こりそうな問題や検討ポイントはいくつもありそうです。それについて見て行きましょう。その1:そもそもプロダクトオーナーが責任をもつことが沢山ある前述のスクラムガイドの記述にもあるとおりプロダクトオーナーが責任を持つことが沢山あります。プロダクトオーナー自身が必ずしもプロダクトバックログアイテムを作らなければいけないわけではありませんが、プロダクトバックログアイテムの優先順位に責任を持ち、各種のスプリント計画会議やスプリントレビューに参加して判断をおこなったり、スプリント中に開発チームからの質問に答えたりする必要があります。このような状況下において、開発の作業も出来るのか?というのが判断ポイントの1つ目です。その2:スプリントが終わらないリスク(コミットメントを守れない)前項の話と関連しますが、キャパシティを計算して大丈夫そうなのでやってみるという判断は当然あります。その計算があっていない場合は、スプリントで選んだアイテムが終わらない可能性があります。結果的に、測定をしてみて妥当なキャパシティを選択していくことにはなりますが、それがずっと続くかどうかも保証はありません。人数が少ないチームほど兼任を検討したいのだと思いますが、人数が少ないほど、開発に使える総キャパシティにおける1人の変動が占める割合が大きくなるため、コミットメントが守れない状況が想定されます。人数が多いチームであれば1人が占める割合は減りますが、そもそもプロダクトオーナーとして活動しなければならない時間は多くなるはずです。その3:トラックNo.1問題による持続性欠如プロダクトオーナーを担う人が、高い開発能力を持っていてエースになっているような場合、プロダクトオーナーとしても開発者としてもボトルネックになる可能性が高いと考えられます。プロダクトに対する質問を受けたり、意思決定をしたり、技術的な質問も受けたり、難易度の高い箇所を担当したりといったことを全てやろうとすると、時間のコントロールが効きません。聞いたケースだと、夜は色々な調整や質問もないので、みんなが帰った後にコードを書いている、みたいな話がありましたが、それを持続するのは相当個人に負担がかかります。その4:どっちの帽子をかぶっているんだ問題スクラムでは、スクラムマスターの帽子をかぶるとか、プロダクトオーナーの帽子をかぶるとか、開発チームの帽子をかぶるとか、そういう言い方で上下関係がなく、あくまで役割が違うことを表します。兼任した場合に悩ましいのは、「いまどちらの帽子をかぶっているの?」という話です。プロダクトオーナーは、開発チームによる見積り作業には参加しませんが、兼任している場合は「開発チームのメンバーとして」見積もるのか、それとも見積りには参加しないのかはっきりさせなければいけません。ここで、もし「開発チームのメンバーの帽子をかぶって」参加した場合でも、「プロダクトオーナーの帽子としては」なるべくスプリントの中で沢山の項目を終わらせたいという欲求が働いたり、自分の出す見積りを過小見積りしてしまったり(もちろんプランニングポーカーであれば全員の議論があるので、その見積りで決まるわけではない)、チームに低い見積りになるよう誘導するといった可能性があります。いわゆる利害相反です。この点に関しては本人に相当の自制心が必要です。利害相反の行動については、スクラムマスターが指摘したり改善を求めることは当然可能ですし、「プロダクトオーナーの帽子をかぶってる人」からの妨害を防ぐように振る舞うのが責任でもあります。結局どうなの?僕自身はまったくできる気がしません。やってみてふりかえりで冷静に判断してプロダクトオーナーを専任に変えられるというのであればやってみても良いと思います。2,797AWSを企業に導入する際に知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用までをまとめた書籍。)定価:$14.99この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。2,138チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍です。カンバンの原則や流れの管理などの入門的な事柄から、サービスクラス、メトリクスの使用、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。カンバンを一から学びたい、組織で使ってみたいと考える方に最適な実践的な入門書です。2,138DevOpsの基本と主にツール面からの解説。2,520スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。1,680スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。吉羽龍太郎(翻訳)出版社:達人出版会定価:500円どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。1,598特集の「強いチームの作り方」を寄稿。ニーズが変化する近年のソフトウェア開発では、既成観念にとらわれない新しいアイデアが不可欠ですが一方で意見の対立がメンバーの衝突を引き起こすことも多くあります。「Vagrantプラグイン」と「Packer」について寄稿。開発者向けカンファレンス「DevelopersSummit」のベストスピーカーを中心とした、100名の執筆陣が書籍を選定・紹介。