グロービス社・CPO兼法人開発チームのPMを担当

久津佑介氏:それでは、「チームで盛り上げるファシリテーション」とタイトルに変えて、お話しします。よろしくお願いします。

まず、自己紹介させてください。久津と申します。株式会社グロービスのGlobis Digital Platform学習サービス事業部で、CPO兼法人開発チームのPMをやっています。

担当プロダクトは、「GLOBIS 学び放題」です。定額制の動画学習サービス、ビジネスパーソン向けにビジネススキルを学べるサービスを提供しています。グローバル版「GLOBIS Unlimited」を含めて、この2つのプロダクトを担当しています。

ほかには、プロダクトマネージャーカンファレンス実行委員会もこっそりやっていたりしています。2022年11月2日開催です。今年も無料なのでぜひお越しくださいませ。

ファシリテーション改革によりスプリントレビューを改善した

今日お話ししたいことですね。フィードバックが出てこないスプリントレビューを改善するために、チームでファシリテーション改革に取り組んだ話です。

今回は、スプリントレビューという会議体をピックアップしたので、すべてのミーティングに汎用的に使えるナレッジという感じではないかもしれませんが、今日(の参加者)はPMの方が多いと先ほど(アナウンスが)あり、スプリントレビューに関わる方が多いかなと思うので、参考になれば幸いです。

当時の「ぜんぜんフィードバックが出てこない」という状況のバックグラウンドから説明します。(スライドを示して)今、下のほうにありますが、私たちは、組織の人材育成に使ってもらう法人向けのプロダクトを提供しています。

この機能の大規模リニューアルがプロジェクトでした。少しずつリリースするのではなく、まとめてどんどんリリースするタイプなので、リリースは半年以上先になっていました。

このプロダクトは、法人という特性上、特にカスタマーサクセスやセールスとの連携が重要です。やはり人材育成は、プロダクトだけを提供して終わりというより、カスタマーサクセスの方と一緒に、「どうやって人材育成戦略を立てましょうか」「そのためにプロダクトをどう活用しましょうか」みたいな感じで、ユーザーにとってのカスタマーサクセスもけっこう大事なので、その中でプロダクトのリリースを、そことアラインさせなければいけないという特性が少しあります。

事業チームと開発チームが共通した価値基準を持てていなかった

当時のチームではスクラム開発をやっていて、スプリントレビューは週1回でした。事業チームと開発チームの間にちょっと壁があり、同じ価値基準を持てていない状況でした。

どういうことかというと、なにかを「良い・悪い」と判断する時の根拠となるデータの出どころがちょっと違っていました。例えば私たちは、実際の定量データを見ていたのですが、事業チームはサクセスの生の声を重要視しており、その価値観が100パーセント一致していないというのが当時の状況でした。

その時のスプリントレビューの様子です。その時は、主にPMかスクラムマスターが、「スプリントレビューを始めます」と言って、「今回の機能の目的はこんな感じで、以前のはこんな感じ」と説明していました。

そのあとに、「エンジニアがデモを見せるので、フィードバックをください!」という感じで、エンジニアが説明をしていました。「じゃあ、終わったので感想をください」と言っても、シーン。「じゃあ終わります」と。そんな感じのスプリントレビューがわりと続いていました。

フィードバックが得られない状況が続いた結果、質問があとから来るんですね。指摘も来て、「ああ、手戻りだ!」みたいなことが起こります。ほかにも、1度説明したのに「あれ、それ言いましたっけ?」みたいな感じで忘れられて、結局何度も説明しなきゃいけない状況になったり。

そうすると、パフォーマンスも落ちるし、「なんのためにやっているの?」みたいになって、モチベーションも低下していくと。だんだん参加者も減っていって、最終的に「別にスプリントレビューに間に合わなくてもよくない?」みたいな感じになり、どんどん形骸化していくという、そんな状況でした。

3つの原因によりお通夜状態のスプリントレビューが完成

なぜこうなっていたのか。分析すると、大きく3つありました。1つ目は、きちんとしたことを言わなきゃいけない雰囲気です。要は、心理的ハードルがちょっと高かった。

進行をかなり形式的にやっていたし、先ほど言ったとおり前提情報が違うので、カスタマーサクセスの方々からすると、「あれ、これは何を前提にしゃべっているのかな?」と(なってしまっていた)。「もしかして自分が知らないだけかな」という感じで言いにくいというのがあったかなと思います。

2つ目は、自分事にならないということで、無関心。リリースが半年も先なので、「まあ、別に今言わんでもええか」みたいな、そんな感じ。リリース直前ならたぶんみんな慌てるんですが、「半年後だからまあいいか」というところで無関心というのが2つ目。

3つ目は、淡々と説明しているだけなので単純におもしろくなかった。まあ、オンラインだと内職をしますよね。

これはその時の「ふりかえり」のボードなんですが、上にあるとおり「お通夜状態だった」みたいなコメントがあります。

あと、左下のほうに「もうちょっと遊び心があってもいいかもね」とグルグル丸を書いていますが、ちょっとチームで改善していこうと決めました。

変えたことその1「気軽に意見を言える」雰囲気作り

実際に何をやったかというと、大きく3つあります。変えたことの1つ目は、気軽に意見を言える雰囲気作りです。

まず、「ミーティング内の発言者の母数を増やす」。それまでは総合司会で1人がずっとしゃべって、時々エンジニアがしゃべる感じだったのですが、それを止めて全員でしゃべる雰囲気を作りました。

「では、次は誰々さんからよろしく!」みたいな感じで、どんどんバトンを回していくし、説明中もツッコミやガヤをどんどん入れていく。要は、「もうここはみんながしゃべる場なんだよ」という場作りをしました。

