専門領域外のマネジメントにおけるEMとしての取り組みと役割

前提

令和トラベルのプロダクトチームの体制

令和トラベルのプロダクトチームは、3つのチームに分かれて日々の開発を進めています。

私はこの中で2つのチームをマネジメントしており、自身が創設した専門領域であるQA Unitと専門領域外であるFrontend Unitを担当しています。

この記事では、私の専門領域でないFrontendのEMとして取り組んだことと、Frontendチームの1年の振り返り、個人的に考えるEMとはなんぞ？といった話をします。

昨日はNEWT App Teamのマネージャー吉田がアプリチームの振り返り記事をリリースしていますので、ぜひこちらも合わせてご覧ください！

スケーラブルで生産性高いチームをつくるための取り組み

https://engineering.reiwatravel.co.jp/blog/Engineering-Manager-Advent-Calendar-20231218

日々の開発サイクル

令和トラベルの開発サイクルは、1週間を1スプリントとして進めています。毎週火曜日を定常リリース日として設定し、このリリースサイクルに合わせる形でプロダクト開発を行います。

開発サイクルは、多くの企業と同様に仕様検討からはじまり、手戻りが少なくなるように進めています。

※ 参考 : プロセスの全体像

開発の始まりは、仕様検討からです。チームが開発する機能や改善点を明確にするために、仕様検討を行います。月曜日に開催される「Product MTG」と呼ばれている会議体で、CEO含めたプロダクトチームみんなで機能開発の方向性やデザインをすり合わせます。その後、デザイン作成が行われ、火曜から始まるスプリントの案件として組み込まれます。

開発フェーズでは、アサインされた案件をエンジニアがそれぞれ実装し、開発が完了したら、デザインQAを通し、体験としての ”NEWTらしさ” をチェックします。個人的には、デザインと実装が一致していることを確認し、カスタマー体験の向上を図っている点が、NEWTのこだわりだと感じています。

そして最後にQAフェーズを通し、不具合や予期しないエラーがないかをチェックし、問題ないことが確認できたら、火曜日の定期リリースにマージします。

1週間という早いサイクルを実現するために、上流フェーズから開発者・QAエンジニアも参加することで、手戻りを極限まで減らし、高い生産性と品質の向上を目指しています。

この1年間の取り組みを振り返る

会社全体としての目標やKPIはありますが、FrontendチームとしてのOKRも掲げています。その目標に向け、各々メンバーのミッションを作り、チームとして進んできました。

チームとして目指したことは、

生産性を向上し、安定的なリリースサイクルを実現すること

初期品質の高いプロダクト開発を実現すること

の2点です。

つまり、NEWTをリリースしてから掲げ続けてきている “質とスピードのトレードオン” の体現を目指すこととしました。

それではこの2つの目標に対して、振り返っていきます。

1) チーム・メンバーの育成

Tech Leadとの併走

私はまず、Webチームとしてスケールする状態を作る必要がありました。

これまでわたしのマネジメントは、前線に立ちつつ背中で見せるスタイルに近かったのですが、Webチームでは技術的な文脈において背中を見せられないので、私自身のマネジメントスタイルや役割を変える必要がありました。

このチームの中での自分自身の役割や立ち回りを見極めるために、まずはメンバーを理解することから始めました。

はじめの3ヶ月くらいは試行錯誤の連続で、メンバーとのコミュニケーションもうまくいっていないこともあった気がしますが（笑）、メンバーと話すうちに、メンバーの個性や特性がなんとなく理解できるようになりました。

その中で出した私の意思決定は、Webの領域についてメンバーが進んでいきたい方向に全力で支援することであり、本人が気づいていない強みを最大限引き出すこと。つまり、私自身が一人で何かをリードすること、担うことをやめると決めました。

結果的に、Webチームのメンバーの1人に、技術的な支援や技術的なリードを任せることにして、Tech Leadとしての役割を担ってもらうことにしました。お互い明確な役割の境界線は設けていないですが、考え方ややり方について乖離が起きたことはありません。

特に、Tech Leadのメンバーには私から見えているチームの状況とメンバーの様子を細かく連携し、逆にTech Leadのメンバーから見えている状況についてもすり合わせてもらうことで、状況や情報のギャップを減らし、技術面とチームワークの両面を担保しようとしてきました。

