note株式会社で導入しているOKRとデイリースクラムについて、エンジニアの私個人の目線で振り返ります。
※ この記事は note株式会社 Advent Calendar 2022 の2日目です。
※ note株式会社の1チームでの振り返りになります。
OKRの説明はしないため、先に以下を読むと幸せに慣れます。
背景
- 7月にnote株式会社に転職。すでにOKRが導入されていた
- 初OKRで学びが多かったので、同時に実施していたデイリースクラムについても振り返る
- OKRは1回目は大体成功しないので、2回目以降に成功する確率を上げるための布石
書かないこと
- note株式会社でOKRを導入した経緯
- OKRの詳細すぎる説明
- OKR以外のフレームワークとの比較検討
私の所属するチームについて
読者の方にもイメージしていただけるよう、必要そうな情報をまとめていきます
チーム構成
人数は期間中の最大数です。
| ポジション | 人数 |
|---|---|
| PdM | 1 |
| デザイナー | 2 |
| エンジニア | 2 |
| ディレクター | 4 |
※ ここでのディレクターは編集者/コンテンツ管理者のような役割です
https://note.jp/n/ncb0be80c6d18
1週間のスケジュール
OKRの1週間をベースに、最終的には以下のスケジュールでした。
デイリースクラム: 毎日朝
チームメンバー1人ずつ報告するのではなく、各KRごとにタスクの担当者が進捗を共有する形を取りました。
KRごとに進捗が共有されるため、他職種の人のタスクについても理解しやすい（目標に進んでいる）実感がありました。
Win Session: 金曜午後①
1週間の成果（win）を共有し、学び(learn)を分かち合い、次週に何をすべきか（try）をチームで30分ほど話し合うMTGです。
OKRとは無関係な内容でも問題ないフォーマットにしており、チームメンバーの相互理解に特に貢献していたと思います。
Checkin MTG: 金曜午後②
OKRの達成自信度の更新と、来週の優先事項（OKR達成に必要な仕事）を考えるMTGです。
毎週月曜日に行うことが推奨されているCheckin MTG を Win Sessionの後に実施しました。
土日の間にWin Sessionの内容を忘れてしまう問題と、金曜午後にMTGを集中させたいチームメンバーの総意から金曜となりました。
Planning: 金曜午後③
Checkin MTGで決定した優先事項をもとに、スケジュールの引き直しやタスクの振り分けを行うMTGです。
KRごとに実施しており、詳細な相談事もこのMTGで行われます。
Checkin MTGと同様の理由で金曜となっています。
その他: 適宜
上記MTG以外でも必要に応じてMTGを設定します。
数分で終わるものはデイリースクラムで、時間のかかるものはメンバーの空いている時間で、と個々人の感覚頼りです。
終盤はSlackでのチャットで完結することが多く、週に30分のMTGが1~3本程でした。
利用ソフトウェア
OKRとデイリースクラムで使用していたソフトウェアを紹介します。
メンバーの個々の業務で使用するソフトウェアは紹介しきれないので割愛します。
miro
Win Session ~ Checkin MTG で使用
1枚のボードに毎週追記していく方法で、いつでも振り返られるようにしていました。
GitHub/ZenHub
Planning, デイリースクラム で使用
KRごとにEpicを作成し、Issueを紐づける形で管理しました。
GitHubの利用が初めてのメンバーもいたため、複雑な機能は使用していません。
Slack/Zoom
全てのMTGで使用
使い分けは以下の通り
- 非同期にチャットで解決する内容 => Slack
- 非同期で仕様に関わる内容 => GitHub Issue
- 同期で話さないと時間がかかる or 関わるメンバーが多い内容 => Zoom
その他
- 議事録 => Google Docs
- 優先度管理（ICEスコア）など => Google Sheets
- リマインダーなど => zapier
約半年間を振り返り
メリット
- 週ごとに優先事項があり、優先度の低い割り込みタスクを断りやすい
- 目標をチーム内で共有するため、異種混合チームでも意気投合できる
- それぞれの得意分野で分担できるため、タスクの進みが早い
- 他職種へのリスペクトが生まれる
デメリット
- 金曜日の半日がMTGで潰れる
- Issueに詳細を書く文化の定着が必要
- ほぼObjective（目標）は1回目では達成できない
補足
OKRにおいてObjective（目標）にはストレッチゴールを設定するため、初回のOKRでは達成できないことが多いです。
実際に今回はチーム初回のOKRで、Objective（目標）は達成できませんでした。
しかしながら、メンバー/チーム/会社としても達成できないのを理解して取り組んでおり、士気には影響のないデメリットだったと思います。
もしOKRを導入する場合は1回目は失敗しやすいことと、その上で必死に取り組むことができるチーム体制にすべきです。
そして2回目以降のOKRを改善していき、ストレッチゴールを達成できるチームになることが大事だと思います。
褒めることの重要さ
エンジニアのチームでは日常的に個人のスキルを褒めることや、強みを教え合うことは（私の経験上）あまりないです。
今回OKRに取り組む中で、ディレクターが各ポジションの強みを褒めてくださり、強みを活かしてタスクに取り組むきっかけとなりました。
Win Sessionにもありますが、1週間で達成したことをメンバー間で祝福し、メンバーの強みを褒めて活かせるチームであるべきだと思いました。
OKRというフレームワークに注目しがちですが、「褒めること」を大事にすべきです。
振り返りまとめ
OKRはKPI/KGIよりもわくわくする目標を持つことで、モチベーションを維持できる（将来のプロダクトの形を想像しながら仕事ができる）良いフレームだと感じました。
またOKRを導入することで、タスクの優先度について認識合わせをしやすい環境と、1週間ごとにタスクを切ることでアジャイルのような開発環境が自然として構築されました。
次回に向けて
チームメンバーは入れ替えとなりますが、今回の振り返りから以下を導入しようと思います。
OKRに対して
Win-Sessionの褒めるアクションの強化
モチベーションの維持としても心理的安全性としても、褒めることを強化することは非常に有効だと思います。
例:
- 達成したことに褒めスタンプをつける
- Win-Session中にお菓子を持ち込んでのパーティー（OKRの本にも記載されている）
- Win-Session用に経費でお菓子代を出す
GitHub/ZenHubの利用サポート
異種混合チームでもしGitHubに疎い方がいれば、ぜひサポートして利用方法を教えようと思います。
殆どの場合、Gitの機能ではなくGitHubのIssueに関する機能のみのため、画面共有をしつつ懇切丁寧に教えられると問題ないはずです。
デイリースクラムに対して
タイムキーパーを用意、もしくはルールの周知をします。
相談事が始まった場合に、複雑な問題の議論が始まると無関係な人の時間まで奪ってしまいます。
1KRもしくは1人あたり5分が目安だと思います。
最後に
OKRは非常に優れたフレームワークだと感じました。
エンジニアが開発に集中できる環境ができるだけでなく、エンジニア自身の強みを理解することにも役立ちます。
一方で失敗に対してネガティブな思考を持つ可能性もあるため、士気を保つためにも褒めること、ワクワクすることにフォーカスを当てて実施すると良いと思います。
note株式会社では広い職種を積極採用中です。note株式会社の１チームで様々な職種の方とOKRに取り組みたい方、ご興味がある方は以下リンクよりご確認ください
▼note株式会社 募集職種一覧はこちら
https://note.jp/n/nc0fe1a230633
▼noteエンジニアアドベントカレンダーはこちら
▼noteの技術記事が読みたい方はこちら