エンジニアリングマネージャのためのファシリテーションのコツと帆船のエクササイズ
元エンジニアリングマネージャで、今は人事をやってます。
この記事は、Engineering Manager Advent Calendar 2020 - Qiita の12/6の記事になります。
今でも、エンジニアリングマネージャの人たちと話をしたりするのですが、みんな見ているチームのふりかえりがうまくいってないとか、チームで議論をしていても、議論が浅くなったりとか、いろいろ悩んでいるようなので、エンジニアリングマネージャのチーム運営に役に立つようなファシリテーションのコツを書いてみようと思います。
目次
だめなパターン
コツの話をする前に、まずは、うまく行ってないケースを考えます。
- 議論が空中戦
- 議論が浅い
- 特定の人だけが議論している
議論が空中戦
これは、まー、よく見ます。エンジニアのチームだけじゃなくて、社内の偉い人がいる会議でも普通に起きてます。 特に、リモートワークになったことで、Google meet等でWeb会議をするのですが、最初は、プレゼン資料をベースに 会議をしていたとしても、その後、議論が派生してくると、ほとんど空中戦になる気がします。
空中戦の何が問題かというと、余程議論している人たちのコンテキストやスキルが共通していない限りは、議論の前提や、考えていることが一致していません。同じキーワードで話をしていても、それが何を指しているかが、ずれます。
あと、ふりかえりのKPTで付箋を使っているので、空中戦にならないと思うかもしれませんが、軽いテーマでProblemを議論する分には良いですが、議論を深めていこうとすると結局空中戦で話していることが多くなります。
例えば、「将来的にはこうしたいよね」みたいな話が出たとき、将来というのが、１年後なのか、３年後なのかみたいなところからずれていることが多いです。
また、空中戦のまま、議論がうまくできた、結論が出たと思っても、後から冷静になって、思い出してみると、なんでこんな結論になったんだっけ？と思い出せないことになります。
ということで、ある程度難しい議論になって、みんなが口頭のみで議論を始めたら怪しいと思いましょう。
議論が浅い
これは、問題解決型の議論のときに発生しやすいです。 特に、実力のあるエンジニアにこういう傾向が多い気がします。なんとなくですが。
チームで何か解決したい問題があった場合に、問題を表面的に捕らえて、すぐできる解決策に飛びついてしまうのです。
例えば、「チームメンバーのスキルが伸びない。」という課題があったとして、「１週間のうち２時間各自が勉強する時間を取る」 という解決策を決めたりします。
もちろん、ずっと検討していて何も行動しないよりは、何かしらのアクションを取る方がいいのですが、 問題の分析が浅いので、そのアクションが本質的な問題解決になっていない場合があります。
スキルが伸びない原因が、「時間」の問題だけであれば上記の解決策でも良いのですが、それ以外に
- スキルを伸ばしたいという意欲がない
- スキルを伸ばした先のなりたい姿のイメージが湧いていない
- スキルの伸ばし方がわからない
みたいな原因があった場合は、単純に時間を作るだけでは解決しないかもしれません。
また、ふりかえりで、このようなアクションが続くと「いろいろやったけど、結局何も解決できないね。」となってしまい、 ふりかえり自体が意味がないんじゃないかという思考になってしまいます。
しかし、ファシリテーターとして、この「議論が浅い」というのを見極めるのは、ちょっと難しいかもしれません。
まず、「ファシリテーター自体が客観的に問題を見れるか」ということが重要です。 ファシリテーター自体が、チームメンバーと同じ立場で議論していると、なかなか客観的に見ることができません。 ファシリテーターは、「今、こういう議論をしているけど、他の視点や観点はないだろうか？」と問い続けないといけません。
もう１つ「議論が浅いという指摘をしたとして、そのことをチームメンバーが受け入れることができるか」という問題があります。 一般的に、ファシリテーターであるエンジニアリングマネージャよりもチームメンバーは経験が少ないでしょう。 チームメンバーが従来考えたことないような観点が抜けていたとして、それを指摘されたときに、「あぁ。なるほど。その観点は抜けていましたね。」となればいいですが、「そんなこと言ったって、やってみないとわからないじゃないか。」と思われてしまうと逆効果です。
なので、「議論が浅い」という問題が見えたときは、その指摘が、チームメンバーにとって受け入れられるレベルのギャップなのかを見極めて、もし、チームにとってちょっとギャップが大きいと感じる場合には、１回指摘するのをスルーして、チームのメンバーの結論を見守ります。その結果、うまくいかなかったときに、はじめて違う観点での指摘を受け入れられるようになるのです。
ということで、チームメンバーの「議論が浅い」と感じたときには、チームのレベルと指摘のレベルを見極めた上で対策を考える必要があります。
特定の人だけが議論している
これは、チームのメンバー構成に差があるときによく起こります。年齢差やプロジェクト経験の差、スキルの差などなど。 特定の人たちの間では、それなりに意思疎通が取れているので、議論自体は有意義に進んでいる可能性もありますが、 それ以外のメンバーの腹落ち感や感情面が置いていかれているかもしれません。
そもそものチームビルディングがうまくできていない可能性もあります。
ということで、特定の人だけが議論している場合は、要注意です。
ファシリテーションのコツ
空中戦にならないように議論の構成を事前にデザインする
何も準備なしに議論を始めると、空中戦になります。 そうなってから、空中戦にならないように議論を見える化するのは大変です。
そうならないように、事前に議論の構成（プロセス）を事前に考えておきましょう。 議論の構成というのは、単なるアジェンダではありません。 議論の前提から結論に至るまでの構成（プロセス）をメンバーの感情的な持って行き方も含めて 具体的にデザイン（想像）することが大事です。
帆船エクササイズ
議論の構成の例として「帆船エクササイズ」というものを使って考え方を紹介します。
このエクササイズは「Agile Talks vol.1」という勉強会で紹介されていて、初めて知りました。 あんまり日本では流行ってないみたいですが、使いやすいフレームだと思います。
詳細は以下に掲載されているので、興味があれば参照ください。
このエクササイズから得られるもの このエクササイズはチームがビジョンを明確にするのに役立ちます。チームの方向性に潜むリスク、チームを停滞させるもの、そして、目標を達成するために実際に必要なｍのを明らかにしてくれます。
以下のSTEPは、僕なりにアレンジしたものなので、本家とは違うかもしれませんので、ご了承ください。
STEP0 ステージを設定する（５分）
説明
島、帆船、岩、錨、追風の絵を書いてください。 帆船は、自分たちのチームを表しているので、帆船の名前もつけてください。
最初は、アイスブレイクも兼ねて、みんなで絵を書いてもらいます。普段、なかなか絵を書くことはないと思うので、非日常を感じて、今後のエクササイズを受け入れる準備をします。 また、帆船に名前をつけることで、その絵を自分事に感じてもらうようにします。
例えばこんな感じの絵を書きます。
STEP1 ゴール・ビジョンを描く（１０分）
説明
自分たちのチームの３年後に、どんなゴール・ビジョンを目指したいか考えてください。 今の延長ではなく、純粋にどうなっていたいかを考えてみましょう。
まずは、個人毎に考えて、付箋に書いてください。（３分）
その後、一人ずつ発表しながら、チームで共有し、島の場所に付箋を張ってください。（７分）
どうしても、何かを議論する時に、現状に引きずられがちになってしまうので、 まずは、ある程度の先の未来にどうなっていたいかを考えるステップです。
STEP2 ゴールに向かう上でのリスク・抵抗力を明らかにする（１０分）
説明
帆船がゴールに向かう上でのリスク・抵抗力を考えてください。
リスク（岩）：将来起こるかもしれない未知の障害になるであろうこと
抵抗力（錨）：現時点のチームが前に進むスピードを遅くしている力
まずは、個人毎に考えて、付箋に書いてください。（３分）
その後、一人ずつ発表しながら、チームで共有し、岩（リスク）と錨（抵抗力）の場所に付箋を貼ってください。（７分）
時間があれば、なぜそのリスク・抵抗が発生するか話し合ってください。
STEP1で描いたゴールに対して、何が障害になるかを考えてもらうことで、次のアクションがより具体的に実効性を もたせるようにします。このSTEPがないと次のアクションが単純にゴールを実現するための思いつきになってしまうので、 このステップがとても重要です。
STEP3 リスク・抵抗力を減らして帆船を前に進める方法を考える（２０分）
説明
ゴールに向かって帆船を進める方向を考えます。
今の帆船のスピードをより加速する方法
リスク（岩）を回避する方法
抵抗力（錨）を小さくする方法
まずは、個人毎に考えて、付箋に書いてください。（５分）
その後、一人ずつ発表しながら、チームで共有し、追風の場所に付箋を貼ってください。（１０分）
いろいろなアイデアの中で、どれが良さそうか具体的なアクションを話し合って決めてください。（５分）
STEP1で描いたゴールとSTEP2の障害の２つを両方意識することで、 机上の空論ではない地に足のついたアクションでかつ未来に向かっていけるような思考にします。
議論が浅くならないための、「問い」を立てる
議論の構成が事前にできていれば、議論の中で、そこからずれていないか都度確認することで、議論を前向きに進めることができます。
例えば、先程の「帆船のエクササイズ」であれば、以下のような問いが有効です。
「STEP1 ゴール・ビジョン」を考える時の問い
- 現状の延長ではなく、本当に実現したいゴールが考えられていますか？
- そのゴールが実現した時をイメージした時に、ワクワクしますか？
- そのゴールは、自分たちだけでなく周りの人にも喜んで貰えますか？
- このゴールは、みなさん全員が行きたいと思えるものですか？
「STEP2 リスク・抵抗力」を考える時の問い
- まだ顕在化してないけど、帆船が進んだ時に、出くわす岩のリスクはないですか？
- 今挙げている「抵抗力の錨」がなかったとしたら、帆船は、何事もなくゴールの島につきますか？
- 他に、リスク・抵抗力はないですか？これが全部ですか？
- 今挙げている「錨の抵抗力」と違う切り口があるとしたら、何がありますか？（切り口）
- このリスクの岩は、どういう場合に顕在化しますか？
- 今、みなさんのチームが困ってることは、この抵抗力の錨として現れていますか？
- この「錨の抵抗力」は、具体的には、どんなふうに帆船のスピードを遅くしているのですか？（具体化）
「STEP3 アクション」を考える時の問い
- この風のアクションで、錨の抵抗力は、本当に吹き飛ばせますか？そう思う理由は？
- この風のアクションで、岩のリスクは本当に避けることができますか？
- 錨の抵抗力自体を無効にしてしまうようなアクションは考えられませんか？
特定の人だけ議論しないようにする
まー、これはそのままです。はい。
- 議論についていけてなさそうな人がいたら、「○○さん、この辺は、理解できていますか？」と振る。
- 何か言いたいことがありそうな人がいたら、「○○さん、どう思いますか？」と振る。
等で、全体で議論しているような演出をしましょう。 実際の議論のメインは、特定の人だけになってしまうかもしれませんが、みんなで議論したという実感を持ってもらうことが重要です。
最後に
エンジニアリングマネージャにとって、ファシリテーションのスキルは必須です。 ですが、意外と本能で乗り切っている人が多い気がします。 エンジニアのプログラミング等と同じように、ファシリテーションも基礎があって、学べば一定のスキル向上ができます。 チームでの議論がうまくいかないな、と思っているエンジニアリングマネージャの方は、ぜひ、ファシリテーションについて 学んでみてください。
参考文献
ファシリテーションというと割とふわっとした本が多いのですが、この本は、具体的にロジカルに説明してくれているので、エンジニアリングマネージャに向いてると思います。
