2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

チームの「型」が偏ってることに気づかず、半年ハマり続けた話

2
Posted at

はじめに

うちのチームは数人の小さなエンジニアチームです。その中でPMも兼務しているんですが、去年の後半くらいから「なんかいつも同じところで詰まるな」という感覚がずっとありました。
具体的に言うと、新機能の要件はすぐ固まるのに実装フェーズに入った瞬間に速度が落ちる。逆に実装が走り出すとめちゃ速いんですが、リリース前のレビューで「これ仕様と違いますよね」という指摘が毎回のように出る。
最初は個人の能力の問題だと思ってたんですよね。誰かがボトルネックになってるんじゃないかと。でも1on1で聞いても、みんな普通に頑張ってるし、スキルも足りてる。なのに毎回同じパターンで詰まる。半年くらいこの状態を繰り返してから、ようやく「これは個人の問題じゃなくてチームの構成の問題なんじゃないか」と思い始めました。

最初にやった間違った対処

最初にやったのは、詰まってる工程に人を増やすことでした。実装が遅いと感じたら実装が得意な人をアサインし直す、レビューで指摘が多いと感じたらレビュー担当を固定する、みたいな対処です。

症状: 実装フェーズで速度が落ちる
対処: 実装が得意なメンバーを増員
結果: 一時的に速度は戻るが、次のスプリントでまた別の工程で同じ現象が起きる

これをやってて気づいたのは、対処してるのが「症状」であって「構造」じゃないということです。人を動かしても、チーム全体としてやってる仕事の種類のバランスは変わってない。誰かが抜けた工程には結局別の穴が空くだけでした。
あと個人にヒアリングする形で「得意不得意」を聞いてもうまく整理できませんでした。「実装が得意です」と言う人が2人いても、片方は「新しい技術を試すのが好き」で、もう片方は「決まったパターンを速く正確に書くのが好き」だったりして、実は全然違う強みだったんです。得意不得意という粒度だと、チームの中の役割の重複と欠落が見えてこなかった。

正しい理解・対処法

ステップ1: 「得意不得意」ではなく「型」で聞く

まずやったのは、質問の粒度を変えることでした。「何が得意か」ではなく「仕事のどのフェーズで一番エンジンがかかるか」を聞くようにしました。

質問例:
- 白紙の状態から方向性を決めるときに一番テンションが上がる
- 決まった方向性を最速で形にするときに一番テンションが上がる
- 出来上がったものの穴を見つけるときに一番テンションが上がる
- 周りの状況を整理して噛み合わせるときに一番テンションが上がる

これを5人全員に聞いてみたら、うちのチームは見事に偏ってました。「形にする」フェーズが得意な人が3人、「方向性を決める」人が1人、「穴を見つける」人が0人。整理役も0人。半年間の詰まりのパターンが、この0人のところにきれいに対応してたんです。実装は速いのに仕様とズレる、というのはまさに「穴を見つける」役がいないから起きてたことでした。

ステップ2: 現状のバランスを可視化する

聞いた内容を4象限くらいのマップに落として、メンバーの点をプロットしました。ちゃんとしたツールを使わなくても、ホワイトボードに軸を書いて名前を置くだけで十分です。

        方向性を決める
             |
  整理する ---+--- 形にする
             |
        穴を見つける

これをやると、誰が悪いという話じゃなく「チームの形」として偏りが見えるので、本人たちも納得感を持って受け止めてくれました。特に効いたのは、この図をチーム全員に見せたことです。今まで「なんで自分だけ毎回レビューで詰められるんだろう」と思ってた人が、「そもそもこの役割が他にいないからだ」と理解できて、個人攻撃じゃなくなったのが大きかったです。

ステップ3: 空いている型を人で埋めるのではなくプロセスで埋める

理想は「穴を見つける」役の人を採用することですが、5人チームでそう簡単に増員はできません。なので、空いてる型を人ではなくプロセスで埋めることにしました。

Before: 「穴を見つける」役がいない → 誰も途中で疑わない → リリース前に発覚
After: 実装着手前に「これは何のためにやるのか」を1行で書く欄を必須化
        → 形にするのが得意な人自身に、着手前だけ整理役をやらせる

つまり全員が常に自分の型で動くんじゃなく、フェーズによって意図的に別の型のふりをする仕組みを作った感じです。これは本人の性格を変えるわけじゃないので、最初は形式的にやってもらうだけでしたが、3ヶ月くらい続けたらチェック自体が自然になって、指摘の数が減っていきました。

ステップ4: 兼務PMだからこそ定期的に測り直す

うちは複数プロダクトを並行して見てるチームで、しかも自分はPM兼エンジニアなので、常にこの偏りを見張ってる時間なんてないんですよね。なので四半期に1回くらい、5分だけ同じ質問をやり直すようにしました。
人は案件によって型が変わることもあるし、新しいメンバーが入れば当然バランスも変わります。一度可視化して満足するんじゃなく、定期的に測り直すことをルール化したのがポイントでした。

おわりに

半年間「なんでいつも同じところで詰まるんだろう」と個人の能力のせいにしてたのが、実はチームの型のバランスが偏ってただけだったというのは、振り返るとかなり拍子抜けする話です。でも当事者としてやってる間はまったく気づけませんでした。
小さいチームほど、この偏りの影響がダイレクトに出ます。誰かの得意不得意を聞くより先に、チームとしてどの型が何人分あるのかを一度可視化してみると、思ってたよりシンプルに詰まりの原因が説明できるかもしれません。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?