OKRと目標管理に実装されていなければならないこと

組織によってはあとひと月ちょっとで年度末を迎えるところもあるだろうし、多くは来年3月が年度末のところが多いのでしょう。だいぶ、web系の会社も増えたり、再編があったりすると決算月がいわゆる年度末の3月ではない組織が増えているような気がしますが。

年度末といえば、業績評定です。まあまあ、そんな嫌な顔をしないで。この1年何をやってきたか、自分と向き合うには良いじゃないですか。

 業績評定をするには元となる目標設定が必要で、評定をするためには元の目標設定の大切さについてはこれまでなんどかエントリを書いています。

ここのところ、グーグルのOKR(Objective and Key Result 目標と主な結果)というキーワードを見かけるようになったのですが、それに当たる記事を読んでみてもよくわからないのですよ。

目標管理での目標設定

過去のエントリで書いてるのですが、目標をどう設定するかでその年の目標設定で達成したいコトがほぼ決まってしまうのです。

どういうことかというと、曖昧な目標設定をするとエンジニアに限らず人は自分に甘いので結果的に目標を達成しないというものです。

ですから、目標管理での目標は、

  • 定量的な目標を
  • 具体的に達成したイメージを持って

設定できるかどうかにかかっていると言い切っても問題はありません。ただ、ほぼ8割方のエンジニアは定量的で達成したときのイメージを目標設定することができないのが実態です。

目標管理でのKPI

 一般的に目標管理のエンジニアレベルの目標を上に辿っていけば、組織の年度の事業計画のKPIに遡れるはずです。いや、遡れなければおかしいです。

なぜなら、組織の事業計画を達成するのが組織に属するエンジニアだからです。そのエンジニアの1年の活動が組織のKPIに結びついていないならエンジニアの活動は評価されないというのと同じです。組織の評価をKPIでするのですから。

そうした考え方を踏まえるなら、エンジニアの目標設定はKPIの一部分を担う定量的な目標になっていなければ辻褄が合いません。

そうした背景もあって、エンジニアの目標管理の目標は、定量的である必要があるし、目標達成時のイメージが具体的である必要がるのです。まあ、後者については、エンジニアが年度の初めで1年後に実際にどうなっているかは別にして、到達したいイメージを作っておかないと最初の一歩が踏み出せないという事情もあるのですが。

 

OKR

ところでOKRですが、

 

企業のチームメンバーそれぞれの目標と期待されている結果を明確にし、組織のオペレーションとコミュニケーションを効率化するためのシステム

引用 

KPIはもう古い! Googleも採用する『OKR』が目標達成に効く理由。 | コラム

 

だそうです。考え方は良いですよね。期待を明確にして、オペとコミュを効率化しよう、ですから。

 

目標自体は、エンジニア一人ひとりに設定するものです。一人ひとりのエンジニアの活動結果が集約して組織の事業計画の達成につながるので。

 

さて、目標を設定するときに、目標は組織の期待だけなのか。いいえ、違いますよね。これも過去のエントリに何度か書いてきましたが、組織の期待とエンジニアの希望のすり合わせの結果の合意がエンジニア一個人の目標にならなければおかしいです。

一方的な期待では、主体性が欠如するので。

引用の中で、

 

ひとつの目標を階層ごとに細分化、数値化し続けていくことで、チーム内で「何をすべきか、目標は何のためにあるのか」がわかりやすくなります。

 

とあります。あれ、上述してきた目標管理の目標設定と同じですね。わざわざOKRと言い換える必要があるのかしら。

ただ、こういう言い方は良いなと思います。

 

しかしたいていの場合、このような目標設定の仕方ではうまく行かない場合が多いもの。なぜならば「結局どうしたいのか」というビジョンをつい忘れがちになってしまうからです。

 

達成したい目標の達成時のイメージを持っていないと目の前の数字を達成することが目的となってしまうのというところ。よく言われる、目的と手段が擦り変わるというやつですね。

目標を個人に活かす

 結局、組織としてはリソースたるエンジニアに事業計画の達成を担って欲しいのです。それだけ。指揮命令して間違いないくオペレーションする必要のある業務もあるのでしょうが、エンジニア個人の属人的な知識に頼っているシステム開発では、それでうまくいくなら良いけれど、実際はそうならないのは考え、行動するエンジニアに依存しているからです。

だから建前上は、主体的に活動して欲しいわけです。でも強制しても期待する結果は得られないから、エンジニアが気持ちよく働けるように落とし所を模索しているのです。

 

エンジニアも、組織がそうしようとしていることは見え見えなので、上手に乗ったふりをして、やりたいこと、試してみたいことがあるなら事業計画を担っているように見せかけて目標を設定すれば良いのです。

大体は、儲かる目標になっていれば文句はつきませんから。

 

そこで必要になるのは、エンジニア自身がこれから1年何をしたいか、どうなっていたいかと事業計画のKPIが落ちてきたときの紐付けと貢献の表現力です。

でもね、儲かるなら(コンプラは当然として)嘘はないわけです。単に、手段まで言っていなかっただけの話です。

だって、目標を達成できれば評価されるのであって、手段を評価するのはお門違いです。それこそ、目的と手段が入れ替わってしまうのですから。

 

 

 

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

 
How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント