スマートキャンプで開発リーダーをしている笹原です。
師走、ということでみなさん、色々な振返りをしているのではないでしょうか。
本日は、私が入社してからボクシルの開発プロセスがどのように変わっていったのか、 そのときどきの課題とともにお話していきたいと思います。
- 2018年4月〜2018年9月: みんなボクシル
- 2018年10月〜2018年12月: 新規事業群雄割拠
- 2019年1月〜2019年3月: 運用とグロースの2チーム化
- 2019年4月〜2019年6月: ボクシルワンチーム化
- 2019年7月〜2019年9月: フロー効率をバリバリ上げてこう
- 2019年10月〜: Visionやロードマップに沿った開発へ
- まとめ
2018年4月〜2018年9月: みんなボクシル
2018年4月に、スマートキャンプ株式会社に入社しました。
このときは、開発しているプロダクトがボクシルのみで開発メンバー全員でボクシルの開発をしていました。
開発プロセスは決まったものはなく、各々が各部署からの要望をそれぞれ受けているような状況でした。
このときは、開発プロセスを振り返って改善していこうという取り組みは特になかったように思われます。
ただ、システムの改善には積極的に取り組んでいて、特に、アプリケーションの安定性向上などが優先度の高い課題でした。
- エラー監視
- Bugsnag導入
- リソース、ログ監視
- Mackerel導入
- 断捨離
- いらない機能削除
- DB要らないテーブル削除
- ローカル開発環境整備
2018年10月〜2018年12月: 新規事業群雄割拠
2018年10月頃から新規事業の開発をするべく、ボクシルの開発リソースが一気に減ります。
新規事業をやっているメンバーには、ボクシルの障害発生時に手を貸して貰う形でした。
その頃のボクシルは、流入を増やしていくことが一つの目標であり、数ヶ月で2倍3倍と流入が増えていきます。
その中で、開発ではパフォーマンスの課題が深刻になり、ちゃんとした負荷試験を実施するようになりました。
また、エグジットに向けて内部統制を効かせていく必要がでてきたのもこの頃です。
AWSなどの開発で利用するリソースの管理を適切にできるような状況にし始めてました。
開発リソースが一気に減ったこと、流入が増えたことでパフォーマンスの改善をしないといけないこと、などから当時はほかチームからの開発要望をだいぶ絞って対応していました。
2019年1月〜2019年3月: 運用とグロースの2チーム化
2019年1月からは、新規事業Bの仮説検証フェーズが終わり一旦開発リソースを使わずに進めていく判断がされたことから浮いた人員をボクシルの開発に入れていきます。
その際に、以下の理由からもともといた2名を運用チームとした上で、1名のグロースチームを立ち上げることにします。
- オウンドメディアへの流入を増やすことに注力したい
- 運用や内部統制にかかる工数は別途確保しておきたい
2019年4月〜2019年6月: ボクシルワンチーム化
運用とグロースで2チームに分けていたことでボクシル開発チーム全体でのコミュニケーションが不足していき以下のような弊害が出ていました。
- 開発リソース全体として、優先度の高いものから取り組めているかわからない
- 両方のチームで開発内容を確認するためオーバーヘッドがかかる
そういった問題が発生していたことと、内部統制を敷くことが一旦の落ち着きを見せたことから、再度、ボクシルを一つのチームで開発していくことにしました。
それに際して、チームビルディングのためにインセプションデッキを作成しました。
インセプションデッキを作成することで、お互いが何を大事にしているのかを知ることができ、その後のコミュニケーションが円滑に行えるようになりました。
また、このタイミングからチームでの開発プロセスの振返りとして隔週でKPTをはじめました。
自分たちのプロセスを自分たちで改善していく仕組みを徐々に作っていきます。
モブプロを少しずつ取り入れ始めたのもこの頃です。
ここから急速に『チームで開発に取り組む』ようになっていきます。
2019年7月〜2019年9月: フロー効率をバリバリ上げてこう
チームで開発を取り組むようになったものの、チームで目指す目標が明確に設定されていないため、チームが前に進めているのかわからない状態でした。
そこで、7月にボクシルの開発チームの目標を明確に設定します。（目標をどう設定していっているのか、についてはアドベントカレンダーの中でまた別のエントリを書こうと思っています。
メインの開発目標として掲げたのは、開発のフロー効率の向上でした。
フロー効率を上げていくために、タスクのフローに注目しやすい開発プロセスとしてKanbanの要素を多く取り入れるようになっていきます。
また、開発のフロー効率を上げていくことを明確な目標としたことで、プロセスの振返りが更に重要になります。
隔週では軌道修正やTryの回数が少ないので、頻度を上げて、毎週振返りとしてKPTをやるようになりました。
目標設定や、振返りの甲斐もあってか、フロー効率の指標の一つとしていたリリース回数が8月に一気に上がります。
2019年10月〜: Visionやロードマップに沿った開発へ
開発チームが変わる中、裏では採用プロセスも改善されていき、2019年10月には1年ぶりの新規エンジニアのチームへの参画がありました！！！
新しいエンジニアが入ることで、今まで暗黙知となっていたことを明らかにする必要があり、ドキュメントベースでのやりとりが一気に増えました。
開発タスクは誰でも着手できるような粒度でオンライン上に書き残すようになったり、複雑な仕様についてのドキュメント化が進むことで属人性が下がっていっています。
チームで開発することやそのプロセスが整うなかで直近で課題になっているのが、中長期的なプロダクトの方向性とそれに向かって開発するための見通しです。
チームでは見通しを立てるために、Biscuetチームがすでに回しているScrumの要素を少しずつ取り入れていっています。
まとめ
こうして振り返ると、3ヶ月おきくらいで大きくチームが変化していっているのがわかります。
そのときどきの課題に合わせて、柔軟にチームのあり方を変えながら対処できていっているのは弊社の良さだなと感じています。
次の3ヶ月でまたどんな課題に立ち向かい、どんなチームになっていくのか、楽しみです！！
明日は弊社エンジニアのタッキーによる「fullstoryとlogrocketの記事」です！おたのしみに！
