【マネージャー】 目標のブレイクダウンはどうやっている？ 【上司に直撃質問！】
こんにちは、またはお久しぶりです。EMの卵の"やも”（@yamotuki）こと鈴木です。
今回は、「目標設定の方法論」について学びがあったのでシェアしたいと思って記事を書いています。
この記事は、私がメンバーみんなの目標設定を人生初めてする前に、社内の経験豊富なマネージャーに知見を聞いて対談形式でまとめた記事です。これまでこの仕事を担っていた人は何を考えていたのだろう、というのを吸い出そうという試みです。
私はエンジニアリングチームのマネージャー、いわゆるEMになります。なので目線はややエンジニアリング周りへ偏りがあると思います。技術用語は少なめにしたのでその他のマネージャーの卵にも役立ててもらえるかもしれません。
登場人物紹介
今日は社内の身近なマネージャーたちにお話を聞いてみました。以下登場人物紹介です。今回は社外の方はおらず、いずれもM&Aクラウド所属です。
荒井さん
私の上司。1人目エンジニアとして入社されており、CTO。現在はプロダクトマネージャー（以下PdM）としても働いている。
村上さん
デザイナーメンバー。これまで上場企業でデザインのマネジメントをやられていた経験がある。
用語解説
目標は弊社ではMBO制度の中で設定されるので、用語の説明を引用で書いておきます。MBOとは？
「目標管理制度(MBO)」とは、個別またはグルーブごとに目標を設定し、それに対する達成度合いで評価を決める制度
~中略~
個別に何を達成させるのかを明確にし、個人と組織のベクトルを合わせ、最終的に個人の目標と組織の目標をリンクさせます。
目標に明示的に書かれていないものをどう扱うか
鈴木）原則として以下のようなブレイクダウンをしていくと考えています。
会社ミッション => 全社目標 => 部目標 => チーム目標 => 個人目標。
上段の部目標に明示的に書かれていないものをどう扱うか聞きたいです。部の半期や通期目標の多くは会社成長に対する目標と手段が書かれており、さらに長期のことや、成長を阻害するけど絶対やらないといけないことは書いていないことが多い。例えばライブラリアップデートとか。
荒井）実は現状だとM&Aクラウドのエンジニアのみんなに持ってもらっているMBOによる目標は部の半期目標とは関係ないものも多い。例えばあるメンバーが持っている社内全体のDX支援とか。DX支援がどれくらいのスパンで価値があるのかで考えてみると、半期には入ってこない。
鈴木）入れている理由はなんでしょう？
荒井） 半期だけじゃなくて長期であるべき形を考えているからですね。これをどう盛り込んでいくかは各マネージャーに任されている。ビジョナリなマネージャーであればあるほど長期のことを考える。例えば、全社のDXやITスキルの向上のところはミッション達成（※「テクノロジーの力でM&Aに流通革命を」）に関わると思ってメンバー個人の目標に入れてます。
村上) 全社目標からブレイクダウンする。その上で、プロダクト開発について理解しているのは我々現場に近い人間だと考える必要があります。経営チームはプロダクト開発からは遠い。プロダクト開発を長期でやっていくための布石はこちらで考えないといけない。チームをスケールさせるための布石は職種軸での詳細も経営陣と擦りあっていると良いですね。
目標到達度ではなく、バリューの方で評価されるものもある（※M&Aクラウド社は目標達成度でボーナス決定、基本給はバリュー体現評価で決定）。例えばアジャイルの思考をチームに浸透させるためのクッキング企画を進めたメンバーとかは、目標達成評価の方での判断は難しいかもしれないが、バリューの方で評価されると思う。
あとは、目標としては最初に立てていないが、後から見たときに落ちていたボールを拾ってくれたことは評価しないといけない。MBOの中で後から評価軸をチューニングしても良い。（変化の激しいスタートアップなので）状況次第で全社目標が変わり、期の途中でも個人目標もピボットすることはよくあると思う。最初に設定した目標の方向と同等のものができているなら、同等に評価したい。それは経営陣と合意が必要であるところだけど。
（荒井）僕の現在のMBO運用だと、やることが変わった時点で目標を変更しています。変わる前の目標と評価はそこまでの達成度で一旦fixする。あるメンバーは半期の中の3ヶ月目で目標が半分変わったこともありました。あるプロジェクトが違う部署の持ち物に移動して責任範囲では無くなったとか。
後から目標をちゃんと変えているので、それを評価の時にガッツリ使っても問題ない。「元に設定した目標に沿っていないけど、同等の成果だから評価する」のを考えるというのは評価の時にすごく大変。
（鈴木）なるほど。現時点で目標じゃなくても状況が変わったら目標を変えるというのは大事ですね。MBOの制度下で評価できないところをバリュー評価として入れられるように、メンバーのいい行動は探しておきたいですね。
現場が頑張れる目標設定とは？
鈴木）目標設定の一つの目的って、みんなの力を引き出すというところが一つあると思うのですが、それに対して何か設定のコツはありますか？
村上）僕が意識していたのは、大上段の目標・MVV（ミッション・ビジョン・バリュー）、今期目標、3年後、5年後、その目標達成のためにプロダクトを作るというのを伝えること。ブレイクダウンの納得感というより、「何のためにレンガを積んでいるのか？」（※レンガと教会の寓話）というのがトップやミドルマネージャーがちゃんと説明しないといけないかなと。レンガを積むの自体が面白ければそれはいいのだが、最終目標も大事。もちろん、現場で実際に働く上で、レンガ積み自体も楽しいと思えるように工夫もしないといけないけど。
目標の魅力や到達可能性は個々人ですり合わせが必要で、完璧にやるのは難しい。なので、もっと先の目標ありきの方が運用として現実的。また、上段の目標が変わるので、詳細の分解をやっているだけで半期が終わってしまうというのも考えられる。
荒井）レンガ積み自体が面白ければ、というのは結構大事だと思ってます。目標を渡すときにレンガ積みの楽しさも同時に伝えるようにしてます。デザイナもそうだと思うけど、エンジニアはコードを書くこと自体を楽しんでいる人も多い。新しいチャレンジができるよ、というところとかを魅力に感じるエンジニアもいます。僕の仕事は「仕事を切り分けて売っている」と思っている。相手によって魅力の伝え方は変わる。例えばあるメンバーに対しては「チームが良くなるのに繋がるよ」っていうところを伝える。一方で他のメンバーには「技術的に面白いよ」という違う伝え方をする。実はやることが同じみたいなのはあり得ます。
鈴木）ありがとうございます。現実的には目標の設定時期の限られた1~2週間のタイムボックスの中でやる必要がありますね。なので、前提の話を伝えつつモチベを考えつつではあるけど、後はバツっと決めるのも大事なのかなと思いました。
この記事が気に入ったらサポートをしてみませんか？