asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。 皆さまにも一緒に学びを楽しんでいただけたら幸いです!

EM1年目が目標設定を通じて成果に向かうチーム作りに取り組んだ話

こんにちは、asken海外事業部の nakawaiです。今年の春からエンジニアリングマネージャーとして試行錯誤の日々を過ごしています。

さて本記事では、マネージャーの役割の中でもとくに悩みどころの多い目標設定について、これまでの振り返りを兼ねてアウトプットしてみようと思います。

※この記事は、Engineering Manager Advent Calendar 2022の18日目の記事です。

「目標設定」はノルマではなく、チームが成果に向かうための重要な取り組み

突然ですが、皆さんは「目標設定」という言葉にどのような印象を抱くでしょうか。

「会社から課せられるノルマ」や「人事評価のために、面倒だけど仕方なくやるもの」など、ネガティブな印象を持つ人も多いと思います。しかしそういったネガティブな印象は誤解であり、本来はメンバーの主体性や挑戦的な目標の達成のためのものであることが名著「エンジニアリング組織論への招待」の中でも語られています。

私自身もマネージャーとして目標設定に試行錯誤する中で、「目標設定=チームが成果に向かうために、マネージャーが行う重要な取り組み」であるという実感を日々強めています。

目標設定にチャレンジしてみたかった理由

もともとエンジニアだった私が、会社からマネージャーへの役割変更を打診された際に、迷いつつも「挑戦してみたい」と思った理由の一つに目標設定があります。 というのも、当時マネージャーの補佐的な役割で開発チームの目標設定に関わっていく中で、エンジニア以外のメンバー(※)も含めたチーム全体にマネージャーとして関わることで、よりチームが成果に向かう状態に近づけられるのでは?という予感があったからです。

(※)私がマネージャーになるタイミングで、それまでは開発チームとマーケティングチームで別だったマネジメント担当が一本化されました。つまり、私が現在マネジメントする対象のチームはミッションチーム寄りです。

2022年12月時点の目標設定サイクル

どうすれば目標設定がより機能するのか色々試行錯誤した結果、弊チームでは現在のところ図のような目標設定のサイクルにしています。

次のチーム方針や目標設定を見据えてチーム振り返りを設計する

チーム振り返りは、次のチーム目標を定める上で特に重要だと考えている部分です。図のなかでチーム振り返りの番号を①としているのも、「まずは振り返りから」という意図を込めています。チーム振り返りの結果を踏まえてチーム目標を考えることで、目標の質や納得感を高めることにも貢献している感触があります。

目標がノルマではなくチームのゴールとして機能するためにも、振り返りはとても重要なプロセスだと考えます。振り返りのフレームワークは目的と結果のギャップにフォーカスしやすいものを採用することが多く、最近は Sailboat Retrospectiveや AAR(After Action Review) を使うことが多いです。

目標設定を通じたコミュニケーションで認識を合わせる

①チーム振り返りから③個人目標設定までを具体化する過程において、チームメンバーやステークホルダーとさまざまなコミュニケーションが発生します。なんとなく「認識は揃っているだろう」と思っていても、目標として具体化していく過程で、実は前提の認識が大きくずれていたり情報格差の大きい部分があることに気づくことができました。

具体的な事例として、以前に「ユーザー価値の検証を最優先し、経営上問題ない範囲で売上の優先度を下げよう」という方針を決めたことがありました。方針としては各自の認識があっていたのですが、いざ具体的な目標として具体化していくと「経営上問題ない範囲」や「売上の優先度を下げる」などといった部分の具体的なイメージが、各自で大きく異なっていたと言うことに気づけました。そこで改めてステークホルダーも交えて前提の認識を合わせ直し、「経営上問題ない範囲」の背景や具体的な数字、「売上はゴール指標ではなくガードレール指標である」という、成果に向かう上で重要な前提の認識を早い段階で揃えることができました。

このように、設定される目標そのものも大事ですが、目標設定の過程で生み出される情報も非常に重要だと感じます。

ただしステークホルダーは多忙な場合も多いため、状況によっては意識的に接点を増やすような工夫も必要かもしれません。私自身も、マネージャーになったタイミングでステークホルダーと週一のMTGを設けるなどして、事業に対する解像度を上げるように意識しました。

定性目標/定量目標は相互に補完しあう関係

ゴールに対する認識を合わせるうえでは、やはり定性/定量をセットで考えることはとても重要だと感じました。

現在海外事業チームではペルソナを再定義したことなどもあり、定性的な目標として初日のユーザー体験の改善に改めてフォーカスしています。それを定量化した指標として「翌日再訪率(D1 retention rate)」を採用しています。

定量的な指標だけを目標にしてしまうと、「初日のユーザー体験を改善する」という目的や、本質的に解決したい課題とずれた取り組みに目が行ってしまいます。また、定量化を行わないと「いつまでに何がどうなったら初日のユーザー体験が改善されたと言えるのか」が判断できません。 これは、OKR における Objectiveと Key Result の考え方にも通じるのかなと思います。

定性的な目標の言語化を促す問いを作る

メンバー個人の目標を立ててもらう上でも、まず定性的な言語化を先に行なってもらっています。ここも現在進行形で試行錯誤中ですが、現在は以下のような問いを立てて言語化をしてもらっています。

  1. 今期中にチームが出すべき成果は何か?
  2. 上記の成果に至るために、自分が最も取り組むべきことは何か?
  3. 取り組んだ結果、何がどういう状態になれば成果に貢献したと言えるか?

改めてチームのゴールを再確認し、そこから個人がフォーカスすべきことと、目指すべきゴールを言語化する、という流れを想定しています。

最近の印象に残った出来事として、メンバーの一人がこの問いを通じて当時の価値検証のスピードや質に関する課題感を共有してくれたことがありました。それについて1on1を通じて深掘りなどをしつつ、メンバー自身に目標として具体化してもらいました。そうして取り組んでもらった結果、期末に価値検証期間の短縮という成果につなげてもらうことができました。後日そのメンバーから「これまでになく個人目標をうまく活用できて良かった」というフィードバックをもらうことができ、マネージャーとして目標設定の手応えを感じられたことを覚えています。

チームが成果に向かう上で、マネージャーが目標設定をいかに機能させるかはとても重要なのだなとあらためて実感したエピソードでした。

今後の課題

目標設定はチームが成果に向かう上でとても重要ですが、しっかりやればやろうとするほど時間がかかります。ここのバランスはなかなか難しく、いまも手探り中です。感覚としては、「メンバーの取り組みをしっかり適正に評価する」という強い意志を持ちつつ、目標の不完全さや不確実さも受け入れて、中間見直しなどでうまく変化に対応しながらやっていくことが大事なのかなと思います。

お知らせ:コーチングの勉強会を開催します

askenでは定期的にエンジニアリングに関する勉強会を開催しています。次回は「エンジニア組織とコーチング」というテーマで開催しますので、ご興味がある方はぜひご参加ください。 asken.connpass.com

エンジニアを積極採用中です

あすけんでは、チーム一丸となって成果に向かいたいエンジニアを募集しています! 少しでも興味を持っていただけたら、ぜひ採用情報をご確認ください。

www.wantedly.com

www.wantedly.com

www.wantedly.com