こんにちは、カイポケの開発組織責任者の酒井 (@_atsushisakai)です。
事業会社で働くソフトウェアエンジニア、特にプロダクト開発に関わる人にとって、個人の目標設定に関する悩みはよく話題に上がるテーマです。「どう立てればいいのかわからない」「立てたはいいものの形骸化してしまう」「目標を達成しても思ったように評価されない」といった悩みを聞くことが多くあります。
以前、私自身の目標設定の考え方を社内でまとめたところ反応がよかったこともあり、改めて「目標」と「評価」の関係性を整理し、形骸化しにくく、成果と成長につながる目標設定の考え方を紹介したいと思います。
目標設定に関するよくある悩み
これまで複数社で主にエンジニアのマネジメントをやってきて、目標設定が難しいと感じる理由にはいくつかの共通点があるように感じています。
形だけ立てて終わる
- とりあえず何かを書かないといけないから、無難な内容にしてしまう。
達成しても評価が思い通りにならない
- 「やったことはやったのに、なぜ評価が上がらないんだろう」とモヤモヤする。
そもそも目標に何を書けばいいかわからない
- 「なりたい自分像」や「理想のキャリア」がはっきりしないと、目標が浮かばない。
こうした悩みを抱える人は少なくないと思います。また、目標を一緒に立てていくマネージャーにとっても、成熟した考え方が身についていないと、このようなメンバーの問題を解決するのは結構難しいことだと思います。
目標と評価の関係性
これまでに何度もメンバーから「目標設定」に関する相談を受けてきました。その度に、前提として目標と評価の関係性をしっかりと認識してもらうためのコミュニケーションを取っています。
目標と評価について、私の考え方を整理すると次のようになります。
目標と評価は直接紐づくものではない
エス・エム・エスのエンジニア評価は「成果評価ではなく能力評価」という手法をとっています (詳しくは、エンジニア採用ページの記載をご覧ください)。この評価手法において、目標は「これを達成したから等級UPする」「達成できなかったから評価が上がらない／下がる」というものではなく、あくまで自分がどの課題にチャレンジするのかを表明するものと位置付けています。
目標の本質は成長のための仮説立て
目標は評価のためではなく、達成することを通じて自己成長を実現するためのガイドツールです。評価されるのは「どのような意味のある成果を生み、その過程でどういう成長を遂げたのか」という結果に対してであり、目標を達成した／しなかったというそれ自体ではありません。
評価は組織ごとのマネジメントポリシーに依存する
どれだけ目標を達成し成長できていると言っても、それが会社から期待されている役割や等級の範囲を超えていなければ評価に反映されにくいこともあります。それぞれの組織にはその組織のマネジメントポリシーに沿った評価軸が存在し、その評価軸に照らし合わせて下されるものです。
つまり、目標は「成果を生むためにどの課題に取り組むかを明確にするためのツール」として活用し、評価については評価の意思決定を行うマネージャーとその評価軸をすり合わせておくことが大切だと考えています。
私自身の体験と学び
私自身も目標設定にはかなり苦労してきました。自分がどんなエンジニアやマネージャーを目指したいのか、明確なロールモデルを持っていたわけではなく、最初は「何を書けばいいかわからない」という感じでしたし、それゆえ目標設定という作業はとても苦手でした（今も得意ではありません）。
そんな中で気づいたのは、「なりたい自分像」から逆算して目標を立てるのは必ずしも必要ではないということです。むしろ、自分が今いる環境やプロジェクトの中で、
- どんなゴールが組織やプロダクトにとって意味があるのか
- そこに向かう中で何が課題になるのか
- その課題を解決するために、自分はどんな貢献ができそうか
- その貢献は自分にとって十分チャレンジングなものか
を考える方が、現実にフィットするし、プロダクト開発を主軸とするエンジニアである自分は目標を作りやすいと感じました。
ここ最近、私は目標を立てる際はいつも、
- まずは少し先の「ゴール（組織やプロダクトについて、こうなっていたら嬉しい状態）」を考える
- そこに向かう上での課題を多面的に洗い出す
- 特に重要度が高い課題を選ぶ
- その課題をどう解くか、課題を解くためにはどんなステップがありそうかを考える
というステップを踏んでいます。
これを繰り返すうちに、「目標を立てる」こと自体は苦手ではあるがやるべきことだとも感じられるようになり、周囲にも説明しやすく、評価にもつながりやすい形に自然となっていったと思います。
「目標設定テンプレート」の紹介
こうした体験を踏まえて「もっとシンプルに、形骸化しにくい目標を誰でも作れる形にしたい」と思い、今回あらためて整理したのが、ここから紹介する「目標設定テンプレート」です。
このテンプレートの大きな特徴は、「まずは事業やプロダクトのゴールを解釈し、そのゴールから逆算して課題を見つけ、そこに挑む中で成長を得る」という順序にあります。「なりたい自分像」ありきではなく、現実の課題から出発してチャレンジを設計するという考え方です。ただし、このテンプレートはプロダクト開発に関わるエンジニア向けに作っており、職種や役割によっては当然合わない部分もあるかもしれません。必要に応じて、自分の役割に合わせて調整して使ってください。
テンプレートの構成
テンプレートは大きく次の5ステップで構成しています。
- ゴール
- 現状と課題
- テーマ
- ステップとチャレンジ
- 目標 (Objectives)
テンプレートの中身と意図
テンプレートの各項目の意図と、どういう考え方で埋めると良いかを簡単に説明します。
1. ゴール
まずは、ビジネスやプロダクトの戦略、長期的な目標を踏まえて目指したい状態・達成した成果を書きます。
2. 現状と課題
このゴールに向かう上で、現在立ちはだかっている問題について言語化してください。チーム、組織、プロダクト、プロセス、自分のスキルやマインドなど多面的に洗い出しましょう。最終的に、この期間に解決すべき特に重要・緊急な課題は何かを明示してください（フォーカスすることを重視したいので最大3個程度に絞りましょう）。
3. テーマ
選んだ課題に対して、自分が取り組む際のテーマを明確化します。なぜこの課題解決を自分が担うことに意味があるのか（貢献・成長の視点）、その課題が解決された状態はどのようなものなのかについて言語化してください。
4. ステップとチャレンジ
課題を解くために、どのようなステップが必要だと考えていますか？ステップを踏んでいく中で、あなたにとって予想されるハードルやチャレンジはどんなものありますか？
5. 目標（Objectives）
フォーカスすることを重視するので、2〜3個に絞って設定してください。定性的でもOKで、ゴールや成果を示すだけでなく、ありたい姿や取り組み方に焦点を当ててもよいです。また、自身の現在の等級や役割における期待を踏まえた上で、「その目標は水準として妥当か」を見立てる意識を持つことが重要です。
この順序で整理すると、「最終的な組織全体が目指す成果を生むために今期自分自身はどの課題にチャレンジするのか」が自然と言語化できると考えています。
テンプレート活用の工夫
テンプレートを最大限活かしつつ、目標を形骸化させないために、いくつか工夫を加えると良いかもしれません。 例えば以下のような工夫を交えながら目標設定という作業に向き合うと、単なる儀式的な作業にならず、現実の課題と向き合うツールとして長く活かせるものになるはずです。
目標設定作業を1人で抱え込まない
目標は自分だけで完璧に作るものではありません。マネージャーやチームメンバーともオープンな会話ですり合わせながら、課題の優先順位やゴールの解像度を段階的に一緒に確認すると、より現実に即した内容になります。
定量化に縛られすぎない
目標を全部数字で表そうとすると、逆に本質からズレてしまうこともあります。「どういう状態を目指すのか」「どんな姿勢で取り組むのか」といった定性的な要素も、成長を示す大事なポイントです。
達成できなくてもOK
目標は「やることの宣言」ではなく「こういう仮説をもってチャレンジする」という表明です。仮に目標が達成できなくても、その過程で何を学び、未達成の原因を内省・追求し、次にどうつなげたかを言語化することができれば十分に意味のある作業です。
まとめ
プロダクト開発を担うソフトウェアエンジニアが事業成果を起点に考える目標設定をどのようなステップで行うか、その背景にある評価の考え方について紹介しました。目標は「評価のためのコミットメント」ではなく、「今どの課題にあえて挑戦するのか」を言語化し、成長と成果を結びつけるツールだと私は考えています。
もし、目標が形骸化しがちであったり、何を書けばいいかわからないなどの悩みがある場合には、ぜひ一度このテンプレートを参考にしてみてください。
