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
zuckey_17
April 11, 2022
Technology
1
520
新規事業のOKRに寄り添う開発の意思決定 / Development decisions to lean on business OKRs
https://studist.connpass.com/event/240401/
の発表資料です。
zuckey_17
April 11, 2022
Tweet
Share
More Decks by zuckey_17
See All by zuckey_17
お手並み拝見にしないオンボーディング
zuckey_17
2
2k
事業の試行錯誤を支える コードを捨てやすくして システムをシンプルに保つ設計と工夫
zuckey_17
10
4.8k
事業の試行錯誤を支えるピボットしやすいシステム設計と工夫 / Easy-to-pivot system design to support trial and error in business
zuckey_17
4
930
Relearning Eloquent
zuckey_17
0
1.8k
Redash made inter-team communication active -
zuckey_17
2
5k
しがないラジオの作り方
zuckey_17
0
2.7k
今更聞けないReact
zuckey_17
4
2k
Other Decks in Technology
See All in Technology
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
750
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
120
Helm , Kustomize に代わる !? 次世代 k8s パッケージマネージャー Glasskube 入門 / glasskube-entry
parupappa2929
0
250
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
3k
プロセス改善による品質向上事例
tomasagi
2
2.6k
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
550
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
110
組織貢献をするフリーランスエンジニアという生き方
n_takehata
2
1.3k
分解して理解する Aspire
nenonaninu
1
300
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
20
8.1k
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
8
1.5k
Swiftの “private” を テストする / Testing Swift "private"
yutailang0119
0
130
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Invisible Side of Design
smashingmag
299
50k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
How to Ace a Technical Interview
jacobian
276
23k
Unsuck your backbone
ammeep
669
57k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Being A Developer After 40
akosma
89
590k
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