メンバーが自走して課題解決に向かうことができるチームマネジメント

はじめに

アライドアーキテクツ株式会社でプロダクト開発チームのEngineering Manager兼Product Managerを担当している@hime0724です。
この記事は Engineering Manager Advent Calendar 2019 の7日目の記事です。

この記事では、私がチームマネジメントをする際に意識しているメンバーが自走して課題解決に向かうことができるチームマネジメントについて紹介したいと思います。

なぜメンバーの自走を意識しているかというと、開発はチームプレイが前提としてあり個々の能力の集合値によってチームのパフォーマンスは変わると考えているからです。
リーダーによるトップダウンだけだと、リーダーがボトルネックになったり、リーダーの能力次第でチームのパフォーマンスの最大値が決まるため、チームとしてスケールし辛くなると考えています。
メンバー1人1人が考え能力を発揮してもらうことで、チーム力はスケールしやすくなるので、メンバーが自走できることを意識しています。
ただ、メンバーが向いているベクトルがバラバラではチームとして機能しないため、向かうゴールの設定とメンバーが自走できる環境を作ったり権限を適切に移譲することがマネージャーの責務だと考え、以下の2点を意識してチームマネジメントを行っています。

メンバーが自走して課題解決に向かうことができるチームマネジメントで意識している2つのアクション
- (1) メンバーが自走できるような、明確なゴール設定（定量的なKPI)
- (2) 権限の移譲

定量的なKPIについて、KPIは四半期単位で設定しており、内容としては開発チーム自体やシステムのパフォーマンスなどから選定しています。
KPIを選定する際は、前四半期から課題を抽出し、それを解決するための指標を設定しています。

本記事では今年採用した2つのKPIの事例をもとに、自走型チームへのマネジメントについて紹介します。

事例1: リードタイム

課題背景

私のチームが担当しているプロダクトは、企業のマーケティング活動を支援するtoB向けのSaaS (Software as a Service)で、月額課金を採用しております。
継続利用してもらうことが重要なビジネスモデルとなるため、プロダクトの機能追加・改善が開発チームのミッションになっています。

昨年、新しいSaaSプロダクトをローンチし、ローンチ後も毎月のように機能リリースを展開していたのですが、3〜4ヶ月を過ぎた辺りから、デリバリーのリードタイムが増加傾向にありました。

リードタイムとはリーン手法において 「顧客のリクエストからそのリクエストが満たされるまでの所要時間」を指し、私のチームでは、【開発チケットが作成されてから、本番環境にデプロイされ顧客がその恩恵を受けれる状態になるまで】をリードタイムと定義しています。
リードタイムが増加するということは、顧客に新機能を体験してもらう機会が減るため、市場の顧客獲得及び利用顧客の満足度向上の機会損失につながるため、SaaS開発では重要視されている指標の一つです。

計測したところ、ローンチ直後に比べると、平均1.5倍近くにまで増加していました。
プロダクトのフェーズとして、新機能追加を盛んに行う必要があったため、リードタイムを削減することを目的にKPIを設定し改善に取り組みました。

改善

(1) メンバーが自走できるような、明確なゴール設定（定量的なKPI)

まずKPIですが、ローンチ直後の数値を意識して、【リードタイムの1.5倍短縮】をチームで目指すことにしました。
設定したゴールについてメンバーに納得感をもって改善をしてもらいたいため、指標の妥当性となぜこの指標を改善しないといけないかをメンバーに伝えた上でチームのKPIとしています。
チームで現状を把握できるよう、ダッシュボードを作成し、リリース後にリードタイムに改善がみられたかチームで振り替えれるようにしました。

(2) 権限の移譲

リードタイムが増加している原因としては、要件定義や画面設計時にタスクのスコープが広がっていることでした。
その結果、コーディングやテストのスコープも広がり、全体のリードタイムを押し上げていることがわかりました。
これは、ローンチ初期に比べると、機能間の連携が増えたり、1機能を構成する要素が増えたことにより、機能追加時の要件自体が複雑化し易くなっていたからです。

画面設計、システム設計、コーディングとチームメンバーが担当する工程で発生する仕様調整を私が都度入るのは効率が悪く、結果リードタイムの増加につながると考え、メンバー自身でタスクの肥大化を防げるよう、要件定義の段階で、そのタスクのスコープを明確にするための「ステートメントシート」というドキュメントを作成することにしました。

