見出し画像

【OKR】コードベリーOKR運用報告〜9ヶ月経過〜

コードベリー牧野です。

コードベリーではOKRをベースとしたエンジニア育成の仕組みを本年度2月から運用しています。
運用3ヶ月目ではこちらの記事でコードベリーの従業員サポート制度を紹介しましたが、今回はOKRをベースとしたエンジニア育成の仕組み(以下、コードベリーOKR)に絞り、共有します。

はじめに

ここではコードベリーOKRについて、現在運用中の姿とその姿に至った経緯を記載します。
エンジニア育成に困っている方々の参考になれば幸いです。

また、エンジニア育成に関する知見共有や意見交換も積極的に行っていきたいので、ご興味湧いた方はお気軽にお問い合わせください。
コーポレートサイトからでも、TwitterのDMからでも構いません。

・コーポレートサイト
https://codeberry.co.jp/

・代表福田のTwitter
https://twitter.com/yoshima_fukuda

・僕のTwitter
https://twitter.com/yasumasa_makino

ここで言いたいこと

エンジニア育成でもうまくフィットできればOKRの考え方は有効のようです。
さらなる改善で、エンジニアの成長に寄与していきます。

現在の全体像

運用体制

現在、以下の体制でコードベリーOKRを運営しています。
エンジニア育成が主目的ですので、メンターはコードベリーで技術責任を負うCTO千葉と代表の福田が務めています。
各メンターに数人の実施者(メンバー)が紐づき、OKRの進捗やアドバイスをやり取りしています。
上記の通り実務はメンターとメンバーで実施し、設計運営は僕が全体を見る形で都度課題を吸い上げ、打ち手を検討実施しています。
なお、課題吸い上げには、

・役員の定例MTGでメンターからヒアリング
・後述するTermごとの実施振り返りMTGでのヒアリングとその後のアンケート取得

で対応しています。今のところ、改善点は拾えている感覚。

202010_OKR体制

大事にしているところ

下記2点です。

・成長実感を得られる
・できるだけ大きな声援、支援

自分で進んでいく気持ちと、周りから背中を押される環境を作って良い循環を生みたいと思っています。

エンジニアのスキルは極めて抽象的ですので、成長をサポートする上で、できるだけ目に見える形にしていくことが大事だと考えます。

全体の流れ

コードベリーでは現在以下の流れでコードベリーOKRを運用しています。
エンジニアのスキルは極めて定性的で広義なので、そこに定量評価のOKRがフィットするようにチャレンジしているところです。

1. 1年後のToBeを決める(定性)
2. Objectiveを決める(定性)
3. KeyResultを決める(定量)

4. 週次の目標を決める(定量)
5. 週次で1 on 1(定量)
6. 月次で成果確認および共有(定量)

7. 振り返る(定性&定量)
8. 公開スキルシートの更新(定性)

ではそれぞれ簡単に説明していきます。

1. 1年後のToBeを決める(定性)

コードベリーOKRをスタートするときです。

現在のOKR実施者は経験浅の子が多いので、1年後に「一人前のエンジニアになる」という定性的な目標を立てます。これは現在のところ、みなこの同じ目標を設定しており、コードベリー内で定義した「一人前」を目指します。
※ベテランについては実施対象者がまだおらず、今後の検討課題です。

2. Objectiveを決める(定性)

ToBeを決めるときに半年後ぐらいまでを仮決めしておき、3ヶ月ごとに見直して決定しています。

一人前になるべく、設計・実装・テストといったコードベリー内で定義した一人前のスキルが習得できるように3ヶ月後の目標を定性で立てます。この3ヶ月をコードベリーではTermと呼んでいます。

・Term1〜2

最初の半年くらいはコードベリー共通の実装課題完了や知識習得で基礎の基礎固めを目指します。実施者によって異なるところなので、メンターが見極めをサポートし実施者本人の意思で目標設定します。
例えば、

「BEの基礎を固める」

「FE課題を完了させる」

という感じに。

・Term3〜4

1年の後半は自分が作りたいWebアプリケーションを検討し、目標として掲げるのが今のところのパターンです。より実務に近い内容で基礎から一歩ステップアップですね。
こちらも、メンターがサポートして一定ストレッチしたObjectiveを実施者本人の意思で設定します。
例えば、

「サッカー情報を記録するアプリ設計」

「TODOアプリ実装」

という感じに。

