エンジニアのOKR・MBOの目標設定は昇給額をどこまで左右するか｜改定率3.9%の内側

期初に書いた目標シートは、期末の昇給額をどこまで決めているのか。結論から言うと、目標設定が動かせるのは会社が用意した昇給原資の配分だけで、原資そのものの大きさは動かせません。 目標の精度を上げる作業には意味がありますが、効く範囲を取り違えると、報われない努力に時間を使うことになります。

まず、動かせる範囲の大きさを確かめます。

目標設定が動かすのは「配分」だけ

昇給額は、会社が決めた改定の総枠を、評価に応じて社員へ配った結果として出てきます。目標設定が関わるのは後半の配り方だけで、総枠の大きさは業績と制度の側で先に決まっています。

令和7年の調査では、情報通信業の1人平均賃金の改定率は 3.9% でした。金額に換算すると 14,096円/月 です。

この数字は「情報通信業で働く人の昇給額の平均」であって、評価が高い人の昇給額ではありません。評価配分が厚い会社なら上位者はこの平均を超え、下位者は下回ります。つまり目標設定が効くのは、この平均を中心に上下へどれだけずれるかという部分です。

注意したいのは、全産業の改定率が 4.4% で、情報通信業はそれを下回っている点です。IT職の年収が伸びているという印象と、昇給率の実態は別の話です。年収の伸びは昇給よりも、転職と昇格のほうが大きく関わります。

昇給の中身が評価で決まる会社はどれだけあるか

目標設定の重みは、会社がどういう昇給制度を持っているかで変わります。制度の普及状況は調査で確認できます。

表の読み方は、上の3行と4行目を分けて見ることです。上の3行は「昇給という仕組みがあるか」を示していて、ほとんどの会社にあります。4行目は「その昇給額が評価で決まるか」で、これも大半の会社が当てはまります。だからこそ、目標設定と評価は昇給額に効きます。

一方で最下行のベースアップは、実施した企業が半分程度にとどまります。ベースアップは評価に関係なく給与テーブル自体を上げる改定なので、評価がどうであれ全員に効く部分です。自分の昇給通知を見るときは、評価で動いた分とテーブルが動いた分を分けて読む必要があります（定期昇給とベアの見分け方）。

この表は企業単位の割合なので、自社が当てはまるかどうかは別に確かめてください。制度があることと、運用されていることも違います。定期昇給制度がある企業の割合と、実際に実施した企業の割合に差があるのは、業績によって見送る年があるためです。

OKRとMBOは昇給へのつながり方が違う

同じ「目標設定」という言葉でも、OKRとMBOでは評価へのつながり方が設計上異なります。ここを混ぜて考えると、目標の立て方を間違えます。

MBOは、個人が期初に設定した目標の達成度を、そのまま評価の材料にする枠組みです。達成度が評価点になり、評価点が昇給額に変換されます。だから目標の難易度と測り方が、そのまま報酬に跳ね返ります。

OKRは、全社の目標を部門と個人へ分解し、方向を揃えるための枠組みとして使われます。意図的に高い目標を置き、達成率が7割程度でも良いとする運用が一般的です。達成率をそのまま評価点に変換しないという前提があるため、ここを昇給へ直結させると、全員が達成できる水準の目標を書くようになり、枠組みの目的が崩れます。

実務では、OKRを方向付けに使いながら、評価と昇給は別のコンピテンシー評価や等級要件で決める会社があります。この場合、OKRの達成率を上げても昇給額は動かず、等級要件の充足度のほうが効きます。逆に、OKRの達成率を評価点に直接使う会社もあります。どちらの運用かを期初に確認しないまま走ると、半期分の努力が評価の対象外になることがあります。

期初の目標設定で、期末にできることが決まる

評価の結果は期末に決まりますが、結果を左右する条件のほとんどは期初に固定されます。 目標の数、重み付け、達成の測り方、どの業務を目標に含めるかは、期初に決めた内容がそのまま採点表になるためです。

期末の自己評価シートでできるのは、やったことを等級要件の言葉に翻訳して、評価者が社内で説明できる形にすることです。それ自体に効果はありますが、目標の外側でやった仕事を目標の中に入れ直すことはできません（自己評価シートの書き方）。

具体例で考えます。期初に「決済APIの移行を完了する」とだけ書いた人と、「決済APIの移行を完了し、移行後の障害ゼロで3か月運用する」と書いた人がいるとします。前者は移行が終われば達成で、品質は評価の対象になりません。後者は運用まで含めて評価されるので、同じ仕事をしても評価の対象範囲が広くなります。

ただし範囲を広げすぎると、自分の裁量の外で達成が決まる目標になります。他チームの意思決定や外部ベンダーの作業に依存する条件を入れると、努力と結果の対応が切れます。目標に入れるのは、自分の判断で進退が変わる範囲までに留めるのが現実的です。

