Tweet
Tweet

Slide 1

Slide 1 text

© 2024 Wantedly, Inc. 開発⽣産性 超⼊⾨ CTOA若⼿エンジニアコミュニティ勉強会 #5 May 31 2024 - Sora Ichigo

Slide 2

Slide 2 text

© 2024 Wantedly, Inc. ⾃⼰紹介 名前 市古 空 (Sora Ichigo) 所属 ● ウォンテッドリー株式会社 ● バックエンドエンジニア ● DevOps 推進チームリード SNS ● X: @igsr5_

Slide 3

Slide 3 text

© 2024 Wantedly, Inc. Business Wantedly Visit iOS, Android and Web 気軽に会社訪問 ミッションや価値観への共感でマッチング ● 給与や福利厚⽣などの条件ではなく、想いがあれば会社 の規模にとらわれない まず「話を聞きに⾏く」という新しい体験 ● 個⼈と企業がフラットな⽬線で出会えることで、より魅 ⼒的な場所を⾒つけることが可能に

Slide 4

Slide 4 text

© 2024 Wantedly, Inc. Business Engagement Perk, Pulse, Story ⾃律型組織づくりをサポート 3つのプロダクトから構成 ● 仕事に夢中になり最⾼のパフォーマンスを発揮するために 必要な環境づくりを後押し リモートワークの課題にも ● 会社との⼼理的距離の拡⼤によるモチベーションの低下を 防ぎ、退職リスクの増⼤など組織課題を解決

Slide 5

Slide 5 text

© 2024 Wantedly, Inc. Business Engagement - Perk（パーク） 福利厚⽣ 仕事環境を整える話題のサービスを 提供する「福利厚⽣」 ● ⼀⼈ひとりの快適な挑戦を⽀えるサービスを特別価格で提供し、福 利厚⽣の充実を⼿軽に実現 ● 特典掲載数 1,000サービス以上

Slide 6

Slide 6 text

© 2024 Wantedly, Inc. Business Engagement - Story（ストーリー） 社内報 メンバー間で⽬的意識と⼀体感を 共有するオンラインの「社内報」 ● ⾯と向かって想いを伝えることが難しい環境においても、 会社のビジョンやバリューの浸透を⽀援

Slide 7

Slide 7 text

© 2024 Wantedly, Inc. Business Engagement - Pulse（パルス） チームマネジメント チームメンバーの現状把握と 改善を⽀援「チームの状態」 ● Slackを通じてチームの価値観を浸透させ、 メンバーの抱える課題や隠れた貢献を可視化

Slide 8

Slide 8 text

© 2024 Wantedly, Inc. 今⽇話すこと 1. ⼤前提: プロダクト開発とは 2. 開発⽣産性とは 3. 開発⽣産性を上げる 4. ウォンテッドリー事例

Slide 9

Slide 9 text

© 2024 Wantedly, Inc. ⽬標 開発⽣産性の基本を why から理解する 󰢃 具体的なプラクティス 󰢏 抽象的な理論 󰢄このスライドを読めば開発⽣産性の全てがわかる 󰢐このスライドを読めば開発⽣産性の基本がわかる

Slide 10

Slide 10 text

© 2024 Wantedly, Inc. ⼤前提: プロダクト開発とは

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. 我々は⽇々、プロダクトに変更を加えている プロダクトの変更とは「仮説」 仮説: この変更を加えればユーザーに価値が届くはず ウォンテッドリー社内 issue テンプレート プロダクトに適⽤

Slide 12

Slide 12 text

© 2024 Wantedly, Inc. なんで仮説が重要？ 不確実性が⾼く、予測可能性が低い 原因と結果の因果関係が、後になって分かる領域。 その因果関係を⾒出すために、失敗しても影響が⼩さい実験を繰り返し、そこから成功パ ターンを⾒つけ出す。 可能性を論じることはできるが、 めくってみないと分からない

Slide 13

Slide 13 text

© 2024 Wantedly, Inc. つまりプロダクト開発とは 継続的な仮説検証サイクル

Slide 14

Slide 14 text

© 2024 Wantedly, Inc. 重要なこと 周囲より早く、顧客が本当に欲しいものを⾒つけ提供する 多くのプロダクトが溢れる時代におけて⾮常に⼤切 「最短距離の最⼤社会的インパクト」 ウォンテッドリーの⾏動指針の⼀つ。 Wantedly, Inc.の事業とカルチャー - Wantedly

Slide 15

Slide 15 text

© 2024 Wantedly, Inc. 開発⽣産性とは

Slide 16

Slide 16 text

© 2024 Wantedly, Inc. 開発⽣産性とは 定義は様々。視点によって変わる。 例. 経営‧財務 視点 現場 視点 アウトプット効率 アウトプット = ⼈数規模 (インプット) x ⽣産性 (係数) 開発者体験 (アクティビティ) ある作業にかかる時間、ストレス度合い...etc

Slide 17

Slide 17 text

© 2024 Wantedly, Inc. 開発⽣産性の定義は重要ではない 各視点の利害を統合する 正確な定義よりも、全体最適にアクティビティ改善→アウトカム最⼤化を⽬指す動きが重要 当たり前じゃん！と思うけど、1つのデリバリーには多くの職種が関わっている。 局所最適の罠は意外と多い。

Slide 18

Slide 18 text

© 2024 Wantedly, Inc. 余談) 誤解されがちな DevOps 「各視点の利害を統合する」がまさに DevOps の関⼼ DevOps は単なる⾃動化やプロセス効率化を指す⾔葉ではない。 黎明期は Development (開発) と Operations (運⽤) の対⽴を無くすことが⽬的だったが、 現代ではあらゆる部署の利害を統合して組織全体のパフォーマンスを⾼めるムーブメントと して発展している。 DORA | Get Better at Getting Better

