コミュニケーションギャップを乗り越え、チームで作った「自分たちにあったスクラム」（後編）

全社でアジャイルに取り組んでいるTRI-AD様。
引き続き、プロダクトオーナー（以下PO）の盛野様、スクラムマスター（以下SM）の山西様にお話をうかがいました。

※前編はこちら

## 「なぜやるのか」を考えることで開発スピードが上がった

－－先ほどのお話ですが、コーチが離れて、もとに戻りそうな現場の特徴というのは？

中村：それまで全然できてない現場だったらわりと戻りづらいんですが、成功体験があると戻りやすくなる、また根ざした文化との整合性によっても戻りやすいことはあります。

盛野様（以下敬称略）：このチームは、ウォーターフォール型でずっとやってきた会社から来てるメンバーが多いし、上位層にもウォーターフォールが染み付いている人が多いので、戻りがちな職場だとは思います。

中村：皆さんさすがに「What（何を）」を理解するのは早い。でも最初の頃は「これ、書いてある通りに作ればいいですか？」という発言が出ることもあった。「いや、そうじゃないよね、何でそれをするの？」と聞くと、すぐに「どう作ったらいいですか」とか「こうできてたらいいんですよね」とPOの盛野さんに聞いていた。「そもそも、これは何のためにやるの？」と聞いても「いやそれは盛野さんが……」という返事だったので、30秒で「なぜやるか」を書いて「せーの」でみんなで出してみる、というのを何回かやりました。

山西様（以下敬称略）：今も継続してやっています。全員で一斉に出したりはしていませんが、「なぜやるのか?」は常に議論しています。

盛野：「なぜやるのか?」がないと、今やっている作業だけに集中してしまって、部分最適に陥ってしまうことがよくあります。タスクをこなす上では最善でも、もともとの目的からしたら別にそこまでやる必要ないよね、という内容はけっこうある。そこを意識できていれば、止めるという判断もできます。「そこに時間かけるんだったら、こっちをやって欲しかった」という場面もけっこうありました。

中村：その都度みんなで「何でそうなったと思う？」という話をして、自分たちで「『なぜ』は必要だよね」と見つけて、「じゃあ、どうやったら『なぜ』を見失わずに進めるか」「『なぜ』に近づく発言をしやすくなるか」を、いろいろ実験しながらやった、というのはすごいと思うんですね。

盛野：それができるようになったことが、POと開発者の関係性の改善にもつながった。「なぜ」を考えることによって、視点が一段高くなり、POがどう考えているかに近づいてくるので、許可を求めるスタイルではなく、自分たちがどうしたいかが、意識的に生まれるようになった。それで関係が良くなってきたと思います。

中村：確かに、そのあたりの取り組みは大きなステップだったと思います。

盛野：メンバーが「そういうことか」と理解が進んだおかげで開発スピードが上がる経験もしてます。

－－指示を出して動いてもらうのと、一人ひとりが考えて動いてくれるのとでは、やはり違いますか？

盛野：全然違います。スタート当初は「何やればいいですか？」と聞かれ続けていて「そんなに指示を待たなくても」と、ずっと思っていました。自分の経験から「これぐらいは自分で考えてくれるよな」という私の想定とチームメンバーの意識とのギャップがすごくあった。「自分たちのやりたいことをもっと積極的に提案してくれればいいのにな」と思いながら、全て明示しないと意図と違うものが出来上がってくるので、説明にかなり時間を費やす必要があって、細かい仕様まで書かなきゃいけなくなっていた。それをやっていると私自身も破綻するので、どうすればいいだろう、やり方を変えないといけないかなって、けっこう悩んでいました。

中村：盛野さんは組織的にもチームのリーダーだし、知識やアイディアについてもチームの中でかなりあったんですね。それまでメンバー側には「上司がちゃんと決めて言ってくれるもんだ、それを遂行するのが私たちの責務なんだ」という観念があったので「それは違う」という話を何回もしつつ。

盛野：スキルと過去の経験がそうさせてきたと思って、中村さんとも相談しながら、「なぜやるのか」という目的のところに立ち返るようにすると、みんな考えるようになる。時間はかかりますが、みんな理解してくれるようになった。今では細かい指示をしなくても、思った通り、むしろ私のレベルなんかを超えたものができているので、そういう意味ですごく良かった。すごく重要だと思ってます。

