読者です 読者をやめる 読者になる 読者になる

ちょうど1年前にチームが崩壊した話

Adways Advent Calendar 5日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar/archive


どうも、大曲です。
とあるサービスのエンジニアをしています。
ちょうど1年の締めくくりとして、マネジメントの話を書こうかなと思います。

1年前にチームが崩壊した

1年前のこの時期に、立ち上げ時期からサービスを引っ張っていたエンジニアが退職することになりました。 退職したから、チームが崩壊したというよりすでに崩壊していた状態でした。

なぜ、崩壊していた状態なのか?

4歩進んで3歩下がる開発だった

4週間で大きな機能をリリースする。
3週間でその機能のバグ修正をする。

こんな状況が多発してました。
4週間でリリースするのは良いと思いますが 3週間ずっとリリースした機能のバグ修正をするという 品質担保の下手さが良く分かります。

最初の4週間で何を開発したの??と突っ込みどころ満載です。
ちなみにバグがない人は、この期間(リリース後の3週間)はめっちゃ暇になります。 (早く次の開発の話をしたいなぁ〜〜と思っていました。)

結合テストするたびに、必ず失敗する

フロントとバックエンドで開発の担当を分けることが多く 尚且つ、どんなデータを渡すか?どんなバリデーションを実装するか?は全て口頭でやり取りをするので 結合テストしようとすると、そもそも結合できないという意味が分からない状態でした。

