初めましてが多いチームの形成期にEMが取り組んだ事

こんにちは、スマートバンクでEM(エンジニアリングマネージャー) をしている三谷です。

今年の4月から新しく1つのチームを立ち上げて、EMを担当することになりました。このチームのエンジニアは、3~4月に入社していただいた社員&業務委託の新しいメンバー3名+自分という “初めまして” 状態のメンバーで作ることとなり、EMとしてチームビルディングをいつもより強く意識しながら取り組んできました。

チームが機能するように成長するまでには、下に添付した図のタックマンモデルのようにチームビルディングのステージ毎によくある課題を理解して対応していくことが近道とされています。

このブログでは、”初めまして” の状態からチームの形成期~混乱期をなるべく早く脱して、統一期に向かうために取り組んでいることについて紹介します！チームビルディングに悩みがある方や、新しいメンバーのオンボーディングに興味がある方に読んでもらえればと思います！

チーム形成期の状態

3月に入社いただいた2名はオンボのメンターを自分が担当しましたが、オンボが完了してからは別チームの新機能開発を担当していただいていました。4月に入られた業務委託の1名はオンボ担当でもありませんでした。新しくチームを立ち上げたタイミングでは、皆出会って1~2ヶ月しか経っておらず、お互いのこれまでの経験や価値観、仕事の進め方などを全く知らない状態からスタートしました。

新しい環境に飛び込んで来られた方の多くはやる気に満ち溢れています。早くコードを書きたかったり、機能開発を担当して早くユーザーに価値を届けたいと思って入社していただく方がほとんどです。今回のチームメンバーも、Good First Issueやアラート対応などをすごく積極的に対応してくれていました。ただ、新しい環境になるので仕事の進め方で分からない部分が多かったり、どの程度の仕事ができれば十分貢献していると思われるのか期待値調整的な部分に不安を抱えていたと思います。

一方で、新しく立ち上がったチーム自体、すぐに開発READYな施策をもっていた訳ではなく、探索型のチームとして施策の企画段階からエンジニアが関わっていく性質のチームでした。そのため、エンジニアが直ぐにバリューを発揮できるタスクが準備できていなかったり、MTGやバックログの整理の仕方も決まっておらず、何から着手しようか非常に悩ましい段階でした。また、EMの自分もチームが立ち上がる前に担当していた開発案件の残りタスクや、定常的な保守運用タスクを抱えていてバス因子係数が高い状態になっており、チーム作りに集中できない期間でもありました。

まとめると次のような状況で、お互いの意識の向き先がバラバラだったと思います。

探索型チームでやることが明確に決まっていない
EMのバス因子係数が高く、新しいチームにフルコミットできていない
エンジニアメンバーはやる気に満ち溢れているがタスクがない

取り組んだこと

①EMのバス因子係数を下げタスクをどんどん渡す

探索型のチームなため、新機能の開発タスクを直ぐに準備することはできませんでした。ただ、エンジニア内での開発サイクルを作ったり、新しいメンバーが既存のコードに慣れて新機能のタスクが生まれた時にスムーズに開発に入れるように暖機運転をしたいと思っていました。そのため、自分が新チームが立ち上がる直前まで関わっていた別案件の残タスクや、会社の中でも属人化してた決済のエラー対応などを巻き取ってもらうことにしました。

別案件の残タスクはQAを実施して発覚したバグを直してもらったり、リリース後の監視のためのコードやクエリを書いてもらっていました。決済のエラー対応では、データ不整合などが起きた際に通知されるslackチャンネルを監視してもらい、発生時に発生理由と対処方法を伝えながら1人で対処できるように引き継ぎをしていきました。

正直、自分としてはあまりテンションが上がるタスクではないけど、やってもらえたら嬉しいくらいの温度感でした。ただ完全にお任せできることで、自分のバス因子係数を下げて新しいチーム作りのタスクに集中できたり、新しく入られた人はタスクの大小や面白さよりも、そのタスクを担当することでコードへの理解が深まったり早期にバリューを出しやすい側面があります。

