2024年1月にグループ内でチーム分けを行いチームリーダーを担当しています。チームリーダーという役職があるわけではないので、これまでと大きく役割が変わるわけではないですが、任せてもらった以上は何かしらの成果をあげたいと思っていました。早くも4半期が終わったので実際に取り組んできたこと振り返りつつ、何を考えていたのかまとめていきます。
目次
- チーム分けの背景
- 課題
- チーム体制
- チームリーダーの役割
- 新チーム始動までの不安
- 3ヶ月のスタンス
- 3ヶ月で取り組んだこと
- 3か月の総括
- 今後に向けて
チーム分けの背景
昨年の12月にチームイベントで今後の組織運営を考える時間がありました。そこで課題を出し合ってみて対策としてチームを分けてやってみようとなりました。
課題
- チームが9人と増えてきたのでコミュニケーションコストが高い
- メンバー同士が何をしているか把握できない
- MTGで話す人が決まっている
- 担当サブが多い
- 得意なサブを持てないので成長している感がない
- サブ知識が足りていないのでメンバーの開発案件をレビューできない
- サブ知識が属人化している
課題の要因はメンバーの数、担当サブの数なのでチーム分けを行うことでそれぞれの数が半分になるのである程度、課題が解消できそうとは思っていました。
チーム体制
開発体制
私が属しているグループの特徴です。
- アジャイル開発(手法はスクラムっぽい。スクラムイベントはだいたいやっている)
- 1ヶ月スプリント
- 保守の差し込み対応が結構多い
- フルリモートで対面で会うことは年数回
旧体制
グループメンバー：9人(マネージャー、メンバー：8人)
新体制
グループメンバー：8人(マネージャー、メンバー：7人)
チームA：4人 ←自分はこっち
チームB：3人
チームの特徴
サブの分け方は明確に2チームにわけることができなかったので、保守工数が多くなるサブと開発メインのサブをわけ、それぞれのメンバーが得意なサブをチームに持っていくように分けられました。
チームA：保守(問合せ、不具合修正)メイン
チームB：新規開発メイン
チームリーダーの役割
チームリーダーという役職はありません。グループ内で決めた役割であり明確に責務も決まっていません。3ヶ月経過して以下が役割だと考えています。
- 通常業務(開発、問合せ対応)に主体性を持って遂行する
- チームの担当サブに関する意思決定を行う、またはチーム内で決定できるようチーム活動を先導する
- 担当サブの未来を考える、考える環境を作る
- マネジメントは行わない
新チーム始動までの不安
新チームが始まるタイミングでグループから1人メンバーがいなくなることも決定していました。問合せ業務において強いリーダーシップを発揮していて、各メンバーが頼りにしていた存在でした。
またチーム(担当サブ)を分けたからといって、問合せ数がそのまま減るわけではありません。グループ全体に来る問合せのうち約8割は自チームが担当サブだからです。
頼れる存在を失いつつ、1人当たり担当数を増やす(3-4割増)ことが求められ、問合せ対応を滞りなくできるか、工数が圧迫して開発時間が取れなくなるのではないかという不安を持っていました。
3ヶ月のスタンス
はじめの3ヶ月間はチームビルディングを行い、やっていいけるという自信を持つ期間とある程度割り切っていました。マネージャーと話し合いやらなければいけない問合せ対応、コミット案件の開発を行い、それ以外の時間を使ってチームイベントを行いました。
チームイベントもチーム運営全体に大きな影響を与えるものは極力行わず、既存のチームイベントを見直し、改善してくことを意識していました。問合せ担当数や難易度の増加に適用することが最重要で他にあまりストレスをかけたくないと考えたためです。(何に対して、どうアプローチするか自分の中で整理できていないという理由もありますが・・・)
スクラムっぽい開発手法なのでスクラムに関する書籍に改善のヒントがあると思って勉強してみて良さそうなものを取り入れていきました。
3ヶ月で取り組んだこと
前置きが長くなりましたがここからが本題で、3ヶ月で取り組んだことを紹介します。
ここまでに記載しているチーム分け前の課題や新チームの置かれている状況を考えてまず取り組むべきことは以下と考えました。
- メンバー同士の関係性の構築
- サブ知識のキャッチアップ、属人化の解消
クロス1on1
活動内容
- 毎週月曜日 30分
- 週ごとに相手を変える(3週でチームメンバー全員と話せる)
- 1サイクル目はフリートーク
- 2サイクル目の前に自己認識に関するワークを行い、各自が重要とする仕事観などを共有 + フリートーク
ねらい
新チームのメンバー同士がほとんど話したことがない状況だったので、まずは話す時間を設けることで個人を知ってもらうこと、困った時にお互いが頼れる関係性を築く、何を考えているかをオープンにすることで業務における認識のズレを埋めることがねらいでした。
効果
メンバー色々なことを思って仕事していることを知ることができたと思います。1on1に雑談をすると「〇〇さんも同じことを悩んでいた」「〇〇さんが思ったより話してくれた」というような声が多かったです。何を考えているかわからない相手に対しては、勝手にネガティブな想像をしてしまうので、心理的安全性が高められたと思います。
モブ作業(サブ勉強会)
3ヶ月で一番効果を感じられた活動でした。メンバーの1人とイベントの内容を考えてある程度決めた段階で取り組み始め、取り組みながら改善していきました。
活動内容
- 週2回 1回45分
- 特定のサブを詳しい人が他メンバーに機能を教えながら実際に動かしてみたり、詳しい人がいない場合は全員で調べたりする
- 一人一人に役割を持たせて全員参加で取り組む(ファシリテーター、モデレーター、議事録担当者、社内情報を探す人)
- 録画する
- wikiにまとめる
モブ作業の流れ
ねらい
問合せ件数の多い機能の設定を組んで実際に動作させます。DBテーブルやソースコードを共有することで問合せ担当する時に初手で止まってしまうことがなくなるよう取り組みました。
議事録や録画内容をwikiに整理することで今後加わるメンバーが資料を見てキャッチアップできる環境を整えています。
効果
チーム全体の問合せ書き込み数の増加
| 2023-4Q | 2024-1Q |
|---|---|
| 159 | 233 |
書き込み件数の増加(約5割増)をみても効果があったと感じられます。
取り組んだ機能について、どんな機能でどう利用するかの基本部分は全員が共通認識でき、苦手意識を克服できていました。
開発を行う時もDB情報を探したり、各オプションの意味を確認したりする時に利用できナレッジの蓄積を少しづつできてきたと感じています。
一人一人に役割を持たせるという方針も良かったと思います。このイベントの経験が実際に緊急度の高い問合せをみる時にslackやwikiを探して担当者に情報を共有してくれたことで即時解決できたこともありました。
MR確認会
活動内容
- 開発担当者が実装完了後に開催
- 追加機能、不具合修正の内容、実装の説明、質疑を行う
- 実装内容によってはスキップ可
ねらい
できるだけチーム内でコードレビューしマージまで行えるようになりたいと考えていました。そのためには実装力、レビュー力を高めることはもちろん必要ですが、まずレビューできる状態(何を追加、修正したかわかる、元の動作をわかる)になることが必要でした。もちろん今までも実装内容の説明はレビューで行われていましたが、リリースノートやテスト観点の議論に圧迫されて時間が確保できない場面が多くありました。そのため別時間を確保することで確実に議論することがねらいです。
効果
- 実装内容と動作を照らし合わせて確認できる(時間内に終わらなくても設定、動作までは理解できるのであとでローカルで確認できる)
- 実装者の思考が勉強になる
- 他メンバーのレビュー観点が勉強になる
ふりかえり
ふりかえり手法の書籍に「ふりかえりのふりかえり」が大事とあったので、これまでの取り組みをふりかえって、何を目的にするか、どんな雰囲気にするかを考えました。
週次
- 毎週金曜 30分
- Googleスライドにボードを用意し、各自が書き込み(他ツールも検討したが断念)
- 書き込む内容は Good,Bad,Next,Thanks(ほぼKPT)
- コミュニケーションの場を確保することも目的の1つなのでゆるい雰囲気
月次
- 毎月月末 60分
- スプレッドシートを用意し、各自が書き込む
- 書き込む内容は KPT
- 各自書いた内容を発表し、メンバーは発表者にコメントを記入
- MRリードタイム、問合せ書き込み数など定量分析も行う
- ファシリテーターをメンバーで交代して行う
- スプリントのふりかえりなので定量的なふりかえりも行う。週次よりはかっちりした雰囲気
3ヶ月の総括
やらなければいけないこと(問合せ対応、コミット開発案件)は着実に成果を出すことができたと思います。3月が問合せ件数は多くなるので滞留はいつもより多くなりましたが、優先度と緊急度を考慮して対応できました。
また新たに始めたクロス1on1やモブ作業によって、メンバー同士の理解、関係性の構築、メンバーやチームへ貢献する雰囲気が高まってきたと思います。
はじめの3ヶ月間はチームビルディングを行い、やっていいけるという自信を持つ期間
はじめに掲げていたことは達成できたと考えています。
個人としてはチームについて考えて取り組んでいくことが楽しかったですし、好きなんだということが発見でした。
今後に向けて
一方でプランニングやタスク管理は以前よりも難しくなったと感じています。月初のプランニングだけだと案件の偏りが発生してしまうので再プランニング時間を設けたり、タスク管理方法を見直して透明性をあげる努力をしてきました。少しずつ改善はできていると思っていますが、個人的にあまり納得感がある状況ではありません。
アジャイルな組織とは何かをメンバーで共通認識して、その思想のもと自チーム状況を踏まえて最適な方法を探していいく必要があると感じています。アジャイル開発、スクラムに関する本をよんで勉強してみましたが、より体型的に学びたいと思い4月にスクラムマスターの研修を受けます。そこで学んだとこを今のチームに還元してアジャイルな組織を目指していきたいです。