「Engineering Manager Advent Calendar 2023」シリーズ2・23日目の記事です。
はじめに
ペイトナーファクタリング事業部でEMをやっている 脇田（@shimpeee_）です。 2023年の前半より、チームでのQ目標設定と、チーム目標に紐づく個人Q目標の設定を始めました。現在、目標設定を始めて3期目です。これまでに起こった変化などをまとめていきます。
よかったこと
いきなり結論、というか記事タイトルでもありますが、「事業・チームに戦略マネジメントが生まれた」というのが最大の変化であり、よかったことです。
スタートアップである以上、リソースは限られています。しかし、やりたいことは山のようにあり、その全てが「重要かつ緊急」のように思えます。
限られたリソースの中で、最小のコストでアウトカムを最大化させるためには、「本当にやるべきこと」を決める、逆に言えば「しないこと」を決める、戦略が必要です。
目標設定（目標および、目標達成のための方針・KPI・アクションの設定）はまさに戦略策定です。戦略のおかげでチーム・個人のアクションの方向性が揃い、パフォーマンスや成長の最大化につながります。
目標設定の運用以前と以後で、明らかにチームパフォーマンスは上がったと感じます。
チームに起きた変化
日々生まれる大量の「やりたいこと」の優先度を議論する上で、目標と照らし合わせることで適切な優先度付けができるようになりました。
チームが向かうべき方向に正しく向かうためのアクションにチーム全体がフォーカスでき、結果として目標達成に近づき、ユーザー価値提供へと繋げられています。
マネージャーである自分の、メンバーとの向き合い方に起きた変化
僕自身も含め、個人レベルでも「やりたいこと」「伸ばしたいスキル」は人それぞれ多種多様です。上位のチーム目標達成につながる、かつ本人として成長したいポイントがかぶる領域を個人目標に設定し、個人の成長の最大化を狙います。
日々の業務や1on1で成長支援のためにフィードバックをさせてもらう機会も多いですが、個人目標設定以前は「あれもこれも指摘」になりがちでした。とりあえず目についたものは大小問わず全てフィードバック。
しかし、それではフィードバック内容も分散してしまい、結果的に成長には繋がりづらいです。
目標設定を始めてからは、フィードバックも基本的に目標に紐づける形で行うようにし、逆に目標に関係ない枝葉の部分はあえて言わないようにもしました。「あれもこれも」になっていた成長支援が、マネージャーにとってもアクションをフォーカスできる状態になりました。
「ピープルマネジメント」というと、1on1とか、フィードバック・コーチング・ティーチングなどの手段がトピックの中心になりがちです。
しかし、「人材育成」という観点で見ると、目標設定があってはじめて、会社の方向性と本人のwill/canとで目線の合った支援ができます。
目標に対し、日々の業務や1on1でフィードバック・コーチング・ティーチング を行い成長支援を行います。
目標設定 → 日々の業務や1on1でのメンタリング → 期末の評価・FB → 次期目標設定 という人材育成のサイクルを構築できたのは、非常に良かったです。
ペイトナーにおけるマネジメント
ペイトナー社では、EVeM社のマネジメントプログラムを全社のマネジメントの型としています。経営陣が参加した研修資料と、EVeM代表長村さんの著書『急成長を導くマネージャーの型 ~地位・権力が通用しない時代の“イーブン"なマネジメント』をベースに、マネジメントの共通言語としています。
目標とは
目標設定もEVeMのフレームワークで行っています。基本思想や構造はOKRと非常に似ています。
『急成長を導くマネージャーの型 ~地位・権力が通用しない時代の“イーブン"なマネジメント』 によると、目標設定をする目的は「チーム／個人の力を最大限引き出すこと」です。
達成確度70％ほどで残り30％は達成イメージのつかない野心的な目標を立て、立てた目標を達成しようと創意工夫することで能力が最大限引き出されます。
この「手の届くギリギリのライン」の目標を立てられるかは、マネージャーの腕の見せ所です。
過去3期分の紆余曲折ストーリー
ここからは、現場運用を開始してから現在の形に至るまでの紆余曲折のストーリーを、具体的なエピソードを交えながら紹介します。
1期目（2Q：4〜6月）
全社の中で、エンジニア組織は従業員の数が多く、唯一正式にマネージャーのポジションを配置し、組織化・マネジメントの型化が進んでいました。全社に先駆けて、エンジニア組織で目標設定の運用を始めました。
一期目となる2Qは、いわゆる four keysのひとつである「変更リードタイム xx 以内」という最重要目標を置きました。
2Q目標を立てた当時（3月〜4月）は、チームがフィーチャーフラグ運用に少し慣れてきた頃でした。元々、PRサイズが大きすぎて、レビューフローで停滞が起こり、結果として開発速度を落としていました。
フィーチャーフラグを使ってPRサイズを小さくし、レビューがスムーズに流れるようになり、その結果指標の1つとして変更リードタイムが短縮されることを目指したいと考えました。
変更リードタイムを目標を置いて3ヶ月走ってみて、期間トータルでは30％ほどの達成度に終わりました。
振り返ってみると、（最初に気づけという話なのですが）目標に置いた変更リードタイムの指標は、本来見たかった「レビューがスムーズに流れていたか」を適切に表現できる指標ではありませんでした。
変更リードタイムの定義を 特定期間にマージされたPR紐づく全コミットの、コミットからマージされるまでの時間の平均 としており、レビューフローの前後の期間も含まれていました。
また、チームメンバーにとっては「進行中のPJが期日通りに終わらせられるか？」の方が関心ごととしては大きく、「リードタイムを短くしたい！」という目標が、チームとして達成したいものになっていなかったのもよくありませんでした。目標をマネージャーである自分一人で考えてしまったのもこの失敗の大きな要因の一つだと感じました。
2期目（3Q：7〜9月）
前Qの反省を生かした目標策定プロセス
2期目となる3Qは、前Qの反省を生かし以下2点を行いました。
- 上位の「事業目標」の作成と、Qはじめに事業全体でのキックオフ実施
- 自分一人でなく、策定段階からメンバーも巻き込む
1. 事業目標の設定＆キックオフ
より本質的なエンジニアチーム目標を設定するため、事業責任者を巻き込み事業目標を作ってもらいました。
事業目標が明文化されたおかげでチームはより本質的なチーム目標を設定でき、個人は「事業- 各チーム - 個人」という上位からつながった個人目標を立てることができました。
『Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR (メジャー・ホワット・マターズ)』によると、上位目標が個人目標までつながることで連携やチームワーク、従業員のモチベーションにつながる（意訳）とあり、その状態を作ることができました。
また、Qの始まりには事業に関わる人全員参加のキックオフを開催しました。キックオフは、Qの事業目標、各チーム目標を事業の社内ステークホルダー全体に向け発表し、質問を受け付ける場としました。 キックオフは非常に好評で、
- 一体感を感じられた
- 普段関わりの薄い隣のチームの戦略が聞けて新鮮だった
等のフィードバックをもらえました。（僕は事業責任者にやりましょう！と言っただけですが）やってよかったです。キックオフは今Qも実施しています。
メンバーを巻き込んだ策定プロセス
策定段階からメンバーを巻き込んだことで、最終的には全員が納得する目標が作れたと思います。しかし、全員の意見を反映させようとしすぎた結果、目標のFixまでにかなりの時間をかけてしまいました。目標設定が完全に完了した頃には、Qの半分が終わろうとしていました。
前Qでの反省から「納得感の醸成」を意識しすぎたあまり、時間をかけすぎてしまいました。新たな課題です。
「チーム／個人の力を最大限引き出すこと」が目的であるはずの目標設定ですが、策定そのものに時間をかけすぎてしまうと実際のアクションにかける時間がなくなってしまい、本末転倒です。
納得感に関しても、毎Q終わりにチームでQの振り返りを実施しているのですが、前Qの振り返りで出たTRYを次Qの目標に組み込むことで担保できそうです。 メンバー"全員"を策定プロセスにがっつり巻き込まなくとも、一定の納得感醸成とスピードを両立できそうだと感じました。
結果
プロダクトチームとしては「PJのリリースをxx月までに完了させる」という納期遵守の目標を立てました。
この目標自体は、最終的に100%達成することができました。プロダクトチームとして過去最大級の案件を見事走りきりました。
プレスリリースも出しましたが、特許出願につながる良い結果になりました。
社内でのインタビュー記事 paytner.co.jp
結果としては目標を100％達成したものの、
- 70％達成を目指すなかで100％達成したのに、「すごいことをした！」という雰囲気があまり感じられない（ = モメンタムの創出ができなかった）
- そもそも目標が野心的ではなかったのでは？
という反省点が出ました。
3期目（4Q：10〜12月）
前Qの反省を生かした目標策定プロセス
- 目標作成に時間をかけすぎない
- 目標をより野心的にすべき
上記の3Qでの反省点に加え、もう一つ大きな改善ポイントがありました。これまでは「プロダクトチーム」の目標の中身はエンジニアをスコープとしており、PO等のエンジニア以外のプロダクトに関するステークホルダーの意向をあまり考慮しない目標になっていました。もともとエンジニア組織から目標設定を始めた名残です。
しかし、事業目標に紐づく形でのプロダクトチーム目標であれば、当然エンジニアだけでなくPOその他のステークホルダーも含めてのプロダクトチームです。エンジニアは、その中の機能の一部と捉えるべきです。
4Qのプロダクトチーム目標は、エンジニアリングマネージャーである僕と、PdM の2人で作成することにしました。
目標作成に時間をかけすぎない
前Qで時間がかかりすぎた原因は、「納得感の醸成」を意識しすぎたが故に、メンバー全員の意見を吸い上げ反映させようとしたことでした。
ここに関しては先ほども触れましたが、毎Q終わりで実施しているQの振り返りの内容を目標に組み込むことで、僕とPdMでスピーディーに決めました。
また、「スケジュールを明確にする＆前倒しする」というシンプルなタスク管理面での改善も行いました。
「なるべくQの早い段階、できれば初月1週目にはキックオフを実施したいよね」という事業責任者との話し合いの結果、今Qの振り返り＆次Qの目標作成開始を最終月3週目から開始するスケジュールを組みました。初月1週目にキックオフを行うことで、事業全体として足並みを揃えてQを走り出すことができるようになりました。ちなみに、3Qのキックオフは初月4週目だったので、大きな進歩です。
目標をより野心的にすべき
これはもうシンプルに高い目標を掲げました。「本当に達成できるかな？頑張ればなんとかなるか・・！」という、まさに「ギリギリ手の届くライン」に設定できたと思います。
PdMと共同で作った目標
プロダクトチームとして、1つの上位目標に対して3つの分解目標を立てていますが、うち2つをEMが、1つをPdMがオーナーとして持つような作り方をしました。
エンジニアだけでは出せない目線での要素も組み込むことができ、「プロダクトチーム」としてより本質的な目標設定ができていると感じます。
結果
記事執筆時点ではまだ期中ですので、最終結果や振り返りはこれからです。
期末まで2週間を切りましたが、まだまだ目標達成に向けて最後の追い込み中です。この時点で達成できるかギリギリという、いい塩梅の野心的な目標が立てられたと思います。
終わりに
最後まで読んでいただきありがとうございました！！！
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください！！
現在ペイトナーでは、以下ポジション積極採用中です！！！
- リードエンジニア