2023年12月現在のWebチームは4人体制ですが、それぞれがチーム内で担うべきミッションが明確であり、そこに向けてそれぞれが自走できる状態を作れていることが、生産性と品質の文脈でも大きく寄与していると感じます。

新メンバーオンボーディングと形式知への昇華

Webチームは2023年5月に新しいメンバーを迎えました。

新しいメンバーがジョインして組織が大きくなる中で、生産性も同じスピードですぐに伸びていくかというともちろんそうではなく、一定期間必ず停滞します。入社後のオンボーディングを経て、メンバーが組織に適応し、力を発揮し始めると、チームとしての価値は最大化します。

私はこのオンボーディング期間としては、3ヶ月ほどでの立ち上がりを目標にして、チームでメンバーのサポートをしてもらうことをお願いしました。

実際2023年5月は、前月4月に比べると、リリースしたEpic数は減少し、障害発生率も上がりました。しかしこれは予測していたリスクが実際に発生した結果であり、必要な停滞であり、チームとして、ではこの状態をいち早く通常に戻し、さらにプラスアルファーの生産性、品質状態に戻せるか？と考える必要がありました。

メンバーごとに用意されたカリキュラムを実施できるように整備されているオンボーディングメニュー

令和トラベルは全体のオンボーディング体制が初期の頃から整っていた方ですが、エンジニアリングにおける必要なドメイン理解やプロダクト開発における作法などはどうしてもドキュメントベースの理解だけでは習得できない部分もあります。

そこはメンターにしっかり時間を確保してもらい、丁寧にサポートしてもらいつつ、形式化したり型化できる部分はフォーマットにしてもらうなど、シニアメンバーにとっては当たり前のことだとしても、それをきちんと当たり前の文化に昇華していく作業を進めてもらいました。

PRの上げ方や、開発者自身で担保すべきQA観点のフォーマットなど、一つ一つの対策は軽微なものでしたが、結果的に3ヶ月もかからずに、Webチームの生産性と品質指数はどちらも回復・向上し、新メンバーの受け入れとオンボーディングは成功したと言える状態になりました。

まさにWebチームみんなのサポートと短期間で食らいついてきた新メンバーの成果と言えます。

【入社エントリ】令和トラベルに転職しようと思ったきっかけと入社4ヶ月目の決意

https://engineering.reiwatravel.co.jp/blog/joining-entry-fuku

※ 新しいメンバーの入社エントリー。今ではめちゃくちゃ活躍中！

2) 生産性と品質の向上

スクラムイベントの導入と運営

もともとデイリースクラムやプランニングはしていたものの、いわゆるスクラムイベントのようなものをきちんと導入できていなかったところに、Tech Lead主導でスクラムイベントやチーム内コミュニケーションの機会が作られるようになりました。

月曜日：バックログリファインメント

次のスプリントで着手する予定のタスクをWebチームメンバーで確認する。
認識のズレがないかの擦り合わせや案件理解度の向上、見積りの精度向上を目指す。

火曜日：スプリントプランニング

先週までのタスクの進捗確認と、今週のタスクの確認。
PM含め案件の優先度を再整理し、リリース時期などを調整する。

水曜日：Frontend定例

技術的なアジェンダに絞り、課題や問題などを議論する。

木曜日：おやつタイム

リモートワークを軸とした働き方のため、チェックイン的な意味合いも込めカジュアルなお話しタイムを設定。
雑談的な話から着手中のタスクの相談など話題は何でも可。

金曜日：開発振り返り

1週間の振り返りを開発目線で実施するKPTの場。

日々のコミュニケーション機会が創出されたことで、クイックに問題解決がなされたり、案件や他のメンバーの状況を把握し合える状態になったことは、非常によいプロセスだと感じます。

Story Pointを導入し、生産性を定量化する

“生産性”という指標をどのように考えるか？というポイントは社内でもずっと議論されてきた話なのですが、元々「カスタマーに提供したカスタマーストーリーを1つの価値として、その単位を1Epicと捉える」と定義していました。

Epic単位で毎月リリースした数をモニタリングし、一定基準を下回らないように生産性を維持することを目指していました。

