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

2023.7.13「開発生産性Conference 2023」登壇資料
https://dev-productivity-con.findy-code.io/

不確実性の高い課題を解決すべくプロダクト開発を行っている昨今、急速な成長を支えるためにもビジネスインパクトに寄与するためにも、開発チーム自らが自律的に生産性向上に取り組んでいくことが重要になっています。

本セッションではログラスの開発チームでの取り組みについて焦点を当て、チームのカルチャーの紹介も交えながら、経験学習を繰り返す中で開発生産性を向上させ、ビジネスインパクトに寄与していった取り組みについてご紹介します。本セッションがチームの改善アイデアのヒントとなれば幸いです。

Transcript

1. ⽣産性向上に⾃ら取り組む チームカルチャーが⽣み出す顧客価値 2023/7/13 開発⽣産性Conference 2023 Lunch Session #1, Hall B Masahiko Asai / Loglass, Inc.
2. ⾃⼰紹介 株式会社ログラス 開発部 エンジニア 浅井 雅彦 / Masahiko Asai フロントエンドエンジニアとしてWeb制作会社、ベンチャー企業2社を 経て、2021年10⽉にログラスに⼊社。 初期からUIデザインを含むフロントエンド開発全般を主に担当。 現在は開発チームのエンジニアとして主要機能の開発を⾏う傍ら、 デザインシステムの構築を担っている。 また、開発チームの開発⽣産性を向上するために、Four Keysを参考に しながら改善に取り組んでいる。 @mixplace
3. ログラスについて
10. https://www.loglass.co.jp/3rd-anniversary
13. “魅⼒的な発信を⾏っている「開発者体験ブランド⼒」評価の⾼い企業” 25位にランクイン
14. 本⽇お話しすること いち機能開発チームに所属して約1年間、 品質と開発⽣産性を上げる取り組みを チームメンバーとともに進めていった結果、 顧客価値を効果的に創出できるようになっていったお話をします
15. AGENDA 1 なぜチームが⾃ら開発⽣産性向上に取り組もうと思ったのか 2 どのような側⾯から開発⽣産性を上げていったのか 3 この1年弱でどのような変化が起きたのか 4 どうして顧客価値を効果的に創出できていったのか チームカルチャーの重要性
16. 1 なぜチームが⾃ら開発⽣産性向上に 取り組もうと思ったのか
17. 開発チーム構成（2022/8 〜） 機能開発 A チーム 機能開発 B チーム 機能開発 C チーム プラットフォームチーム
18. 開発チーム構成（2022/8 〜） 機能開発 A チーム 機能開発 B チーム 機能開発 C チーム プラットフォームチーム
19. 機能開発 A チーム 機能開発 A チーム • PdM/デザイナー/エンジニア/QAで構成された機 能開発チーム • 2022年夏に新しいメンバーが数名ジョイン、新た な船出となったチーム • 開発手法はスクラム
20. 機能開発 A チーム組成後に取り組んだ 機能改修エピックで課題感があがった
21. 機能改修エピックでの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった ◦ プルリクエストのレビューが⼤きくなりがち ◦ レビューに時間がかかる 2. ビッグバンリリースになってしまった ◦ お客様に機能を提供するまでに時間がかかっている 3. 変更失敗が複数回起きてしまった ◦ 複雑な仕様、テストが不⼗分
22. 📖 Four Keysより リードタイム コードがcommitされてから本番環境で正常に実行されるまでの時間 デプロイ頻度 コードを本番環境にデプロイまたはエンドユーザーに リリースした頻度 変更失敗率 本番環境に変更を加えた、またはユーザーへのリリースを実施した結果 サービスが低下し、その後修正を行う必要が生じた割合 復元時間 サービスインシデントまたは不具合が発生したときにサービスの復元にど れくらいの時間がかかるか
23. 機能改修エピックでの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった リードタイム 変更失敗率 リードタイム デプロイ頻度
24. 機能改修エピックでの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった リードタイム 変更失敗率 リードタイム デプロイ頻度
25. あるスプリント レトロスペクティブの⼀コマ
26. 機能改修エピックでの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった リードタイム 変更失敗率 リードタイム デプロイ頻度
27. 変更失敗が複数回起こしてしまった • マイナーケースの不具合に遭遇してしまったお客様から 品質の改善要望をいただく • 品質の底上げ、不具合の洗い出しを⾏うべく、 新規開発を数週間⽌めて品質向上のための改善活動に取り組む
28. チームメンバーみんなが⾃問⾃答する 💭これは⽣産性を上げられていると⾔えるのだろうか…？🤔 💭これはお客様へ価値を届けていると⾔えるのだろうか…？🤔
29. チームメンバーみんなが⾃問⾃答する 💭これは⽣産性を上げられていると⾔えるのだろうか…？🤔 💭これはお客様へ価値を届けていると⾔えるのだろうか…？🤔 お客様へ価値を届けていけるように 品質を担保しながら チームで開発⽣産性の改善を進めていくことに
30. 2 どのような側⾯から 開発⽣産性を上げていったのか
31. 2つの軸で改善を実施
32. 🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施
33. 開発スピードを上げる 🚀 • エピックから⼩さなストーリーに分割する ◦ 良い粒度でストーリーを分割するために練習する ◦ チケットも⼩さく切る • ペアプログラミングの導⼊ • Findy Team+ を活⽤して、サイクルタイムをトラッキング • フィーチャートグル、ユーザーロールを活⽤する • プルリクエストを⼩さくする
34. エピックから⼩さなストーリーに分割する 🚀👌 • エンジニア組織の中では「良いケーキの切り⽅」と呼称している • チーム内で良い知⾒がないときは、他チームメンバーの知⾒を借りて ストーリーの分割の仕⽅を練習する • 影響範囲も⼩さくできるため、テスト範囲も明確になった
35. ペアプログラミングの導⼊ 🚀 • 新しいメンバーが増えた時期でもあった知見の伝承を意図してペアプログラミングを 実施 ◦ 経営管理という複雑性の高い領域ということもあり、知見の伝承が効果を発揮 • ドライバーとナビゲーターが相互にレビューすることで、実装の方針や設計標準の 知見が伝搬できる • アタマの中で思ったことを口に出し合って開発する • プルリクエストのレビューコストを削減しながら品質も担保できる
36. 開発スピードを上げる 🚀 • Findy Team+ を活⽤して、サイクルタイムをトラッキング ◦ 社内勉強会でFour Keys を指標にすると良さそうという示唆を得る ◦ 最初のコミット〜マージまでの時間を計測する ◦ 自分たちのボトルネックが知れる • チームのOKR（目標）として設定、週次で改善アクションを試す ◦ オーナーシップを持つ ◦ 毎週指標をトラッキングして、スコアの変化を観察する
37. 品質を上げる👌 • チームで品質のシフトレフトに取り組む スプリント プランニング時に「テスト設計」を実施する ◦ QAメンバーにテスト設計レビューを受けて、⾜りていないテスト観点を学習する • 「ソフトウェアテスト技法ドリル」を解く ◦ 朝⼣に⾃習タイムを設けて解くことで、テスト技法のナレッジを深める
38. 🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施
39. 🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施 これで⼗分、開発チームとしては改善したともいえる
40. 🚀 開発スピードの向上 👌 品質の向上 2つの軸で改善を実施 いや、これだけじゃない
41. 💖 お客様への 提供価値向上
42. ⼤事なことでは？ 💖 お客様への 提供価値向上
43. お客様からいただいた要望を把握する 💖 • お客様やビジネスサイドからいただく要望を 週次でスクリーニングする • 要望の件数が多い かつ 少ないリソースで改善できるものは 躊躇なくその場でチケット化 ◦ 次のスプリントで対応を進めていく
44. 🚀 開発スピードの向上 👌 品質の向上 💖 お客様への 提供価値向上 お客様への提供価値も考えていけるように
45. もともとの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった
46. もともとの課題感 1. 開発着⼿からリリースまで、デリバリーに時間がかかった 2. ビッグバンリリースになってしまった 3. 変更失敗が複数回起きてしまった 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上 👌 品質の向上 🚀 開発スピードの向上 💖 お客様への提供価値向上
47. 課題と改善活動の時系列 新⽣チーム船出 新メンバー複数名ジョイン 改修エピックを進める 課題感から改善活動に着⼿ 不具合の洗い出し、品質向上に注⼒ 品質のシフトレフトに取り組む ペアプログラミング プルリクエストを⼩さくする取り組み 2022/8 要望のスクリーニング サイクルタイムのトラッキング 2022/9 2023/1 2022/10
48. 3 この1年弱でどのような変化が起きたのか
49. サイクルタイムが改善
50. サイクルタイムが改善 サイクルタイム 平均値 約 260 時間 サイクルタイム 平均値 約 32 時間
51. お客様からも改善された機能について 感謝のお声をいただけるように
52. カスタマーサクセスの皆さんからも 機能改善とスピードに対して感謝の声をいただく
53. 4 どうして顧客価値を効果的に創出できていったのか チームカルチャーの重要性
54. チームメンバー各々が 自ら能動的・協力的に行動できたから
55. 3つの軸で改善を実施 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上
56. 3つの軸で改善を実施 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上 👥 チームカルチャー
57. 3つの軸で改善を実施 👌 品質の向上 💖 お客様への提供価値向上 🚀 開発スピードの向上 👥 チームカルチャー 重要な要素では？
58. 組織の「カルチャー（文化）」は 非常に重要である––– 「LeanとDevOpsの科学」 第3章　組織文化のモデル化と測定、改善の方法 より引用 LeanとDevOpsの科学でも⾔っていた
59. チーム力を上げるために取り組みを実施 チームの一体感をより強固にしていくワークを月1回、定期的に開催 • 関係性システムコーチング ◦ DTA（Designing Team Alliance: 意図的な協働関係の構築） ◦ ハイドリーム・ロードリーム どういった状態が最高／最低のチームと言えるかを表現 • ドラッカー風エクササイズ ◦ 自分の得意なこと、大切に思う価値、 メンバーは自分がどのように貢献することを期待していると思うかを表現
60. ワークを経て チームの価値観‧⽂化が形成されていく ⼩さなTryを 重ねる 困難な道のりにも ⽴ち向かう 今の状態は ベストではない ⼀⼈称→三⼈称 I ではなく We お客様に近い⽅と 対話を深めたい お客様に 使っていただける 機能を提供したい 先導‧推進した⼈ を褒める 困ったら 作戦会議を⾏う 学習し続ける 経営管理領域は 複雑で難しい ⼀⼈で⽴ち向かう のは難しい お客様理解を 深めたい
61. チームのカルチャーが形成されていく中で 開発生産性の向上、お客様へ価値寄与したい 価値観が生まれていく
62. まとめ
63. まとめ チームのカルチャーは重要 • ⾃律的に開発⽣産性向上‧改善活動の原動⼒となる • 褒める⽂化があると⼼理的安全性が⾼まる • チームで価値観が形成されると各々オーナーシップを 持って進めやすい 開発⽣産性の向上には指標をトラッキングし続 けることが重要 他チームとの協⼒は不可⽋ • 改善活動にオーナーシップをもって継続することが重要 • 知⾒のある⽅を巻き込むことでチームが強くなる QAエンジニア, カスタマーサクセス, EM, SRE, etc…
64. お知らせ 本⽇会場にブースを出展しています ログラスブースへぜひお越しください。 開発⽣産性全般、チームづくり、プロダクトマネジメ ント、etc… このセッションで話しきれなかったこと、 詳しく知りたいことをご紹介します。