エンジニアの目標設定の実例とポイント

はじめに

こんにちは！ ホワイトプラスのWeb開発チームでエンジニアリングマネージャ(EM)をしている田中Dです。 EMとしてメンバーの目標設定や達成に向けた支援をしています。

本記事では、弊チームでの目標設定のやり方・考え方をまとめました。 目標設定が難しいと感じている方へ、何かしらプラスになれば幸いです。

※ なお、この記事の記載事項はあくまで弊チームでのお話で、全てが全社標準という訳ではありません。予めご承知おきください。

目標設定の概要

弊社の評価制度では、6ヶ月周期で目標設定と評価を行っています。 メンバーの昇給にも関わる重要な行事です。

目標は「全社目標 → 部署目標(エンジニア全体) → チーム目標(弊チーム) → 個人目標」とブレークダウンしていきます。 チームのマネージャには部署目標が降りてきて、そこからチーム目標と個人目標を設定するのがマネージャのお仕事になります。 メンバーと1on1を繰り返し実施し、およそ1ヶ月程度の期間をかけて設定します。

メンバーのキャリアに応じて目標設定の進め方が変わります。 ミドル層以上のエンジニアには、できるだけ自分で目標を考えてもらっています（マネージャはレビューを行います）。 反対に、ジュニア層のエンジニアにはマネージャが課題を特定し、目標を与える事が多いです。

目標設定とは？

私は目標設定の事を「課題をより効率よく解決するためのツール」として捉えています。

組織や個人には解決すべき課題があり、EMは課題とメンバーを繋げる役割を担います。 EMがメンバーに依頼する際......

• 課題は何か？
• なぜ取り組む必要があるのか？(目的)
• どの程度の成果を期待しているか？(ゴールや評価方法)

......等の枠組みを整えた上で丁寧に説明すると、任されたメンバーはモチベーションを高く持ち、活動しやすくなるのです。

よく「どんな目標を掲げたらメンバーのモチベが上がるだろうか？」と考えてしまいがちですが、これは順序が逆ですね。 解決すべき課題は何なのか？をまず考えたいなと思います。

また、個人の成長にばかりフォーカスしてしまいがちですが、「組織として何故この人に成長して欲しいんだっけ？」と背景から考える事で、伸ばしたいポイントやゴールをより具体的に描く事ができるようになると思います。

実例

実例として、今期のWeb開発チームの目標設定内容を記載します（全て載せると文量が多くなってしまうため、要所のみの記載です）。

前提

弊チームはフルサイクルのスクラム開発チームです。 スクラムの「開発内容を細かく分割・分担して進める」という性質上、プロジェクトの成功をメンバー個人の成果に当てはめにくい……という特性があります。

部署課題

今期は、チームの1つ上のレイヤーであるエンジニアリング部全体の課題として「コードの保守性の強化」が掲げられました。 10年以上続いているサービスで、レガシーコードがそれなりに存在しており、開発の足かせになっているためです。

チーム課題

リファクタリング等の地道な改善は日々行っておりますが、大規模な改修には手が出せていませんでした。

• 単純に手を動かすメンバーが足りない
• スキル面でも対応できるメンバーが限られる

といった理由が挙げられます。 チームのメンバー構成は「ジュニア2名・ミドル3名」で、アドバイザーとしてシニアエンジニア1名にサポートしてもらっています。 チームのスキルトップラインがミドル層のため、複数ドメインに跨るような複雑な設計は若干チャレンジングな印象です。

ミドル層のメンバーには大規模改修の経験を積んで、シニアレベルに到達して欲しいと考えています。 しかし、大規模改修に腰を据えて取り組んで頂く環境が用意できていません。 現状は事業部からの依頼(フィーチャー系の小粒の開発)が多い上、ジュニア層の育成にも時間を割く必要があるためです。

チームのビジョン

半年後のイメージとして、以下を定めました。

