📝 はじめに
目標設定や評価について考える中で、
こんな違和感を持ったことはないでしょうか？
- 「改善提案を3件出す」
- 「PRを月10本出す」
一見すると分かりやすい目標ですが、
本当にこれで良いのでしょうか？
本記事では、目標設計を
🔹 Why → What → How → Feedback
で分解しながら、
「指標を目標にしてしまう問題」とその解決方法について整理します。
🧱 目標設計の基本構造
まず、目標は以下の4つで構成されます。
① 🎯 ありたい姿（Why / 定性的ゴール）
- 将来的にどうなっていたいか
- どんな状態なら成功と言えるか
✨ 例
チームの中で自走できるエンジニアになり、
設計〜実装まで一人称で進められる状態になる
💡 ポイント
- 抽象でOK（むしろ抽象が良い）
- モチベーションの源泉になる
② 📊 成果指標（What / 定量）
「①が達成できた」と判断するための指標
✨ 例
- 自分主導で設計〜実装まで完了したタスク数：月3件以上
- PRのレビュー指摘数：平均3件以下
- 仕様相談の回数：週1回以下
💡 ポイント
- 誰でも判断できる
- 感覚ではなく数値で評価できる
③ ⚙️ 実行計画（How / 具体アクション）
指標を達成するための具体行動
✨ 例
- 週1回、設計レビュー前に自己レビュー
- PR作成前にチェックリスト確認（毎回）
- 毎日30分のコードリーディング
- 週1回、先輩にレビュー依頼
💡 ポイント
- 「やった / やってない」が明確
- 行動レベルまで落とす
④ 🔁 検証・改善（Feedback）
定期的に振り返る
✨ 例
-
週次でKPI確認
- タスク数 → 達成できているか？
- 指摘数 → 減っているか？
-
問題があれば改善
- 指摘が多い → チェックリスト改善
- タスクが進まない → タスク粒度見直し
💡 ポイント
- やりっぱなしにしない
- 手段（③）は柔軟に変える
🔄 全体像
① Why（ありたい姿）
↓
② What（指標）
↓
③ How（行動）
↓
④ Feedback（改善）
🤔 なぜ目標設計がうまくいかないのか
結論はシンプルです。
👉 「どこかが欠けている」
❌ よくある問題①：指標や手段を目標にしている
例
- PRを月10本出す
- 改善提案を3件出す
👉 手段 or 指標であって目的ではない
なぜダメか
- Whyがない → モチベーションが続かない
- 数値だけ追う → 本質を見失う
✅ 改善
👉 必ずWhyから考える
❌ PRを10本出す
↓
✅ チームの開発速度を上げるエンジニアになる
→ そのため、PR数を増やす
👉 一言でいうと
「指標を目標にしてしまっている問題」
❌ よくある問題②：振り返りがない
状態
- 目標を立てて終わり
- 半期の最後に思い出す
なぜダメか
- 行動のズレに気づけない
- 改善されない → 成長しない
✅ 改善
👉 Feedbackを仕組みにする
- 毎週：KPI確認
- 隔週：上司と振り返り
- 月次：目標見直し
👉 一言でいうと
「PDCAのCとAがない問題」
❌ よくある問題③：Whyが弱い
目標は以下3つを統合する必要があります。
- 自分のなりたい姿
- 会社が求める能力
- 市場で求められる能力
❌ 例
「技術力を上げたい」（自分軸だけ）
✅ 例
フロント〜バックエンドまで一貫して開発できるエンジニアになり、
自社プロダクトの開発速度と品質を高めつつ、
市場でも通用するフルスタック力を身につける
👉 一言でいうと
「Whyの設計不足」
💡 なぜ「指標を目標にしている」がダメなのか
👉 評価につながりにくいから
📊 アウトプット vs アウトカム
| 種類 | 内容 | 例 |
|---|---|---|
| アウトプット | 行動・量 | 改善提案3件 |
| アウトカム | 成果・影響 | 開発効率が上がった |
👉 評価のスタンス
アウトプットではなくアウトカムを評価する
⚠️ 何が起きるか
「改善提案3件出す」とすると…
- とりあえず3件出す
- 小粒な提案が増える
- 本質的な改善が起きない
👉 数値達成が目的化する
✅ 本来の評価
-
改善提案：1件
- ビルド時間50%削減
→ 高評価
- ビルド時間50%削減
-
改善提案：10件
- 影響なし
→ 低評価
- 影響なし
👉 評価すべきは「何を変えたか」
🎯 正しい目標の置き方
① Why
開発効率を改善できるエンジニアになる
② What
- 開発時間削減率
- バグ減少率
- リードタイム
👉 アウトカムで測る
③ How
改善提案を出す
❌ 改善提案数（How）を目標にする
✅ 改善結果（Outcome）を目標にする
🧠 SMART原則との関係
| SMART | 解釈 |
|---|---|
| S | 具体的であるか |
| M | 成果は測定可能か |
| A | 達成可能か |
| R | 関連性があるか |
| T | 期限が明確か |
❌ よくある誤解
- M（測定可能）＝件数
👉 「3件出す」になる
✅ 正しい解釈
👉 測るべきは成果
例
- リードタイム20%削減
- エラー率30%削減
⚠️ 注意：アウトカム主義のリスク
- 成果が出るまで時間がかかる
- 運や環境に左右される
- 若手が不利になる
※ 個人的には、若手（作業者）の段階では、成果（アウトカム）よりも行動（アウトプット）を重視するのもありかと考えています！
⚖️ バランスが重要
👉 アウトカム × アウトプット
- 成果（主評価）
- 行動（補助評価）
🚀 まずは何をすればいいのか？
「どう始めればいいの？」と思った方は👇
① 会社視点
- 今の役割で期待されていることは？
- どんな成果で評価されるか？
👉 評価に直結 (期待値の解像度を上げよう！)
② 自分視点
- 半年後・1年後どうなりたいか？
👉 モチベーションの源泉
③ 市場視点
- 市場で評価されるスキル・成果は？
👉 キャリアにつながる
🔍 なぜこの順番？
- 会社だけ → モチベ低い
- 自分だけ → 評価されない
- 市場だけ → 業務と乖離
👉
「会社 × 自分 × 市場」
この3つを重ねることが重要
※ どうしても上記の3つが一致しない場合、それは価値観のズレなので、転職も視野に入れるべきでは？というのが私の考えです🙅
🎉 最後に
目標設定は難しく感じますが、
- Why → What → How → Feedback
- 会社・自分・市場
この2つで整理すると、一気に考えやすくなります。
上記の考え方は下記の書籍を参考にしています。
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。