エンジニアの仕事を目標に落とす4つの型

エンジニアの仕事は、成果が数字になりにくい部分を多く含みます。それでも評価の対象にするには、観測できる形に言い換える必要があります。よく使える型は4つです。

この表は、上から下へ行くほど測りやすく、同時に評価の重みが軽くなります。状態目標と影響目標は、達成したかどうかの判定に解釈が入るぶん、達成すれば等級要件の上位の記述に届きます。量目標は判定が機械的で揉めませんが、こなした量として読まれるため、等級を一段上げる材料にはなりにくいです。

使い分けの目安は、自分が次にどの等級要件を満たしたいかで決めることです。要件に「設計方針を決められる」と書いてあるなら判断目標が噛み合い、「安定運用に責任を持てる」と書いてあるなら状態目標が噛み合います（等級・グレード制度の読み方）。

4つのうちどれも書けない仕事がある場合、それは目標ではなく職務の前提として扱われている可能性があります。次の2つの節で扱います。

数値目標が仕事を歪めるとき

数値目標には、達成しやすくするために本来やるべきでない行動を選んでしまうという副作用があります。期初の設計段階で、この可能性を潰しておく必要があります。

理由は単純で、測られる数字と、組織が本当に欲しい成果が一致しないことがあるためです。測られているほうが報酬につながるので、合理的に動けば数字のほうへ寄ります。

具体例を挙げます。「リリース回数を増やす」を目標にすると、まとめてよい変更を小分けにしてリリース回数を稼げます。「テストカバレッジを規定値まで上げる」を目標にすると、重要な分岐ではなく通しやすい箇所のテストを増やすほうが早く達成できます。「対応チケット数」を目標にすると、原因を調べて根本を直すより、表面的に閉じるほうが件数が伸びます。

対策は、数字を1つだけ置かないことです。リリース回数を置くなら、変更失敗率や障害件数のような、質を担保する指標を同じ目標の中に添えます。評価者と合意しておけば、期末に「数字は達成したが質が落ちた」と後から減点される事態も避けられます。注意点として、指標を増やしすぎると今度は何を優先すべきか分からなくなるため、1つの目標に添える指標は2つまでが扱いやすい範囲です。

目標に書けない仕事をどう扱うか

コードレビュー、障害の一次対応、設計の相談役、新しく入った人のオンボーディング支援。これらは目標シートに書きにくく、しかもチームの生産性には強く効きます。扱いを決めずに引き受け続けると、時間を使った量に比べて評価に残る量が少ないという状態になります。

まず確認するのは、等級要件の側にこれらの記述があるかどうかです。要件に「チームの生産性に寄与する」「技術的な相談に応じられる」といった項目があるなら、目標欄に書かなくても評価の対象になります。その場合に必要なのは、期中の記録です。レビューの指摘をコメントとして残す、障害対応の経緯をドキュメントに書く、相談の結論を共有チャンネルに残す。記録が残っていれば、期末に実績として差し出せます。

等級要件にもどこにも記述がない場合は、評価されない仕事だと分かったうえで引き受ける量を決める判断になります。全部断るという話ではありません。チームが回らなくなれば自分の目標も達成できないため、必要な範囲は引き受けます。ただし、評価されない仕事に時間を寄せ続けると、評価される仕事の進捗が落ちます。期初の面談で「この範囲を担当する前提なら、目標の数は3つに絞りたい」と交渉するほうが建設的です。

例外として、評価制度の外側で報酬に効く場合があります。相談役として機能している事実が、昇格の推薦理由や、社内公募での受け入れ判断に影響することです。制度上は目標外でも、人の判断としては見られています。ただしこれは確実性のない経路なので、期待値として織り込みすぎないでください。

評価が高いのに昇給額が小さいとき

目標を達成し、評価も高かったのに昇給額が期待より小さい。この場合、原因は目標設定ではなく配分と原資の側にあります。見るところは3つです。

1. 配分方式 — 原資を一律に配る比率が高い会社では、評価で動く幅がそもそも小さくなります（一律配分か評価配分か）
2. 評価の枠 — 相対評価では上位評価に人数枠があり、成果の絶対量ではなく分布の中の位置で決まります（相対評価と絶対評価）
3. 原資の総額 — 会社の業績が改定の総枠を決めます。決算から昇給余力を読む手順があります（決算から昇給余力を読む）

3つのうち自分の努力で動かせるものはありません。だからこそ、期初の時点で確認しておく価値があります。評価で動く幅が小さい会社だと分かれば、目標設定に時間をかけるより、昇格の要件を満たす方向へ力を振ったほうが金額の効きが大きくなります。

企業規模による原資の差も確認しておきます。改定率は従業員5,000人以上で 5.1%、100〜299人で 3.6% でした。評価が同じなら、規模の大きい会社のほうが配られる原資が大きい傾向があります。ただしこれは企業単位の平均で、個々の会社の業績によって大きくずれます。

