生産性向上に自ら取り組むチームカルチャーが生み出す顧客価値

by masahiko.asai

Slide 1

Slide 1 text

⽣産性向上に⾃ら取り組むチームカルチャーが⽣み出す顧客価値 2023/7/13 開発⽣産性Conference 2023 Lunch Session #1, Hall B Masahiko Asai / Loglass, Inc.

Slide 2

Slide 2 text

⾃⼰紹介株式会社ログラス開発部エンジニア浅井雅彦 / Masahiko Asai フロントエンドエンジニアとしてWeb制作会社、ベンチャー企業2社を経て、2021年10⽉にログラスに⼊社。初期からUIデザインを含むフロントエンド開発全般を主に担当。現在は開発チームのエンジニアとして主要機能の開発を⾏う傍ら、デザインシステムの構築を担っている。また、開発チームの開発⽣産性を向上するために、Four Keysを参考にしながら改善に取り組んでいる。 @mixplace

Slide 3

Slide 3 text

ログラスについて

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

https://www.loglass.co.jp/3rd-anniversary

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

“魅⼒的な発信を⾏っている「開発者体験ブランド⼒」評価の⾼い企業” 25位にランクイン

Slide 14

Slide 14 text

本⽇お話しすることいち機能開発チームに所属して約1年間、品質と開発⽣産性を上げる取り組みをチームメンバーとともに進めていった結果、顧客価値を効果的に創出できるようになっていったお話をします

Slide 15

Slide 15 text

AGENDA 1 なぜチームが⾃ら開発⽣産性向上に取り組もうと思ったのか 2 どのような側⾯から開発⽣産性を上げていったのか 3 この1年弱でどのような変化が起きたのか 4 どうして顧客価値を効果的に創出できていったのかチームカルチャーの重要性

Slide 16

Slide 16 text

1 なぜチームが⾃ら開発⽣産性向上に取り組もうと思ったのか

Slide 17

Slide 17 text

開発チーム構成（2022/8 〜）機能開発 A チーム機能開発 B チーム機能開発 C チームプラットフォームチーム

Slide 18

Slide 18 text

開発チーム構成（2022/8 〜）機能開発 A チーム機能開発 B チーム機能開発 C チームプラットフォームチーム

Slide 19

Slide 19 text

機能開発 A チーム機能開発 A チーム ● PdM/デザイナー/エンジニア/QAで構成された機能開発チーム ● 2022年夏に新しいメンバーが数名ジョイン、新たな船出となったチーム ● 開発手法はスクラム

Slide 20

Slide 20 text

機能開発 A チーム組成後に取り組んだ機能改修エピックで課題感があがった

Slide 21

Slide 21 text

機能改修エピックでの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった ○ プルリクエストのレビューが⼤きくなりがち ○ レビューに時間がかかる 2. ビッグバンリリースになってしまった ○ お客様に機能を提供するまでに時間がかかっている 3. 変更失敗が複数回起きてしまった ○ 複雑な仕様、テストが不⼗分

Slide 22

Slide 22 text

📖 Four Keysよりリードタイムコードがcommitされてから本番環境で正常に実行されるまでの時間デプロイ頻度コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度変更失敗率本番環境に変更を加えた、またはユーザーへのリリースを実施した結果サービスが低下し、その後修正を行う必要が生じた割合復元時間サービスインシデントまたは不具合が発生したときにサービスの復元にどれくらいの時間がかかるか

Slide 23

Slide 23 text

機能改修エピックでの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまったリードタイム変更失敗率リードタイムデプロイ頻度

Slide 24

Slide 24 text

Slide 25

Slide 25 text

あるスプリントレトロスペクティブの⼀コマ

Slide 26

Slide 26 text

Slide 27

Slide 27 text

変更失敗が複数回起こしてしまった ● マイナーケースの不具合に遭遇してしまったお客様から品質の改善要望をいただく ● 品質の底上げ、不具合の洗い出しを⾏うべく、新規開発を数週間⽌めて品質向上のための改善活動に取り組む

