OKRはリーダーを育成してくれる神ツールらしいひろTechメモ技術ブログです。期の始まりの時期ですね。「目標を立てて報告せよ」とうるさく言われる時期となってきました。山根の今いる現場では「OKR」という目標管理ツールを使っています。本記事では、今期の目標を決めるにあたって、改めてOKRとは何なのか、学び直してみた時の気づきについて書いていきます。実務で使ったことがある人間の目線で書いているので、参考にしていただけると嬉しいです。今回学び直しに使った本はこちら。Results「組織の成果を最大化する」ための目標管理ツール。相乗効果であり、組織~個人のレベルで目線を合わせることでこれを最大化する。「組織の目的に自分の目的を重ねる」ことで、個々人がワクワクして働けるようになる。目的に結びついていること計測可能であること容易じゃないが、達成可能な水準を見つけること重要なものに集中していること(いっぱい目標立てすぎるな)気づき以下、書籍を読んで気づきになったところにコメントしていきます。自分が印象深かった点として、「OKRの導入は、組織だけでなく、現場リーダーにとってもメリットがある」という点でした。OKRは「目的」を明確に示すことで、リーダーシップの第一歩を、仕組みとしてサポートしてくれます。OKRで設定した「目的」を発信し続けることで、メンバーは方向性を見失わなくなります。OKRが組織力を高めるOKRは、メンバーのマネジメントについて、仕組みとリズムを与えてくれます。そのため、マネジメント経験の浅いリーダーにとって非常に強力なツールになります。OKRが組織力を高める配属された現場のリーダーが率先してやるべきことは何をやって、何をやらないかをメンバーと話して決める(戦略の立案)それをメンバーと協力して実践する適切にフィードバックする1~3を繰り返すだと思うのですが、それはOKRを決めて、実行することに他なりませんね。WHYを考えないと書けないようになってる実際、リーダーとしてチームのOKRを決める側に立つと、「結局、この仕事って何でやんなきゃいけないんだっけ??」といったWHYをより深く考えるようになりました。自分の性格上、何も強制力がないと「上から降りてきた仕事をただ捌くだけ」になってしまいがちです。OKRという仕組み、考えるためのツールがあることでボトムアップ型の組織になりやすいという面はある気がしました。個人OKRは必須じゃない本書の後半では、パーソルプロセス&テクノロジー社によるOKR導入事例がインタビュー形式で語られています。その中に面白い一節がありました。エンジニア組織では、個人のOKRを設定しづらい、どうもフィットしない、ということに気づきました。エンジニア組織は、チームとして、コラボレーションの結果何を生み出すか、どんな機能を作ってリリースするのかを追っていかないといけないので、個人の役割ごとに達成度を測ってもあまり意味がなかったのです。(中略)チームのOKRはありますが、個人のOKRは設定していません。チーム全体で同じ目標を追う、という形にしています。僕は個人OKRが必須な運用しか経験したことがないため、この記述は新鮮でした。確かに、毎回思うのですが、エンジニアとしての個人OKR、設定しづらいんですよね。計測可能な目標になりづらい評価の際にチームOKRに自分がどれだけ寄与したかは測りづらい(定性的な評価になりがち)というのが率直な感想です。あるべき論として「OKRと組織の人事評価は分離して考えられているべきだ」というのを聞いたことがありますが、実際問題、しっかり分離するのは難しいような気がしています。挑戦をOKとするのが大事とある飲みの場での、上司との会話をご紹介します。個人OKR立てた後、〇〇さん(上司)にレビューしてもらいますけど、その時〇〇さんは何を見てるんですか?ん〜、その人の「視座の高さ」を見てるかな。当時は「視座って何やねん」と思ったのですが、今となってはなんとなく理解できるようになりました。ポイントは評価時に見るべきは「達成度」ではなく「成果」より良い成果を出すような行動を起こすために、「視座の高い」OKR設定が重要だと思います。自分含め、人間は「目標を設定したけど達成できませんでした」という勇気を持ちづらいので、目標設定を甘めにしてしまいがちです。挑戦的で、達成できなくても良い目標を作るその目標を追う過程で、自分の出せる成果の幅が広がっていくという状態です。OKRという枠組みの解説とは逸れるのですが、そもそも目標を立てる意味について、解説している僕の好きな動画があるので、貼っておきます。人間の「甘えちゃう」原則(=コンフォートゾーンに居ようとし続ける)について触れながら解説してくださっていてわかりやすいので、もしよければ見てみてください。まとめエンジニア目線で、「OKRって何やねん」について改めて学び直した際の、気づきについてまとめました。コミュニケーション力改善したいので「エンジニアがビジネスリーダーを目指すための10の法則」を読んだこの度「エンジニアがビジネスリーダーをめざすための10の法則」という本を読みました。「リファクタリングをしたい」となったときに、リーダーとして「これってGoサイン出していいんか...??」と迷った時の思考についてメモります。Q&Aベースで思考を深めていく形をとります。徐々に年次と経験が長くなり、「人に何かを任せて、自分は別のことをやる」と言った仕事の進め方が増えてきました。【技術書読んでる場合じゃない】エンジニア業、辛い時に泣ける本。【逝ってしまった君へ】こんにちは。ITエンジニアに限らず、仕事しているといろいろ大変なことがありますよね。今回は、山根が仕事頑張りすぎてる時に読んでリフレッシュできた本を紹介します。CAMP」の本を読みました。書籍の内容を紹介しつつ、その中で気づいたことや、現場開発で試してみたいことについてメモります。経験5年目のWebエンジニアです。SIerからの転職経験1回あり。技術とリーダー経験の両取り目指して邁進中。ひろTechメモ技術ブログです。