「ステートメントシート」には、以下の内容を記載しています。
1. 課題: 解決すべき、明確な課題
2. ステートメント: 課題が解決された状態
3. ユースケース: 対象の機能を顧客が利用する明確なユースケース
4. コア機能: ステートメントを実現するために、必要な機能のリスト
5. 諦めること: 実施しないこと、別のタスクに委譲する機能などを記載

このドキュメントの目的としては、タスクで解決したい課題と課題が解決された状態を明文化することで、ゴールイメージをチーム全体で持つことです。
タスクで実施しないことも予め定義しておくことにより、要件定義以降のフェーズで肥大化を防ぐ効果も期待できます。
注意点としては詳細に書き過ぎると逆にメンバーの行動を抑制してしまうことに繋がるので、外したくないポイントだけ書いて、メンバーが担当領域でブラッシュアップできるよう試行錯誤しながら書いています。
このドキュメントに記載されていない追加仕様で困ったときだけチームで議論し、議論がまとまらなかった時にPMがサポートすることで、メンバーの主体性が出るようにも気を配っています。

開発を進めていくなかで、追加で開発したほうが良いタスクについては、別タスクに切り出すこともメンバーが自主的に進めてくれ、タスク生成にもメンバーが積極的に参加してくれたのも良かった点になります。

具体的なリードタイムの目標値を提示し、問題となっていた箇所へ対策を行ったことにより、リードタイムをローンチ直後と同水準まで削減することができました。
また、各タスク自体のスコープがスリムになったことにより、タスク単位でのバグ発生率を下げる副次的効果も得ることができました。

事例2: レスポンスタイム

課題背景

プロダクトの成長と共にシステムで扱うデータ数が増加していき、サイトのレスポンスタイムが遅くなるという課題が発生しました。

遅いところでは、表示に10秒以上必要なページも存在しました。
いくらリードタイムを改善し機能リリースのサイクルを早めたところで、利用顧客にとってストレスフルな機能を提供し続けると顧客満足度の低下につながるため、チームで改善に動きました。

改善

(1) メンバーが自走できるような、明確なゴール設定（定量的なKPI)

KPIについては、フロントエンドよりもバックエンドの処理で時間がかかっていたので、バックエンドのAPIに対象に【レスポンスタイムを2,000ms以下】をKPIに設定しました。
このKPIについてはもメンバーに納得感をもって改善をしてもらうため、指標の妥当性となぜこの指標を改善しないといけないかをメンバーに伝えた上でチームのKPIに設定しました。

(2) 権限の移譲

新機能のタスクと改善タスクではタスクの粒度が異なり、タスク優先度の意思決定が複雑になりがちになると予想されたため、改善タスクを専門に進めるチームを新機能チームとは別に編成しました。

機能優先度だけ予めPMが選定し、その中でどのAPIが遅くなっているかを確認できるダッシュボードをNewRelicで作成しました。
後は、NewRelicのダッシュボードを確認するだけで、メンバー自身が自主的に遅い箇所を改善するタスクを生成し、現場でスピーディーな改善サイクルをまわしてくれました。

※NewRelicのダッシュボードイメージ

また、新規機能チームもこのダッシュボードを参照し、チーム全体で現状把握ができるようにし、チームの定例会議で議論することで、チーム全体でパフォーマンスに対する意識向上に努めました。
その結果、新規機能開発チームも設計時に本番データ数を想定したレスポンスタイムの検証を行うことで処理の遅いAPIを増やさないよう新規機能開発チームも意識をしてくれるようになりました。
今までパフォーマンスをあまり意識しなかったメンバーも設計時にパフォーマンスを意識できるようになったことで、チーム力の底上げにもつながった点も良かったです。

結果としては、四半期内に対象としていた全APIでKPIを達成し、安定したシステムを提供できるまでに改善が進みました。

おわりに

昔に比べると、マネジメントに対するイメージも変わってきていると思いますがまだまだ、「マネージャーって大変ですよね？」って質問をされることが多いです。
もちろんマネージャーになった当初はわからないことが多く辛かったですが、最近はマネージャーの仕事が楽しいと思えるようになってきました。
本記事で紹介した成果は僕から発信して進めましたが、最終的に良い成果が出せたのは特にメンバー一人一人がコミットしてくれたからです。
チームで成果が出た時はマネージャーやってて良かったと思える瞬間の一つで、成果にコミットしてくれたメンバーには感謝しきれないです。
チームで大きな成果を出すことに喜びを感じれる人は、マネージャーに向いていると思うので、来年もより多くのEngineering Managerになる人が増えることを期待し、本記事が少しでも参考になれれば幸いです。