この2ヶ月ぐらいサポートしてるチームで、実験を重ねる中でチームのやり方として定着してきたものがあるので、温かいうちに書いとく。6個ある。
背景
どういう背景かを簡単に：
- エンジニア4人とリーダー1人、プロデューサーが2人のチーム。全員家からリモートでつないでる。
- サポートに入る前はチームは計画重視の指示型開発で全員別々の作業をアサインされて取り組んでいた
- そこに「自己組織化チームにしたいけどそういう経験者もいないしプロジェクトも忙しい中なのでサポートしてほしい」と声をかけてもらって参加
- 2週間くらい観察して色々周りを整えたあとにチームに入って、スクラムを導入して1週間スプリントを6回終えたところ
- 自分はリーダーの代わりに入らせてもらうことにした。まずはチームのやり方を色々変えてしまって、チームが落ち着いてきたら徐々にリーダーと一緒にそのリーダーならではの道を探して、最終的にはそのリーダーに渡す予定。
スクラムをどんな風に導入したかは今日は触れない。そして、いつものことだけど、ちゃんとスクラムやってるわけじゃない。
定着してきたチームのやり方
ということで、チームのやり方として、実験して定着してきたものたちを紹介する。
(1) Mobbing by default / 基本はモブ
全員が集まることを基本とする。特に以下の場合はペア作業中だとしても全員を集める。
- 大きな設計判断、または難しい設計判断をする場合
- ペアの二人共が悩んでしまった場合
- 他のペアの意見も聞いてみたい場合
基本をモブにする背景
- 基本がペアだと、全員で集まるハードルがあがってしまうため、基本はモブとする
- 基本がモブで、そこからペアに分かれるのは簡単
これを実現させるためにまず最初に「チームとしてタスクを受け取る」ということに取り組んだ。個人やペアでタスクを受け取るという認識だと、助け合うときに足枷になってしまうから。自分の今担当しているタスクの手を止めても、別のペアのタスクの相談にのることがチームとして優先することだ、という認識を持てる場にすることが大切。
(2) Pair as Atomic Unit / 最小単位はペア
作業担当の最小単位はペアとする。一人ではタスクを担当しないこと。
- 設計・実装・テスト、それぞれに対してクオリティがあがる
- イージーミスが減る
- 別の視点の意見が入る
- コードレビューの負担が下がる
- 一人だと焦ってとばしてしまいたくなることも、二人だと止めてもらえる
- 名前づけを真剣に考えやすくなる
- ときには途中で見切りをつけてまず動くところまで持っていくという判断をしやすくなる
- 一人だと悩んでハマってしまう場合があるが、ペアに相談できるし、ペアでも悩む場合に他のペアに相談するという判断がすばやくできる
- ペアのもう一人がお休みの場合は、別のペアに合流して3人で作業することを第一に考える
これは「効率上げるために一人で作業してみる」という実験をしたときに「やっぱりつらい」「結局時間がかかる」ってなって「最小単位はペア」にすることになった。
(3) Separate Work in a Pair / ペア内別作業
ペアワークだからといって常に一緒に作業をしないといけないわけではない。
- 必要に応じてペアで別々に作業をしても問題ない
ただし、あくまでも担当の最小単位はペア
- 一日の終わりには、そのペアのどちらに話を聞いても状況が分かるように認識を同期しておくこと
- そのため、ペアで頻繁に認識合わせをしておく
実際にうまくいった方法
- 時間を区切って「1時間後に共有しましょう」というようにしたらうまく同期できた。
(4) Frequent Breaks / 頻繁な休憩
モブやペアは想像以上に疲れるので、頻繁に休憩を取ることを忘れないようにする。
- 特にペアは気を抜くことができないので疲れる。
長くても1時間に1回は休憩を取ること。
- 例：45分作業したら15分休憩
- 例：25分作業したら10分休憩
休憩といってもずっと休んでるわけじゃないよ
- 気になってたことを調べたり
- メールの確認みたいな開発以外の作業をしたり
- チャットに返事をしたり、チケットを見てたりするから
(5) Engineer Evening Huddle / エンジニア夕会
毎日夕方にエンジニアだけで集まって共有や相談をする場を設ける
- 「話すことがあれば開催」ではなく一旦集まって「話すことがなければ解散」というスタイル。開催のハードルをあげないため。どうでもいい話もできるようにするため。
- 朝会のようにエンジニア以外が参加している場だと気を遣ってしまうような細かいコードの話やどうでもいいような話題が中心
- もちろんエンジニア以外の参加も歓迎する
具体的によくやるのはこんな感じ↓
プルリクエストの事前説明
- プルリクエストで「書き終わったコード」だけを見てレビューするよりも過程も共有したい
- なので、そのプルリクエストで何を考えてどんな風に修正をしたのか
- 主にどの辺りを見てほしいか、どの辺りが心配か、気にしなくても大丈夫な部分はどこか
- 動作確認やテストについての共有
など。これでプルリクエストのレビューの負担がだいぶ下がった。
設計判断の共有
- コードを書いてる途中でも、書く前でも、早い段階で設計判断を共有しておくと色んな意見がその時点でもらえるので、より良いコードがかける
悩み・不安の共有
- 何か悩んでたり不安に思っていたり困っていたりすることがあれば共有する
- エンジニアの不安はあたってることが多い
って感じなんだけど、これは、それまでモブでやっていたのをペアでも作業し始めて、情報が分断され始めたとチームが感じたときに、TRYとして始まったもの。
一日中モブをやってる場合は常に情報が同期されているのでこの会をスキップすることができる。実際に何度かスキップしている。
(6) Morning Huddle over 15 mins / 15分以上の朝会
朝会は15分以上かかることが多いけど気にしない。
実際のところエンジニアのタスクの状況共有は10分もかからないのだけど、その前に、プロデューサーからエンジニアへの同期というのをやってる。
プロデューサーからはこういう共有がある：
- 他部署との調整
- サービス運用に関わる共有や調査依頼
- ステークホルダーからの情報の共有
- 他の案件の準備のためのエンジニアの協力依頼
- などなど
チームの外側の状況は日々めまぐるしく変わっているのだけど、それをフィルタリングして大切なものだけを伝えてくれる。そのおかげでチームが開発に集中できるようになってきている。
そして、チームは「現在の状況の中でチームとして今日最優先にするべきことは何だろう？」って考えて取り組むことができる。
そんな感じ
自分が大切にしてるのは「気持ちの自然な流れ」。別々作業を基本にしてると「モブやってもいいですよ！」ってしててもなかなかそちらに流れない。モブの方が気持ちの位置エネルギーが高い感じ。
だから「モブを基本にします！でも別々に作業してもいいですよ！」ってしとくとエネルギーが低い方には自然と流れることができるので両方をうまく使い分けることができる。そういう仕組みづくりが好き。
全員が前向きに取り組んでくれてるし意見を出してくれるのでとても助かる。定着したものもチームの成長や周りの状況に応じて変化するので、定期的に見直していきたい。