3. KeyResultを決める(定量)

Objectiveを達成するためのKeyResultを決めます。Objective決定後に実施します。
通常2つ、多くても3つです。

Term1〜2の基礎固めであれば、例えば

「エラー処理とJUnitテストの実装 カバレッジ90%以上」

「オブジェクト指向に関連する書籍(CTO含め相談し確定)を読破、理解し、帰社日で説明できる。感想ではない。3冊読む、1ヶ月に1冊。」

という感じ。

Term3〜4であれば、例えば

「サッカー関連アプリ設計」

「APIがとりあえず動くまで実装 CRUDの4本」

といった感じ。

工夫した点はこちら。

週3回以上GitHubへのPush
実装がメインのKeyResultの場合は、「週3回以上Push」を原則含めることにした点です。
忙しくなると課題に手を付けなくなりそのままになってしまうことを防ぐため、とにかく少しでもプログラムに触ってもらうのが狙いです。

4. 週次の目標を決める(定量)

Termの目標を達成するために週次の定量的な目標を決めます。
書籍であれば週○ページ、実装であれば何%進捗させるかですね。
ObjectiveとKeyResultが決定したらTerm分のすべてを決めます。

難しかったのは、課題実装をどう定量的にモニタリングするかだったのですが、運用負荷を減らすためにメンターの定性的な評価としています。プログラムのステップ数をカウントする、や要件の数をカウントする、など考えましたが、綿密な要件定義と設計が必要になりメンター・実施者双方の負荷が高すぎると判断し、やめました。

コードベリーOKRではObjective達成までのKeyResultモニタリングを以下のようにスプレッドシートで行っています。

この例は課題実装のモニタリングですので、予実は進捗度です。
例えばAPI5本実装が課題だったとすると、全量を500%と置き、進捗度を積み重ねていって500%に到達すれば達成ということになります。

スクリーンショット 2020-10-13 7.03.14

それをこのようにグラフ化しています。
スプレッドシート管理にしたことで、全体進捗のモニタリングも容易です。
※下記は6本のAPIを実装予定なので600%が目標達成ラインになっています。

スクリーンショット 2020-10-13 7.07.03

そして、複数のKeyResultをグラフし集約することで全体感がつかめるようになっています。

スクリーンショット 2020-10-13 9.09.01

これらはもちろん全社公開しており、slackでは定期的に進捗状況の周知を行っています。

5. 週次で1 on 1(定性、定量)

目標を決めたらあとは運用のフェーズですね。
週に1回、現在はオンラインで1 on 1を実施して進捗状況の確認や困りごとの解消を行っています。

進捗状況を確認し、前述したスプレッドシートに進捗状況を記入しています。

6. 月次で成果確認および共有(定量)

月の初めに1ヶ月の進捗状況を1点満点で算出しています。0.2とか0.3とかですね。もちろんこちらも全社公開しています。
Term終了時点で0.7以上になっているとObjectiveを見事達成ということになります。

また、月に一度全社MTGがありますが、そのアジェンダの中にKeyResult達成者表彰というコーナーを設けています。
KeyResultを達成した人、それから達成に等しいような際立った成果を上げた人を全社表彰しています。
直近だと、コードベリーOKRの中でJavaの資格を取得した子がいまして、みんなで祝福しました。

7. 振り返る(定性、定量)

Term終了時点で、実施者と役員で集まり振り返りMTGを実施しています。
実施目的とアジェンダは以下です。

■目的
会社のVMVを心に留める
OKRが楽しくなること

■アジェンダ
・下記内容で振返りをし(本人発言5分)、出席者からのFB(意見質問5分) (最大70分)
 ①Objective達成度(担当メンターより)と「一人前のエンジニアに近づけたか」を軸に自己評価
 ②達成するために気をつけたこと
 ③次のTermで取り組みたいことをできるだけ具体的に
 ④エンジニアの価値向上にどれぐらい貢献できたと思う?

・その他OKRについての感想、意見(あれば)
 ※言いづらいことであればFBアンケートでもOK

また、振り返りMTGのあとにアンケート形式で振り返りMTGに関するフィードバックを実施者からもらうようにしています。
MTGでは言いづらいことも書いてくれるので、振り返りMTGに関する課題解消という点で見ると非常に効果的だなと思っています。
※アンケートの回答内容は後ほど

