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

自動運転のソフトウェア開発を行うトヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント（TRI-AD）様。生産性を最大化するために、全社でアジャイルな開発に取り組んでいます。
「自分たちにあったスクラムとは？」を模索するチームに、ギルドワークスの現場コーチがどう寄り添っていたのか、プロダクトオーナー（以下PO）の盛野様、スクラムマスター（以下SM）の山西様にお話をうかがいました。（肩書きは2020年3月現在のものです）

## 自分たちの現場にあったスクラムの形を求めていた

－－現場コーチを依頼する前には、どんな課題があったのでしょうか。

盛野様（以下敬称略）：会社全体として「スクラムで運用していく」とはじめた研修を受けてから、チームとしてもはじめたのですが、自分たちがやっていることがスクラム的にどうなのか、正解が分からない部分もある状態で「こう応用しちゃって大丈夫かな?」などと迷いながら試行錯誤していました。メンバーも多いですし、自分もPOとして経験がない。開発の効率を上げるためのフレームワークなのに、運用に困って、辛さを感じていました。

山西様（以下敬称略）：研修は受けたので「スクラムってこういうものだよね」という大枠は理解できていました。ただ、細かい知識や実際に自分たちの現場ではどう運用していくかなど、応用の部分が分かっていなかったので、アドバイスいただけたら、と思っていました。社内アンケートでも支援があるなら受けたいという声を上げていました。

中村：もともと知り合いだったCOO虫上さんとの会話のなかで、うまくいっていない部分があると聞いたことが現場コーチとしてこちらにうかがうきっかけでした。

－－知識があってもスクラムを実践するのは難しいものですか？

中村：スクラムガイドに「スクラムは軽量で理解が容易、ただ習得は困難」と書かれています。その通り、集合研修で一日だけ学んで「あとは頑張れ」といわれても経験がないなかで行うのは難しいものです。運用するためには、スクラムの考え方についてディスカッションしたり、他の事例の紹介をする役割をコーチが果たすことがあります。今回はそのパターンでした。

－－現場コーチとして他の人は考えてはいなかったですか？

盛野：実は他のコーチも検討していましたが、「スクラムとはこうだ」というような「型」の話が多かった。しかし私たちは型通りにやるというよりは、それを自分たちに合うように応用していきたい。中村さんは型を踏まえた上で、「その場合なら、こういう手法もあるよ」「他の現場では、このように解決してきた」と、私たちの課題を聞いて型にとらわれない提案をしてくれました。それだけでなく「解決策を決める際は、自分たちが主導で決めていくんだよ」と言ってくれた。私たちと考え方がマッチすると思い、お願いすることにしました。

中村：スクラムもアジャイルも、やることが目的になってしまうと「正しいのかどうか」みたいな議論になる。「なんでスクラムでやってるんですか？そもそもスクラムじゃなくていいじゃないですか？」みたいな話もしましたね。

山西：初回でそういう話もしていましたね。

中村：スクラムを教えてくれる先生なら、私じゃなくてもいい。ですが、最初の段階で山西さん、盛野さんから出たのは「スクラムってどうやるの？」ではなく「私たちがうまくやるために、こういうときどうしたら良いのか」という聞き方をしてくれたので「やれそうや」と思った。これは一緒にやると私も楽しいし、お役に立てるかも、という手応えがありました。

－－自分たちでやろう、というのは、研修等でスクラムを学んでこられたからですか？

山西：スクラムにはもともと、自己組織化を進める、という考え方があるので、そこでの学びがベースにあった。中村さんも当初から「最終的なゴールは現場コーチがいなくてもやれることだ」と言ってくれたので、お互いの認識はあっていたのかなと思います。

－－最初から同じゴールを見ていたんですね。

中村：他の現場ではゴールを決めないことも多いですが、今回は組織でやっているのが見えていたので「早く手離れしたいだろうな」と、わりと早めにゴールを決めました。

－－チームメンバーからの反発は？

山西：なかったですね。

盛野：いろいろ教えてもらうことに対して、みんな「ありがたい」「あれはそういうことだったのか」という反応でした。