• ジュニア層が自走力を高めて、フィーチャー系の開発をバリバリと(見積通りのスピードで)こなしている状態
• ミドル層がより難易度の高い課題にチャレンジできている状態

個人目標：ジュニアAさんのケース

• 課題
  • コードレビューにて保守性や可読性に対する指摘が多いため、減らしたい
• 目的
  • レビューのコストを削減し、生産性を向上させるため
  • ミドル層のレビュー負荷を軽減するため
  • (将来的に)メンバーが増えた際に育成側に回って欲しい
• ゴールと評価方法
  • 基準となる過去のプルリクに対して、同程度の難易度のプルリクでの指摘がほぼ無い状態
  • 週次の1on1で前週取り組んだタスクを個別に振り返って評価を積み上げていく
  • ラスト1ヶ月における指摘の量を最終評価とする
• 取り組むこと
  • リーダブルコードの再読
  • 一般的な原理・原則の知識収集
  • 他者のコードを自分がレビューする際に可読性観点で指摘できる点が無いか意識する

個人目標：ミドルBさん(スクラムマスター)のケース

• 課題
  • サイズの大きなリファクタリングタスクに中々手が出せていないため、着手したい
• 目的
  • 保守性の向上
  • 個人として複雑な課題に対応するスキルを付ける
• ゴールと評価方法
  • サイズの大きなリファクタリングタスクの実装に着手し、継続的に進行できている状態
    • リリースまで持っていけた場合は120点！
  • 事業部からの依頼(フィーチャー系の開発)を予定通り進行できている状態(＝改善とのバランスが取れている状態)
• 取り組むこと
  • 調査・設計を主導する
  • タスクを細分化して日々のスクラムで少しずつ消化できる状態にする
  • 改善の重要性をPOに説明し、スクラムの中で改善タスクの枠を確保する

目標設定のポイント

ビジョンを持つ

数年後や半年後にチームをどんな状態にしたいか？を言語化しています。 メンバー間でブレなく一貫性のある目標(=同じ将来像に向かって進むための目標)を設定するのに役立ちます。

目標設定にかける時間

目標設定にかけている時間はおおよそ以下のイメージです。

• チーム課題の整理に1日
• メンバー1人あたりの目標設定に半日〜1日(数回に分けて1on1を実施)

目標設定の期間はかなりハードになりますが、しっかりと時間をかけるべきかなと思っています。

解決策の立案にはメンバーを頼る

マネージャは目標設定を主導しますが、できるだけ1人で抱え込まないようにしています。 課題に対する打ち手はメンバーと一緒に考えたり、考えてもらったりします。

S M A R T

月並みですが、S M A R T は私も大事にしています。 特に「測定可能か？」を疎かにすると評価のタイミングで困ることになります。 メンバーとマネージャの間で認識が一致せず、評価への納得感が得られないためです。

目標をシェアする

設定した目標は個人に留めず、チーム内でシェアしています。 「○○さんはテックリードを目指している」など分かりやすくキャラ立てをすると、周囲も応援しやすい環境になります。

また、ジュニア層の自走力を育てる上でも、ミドル層の協力が必要です。 ティーチングではなくコーチングを意識して欲しい！など予めオーダーしておきます。

自分の言葉で説明できるか

メンバーが以下を自分の言葉で説明できる状態が理想です。

• 自分の目標の背景となっている組織課題は何か？
• 自分の目標達成が、組織課題の解決にどう結びつくのか？

弊チームでは、前述の「目標をシェアする」のタイミングで説明してもらっています。

終わりに

ここまで読んで頂きありがとうございます。

今回設定した目標は 6〜7月が評価のタイミングになります。 目標設定は適切だったのか？うまくワークしたのか？ などなど、その頃にまた記事が書けたらいいなと思います。

エンジニア募集中！！！

ホワイトプラスではエンジニアを募集しています！ 目標を持って事業貢献したい方はぜひお気軽にお問い合わせください。
www.wh-plus.co.jp