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

チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development

チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development

YAPC::Kyoto 2023 前日祭 - connpass のReject Conにて発表した時の資料です。

すてにゃん

March 18, 2023
Tweet

More Decks by すてにゃん

Other Decks in Technology

Transcript

  1. チーム開発における様々な
    ボトルネックの整理
    すてにゃん (id:stefafafan)
    2023/03/18 YAPC::Kyoto 2023 Reject Con
    1

    View full-size slide

  2. 自己紹介
    ● すてにゃん (id:stefafafan / @stefafafan)
    ● 2015- 株式会社はてな
    ○ Webアプリケーションエンジニア
    ○ 最近はスクラムマスター、テックリードなど
    2

    View full-size slide

  3. 今日話すこと
    ● チーム開発のサイクルを改善するにはどうす
    ればよいのか
    ○ 状況に応じて取れる手段を提示
    ○ 読んだ本や記事、経験を元に分類分けしたものを共有
    3

    View full-size slide

  4. 4
    ケース1:
    改善サイクルが
    回っていない

    View full-size slide

  5. ケース1: 改善サイクルが回っていない
    ● 状況
    ○ 効率の悪い仕事の仕方を続けている
    ○ 改善される見込みがない
    ● 取れると良い手段
    ○ アジャイルフレームワークを取り入れる
    5

    View full-size slide

  6. ケース1: 改善サイクルが回っていない
    ● 大事なのは Incremental で Iterative である
    こと
    ○ Incremental: 漸進的
    ○ Iterative: 反復的
    ● 課題の解消に向けて少しずつ着実に進めると
    良い
    6

    View full-size slide

  7. ケース1: 改善サイクルが回っていない
    ● 漸進的で反復的に仕事を進めるには?
    ○ アジャイルフレームワークを導入すると良い
    ■ Scrum とかはソフトウェア開発に限らず汎用的に使える
    7

    View full-size slide

  8. 8
    ケース2:
    ソフトウェア開発速度が
    遅い

    View full-size slide

  9. ケース2: ソフトウェア開発速度が遅い
    ● そもそも「遅い」とはどういうことなのか
    ● Four Keysの指標で会話すると良い
    ○ デプロイの頻度
    ○ 変更のリードタイム
    ○ 変更障害率
    ○ サービス復元時間
    9

    View full-size slide

  10. ケース2: ソフトウェア開発速度が遅い
    ● Four Keysはそれぞれの指標が満たされてい
    る必要がある
    ● 例えば「デプロイ頻度は高いけど毎回障害が
    発生している」だとサービス復旧などに時間
    がとられてしまっていることとなる
    10

    View full-size slide

  11. ケース2: ソフトウェア開発速度が遅い
    ● Four Keysの指標の改善にはどういうものが
    効くのか
    ○ Extreme Programming (XP) のプラクティス
    ○ DevOps のプラクティス
    11

    View full-size slide

  12. ケース2: ソフトウェア開発速度が遅い
    ● Extreme Programming (XP) プラクティス
    (以下は一部の例の抜粋)
    ○ 計画
    ■ 小さい単位でリリースする
    ○ コーディング
    ■ ペアプログラミングで進める
    ○ テスト
    12

    View full-size slide

  13. ケース2: ソフトウェア開発速度が遅い
    ● DevOpsのプラクティス
    ○ インフラ要件も一緒のプロジェクトで管理する
    ○ CI/CDを整える
    ○ Infrastructure as Code (IaC) する
    ○ 可観測性をあげる
    ○ アプリケーションエンジニアがインフラのオーナー
    シップを持つ
    13

    View full-size slide

  14. 14
    ケース3:
    チーム内の連携が
    イマイチ

    View full-size slide

  15. ケース3:チーム内の連携がイマイチ
    ● 心理的安全性が足りない
    ○ HRT (謙虚・尊敬・信頼) の欠如
    ○ コードレビューが辛い、気軽に発言できなくて課題が
    隠されてしまう等
    ● プロセスの改善の前に信頼関係を作るところ
    から
    15

    View full-size slide

  16. ケース3:チーム内の連携がイマイチ
    ● チームが自己組織化されていない
    ○ エラスティックリーダーシップ
    ■ サバイバルモード
    ■ 学習モード
    ■ 自己組織化モード
    ○ 現在のモードを自覚し、自己組織化へと導くにはどう
    すると良いかを考える
    16

    View full-size slide

  17. 17
    ケース4:
    チーム外との連携が
    イマイチ

    View full-size slide

  18. ケース4:チーム外との連携がイマイチ
    ● Team Topologies
    ○ 現状の他チームとの関わりを図にする
    ○ リリースまでの流れで毎回他チームとコミュニケー
    ションが発生していると効率が悪そうなど
    ○ モノリシックなリポジトリのデプロイのたびに他チー
    ムに許可をとらないといけないなど
    18

    View full-size slide

  19. 19
    様々な話題があるが
    上手く整理できないか

    View full-size slide

  20. 整理: スコープ別
    ● いくつかのスコープで考えることができる
    ○ 職能チーム(エンジニアチーム、デザイナーチーム)
    ○ 機能開発チーム(企画からリリースまで)
    ○ チーム横断(同じ部署、会社レベルなど)
    20

    View full-size slide

  21. 整理: カテゴリ別
    ● スコープごとに以下のようなカテゴリがある
    ○ テクニカルな話題(コード設計、リファクタリング)
    ○ プロセス周り(Scrum、XP)
    ○ 人間関係(信頼、メンバーの成長)
    21

    View full-size slide

  22. スコープ✖カテゴリで考える
    ● チームごとにどこにボトルネックがあるかは
    バラバラなのでスコープ×カテゴリで考えると
    良い
    22

    View full-size slide

  23. 1. 職能チーム
    2. 機能開発チーム
    3. チーム横断
    1. テクニカルな話題
    2. プロセス
    3. 人間関係
    23
    スコープ✖カテゴリで考える

    View full-size slide

  24. スコープ✖カテゴリで考える
    ● エンジニア+デザイナー × テクニカル面
    ○ コードベースがデザイナーにとっても開発体験の良い
    ものになっているか会話しながら見直すなど
    ● App Engineer+SRE × プロセス
    ○ DevOpsのプラクティスを導入すると良い
    ○ デプロイを依頼するのではなくIaCやCI/CDを整える
    24

    View full-size slide

  25. スコープ✖カテゴリで考える
    ● 会社のエンジニア組織 × メンバーの成長
    ○ チーム間のエンジニアの交流が足りているか
    ○ 社内でのエンジニアの異動を促進していくと良いか
    25

    View full-size slide

  26. まとめ
    ● チーム開発には様々なボトルネックが存在す

    ● スコープ×カテゴリ別に考えてどこから手をつ
    けていくかを考えると良さそう
    ○ 足りていないところはどこかというのを出すのにおす
    すめ
    26

    View full-size slide

  27. 参考文献
    ● Brian W. Fitzpatrick, Ben Collins-Sussman. Team Geek ―Googleのギークた
    ちはいかにしてチームを作るのか. オライリージャパン. 2013.
    ● Matthew Skelton, Manuel Pais. チームトポロジー 価値あるソフトウェアをす
    ばやく届ける適応型組織設計. 日本能率協会マネジメントセンター. 2021.
    ● Nicole Forsgren Ph.D., Jez Humble, Gene Kim. LeanとDevOpsの科学
    [Accelerate] テクノロジーの戦略的活用が組織変革を加速する. インプレス.
    2018.
    ● Roy Osherove. エラスティックリーダーシップ ―自己組織化チームの育て方. オ
    ライリージャパン. 2017.
    27

    View full-size slide

  28. 参考文献
    ● Don Wells. “The Rules of Extreme Programming”. Extreme Programming (xp): A
    Gentle Introduction. 1999. http://www.extremeprogramming.org/rules.html
    ● hirokidaichi. “エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読
    書ガイド”. Qiita. 2021.
    https://qiita.com/hirokidaichi/items/95678bb1cef32629c317
    ● Tom Hall. “DevOps のベスト プラクティス”. Atlassian. 2023.
    https://www.atlassian.com/ja/devops/what-is-devops/devops-best-practices
    ● Toshimaru. “『Team Geek』読んだ ~HRT(謙虚/尊敬/信頼)の精神を知り会社でサバイブし
    ていく方法~”. Hack Your Design!. 2019. https://blog.toshimaru.net/team-geek/
    ● yigarashi. “Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法に
    ついて”. yigarashiのブログ. 2022.
    https://yigarashi.hatenablog.com/entry/2022/05/30/093000
    28

    View full-size slide