目標設定では動かない差

昇給の話に時間をかける前に、目標設定でも評価でも動かない差の大きさを把握しておきます。実務3〜5年・東京勤務・スキル中位という条件を固定して、企業タイプだけを変えるとこうなります。

この表は当サイトの推定モデルによる値で、経験年数・勤務地・スキルを揃えたうえで企業タイプだけを動かしています。上端と下端の開きは、1年の昇給で埋まる幅とは桁が違います。事業の利益率と商流の深さという構造から来る差なので、目標設定の精度では動きません（企業タイプ別の年収相場）。

適用できないケースもあります。同じ企業タイプの中でも、報酬水準を意図的に高く設定している会社と、人員規模を優先する会社があります。表はタイプごとの中心を示すもので、個別の会社の提示額を当てるものではありません。応募先の水準は、求人票のレンジと等級の対応で確かめてください。

改定の回数も、年間の伸び方に関わります。年1回の会社と年2回の会社では、同じ年率でも途中の段差が変わります（昇給は年1回と年2回でどちらが有利か）。

同じ等級の中では、スキルで位置が動く

構造の差は動きませんが、同じ枠の中での位置は動きます。実務3〜5年・東京・上場企業という条件を固定し、スキルの水準だけを変えると次のようになります。

• スキル下位（スコア30）：491〜576万円
• スキル上位（スコア85）：602〜707万円

目標設定が効くのは、この幅の中でどこに置かれるかという部分です。幅の中で上側に行くには、目標の達成そのものより、達成した内容が等級要件のどの記述に対応するかを示せるかどうかが関わります。

注意点として、この推定は同条件のモデル値であり、個人の提示額を保証するものではありません。自分の現在位置を確かめる用途に使ってください。

期初・期中・期末に確認する手順

目標設定を昇給につなげるためにやることを、時期ごとに並べます。

1. 期初 — 目標の数と重み付け、達成度の判定者、難易度を評価に加味するかを確認する
2. 期初 — 目標に含めない業務のうち、等級要件で評価される項目を把握しておく
3. 期中 — 目標の前提が変わったら、変更を記録に残したうえで評価者と目標を更新する
4. 期中 — 目標外で引き受けた仕事の記録を、その都度残す（期末に思い出そうとしない）
5. 期末 — 達成度の判定根拠を自分の言葉で用意し、等級要件の記述に対応づける
6. 昇給通知後 — 評価で動いた分とテーブルが動いた分を分けて確認する

この順番で効果が大きいのは1と3です。1は採点表そのものを決める作業で、3は前提が変わった事実を残す作業です。期中に仕様が変わって達成不能になった目標を、そのまま期末まで放置すると未達として扱われます。変更の合意を取っておけば、同じ結果でも評価が変わります。

手順のうち6だけは昇給額が出てからの確認ですが、翌期の目標設定の材料になります。評価で動いた幅が小さいと分かれば、翌期は目標の精度ではなく昇格要件に力を振るという判断ができます。

制度と目標が噛み合っていない会社の見分け方

制度が整っていない会社では、目標設定にかけた時間が報酬に反映されません。見分ける材料は、目標設定の面談で得られる答えの具体性です。

噛み合っている会社では、目標の重み付けと評価への反映ルールが文書化されており、評価者が説明できます。等級要件も明文化されていて、目標がどの要件に対応するかを話せます。この状態なら、目標設定は昇給に効く作業です。

噛み合っていない会社では、目標が形式的な提出物として扱われます。重み付けの説明がない、達成度の判定基準が評価者ごとに違う、等級要件が明文化されていない、といった状態です。この場合、昇給額は目標の達成度ではなく、評価者の裁量や前年の額の延長で決まっている可能性があります。

対応は2段階に分けます。まず、評価者に判定基準を確認し、文書がなければ面談の内容を自分の記録として残します。これだけでも、翌期に基準がぶれたときの材料になります。それでも説明が得られない状態が続くなら、評価制度そのものが報酬を決めていないということです。その事実は、社内で努力の方向を変えるか、外の条件を見るかを判断する材料になります。

まとめ

• 目標設定が動かすのは昇給原資の配分だけ。情報通信業の改定率は3.9%で、原資の総額は業績と制度で先に決まる
• OKRは達成率を評価点に直結させない前提、MBOは達成度が評価になる前提。どちらの運用かを期初に確認する
• 期末にできるのは翻訳だけ。目標の数・重み付け・測り方という採点表は期初に固定される
• 数値目標は1つだけ置かず、質を担保する指標を添える。レビューや障害対応は等級要件側の記述と記録で拾う
• 評価が高いのに額が小さいときは、配分方式・評価の枠・原資の総額を順に確認する