エンジニアリングマネージャー間でスクラムを始めてみた話
本記事はTimee Advent Calendar 2023の25日目の記事です。
はじめに
はじめまして。
タイミーでエンジニアリングマネージャー（EM）をしている三宅です。
私は今年の8月にタイミーにjoinしました。前職ではプロダクトのドメイン単位で技術・プロダクト・組織の全てを管掌するような役割を持っており、広くプロダクトを支える動きをしてきましたが、現職ではEMという少し限定された役割を持ち、深く組織に関わるような動きをしています。
今回は入社してから自分にとって大きな変化であったEM内のスクラム導入について、導入に至った考えと始めるための下準備についてまとめてみたので、アドベントカレンダー25日目の記事として紹介させていただきたいと思います。
タイミーの開発組織
組織の定義と開発サイクル
タイミーのEMはチームトポロジーの考え方をもとに組織とその関係性を定義し、価値創出のための開発手法としてスクラムと大規模アジャイルの考え方であるSpotifyモデルを採用しています。それぞれの言語定義はここでは割愛しますが、現在ではざっくり開発グループ（Tribe）が3つとその配下にスクラムを主体とした4-5ほどの開発チーム（Squad）が存在しています。Squadはプロダクトオーナー、スクラムマスターをはじめとした職能混成のチームであり、フロー効率を重視した自律的な開発組織を目指しています。
Tribeの構成
Tribeが管掌する機能範囲
開発組織でのEMの役割
タイミーのEMは主にスクラムの主体である各Squad単位の管掌範囲をもち、主にピープルマネジメントを主軸に活動しています。EMの定義は会社によってまちまちであり、プロダクトマネジメントやテクノロジマネジメントも含む定義をする場合もありますが、タイミーではピープルマネジメントに対して深く関わり、それ以外のマネジメント要素についてはSquadが持つ能力に対して不足する能力に対して染み出しながら支援するような動きをしています。
エンジニアリングマネージャーの役割
組織の状況とEMが持つ課題
タイミーは現在サービス、組織共に拡大期を迎え急速に人員が増加しています。現在はプロダクト本部で75名[1]ほどの組織となっており、ここに毎月複数名新しいメンバーが入社しています。そのため、組織的には毎月何らかのオンボーディングを行なっている状況であり、組織にかかるインパクトも大きくそれに合わせた組織の適応も強く求められます。
これにより現在では毎月のようにチームの組成の検討や組織定義のアップデート、運用方法の変更等が行われるようになっており、説明責任や実行責任を果たすためEM間の連携の強化や設計、内容の合意など動き方をより強くしていかなければなりません。
一方で以前までのEMの動きはそのほとんどが個人活動に依存しており、強いセルフマネジメントと情報収集能力、意識的な連携を行わなければならない状況が続いていました。一応この状況でも組織を動かすことはできていましたが、個人の能力に大きく依存するかつ組織規模が小さいからこそできるような動き方でもあったため、今後適応できなくなることは明らかでした。
EMが行うスクラム
実施の背景
ここまでの状況を踏まえ、組織が拡大したとしてもより強い連携と適応を実践する体制を作ることが急務でした。そしてその解決法として実践してみたのがEM間のスクラムを行うことでした。
スクラムは考え方としてアウトプットの量ではなく、変化し続ける見通しの立てにくいユーザーのニーズに細かく適応しながら価値を積み上げていき、提供する価値の大きさを最大化することを目的としていると思いますが、この考え方が「有機的で変化し続ける組織に対して強く支援する活動そのものにも当てはめることができるのでは？」と考えたのがきっかけです。
また、単純にタスク管理と情報の透明性を担保するフレームとしても有効であると考えました。特に管理職に近い役割を持つ方はセルフマネジメントの難易度が高い傾向にあり、抱え込んでしまうハードワークさと扱う情報が故の不透明さを生みやすい領域であるため、そういった難しい領域を生まないことに対する対応も必要だと考えました。
実施するための準備
早速EMのスクラムを始めようとなってもタスクを管理するための土台が何もなければ始まりません。そこで業務フローをデータ主体で設計することにしました。タイミーではドキュメンテーションツールにNotionを採用しています。スクラムを実践するためのタスク管理手法としてNotionを組み合わせることは社内リソース的に必然であったため、NotionDBをベースとしたデータの設計を行い、Notionページ間のリレーションをコントロールすることで業務フローを整備していきました。
データ設計
細かいテーブルに対する定義の説明までは省きますが、ざっくりと下記のようなデータを保持することで管理体系を作り込みます。
データ関連図
※ 個人の慣習としてデータは強制的に複数にしたがる病なのですがあまり気にしないでください。
以下にデータ要素の概要を記載します。
Category
EMが取り扱うとする仕事の領域を定義します。解決したい全ての課題は何らかのCategoryに紐付き、EMがどの領域に課題を感じコストをかけているかの可視化を助けます。
Epic
数スプリントの範囲内で組織として解決したい課題を言語化したものを蓄積します。原則EMが取り組む仕事はこれを起点とするようにして、各MTGとの接続や外部の方に対する説明責任を果たす場合もこの情報を参照します。
Task
EMが具体的に取り組む作業を言語化したものであり最小単位です。これはEpicに関連づけられるようになっており、アサイン者やタスク量の見積もり、どのスプリントで実施されるかというような実行に関わるステータスはこのTaskに紐づくようにします。 Taskは原則として1つの解決の定義を持ち、それがクリアされれば完了になります。
Topic
Taskに関連する共有や他の領域からの情報展開など、一時のコミュニケーションで完結するものについてはTopicとして起票しておきます。これは定期的に参照されEM間の認識として保たれるようにします。
Minutes
スクラムに関連するすべての会議体の議事録はここに集約されます。会議体ごとにテンプレートで管理し、参照される情報はすべてその中に記載されます。また、会議の中で得られた気付きはFBのループに回せるようにNoticesのテーブルに蓄積されるようにして、ローリングされるようにします。
Notice
会議体の中で進行に関わる気付きや課題、感想等感じたことを蓄積します。基本的には自身のフローに対するFBループを回しながら適応することが大事だと思っているので、気付きはできるだけ漏れないように接点を作ります。また、Retro等でも気付きが得られると思いますが、これもこのDBに統合させます。
その他SprintやVelocityなどはよく使われるワードと定義だと思うので割愛しますが、その全てをDB化してリレーションを貼ることで制御しています。
会議体設計
会議体は上記のデータを各会議でどのように取り扱うか？を考え、時系列に当てはめることで設計を行います。一回のスプリントは二週間とし、最終的に下のグラフのような業務フローとなりました。
会議体と業務フロー
基本的な流れとしてはよくあるスクラムの流れに近いと思いますが、いくつかポイントをまとめたいと思います。
外部MTGとの接続
組織上EMが取り扱うタスクの他にも採用やプロダクト、技術管理など複数の領域の仕事が同時並行で行われている状況です。基本的に仕事は何らかの手法の有無に関わらず一定のサイクルで行われているものと考えているため、接点を設けるような会議体に関してはタスクの二重管理を防ぐよう、情報の流通のみを行うことにし、相互に情報を連携して説明責任を持つものに対してバックログに取り込む形をとるようにしました。
POの設定とゴール管理
現時点ではEM内にはPOという役割を設定していません。（本来は必要なのですが諸事情により作っていない状態になっています） ただ、組織変化に対する全体の説明責任は現在CTOが担っているため、タスクの優先度と進め方に関してはSprint単位で認識を合わせるようにしています。また、スプリントの進行や細かい意思決定などはできるだけ仕組み化することで負担を軽減しています。
スクラムを実施して得た結果と今後
EMのスクラムは始めたのが11月の中旬ごろなのでちょうど1ヶ月ほど経ちました。スクラムは経験則をもとにチューニングされるものでもあると思っているので、未熟な部分もまだ多くありますが、課題感であったタスクの可視化、透明性の向上、タスク量の管理や計画性のレベルを上げることができたと思っています。一緒に実施しているEMの方々からも「タスクが良く見えるようになった」、「共通認識が持てて良い」、「横のつながりが強化された感じがする」といったFBをもらっており、一定の効果が得られたかなと振り返っています。
一方で課題もあります。EMはその特性上、一人が複数の組織に所属することが多く、タスクの分離、共有判断が難しいと感じています。仕事の中には綺麗に言語化できないものもあり、そういったものを経験に頼るか仕組み化するかといった判断やEMが持つタスクに対して相互に協力し合うようなフォロワーシップを発揮した活動はまだ十分にできていません。これらは今後のSprintを通してFBループを回しながら改善できればと思っています。
今回はとりあえず始めてみたよ！っていう趣旨で執筆していますが、今後そのメリットやプラクティスがまとまってきた段階で別途まとめの記事を作りたいと思います。
余談
あまり意味のある話ではないと思いますが、最近マネージャーとは肝臓と表現できるのではないかと思ってきました。
組織は人の集合体で有機的なものであり、組織のロールは役割を定義、分担することで組織全体が円滑に働くための仕組みを形作っています。それは細胞の集合体である生物と臓器等の役割の関係に似ているのでは？という発想があり、その中でマネージャーという役割は組織全体の健全性を保ち、組織が生み出す課題を解決し続けることを仕事とするならば、おそらく肝臓が一番適任なのかなと、そんなことを思っているクリスマスです。はい。
もし近いことを考えている人いましたら一緒にお酒を飲みにいきましょうw
採用頑張ってるよ！
本文にも少し関わりますが、タイミーでは現在一緒にプロダクト、サービス、業界を育てていくメンバーを積極的に募集しています。プロダクトも組織も急激に成長しており、変化も大きいですがそれだけ楽しめる環境だとも思いますので、興味あるーって方いましたら是非お声がけくださると嬉しいです！
それでは最後までお読みいただきありがとうございました！
Discussion