こんにちは。クラシコムのエンジニアマネージャーをやっている濱崎（@avosalmon）です。クラシコムのエンジニアチームはこの1年でメンバーが増えて、2018年10月で8人になりました。（1年前は3人でした）

一緒に仕事をする仲間が増えるのはとても嬉しいことなのですが、人数が増えるにつれて1つのチームでは身動きが取りづらくなってきました。今回の記事では、そんな状況を改善するために僕たちが最近取り組んでいることについてお伝えします。

目次
・1年間で大きくなったチーム
・改善策を検討
・チームを分割
・短いサイクルで数多くリリース
・チーム間のコミュニケーション

1年間で大きくなったチーム

1チームで動くには人数が多すぎる
2017年9月の時点で3人だったチームが徐々に大きくなり、2018年5月には6人で1つのチームを運営するようになっていました。この時点で朝会やミーティングでのコミュニケーションコストがかなり大きくなっていました。また、1チームで全ての業務領域を担当していたので、タスクの優先順位を決めるのが難しい状況でした。各メンバーの責任範囲が曖昧になり、誰が誰のコードレビューをするのかも明確ではなかったため、結果的に古株の僕にレビュー依頼が集中してレビュー待ちがスタックしてしまうこともしばしばありました。

進捗を実感しづらい
以前は2週間のスプリントで計画を立てて仕事を進めていましたが、2週間分のタスクを見積もるのは難しく、計画通りに進むことは滅多にありませんでした。また、1つ1つのタスクの粒度が大きかったため、何日も同じタスクをやっているという状況が続き、仕事の進捗を実感しづらかったです。進捗を感じにくいというのは、精神衛生上よろしくありません。

その他の課題
ほぼ未経験の新人エンジニアが5月に入社したのですが、固定のメンターが付けられておらず、その時々で先輩エンジニアが交代で指導をしていました。
また、システムの信頼性を高めるためのSRE的な活動にあまりリソースを割けておらず、将来的にリスクになり得る要素が溜まりつつありました。

改善策を検討

10月に新しいエンジニアとデザイナーの入社が決まっており、同じやり方を続けていたら破綻するのは目に見えていました。そんな状況を変えるべく考えを巡らせ始めたものの、初めての経験なので考える手がかりがありませんでした。

ちょうどそんなタイミングで参加したLaracon USで、BasecampのCEOであるJason Fried氏の話が手がかりになりました。Basecampでは6週間のサイクルで仕事をしています。「どんなプロジェクトに取り組むか」「どんなチーム構成にするか」を6週間ごとに決めて実行しているそうです。つまり、6週間以上かかるプロジェクトは基本的に存在せず、6週間を超えそうな場合はプロジェクトのスコープを削り、小さな単位でリリースしていくのです。チームの規模も小さくて、1チームの人数はMAXで3人。今まで大きな単位で物事を捉えていた自分にとってはすごく新鮮な話で感銘を受けました。（1年ぐらいの長期プロジェクトもやってきたので）

そんな手がかりをもとにいろんなチーム構成や運営方法を考えてみましたが、クラシコムとBasecampでは状況が異なるので、自分たちにフィットする形を模索していきました。何とか草案をまとめてメンバーに共有したところ、いろんな突っ込みやアイデアが出てきたので、そこからはメンバーと一緒に考えることにしました。彼らと2日ほど議論し、納得のいく形にまとめることができました。1人で考えているとだんだん辛くなってくるし、複数の頭で考えた方がいろんなアイデアが出てくるので、これからはもっと早い段階でメンバーに相談して一緒に考えようと思います。

チームを分割

新しいチーム構成では、エンジニア3〜4人の2チームに分け、デザイナーとプロダクトオーナーがチーム横断的に動いています。プロダクトオーナーの役割は弊社代表の青木が担っています。後々は各チームにデザイナーが1人ずついる構成にしていきたいと思っています。ビジネスの変化やメンバーの状況に柔軟に対応していけるように、3ヶ月ごとに取り組むテーマとチーム構成を変えていく予定です。

分け方の基準
・チーム内でコードレビューが完結できる。レビューし合えるなら1チーム2人体制でも良い。
・新人には専任のメンターを1人つける。

改善されたこと
・コミュニケーションコストが減った。（MTGが短くなった）
・各チームの責任範囲が明確になった。
・1人当たりのレビュー量が減った。
・新人のサポートをしやすくなった。

短いサイクルで数多くリリース

取り組むテーマとチーム構成が決まったら、各チームは1週間のサイクルで仕事を進めます。以下のように、作る機能の仕様決定・実装・リリースというフローを1週間のサイクルで回していきます。

[1] プロダクトオーナー・デザイナーと一緒にプロトタイプを見ながらディスカッション、仕様決定。

[2] エンジニアはその場で実装方法を設計。

[3] エンジニアは時間で見積もりをし、1週間で作ってくる内容をプロダクトオーナーとコミットする。

[4] 1週間後、作ってきたものをデモする。プロダクトオーナーから合意が取れればリリース。

プロジェクトのサイズが大きく、2週間のスプリントで開発していた以前と比べて、以下の点が改善されました。

改善されたこと
・小さなものでも毎週何かを作って動くものを見せることで、具体的な議論ができる。
・エンジニアもプロダクトオーナーも仕事の進捗を実感しやすい。
・1週間ごとに計画するので見積もりに大きなズレが生じにくく、軌道修正もしやすい。
・SRE的な課題に一定のリソースを使えるようになった。（プロダクトオーナーとコミットしたもの以外は、新しい技術の検証や技術的負債の解消などに時間を使うことができます）

チーム間のコミュニケーション

チームが分かれたことで、チーム間の情報共有がしづらいといった課題も出てきましたが、「全てが共有されているべきだ」という前提に立ってしまうと、またコミュニケーションコストが増えてしまいます。他のチームを信頼して任せたり、必要な情報は自分から取りに行くことも大切です。

とはいえ、全く共有しないわけにもいかないので、週1で全体の共有MTG（30分）をしたり、全体に影響することは早めに共有するといった心がけをしています。また、チームをまたいでコミュニケーションする機会として、技術勉強会・読書会・全員でランチなどを行っています。

・・・・

新しい体制になって改善されたことも多いですが、まだこのやり方を始めたばかりなので、試行錯誤しながら継続的に改善していきたいと思っています。

クラシコムではエンジニアの仲間を募集しています。興味のある方は気軽にオフィスに遊びにきて下さい🙂

エンジニア&デザイナーもくもく会やってます！週末に勉強したい方はお気軽にご参加ください🙂