初めての目標設定の失敗共有【エンジニアリングマネージャー】
こんにちは。EMの卵の”やも”（@yamotuki）こと鈴木です。普段はM&Aクラウドという会社でエンジニア活動をしています。最近エンジニアリングマネージャー（EM）になったので、実際にやってみた業務での学びを共有したいと思います。
前回は「目標のブレイクダウンはどうやっている？」というタイトルで上司に実務の考え方を聞いた記事を書きました。
今回の記事では「実際にやってみてどうだったのか？」を発生した問題ベースでシェアしたいと考えています。
目標ブレイクダウン、自分のチームだけ考えがち問題
課題認識と目標が「コインの裏返し」になっている
個人目標が”個人の成長”を意識しすぎたものになっている問題
頑張りがいのない目標になっている問題
目標ブレイクダウン、自分のチームだけ考えがち問題
私は今回エンジニアリングチームのマネージャーとして仕事をすることになりました。そのため目標設定のセオリーだと思っていた以下の方法でブレイクダウンを始めました。
全社長期・中期目標の理解
部門半期目標の理解
個人目標の設定
ここには大きな欠陥があって、「エンジニアリングチーム」の横に協調して働く「UXチーム」（PdMやデザイナが所属）があるという視点が抜けていました。
この半期の部の目標の一つはとてもざっくりいうと「大きなプロジェクトの仕様を固め、期限内にユーザ価値になるものを外に出す」でした。しかしながら私が最初に立てた目標は、どこまで方針や仕様が固まっているのか意識せず「エンジニアが実装を終わらせる」に強く偏った目標となってしまっていました。つまり、「部門半期目標の理解」と「個人目標の設定」の間に入るべきである「チーム目標の理解（チームがどう動くべきか）」の情報が弱かったのです。
目標設定週間の後半になり、その視点が抜けていることにUXチーム側のマネージャーが気がついてくれました。実装ありきより、仕様を高速で決められる座組みを前提とした目標設定が行われました。
あるメンバーが持っていた目標の before/after は以下のようになりました。
before: 実装目標から逆算したロードマップ作成してプロジェクト回し（仕様がかっちり決まっている前提。せっかくスクラムをやっているのにウォーターフォール的な思想）
after: スプリントゴール仮作成とPBI作成をPdMとともに行う（詳細仕様を決めながら細かいイテレーションで価値を出すのをスムーズに行う思想）
また、追加で他のメンバーに「もっと大枠の仕様を決めるためにPdMと話しつつ技術意思決定とROIの明示」を持ってもらうことになりました。
エンジニアリングチームはそのチームだけで動くわけでなく、会社として成果を出すために動く1チームです。他のチームとコラボレーションして成果を出せるように目標設定する必要がありました。
課題認識と目標が「コインの裏返し」になっている
課題と解決策が1:1になっているいわゆる「コインの裏返し」の解決策ほど愚かなものはありません。書籍「問題解決の全体観 上巻」には以下のように書かれています。
コインの裏返し
問題認識を、そのままひっくり返して解決案にしてしまうものである。
例えば「当社の営業マンは競合企業に比べて50人少ない」という問題に対して「営業マンを50人増やそう」といった解決案を作ってしまうようなものである。
~略~
解決案としては最もレベルの低いものの一つである。なぜなら、コインの裏返しで難しい問題が解決することはほとんどないからだ。
私の課題認識として「アラートが最近増えている」というものがありました。これに対して「アラートを減らしてシステムを安定化する」という目標設定を一人のメンバーに対して置こうとしました。
これに対し、メンバーから以下のように指摘を受け、目標を変更してもらいました。
アラート対応の目的はUX悪化を防ぐこと。その対応に追われて開発業務が進まない問題があったらそれを潰すことが重要。現在は SLO 99.95%を満たしており、外部品質への投資優先度は高くない。アラート件数を減らすこと自体は現在の保守タスク消化の座組みの上で行うでよい。
SLO満たしているなら投資対象として他のところに投資した方が良い。ROIを考えるべき。Four Keysを追うことでより早いユーザ価値提供やMTTRを低下させる仕事に注力したい。
そもそもROIを考えていなかった自分を恥じ、目指すべき方向を示してくれたメンバーに感謝。最初から最終決定となる目標を押し付けず、目標設定を自身でできるメンバーには持ち帰ってもらって提案を出してもらうという動きができたのはうまくワークしたところだと思いました。
個人目標が”個人の成長”を意識しすぎたものになっている問題
組織目標に紐づく個人目標を持ってもらい、それに対して全力を尽くせれば個人は成長します。私は最初、目標を持つ個人が一人で主導できないかも（＝自分から巻き込むではなくて、周りの積極サポートを受けて達成できるかも）という目標でも、個人に持ってもらおうとしていました。それは、本人が主導できなくても、周りが助けて結果的に達成できれば組織のためになるだろうと考えていました。また、多少無茶な目標であってもサポートを受けて一度達成してしまえば仕事のやり方を学べるだろう、という意図でした。
例えば、今まで弊社で仕様策定の初期工程をやったことのないメンバーに対して、本人の希望を考慮して「仕様策定の仕事をうまくやること」（※実際の詳細表現は違います）を目標を置いていました。
しかし、弊社ではMBOの目標は達成度によりボーナスに直接紐づくものです。その目標を達成した方法を問わず、達成していればボーナスが個人に支払われます。その仕組みの上では、ボーナスは「実際の主導をした人」ではなくて「MBO目標をサポートしてもらった人」に支払われてしまいます。それは頑張った人に報いる正当な評価とは言えません。
このことを上司に指摘され、それぞれが主導権を持って達成できる目標にすることにしました。
MBO目標として持っていなくても、その仕事に対して全力でサポートをした場合には、MBOの文脈ではなくバリュー体現評価として基本給に反映されることになります。
頑張りがいのない目標になっている問題
最初の個人目標素案に、最初の方に失敗してしまうと後から巻き返し辛い目標がありました。具体的には、スプリントゴール（ざっくり言うと1週間で出すユーザ価値の塊をゴールとしたもの）の半期での達成率を設定していました。スプリントゴール達成率は過去実績で90%程度だったのですが、同等を目指そうとすると半期25週間のうち2~3回ほどしか失敗できない目標です。裏を返すと、どこかで4回ほど失敗してしまうと後からいくら頑張ったとしてももう100%達成はあり得ないのです。仮に頑張っても巻き返せないと分かると、人はやる気を失ってしまうものだと思います。
この目標を設定した背景としては「特に重大なプロジェクトを加速させて欲しい」だったり「エンジニアとして実装力を活かして価値を提供してほしい」というところでした。この目的を達成できるのであれば他の指標でも問題はありません。
そこで、過去の目標である程度ワークしていた「プルリクエストを稼働日平均で1.5個出す」を目標に使用することにしました。この目標はアウトプットの指標としての賛否はあると思うのですが、タスクを適切なサイズのサブタスクに分割し、素早い実装で価値を出してもらうのを期待する形です。
あくまで”平均”なので、最初の方に多少上手くいかなくても、後半に工夫したり注力することで巻き返せる目標になっています。
終わりに
今回は目標設定での理解の甘さがあったところについてシェアしました。
この記事に書いた問題は、目標設定期間でのみ気がついたものです。実際に目指すべき目標として運用した場合にはさらに問題が発生すると思います。またそれを乗り越えられたら整理してシェアさせて頂きたいと思います。