エンジニアチームの体制作り、メンバー育成(現在在籍している企業にて)
「最強の開発チーム」です。(というお題だけがありました...)
エンジニアに明るい人があまりいなかったので最強の定義についてはあまり議論できていなかったように思います。要は、あらゆる要求に柔軟にスピーディに対応できるチームにしたい、ということだったと思います。
チームといいつつ、数人の間は個の力が重要と考えていました。
なので最初はメンバーの育成を中心に考えました。
スタートアップであるため、人的リソースを1ミリも無駄にはできません。しかし要求がぼんやりした状態で案件がくることも少なくなく、開発工程の一部しかできないと待ちが発生することになるため、全員がどんな案件がきても対応できるくらいにスキルを強化しようと考えました。それが集まれば強いチームになると考えました。
そのため最初に以下のような方法論を私が考え実行しました。
・何にでも対応できるよう1つの案件に対し1人をアサインし、そのメンバーが最後まで責任を持ちメンバーの裁量で完遂する。(分担するとコミュニケーションコストや待ちが発生するため、リソースを無駄にしない、というもう一つの目的のためでもあります)
・コードの品質は担保したいので必ずコードレビューをする
・困った時や、重要な設計の場面で分からないことがあれば、いつでも質問ウェルカムな状態にした。(縦割りな体制をフォローする)
・定期的に1on1MTGを行い現在のスキルや目標のすり合わせをする。
これがあまりはまりませんでした。
特に問題となったのがコードレビューで、以下のような課題がありました。
・レビューアーが案件の内容把握から入るためレビューの負荷が高い
・プルリクの粒度が個人に委ねられているので大量の差分が発生することも少なくなく、レビューの精度が落ちる
・設計をちゃんとすり合わせていないと設計からちゃぶ台返しが発生することがあってレビューアーもレビューイも精神を削られる
リソースを無駄にしないためにあえてコミュニケーションを抑えていたことと、必要な場面では質問等しやすい状況にしていたものの、そのアクションを個人に委ねていたため想定より情報共有や設計の相談がされなかった、といったところが今となっては原因だったと思います。
その中でレビューで上記のようなことが起きると余計コミュニケーションが取りづらくなる悪循環に陥り、それでも個人の問題と思い込んでいたため改善策を見出せない状態が続いていました。
これが後に劇的な改善に向かうわけですが、私から問題提起をしたり何か工夫をしたことがきっかけではなく、メンバーが「もっとチームでわいわいやってみたいんですよね」とぽつりと言った一言がきっかけでした。
私が手綱を握ることで失敗した過去があったので、「メンバーみんなで話し合い、メンバーが良いと思うやり方でやって、またみんなで振り返る」というやり方でチーム作りを行い、私はそれがスムーズに進行するようにサポートすることに徹しました。
試行錯誤して生まれたのが、個とチームプレイのハイブリッドな開発体制でした。
・要求・要件の整理はコンスタントにやらないと開発タスクが枯渇する。そこをチームで行うとバランスよく進まないため、これまで通り個人が行う。
・外部設計以降はチームで考えるターン。個人が整理した案件をチームに共有して、誰かが設計の叩き台を作りみんなで議論しながら内部設計までブラッシュアップする。
・開発はスクラムをベースとして、上記の議論した結果からタスクに分解して実装していく。認識がすりあっている状態なので誰がタスクを取ってもよく、リソースの無駄もなくなる。
今は上記の体制の上で、2週間単位でスプリントを切って2週間でやることを相談しながら進めています。
そしてその2週間の最後にはレトロスペクティブという振り返りのMTGでチーム運用での課題とその解消方法を話し合い、改善を回していくサイクルを作っています。
また一番大きなレビューでの問題も完全に解消されました。
・案件の内容は知っているのですぐレビューに入れる
・1つの案件に対し複数のタスクで分解するので、自然と1プルリクが適量になり、レビューの精度が保たれる
・設計を事前にすり合わせてるので誰がやっても大体同じアウトプットになり、ちゃぶ台返しが全く起こらない
設計をみんなで考えたりレトロスペクティブの実施など、コミュニケーションコストについては最初とは全く逆の考え方でコストをかなりかけるようになりました。
ただそれにより全員の認識が常に合っている状態が保たれ、各々が各々の分身のように動けるようになり、トータルで見るとパフォーマンスは上がりました。
みんなで考えて実施することがこんなに目に見えて改善に繋がるとは思っていなかったので、むしろ自分が成長させてもらった感覚があります。
もともとの「最強の開発チーム」を作るという代表からのお題に関して、結局代表とはあんまり話できてはいないのですが...開発チーム内では「全員が常にベストだと思えるチーム」にしようということになって、もうそれがイコール最強なのかなと思っています。
転職したらそこの開発チームの特色はあると思いますのでその良さを壊さないようにはしたいと思いますが、私が学んだことの良さをうまく出していければなと思っています。