Slide 28

Slide 28 text

チームメンバーみんなが⾃問⾃答する 💭これは⽣産性を上げられていると⾔えるのだろうか…？🤔 💭これはお客様へ価値を届けていると⾔えるのだろうか…？🤔

Slide 29

Slide 29 text

チームメンバーみんなが⾃問⾃答する 💭これは⽣産性を上げられていると⾔えるのだろうか…？🤔 💭これはお客様へ価値を届けていると⾔えるのだろうか…？🤔 お客様へ価値を届けていけるように品質を担保しながらチームで開発⽣産性の改善を進めていくことに

Slide 30

Slide 30 text

2 どのような側⾯から開発⽣産性を上げていったのか

Slide 31

Slide 31 text

2つの軸で改善を実施

Slide 32

Slide 32 text

🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施

Slide 33

Slide 33 text

開発スピードを上げる 🚀 ● エピックから⼩さなストーリーに分割する ○ 良い粒度でストーリーを分割するために練習する ○ チケットも⼩さく切る ● ペアプログラミングの導⼊ ● Findy Team+ を活⽤して、サイクルタイムをトラッキング ● フィーチャートグル、ユーザーロールを活⽤する ● プルリクエストを⼩さくする

Slide 34

Slide 34 text

エピックから⼩さなストーリーに分割する 🚀👌 ● エンジニア組織の中では「良いケーキの切り⽅」と呼称している ● チーム内で良い知⾒がないときは、他チームメンバーの知⾒を借りてストーリーの分割の仕⽅を練習する ● 影響範囲も⼩さくできるため、テスト範囲も明確になった

Slide 35

Slide 35 text

ペアプログラミングの導⼊ 🚀 ● 新しいメンバーが増えた時期でもあった知見の伝承を意図してペアプログラミングを実施 ○ 経営管理という複雑性の高い領域ということもあり、知見の伝承が効果を発揮 ● ドライバーとナビゲーターが相互にレビューすることで、実装の方針や設計標準の知見が伝搬できる ● アタマの中で思ったことを口に出し合って開発する ● プルリクエストのレビューコストを削減しながら品質も担保できる

Slide 36

Slide 36 text

開発スピードを上げる 🚀 ● Findy Team+ を活⽤して、サイクルタイムをトラッキング ○ 社内勉強会でFour Keys を指標にすると良さそうという示唆を得る ○ 最初のコミット〜マージまでの時間を計測する ○ 自分たちのボトルネックが知れる ● チームのOKR（目標）として設定、週次で改善アクションを試す ○ オーナーシップを持つ ○ 毎週指標をトラッキングして、スコアの変化を観察する

Slide 37

Slide 37 text

品質を上げる👌 ● チームで品質のシフトレフトに取り組むスプリントプランニング時に「テスト設計」を実施する ○ QAメンバーにテスト設計レビューを受けて、⾜りていないテスト観点を学習する ● 「ソフトウェアテスト技法ドリル」を解く ○ 朝⼣に⾃習タイムを設けて解くことで、テスト技法のナレッジを深める

Slide 38

Slide 38 text

🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施

Slide 39

Slide 39 text

🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施これで⼗分、開発チームとしては改善したともいえる

Slide 40

Slide 40 text

🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施いや、これだけじゃない

Slide 41

Slide 41 text

💖 お客様への提供価値向上

Slide 42

Slide 42 text

⼤事なことでは？ 💖 お客様への提供価値向上

Slide 43

Slide 43 text

お客様からいただいた要望を把握する 💖 ● お客様やビジネスサイドからいただく要望を週次でスクリーニングする ● 要望の件数が多いかつ少ないリソースで改善できるものは躊躇なくその場でチケット化 ○ 次のスプリントで対応を進めていく

Slide 44

Slide 44 text

🚀 開発スピードの向上 👌 品質の向上 💖 お客様への提供価値向上お客様への提供価値も考えていけるように

Slide 45

Slide 45 text

もともとの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった

Slide 46