次に「どんなフィードバックもありがたい」「どんなのでもいいんですよ」としつこく伝えました。「どんなのでもいいです」と何度も言って、なにかを言ってもらったら、もうZoomのチャットで「ありがとうございます!」「アザース!」「ガーサス」みたいな感じで、ガンガン鬱陶しいぐらいやっていっています。

たまに前提がずれちゃっているフィードバックはあって、「それは前に言ったけど、伝わっていないな」みたいなのもありますが、それは別途(認識を)合わせる場を設けて、その場で「あ、ちょっとそれは前提が違うので」とかは言わないようにしています。それを言ってしまうと、やはりまた言いにくくなってしまうので、なるべく「ありがとうございます」といったんは受けるようにしています。

3つ目は、「意見を出してほしい人を名指しにする」。機能によって、ちょっとこの人からフィードバックが欲しいという時に、「○○さん、これを聞いといて!」というのをやっています。

リアルだとなんとなく体の向きで「この人に問うてます」というのがわかると思いますが、オンラインだと、これは言わないと絶対に伝わらないと思っています。なので、これはけっこう意識的にやると良いかなと思います。

あとは細かいところで、やはり声を出すのも1個ハードルが高いので、Notionとかにあらかじめテーブルを作っておいて、誰かがしゃべっている間も、思いついたら書いていってもらう。あとからこれを拾って、「ちなみにこれはどういうことですか?」という感じで聞くこともやっています。(スライドを示して)ちなみにこれは、昨日やったやつですね。

これはすごく余談ですが、うちのスクラムマスターは、場を凍らせる特殊能力を持っています。開始直後で、人がどんどん入って来て、アイスブレイクで「バーチャル背景がかわいいね」「いいですね、それ何ですか?」みたいに話している時に、唐突に「私のほうがかわいいけどね!」みたいなことを言うんですよ。そうするとみんな「はっ?」「えっ?」となって、要はシーンとなるわけですね。

そうすると、「あ、凍った、やったぜ!」みたいな感じで爆笑し始めて、「はい、じゃあスプリントレビューを始めます」みたいな。これをけっこうな頻度でやっています。

これは個人的に超すごいなと思っていて、これと比べればなにを言っても恥ずかしくないという雰囲気がちょっとできるんですね(笑)。だいぶキャラでできているので、全員できるかちょっとわかりませんが、うちのスクラムマスターの特殊能力をちょっと紹介しました。

その時のZoomチャットはこんな感じです。「ああ、ごめんごめん、凍った?」みたいな、こんな感じのことを本当にやっています。

ちょっと今のは余談ですが、そんな感じで、とにかく言いやすい雰囲気を作っています。

変えたことその2「参加型スプリントレビュー」

2つ目は、参加型スプリントレビューというところで、参加者に機能を触ってもらうようにしています。

ブレイクアウトルームを作って少人数に分けて、かつ説明するのではなく、お題を出すようにしています。新しく作った機能に対してお題を出して、1ルームごとに必ず開発メンバーを1人入れて、なにかに詰まったら気軽に答えられるようにしています。(スライドを示して)右側が実際のアジェンダですが、なんとか組とかに分かれて、「やることはこれ。やって」と言ってやります。

半ば強制的ですが、これをやると自分事になるし、例えば20人とか大勢の前だと言いづらいけど、4人ぐらいだったら、「ちなみにこれってどういう前提でしたっけ?」みたいなことが、すごく聞きやすいかなと思います。これが2つ目です。

変えたことその3「お祭り感を演出」

3つ目は、おもしろくないイベント感をちょっと払拭するために、お祭り感を出しています。もちろん今は、Googleカレンダーに毎週スケジュールが入っているんですが、必ずその日の午前中にSlackに告知を投げています。

いろいろ伏せているので、わからないかもしれませんが、「こんな機能を今日やりますよ」と(告知しています)。ここに来るとなんかおもしろそうという感じを出して、お祭り感の演出をしています。

また、先ほども言いましたが、その場では、Zoomで「ゴイスー」とか「すごい」とか「うおおおお」とか、こんな感じでガンガン、ガヤをやっていきます。

けっこうこれがきっかけで議論が始まることもあります。それに乗っかって「これって何だっけ?」みたいなものもやはり出てくるので、これもまた1個ハードルを下げる取り組みかなと思います。

スプリントレビューを改善した結果、変わったこと

(改善して)どうなったかというと、メッチャ測定したわけではありませんが、体感としてフィードバックの数は3倍ぐらい増えたかなと思います。漏れていた観点もリリース前に検知できるようになったし、フィードバックをもらえるのはやはり開発チームとしても単純にうれしいと、モチベーションが上がってきました。

「プロトタイプでのレビューもできるように」というのは、スクラムのお作法的に正しいかどうかがわからないのですが、完成前のものでも気軽にフィードバックをもらえるようになったというのは、良いことかなと思います。

また、参加者の数が自然と増えました。ほかのチームから「なんかおもしろいらしいやないかい」と言って来てくれることがあります。

その結果、PMはあまりやることがなくなって、基本ガヤしかやっていません。鬱陶しいのかどうかわかりませんが、最近はスルーされるようになったので、やることがなくて遊ぶということをしています。

というわけで、まとめです。ファシリテーションは必ずしも1人でやる必要はなくて、チームでいい場を作ることも可能だと思います。

なので、もし課題を感じたら、いったん「ふりかえり」でチームに頼ってみるのもいいかなと思っています。場が盛り上がらない原因を突き止めて、1つずつ解決していくことはできると思うので、ご参考になればうれしいです。

最後に、最近採用資料を作ったので、ちょっとこれでググッて見てもらえればなと思います。以上です。ありがとうございました。