実施目的について
せっかく組織にいるので、組織と同じ方向を向いて成長していってほしいという思いがあります。
僕自身がそうでしたが、自分のために頑張るのって息切れしやすいんですよね。自分以外のために頑張ると馬力ってでるんです。
社畜になってほしいということではなく、同じ思いを共有してそれを原動力に頑張ってほしいのでこのように目的を設定しています。

ちなみに、コードベリーOKRは任意です。好きなときにやめることができます。暗黙のプレッシャーで実質必須にならないよう気を付ける必要がありますが、コードベリーに評価制度はないので、雰囲気作りと合わせて常に実施者に伝えています。

振り返ること
次の取り組みに向けて、ということももちろんなのですが、今後自己学習していく上で振り返りを癖にしていってほしいという思いです。
日々の業務で忙しいと忘れがちになりますからね。

また、実施者の振り返りを聞くことで運営側の課題もかなり出てきます。
問題や課題が出てきたらその場でどこに原因があるかを切り分けて、実施者なり運営側で「次はこうしよう」ということができるので、とても効果的です。

第三者からのフィードバック
実施者が話したあと、参加者から自由にフィードバックしてもらっています。ポジティブなことがほとんどです。
自分が全然気にしてなかったことや短所だと思っていたことが、他の人にとってはうれしいことだったりして、フィードバックされる側は自信を得ることが多いようですね。
この第三者フィードバックは、本人が気付いていない能力や良さを知らせる方法として、非常に効果的だと感じています。

※後述のアンケート回答も併せて読んでみてください。

8. 公開スキルシートの更新(定性)

コードベリーではスキル見える化の取り組みとして、各自のスキルシートを全社公開しています。

Objectiveに挑んだ結果として習得できたスキルを公開スキルシートに追記します。Termが終わったタイミングでの更新です。
出来ることが増えたということを実感してもらうためです。
繰り返しになりますが、エンジニアのスキルは極めて抽象的なものですから、可能な限り可視化していくことが大事だと考えています。

参考:振り返りMTGに関するアンケート回答の公開

下記、参考に振り返りMTGに関するアンケート回答を公開します。4月と7月に振り返りMTGを行っているのでそれぞれ公開します。

2020/04実施アンケート「参加してよかったと感じたこと」の回答

課題をやっているのは自分だけじゃなく、みんなそれぞれ頑張ってるんだなというのを目にする事で学習の励みになるなと思いました。
今は特にリモートで社員の方と接する機会が少ないのもあって、技術的な部分や会社の理念的なところの認識のすり合わせができたのも良かったです。
他のメンバーの学んだことや改善点、良かった点を具体的に知ることができたこと、それを踏まえて、自分自身のやる気につながったこと。
他の人の状況だったり、考え方などを知れた。
OKRの進捗があまり良くなかったので、他の人の話を聞いたことによりもう少し頑張ろうと刺激をもらえた。
また、自分の仕事に対しての想いを忘れかけていたので他の人の話を聞いて改めて思い出せた。
少しなりとも成長できたと実感できたこと(現場で生かすことができた)
他のメンバーの取り組み状況が知れて、モチベーションに繋がった。

2020/04実施アンケート「改善したほうがよいと感じたこと」の回答

OKRは自発的なものという考え方の中で、いかに出来なかったことよりも出来た事に焦点を当てて、プレッシャーを取り除くかが大事だと思いました。
(例えば感想の項目で、"うまく行かなかったことと改善点"ではなく、"今回のポイントまで達成するために気をつけた事と次に取り掛かりたいこと"に変えるなど)
もうちょっと意見ををバンバン出し合える雰囲気があればいいなと思いました。(抽象的ですみません)
モチベーション大事だと思うのでMTGの時に出たグループ化の他に具体的な案はありませんがモチベーション向上に繋がるようなことがあればいいのかなと感じました。
OKRに関して話す内容が進捗メインになっていた気がしたので、次はどう楽しみながら取り組んでるか聞きたい。

2020/04実施】アンケート「こんなことをやりたいと感じたこと(あれば)」の回答

(メンターなしの)OKRのメンバーのみで月1位で意見交換の場があってもいいかなと思いました。

2020/07実施アンケート「参加してよかったと感じたこと」の回答