Aさん「あれ、このデータってこのAPIで取得できますよね?」
Bさん「取得できないよ!」
Aさん「え!!( ̄ー ̄; ヒヤリ」
Bさん「え??( ̄ー ̄; ヒヤリ」
Cさん「ヤレヤレ ┐(´ー`)┌ マイッタネ」

上記の内容みたいな会話が何度も交わされました。
そして、結合テストのタイミングなので十分にコードを書く時間がないので 急ごしらえでコードを書くのでもちろんコードは見るに堪えない状態で さらに、JSONのAPIでキャメルケースとスネークケースが混ざったAPIが出来てしまうという なぜこうなったと叫びたくなるような状況でした。

崩壊した原因とは?

崩壊した原因は、2点あると考えています。

  • 事業の規模に対して、チームの開発スタイルがマッチしていなかった
  • エンジニア側の責任者を、ディレクターがやっていたこと

事業の規模に対して、チームの開発スタイルがマッチしていなかった

当時の開発スタイルは、各個人が好きなように開発するスタイルでした。
このスタイルでもうまく機能しているチームがいました。
これがなぜダメだったのか考えると二つのチームには違いがありました。 f:id:AdwaysEngineerBlog:20161207180020p:plain

このようにチームの開発の割り振りが、異なっていたので今回のサービスの場合だと
各個人が好きなように開発した機能は同じチームメンバーが開発した機能と結合しなければなりません。
そのため、結合テストで毎回失敗してしまう状況が多発しました。
また、サービス自体複雑になったことや単純に一人でサクッと開発できるシステム構成ではなくなったので 各個人が好きなように開発できなくなっていました。

エンジニア側の責任者を、ディレクターがやっていたこと

責任者がディレクター自体は、別にダメなことではありません。
ダメだったことが、エンジニア側のチームの方向性を決める人がいなかったことが原因でした。
エンジニア側の責任者ディレクターがサービスの品質を守るためにひたすらテストを頑張っていたり コードレビューは時間がかかるからとコードレビューをしないようにしたりと改善のやり方が間違っていました。
これにより、エンジニア側もディレクター側もお互い疲弊する状態になっていました。

f:id:AdwaysEngineerBlog:20161207143806p:plain

現在は、ディレクターなしのエンジニア側はエンジニアがリーダーをやっています。

f:id:AdwaysEngineerBlog:20161207143817p:plain

崩壊した状態からの改善

具体的な原因を書いておいて、具体的な解決策を書こうと思ったのですがやった内容が細かすぎて うまく書けませんでした。すみません。。。

そこで、チームを改善する上で自分なりにチームで大切にした点を書こうかなと思います。 大切にしたのは以下の3点です。

  • 振り返りに力を入れる
  • 改善を当たり前のように行う
  • 公平と不公平を明確にする

ちなみに、大枠でまとめるとチームの立て直しの流れは以下の通りです。

f:id:AdwaysEngineerBlog:20161207143825p:plain

振り返りに力を入れる

チームにとって、一番危険な状態は今のチームの状態把握ができないことだと考えました。
また自分にとって問題だけど、ある人にとって問題ではない場合がありチームにとっての何が問題なのかを明確にする必要がありました。
そのために振り返りを行うことによって、強制的に問題の認識と改善までの手段をチーム内で共有できるようにしたいと思いました。
そこでJIRAを使ったスクラム開発を行うようにしました。

スクラム開発の変更の流れ

  1. 1週間単位でのスプリントを実行
     (振り返り対象: すべての完了したタスク)
  2. 1週間単位でのスプリントで、タスクの見積もりを出して3~4日分のタスクを入れてスプリントを実行
     (振り返り対象: 完了したタスクで、見積もりの150%以上だったタスク)
  3. 2週間単位でのスプリントで、タスクの見積もりを出して6~8日分のタスクを入れてスプリントを実行
     (振り返り対象: バージョン※完了後、見積もりの150%以上だったタスク)
  4. 2週間単位でのスプリントで、タスクの見積もりとストーリーポイントを出して6~8日分のタスクを入れてスプリントを実行
     (振り返り対象: バージョン※完了後、総括して反省する)

約1年近くかけて、ようやく各メンバーの時間(見積もり)と質(ストーリーポイント)の関係が出せるようになりました。
自分たちの中で、やるメリットや意味を理解して少しずつ変更して行ったのであまり副作用的な内容は発生しませんでした。

スプリント閉じ会の会議は、隔週の金曜日で17時〜21時までお寿司を食べながらやっています。(長い時は17時〜23時までやったこともあります)
僕らはあまり会議を作らないチームにしているのでスプリント閉じ会で一気に相談事や共有事項などもやるようにしているため 1回の会議がかなり長いです。

f:id:AdwaysEngineerBlog:20161207143839p:plain

こうやってポイントをそのまま評価に加えると、裁量制みたいで面白そうですね。(大きな機能のリリースの時に一気にストーリーポイント消化が増えたりします!!)

また、半年に一度に大会議と称して1日かけての振り返りの会議をやっています。
ここで、各個人の振り返りや開発フローの大きな変更、サービスと改善のロードマップなどを作って 次の半年の方向性を決めています。 まだ、2回しかやっていませんが自分達のチームの方向性を見直せるので有意義な会議になっています。

※バージョンとは、JIRAのバージョンのことです。 僕らのサービスでは、バージョンごとで大きな開発を分けています。
https://ja.confluence.atlassian.com/servicedeskserver030/organizing-work-with-versions-761768983.html

改善を当たり前のように行う

僕らの考えとして、当たり前のように改善し続けるチームであってほしいと思っています。なので改善に対しての意識も、改善タスクを無意識に出来るようにするしたいとずっと考えてしました。(ここで言う改善タスクは、リファクタリング、チューニング、可視化、新しいツールの導入などです。)

改善をやろうとした時に決めたことが以下の通りです。

  • 改善に割り当てる時間はチーム全体から捻出する
  • 改善をやる人は、各メンバー全員に平等にやれるようにする
  • 改善はなるべく小さく続ける

改善に割り当てる時間はチーム全体から捻出する

改善に使う時間をチーム全体の作業時間の20%とすると

チームメンバーが3人の場合

8(1日の作業時間) * 5(1週間のうちの稼働日数) * 3(メンバーの数)

= 120 * 0.2 = 24

他の2人が通常の仕事をする代わりに、1人は5日ある内の3日間も改善タスクに割り当てられるのでやれる範囲も広がります。
今は、チームメンバーが5人になったので丸々1週間を運用と改善の週として既存の仕事を止めて運用と改善のタスクをこなしています。
(もちろん既存の仕事が遅れていたら、そちらをやります!!)

改善をやる人は、各メンバー全員に平等にやれるようにする

主観的な意見で言えばエンジニアのやる気を上げる仕事とやる気を下げる仕事が存在すると思っています。
改善のタスクは、やる気を上げる仕事(新しいツールなどの導入などがあるので)が多いので 一部のメンバーに偏らないように交代制にするようにしています。

改善はなるべく小さく続ける

改善するタスクの内容は、なるべく細かな粒度で出来るようにしています。
なるべく、だいたい3日以内に終わるタスクの粒度にしています。
(最低でも1週間以内のタスクに落とし込む)
Scalaの導入に関しても、少しずつやれる領域を増やしていきました。
(バッチ処理, デーモン処理, 管理画面のAPI, 配信の基盤 この順番で導入していきました。)

公平と不公平

チームのメンバー内で公平にすべきことと不公平にすべきことを明確に認識してマネジメントしました。

公平にすべきこと

  • 改善タスクの頻度
  • 作業的なタスクと障害対応

不公平にすべきこと

  • 働き方
  • 報酬

公平にすべきは、メンバーがやりたいことへのチャンス(改善のタスクの頻度)や誰でも出来る作業の負担(ビジネス側からの質問対応)だと考えています。そのため、こういった内容はチーム内で必ず交代制にしています。 障害対応なども、大半はメンバー全員が対応できるようにしています。

(広告配信が止まったなどのクリティカルな障害は全員で対応しますが 管理画面の挙動がおかしいなどの調査は、その週の障害対応担当の人が調査してくれます)

不公平にすべきは働き方や報酬だと考えており、仕事に対する品質が担保できるから自分が好きな働き方(リモートワーク)を選べることや仕事が進捗通りだから有給消化する動きがあって良いと思っています。

この1年を振り返って

CI導入、RDSへの移行、FinagleやAngular2の採用、Hubotの利用、配信関係の可視化...etc 色々やりました。よく1年間でやったなと思います。 うまくチームでの仕組み作りが成功したから、ここまで改善できたと思っていますしチームのメンバーにも恵まれたなと感じました。

また、1年前の状況と比べてチームへの周りからの評価がガラリ良い方向に変わったことは嬉しかったです。非常にありがたいことに「さすがだね」や「攻めてるね」という言葉もいただくようになりました。頑張ってよかったです。そして、来年も頑張ろうかなと思います。

最後に

マネジメントに関しての記事は、初めて書くのですが難しいですね。
次回書く時は、もう少しまとめられたらいいなと思います。


次は渡瀬さんの記事です。

http://blog.engineer.adways.net/entry/advent_calendar/06