## コミュニケーションギャップを埋めていく

－－そういう反応ならば、トラブルも少なく突き進んでいけるような気がするんですが？

盛野：トラブルは、なくはないです。個性の強いメンバーばかりだし、思いを持って進めてくれているので、意見のぶつかりあいはありましたね。例えば、プロダクトの作り方のステップとして、積み上げ式か、先にプロダクトを見える形にするか。リサーチャー寄りの人は積み重ねてやりたいですし、アプリを作ってきた人は「もう早く作ろうよ」とアジャイルに近いプロダクトアウトを目指す、というような考え方の違いなどで、ぶつかることも多かった。

中村：チームメンバーは「自分がやること」は分かってるんですが、「チームでどういう仕事のやり方をするのか」については共通認識がなかったんですよね。メンバーのそれぞれが「自分のこれまでのやり方だったらこうだ」の前提を言わないままに話すから、「チームとしてどんな仕事のやり方をするの？」には、最初の頃は共通認識ができていなかった。「スクラムというフレームワークだったらこういう考え方もできます。他の現場はこんなことをやってます。皆さんだったらどうします？」みたいな話は結構しました。

－－チーム内で共通認識を創り上げていくみたいな作業ですね？

盛野：共通認識もそうですし、グループワークをする上でのコツみたいなところも、色々と教えていただきました。

山西：そもそも、コンフリクトが起きていた理由は、互いの話してることがかみ合わないことでした。うまく擦り合わせるために、ホワイトボードに書くとか、ポストイットに書いて動かしてみるとか、さまざまな方法を試して、みんなの共通認識が取れるようになった。スクラムをやる上でも、普段の仕事でも役に立ったので、全体として良かったと思っています。

中村：盛野さんはチームの上司でもあり、POでもあるんですよね。会社では上司が偉いかも知れませんが、スクラムチームではPOが偉いわけじゃなくて、あくまで方向性を決める責任を持っている。そして開発チームは「どう作るか」に責任を持っている。だからどっちが偉いというのはないですが、盛野さんにそういうつもりはなくても、盛野さんが言うと、どうしても「盛野さんが言うから」みたいなものが出てしまうんですよね。「チームの仕事なんだから、うまくいかなかったときにはみんなの評価につながるんだから、ちょっとは言った方がいいんじゃないか」と。

山西：メンバー側は盛野さんに対して「～してもいいですか？」と許可を求めるような言葉遣いがあった、それによって上下関係ができてしまっていました。

中村：「させてもらっていいですか」って、誰に言ってるの？みたいな。

盛野：「やろうよ」って言ってくれればいいけれど、「やらせてもらっていいですか」という言葉遣いが出てしまう関係でした。

中村：偉い人の指示に従うことで自分の責任を誰かに渡す、押し付けたくなるとか、できなかったときの言い訳にしてしまう心理は、やはりあるんですよね。でもアジャイルは自己組織化をどうしていくかがとても大事で、そこに上下はなく、得手不得手があるだけです。いかに上下関係を少なくするかを意識しながら話をしていました。

盛野：私は言葉遣いから直されました。その辺も私としてはすごく勉強になりました。

中村：チームメンバーが盛野さんに「それはツライです」などと言えていたら、私は何も言わなかったんですが、明らかに腹を立てているのに言わない、というのが見えていた。日本人のよくやる「察してよ」は難しいですよね。

－－言語化してフラットな感じに変えていくことについて、抵抗はなかったですか？

山西：基本的にはなかったと思います。SMがPOにこうしたいと決めていくのではなくて、メンバー全体で「こういう風に変えていくといいよね」と合意を取りながら進めた。特にコンフリクトはなかった。

－－コミュニケーションスタイルを変えることによって、いい方に転がっていったのでしょうか？

盛野：さすがに色々な苦労があって、トントン拍子とは言いがたいです。いきなりは変わらない。もう何年も社会実験を積んでいる人のやり方を変えるには、けっこう時間はかかる。時間をかけて直していくものだということも、今回中村さんとこのプロジェクトでやらせていただいて、実感しました。