Slide 19

Slide 19 text

© 2024 Wantedly, Inc. 開発⽣産性を上げる

Slide 20

Slide 20 text

© 2024 Wantedly, Inc. 開発⽣産性を上げるとは アクティビティ改善→アウトカム最⼤化を⽬指すこと 再掲 p.12

Slide 21

Slide 21 text

© 2024 Wantedly, Inc. アウトカムとアクティビティの関係性 仮説検証のスピード 仮説検証の回数 仮説検証の質 プロダクト価値 アウトカム アクティビティ

Slide 22

Slide 22 text

© 2024 Wantedly, Inc. KPI に落とし込んで考えてみると 仮説検証のスピード 施策あたりのリードタイム 仮説検証の回数 ⽉当たりの施策リリース数 仮説検証の質 ⽉当たりの本機能化率

Slide 23

Slide 23 text

© 2024 Wantedly, Inc. 開発⽣産性を上げる 2 種類の⽅法 「改善」と「改⾰」

Slide 24

Slide 24 text

© 2024 Wantedly, Inc. 改善 現状をよりうまく回すための改善 連続的な成⻑。地道な改善を積み重ねることが多い。 例. ストリームアラインドチームの施策リードタイム短縮

Slide 25

Slide 25 text

© 2024 Wantedly, Inc. 改善モデル 「把握→分析→対応」のサイクル クネビンフレームワークの「Complicated / 込み⼊った状況にある領域」 sense analyze respond

Slide 26

Slide 26 text

© 2024 Wantedly, Inc. 改⾰ 理想を実現するための改⾰ ⾮連続的な成⻑。⼤きな障壁があることが多い。 例. ● モバイルアプリ開発には時間がかかるからクイックな仮説検証には向いていない ● => モバイルアプリ開発が爆速になれば新しい仮説検証スタイルになるのでは？

Slide 27

Slide 27 text

© 2024 Wantedly, Inc. 「改⾰」でプロダクト‧事業に⼤きな変化を⽣む プロセス的な制約を取っ払った新しい仮説検証スタイル

Slide 28

Slide 28 text

© 2024 Wantedly, Inc. 「改⾰」でプロダクト‧事業に⼤きな変化を⽣む ⼤きな現状課題はなんですか？ 事業フェーズや外部環境など、要因はさまざま ⾮連続的な成⻑を実現する伸び代はありますか？ プロセス的な制約によって実現されていない仮説検証スタイル

Slide 29

Slide 29 text

© 2024 Wantedly, Inc. ウォンテッドリーの「改善」事例

Slide 30

Slide 30 text

© 2024 Wantedly, Inc. 実際に改善モデルを回した事例を紹介します 再掲 p.25

Slide 31

Slide 31 text

© 2024 Wantedly, Inc. ① 把握: 施策の可視化 まずは施策のリードタイム‧並⾏数を可視化してみる

Slide 32

Slide 32 text

© 2024 Wantedly, Inc. ① 把握: 施策の可視化 リードタイムは短縮傾向にあるが、まだまだ伸び代もある 2週間にしたいですね

Slide 33

Slide 33 text

© 2024 Wantedly, Inc. ② 分析 全ての施策が 2 週間で終わったと仮定すると...？

Slide 34

Slide 34 text

© 2024 Wantedly, Inc. ② 分析 全ての施策が 2 週間で終わったと仮定すると...？ ● Q あたりにリリースできる施策数は 4 つ増える！ ● 同時並⾏する施策数を 3~4 つ → 2 つまで減らせる！

Slide 35

Slide 35 text

© 2024 Wantedly, Inc. ③ 対応 ⽬標設定「施策のリードタイム 2 週間」 伸び代を探るため、さらに個々の施策ごとに「把握‧分析」を進める ● 施策リードタイムの内訳分析 ● 上⼿くリリースできた施策‧時間がかかった施策の⽐較

Slide 36

Slide 36 text

© 2024 Wantedly, Inc. ③ 対応 Daily Sync Up のフォーマット改善 MTG の⽬的を再確認。個⼈単位の共有 → 施策単位の共有へ。 仕様議論の進め⽅改善 1 トピックあたりのラリー数を減らして複雑性を減らす。 仕様を議論する順番を最適化する。 ペアプロ‧モブプロの推進 軽量なレビュープロセス。知⾒の伝搬。 実際にあった改善例

Slide 37

Slide 37 text

© 2024 Wantedly, Inc. 他にも 施策だけでなく、変更単位の数字も活⽤ ※1つの施策は複数回の⼩さな変更を経てリリースされます 右グラフは 変更のリードタイム (h)

Slide 38

Slide 38 text

© 2024 Wantedly, Inc. 他にも よく改善の参考にするモデル DevOps Capabilities

Slide 39

Slide 39 text

© 2024 Wantedly, Inc. まとめ

Slide 40

Slide 40 text

© 2024 Wantedly, Inc. まとめ ● プロダクト開発とは「継続的な仮説検証サイクル」p. 10 ● 周囲より早く、顧客が本当に欲しいものを⾒つけ提供することが重要 ○ ≒ 開発⽣産性の重要性 ● 開発⽣産性の定義はさほど重要ではない (視点によりけり) p.15 ● 真に重要なのは「各視点の利害を統合すること」p.16 ○ = DevOps ○ 特にアクティビティとアウトカムを統合して考えるべし ● 開発⽣産性の取り組みでは「改善」と「改⾰」の2⾯性を意識する p. 19