そのためタスクの選り好みは一切せず、自分が抱えていたり新規に降ってきたタスクは全てチームメンバーにお任せする方針をとり、自分はタスクの説明とサポートに徹してメンバーが開発できる時間を増やしていきました。

②チームで話す時間を増やす

開発タスクは準備できたのですが、B/43はリリースして3年が経ちモデル数も1000を超えるほどになっているため開発を進めるにはドメイン知識が必要になります。また、チームメンバーのほとんどは前職での開発言語がRubyではなく、Ruby on RailsやMVCのアーキテクチャでの開発スタイルにも慣れていないという悩みを持っていました。

そのためお互いが開発タスクをやる中で悩んだポイントだったり、新しく得られた知識をチーム内で共有するための時間として、朝会を毎日1時間取るようにしました。朝会は以下のアジェンダになっており、今日やることを宣言しつつ後半パートで悩みを払拭し、徐々にB/43のコードと開発スタイルに慣れてもらうことが目的です。

今日やることの宣言とバックログのアップデート
前日のアラート通知の確認と更新
前日のPRを眺めて相談・共有
実装以外のタスクの相談・共有

PRやタスクで相談・共有したいものは前日の夕方にリマインダーがセットされているので、そのスレッドに貼り付けるようにしています。

毎日朝会で1時間、エンジニア全員が集まって話すのは少しヘビーに思われるかも知れませんが、チーム形成期ではお互いに知らないことが多く話題も尽きないので時間が足りないことも多々あります。

長く働いているとお互いのコードの癖が分かったり、この人にタスクをお願いしたらきっとこういう形で進めてくれるはずといった以心伝心的な状態になると思いますが、そういった状態へのショートカットとして話す時間を増やすのは良い方法だと思っています。

②チームの開発サイクルを作る

バックログを整備 & チームとして話し合って仕事が進められる状態が作れたので、よりチームが動きやすいようにタスクの進め方でいくつか工夫をしています。

一つ目が保守運用系のタスクを行うための専用チャンネルの設置です。B/43ではSentryやバッチ系のエラーが発生した際には全エンジニアが入っている共通のslackチャンネルにそれぞれ通知されます。また他にもCSや外部パートナーから問い合わせ経由で行うタスクもあります。

過去の対応内容をストックしたいというのと、チームが対応すべきタスクの状況を一元管理するために チーム名_ops というチャンネルを作り、リアク字チャンネラーを使って特定のスタンプをつけるとそのチャンネルに流れるように設定し、そこで対応をするようにしています。

上記のようにエラーなどが発覚した時点でスタンプをつけてチャンネルに投稿 → スレッド内で対応ログを残すというフローで行なっています。

二つ目がWorking Out Loudです。タスクに取り組む際にslackに :wol: というスタンプをつけて、作業ログを残しています。こうすることで他のメンバーが、今どういう作業をしていて、どういうところに悩んでいるのかを知ることができますし、困っている時に気軽にサポートができるのが良いです。

Working Out Loudについてはこちらのブログが詳しいのでぜひご覧ください。

blog.smartbank.co.jp

最後の三つ目は、週次定例でのふりかえり手法です。今は明確にスクラムのメソッドを取り入れて開発をしているわけではないのですが、週次でレトロスペクティブのMTGを実施しています。今のチームは探索型ということもあり、毎週状況が変わり悩みも変わっていきます。そのためKPTだけをやっていてもチームの状況の変化に合いにくいと思い、ふりかえり手法を毎週変えています。

この方法はカケハシの@dora_e_mさんのXの投稿にインスパイアされ、@bufferings さんとお話しした際にふりかえりカタログを教えてもらって運用しています。 チーム名_furikaeri というチャンネルがあるので、日々気になっていることを投稿してもらい、金曜日時点で内容を自分が確認し、悩みを解決できそうな振り返り手法をピックアップして実施するという形です。