Project Lead Engineer制を導入した話
こんにちは、プロダクトオーナー(PO)兼プロダクトマネージャ(PM)兼サーバーエンジニアのひっしーです。長い。
以前「チーム開発の成功に大切なこと」「エンジニア発プロダクトマネージャが大切にしていること」という記事を書きまして、Timersではサーバーエンジニアから始まりPM、そして今はPOとして業務させていただいております。
本日は、POとしてチーム開発を進める中で、 Project Lead Engineer制を導入した話 についてご紹介いたします。今となっては、 なぜもっと早くやらなかったのか？ と振り返るほど、良い効果があるように思っています。それでは参りましょう！
- 目次
- これまでの開発体制
- 訪れた転機
- 現在の開発体制
- Project Lead Engineer制の効果と注意点
これまでの開発体制
これまでの弊社における開発チーム体制は、以下のようなよくあるスクラムチームでした。自身は以前、サーバーエンジニアとして参画しておりましたが、今はプロダクトオーナーです。でもちょっと実装もします。なおEngineerにプラットフォーム区分が付いていない状態がスクラムとして正しいと思いますが、ここでは実態に合わせています。
具体的に当時のプロジェクト進行中の状態を説明します。下図の通り、 サーバーエンジニアが自然と全体の設計を考え、POは各メンバーとコミュニケーションをとりながら遂行していく形 でした。ありがたいことに優秀な開発チームに支えられ、プロジェクト進行に大きな問題はなく日々一歩一歩、前に進めていました。
訪れた転機
当時、私はまだまだ駆け出し素人PO状態でした。そのため、漠然とこの開発体制のどこかに改善ポイントがあるように感じつつも、なかなか「これだ！」という提案・アクションはできていませんでした。
そんな中、弊社同僚のスクラムマスターに連れ回され(※いい意味です)、様々なPO/PMの勉強会に参加する機会があり、そこで Project Lead Engineerという存在を知りました 。不勉強でお恥ずかしい話ですが、Project Lead Engineerは職種として一般的に存在しており、海外の求職サイトでも目にするものでした。また、Lead Engineerはすでに弊社にも存在しておりましたが、その位置付けとは異なるものでした。
Project Lead Engineer = プロジェクトをリードするエンジニア
もちろんどこかで厳密に定義されていると思いますが、私の解釈は文字通りで、 特定プロジェクトにおける全体設計を含むエンジニアリングに責任を持つエンジニア と捉えました。そして個人的に「これを自社に適用したらどうなるか？」という考えが芽生え、早速チームに提案・実施に至りました。
現在の開発体制
Project Lead Engineerを定義した現在のプロジェクト体制は次の通りです。まだまだ導入して間も無いので実務通りに書いています。次はAndroidエンジニアがLeadの予定です。覚悟 準備、お願いします。
プロジェクトA
プロジェクトB
見ての通り、 プロジェクトを発足すると、３名いるエンジニアのうち１名がProject Lead Engineerに任命 されます。コミュニケーションについては、必然的にPO→Leadがメインとなり、さらにLeadを中心として開発チームに情報が共有されます。Leadの指名は私(PO)の独断と本人の承認を経てですが、そこの信頼関係はしっかり築けています。無理やりじゃないです、 本当です 。
Project Lead Engineer制の効果と注意点
まだ始めて間も無いタイミングではありますが、チームに良い効果があることを実感しています。これまでの体制と現在の体制を比較し、現在感じている効果と注意点をまとめてみます。
効果１：エンジニアリングを開発チームに一層任せられるようになった
POとエンジニアの責任分岐点は、往々にして曖昧になりがちです。これまでは細かな仕様の調整や情報共有をPOが主導して行う傾向にありましたが、現在はLead Engineerが主体的に動いてプロジェクトを進めてもらっています。
要するに、 エンジニアリングに関することを開発チームに一層任せることができるようになり、POは本質的なPO業務に集中できるようになった ということです。また、分散されていたPOと開発チームのコミュニケーションパスもLeadに集約され、開発に関するやり取りが非常にスムーズになったと感じます。
効果２：エンジニアが主体性を持つことで生産効率が良くなった
これまではPOがユーザーストーリーを細かく分解し優先度も検討しつつ開発チームとスプリントを回していましたが、今は大きめのユーザー体験ベースのストーリー分解に留めています。そこからLead Engineer主導で「これならこういう分解をするとやりやすい」「こういう優先順位でやった方がいいね」と言ったHowを詰めてもらっています。
こうすることで、 全体を見渡しながらどうリリース可能なゴールに到達するかを開発チームが主体的に検討 できます。自身がサーバーエンジニアだった頃を振り返ると、面白さ/やりがいを感じられる気がしています。(すみません、ここはちゃんとメンバーにも確認します)
なお具体的に生産効率が良くなった話としては、Sprint毎の消化ポイントです。 導入前後で週あたりの消化ポイントを比較すると、約２倍程度になっていました 。見積もりはそこまで精緻にやっていないのでブレはありますが、生産効率の向上を感じずにはいられません。
注意点：メンバーの意向を汲みとること
「Project Leadなんてやりたくない！」というエンジニアの方にLeadをお願いすれば、摩擦を生むことは間違いないでしょう。だからと言って「やりたくない人はやらなくて良いです」という形で、Lead Engineerを他のエンジニアで持ち回れば、表に出ない回避し難い優劣意識的なものをメンバーが抱える可能性 には配慮しなければなりません。
幸いなことに、現在の私のチームはLead Engineerを担える能力があり、拒否せずやる気になっていただけるメンバーばかりですが、導入する際にはメンバーの意向を汲みながら検討する必要があると考えています。
まとめ
今回は、POとしてチーム開発をより良くしていくことを考え、Project Lead Engineer制導入のお話をさせていただきました。
もちろん チーム開発を改善していく目的は、良いプロダクトを作るため という本来のゴールを忘れてはいけません。今後は、現在個人的に興味が強いUXやデザインスプリントに興味を持ちつつ、チーム一丸さらにプロダクトを良くしていこうと考えています。
積極採用中!!
子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc. では、現在エンジニアを積極採用中！ 急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！ 採用HP : http://timers-inc.com/engineerings
