開発生産性 超入門 / development productivity introduction

CTOA若手エンジニアコミュニティ勉強会 #5 の発表資料です。
https://ctoa-wakate.connpass.com/event/318007/

Transcript

1. © 2024 Wantedly, Inc. 開発⽣産性 超⼊⾨ CTOA若⼿エンジニアコミュニティ勉強会 #5 May 31 2024 - Sora Ichigo
2. © 2024 Wantedly, Inc. ⾃⼰紹介 名前 市古 空 (Sora Ichigo) 所属 • ウォンテッドリー株式会社 • バックエンドエンジニア • DevOps 推進チームリード SNS • X: @igsr5_
3. © 2024 Wantedly, Inc. Business Wantedly Visit iOS, Android and Web 気軽に会社訪問 ミッションや価値観への共感でマッチング • 給与や福利厚⽣などの条件ではなく、想いがあれば会社 の規模にとらわれない まず「話を聞きに⾏く」という新しい体験 • 個⼈と企業がフラットな⽬線で出会えることで、より魅 ⼒的な場所を⾒つけることが可能に
4. © 2024 Wantedly, Inc. Business Engagement Perk, Pulse, Story ⾃律型組織づくりをサポート 3つのプロダクトから構成 • 仕事に夢中になり最⾼のパフォーマンスを発揮するために 必要な環境づくりを後押し リモートワークの課題にも • 会社との⼼理的距離の拡⼤によるモチベーションの低下を 防ぎ、退職リスクの増⼤など組織課題を解決
5. © 2024 Wantedly, Inc. Business Engagement - Perk（パーク） 福利厚⽣ 仕事環境を整える話題のサービスを 提供する「福利厚⽣」 • ⼀⼈ひとりの快適な挑戦を⽀えるサービスを特別価格で提供し、福 利厚⽣の充実を⼿軽に実現 • 特典掲載数 1,000サービス以上
6. © 2024 Wantedly, Inc. Business Engagement - Story（ストーリー） 社内報 メンバー間で⽬的意識と⼀体感を 共有するオンラインの「社内報」 • ⾯と向かって想いを伝えることが難しい環境においても、 会社のビジョンやバリューの浸透を⽀援
7. © 2024 Wantedly, Inc. Business Engagement - Pulse（パルス） チームマネジメント チームメンバーの現状把握と 改善を⽀援「チームの状態」 • Slackを通じてチームの価値観を浸透させ、 メンバーの抱える課題や隠れた貢献を可視化
8. © 2024 Wantedly, Inc. 今⽇話すこと 1. ⼤前提: プロダクト開発とは 2. 開発⽣産性とは 3. 開発⽣産性を上げる 4. ウォンテッドリー事例
9. © 2024 Wantedly, Inc. ⽬標 開発⽣産性の基本を why から理解する 󰢃 具体的なプラクティス 󰢏 抽象的な理論 󰢄このスライドを読めば開発⽣産性の全てがわかる 󰢐このスライドを読めば開発⽣産性の基本がわかる
10. © 2024 Wantedly, Inc. ⼤前提: プロダクト開発とは
11. © 2024 Wantedly, Inc. 我々は⽇々、プロダクトに変更を加えている プロダクトの変更とは「仮説」 仮説: この変更を加えればユーザーに価値が届くはず ウォンテッドリー社内 issue テンプレート プロダクトに適⽤
12. © 2024 Wantedly, Inc. なんで仮説が重要？ 不確実性が⾼く、予測可能性が低い 原因と結果の因果関係が、後になって分かる領域。 その因果関係を⾒出すために、失敗しても影響が⼩さい実験を繰り返し、そこから成功パ ターンを⾒つけ出す。 可能性を論じることはできるが、 めくってみないと分からない
13. © 2024 Wantedly, Inc. つまりプロダクト開発とは 継続的な仮説検証サイクル
14. © 2024 Wantedly, Inc. 重要なこと 周囲より早く、顧客が本当に欲しいものを⾒つけ提供する 多くのプロダクトが溢れる時代におけて⾮常に⼤切 「最短距離の最⼤社会的インパクト」 ウォンテッドリーの⾏動指針の⼀つ。 Wantedly, Inc.の事業とカルチャー - Wantedly
15. © 2024 Wantedly, Inc. 開発⽣産性とは
16. © 2024 Wantedly, Inc. 開発⽣産性とは 定義は様々。視点によって変わる。 例. 経営‧財務 視点 現場 視点 アウトプット効率 アウトプット = ⼈数規模 (インプット) x ⽣産性 (係数) 開発者体験 (アクティビティ) ある作業にかかる時間、ストレス度合い...etc
17. © 2024 Wantedly, Inc. 開発⽣産性の定義は重要ではない 各視点の利害を統合する 正確な定義よりも、全体最適にアクティビティ改善→アウトカム最⼤化を⽬指す動きが重要 当たり前じゃん！と思うけど、1つのデリバリーには多くの職種が関わっている。 局所最適の罠は意外と多い。
18. © 2024 Wantedly, Inc. 余談) 誤解されがちな DevOps 「各視点の利害を統合する」がまさに DevOps の関⼼ DevOps は単なる⾃動化やプロセス効率化を指す⾔葉ではない。 黎明期は Development (開発) と Operations (運⽤) の対⽴を無くすことが⽬的だったが、 現代ではあらゆる部署の利害を統合して組織全体のパフォーマンスを⾼めるムーブメントと して発展している。 DORA | Get Better at Getting Better
19. © 2024 Wantedly, Inc. 開発⽣産性を上げる
20. © 2024 Wantedly, Inc. 開発⽣産性を上げるとは アクティビティ改善→アウトカム最⼤化を⽬指すこと 再掲 p.12
21. © 2024 Wantedly, Inc. アウトカムとアクティビティの関係性 仮説検証のスピード 仮説検証の回数 仮説検証の質 プロダクト価値 アウトカム アクティビティ
22. © 2024 Wantedly, Inc. KPI に落とし込んで考えてみると 仮説検証のスピード 施策あたりのリードタイム 仮説検証の回数 ⽉当たりの施策リリース数 仮説検証の質 ⽉当たりの本機能化率
23. © 2024 Wantedly, Inc. 開発⽣産性を上げる 2 種類の⽅法 「改善」と「改⾰」
24. © 2024 Wantedly, Inc. 改善 現状をよりうまく回すための改善 連続的な成⻑。地道な改善を積み重ねることが多い。 例. ストリームアラインドチームの施策リードタイム短縮
25. © 2024 Wantedly, Inc. 改善モデル 「把握→分析→対応」のサイクル クネビンフレームワークの「Complicated / 込み⼊った状況にある領域」 sense analyze respond
26. © 2024 Wantedly, Inc. 改⾰ 理想を実現するための改⾰ ⾮連続的な成⻑。⼤きな障壁があることが多い。 例. • モバイルアプリ開発には時間がかかるからクイックな仮説検証には向いていない • => モバイルアプリ開発が爆速になれば新しい仮説検証スタイルになるのでは？
27. © 2024 Wantedly, Inc. 「改⾰」でプロダクト‧事業に⼤きな変化を⽣む プロセス的な制約を取っ払った新しい仮説検証スタイル
28. © 2024 Wantedly, Inc. 「改⾰」でプロダクト‧事業に⼤きな変化を⽣む ⼤きな現状課題はなんですか？ 事業フェーズや外部環境など、要因はさまざま ⾮連続的な成⻑を実現する伸び代はありますか？ プロセス的な制約によって実現されていない仮説検証スタイル
29. © 2024 Wantedly, Inc. ウォンテッドリーの「改善」事例
30. © 2024 Wantedly, Inc. 実際に改善モデルを回した事例を紹介します 再掲 p.25
31. © 2024 Wantedly, Inc. ① 把握: 施策の可視化 まずは施策のリードタイム‧並⾏数を可視化してみる
32. © 2024 Wantedly, Inc. ① 把握: 施策の可視化 リードタイムは短縮傾向にあるが、まだまだ伸び代もある 2週間にしたいですね
33. © 2024 Wantedly, Inc. ② 分析 全ての施策が 2 週間で終わったと仮定すると...？
34. © 2024 Wantedly, Inc. ② 分析 全ての施策が 2 週間で終わったと仮定すると...？ • Q あたりにリリースできる施策数は 4 つ増える！ • 同時並⾏する施策数を 3~4 つ → 2 つまで減らせる！
35. © 2024 Wantedly, Inc. ③ 対応 ⽬標設定「施策のリードタイム 2 週間」 伸び代を探るため、さらに個々の施策ごとに「把握‧分析」を進める • 施策リードタイムの内訳分析 • 上⼿くリリースできた施策‧時間がかかった施策の⽐較
36. © 2024 Wantedly, Inc. ③ 対応 Daily Sync Up のフォーマット改善 MTG の⽬的を再確認。個⼈単位の共有 → 施策単位の共有へ。 仕様議論の進め⽅改善 1 トピックあたりのラリー数を減らして複雑性を減らす。 仕様を議論する順番を最適化する。 ペアプロ‧モブプロの推進 軽量なレビュープロセス。知⾒の伝搬。 実際にあった改善例
37. © 2024 Wantedly, Inc. 他にも 施策だけでなく、変更単位の数字も活⽤ ※1つの施策は複数回の⼩さな変更を経てリリースされます 右グラフは 変更のリードタイム (h)
38. © 2024 Wantedly, Inc. 他にも よく改善の参考にするモデル DevOps Capabilities
39. © 2024 Wantedly, Inc. まとめ
40. © 2024 Wantedly, Inc. まとめ • プロダクト開発とは「継続的な仮説検証サイクル」p. 10 • 周囲より早く、顧客が本当に欲しいものを⾒つけ提供することが重要 ◦ ≒ 開発⽣産性の重要性 • 開発⽣産性の定義はさほど重要ではない (視点によりけり) p.15 • 真に重要なのは「各視点の利害を統合すること」p.16 ◦ = DevOps ◦ 特にアクティビティとアウトカムを統合して考えるべし • 開発⽣産性の取り組みでは「改善」と「改⾰」の2⾯性を意識する p. 19