スクラムマスターとプロダクトオーナーのはなし

おはようございます、こんにちは、こんばんは、tarokenです。
pmconf 2023のKeynoteだけ見れました。

何気なく及川さんがおっしゃった一言
「Googleという会社はデータドリブンなんですけど云々」
なぜこれにハッとしたか分かりませんが、

自分はこれまで”やってみないとわからないなら、とりあえずやるか”みたいな感覚だったことに改めて気づきました。

１週間、２週間でできるモノであれば、とりあえずやってみよう、です。そう、計測可能な何かを設定せずに。

で、１週間後出来上がったものに対して「うん、いい感じだね」という定性MAXな評価をしていることに気づきました。（もちろんいつも、というわけではないですが、２週間以内にできるものは7割型こういうやり方していたと思います）

というわけで、これからは「とりあえずやってみる」ではなく、「仮説を立てて、だいたいこれくらいになるだろうという指標をもうけて、評価していこう」と思いました。

エンジニアリングマネージャーとプロダクトマネージャー

さて本題ですが、これまたpmconfでのKeynoteを見ていて、エンジニアリングマネージャーとプロダクトマネージャーが大事にするものは時に反目する、という内容にぴーんときました。

あるタイミングにおいて、プロダクトマネージャーは「市場や顧客の状況を鑑みると、今このタイミングでこの機能をリリースすることで顧客の感じているペインを解消できるから、開発チームは最優先でこの機能をリリースしてほしい」と思っている一方で、エンジニアリングマネージャーは「エンジニアが技術を深く潜って、より長期的な目線で生産性を向上させるために、今この瞬間は開発生産性を落としてでも経験させる必要がある」ということを思ったとします。

どちらを優先すべきなんでしょう？

プロダクトマネージャー：機能を最優先に作ってほしい
vs
エンジニアリングマネージャーは機能は後回しでエンジニアに何か勉強をしてほしい

多分答えはないんだろうと思います。

一方で、実は私はスクラムマスターとプロダクトオーナーを兼任しているのですが、こういう状況がよく起きます。

プロダクトオーナーの私「マイルストーンを考えたらこの機能はこのスプリントでやりきってほしい」

スクラムマスターの私「チームのモチベーションや技術負債のリファクタをやりたいだろうからプロダクトオーナーと調整できるように支援してみるか」

という状態になります。どちらも「私」です。
結果、「プロダクトオーナーの私はやってほしいけど、スクラムマスターの私としては技術負債がどんな状況か、みんなでディスカッションしてみたらどう？」とかいうわけのわからないことを言い出し、チームは混乱します。

また、プロダクトオーナーとしてWhyやWhatを語り、開発エンジニアたちが実現性に対して後ろ向きな発言が多くなった時にも、強力な「強い思い」を持って開発エンジニアの人と衝突するのですが、それをフォローするスクラムマスターがいないんです。

これはとてつもなく苦しいことですし、かといって開発エンジニアに忖度していいたいことも言えない世の中（ポイズン）になると、プロダクトチームが価値提供に対して直線的に進めなくなってしまいます。

最近はプロダクトオーナーとして過ごすことが多く、スクラムマスターが出てくる時は、プロダクトオーナーが意思決定に絡まない、プロセスの改善であったり、チームがモブしているとき、ディスカッションしている時、というように限定しています。

でもやはりスクラムマスターとプロダクトオーナーはその役割上、大事にするべきポイントが反目することがあるので、兼任はダメです。

たまにイベントに行ったり、記事を読んだりしていると、意気揚々と「スクラムマスターとプロダクトオーナー兼任しています」みたいなものを見ることがありますが、「本当に？それめっちゃ苦しくない？」と思ったりします。だから私は、兼任って使いたくなくて、基本「スクラムマスターです」と名乗っています。

他の兼任はありなの？

じゃあエンジニアとスクラムマスター、エンジニアとプロダクトオーナー、この兼任はありなんでしょうか？

私はなしだと思います。

スクラムマスターはとてつもなく思考するロールだと思っています。だからスクラムイベント以外は観察して思考して、チームがどうしたら自己組織化するのか、常に考えることが必要だと思っています。エンジニアリングをしながら片手間にそのことを考えるのは無理だと思います。というか、スクラムマスターがエンジニアリングしている時点でもう支援の枠から離れています。はい、ぶっちゃけ私はこれを自戒も込めて書いています。

プロダクトオーナーも然り、です。WhyやWhatを思考することは時間も必要ですし、一つ一つ丁寧に仮説と指標を決めて、その結果を検証します。エンジニアリングをしながらやるということは、丁寧さが損なわれ、結果的に顧客への価値提供という部分で劣ってしまうと思います。バランスが良ければまだ可能性はありますが、それができる人はほんの一握りだと感じます（100人プロダクトオーナーがいたら1人くらい）。

いいたいこと

スクラムマスターの役割に集中したい