フロントエンドエンジニアの笠原です。こんにちは。 新型コロナウイルスの影響で「全員在宅勤務」のアナウンスが出てから早くも 9 ヶ月近くが経ちました。 その間にプロダクトチームの体制が再構築され、チームメンバーの変更もありました。
この数ヶ月の間にリアルで顔を合わせずに集まったメンバーで始まり、そして完了したプロジェクトを経験しました。 今回はそのときのプロジェクトでチームがどう移り変わっていったか?というお話をします。
チームの移り変わり
あとから思い出したときに、その時々の状況がタックマンモデルに近いと感じたので(少し無理やりですが) 4 つの段階にわけて書いていきます。
形成期
ディレクター 2 人と開発メンバー 3 人の計 5 人でスタートしました。 プロジェクトの内容は Classi の中でも校務系と呼ばれているプロダクトの機能追加でした。詳細は内容の簡単のために割愛します。 個人的には慣れたプロダクトでもなければ、一緒に働いたことのあるメンバーもいなかったのでかなりそわそわしていたのを覚えています。 MTG は Google Meet で行っていましたが、それ以外は Slack のテキストコミュニケーションが多かったように思えます。 プロジェクトの概要は決まっていたので、ディレクターから開発メンバーへのインプットを行う MTG が多い時期でもありました。 困ったときに少しでも話しかけやすい雰囲気にするために下記をワーキングアグリーメントととして決めました。
- Slack で開始 / 終了時のあいさつをする
- Google Meet で朝会をする
- Google Meet で15 時におやつたいむという名の雑談時間を設ける
毎日顔を合わせる時間が持てたので、割とすぐに雑談はできるようになっていた気がします。
混乱期
雑談レベルのコミュニケーションが取れるようになってきて、プロジェクトのインプットもできてきたころ、スクラム開発を導入してみました。 慣れないチームで、ある程度スケジュールも決まっているプロジェクトだったのでスクラムの各種イベントを設定したほうが一週間のリズムができていいのではないか?というのが理由でした。開催したスクラムイベントは下記の通りです。
- デイリースクラム
- スプリントプランニング
- スプリントレビュー
- レトロスペクティブ
- プロダクトバックログリファインメント
またこの頃からバックログを作り始めました。プロダクトバックログとスプリントバックログには Asana を使用し、それぞれ Asana のプロジェクトをわけて運用していました。 バックログの管理の仕方やスクラムイベントの進め方などは、以前僕が所属していたチームのやり方を持ってきました。そのため他のメンバーは慣れるまで覚えることが多かったかもしれません。 また、決して余裕のあるスケジュールではなかったので各ストーリーどこまでできたら done とするのかを決める「完成の定義」を作ったり、いざというとき何を優先するか(何を諦めるか)を決める「トレードオフスライダー」を作ったりしました。これによってみんながどういう風に考えているかや、チームとしての共通認識が深まったと思っています。
2 スプリントくらい回したところでスプリントレビューの場に QA メンバーの知見も欲しいという意見が出てくるようになりました。もともと QA メンバーはチーム外にいて、リリース前の検証で初めて関わる役割だったのですがスクラムチームのメンバーとして入ってもらうようにしました。QA メンバーがチームに入ることによりスプリントごとに検証の観点を QA 視点で確認できるようになり手戻りが少なく済みました。同じタイミングで開発メンバーももう一人くらいいると円滑に動けそうだったので、ここで QA メンバー +1 / 開発メンバー +1 の計 7 人になりました。(少しあとのタイミングでディレクターの一人が別案件に移ったので最終的には 6 人で進めました)
開発面ではモブプロを始めてみました。最初はどのくらいの頻度でやるほうがいいのか探り探りだったこともあり、「午後の数時間だけやる」とか「困ったらやる」といった感じでした。しばらく経ってくると「モブプロ良い」というコメントがレトロスペクティブで出るようになってきました。
一方で自分たちの作業時間を把握できていなかったり、「完成の定義」や「トレードオフスライダー」を作る時間を取ったりしてプランニングで決めたことが全部終わらない、という週が少し続いていたりもしました。
統一期
最初は少しずつ始めたモブプロでしたが、この頃には朝会が終わってすぐに Slack call でモブプロをするようになってきました。今回のプロジェクトでは詳細にベロシティの記録をしていなかったので感覚値になりますが、モブプロになったことでスピードが落ちたと感じることも、そのように指摘されることもありませんでした。逆にみんなで一つずつタスクを完了にしていく進め方になったのでどのタスクも自分ごとに捉えられて「終わらせるぞ」というモチベーションが上がっていたようにも思えます。
また今までは一通り実装を追えたあと、ステージング環境にデプロイしてディレクターに確認を依頼していたものを、軽微なものはローカル環境で実装中の画面キャプチャを見てもらう、といったように気軽にコミュニケーションが取れるようになってきてフィードバックを早くもらう工夫もできてきました。
進捗も安定してきてスケジュール感が把握できるようになってきました。これによって、すべての機能を作ってからのリリースではユーザーが使いたいタイミングに間に合わない、といった話も出てきて一部の機能だけ先行リリースをするといった決定もできました。
機能期
このころは開発メンバーだけでなくディレクターや QA メンバーを巻き込んで開発するのが日常的になっていました。 開発メンバーがモブプロで実装している途中で、ちょっとした疑問や相談事ができた場合にはすぐにディレクターを Slack call に呼んで作りかけの画面を見せながら相談をしたり、逆にディレクターや QA に相談ができたときは開発メンバーが作業している Slack call に気軽に入ってきて話しかける、という動きができていていい意味で遠慮がなくなってきました。
またレトロスペクティブのときに「みんなが同じくらい発言するようになってきた」というようなコメントも出てチームとして成長しているんだと実感したのを覚えています。
最後は無事予定通りリリースすることができました。
まとめ
僕自身、全員リモートワークになるまでは基本オフィスに出社していたためリモートワークに慣れておらずチーム作り新チーム体制に結構な不安がありましたが、リモートワークでもチーム作りはできるんだという学びを得ました。 今は様々なサービスにあふれていてオンラインでもツールに困ることも少なかった気がします。
すべてが終わったあとに開催した振り返り会では「チームの人数がちょうどよく、皆がこのプロジェクト専任だった」・「すぐ話せたり、カメラオンでリアクションがありコミュニケーションが密だった」といったコメントがありこの辺りもいい効果を生んだのではないかと思っています。
リモートワークが基本の会社も増えてきていると思うので、もしリモート環境下でのチーム作りに悩んでいる人の参考になれば幸いです。