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

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

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

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

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

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

４歩進んで３歩下がる開発だった

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

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

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

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

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

Aさん「あれ、このデータってこのAPIで取得できますよね？」
Bさん「取得できないよ！」
Aさん「え！！(￣ー￣； ﾋﾔﾘ」
Bさん「え？？(￣ー￣； ﾋﾔﾘ」
Cさん「ﾔﾚﾔﾚ ┐(´ｰ｀)┌ ﾏｲｯﾀﾈ」

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

崩壊した原因とは？

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

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

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

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

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

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

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

f:id:AdwaysEngineerBlog:20161207143806p:plain

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

f:id:AdwaysEngineerBlog:20161207143817p:plain

崩壊した状態からの改善

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

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

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

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

f:id:AdwaysEngineerBlog:20161207143825p:plain

振り返りに力を入れる

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

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

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

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

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

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(１週間のうちの稼働日数) * 3(メンバーの数)

= 120 * 0.2 = 24

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

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

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

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

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