「100パーセントの力が必要な計画は破綻する」　プロダクトオーナーがチームを醸成するためにできること

POがチームを醸成するためにできること

森一樹氏：よろしくお願いいたします。「プロダクトオーナー（以下、PO）がチームを醸成するためにできること」ということで、ちょっとライトめな話をさせていただこうかなと思っています。

先ほど紹介に預かりましたNRIの森と申します。ふだんはチームファシリテーターとして、ふりかえりだったり、チームを良くすること全般に関して、講演や、アドバイザー、ワークショップなどをやらせていただいております。

POとしては、社内でbitLabsという、アジャイル、スクラムを社内外に展開していく教育コンテンツを作るなど……。

（抱えた子どもがマイクを取ろうとする）

邪魔しないでね（笑）。開発基盤、モノを作るっていうことをやっています。これは内製プロダクトなので、内製プロダクトのPOとしてやらせていただいてます。

遍歴としては、去年からアジャイルをいろいろ始めています。開発メンバー、スクラムマスター、POといろいろ経験しながら、今はPOとスクラムマスターということで兼任しながらやっています。いろいろなアンチパターンも、PO2つを掛け持ちとか死にかけながらもやってきました。

「良いチーム」をどう定義するか

今日お話しすることなのですが、POがチームを醸成するためにできることってなんだろうな、というのをちょっと考えてみたんですね。私自身が開発メンバー、スクラムマスター、POといろいろ経験してきたので、みんなの思いもだいたいわかる。そういうわけで、いろんな失敗談と、それに対してどうやって解決していったのか、というお話ができればいいなと思っています。

じゃあ、「良いチームってなんだろう」って考えたときに、まずは「同じ目標に向かって行ってること」が1番かなと思っています。あとはいろんな人が集まって、「多様性を認め合っていること」。また「良い関係性になっていること」と、あと「チーム独自の文化を作っているということ」も大事かなと。あとはそれで「自立（自律）して動いているということ」が大事なのかなと思ってるんです。

ただ、みんながこの上記の状態を目指そうとしていても、思いのすれ違いはやっぱり生じてしまいます。というのは、ロールが違うことによって視点が違ってしまって、すれ違いが起こってしまったりだとか。あとは失敗が続いてしまうってこともあるのかなと思っています。なので、今日は私がいろいろ経験してきた失敗談をお話していきたいなと。

POと開発メンバーのすれ違い

まずはすれ違いの話ですね。開発メンバーからしてみると、「POはいつも忙しそうで、声かけづらいな」と。POからすると「ビジネスを考えたり、仮説検証したり、やること山積みで忙しいんです」と。ポイントとしては、POがいつも忙し「そう」にしている、というところなんですね。思い込みだったりします。

あとは開発メンバーから、「聞くと『忙しいからあとにして』って、そのタイミングで言われてしまう」と。POは「ちょっと聞いてくるタイミングが悪かったんだよね、ごめんね」というようなことを心で思ってたりするわけですね。

こうすると、どうなってしまうか。「POが何やってるのか見えない、めちゃくちゃ不安です！」だったり、あとPOからすると「開発メンバーの状況がぜんぜん見えてこない。なにも言ってくれない。不安！」ってなるわけですね。

こうしてお互いのことがわからないがゆえに、疑心暗鬼になってしまった……っていうのが実際にありました。このプロダクトのときには失敗して、今POとして私がどう活かしてるか、という話なんですけれども。

「なぜ忙しいのか」をきちんと自己開示していく

まずは自己開示しましょう。POってすごく忙しいと思うんです。どこでなにしてるかとか、1週間のスケジュールは見せられる範囲は全部公開しましょう、っていうふうに思っています。それとステークホルダーとどんな話をしてきたかというのも、できる限りチームに逐一共有する。

あとはチームと一緒にいられるのはいつかだったり、会話できるのはいつかっていうのをちゃんと明らかにしました。そして、忙しいときには「忙しいからあとで」じゃなくて、「こういう理由で忙しいから、何時だったら大丈夫だよ」とか。

