挑戦する目標を促さないマネージャはシステムエンジニアの方から見切れ

on


今日も最初に言いたいことを書いておきます。

  • 挑戦する目標を促さないマネージャは見切れ
  • 挑戦する目標は＋αの加点
  • 評価が期待値以上になる目標を作り込む


少し前に飲んだ帰りの電車の方向が一緒だった、しーいーおーという偉いおじさんがこんな話をふってきたんですよ。

「ある事業が旧態依然としているので技術のキャッチアップをするように言っているんだけど、やらないんだよ」


しーいーおーなのにそれでいいの、って内心思いましたが。その話の流れで、ワタシは必ず目標管理の目標に挑戦する項目を入れさせるけれど、その事業全員に同じようにさせればいいのでは、とつい軽い気持ちでリターンを返してしまったあと、「やっちゃったかな」と思ったけど、さて。


挑戦する目標を促さないマネージャは見切れ
ビジネスは拡大が大前提です。サンセットするようなビジネスプランなんて作らないです。業務が拡大するから人が少ない、拡大しているのに補充されないから慢性的に人員不足と現場が言うわけですから。


その観点だけでも、拡大するビジネスのところを切り出せば、そこは定常の業務からはみ出している領域なので何かしら挑戦する領域なわけです。そうした下地があるのにメンバに挑戦させないということはビジネスを拡大する気がないのか、メンバに期待していないということの表れです。


そんなマネージャは見切ったほうがいいです。


挑戦する目標は＋αの加点
ビジネスが拡大するなら、それに見合った目標は、組織にも、個人にも必要なのです。組織は定量的な目標になりますし、個人も定量的な目標に極力するように推奨しますが、上手にブレンドできるならマネージャ自身もメンバに定性的な目標を組み合わせさせて設定させることが実は運営がしやすかったりします。


運営のしやすさとは、挑戦するような目標は、定性的な書きっぷりで合意しておき、チャレンジすること自体を評価する項目として設定するんです。定常的な目標はできたかできなかったかのゼロイチなので客観的に評価しやすいし、そうすればいいですがチャレンジのような挑戦する目標は個人の業務をエンハンスすることが目的なので定性的にしておくほうが良いのです。


という前提に立てば、チャレンジしたことに意味があり、したかどうか、が評価の対象になります。


評価が期待値以上になる目標を作り込む
定常的な業務は定常的な役割における期待と成果ですから、ドラマチックな結果と成果は得にくいものです。あるのは期待に応えられずデスマをしてしまうとかのマイナスの方向は大きく振れることがあるかもしれませんが、プラスに振れる幅は少ないものです。


そこで、挑戦する目標が必要になるのです。挑戦する目標を入れておき、挑戦したよ、結果もあるよと言える余地を作っておくのが良いわけです。


良いのは、システムエンジニアの目線で言えば、２つあります。一つはこれまでの流れのように評価をプラスに伸ばすことのエビデンスとして。もう１つは将来の自分のために。挑戦する目標を実行することで将来の自分の選択肢を広げられる伏線を仕込むことができるから。


それを業務の一環で、つまり仕事で仕込んで置けるのは持ち出すことすがないということなのでエコなわけです。


なので、挑戦する目標を持とう、それをやって認めさせて少しでも多く給与をもらおう、というわけです。同じ仕事ばかりやっていると給与は相対的に下がる一方ですよ。