OKRとスクラムの併用マネジメントについて
こんにちは。お金のマッチングプラットフォーム"お金の健康診断"を提供する（株）400Fで代表をしている中村仁です。
組織マネジメントは会社経営における永遠の課題であります。今回は400Fのスタイルについてまとめています。
株式会社400Fはお金に悩んでいるユーザーとお金の専門家をマッチングするサービスを展開しています。そのため、ユーザーとプランナー（専門家）を繋ぐリボン型のビジネスをやっています。
このお金の健康診断ですが2018年11月にサービスリリースをしており、色々とありましたが、2020年9月末時点では1年前と比較してC側もB側も主要KPIがそれぞれ10Xしているというそれなりのグロースを達成してきました。
この成長を実現する中で、個々の能力が優れているというありがたい気持ちがいっぱいですが、加えてその能力を最大限に発揮するために活用してきたマネジメントフレームワークがOKRとスクラムでした。
今回、このOKRとスクラムの併用マネジメントをこの上半期徹底的にやってきた中で感じたメリットと改善点、そして下半期に僕たちがチャレンジする手法について解説していきたいと思います。
OKRについて
OKRは目標の設定・管理方法の一つで、Objectives and Key Results（目標と主要な結果）の略称です。OKRは他の目標管理手法などと比較して高頻度での設定、追跡、再評価ができると言われています。OKRについての詳しい内容はこちらの本がお勧めです。（僕は社員全員分を購入して配布しています）
OKRのOとKRはそれぞれ以下のような条件で設定します。
Objective (目標)
- 定性的な目標であること
- 組織全体の意識を高め社員全員がワクワクするような高い目標であること
- 簡単すぎる目標は避け、全社をあげて取り組んだ結果、達成度が60～70%程となること
- 1カ月～四半期で達成できる目標であること
Key Results（目標達成ための主要な成果）
- 定量的な（数字で測ることができる）指標であること
- 1つのObjectiveに対し、2～5個程度のKey Resultsを設定すること
- 「ベストをつくせば達成できる」くらいの負荷がかかる、達成可能性50％程度の難易度の目標であること
400Fでは四半期ごとにOKRを設定して、週初に各チーム/全社チェックインミーティングを行い、必要に応じて各チームがウィンセッションを行うということをやっていました（全社ウィンセッションを行っていない理由は後述）。
各チームのOKR設定ですが、上半期だけでも色々とあり、4-6月期は本格的なOKR導入期だったためマネジメントサイドでOKRを設定しましたが、それによって現場とのズレや納得度の薄さがチームごとにばらつきが出てしまいました。そのため、7-9月期のOKRは各チームでしっかりと議論を行い（1日のオフィス合宿）設定しました。OKR運営は以下のシートを毎週各チームごとに更新していました。
400Fは、2Cのエンジニアチーム、2Bのエンジニアチーム、ビジネスディベロップメント（BizDev）、マーケティング、コーポレートに分かれていたため、それぞれのチームが毎週月曜日にこのシートを更新して、月曜日の夕方に全社でチェックインミーティングを行っていました。
一方で、OKRであるウィンセッションはBizDevは行っていたのですがそれ以外では行っていませんでした。月次会では全社がウィンを共有していたのですが、特にエンジニアチームには毎週のウィンセッションは適合しないという理由でした。それはエンジニアチームがスクラム開発を行っていたためです。
スクラム開発
スクラムは複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものです。
詳しい内容は弊社のエンジニアが"聖典"と読んでいることをぜひご覧ください。
400Fのスクラム体制は2Cと2Bでそれぞれ3名ずつがチームとなり、その中からスクラムマスターを1名任命して運営していました。プロダクトオーナー（PO）は当初2Cも2Bも同じ人物がやっていたのですが、2Cと2Bは考えることが全く異なり頭の整理ができないという中で、7-9月は僕が2BサイドのPO、もう一人の取締役が2CサイドのPOをやっていました（これは大正解。正直自分が2BのPOをやって、2Cも詳細に見るのは不可能だと思いました）。
なお、組織図としては以下のような感じでした。CEOの僕が2B、BizDev、Corpを管轄し、取締役CPO（Chief Product Officer）が2CとMarketingを見ていました。CTOもいるのですが、取締役や執行役員ではありません。ただし、エンジニアチームのマネジメントは一任しています。
そして1スプリントを２週間と設定して運営をしていました。ここでOKRとの齟齬が生まれるのですが、OKRは毎週チェックインとウィンセッションをやるのですが、スクラムでは２週間を一つの期間として設定しているスクラムチームにとってはOKRのウィンセッションはなんの意味合いも持たなくなりました。
そこで、OKRにおけるウィンセッションは各チーム必要に応じて行うこととしました。スクラムでは、デイリースクラムを行い、２週間目にスプリントレビュー、スプリントレトロスペクティブ、スプリントプランニングを行い、その中間週にバックログリファイメントを行っていました。
個人的に400Fはこのようなフレームワーク（OKRやスクラム）をかなり効果的に活用していると思っております。そういった中で上半期に感じたOKRとスクラム併用のメリット・デメリットがあります。
OKRとスクラム併用のメリット・改善点
両方のフレームワークを活用してきた中で感じたメリットは以下になります。
①イベントが多くなることを契機に全社的なミーティングの見直しやルールを制定できた
②OKRにおける今後4週間のプロジェクト、今週の優先事項がスクラムと紐づいておりやっていることの透明性が高まった
③自信度をOKR期間とスクラムでの運営状況から透明性を高めて可視化できるようになった
④チームごとのコミュニケーションが増えて「言いたいことを言う」と言うカルチャーができてきた
①OKRとスクラムはそれぞれにイベントが多くあり、これを全部やろうとするとミーティングだけでも１週間のうちかなりの時間を裂かれることになります。さらに、その他のミーティングなどもあるともはや「ミーティングのために勤務している」と言う最悪な状況になってしまいます。
そこで、これはボトムアップからのアラートが発せられて全社で行われているミーティングの棚卸しを行いました。以下は実際にミーティングの棚卸しをした時のリストです。吐き気がしそうになりました。
そこでそれぞれのミーティングの主旨や参加者などを全て確認した上で断固たる決意でミーティングの統廃合を進めました。今ではほとんど（そのように期待）のミーティングに無駄がなくやっていると感じます。
②スクラムでプランニングを行っていくことでOKRにおいて計画していることがどのようなものなのがかなり透明性を持ってわかるようになってきました。そのため、他のチームが見ても「今このスクラムチームはこれをやっているのか」と言う理解が進みました。
③自信度については各人がKRに対してvoteを行って決めること、さらにvoteはOKR期間内で達成できるのかと言う基準も入れることによって、マネジメントとしては四半期というOKR期間において何ができそうで何ができなさそうなのか、ということが明確になり、それによってリスクコントロールなどをできるようになりました。
④そしてOKRもスクラムも僕はコミュニケーションを促すことが非常に大事だと思っています。単にフレームワークを運用して、内容を当てはめていくだけでは両方は機能しません。
OKRとスクラムの中で、レトロスペクティブなどで１スプリント期間で行ってきたことの振り返り、スプリントレビューでは率直な意見を他メンバーからも受ける、プランニングでは「何を優先すべきか」ということを侃侃諤諤議論するなど、これまでと比較して圧倒的に会話の量が増えました。
スクラムでは２週間に一度は1日を潰してスクラムイベントを実施しています。その日は開発が出来ない訳なのですが、「今自分たちは何に取り組んでいる」「何がボトルネックなのか」「何を優先すべきなのか」などを徹底的に議論することによって残りの日数の進捗が圧倒的にスピーディーになったと実感しています。
一方で改善点で感じたことは以下になります。
①分業が進んでしまい、横断的なタスクへの対応に対するモチベーションが上がらない
②作業していることが目的化してしまい、そもそもの組織の目的と乖離してしまうリスクがある
③チームごとの運営方法が統一化されていないことで、マネジメントとしてはそれぞれの状況を別々のフォーマットで確認しなければならない
①OKRを各チームが別々に運営していることと、スクラムによって開発の優先順位などが決められていくことで、それぞれ連携すべきチームのやりとりが微妙にずれていくな、ということを感じていました。特に、ベンチャーですとどうしても差し込み的な案件が発生してしまい、それによって一時期はスプリントの中止をしてまで対応することもありました。今ではスプリント期間中にいきなり対応することはせずに、差し込み案件もスプリントプランニングに入れて対応することにしています。
しかし、OKRでやろうとしている目標に対してスクラムで設定した自分たちがやろうしている案件ではないタスクが発生したらやはりモチベーションは低下してしまいます。これは非常に悩ましい問題でした。
②これはマネジメントサイドの問題なのですが、OKRのKRを定量化しているものの、PMF前後のベンチャーですと何をKRとして明確に設定して良いかの悩む時があります。そうなると意図せずともスクラムで開発しようとしているタスクがKRにすり替わっていくことがあります。
それによって手段が目的化してしまうこととなり、かなり本末転倒な運営になってしまうという危機感を感じました。つまり会社の目標よりもチームの目標が優先されてしまうという状態に陥るリスクがあるということです。
③これもマネジメントの責任ですが、OKRは各チーム共通にしている中で、スクラムについてはエンジニアチームには適用し、それ以外のチームはOKRの延長で運営していました。そうすると各チームの運営フォーマットがバラバラでマネジメントサイドとしては進捗確認などを別々に管理しなければならない手間がありました。
これはシンプルな問題に見えて非常に厄介な問題になっていました。
下半期のOKRとスクラム併用マネジメンをどのようにするのか
上記のように上半期OKRとスクラムの併用マネジメントを行う中で、メリット・デメリットを感じておりました。そういった中で、僕たちなりの挑戦として下半期は以下のような取り組みをすることとしました。
① マネジメントとしてはチームごとのOKR設定はやめて、グループでOKR設定を行う
②全てのチームの運営はスクラムのフレームワークを活用する
①OKRとスクラムの併用を行っている中で感じた懸念点は分断です。それはチームがサイロ化することと、本来組織としてはKR達成のためにやった方が良いがチームとしてはそれをやることに意欲が湧かないという課題です。
そこで下半期は各チームでのOKR設定ではなく、グループごとのOKR設定にしました。
400Fのビジネスモデルはリボン型であるため、その両方を担当しているチームをグループとして取りまとめるのと同時に、財務などを担当するコーポレートはマネジメントと統合しました。
そしてベンチャーは常に未来思考であるべきものの、これまでにリリースしてきたプロダクトの改善などを行っていかないと負債化していくリスクが高いと思っています。
そこでKRについては改善系と10X系に分けて設定することとしました。非常にハードな運営ですがこれまでのリリースプロダクトをしっかり改善しつつも、それだけでは飛躍的なグロースは達成できないため10Xもやっていくというスタイルです。
②各チームの運営フォーマットがバラバラになることに違和感を感じていたため、マーケティングやBizDevもスクラムのフォーマットを活用することとしました。デイリースクラム、スプリントレビュー、レトロスペクティブ、バックログリファイメント、スプリントプランニングの要素は非エンジニア組織においても適合すると営業出身かつスクラムを経験した僕は感じました。
例えば、営業は毎日日報を書く方が良いし、自分たちの取り組んできた内容の振り返りを行うべきですし、取り組み途中で軌道修正などもやったりするべきですし、さらにはしっかりとした計画を立案すべきです。このフレームワークを他のフレームワークを使うのも良いのですが、スクラムという最高の教科書がある中でそれを活かさない手はないと思い、全社的に導入することにしました。
まとめ
このように400FではOKRとスクラムを併用して活用してきた中で、メリット・改善点を色々と感じてきました。そしてその学びを踏まえて、グループOKRと全社スクラム体制というフレームワークを活用することにしました。
この取り組みが良いのかどうか、また成果を出せるのかどうかは半年後に結論が見えます。しかし、マネジメントとは常に改善の連続であるため新しいことにチャレンジをしつつ400Fなりのフレームワークを構築して、常に10Xなグロースを実現できるようにしていきたいと思います。
----------------------------------------------------------------------------
最後までご覧いただきありがとうございます。現在営業サークルを運営しています。営業サークルでは、業界の未来予想図に関する議論、日々の営業活動やマネジメントの悩み相談などを行っております。今回のような無料noteに加えて、サークル加入メンバーは業界分析を中心とした有料noteを無料で閲覧できるのと、メンバー限定のSlackに加入して様々なディスカッションをしたり、毎週開催されるオンラインミートアップに参加できます。ぜひご加入をご検討くださいませ。
この記事が気に入ったらサポートをしてみませんか？