他のメンバーの次のtermに行う内容を参考に自身のOKRの反省ができたこと。
全体としてのフィードバックがあることでOKRをやっているという実感が持てるのが良いと思った
みんなの自己評価やエンジニアの価値向上にどれぐらい貢献できたかを聞けて良かった。エンジニアの価値がいまいちわかっていなかったが、他者からの評価で具体例を出してくれたりしたのでわかりやすかった。
自分ではそんなに大したことをしたように感じていなくても客観的な意見をもらえたのでモチベーションが上がってよかった
OKRの取り組みだけでなく、普段の業務へどれだけ活かされているか知れたので良かった。
・みんなが取り組んでいることがわかるのが良いと感じました。
・個人目標を達成するための進め方やツール、考えていることの共有ができること
・自分のやってきたことを振り返れること

2020/07実施アンケート「改善したほうがよいと感じたこと」の回答

Sくんは初めてだったので振り返りはなくてよかったのではないかと思いました。(参考に見るための参加でよかったと思います。)
全体としてのフィードバックがあることでOKRをやっているという実感が持てるのが良いと思った
自分自身もそうだが、もう少し皆で質問したほうがより良いのかなと思った。(Sさんが主に質問していたから)
牧野さんたちからの質問も1つ2つあったほうが「あ、たしかに。それ聞きたいかも」って私たちもなるのかな、と思った。

2020/07実施】アンケート「こんなことをやりたいと感じたこと(あれば)」の回答

なし

これまで対応した課題

前回の運用開始3ヶ月後振り返りから対応した課題について書きます。

進捗状況の可視化

既出ですが、スプレッドシートで週次の進捗状況をモニタリングすることにしました。

対応した課題ですが、実施者から振り返りMTGの中で「自分の対応している課題がどこに向かっているか分からなくなる時があり、モチベーション維持に苦労した」という声がありました。
運営としては「全体像の不明瞭」を課題としておき、この施策を実施しました。

これにより、目標に対する実施者の状態が可視化されたので、本人のモチベーションアップと、モニタリング側の認識がクリアになるところに繋がりました。

運営側からの全社アプローチ

これは僕自身の反省からなのですが、「OKRに全社を巻き込む感」が足りないと感じ、この施策を実施しました。

具体的には、週次で全社に向けモニタリング用スプレッドシートの参照をお願いするという取り組みです。
個人を取り上げて全社周知するとプレッシャーになりそうですので、背中を押してくれるぐらいの程よいプレッシャーが掛かるような手がベスト。
ここはまだまだ模索中です。先週から運用を始めたので改善していきたいところです。

会社のみんなから応援されるってやっぱり嬉しいことだと思うんですよね。それが成長へのモチベーションに繋がると思うんです。
これまで全社MTGでの表彰などはしていましたが、役員以外のベテラン社員の絡みが不足しているように感じていたので、もっと全社員を巻き込みたいなという思いがあり実施することにしました。

メンバー間でのコミュニケーション活性化

はじめに言いますと、運営側の施策は効果ありませんでした。失敗ですね。
4月の振り返りMTGで実施者同士のコミュニケーションが少ないという課題がでまして「実施者のペアを作る」ということをしたのですが、結果的にうまく機能しませんでした。

一方で、実施者の一人からこのようなアンケート回答があり、隔週で1時間のよもやまを設定してあげることにしました。

(メンターなしの)OKRのメンバーのみで月1位で意見交換の場があってもいいかなと思いました。

すると、今ではそこで活発なコミュニケーションが生まれているようです。
運営の牧野や役員は出席せず、実施者だけでざっくばらんに話をする場になっていて、モチベーション維持に機能しているようです。
また、ファシリテーションの練習の場となっているようなので、様々な副次的な効果がありそうです。

この施策については、実施者から自発的な意見として上がってきて実現しているので、非常にうれしい誤算となりました。

今後の予定

僕自身としては、これら行っていきたいと思っています。

・運用側の全社の巻き込みをもっとしていきたい
・メンターに対する実施者のフィードバック運用

今月末に振り返りMTGを実施しますので、そこで出る課題も楽しみに待ちたいと思います。

さいごに

冒頭に書いたとおり、エンジニアの育成にOKRは有効そうだという感想です。可能なレベルまで定量化を行い見える化することがポイントかなと思っています。

これからも改善を繰り返して確固たる育成制度に仕上げていきたいです。

また話題が溜まったら共有させて頂きます!


どなたかの参考になれば幸いです。
最後までお読み頂きありがとうございました。

この記事が気に入ったらサポートをしてみませんか?