Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

masahiko.asai

July 13, 2023
Tweet

More Decks by masahiko.asai

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. ログラスについて

    View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. View Slide

  9. View Slide

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

    View Slide

  11. View Slide

  12. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. 開発チーム構成(2022/8 〜)
    機能開発
    A チーム
    機能開発
    B チーム
    機能開発
    C チーム
    プラットフォームチーム

    View Slide

  18. 開発チーム構成(2022/8 〜)
    機能開発
    A チーム
    機能開発
    B チーム
    機能開発
    C チーム
    プラットフォームチーム

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  31. 2つの軸で改善を実施

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  49. サイクルタイムが改善

    View Slide

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

    View Slide

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

    View Slide

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



    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  62. まとめ

    View Slide

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

    View Slide

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

    View Slide

  65. View Slide