## コミュニケーションギャップの「見える化」

中村：今回は「見える化」をすごく大事にしました。山西さんが目標にどれくらい近づいているかといったことやチームの作業状況などを見える化するプロジェクトのダッシュボードを作ってくれて、こういうことが問題で、今こういう状態で、どういうことを実験してるかが見えるようになりました。何が違うのかをずっとコミュニケーションしながら、どんなギャップがあり、そのギャップはどの程度なのかを自分たちで把握するようにしていました。ギャップの距離さえ分かってしまえばそんなに怖がることはないので。例えば「ちょっと」というとき、その「ちょっと」を、何時間だと思うか、何日と思うか、人によって全然違う、ということを何回もけっこうしつこく言いました。

盛野：その辺のコミュニケーションの質が変わってきた。何が分かっていなくて何が分かっているかを見える化するというところが、すごく良かったなと思います。

例えば、私が「これって、こうするだけだよね？」と言ってしまう。でもメンバーから、「単純作業ではなく工夫もあるから『するだけ』じゃない」と言われたことがありました。私の感覚では、単純作業に落ちている仕事は「やるだけ」で、どれだけ時間がかかってもスタートしたら必ず終わる。そういう選択肢がない仕事は「やるだけの作業」として落としこみ、逆に短い時間でも枝分かれが多い仕事こそが重要だという認識があります。でも「なぜやるのか」と目的を考えられてない人からは、選択肢を自分でコントロールすることなく「どの選択肢をとればいいですか？」と聞かれ、「じゃあここですね。これやります。」となる。結局、選択した後のところがメインになってしまい、その部分に対して「だけ」と言われることにすごくギャップを感じているようでした。

みんなが「なぜやるのか」という目的に立ち帰り、「今この理由でこの目的のためにこの選択肢を選んでいる」と考えてくれるようになってきたことで、選択肢が増えた際の次へのアクションがとても速くなっており、開発効率が向上していると感じています。

－－「これが求められている」と自分で思っているものと、実際に求められているものとのギャップをメンバーが認識していなかった。それがわかって、動けるようになった、ということですか？

盛野：そうです。それが一番大きいところです。

中村：皆さんプログラムを組む、データを解析するといったスキルはあったし、理解度も早かったので、その視座を「盛野さんが指示するから」から少しだけ変えることができれば、チームとしてパフォーマンスが出るだろう、と未来をなんとなく想像していました。

盛野：本当に助かりました。私は選択肢の分岐の部分のことしか言わないで、分岐のない部分は正直、やればいいだけと思うので、そこで会話がかみ合わない。私ひとりだけ変なことを言ってる人みたいになっていました。それが、中村さんが来てくれて、伝え方を学ばしてもらいつつ、私の伝えたいこと、メンバーにPOがどんなことを考えているのか伝える、というのをサポートしていただいた。

中村：盛野さんや山西さんには色々とアドバイスをしたんですが、チームにはあまり言ってないんです。ただ、何回か「盛野さんは本来ビジネスのことを考える責務を負っている人なのに、わざわざ『What』（何を）に関して言わなければいけないとか、フィードバックをたくさんしなければならないということは、チームが期待に応えられていないってこと。それをもうちょっとシリアスにとらえてもいいかもね」みたいな話はしたかもしれません。

－－メンバーとの距離が近くなった感じでしょうか？

盛野：もともとそんなに距離感はあったわけではなかった。仕事上で多少ギャップを感じても、自分的にはコミュニケーション上の距離はあまり感じていなかった。メンバーに聞かないと分からないけど、違うかな?

山西：違いません（笑）

中村：普通に話すし、距離感はとてもいい。それなのにプロジェクトに関する議論の視座のレベルのギャップがあった。不思議で面白いですよね。ミーティング中にすごい激しく激論して、ケンカ別れするのかと思ったら「じゃあランチ行きましょう」って。

盛野：激しい議論のあとにスパッと切って、ご飯行こうって

中村：けろっとみんなでご飯食べに行って……「あ、一緒に行くんや」って。

－－すごくいい関係ですね。

中村：関係性はもとからベースとしてあって、変える必要があったのは仕事やり方の部分だけだったのが、チームが早く変化できた要因かなと思っています。

## 仕事のやり方の「実験」をくりかえす

－－チームが変化したことへの周囲の反応はどうですか？

