この記事は「Engineering Manager Advent Calendar 2022」に参加しています
23日目の記事です。
昨日は
でした。
20名のエンジニア組織でVPoEになり1年が経ちました
株式会社SODA でVPoE兼エンジニアリングマネージャーをしている @rinchsan です。
2年ほど前の2020年10月よりソフトウェアエンジニア（SWE）としてSODAへ入社しました。
そのタイミングではマネジメントの知識は皆無で、マネージャーは「いい感じに1on1と言って話を聞いてくれるおじさん」としか思っていませんでした。
そんな僕ですが、今年2022年の1月よりVPoE兼エンジニアリングマネージャーに転向し、1年ほどが経過しました。
SODAは現在20名ほどのエンジニア組織で、プロダクトマネージャーやデザイナーと協力しながら「SNKRDUNK（スニーカーダンク）」というプロダクトを開発しています。
ここ1年の取り組みをご紹介します
SODAで直近1年ほどで取り組んできたことをご紹介します。
今回ご紹介する取り組みは、すべてにおいて僕1人で進めたものではなく、ありがたいことにプロダクト開発チームの皆さん（エンジニア、PdM、デザイナー、などなど）が積極的に協力してくれたからこそ進んだものばかりです。
圧倒的感謝。
感謝するぜ お前らと出会えた これまでの全てに!!!
だいたいの課題は「属人化」でした
実際には色々な課題があったんだろうなと思いつつ、結局は「属人化」にグルーピングできるような課題が多かったように思います。
タスク属人化により、PdMとの調整のコスト増などの課題が発生
タスクによっては2人の場合もありましたが、基本的に1つのタスクを1人のエンジニアが担当していました。
他のエンジニアによるコードレビュー実施はルールとして定着していましたが、実装対象について把握していることが少なくレビューコストは高く、ジワジワと担当した人しか周辺を触れなくなっていく予感がありました。
また、開発スケジュールの長さも見積もりが属人化していることによって人による差が顕著になってきました。
次第にスケジュールが不安定になり、雑に決めたリリース予定日の延期が頻発し始めていました。
チームではなく個人に依存しているので誰がタスクを担当するかによっても大きくスケジュールが変わることもありました。
さらに、開発スケジュールの属人化によるもう1つの弊害として、PdMと開発スケジュールに関するすり合わせ・調整に必要以上にコミュニケーションコストがかかるようになっていました。
チームではなく担当者個人に対して進捗の確認やリリース予定の調整をしなければならず、エンジニアの人数分のタスクが走るのでPdMの認知負荷は多大なものになっていました。
フロー効率を重視するように変化し認知負荷を下げました
まさにリソース効率を重視した開発チームの動き方をしてしまっていたことにより、PdMに限らずエンジニアも含めた全メンバーの認知負荷が増大していました。
きちんと計測は出来ていませんが、それによって不具合発生率の増加やユーザへの価値提供リードタイムの増加などが発生していたかもしれません。
そこで、フロー効率を重視する価値を説明し、1つのチームで同時に走る大きな開発タスクは出来るだけ1つに絞られた状態で開発が進むことが理想であるという考え方が定着してきました。
PdMとエンジニアで1つのチームとして動くようにもなりました
もう1つ調整コスト増大に繋がってしまっていた原因として、「エンジニアチーム」と「PdMチーム」のように2つのチームがチーム間連携を行うことでプロダクト開発を進める、という体制に実質なっていたことが挙げられます。
そこで、1つのエンジニアチームに対して1人のPdMが担当として付くことで、エンジニアとPdMが一緒に同じチームとして動いていける体制を整備しました。
これによって、それぞれのエンジニアチームで実施していた定例MTGにPdMが参加しやすくなったり、コミュニケーション相手が固定されることで業務をスムーズに進められるようになったりと色々進めやすくなりました。
Team Topologies で導入されるStream-aligned Teamと近い考え方のチーム体制になりました。
ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの１つのような場合もあるだろう。さらに、なるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ないということだ。
マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition) (p.144). Kindle 版.
【宣伝】開発生産性の文脈で、より詳細に組織作りの考え方を紹介しています
組織作りにおける考え方について、開発生産性の文脈でより詳細に紹介しているZennも是非ご覧ください！
Story Pointによる相対見積もりの導入を試みました
開発スケジュール見積もりの安定化を狙い、担当者に依存する絶対見積もりを廃止しました。
そして、相対見積もりで開発タスクの工数を見積もるべく、Story Pointの導入を試みました。
Function Pointも組み合わせて工数見積もりを始めました
ただ、相対見積もりやStory Pointの概念は初見では比較的難しい概念で、エンジニア全員がスッと腹落ちして開発プロセスに落とし込むことは難しいと判断し、見積もりを進めやすくするためにFunction Pointの概念も同時に導入しました。
Function Pointとは、A.J.Albrecht氏が1979年に考案した見積もり手法です。
かなり昔からある手法で、今では実施コストの観点であまり使われなくなっているようです（出典不明）。
とても簡単に言うと、1つの開発タスクを作業レベル[1]でサブタスクに分解し、作業ごとの所要時間の総和で工数見積もりを行う手法です。
弊社SODAでは、Function Pointの考え方を参考に開発タスクを分解し、分解したサブタスクに対してStory Pointによる相対見積もりを行う手法を取りました。
- 事前に作業の種類（DBに対して読み込みを行うメソッドを実装、など）に対するStory Pointの対応表（DB読み込みメソッドの実装は2ポイント、など）を作る
- Function Pointの概念を利用して開発タスクを作業レベルに分解する
- 分解したサブタスクに対して対応表を参考にStory Pointを付け、開発タスク全体のStory Pointはその合計値とする
と進めるようにしました。
対応表に関しては形骸化していくことを防ぐために定期的にチームでポイント対応を現状と一致した状態にアップデートしていきました。
相対見積もりに慣れてから、Story Pointのみでの見積もりへ移行しました
上記のFunction Pointと組み合わせた手法で相対見積もりに慣れて、ある程度見積もり精度が向上したり、チーム内開発タスクの相互把握が見積もりプロセスにより進みレビューコストが低下しました。
ですが、Function Pointを用いると細かいサブタスク分解が必要になり、見積もりコストが大きくなります。
弊社SODAでは、ある程度エンジニア全体が上記の見積もり手法に慣れてきたあと、Story Pointのみでの見積もりへ移行し、開発タスクに対して直接Story Pointを割り当てるように変化しました。
【宣伝】EMが2人になりチームへ
今年2022年の8月より社内でソフトウェアエンジニアをしていたメンバーが「エンジニアリングマネジメントに興味がある」と手を挙げてくれてEMチームは2名体制になりました。
しかしエンジニア組織は年明けに25名ほどになる予定で、さらにEMのパワーを増やさねば健全な開発組織作りが難しくなってくると想定しています。
今後はScaling Agileの導入やデザイン組織作りなどにも注力します
サービス特性上、ソフトウェアエンジニアのパワーが持つビジネスインパクトは非常に大きいため、今後も引き続きエンジニア採用へ注力し続けます。
エンジニアの数がどんどん増えても1人あたりの開発生産性を下げることなく、むしろプロダクト開発のアジリティを上げていきたいと考えています。
「LeSS」や「Scrum@Scale」のようなScaling Agileフレームワークの導入や、デザイン組織のプロダクト開発プロセスへの適切な巻き込み[2]なども今後の大きな課題です。
LeanとDevOpsの科学 で言及されているような、人数が増えてもデプロイ頻度が単調増加していくハイパフォーマーなチームになっていきたいです。
ハイパフォーマーなチームは開発者数が増えてもデプロイ頻度が増加していく図（出典：LeanとDevOpsの科学）
Engineering Managers Wanted !!!
このようなエンジニアリングマネジメント領域の取り組みに少しでも興味のあるEM志望の方がおりましたら、是非お話ししましょう！！
-
あるSELECT文を発行してある条件に合致するレコードを取得するメソッドを実装する、など ↩︎
-
デザイン組織の巻き込みに関する課題は こちらのインタビュー記事 でも言及しています。 ↩︎
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください！ → recruit.soda-inc.jp/engineer
Discussion