駆け出しSM Stage1:ファシリテーション
これは豆蔵デベロッパーサイトアドベントカレンダー2023第15日目の記事です。
はじめに
#ご無沙汰しております。駆け出しスクラムマスター(以下、SM) 亀井です。
夏のリレー連載2023でも書きましたが、5月にSMデビューしてあるプロジェクトに参画し早7カ月が経ちました。
今回もありがたく執筆の機会を賜りましたので、初めてSMとして参画したプロジェクトで私がぶち当たった壁「ファシリテーション」でのつまずきと打開策をご紹介したいと思います。
プロジェクトに参画してSMデビュー!
#SMになる!と宣言して早1カ月でご縁があり、あるプロジェクトにSMとして参画することになりました。
プロジェクトの概要は以下のとおりです。
・大規模スクラム「LeSS」を採用
・基本オンライン勤務
・1Sprintは1週間
・木曜午後にSprintPlanning
・毎朝デイリースクラム実施
・1週間のうち3回リファインメントを実施(金、月、水)
・水曜夕方にSprintReview
・木曜午前にふりかえり
LeSSとは、1つのDevチームで行うスクラムをスケールアップしたフレームワークです。
LeSSの場合、1つのDevチームにつきDevは8名までで、最大8チームまで擁することができるとされています。
スクラムと同じなのは以下のことが例に挙げられます。
・1つのプロダクトバックログ
・1人のPO(プロダクトオーナー)
・1つのSprint
逆に、スクラムと違う点としては以下のようなものがあります。
・SprintPlanning・デイリースクラム・ふりかえりは全体と各チームごとの2本だてとなっている
LeSSの詳細はこちらをどうぞご覧ください。
そのプロジェクトは、 私が参画した5月時点では次のようなスクラムチームの編成でした。
・Dev(開発者):各5人ほどの3チーム(計17人)
・PO:POと各チームのエリアPO5人(計6人)
※本来LeSSはPOが一人だが、多忙のためPOのサポートとして各DevチームのPBIを作成するエリアPOを配置
・SM:既に参画している1人+私(計2人)
→ 合計 24人
PBIとは、プロダクトバックログアイテムのことです。
まず、プロダクトバックログと呼ばれる「プロダクトの実現に必要やアイテムやフィーチャーの優先順位をつけてリスト化したもの」があります。
そのプロダクトバックログに並んだ1つ1つのアイテムやフィーチャーのことが「プロダクトバックログアイテム」です。
プロダクトバックログアイテムには、機能追加やバグ修正が例として挙げられます。
参画した当初はSMが初めてということもあり、既に参画しているベテランSMに指示を得て活動していました。
1Sprintで起こる1週間の時間の流れに慣れつつ、このプロジェクトではどういう雰囲気でスクラムイベントや開発を行っているのか、最初の数SprintはどこかのDevチームに張り付いてひたすら観察の日々でした。
このプロジェクトは1年程前から始まっており、参画している方々は基本的にはスクラムの知見がありある程度成熟しています。
そのため、イベントもSMがサポートとして介入する必要もない状態でした。
スクラムチームにスクラムを理解してもらえるよう支援する必要はなかったので、今までDev目線だったのを改めてSM目線からスクラムでどうより良いプロダクトを作り出すのか、思考の切り替えに集中できました。
だんだんプロジェクトに慣れてきたころ、今までベテランSMが担っていた全体ふりかえりのファシリテーションを一回やってみないか?と私がファシリテーションする機会を頂戴しました。
信じられないくらいファシリテーションで失敗...
#ファシリテーションとは簡単に言うと「ミーティング等話し合いをする場を円滑にすすめること」です。
しかし、今まで10人以上集まって何か決めごとや相談する場で議題に対して会話を発散させたり、でた意見をまとめたりすることをした経験が私はありませんでした。
「ひとまずやってみよう」のチャレンジ精神のもと、見よう見まねでスクラムチームが全員いる1時間の全体ふりかえりのファシリテーションに挑戦したところ、見事に撃沈。
失敗の要因として挙げられるものは以下のとおりでした。
- 各自議論したいともってきたもののうち、重要であったりスクラムチームとして身になるもの順に議論できず時間切れになってしまった
- 貸与されたPCのスペックの都合上オンライン・カメラオフ同士で会話している為、話を振って数秒沈黙が起きると、考え中なのか返答に困っているのか分からなかった
そのため、話題を振り直すこともできず誰かが助け舟を出すまで沈黙が続いた - 議論の当事者となる話を振る相手が分からず、「このことについてどう思いますか?」と話を振ってしまい、聞いている側も誰宛てに問うているか分からず、沈黙が続いた
正直「ああ今日全体ふりかえりがある」とドキドキという音が聞こえそうなほど、当時は緊張していたのを覚えています。
最初の失敗に慄きファシリテーション嫌だなあ...と内心思っていたのは秘密です。
そんな私も全体ふりかえりのファシリテーションをなんだかんだ続けて早5カ月がたった今、最初にあった苦手意識も薄れ、なんとかファシリテーションすることができています。
要は場数を踏むことで失敗と少しの成功を積み重ねることでスキルの向上は図れると思います。
しかし、がむしゃらに場数を踏んでも次はこうしよう、と改善を意識しなければ向上するものもしません。
次は、先ほど挙げた失敗したこと3点についてどう打開していったのかお話ししたいと思います。
失敗の要因への対抗手段
#- 議論したいことが複数個ある場合、どう優先順位をつけるか?
内容や話題数から1時間で全て議論しきれないと判断した場合、全体ふりかえり出席者に会話したい議論に投票をしてもらいました。
投票された数が多いほど出席者の関心が高い話題である、と判断できるので投票数と内容を参考に会話する優先順位をつけていくことができるようになりました。
ちなみに、全ての話題を議論できそうな数であれば、投票による優先順位を特につけることなく順番に話題に触れるようにしています。
- 会話の間に発生する恐怖の沈黙への対処法
ベテランSMからの「話を振った後の沈黙は考え中の時間ととらえる」という金言を得ました。
また、関東圏の人は思った以上に会話のレスポンスがゆっくりということを念頭に置いておいたほうが良い、という助言もいただきました。
私事ですが生まれは関西のため、普通と思っていた会話のテンポは早いものだったのを知ったときはすごく驚きました。
また、オンラインだからこそ発言時だけミュートが外れるため、考え中に出がちな「んー」という言葉が聞こえないのかも、という気づきを得ることもできました。
なので、沈黙が起きた際は数秒待ってみて返事があれば良し、さらに続くのであれば「考え中でしょうか?」と再度投げかけるようにしています。
- 話を振る相手をどう判断するか?
どなたと相談したいことなのか議論したい内容に明記されていれば、その方に振れば良いのですが大体明記はされていません。
その場合は話題の内容が技術や開発環境のことであればDevへ、プロダクトのことであればPOへ、と大体の目星はつけられる、と気づきました。
ただ、振った先が宛先違いだったとしても、誰かが「○○さんなら分かりますか?」や「このことならDevのXXチームが担当していたと思います」とより適切であろう宛先に話を振り直してくれます。
もしも振る相手を間違えたとしても誰もそんなことで怒らないし、と思いつつ場数をふむことで、話題の内容で宛先の見当が大体分かるようにもなってきました。
おわりに
#SMはイベントの司会者ではない、はよく言われる事と思います。
しかし、議論を展開したり論点を整理してまとめたり問題解決に繋げられるよう会話の流れをもっていったり...SMがファシリテーションを担う場面は多いです。
ファシリテーション以前に会話の順序やオンラインだからこそ声のみのやり取りをする中で気を付けるべきポイントは幾つかあるかと思います。
ただ、SMに限らずファシリテーションは磨いていて損はないスキルだと思います。
ちなみにベテランSMにおすすめいただいた書籍「ファシリテーション入門<第2版>」をご紹介します。
ご参考になれば幸いです。
最後まで読んでいただきありがとうございました。