山西：ポジティブなものもネガティブなものもありました。ネガティブなものから言うと、見える化しながら議論が活発になったので「ちょっとうるさいですよ」と言われたりとか、会議の場所選びが大変だった時期もありました。ポジティブなもので言うと、実際に他のチームのPOにボードだとか、自分たちの改善の手法を見てもらったところ「自分たちのチームでもやりたい」というコメントをいただけたのが良かったなと。

盛野：議論ができるプランニングのやり方を教えてもらったのが私のなかでは一番大きかった。スクラムでは、リファインメント（プロダクトバックログの見直しや整理）とプランニングがあるのですが、プランニングの「プラン」という言葉にちょっととらわれていて、リファインメントは「リファイン（見直し）するだけだから、今のプランをやり直す、見直すだけだと思って重視せずにいた。それを変えて、リファインメントで議論する時間を長めに取るようにしたら、上位層の考えをチームメンバーと共有でき、結果として、プランニングの作業が速くなった。ものすごい大きな変化があった思う。他のチームはまだたぶん、プランニングに時間をかけていると思います。

中村：そういうのって、やってみないと分からないですよね。

盛野：そうなんです。よく中村さんがおっしゃる実験。私たちは技術的には実験をくりかえしますけど、仕事のやり方の面で「実験」と「やり直し」ということをけっこう言ってくださっていた。「とりあえずこの辺のやり方を実験してみましょう」と、うまくリードしてもらって、トライが何度かできた。なかにはうまくいかないものもありましたが、そういうものも振り返りながら「これはいい」「これはダメだ」というのができたのがよかったんじゃないかと。

山西：はじめの頃はチームとしては、失敗することに抵抗があって、そこまで新しい施策にトライできなかった。中村さんから「スクラムという手法自体、そもそも失敗をするために短く期間を切っている、どんどん失敗していいんだよ」と伝えてもらって、そこから失敗に対する抵抗は減ってきたのかな、と思ってます。最近は「とりあえず、これやってみようよ」という感じで、新しいことに対してもどんどん取り組み、改善する習慣がついてきています。

中村：とりあえずやってみて、ちゃんとそれに真摯に向き合えるところが、このチームにはもともとあった。「これダメだ」「私たちには向いてないね」というのは割といい判断をしている。今は山西さんがリードして実験しているので、いいなって思って見ています。

## スクラムマスターがいなくなる未来？

中村：こちらの現場のコーチは2月で終わりで、「いけそうだ」と思っています。4月から私は月1回くらい来て、山西さんと「最近どうすか」みたいなことを話す役割でいいんじゃないですかね。たぶん環境的には、もとに戻りやすいところがあるかもしれませんが、山西さんと盛野さんがここまで理解されているし、チームメンバーみんなが「そういうのはSMに任せればいいや」という発想ではないですよね。なかには「SMがやるもんだ」みたいになる組織があるなかで、この現場はそういうのがないのが安心ですね。

山西：私が休んでるときも今は普通に回っています。

中村：SM自身もチームに要らなくなるのはいいことですね。

山西：SMやPOという役割がなくても、スクラムやアジャイルの開発を行なっていくことができるようになったらいいな、と思っています。一人ひとりが、責任感を持って「なぜやるのか」の部分を考えて「自分はこうしたい」という思いを持てるようになると、そういう役割も不要になってくると思うので、そこを目指していきたいなと思っています。

盛野：チーム体制の見直しがかかったときに継続できるかですね。今は自分たちのチームで上手く回り始めているので、隣りに困ってるチームがある場合は手助けしていき、全体の風土がそうなって来るといいと思っています。

山西：この半年間で、チームの仕事のやり方やPOと開発者の関係性が、だんだんと良くなってきている。中村さんはそこをうまくコントロールしてくださった。本当にありがたかった。中村さんに感謝です。

中村：私は選択肢を増やして欲しいと思っていて、組織がスクラムやるからスクラムをやる、じゃなくて、スクラムという選択肢も手に入れている。昔流のやり方もあるし、スクラムも、別のやり方もある、選択肢が一つでも二つでも増えていくといいじゃないかなと思います。

絶対的な正解ではなく「自分たちにあったスクラム」を求めて試行錯誤してきたチーム。
現場コーチが伴走することによって、目指す未来の形がさらに明確になったようです。

聞き手・編集：曽田照子