この記事は Retty Part1 Advent Calendar 2021 の9日目の記事です。

Rettyでエンジニアをやっている池田です。静的型付け言語とRDBMSとふりかえりが好きなエンジニアです。

今年の10月にチーム編成が変わり、それを機にスクラムマスターを始めました。
この3ヶ月ぐらいで「チームが自ら課題を発見する」という状態にどうやって向かうかを1つ学ぶことができたので、そのチームビルディング的な観点について書いてみます。

自分のチームは新卒2人、中堅エンジニア1人、ベテランエンジニア1人、スクラムマスター（自分）の5人チームです。
BtoB領域を担当していますが、新チーム体制の発足当時は業務知識が少ないメンバーの方が多い状況でした。
（自分がToCから移って4ヶ月ほど、新卒2人はToCから移ったばかり）
「わからないことがわからない」ような状態でしたが、ここでベテランに業務を教えてもらうだけの構図になってはチームとして大きな成果は出せないと考えていました。
そこで、成果をスケールアップし続けられるチームになるためにまずは自ら課題を発見し改善できるチームを目指すことにしました。
あれこれ試行錯誤し、ようやくそのレベル1ぐらいがスタートできたかなと思っています。

その過程でわかったのは、課題を自ら発見できるチームになるためにはチーム内で課題を話しやすい場づくりが大事ということです。

チームで課題を発見できる環境とは

まず課題をどうやって発見したらいいのかについては以下の考え方が好きで、たびたびチームメンバーに伝えていました。

問題とは、望まれた事柄と認識された事柄の間の相違である
出典: ライト，ついてますか - 共立出版

課題発見と言われるとチームの障壁になってることを探さなきゃと難しく考えてしまうかもしれませんが、「こうなってたらいいと自分は思うのになぜかそうなっていない」という疑問やもやもやを探せば最初は十分です。
チームの障壁になっているのか、解くべき課題なのかはそれをチームに投げてみてからみんなで考えれば十分間に合います。
むしろ同じ課題でも人によって思い当たる原因や重要度は様々なので、まずは会話して課題感を共有し、すり合わせてから改善行動を起こした方がより良い結果が得られるはずです。

そして課題を会話するためには「このチームなら課題を投げかければ何とかできるかも」と思ってもらう必要があると考えています。
もし課題を発見しても個人で何とかしないといけないと思われている内は個人の胸に留めてひっそりと解決、もしくは諦めてしまうかもしれません。
チームが課題を発見すると言っても実際に発見するのはメンバー個人です。
課題をチームでカジュアルに話すことが自分やチームの開発をより良くする第一歩と考えてもらい、チームに対して課題を投げかけるハードルをいかに下げられるかがポイントだと思います。

課題を話しやすいチームをどうやって作るか

心理的安全性という言葉が広く知られるようになりましたが、課題について会話するためにはそれをチームに話しても大丈夫だという状態を作る必要があります。
そのために大きく以下3つのきっかけ作りに率先して取り組みました。

目指したい姿を共有する
課題をただ雑談する
誰かの課題提起にとにかく反応する

「心理的安全性があるかのように振る舞う」（出典: チームが「サイロ化」しないための仕掛け（増補版））というのは結構大事だと思っていて、課題を話せるチームになるために取って欲しい行動は全体を通してまず自分が積極的に取るようにしていました。
（心理的安全性を高めるための行動がいい感じに言語化されている記事がちょうどあったのでこちらも是非 → 心理的安全性をもたらすには - tuneの日記）
一方でやるのはあくまでも第一歩を率先して踏み出すだけで、そこから先はチームが良いと思ってくれた方向に自然と場が広がるよう過剰にやりすぎないことも意識していました。

目指したい姿を共有する

一番始めにやったのがこれです。みんながバラバラの方向を向いた状態で行動を起こしてもなかなかうまくいきません。
「自ら課題を発見し改善できるチームにしたい！」というのはチーム発足後のわりと早い段階でチームに相談しましたし、ことあるごとに口にしていました。
そもそもこれをチームメンバーがどれくらい良いと思ってくれるかは話さないとわからないですし、受けとめ具合も人によって違います。
まずは話して反応をもらいつつ価値観を共有し、目指したい姿のだいたい同じイメージをみんなに持ってもらうことが大事だと思います。

この「だいたい同じ」という感覚も大事にしています。
認識を100％揃えることは中々難しいですし揃える労力もかかります。それよりも向かう方向がだいたい揃った段階で動きだして、あとはやりながらすり合わせる方が楽です。
行動の結果をふりかえって次に何をしたら良いか見直せますし、やっていくことで言語化し共通認識にできる部分も増えていきます。
わからない未来に対してあれこれ準備万端にしようとするよりも経験に基づき軌道修正していく方が不確実性とうまく付き合えます。

課題をただ雑談する

課題だなと思ったことは「ちょっと雑談したいんですけど」と軽く話したり、【雑談】とそえてSlackに書いたりしました。
解決策が今でなくても良いという期待値も一緒に伝えたり、「課題」ではなく「もやもや」というちょっとゆるい雰囲気の単語を使うことでハードルを下げやすくもしました。
率先してそれをやることで課題を話しても大丈夫なんだなという体験を作ることができます。
続けていると次第にチームメンバーからも「もやもや」が挙がってくるようになりました。
チームメンバーが「Slackでもやもやを見かけるようになって言うハードルが下がった」、「同じ課題感を持ってるという共通認識があって話しやすくなった」とふりかえりで話していたので、自分がまず行動する大事さがよくわかった体験でもあります。

誰かの課題提起にとにかく反応する

チームメンバーが挙げてくれた課題には積極的に反応するようにもしました。
受けとめて会話することはもちろん、「たしかに〜」みたいな軽い相槌程度でもとにかく反応しました。
（自分が見たものはおそらくスルーしたことないはず）
本人の中で勇気を出して発言してくれたことかもしれないですし、なりより疑問を投げかけたら必ず反応してもらえると感じられる体験を作ることが「このチームなら課題を投げかければ何とかできるかも」と考えてもらうことに繋がります。
これも続けているうちに自分以外のメンバー間でも反応して会話する機会が増えました。
こちらもチームメンバーが「課題を投げてもスルーされずに受けとめてもらえると感じて話しやすくなった」とふりかえりで話していたので、一定の効果があったと思います。

まとめ

ここまでに書いた以外にも象、死んだ魚、嘔吐という問題に着目したふりかえりをやったり、ことあるごとに「もやもやは発信しないと抱えたままじゃ解決できないよね」と口にしたりしていました。
ふりかえってみると1つ1つは特に大した取り組みではないのですが、こういう地道な活動がチームの環境や文化を作ることに繋がるんだと改めてわかりました。

実は「これをやればこの状態になれる」と最初からわかってやっていたわけではなく、やってみてふりかえる中でわかって言語化できた部分があります。
また、チームメンバーが言語化してくれたことや新たに取り組んでくれたこともたくさんあります。
やってうまくいかなかった取り組みも当然あって、小さく失敗してそこから次のアクションを見直し続けるというマインドセットがチームビルディングにも大事なんだなと実感しました。