Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
新規事業のOKRに寄り添う開発の意思決定 / Development decisions to...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
zuckey_17
April 11, 2022
Technology
670
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
新規事業のOKRに寄り添う開発の意思決定 / Development decisions to lean on business OKRs
https://studist.connpass.com/event/240401/
の発表資料です。
zuckey_17
April 11, 2022
More Decks by zuckey_17
See All by zuckey_17
お手並み拝見にしないオンボーディング
zuckey_17
3
2.7k
事業の試行錯誤を支える コードを捨てやすくして システムをシンプルに保つ設計と工夫
zuckey_17
10
5.7k
事業の試行錯誤を支えるピボットしやすいシステム設計と工夫 / Easy-to-pivot system design to support trial and error in business
zuckey_17
4
1k
Relearning Eloquent
zuckey_17
0
2k
Redash made inter-team communication active -
zuckey_17
2
5.3k
しがないラジオの作り方
zuckey_17
0
3.1k
今更聞けないReact
zuckey_17
4
2.1k
Other Decks in Technology
See All in Technology
【Oracle AI Spotlight ウェビナー】AWSか、Azureか、Google Cloudか。その議論にオラクルを含める意義。
oracle4engineer
PRO
2
230
プロダクトエンジニアに必要な「いい感じ」に作る能力 〜たくさん作れる時代に、どこまで作るかの決め方〜
jnishime_dresscode
2
1.3k
Jetpack Compose で挑む新聞紙面UI ─ 複合ジェスチャー・ポリゴン記事領域・適応的ページ構成という3つの壁/droidkaigi2026
nikkei_engineer_recruiting
0
190
Hub & Spoke 環境のネットワークルーティングを分解してみる
tsuyataku
1
520
Self Healing Rollouts: Automating Production Fixes with Agentic AI
kdubois
0
150
最新技術に積極チャレンジ!EKS共通基盤のこれまでとこれから
daitak
0
300
どんな手を使っても絶対間に合わせるスケジューラ
asari194617
0
1.6k
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
230
データエンジニアリングワークショップ:Auto LoaderとSparkで学ぶデータパイプライン構築
databricksjapan
PRO
0
150
生成AI時代の クレデンシャルとパーミッション設計
nrinetcom
PRO
3
1.5k
Genie Code ワークショップ 応用編 / Genie-Code-Workshop-advanced
databricksjapan
PRO
0
320
Does an AI Watermark Survive Translation?
machinetranslation
0
520
Featured
See All Featured
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
890
Done Done
chrislema
186
16k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
How to Ace a Technical Interview
jacobian
281
24k
Information Architects: The Missing Link in Design Systems
soysaucechin
1
1.1k
The Spectacular Lies of Maps
axbom
PRO
1
970
Exploring anti-patterns in Rails
aemeredith
3
490
Large-scale JavaScript Application Architecture
addyosmani
515
110k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
Odyssey Design
rkendrick25
PRO
2
800
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.4k
Transcript
新規事業のOKRに寄り添う 開発の意思決定 Studist Tech Talk #1 @2022-04-06
zuckey (ずっきー) ✓ 新規事業⽴ち上げ時にリードエンジニアとして⼊社 ✓ 現在はEngineering Manager兼開発責任者 ✓ 趣味は Minecraft
最近整備した上空の庭園
✓ OKR? 新規事業で感じたOKRの難しさ ✓ 開発チームが事業のOKRに寄り添うとは Topics
⚠ EXCUSE ⚠ ✓ タイトルにOKRをどーんと掲げていますが、⼀般にいう理想的な OKRの取り組みの話にはなりません ✓ 会社全体のOKR運⽤の中で、⾃分たちの状況にマッチするよう エッセンスを取り⼊れ、開発に役⽴てた事例の紹介になります
本題に⼊る前に 認識合わせ
None
1. PoC(Proof Of Concept)期 ✓ パイロット顧客に伴⾛してプロトタイプと⼿運⽤を混ぜながら価値検証 2. MVP実装期 ✓ 提供したい価値を固めて実装、顧客にヒアリングしながら最低限固める
3. ビジネスモデル確⽴期 ✓ MVPを実運⽤になじませ、価値を感じていただけた顧客から受注する ✓ 受注が重なればビジネスモデルが確⽴できたとみなせる ✓ 改善要望やデータをもとに、⼩さく速く作っては当ててみる 新規事業のフェーズわけ
1. PoC(Proof Of Concept)期 ✓ パイロット顧客に伴⾛してプロトタイプと⼿運⽤を混ぜながら価値検証 2. MVP 実装期 ✓
提供したい価値を固めて実装、顧客にヒアリングしながら最低限固める 3. ビジネスモデル確⽴期 ✓ MVPを実運⽤になじませ、価値を感じていただけた顧客から受注する ✓ 受注が重なればビジネスモデルが確⽴できたとみなせる ✓ 改善要望やデータをもとに、⼩さく速く作っては当ててみる 新規事業のフェーズわけ 今ココ
✓ OKR? 新規事業で感じたOKRの難しさ ✓ 開発チームが事業のOKRに寄り添うとは Topics
Objectives and Key Results
ざっくりOKR ✓ 導⼊の⽬的: 組織の⽅向性の調整 と 個⼈のアクションへの紐付け(not ⼈事評価) ✓ Objectives: 気後れするぐらい⾼いレベルの、ワクワクする⽬標
✓ Key Results: 頑張っても 6,70% の達成度になりそうな測定可能な成果指標(ムーンショット) ✓ 「会社 > 事業 > チーム > 個⼈」のようにTree状につながるように設定 ✓ オープンにして別のチーム、メンバーなどとの協⼒を促す ✓ 短期のスパン(4半期を推奨)で⾒直し、⽅向修正したり、もしも達成した場合により⾼いレベルに設定する ✓ ⽉曜に⽅向修正し、⾦曜⽇に成果を称え合う
(とくに新規事業で)ここが難しいよOKR ✓ 6,70%達成、ムーンショットの認識のズレ ✓ 数字に変化が少ない事業状況だとKRを追いかけずらい
(とくに新規事業で)ここが難しいよOKR ✓ 6,70%達成、ムーンショットの認識のズレ ✓ 数字に変化が少ない事業状況だとKRを追いかけずらい 価値検証が重要なフェーズではKRが曖昧に その到達度の認識も⼈それぞれ
(とくに新規事業で)ここが難しいよOKR ✓ 6,70%、ムーンショットの認識のズレ ✓ 数字に変化が少ない事業状況だとKRを追いかけずらい 価値検証が重要なフェーズでKRが曖昧に。 その到達度の認識も⼈それぞれ プロダクト指標をえいやで決めてみたものの ユーザー数が少なくてそもそも使ってもらえず、
振り返るネタがない
(とくに新規事業で)ここが難しいよOKR ✓ 6,70%、ムーンショットの認識のズレ ✓ 数字に変化が少ない事業状況だとKRを追いかけずらい 価値検証が重要なフェーズでKRが曖昧に。 その到達度の認識も⼈それぞれ お試し期間で無償提供 売上をKRにしていたら数ヶ⽉変化なし…
プロダクト指標をえいやで決めてみたものの ユーザー数が少なくてそもそも使ってもらえず、 振り返るネタがない
1. PoC(Proof Of Concept)期 ✓ パイロット顧客に伴⾛してプロトタイプと⼿運⽤を混ぜながら価値検証 2. MVP 実装期 ✓
提供したい価値を固めて実装、顧客にヒアリングしながら最低限固める 3. ビジネスモデル確⽴期 ✓ MVPを実運⽤になじませ、価値を感じていただけた顧客から受注する ✓ 受注が重なればビジネスモデルが確⽴できたとみなせる ✓ 改善要望やデータをもとに、⼩さく速く作っては当ててみる 新規事業のフェーズわけ 今ココ
新規事業のフェーズわけ 今ココ 1. PoC(Proof Of Concept)期 ✓ パイロット顧客に伴⾛してプロトタイプと⼿運⽤を混ぜながら価値検証 2. MVP
実装期 ✓ 提供したい価値を固めて実装、顧客にヒアリングしながら最低限固める 3. ビジネスモデル確⽴期 ✓ MVPを実運⽤になじませ、価値を感じていただけた顧客から受注する ✓ 受注が重なればビジネスモデルが確⽴できたとみなせる ✓ 改善要望やデータをもとに、⼩さく速く作っては当ててみる PoC期、MVP実装期は、⽴ち返るべき KR の設定が難しく、 ある種OKRをうまく回すことを諦めていた。
プロダクト・マーケット・フィット[製品と市場の最適な組 み合わせ]を⾒つける前のスタートアップがOKRを使うべ きかと聞かれたら、⾃信を持ってイエスとは⾔えない(中 略)、OKRの導⼊は時期尚早だ。 クリスティーナ・ウォドキー. OKR(オーケーアール) (Japanese Edition)
✓ OKR? 新規事業で感じたOKRの難しさ ✓ 開発チームが事業のOKRに寄り添うとは Topics
O: Hansoku Cloudが⼩売企業の売上最⼤化に貢献するツールだと認められ、 ビジネスモデルを確⽴することができる KR1: 売上指標 ARR x万円 KR2:
商品陳列指⽰配信数 x回 KR3: ⼩売企業のユーザー利⽤頻度 x⽇/週 事業OKR(例)
O: Hansoku Cloudが⼩売企業の売上最⼤化に貢献するツールだと認められ、 ビジネスモデルを確⽴することができる KR1: 売上指標 ARR x万円 KR2:
商品陳列指⽰配信数 x回 KR3: ⼩売企業のユーザー利⽤頻度 x⽇/週 事業OKR(例) この数字の根拠は?顧客の数から逆算して 妥当か?増えるなら何社程度増えるのか? ⼀社あたりの単価は?
O: Hansoku Cloudが⼩売企業の売上最⼤化に貢献するツールだと認められ、 ビジネスモデルを確⽴することができる KR1: 売上指標 ARR x万円 KR2:
商品陳列指⽰配信数 x回 KR3: ⼩売企業のユーザー利⽤頻度 x⽇/週 事業OKR(例) この数字の根拠は?顧客の数から逆算して 妥当か?増えるなら何社程度増えるのか? ⼀社あたりの単価は? 配信はいつ⾏われるのか?頻度は?いつ頃か ら増え始めるのか?配信数が増える要因はな にか?
O: Hansoku Cloudが⼩売企業の売上最⼤化に貢献するツールだと認められ、 ビジネスモデルを確⽴することができる KR1: 売上指標 ARR x万円 KR2:
商品陳列指⽰配信数 x回 KR3: ⼩売企業のユーザー利⽤頻度 x⽇/週 事業OKR(例) この数字の根拠は?顧客の数から逆算して 妥当か?増えるなら何社程度増えるのか? ⼀社あたりの単価は? 配信はいつ⾏われるのか?頻度は?いつ頃か ら増え始めるのか?配信数が増える要因はな にか? ユーザーとは誰か?何をすれば利⽤というの か?この数字をどのように監視するのか?
O: Hansoku Cloudが⼩売企業の売上最⼤化に貢献するツールだと認められ、 ビジネスモデルを確⽴することができる KR1: 売上指標 ARR x万円 KR2:
商品陳列指⽰配信数 x回 KR3: ⼩売企業のユーザー利⽤頻度 x⽇/週 事業OKR(例) この数字の根拠は?顧客の数から逆算して 妥当か?増えるなら何社程度増えるのか? ⼀社あたりの単価は? 配信はいつ⾏われるのか?頻度は?いつ頃か ら増え始めるのか?配信数が増える要因はな にか? ユーザーとは誰か?何をすれば利⽤というの か?この数字をどのように監視するのか? 開発チームのOKRに落とし込むには事業OKRの背景知識を 共有して咀嚼する必要がある
顧客の組織図を作る 特に誰をプロダクトのファンにしたいのか? 決済権を持つのは誰か?サポーター、エネミーは誰か?
MVP実装前に作ったサービスブループリントを⾒直して修正する プロダクトとユーザーとのタッチポイントは変わっていないだろうか? 新たに出てきそうな運⽤上の⼤きな課題はないだろうか? 新たに刺さりそうな価値はないだろうか?
O: Hansoku Cloud を顧客に「普段使い」される プロダクトにする KR1: 同時配信数 xに耐えうる安定的なシステムにする KR2:
顧客要望Backlog x個の解消 KR3: カスタマーサクセスチームの⼯数を x%改善 開発チームOKR(例)
✓ ⾮機能要件の策定につながる ✓ どういう⼈格がプロダクトを利⽤するのか?権限のような機能は必要だろうか? ✓ いつ、どのくらいのアクセス数、流量を⾒込めるのか?サーバーリソース、負荷検証は⼗分か? ✓ 要望の優先順位づけに役⽴つ ✓ 顧客のどの⼈格(部⾨)に対して魅⼒的な機能が今優先されるのだろうか?
✓ 要件が落ちていると成り⽴たない機能はあるだろうか?実装予定にすべて含まれているか? 開発チームが事業のOKRに寄り添うことで得られること
まとめ と これから ✓ 新規事業の⽴ち上げ直後は無理にOKRを遵守しなくて良さそう ✓ 事業OKRをうまく解釈できると開発の案件をうまくコントロールできる ✓ チームOKRが固まりつつある。個⼈OKRへ接続もやっていきたい💪
新規事業のOKRに寄り添う 開発の意思決定 Studist Tech Talk #1 @2022-04-06