お子さんのご誕生、おめでとう！
スマートキャンプのプロダクトマネージャーの郷田です。
近頃、育休を取得されたエンジニアの方の記事をよく見かけるようになりました。
そんななか、弊社スマートキャンプでも直近でエンジニアが育休を取得する機会があったのですが、
本記事では逆の視点、つまり残されたメンバーの視点から、「育休でエンジニアリーダーが不在となった開発チームに、どのような変化があったのか？」をお届けします！
開発体制
はじめに、我々のチームではどのような体制で開発を行っているのかを紹介します。
スクラムでのプロダクト開発
我々のチームではスクラムのプロセスを取り入れたプロダクト開発を行っています。
『スクラムをどのように実現しているか？』については以前投稿した以下記事をご覧いただければと思います。
チームの編成
エンジニアリーダーがいた頃のチーム編成をご紹介します。 今回はこのような体制の中でTさんが1ヶ月の育休を取ることとなりました。
| 担当者 | 所属チーム | 役割 |
|---|---|---|
| 郷田さん | POチーム | プロダクトマネージメント、元エンジニア |
| Tさん | エンジニアチーム | チームリーディング、テックリード、育休とった人 |
| Hさん | エンジニアチーム | エンジニアリング、デザインもする人 |
| Aさん | エンジニアチーム | エンジニアリング、インフラ強めの人 |
| Cさん | エンジニアチーム | エンジニアリング、アプリ開発中心の人 |
※ビジネスサイドのメンバーは省いています。
エンジニアリーダーの業務
育休前にエンジニアリーダーが担っていた業務や役割は以下になります。
- エンジニアリング
- フルスタックの開発
- サーバーサイドでは開発をリーディング
- 技術選定
- アーキテクチャ設計や外部連携設計
- リモート時短の業務者へのタスク割り振り
- フルスタックの開発
- スクラム
- 開発環境の改善に対する、アイデア出し・優先度付・工数の見積もり
- PdMの新機能アイディアに対する、実現可能性と工数の見積もり
- プランニングのファシリテーションと推進
- 生き字引き役
- 古い実装の経緯の把握
- プロダクトの立ち上げ経緯のフェーズからエンジニアリングでの関わり有り
- 古い実装の経緯の把握
育休に入るまで
以下のタイムラインで育休に向けた準備を行いました。
- 育休取得の3ヶ月前
- 開発チームへの共有、相談
- 育休取得の1ヶ月前
- MTGにて、起きうる問題の洗い出し
- 育休取得の1週間前
- MTGにて、問題と対策を整理
不在時の問題と対策案の共有
POチームも含めて課題を話し合い、不在時にどのような問題が起きるか、それらにどのような対策が想定されるかをディスカッションし、チームの認識合わせを行った結果が以下となりました。
その１：業務委託のタスク割り振りに困る
対策案：
- スプリントプランニングに1Step追加し、チーム全体でタスク割り振りを実施
その２：技術的な意思決定に困る。アーキテクチャの設計や、コードの品質が下がるかもしれない
対策案：
- 外部アドバイザーに意見を求める
- 意思決定は3名全員でディスカッションして決めることとする
その３：開発スピードが下がる
対策案：
- POチームにてスピード低下を前提とした事業計画の見直しを行う
その４：さみしくなる
対策案：
- お子さんの成長記録を流すslackチャンネルを作って運用してもらう
実際にエンジニアリーダー不在となって
困ったこと
準備はしていたものの、いざ不在となると発覚する困りごとが沢山ありました。
1. エンジニアリーダーによる「意思決定」がなくなったこと
事前MTGでも技術的な意思決定に困る可能性がある件については検討していましたが、やはりエンジニアチームで行う意思決定の多くにエンジニアリーダーの意見が反映されいていたため、実際に不在となると「どうしよう？」と困るシーンが多かったようです。
2. 既存のコードでリーダーに依存していた部分が多かったこと
エンジニアリーダーが不在となることで、エンジニアリーダーのみが把握していたコードがあることがわかり、それらに対する改修を即座に行えない状態となっていました。
3. ビジネスサイドからのざっくりとした開発要望の所感を聞く相談相手がいなくなったこと
「コレを実現してみたいけど、それってできるの？」といった相談をする相手がエンジニアリーダーとなっていたため、どこで誰に相談すればいいのかがわからない状態となっていました。
困ることで起きたポジティブな変化
実際に不在となるとエンジニアリーダーへ依存していた業務が沢山有ったことに再認識させられました。
それにより、開発メンバーは業務を進めるために自分が調べて「意思決定」をし、「コードを書く」必要がでたこと、またPOチームは開発チームに聞く前に「もう少し自分で調べる」時間を作り実施するようになりました。
エンジニアリーダー不在による穴は大きいものだったため、特に不在となった初期のころはスピードがかなり下がってしまいましたが、それにより一人ひとりの業務理解度があがり、1ヶ月が終わる頃にはメンバー全員のプロダクトや業務の解像度が上がり、不在の穴を充分に埋められるほどになっていました。
思ったより、困らなかったこと
もっと困ると思っていたが、実際には困らなかったことも有りました。
スクラムによる恩恵
弊チームではスクラムの以下イベントのファシリテーションを毎回ランダムに決めています。
- デイリースクラム
- リファインメント
- スプリントレビューでの開発デモ
- レトロスペクティブ
- スプリントプランニング
これにより、各イベントへの理解度がスクラムマスターやエンジニアリーダーに偏らず、不在時も自然とスクラムを回すことができていました。
また、開発チームはメンバー全員の開発可能な合計時間（キャパシティ）と、過去の実績から実施可能ポイントの見積もりを行っています。
これにより、1名が不在となった場合に消化できるポイント（開発可能なタスク量の見積もり）ができていたため、タスクを詰め込みすぎる開発とならずにイテレーションを回すことができました。
育休期間を終えて
一人ひとりの感想
Hさん
- 既存機能がエンジニアリーダーに属人化している部分が多い認識はあったため、不在となることに不安があった。
- 属人化していた部分も開発を進めるために、メンバー全員でコードテストを書くことや複雑な機能のロジックのコードリーディングをして理解ができるようになったのは良かった。
- 開発プロセスはスクラムを導入して数ヶ月前から作り上げていっていたので、大きく困ることはなくいい感じに進めることができてよかった。
Cさん
- 育休に入るまでは不安感あった。新機能の設計・開発が、というよりも既存の複雑であったり属人的な機能で不具合が発生したら解決出来るのかな、みたいな漠然とした不安があった。
- 育休期間中は自分たちでやらざるを得ない環境になったことで、自分があまり触ってこなかった領域も触るきっかけになったしその結果アプリケーションの全体感がより立体的になった。
- そのおかげで上述の漠然とした不安みたいなものが薄くなった。「読んでもわかんないかも」から「読めばいけるかも」になった。
Aさん
- 技術的な部分はもちろんだが、開発チームの統率や今までと違う体制になることによってどう意思決定していくかみたいな面もかなり不安があった。しかし、スクラムに取り組んでいてプロセスの型化ができていたり、今まで頼っていたけど足りない部分をみんなで補わないといけない！という危機感みたいなのがうまく噛み合って、育休前に想像していたよりもいい形でチームがワークしたと思う。
- 個人的には、テックリードが抜けた分、POや業務委託の方と認識齟齬が起きないようこまめに連携するようにしたり、今までよりもしっかり確認やレビューをするように意識した点もよかったのかなと思う。
- 人が抜けてメンバーが強制的に変わることで各メンバーの立ち位置が変わったり、チームで作業するときのスタイルが変わったりするのはとてもおもしろいし、刺激があってとてもいい変化だと思った。
郷田さん
- POチームから見ても、プロセス面も技術面もエンジニアリーダーに依存している部分が多いように感じていたため、困りごとは増えると考えていた。
- 誰かがなにかを担う形でエンジニアリーダーの業務を分散化する必要はあると考えていたため、各人のオーナーシップによって上手に巻き取ってもらうことができたのはとてもよかった。
- 特に、エンジニアリーダー不在による自分含めた一人ひとりの自責の意識が向上したことが一番の成果だと思う。
育休をとったエンジニアリーダーからのコメント
Tさん
- スクラムで回していたり、各メンバーがオーナーシップとってくれる環境だったので、そこまで心配はしていなかった。
- 快く育休へ送り出してくれて、その間も滞りなく開発を進めてくれて感謝しかない！
まとめ
以上が弊社の事例になります！
いかがだったでしょうか？
育休を取得する側の不安以外にも、取得する人が所属しているチーム・組織の不安についても弊社の事例によって解消されうる部分があれば幸いです。
その他
当テックブログでは過去に、育休を取得したEMが「子育てで取り組んだことやエンジニアのノウハウをどう活かしたか？」を紹介した記事も書いております。
ご興味がございましたら、ぜひこちらも御覧ください！
