はじめに
こんにちはへたれです。
株式会社アイデミーでエンジニアとして、材料開発のためのデータ活用プラットフォームLab Bankを開発、運用しています。
みなさん開発チームの運用はどうされていますか？
- チームの規模
- 開発サービスを取り巻くビジネス状況
- メンバーのスキル構成
など様々な要因があり、それぞれのチームにとって最適なチーム運用が異なります。
例に漏れずLab Bankグループでもチーム運用を探るのに苦労しました。
自分が運用設計を考えるにあたり特に意識していたのは
- 冗長性を持ったチームになること
- トップダウンの素早さ、ボトムアップの創造性をバランスよく発揮できること
- チーム全員がエンジニア・マネジメント両方の成長機会を得られること
です。
プロダクトの立ち上げからリリースを経てどのようなチーム運用に行き着いたか？
Lab Bankグループのチーム運用についてご紹介したいと思います。
ロール割り当て
Lab Bankメンバーの構成はアプリケーションエンジニア 3名、インフラエンジニア 1名、営業 1名という構成です。
新規事業あるあるだとは思いますが、チームの人数が少なく綺麗に分割するというのが難しいです。
そのためそれぞれが得意領域を持ちつつ、こなすタスクやロールをその時々で臨機応変に変えていく形をとりました。
これはアジャイル開発でよく言われる職能横断型チームに近いものだと思っています。
エンジニアリング以外のロールに関しては以下を採用し、Lab Bankの中で実態に即するように責務を明文化しました。
- PdM(プロダクトマネージャ): 外部向けにニーズの把握や折衝、期待値調整に責任を持つ。内部向けにフィードバックを行い、目指すべき姿を共有しつつプロダクトゴールの設定を行う。
- PM(プロジェクトマネージャ): チーム全体が開発を円滑に進めるようにサポート・タスク管理を行う。
- PGL(プロダクトゴールリーダ): 各プロダクトゴール(機能や改修などの大きな単位)をリードするメンバー。基本的にはタスクの進行や依頼、管理などに責任を持つ。
- TL(テックリード): プロダクトの技術に責任を持ち、技術選定や実装方針の相談などを請け負う。
この中でPdM, PM, TLは固定化し、困った場合誰に相談するのか？誰がフォローするのか？を迷わないようにしました。
一方でPGLは各メンバー間で持ち回りをする形にしました、理由は後述します。
Product Goal Leader
プロダクト全体をどこに持っていくか？の方向づけを行うのはPdMです。
ただし全ての機能について仕様を決定し、スケジュールを管理する...というのは現実的ではありません。
そのためPdMと開発メンバーの橋渡しになるようなPGLを設けることにしました。
(PGLはスクラムやアジャイルの概念ではなく、自分が勝手につけた名前です)
PG(プロダクトゴール)はスクラムの概念で、チームがプロダクトを前に進めていく中で目指す目標のことです。
スクラムの定義から少し外れるかもしれませんが、Lab Bankでは機能開発やリファクタリングの単位でPGを作成します。
PGLはPGを達成することへの責務を負っています。
主な役割は以下としました。
- 詳細設計
- 画面・API設計
- 開発スコープ
- タスク管理
- リソース配分
- スケジュール設計・管理
- タスク設計・管理
- メンバーのフォローアップ
このPGLをPGが始動するごとに開発メンバーに割り振り、規模感や他PGの優先度と比較して開発スケジュール決定とタスク着手を行います。
PGLは新規開発資料と称して、背景や仕様、スコープなどのPGの中身を徹底的に言語化します。
また最終的な決定内容だけでなく、途中の議論や調査内容を気軽に残せるよう新規開発資料下に「議論・調査メモ」を用意しました。
こういうのを用意するときに、Notionのテンプレート機能はとても便利ですね。
またPGLは以下の理由によりメンバーを固定せず、PGが動き出すタイミングでメンバーの誰かに割り振るようにしました。
- PGLのタスクが重く、負担が集中しないようにするため
- 意思決定の機会を分散し、各メンバーにエンジニアリングとマネジメント両方の機会を提供するため
Lab Bankグループの現状を振り返ってみると、各メンバーがPGLを経験することで比較的早いサイクルでのリード経験が積めました。
オーナーシップの高まりも感じており、非常に良い取り組みだったなと思っています。
開発管理
Lab Bankグループでは以下の定例を実施しています。
- 月次PG見直し定例
- 営業&エンジニア
- 営業活動の所感や顧客からの要望をメンバーで共有
- PGごとの優先順位や取り組む時期を議論して見直す
- 週次開発定例
- 営業&エンジニア
- タスクの取り組み・完了確認
- 進行中のPGごとにその進捗を確認
- 毎朝のデイリー
- エンジニア
- 今日取り組むことの確認
- タスクの進行をブロックしているものはないか確認
- 月次開発振り返り
- エンジニア
- 一ヶ月の開発の振り返り
- 翌月に向けて改善したいことの抽出
PG見直し定例を設けることで、マーケットや顧客のニーズと開発チーム内でのズレを解消し、早い段階で方向修正ができるようになりました。
課題
最後にこの運用方法で感じている課題感も共有したいと思います。
PGLによって進め方にムラがある
毎回PGLが変わるため、それぞれの得意・不得意や考え方によって進め方にどうしてもムラが出ます。
またPGL業務と開発業務が同時に割り当てられているため、状況によっては専念することが難しかったりもします。
これに関しては適宜他メンバーがフォローに入ったり、リソース・スケジュール調整を行っています。
PGが突然消滅することがある
ビジネス上の都合でPGが消滅したり、優先順位が変わることもあります。
早めの方向転換ができて良かったという反面、PGLの任を突然解かれるという状態になります。
また個人の評価目標にも関わることもあります。
その際には新しいPGLに任命したり、期の目標を見直したりといったフォローアップをしていました。
PGを見直す際には全員の納得とPGLが不利益を被らないようなケアが必要です。
おわりに
いかがでしたでしょうか？
PdM, PM, TLを固定化しつつ、PGLを持ち回りにするという運用で以下を達成することができました。
- 冗長性を持ったチームになること
- トップダウンの素早さ、ボトムアップの創造性をバランスよく両方どりできること
- チーム全員がエンジニア・マネジメント両方の成長機会を得られること
自分はチーム運用が専門というわけでもないので、スクラムやプロジェクトマネジメントという文脈でセオリーを踏襲できているか？と言われると微妙なのですが、実態に即した運用を設計・実施できていると感じています。
もし提案やアイデアがあればぜひコメントでください。泣いて喜びます。
Lab Bankというサービスもまだまだ道半ばです。
チームのあり方も状況に合わせてアップデートしていきますので、応援していただけると非常に嬉しいです。
Discussion