EMサイクルで実現する適切な技術投資 —— 組織的な技術課題解決への取り組み

こんにちは、SmartHRでエンジニアリングマネージャーをしている sako です。

前回の記事では、アジャイルコーチの wassan が、「SmartHRが拓くアジャイル組織の未来 —— 労務ドメインの組織変革とScrum@Scale」について紹介しました。

本記事は、アジャイル組織変革連載の第2回として「技術戦略とEM（エンジニアリングマネジメント）サイクル」をテーマに、Scrum@Scale（以下S@S）の中でもEMサイクルが技術課題への投資においてどのような役割を果たすのか、エンジニアリングマネージャーの視点からお伝えします。

機能開発と技術課題解決のバランスは難しい

SmartHRでは、これまで各プロダクトの技術課題は各チームの自助努力によるボトムアップで対応がされてきました。プロダクトにオーナーシップを持って対応できている点は良い一方で、課題もありました。

各チームは、機能開発と技術課題への対応どちらも行う必要がありますが、それぞれにどれだけリソースを割くべきでしょうか。機能開発はユーザーへの価値提供が分かりやすく成果も見えやすい一方で、技術課題への対応は対応効果が測りにくいため、どうしてもユーザー価値が分かりやすい機能開発を優先しがちになってしまいます。

その結果、解決のタイムスパンが長い技術課題や、複数チームにまたがる横断的な課題は、対応コストが高く優先度判断が難しく、対応が後回しになっていました。

どうしても対応する必要がある技術課題については、ロードマップに差し込んだり、別途メンバーを割り当てるなどをして対応していたものの、機能開発と技術課題への投資の適切なバランスを取る仕組みが不足していることが課題でした。

S@SのEMサイクルで解決したいこと

今回、SmartHRの労務ドメイン開発組織にS@Sを導入しました。この体制変更により、技術課題に適切に対応できるよう、EMサイクルを中心とした仕組みを整えていきます。

階層的なエスカレーション構造の構築

EMサイクルでは、各レイヤーで扱える課題はそれぞれで議論のうえ対応を行い、そのレイヤーで解決できないものを上位レイヤーへエスカレーションする構造を作ります。

EMサイクル。チーム単体では解決できない、技術的負債や横断課題などの障害物を上位レベルにエスカレーションをして解消する。 — EMサイクル

チームレベル：日々のレトロスペクティブで解決可能な技術課題
エリアレベル：複数チーム間の調整が必要な技術課題
ドメインレベル：ドメイン全体に影響する大規模な技術課題

課題が大きい、影響範囲が大きい、リソースが足りない、ロードマップに影響するなど、そのレイヤーで解決できないものは上位へエスカレーションされ、適切なレベルで意思決定を行います。

適切な技術投資を実現する2つの仕組み

EMサイクルでは、以下の2つの仕組みにより、データに基づいた適切な技術投資を実現します。

1. チームとプロダクトの状態を計測し、投資割合を決定する仕組み

機能開発と技術課題解消へのリソース投資のバランスを適切に取れるように、チームとプロダクトの状態を計測する仕組みづくりを進めます。

これまで取り組んでいたSPACEフレームワークによる開発者体験サーベイやFindyTeam+を用いたサイクルタイム分析は継続しつつ、投資分析と障害物ボードによる技術課題の可視化を行います。

投資分析では、各チームの活動時間を機能開発、技術課題解消、運用・保守に分類し、その配分を定量的に把握します。障害物ボードによる技術課題の一元管理では、各チームが抱える技術課題を可視化し、組織全体で優先順位を判断できるようになります。

これらのメトリクスの内容と技術課題のロードマップを踏まえ、S@Sで行う「メタスクラム」というイベントで投資割合をEM（エンジニアリングマネージャー）・PM（プロダクトマネージャー）間ですり合わせを行い、機能開発と技術課題解消のバランスをとり全体最適を目指します。

2. 基本機能プロダクトに対するエスカレーション

SmartHRのプロダクトは、祖業のプロダクトである基本機能プロダクトとプラスアプリと呼ばれる拡張機能のアプリケーション群で構成されています。この基本機能プロダクトは労務領域だけでなく他本部も含めた複数のチームで開発されているため、労務領域単独での課題解決、意思決定ができません。そのため、EMサイクルと並行して、「技術戦略プロジェクト」という枠組みを作り、基本機能に対する技術課題のエスカレーションの仕組みも構築します。