一方、2023年下期になり、具体的にどれくらい案件が重いものなのか、具体的な見積りがわからない、、、といった課題感が生まれ、そこでStory Pointを導入し始めました。

Story Pointは基本となるタスクを決め、それを基準にタスクの重みをつけています。まず試験的に運用を始め、1スプリントでどの程度のアウトプットが出せるのかをモニタリングしました。その上で、チームとして最大化できそうな、目指せそうなゴール数値にStory Pointを設定しました。

ここで気をつけたポイントは、メンバー全員に同じだけのタスク量を求めてはおらず、はじめからチームとしての目標数値を掲げたことです。

これにより、あるメンバーが中長期的な案件や他チームのタスクをサポートしている場合は、他メンバーが自発的にタスクをとるような動きができるようになり、まさにチームで目標を達成しよう！という初期のテーマ設定と共通認識を持てたことが良い点でした。

また単純なStory Pointの消化数だけでなく、見積もりとの乖離もモニタリングしており、QAフェーズで見つかった不具合対応を当初の見積もりとの乖離と定義しています。この乖離も1スプリントで収めなければいけない指標を作り、生産性と品質のバランスを常に確認しています。この乖離が大きいことを初期品質が悪い状態と考えています。

定期的なモニタリングと、定量的なフィードバックができるようになったことで、メンバーそれぞれに生産性の観点が明確に芽生え、現在チームとしては1.2倍の生産性アップを達成中です！

テスト自動化

現状、令和トラベルのリリースは1週間に1度としていますが、Frontendのリリースサイクルはもっと高速化できると考えています。ただしそれを実現するためには、安定的なリリースフローを整備する必要があり、そのためにテスト自動化の運用に力を入れ始めました。

もともと初期からCypressを使ったE2Eシナリオの自動テストはあったのですが、メンテナンスが止まり、運用が止まっていました。

2023年に入り、サービスのスケールも鑑み、いよいよテスト自動化の重要性も上がったことで、運用に本腰を入れ始めました。

大きく変わった点は、元々QAチームで実装していたものを開発メンバーと協業するスタイルに変えたことと、CypressからPlaywrightにリプレイスしたことです。

自動化の進め方や開発メンバーとの協業方法、Playwrightにリプレイスしてみての感想については、それだけで一つのブログにできてしまう濃厚な内容なので、またの機会に公開したいと思います。お楽しみに。

EMに求められることとは何か？

FrontendチームのEMをする上で意識していたこと

この1年を振り返った時、異なる専門性・属性のチームを各論、総論の両面的にマネジメントするということは私にとってまったくの新しい挑戦でした。

特にFrontendという専門外のチームの成果を最大化させる方程式を、自分の中では持ち得ていない中でのスタートだったので、当初は試行錯誤の連続でした。

ただ会社の向かう方向性は理解していたし、メンバーの強みや専門性を信じていたので、私がすべきことはメンバーが苦手なことをフォローアップすることと、メンバーの強みをさらに引き出していくことの組み合わせだったと思います。

つまり、私が形を変えてチームに足りないピースを埋め、新しい価値に変えていくということ。もちろん、私がその足りないピースになれないときもあるので、どんなふうに埋めることができるのか、どんなふうにメンバーを育成すべきかを考え、それでも埋まらない場合は採用という形を模索するなど、そのピースをさまざまな手段で埋めていくことが、私のEMとしての役割でした。

私がエンジニアリングブランディング（DevRel）に未経験ながらリード推進しているのは、こういった形でチームに貢献できるのではないか？という領域であり、今後チームを救う可能性のある領域だと思ったからです。

”とあるテーマを牽引するものが、誰よりも牽引すべき” という考えのもと、こうした発信や企画を考え、できる限り行動しています。

また、私が目指す目標は “昨日よりも今日が少しだけ良くなるためにできることを考える” というもので、日々の小さな成功体験と適切かつストレッチなゴール設定がチームを成長させると考えています。

定量的に物事を振り返るのは、結局のところ今日より明日をよりよくできるには何ができるか？という問いと向き合うことであり、日々の改善が結果的に安定的な成果を生み出すことにつながると思っているからです。

高すぎる目標を設定することは、逆に効果を下げてしまうリスクがあり、チームの生産性が上がる絶妙な塩梅の目標を、メンバーとのコミュニケーションから読み取り、掲げるということが私のチームの作り方です。