あとは「ちょっと忙しいから誰か手伝って」と、自分から声を上げるようにしました。そうして自分が変わることによって、開発メンバーから逐一情報を共有してくれるようになりました。

また、双方の先ほどのギスギスした不安感というのはなくなり、安心感とか信頼感の醸成につながったのかな、と考えています。ですので、自分から自己開示するというのが良いやり方だったのかなと。

100パーセントの力でできる計画を立てがち

もう1個の失敗体験なんですけれども「スプリントが失敗続き」っていう……ちょっとスクラム前提のお話になっちゃいますが。

これは開発者目線です。よく100パーセントの力でできる計画を立てがちなんですね。「1日8時間働けます、8時間×5日間、40時間すべて使ってこの計画ができます！」みたいな計画を立てちゃいがちです。そんなのできるわけないのに。1日の時間をすべて食いつぶす計算ですね。

でも、こうして立てた計画っていうのはだいたい破綻するんですよ。時間をマックスで見積もると、バッファがなければなかなかうまくいかないわけです。時間があればあるだけ消化しちゃうっていう、学生症候群にもなりました。

それがどういうことかというと、余裕がない計画を立てて、スプリントを例えば「40ポイントやろう」と言っていたのに、20ポイントしかできなかった。次の週にその失敗を埋め合わせようと残業をして、さらに疲弊して、どんどん生産性が落ちていって、失敗して自信を失って。最終的には速度が0になっちゃう、っていうこともあったんですね。

「どうしてこうなっちゃったのかな？」ってちょっと考えて。実際に自分がどう取り組んだかというのを、これからお話します。新しいPOとして私が始めたときには、「勇気を出す」ということですね。そういうことをやりました。

どういうことかというと、「ここまでだったら確実にいけるでしょ」っていう、どう考えてもいけるようなラインですね。余裕をかなり持った状態で最初はコミットしてもらう、ということをやりました。

「いや、これしかできないの？」と言いたくなるのをぐっと抑えて、開発チームに勇気を出して委ねる、ということをやりました。そうすると、少量のバックログだけですけれども、「必ずやる」「必ずできる」「絶対できるよね」という自信を開発チームも持ってコミットしてくれるわけです。そうするとどうなるか。成功するわけですね。小さく成功します。

小さな成功体験を積み重ねる

そして成功を連続で体験することによって、自信がついてきます。ここが1番重要だと思ってるんですが、成功すると現状が見えます。失敗すると、「もしかしたらいけたかもしれない」っていう過大見積もりしちゃいがちなんですよ。過大評価。自分だったらいけた、だから次もこういう見積もりをしよう、ってなっちゃうんですね。

でも成功すると、できたことしか見えませんから。だから、それによって現状が見えると。成功して初めて現状が見えやすくなるのかな、と思っています。そして成功することによって、どんどんいろいろチャレンジしよう、って前向きな発想に向かっていって、改善も進みやすくなります。

この積み重ねが、もともとPOが「ここまでくらい出せるとうれしいな」っていう成果の想像を、大きく上回る成果を生んでくれるようになりました。こういうことをやったわけです。

ということで、「POがチームの醸成のためにできること」について。今までの発表でもいろいろ、ビジネスのこととかお話していただきましたが、チームのことも考えたときには、まずは自分からちゃんと自己開示しましょうと。忙しいのはわかってるんですが、やっぱりその「なんで忙しいのか」というのを、チームにもしっかり伝えてあげることが大事なのかなと思っています。

そして、勇気を出して委ねる。最初は不安かもしれない。「これしかできないの？」って言いたくなるかもしれないんですが、でもちゃんと成功体験を積む。そういう経験をどんどん積み重ねることによって、POの想像以上の成果が生まれるのかなと思っています。

本日は発表を聞いていただき、ありがとうございました。

（会場拍手）