distributed-agile-team.connpass.com
今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
いくおさんがこの会のために書いてくれたnote
会の概要
いきいきいくおさんこと小田中さんの以下のつぶやきをきっかけに、エンジニアリングやOKRについて話してみようという会です。
「売上○○円」「ユーザー数○○人」「平均DAU○○」といった目標をどうやってエンジニアリングの目標に落とし込むか。
— いきいきいくお/ いちやさアジャイル (@dora_e_m) 2021年10月28日
OKRの場合、ツリーが連なってく中で親KR (定量)→子O(定性)の変換を行うため、ここの変換の仕方がキモになる。
こういう「エンジニアのためのOKR」について言語化したくなってきた
会で印象的だったこと
変化するObjectiveの難しさ
スタートアップなどで、Objectivesが四半期に一度変わるような組織だと、四半期ごとにエンジニアチームがプロダクトバックログを全て作り直すような事態が発生してしまう問題が起こるという話がありました。
また、そもそもOKRには導入しやすいビジネスモデル(例えばR&Dをする部署など)というのは確実にあるので、どこにでも上手くいくわけではないし、全社導入しようという話になった時に壁にぶち当たることが起きるというお話もありました。
Objectivesは長期間変わらないものである前提があった方が基本的には良いというのは確かになあと思いながら聴いていきました。
エンジニアだからこそ気が付く目標の解像度の粗さ
コンサルをはじめとしたビジネス職の人は、OKR*1のツリー構造で上位と下位のつながりや論理性といった部分には目が行くしチェックできるけれども、key resultの解像度がめちゃくちゃ粗いことにはなかなか気が付かない実態があるという話がありました。
一方で、実際に活動するエンジニアの人たちは、key resultの解像度がめちゃくちゃ粗いことに気が付くので、Gapが生まれたり、やってやろうという気持ちにならずに仕事することになるという話がありました。
エンジニアだからこそ気が付けるというのはあるなあと思っていて、OKRに限らず、エンジニアと経営層やビジネス層をいかに近づけるかは大事だなあと改めて実感しました。
先行指標
Key Resultなどで定量的な指標を設定する際、遅行指標よりも先行指標を見つける方が大事なんだけれど、単なる相関関係を見つけて先行指標として設定してしまったり、希望的観測や妄想を先行指標としてしまうことがあるよね、という話を聴いていきました。
ちょうど自分もKPIや指標づくりで今悩んでいたので、この話はぐさぐさ刺さりながら聴いていました。
いきいき
小田中さんが、OKRの運用を考えて色々と質問をしている時、常にチームメンバーや社員にどうやっていきいきしてもらうか、というのを考えている様子が伺えて、OKRがよくできたフレームワークというよりも、小田中さんがチームメンバーや社員のことを真剣に考えていることが小田中さんが話されていた成果に結びついているんじゃないかなあと漠然と感じました。
ObjectivesやKey Resultがどうかというよりも、ObjectivesやKey Resultを考える過程(ユーザーの声を聴いたり社員と話したり...)が大事なのかもなあと思いました。
全体を通した感想
OKRの話も勿論楽しかったですし、途中にあった会社のリアルな話だったり相談の話も含め、全体を通していつも通りとっても楽しかったです。
社長の話など、普段コミュニティで聴ける話より視座が高めの話が聴けた*2のも学びが深く、充実した時間を過ごすことができました。
また、小田中さんの人の良さといきいきいくおと名乗っている所以をしみじみと実感できた会でもありました！いつも通りたくさん刺激をもらえたので今日も参加できて楽しかったです。