時にスタートアップという環境では、非連続な成長曲線を求められますが、日々の過程でそれを常に求められるのは私自身もしんどいと感じるタイプなので、メンバーにもそれを強くは求めることはありません。そういった強いリーダーシップを求められる場面は、ビジネスというマラソンをやっている限り、多くあるべきではないとも思っていますし、普段から堅実に戦略的に物事を推進していくことが、成功の角度を上げる何よりの要素だと私は考えています。

「チームの成果を最大化する」こと

EMという役割を担って数年になりますが、各社で求められる要素・役割が違うことを、多くのEMの方とお話しする中で理解してきました。

例えばある組織においては、ピープルマネジメントのみを求められ、ある組織ではプレイングマネージャーとしての役割を求められるなど、その期待値はさまざまです。

ただ共通するミッションもあり、それが「チームの成果を最大化すること」でした。

私たちEMがみている単位はあくまで “チーム”です。チームとしての成果を最大化するための役回りを常に考え、動く必要があります。

チームをさらに分解すれば個人であり、つまり一人一人のできることを引き上げることはもちろん、個人が持っている素養を引き出し、できる幅を拡大していくことが結果的にはパフォーマンスやモチベーション向上につながっていくのだと思います。

私が意識していたこととしては、個人のレベルアップだけでなく、コミュニケーションのハブに私が入ることや、情報を伝達すること、ブロッカーを整理することなどの関わり方によって、スムーズに意思決定やメンバーひとりひとりが自発的に動ける状況を作るということもアウトプットに繋がっていくということを、この1年を通して改めて学びました。

この記事では扱うことができませんでしたが、技術的な取り組みや挑戦も自発的に提案して推進してくれるなど良い動きもありました。プロダクトのスケールに合わせた守りの開発という意味での、エラー検知の仕組みの導入や、技術的負債との適切な向き合い方など幅広く取り組むことができました。

2024年はさらにR&D的な取り組みにもチャレンジしていきたいと思っているので、みなさん今後のNEWTに期待してください！

「信頼貯金」を積み上げること

これはEMだからとかではなく、私自身が大事にしたいことでもあります。

“信頼” という目には見えない、けれど仕事をする上で最も大事な要素の一つです。

書籍『7つの習慣』の中で、信頼のレベルは「信頼貯金（残高）」で測ることができるとされています。

私は ”信頼” について真剣に意識しはじめたのは、QAエンジニアとしてのキャリアを築いてすぐだったと思います。理由は簡単で、QAエンジニアは悪魔の証明と向き合う業務であり、信頼関係が成り立っていなければ仕事として成立しないからです。

そしてマネジメント業務に関わるようになり、マネジメント職はさらに信頼関係によって成り立つのだと実感しました。

マネジメント業務は結局のところ、人との対峙であり、人の成果のコントロールなので、信頼貯金を積み上げられているかというポイントが影響します。

例えば、「miisanが言うならこれはリリース難しいよね」「miisanが言うなら大丈夫だよね」みたいなやりとりが実際に日々のやり取りの中にあります。

もちろんその過程に提示した情報やロジックにそれなりの納得感もあるのかもしれませんが、ここでの最後の意思決定にいたる主語は私です。これがまさに私自身に価値を感じ、信頼を置いてくれているという証拠だと思っています。

私自身も信頼してもらっているのだから、その信頼に応え、必ず結果を出す。その繰り返しの中で、信頼貯金はさらに積み重なります。

ですが当然人間なので、もちろん失敗もあります。そんな時は、全力でリカバリーと次回以降どうしたら起きないのかを考えます。

そして上記では、私を主語に例をあげましたが、私は同様にメンバーを信頼してます。「〇〇さんがいうならこれが最適なソリューションであるのだろう」とサポートします。過程のロジックや思考について尋ねることはありますが、そこに違和感や方向性の乖離がなければ信じてやってみる。その結果の責任を取ることも私の役割であり、その時は一緒になって全力でリカバリーを考えます。

こうした小さな積み重ねを続けていくことが、良いチームを作ることだと私は信じ、今後も信頼貯金を増やせるように精進しようと思います。