山西：その時々には変わったなという感覚はないですが、徐々に変わっていって、振り返ってみると「けっこう変わってきてる」と感じます。

中村：3ヶ月前とか5ヶ月前とかと較べると、たぶん全然違っていますよね。やり方とか会話とか。

## スクラムマスターの孤独

－－山西さんはSMですが、ご自身で志望されたんですか？

山西：2019年3月ぐらいからSMになりましたが、志望したのは、前任のSMのワークスタイルが変わったことがきっかけでした。

盛野：積極的に「やります」と言ってくれ、メンバーみんなで話して「いいんじゃないか」と決めました。

山西：SMは地味な作業を含め、やることがけっこう多いですが、自分のタスクだけじゃなくて「チーム全体として開発がうまく回るように」という方向で考えることができるので、自分の経験としても非常に良かったと思っています。どこにいっても個人でやっていく仕事ってなくて、チームとして開発していくことが多いと思うので、今後にも役に立つと思ってます。

－－SMを育てるというのも今回のポイントでしょうか？

中村：そうですね。山西さんには「なぜその発言をしたのか？」「なぜそういう振る舞いをしたのか?」といった背景や理由などについて会話することが多かったです。さっき言ったように、私が早めに離れるのがゴールの現場だし、しかもその後にもとに戻る可能性があると思ったので。

－－コーチが離れるともとに戻ってしまうことはよくあるんですか？

中村：ありますよ。戻るには色々な理由があって、コーチの腕前が悪かった、ということもあります。また、人や組織は楽な方向へ戻るので、コーチがいなくなったり、スクラムを理解している山西さんたちがいなくなったりして、環境が変わると、文化を保てないことはよくあります。これからは私にかわって山西さんが「そんなんやめようよ」とか「こうしましょうよ」って言っていくと思っていますが。

山西：これまでは私たちがずれてたら中村さんが「ちゃうで」と戻してくれたんですが、これから自分たちでやれるのかなと思います。

中村：山西さんを外に連れていったりもしてましたね。別のクライアントの現場を訪問して意見交換したり、カンファレンスに誘って一緒に参加して来ている人たちと話してもらったりしました。

山西：そうですね。スクラムのイベントに参加して、新しいスクラムやアジャイル開発の手法を学んだり、他の現場に行って、どういう開発手法を取り入れて改善をしているか共有したりして、自分の知識を蓄えています。自分たちが今抱えている課題は他の現場でも起こり得る課題であることが多いので、情報共有をすることで、自分たちの改善にも繋げられると思ってます。

－－他の現場を見ると、視野は変わりますか？

山西：視野が変わるだけでなく「やはり、みんなここは通過するんだな」という安心感もありますね。

中村：SMって孤独なんです。というのは、SMが担う、改善とか人の変化とか、そういったものは、数値化できるものではないので「なんか私の苦労を誰も分かってくれない」という状態になりがちなんですよね。他のSMと交流して「私たちも通った道だ」「それはこうしてる」みたいな話をする機会を意図的に設けています。それが役に立っているなら良かったと思いますね。

－－なかなか同じ苦労を分かちあえる方とは会えないですか？

山西：普段はそんなにないですね。会社のなかでは他にもSMはいますが、チームでは1人です。

－－社内の他のSMの方との交流は？

山西：以前はあまりなかったんですが、最近は少し増えてきています。社内で、自分と同じようにスクラムを学んでいるSMと、特にスクラムに詳しい人たちとが集まって、スクラムの手法を学んだり議論したりする場を設けています。その場づくりも中村さんと一緒にはじめることができて、今後はそこをメインで使っていきたいと思っています。

－－そういう場が複数発生すると、会社全体の雰囲気が変わってきそうですね。

山西：個々の違いはあると思いますが、他のチームでも同じような課題は発生してるので、それの共有ができると開発の効率も上がりますし、会社全体の雰囲気も良くなるかなと思っています。

後編に続きます。

※後編はこちら

聞き手・編集：曽田照子