職能チームのチームビルディングに奮闘してる話
ソフトウェア会社の組織で良くある編成として、プロジェクト毎に職能横断のメンバーで構成されたプロジェクトチームと、職能ごとのチームの二軸編成があると思います。縦軸と横軸で表現されることもありますね。
僕が所属している部署もそうで、クライアント・サーバーエンジニア、デザイナー、QAなどからなるプロジェクトチームと、Androidなど職能ごとのチームがあります。
プロジェクトチームは普段から一緒に共通の目標に向かって取り組んでいるので比較的チームビルディングがしやすいと思いますが、職能チームは意識的に工夫しないとチームビルディングが疎かになりやすいと感じることはないでしょうか？プロジェクトに集中するあまり、職能チームの課題に向き合う時間を確保できない事はないですか？
僕はAndroidエンジニアなのですが、メンバーの入れ替わりをきっかけに職能チーム(Androidチーム)の連携が薄れ、チームとして課題に向き合う時間が減ったように感じ、特にコロナ禍でのリモートワークがそれに拍車をかけているように感じたため、職能チームを改善するためにチームとしてどう向き合ったかの軌跡を共有します。
結論はこちら
・振り返りで職能チームメンバーの声に耳を傾け、チームの目標の向き直しをする
・職能チームの定例の場でモブプロをして解決することで、プロジェクトに集中できるようにする
序章：Android定例の廃止とコミュニケーション頻度の低下
元々僕らのAndroidチームでは定例があり、週次でAndroid界隈の最新ニュースや各プロジェクトのシェアをしていました。
しかし当時定例を立ち上げた主要メンバー数人がAndroidチームから離れ、また組織全体の雰囲気も変わっていくうちに、次第に「なんでこの定例やってるんだっけ？」という空気が漂うようになりました。
定例ではチームメンバーが顔を合わせて１つの空間に居合わせる心地よさや楽しみもあったと思いますが、メンバーが変わったことでこの部分が削がれ、本来の定例の目的に意識が向いたのがきっかけじゃないかと思っています。
いずれにしても、残ったメンバーにとって当時の定例の必要性は低く感じ、定例を解体することにしました。
シェアが目的であればわざわざ会議体にしないでSlackで十分じゃない？ということで、専用のSlackチャンネルを作ってそこにAndroid界隈のニュースをRSSで自動で流すようにしました。
コミュニケーションが減り、チームからグループへ
Android界隈のニュースを流すチャンネルを作った事でライブラリのアップデートやAPIの更新などの情報にチームメンバー全員が触れる場を作る事はできました。
しかし、Slackチャンネルに無機質にニュースが流れるだけで、そのニュースについてメンバー同士で会話をしたり、実際にプロダクションコードに取り入れたりすることがあまりなく、チームとして知見を共有したり、プロジェクト以外でプロダクションコードを改善していく空気はあまり作れませんでした。
定例が無くなったことでAndroidチームメンバー同士の交流が一気に減って、同じプロジェクトチームに所属しているメンバー間での交流とプルリクのレビューくらいしかやりとりが無くなり、個人的には"チーム感"がなく寂しく感じるとともに、ライブラリのアップデート、Issueや負債コードが放置されていたり知見のシェアが少ないことで、この状況が続くとAndroidチームの負債がどんどん溜まり個々人の技術的な成長も遅くなることを危惧するようになりました。
それぞれプロジェクトチームとしては一生懸命向き合っていますが、職能チームとしては共通の目標も協力もなく、Androidチームが、Androidという枠組みのみで区別されたただのグループのように感じていました。
参考：チームとグループの違いとは―チームワークをよくしたいなら、まず「理想」を共有しよう
ただしこれはあくまで僕個人の主観で、必ずしも他のチームメンバーも同じ印象を持っていたわけではありません。当時チーム・ジャーニーという本を読んでいた影響で、人一倍チームというものに目を向けていたからこそ強く感じていたことです。
定期的な振り返りでチームの声を聴く
このように職能チーム(Androidチーム)に課題感を持っているものの、個人で課題に思っていることをチームメンバーに押しつけてもチームを動かすことはできないため、チームメンバーがどう感じているかをヒアリングしてみることにしました。
そのためにまずは隔週で30分のリモート会議を設け、ファイブフィンガーという手法を使って振り返りをすることにしました。
ファイブフィンガーは５本指で今の状態を示すもので、5が最高で1が最低になります。
みんなで一斉に画面に向けて手を出すことでイベント感というか一体感を出そうとしたのですが、カメラのオンを強要するわけにはいかないので、議事録のドキュメントにそれぞれ点数を書いてもらうことにしました(ちょっと残念)。
思ったより高評価で、さらにその点数の理由を聞いてみると、意外と結構肯定的なメンバーが多いという気づきを得ました。
一方で、課題に感じていることを沢山書いてくれる方も。
こうしてヒアリングをしてみると、設計・実装やレビューなど普段プロジェクトに関わる中でのAndroid関連のフローは安定していて高評価な一方、技術へのより積極的なコミットやメンバー同士の雑談、負債や課題の放置に対しては課題を感じているということが見えてきました。
雑談については早速専用のSlackチャンネルを作り、僕は「疲れた」「金曜嬉しい」など気軽に投稿しています。(ここだけみると仕事したくない人みたい)
隔週で負債や課題のお掃除会に取り組む
振り返りをした結果、まずは個人的にも気になっていたしメンバーからの声にもあった、負債や課題の放置に着目した定例「お掃除会」を隔週で開催することにしました。放置されてるものを掃除しましょう、という意味合いでの命名です。
アジェンダはGithubでの放置物のお掃除を中心に、以下です。
放置されてるリモートブランチを削除する
放置されてるIssueを棚卸しする
放置されてるプルリクを棚卸しする
このコードどうなの？のシェア
実装して困ったことのシェア
リモートで画面共有してその場で皆でブランチやIssueを消したり議論をするのですが、チームで決めた目標に向かって皆で取り組むことで、放置物の掃除という実益だけではなく、チーム力も向上できたのではないかと思っています。
僕個人だけが課題に感じて会議体を作ってみんなに協力してもらうのではなく、チームとして共通課題を持って協力しあうというのが大事だと思います。
控えめに隔週にしてたが、チームの声で毎週実施に
隔週でお掃除会をしつつ振り返りも続ける中で、「各プロジェクトチームでどんな企画をしているか分かりづらくプルリクのレビューがしにくい」「共有や洗い出しをもっとやりたい」などの声も出るようになりました。
そしてチームで話し合い、これまで隔週で30分お掃除会をしていたのを、内容を加えて週次で1時間のAndroid定例を開催することにしました。
これまでは、まだ若干自分の押しつけがあるんじゃないかと懸念して、メンバーの不満が大きくならないように控えめに隔週で30分にしていたので、メンバーの方から「毎週やりたい」という声を聞くことができてとても嬉しかったです。
内容としては、これまでの「お掃除会」に加えて、企画や気づきをシェアする「シェア会」もやってみよう！となり、アジェンダを隔週で切り替えることにしました。
お掃除会
・放置されてるリモートブランチを削除する
・放置されてるIssueを棚卸しする
・放置されてるプルリクを棚卸しする
シェア会
・各プロジェクトの企画シェア
・このコードどうなの？のシェア
(参照されてないライブラリやコード、複雑なコード、負債コードなど)
・実装して困ったことのシェア
特に企画シェアでは、これにより他のメンバーがどのあたりのコードに手を加えるのか事前に分かってプロジェクト間のコンフリを防ぐことができたり、「そのユーザーストーリーを満たしたいなら、最近公式でこんなAPI(アプリ内の公式レビューダイアログなど)が提供されたよ」などの知見シェアが生まれ、効率的な開発に役立っています。
このように、チームメンバーから自発的に意見が出るようになり、「毎週こういうのに取り組めるのは良いですね」という発言があったのがとても嬉しかったです。
そして意図せずモブプロへ
このように週次でAndroidチームの課題に取り組む中で、思いも寄らぬ動きも起こりました。
例えばIssueの棚卸しのとき、不要な場合の削除はその場でするものの対応が必要となったものは担当者を割り振って各自対応にしていたのですが、自然と「この場でコード書いて対応しちゃいましょう」とモブプロでその場でプルリクを作って対応するようになりました。
各自の宿題にして持ち帰ると、定例が終わってプロジェクトに意識が戻るとなかなか職能チームの課題に着手しにくいので、モブプロにせよ各自で対応するにせよ、定例の最中に成果物を出す時間を作るのはとても効率的なことだと思いました。
これにより後回しにせずその場でIssueに対応できるだけでなく、「AndroidStudio(統合開発環境)のこんな機能あるんだ！」など他者のコーディングを見ることによる発見という、モブプロの恩恵の１つを受けることができましたし、何より「これからもモブプロしたいね」という空気感が生まれたのがとても良かったと思います。
チームで定例をアップデートしていく
こうして週次でAndroid定例を開催するようになりましたが、盲目的にずっと同じアジェンダを繰り返していては、最初に触れたようにいつの日か定例の意義が薄くなり、形骸化してしまいます。
そうならないように、「いまのアジェンダはずっと続けるつもりはなく、もっとこうして欲しいというのがあればどんどんアップデートするので意見をください」とメンバーに伝えています。
直近の定例では「消せそうなライブラリのリストアップ」や、「消したいが影響範囲が大きいライブラリの削除対応を分担して取り組む時間を作ろう」などの案も出てきており、メンバーの声を聴きながら定例にアップデートしていこうと思っています。
まとめ~振り返りと向き直りで改善し続ける~
長くなりましたが、職能チームの各メンバーがプロジェクトチームとしてユーザーに価値を届けることに注力しながら、職能チームとしても負債解消や技術力のキャッチアップに取り組む過程を共有させてもらいました。
また、定例の時間内で負債解消の対応をモブプロすることで、プロジェクトに集中して取り組むのに忘れることを防ぐことができる、という発見も共有しました。
実はこの取り組みを始めたのは今年の5月頃からで、まだ3ヶ月ほどしか経っていません。そのため、今はまだまだチームビルディングの序盤で、もしかすると最初の勢いが出ていてたまたま上手くいってそうに見えるだけで、徐々に上手く行かなくなることもあるかもしれません。
そんな時には、同じように振り返りでチームメンバーの意見に素直に耳を傾けて、チームとしての目標を再設定して向き直りをしよう思います。
また、みなさんが職能チームとして取り組んでいることやチームビルディングの工夫もぜひ教えていただきたいです。