記事を書いた背景

スクラムでアプリ開発をしている所属チームで昨年末からOKRを運用することになり、スクラムとOKRを併用した状態で開発を行ってきました。スクラムとOKRによる恩恵は大きいと感じたものの、併用の過程でいくつかのハマりどころがあったので、今回まとめておこうと思います。概念的な話というよりも、細かい運用Tipsについて書いています。(前提としてスクラムとOKRを教科書に沿って運用している場合を想定しています）

まだ併用してから日が浅いためもっと改善できる点はあるかと思いますが、スクラムとOKRの利用をされている方や検討されている方の参考になれば幸いです。
(※この記事は個人の見解であり、所属する組織の公式見解ではありません。)

参考文献

スクラムとOKRの詳細な内容については省いています。以下が参考にしている文献になります。

スクラムガイド
SCRUM BOOT CAMP
OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法
re:Work-OKR

スクラムとOKR併用におけるつまづきポイント

今回まとめたつまづきポイントは下記の項目です。

　- イベント多すぎ問題
　- イベントをマージしようとするとコンフリクトする問題
　- スクラム運用とOKRの整合性がとれないと意味がなくなる問題

それぞれについて説明していきます。

イベント多すぎ問題

1つ目のハマりポイントは、「イベントの多すぎ問題」です。
スクラムを運用する場合、下記のようなスクラムイベントをスプリントの中で実施していくことになります。

• デイリースクラム
• スプリントプランニング
• プロダクトバックログ・リファインメント
• スプリントレビュー
• スプリントレトロスペクティブ

スプリント期間の長さの違いや、どの程度教科書に沿っているかといった違いはあるとはいえ、スクラムイベントをこなすにはそれなりの時間と労力が必要です。
スクラムの運用だけでさえも、所属チームのスクラム開始当初は、「スクラムイベントと実装時間のバランス」について振り返りで議論することが多々ありました。

OKRを実施する場合、さらに下記のようなイベントが加わります。

• チェックインミーティング
• ウィンセッション

これらもまたそれなりに時間と労力を要するイベントで、スクラムと併用する場合、全体で見るとかなりのボリュームになってしまい、作業に当てる時間が減ってしまうことがまず１つ目のハマりポイントです。

イベントをマージしようとするとコンフリクトする問題

イベントのボリュームが増えてしまうことから、似通ったイベントに関してはマージすることを検討しました
そこでハマったポイントが「イベントのコンフリクト問題」です。
スクラムとOKRには、形式や行為が似たイベントが互いに存在しますが、形式は似ていても目的や考え方が異なる場合があります。そのため、形式が似ているが故に無理にマージして実施しようとすると、本来期待する効果が得られなかったり、スクラムとOKRそれぞれの良さが消えてしまう問題(目的のコンフリクト)が発生します。

例を上げるために、スクラムとOKRのそれぞれのイベント群の内容を簡単にまとめてみます。

スクラムイベント

OKRイベント

※ OKRの４象限
OKRで利用される４つの四角形。(枠内の値は例です。)

OKR自信度

設定したO、KRと、それらの自信度を記載します。

健康・健全性

目標達成を目指す一方、疲弊したり負の遺産を残すことを防ぐために設定する。

今週の優先事項

Oを達成するために、今週フォーカスすべきタスク。

今後４週間のプロジェクト

目標達成のための中期的な計画を記述します。

コンフリクト例

コンフリクトの例として上げたいのは、　「スプリントレビュー」 vs 「ウィンセッション」　です。

この２つのイベントは、上記の表でまとめたように、互いに成果物を共有するという観点からDEMO形式で行われることが多いです。
人を集めるDEMO会を１スプリントで２度実施するのはなかなかの労力を必要とします。可能であれば1つにまとめて実施してしまいたいところです。
ただし、スプリントレビューとウィンセッションは形式は似ていますが目的が大きく異なります。

スプリントレビューは、スプリント終了時のインクリメントの検査とプロダクトバックログの適応が目的のため、
成果物(完了の定義を満たすもの)をレビューし全員で話し合います。レビューによっては、大きな議論を伴います。
一方、ウィンセッションは同じように成果物を持ち合ってDEMO形式をとることが多いですが、OKR進捗の把握・共有やチーム内モチベーション向上を目的とするため、共有する成果物は途中でも可能であり、議論は行わずに賞賛を送り合います。

レビューと議論が発生するシビアな雰囲気になりがちなスプリントレビューに対し、ウィンセッションはとにかく褒め合うことにフォーカスするリラックスした雰囲気を大切にしています。

このように、スプリントレビューとウィンセッションはDEMOという行為がある観点で形式上似ていますが、目的を考えると似て非なるものです。
そのため１つのイベントとして実施してしまうと、互いの良さが消えてしまいます。

スクラム運用とOKRの整合性がとれないと意味がなくなる問題

スクラムとOKRの併用を初めてから悩んだのが、スクラム運用とOKRの内容が連動していない場合の問題です。
スクラムで開発を行なっている場合、プロダクトバックログ、スプリントバックログに並んでいるストーリーを順に消化していきますが、１スプリントでこなすストーリー群がOKRの内容と乖離したものばかりだったり、OKRの優先事項タスクとスプリントのストーリーがそれぞれ独立した状態だとこの問題が生じます。
(その場合、そもそものOKRの設定に問題がある場合もあります。)

例えば、１スプリントで行なった作業がほとんどOKRに紐づかない場合、無理やりOKRを運用していると、

- チェックインミーティングでOKRの自信度が一向に上がらない
- ウィンセッションで勝者の気分を味わえない※

※ 「ウィンセッション」と呼ばれる所以は、
 「メンバー自身が特別な勝者のチームに属している気分になれる」
「共有できるものを作ることがチームの楽しみになり、メンバーが勝利を求めるようになる」
といった観点

といった状態に陥り、OKRの運用が逆にチームのモチベーションを落としてしまう事態につながりかねません。

また、スクラムとOKRを利用していると、下記のように運用対象が増えます。
【計画系の運用】
- (スクラム)プロダクトバックログやスプリントバックログ
- (OKR)「今週の優先事項」「今後４週間」

【改善系の運用】
- (スクラム)KPTなどの振り返り
- (OKR)「健康・健全度指標」

それぞれを運用した場合、内容に一貫性がないと１つ１つの運用の効果が薄れ、スクラムとOKRを併用する意味がなくなってしまいます。

どうやって解決したか

上述の問題に対してとったアプローチについて紹介します。問題解決のためにとったアプローチは２つありました。

　- 形式が似たイベントはくっつけ、アジェンダできっちり分ける
　- OKR４象限の更新をスクラムイベントに混ぜ込む

形式が似たイベントはくっつけて、アジェンダできっちり分ける

形式が似ていてなるべく同じ時間帯に済ましてしまいたい場合、イベントの時間帯は合わせ、アジェンダできっちり分けると良かったです。参加メンバーには各イベントの目的と違いを明確に伝え、中途半端に両イベントを混ぜずにアジェンダの区切りで雰囲気を大きく変えるようにしました。それによって、本来のイベントの目的を損なわず、効率的にイベントを実施することができます。(イベント多すぎ問題とコンフリクト問題を軽減することができます)

例: スプリントレビュー & ウィンセッション

【前半】
スプリントレビュー
(目的):
- インクリメントの検査
- プロダクトバックログの適応
(形式):
成果物のDEMOとそれに対する議論。
※成果物はストーリーの「完了の定義」を満たしているもの

【後半】
ウィンセッション
(目的):
- OKRへの進捗の把握と共有
- チーム全体のモチベーション維持
- チーム内コミュニケーションの円滑化
(形式):
成果物を発表し合って、褒め合う
※成果物は作業途中も可。目的と反するので成果物に対する議論は行わず、賞賛を送り合う。
賞賛を送り合いながらスプリントを走りきったチームを労う事ができるよう和やかな雰囲気で行う。

ウィンセッションはお菓子やジュースを持ち寄って砕けた雰囲気で実施するなど、スプリントレビューの雰囲気との切り替えを大胆にすると、イベントの切り替わりが意識されて良かったです。また、DEMO形式である点が似ているため、「スプリントレビューは完成した成果物のみ」「ウィンセッションは作業中の成果物もあり」と明文化して違いを意識しました。

OKR４象限はスクラムイベントを活用して更新

OKRの運用とスクラムイベントの運用を密にすることで互いの運用に齟齬が生まれないようにする工夫です。
それによって、上述した スプリントバックログとOKRの整合性がとれないと意味がなくなる問題の解決を目指しています。
同時に時間短縮の効果も見込めるため、イベント多すぎ問題の解決にも有効だと考えています。

OKR４項目　更新の例

OKRでは、週初めのチェックインミーティングで上述したOKRの4項目について話し合い、決定します。

4項目の目的
- OKR自信度: OKRの進捗確認と自信度の上下について議論することによる認識合わせ
- 今週の優先事項: 目標に向かって今週取り組むべき重要な仕事を決め、フォーカスする
- 今後４週間: チームへの共有とメンバーが余裕をもって準備や心構えができるようにする
- 健康・健全度: 目標達成を目指す一方で守りたいもの、失ってはいけないものを決定する

チェックインミーティングを開催して上記４項目を更新していくのが本来のOKRの手法ですが、スクラムイベントにも似た目的を果たすイベントが存在しており、スクラムイベントと併用している場合、チェックインミーティングをスクラムから独立して開催すると、同じ議論が複数回発生してしまいます。

そのため、各４項目の更新はスクラムのイベントに混ぜ込んでいます。
OKRの４項目の更新をスクラムイベントに混ぜ込んでみた例です。

今週の優先事項
スプリントプランニングで更新します。
※この場合の「今週」はスプリントの単位と同じだと仮定しています。
スプリントプランニングは、そのスプリントで何ができるかを決定し、実施するストーリーをスプリントバックログに移します。その過程でスプリントバックログに優先度を決めますが、その優先度をOKRの「今週の優先事項」に当てはめます。

今後4週間
プロダクトバックログのリファイメントで更新します。
リファインメントではプロダクトバックログの最適化とチームメンバーへの可視化を行いますが、この目的はOKRの4象限で「今後4週間」の項目を記入する意図とほぼ同じだと考えています。
そのため、プロダクトバックログのリファインメント時にこの項目を更新すると効率的です。

健康・健全性
振り返り(KPT等)で更新します。
OKRにおける「健康・健全性」は、目標達成を目指す一方で守りたいもの、失ってはいけないものを決定し、それが正常な状態に保てているかを可視化する意味合いで用いられています。チームとして守りたいもの、失ってはいけないものについては、振り返りの際に議論をすることで次スプリントの改善に繋がります。加えて、OKRで可視化しておくことによって、振り返りの際に議論のきっかけがつかみやすくなります。

OKR自信度
この項目についてはどのスクラムイベントのタイミングに入れるべきか判断できていません。
ただ、スクラムのスプリントプランニングで利用される手法「プランニングポーカー」のスタイルを利用すると円滑に進む感触をもっています。
(自信度ポーカーと勝手に呼んでます。)

(自信度ポーカー)
各KRについて下記を行う
1. KRについて自信度が10段階で表すといくつかを各々が考える
2. 同時にそれぞれが考えた数字を提示する
3. 数字のばらつきやなぜその数字になったのかを話し合う
4. 話し合いをもとに、最終的なチームの自信度を決定

※見積もりではないため、プランニングポーカーのようにフィボナッチ数になってる必要はなし

まとめ

スクラムとOKRを併用していてハマった落とし穴とそれに対する改善案として試みた方法についてまとめました。

スクラムとOKR併用によってつまづく問題
　- イベントが多発し実装時間が減ってしまう
　- 無理にイベントをマージして実施しようとすると互いの目的を損なってしまう
　- スクラムの運用とOKRの内容がズレるとOKRの効果がなくなってしまう

解決策
　- 形式が似たイベントはくっつけてアジェンダできっちり分け、違い(目的)を明確化する
　- OKR４象限の更新をスクラムイベントに混ぜ込む

スクラムやOKRを運用する事が目的ではないことは注意しなければいけませんが、スクラムやOKRを導入するのであれば、両フレームワークの恩恵を正しく得られるよう試行錯誤することは重要だと思っています。まだまだ試行錯誤中なのでツッコミどころ満載かとは思いますが、より良い運用を目指して改善していきたいです。
もっと良い改善ポイントや指摘事項等ありましたら、コメントいただけると幸いです。