Slide 46 text

もともとの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上 👌 品質の向上 🚀 開発スピードの向上 💖 お客様への提供価値向上

Slide 47

Slide 47 text

課題と改善活動の時系列新⽣チーム船出新メンバー複数名ジョイン改修エピックを進める課題感から改善活動に着⼿不具合の洗い出し、品質向上に注⼒品質のシフトレフトに取り組むペアプログラミングプルリクエストを⼩さくする取り組み 2022/8 要望のスクリーニングサイクルタイムのトラッキング 2022/9 2023/1 2022/10

Slide 48

Slide 48 text

3 この1年弱でどのような変化が起きたのか

Slide 49

Slide 49 text

サイクルタイムが改善

Slide 50

Slide 50 text

サイクルタイムが改善サイクルタイム平均値約 260 時間サイクルタイム平均値約 32 時間

Slide 51

Slide 51 text

お客様からも改善された機能について感謝のお声をいただけるように

Slide 52

Slide 52 text

カスタマーサクセスの皆さんからも機能改善とスピードに対して感謝の声をいただく

Slide 53

Slide 53 text

4 どうして顧客価値を効果的に創出できていったのかチームカルチャーの重要性

Slide 54

Slide 54 text

チームメンバー各々が自ら能動的・協力的に行動できたから

Slide 55

Slide 55 text

3つの軸で改善を実施 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上

Slide 56

Slide 56 text

3つの軸で改善を実施 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上 👥 チームカルチャー

Slide 57

Slide 57 text

3つの軸で改善を実施 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上 👥 チームカルチャー重要な要素では？

Slide 58

Slide 58 text

組織の「カルチャー（文化）」は非常に重要である––– 「LeanとDevOpsの科学」第3章　組織文化のモデル化と測定、改善の方法より引用 LeanとDevOpsの科学でも⾔っていた

Slide 59

Slide 59 text

チーム力を上げるために取り組みを実施チームの一体感をより強固にしていくワークを月1回、定期的に開催 ● 関係性システムコーチング ○ DTA（Designing Team Alliance: 意図的な協働関係の構築） ○ ハイドリーム・ロードリームどういった状態が最高／最低のチームと言えるかを表現 ● ドラッカー風エクササイズ ○ 自分の得意なこと、大切に思う価値、メンバーは自分がどのように貢献することを期待していると思うかを表現

Slide 60

Slide 60 text

ワークを経てチームの価値観‧⽂化が形成されていく⼩さなTryを重ねる困難な道のりにも⽴ち向かう今の状態はベストではない⼀⼈称→三⼈称 I ではなく We お客様に近い⽅と対話を深めたいお客様に使っていただける機能を提供したい先導‧推進した⼈を褒める困ったら作戦会議を⾏う学習し続ける経営管理領域は複雑で難しい⼀⼈で⽴ち向かうのは難しいお客様理解を深めたい

Slide 61

Slide 61 text

チームのカルチャーが形成されていく中で開発生産性の向上、お客様へ価値寄与したい価値観が生まれていく

Slide 62

Slide 62 text

まとめ

Slide 63

Slide 63 text

まとめチームのカルチャーは重要 ● ⾃律的に開発⽣産性向上‧改善活動の原動⼒となる ● 褒める⽂化があると⼼理的安全性が⾼まる ● チームで価値観が形成されると各々オーナーシップを持って進めやすい開発⽣産性の向上には指標をトラッキングし続けることが重要他チームとの協⼒は不可⽋ ● 改善活動にオーナーシップをもって継続することが重要 ● 知⾒のある⽅を巻き込むことでチームが強くなる QAエンジニア, カスタマーサクセス, EM, SRE, etc…

Slide 64

Slide 64 text

お知らせ本⽇会場にブースを出展していますログラスブースへぜひお越しください。開発⽣産性全般、チームづくり、プロダクトマネジメント、etc… このセッションで話しきれなかったこと、詳しく知りたいことをご紹介します。

Slide 65

Slide 65 text

No content