開発生産性を計測し_技術的負債返済ができる開発体制を作ったお話

by 株式会社助太刀

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright©2021 Sukedachi Inc. All Right Reserved 自己紹介経歴 Career 01 グリー株式会社 2013.04- 仕事内容 Job 02 2017.03- 月澤拓哉 Employee Introduction 助太刀の開発組織作り業界を変えられるサービスを生み出せる開発組織を作る仕事 Tsukisawa Takuya 執行役員 CTO　これからやりたいこと技術負債の返済と開発サイクルの効率化、社員旅行 1987年生まれ秋田県出身北海道大学大学院情報科学研究科卒激辛料理、お酒、格闘技、筋トレ Twitter @tksw_009 SNS 好きなこと Like 03 株式会社ジーニー　今やっていること主にバックエンド開発、開発組織作りや開発の内製化などに従事 2020年11月 VPoEとして入社 2021年6月執行役員就任 2022年11月執行役員CTO就任 2020.11- 株式会社助太刀　

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀の紹介行政との連携国土交通省が主催する「令和2年度i-Construction大賞」において国土交通大臣賞(最優秀賞)を受賞国交省主導の建設キャリアアップシステム（CCUS）と連携 ESG経営の推進サステナビリティサイトを公開 https://suke-dachi.jp/company/esg/index.html ESG・サステナビリティ投資家からの評価と参画経済産業省が推進する「J-Startup企業」に選定

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright©2021 Sukedachi Inc. All Right Reserved 本セッションで話すこと ○ 助太刀は今まで開発プロセスの改善に取り組んできた（前回デブサミ2023） ○ スクラムを導入し体系的に開発するサイクルは構築できた ○ エンジニア単体やチーム単位での生産性は可視化がイマイチだった ✓ SPとかSLOだけでなく、4keysも並行して測ってみた ✓ 4keysを最適化できるような動きをチームでやってみた ✓ 開発生産性をより解像度高く可視化できた ✓ 効率化することで技術負債返済に時間を使えるようになった今年初めまでの取り組み今回取り組んでみたこと

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発生産性 ➢ 物的生産性 ○ 物理的にどれだけの労働力でアウトプットを出したかの指標 ○ 物的生産性（量／人）＝アウトプット量／エンジニア数 ➢ 付加価値生産性 ○ どれだけの労働力でどれだけの売上総利益が出たかを測る指標 ○ 付加価値生産性（円／人）＝売上総利益／エンジニア数現実理想 2~3ヶ月 2~3ヶ月要件定義設計  開発  テスト  要件定義  設計  開発  テスト  1~2週間要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  1~2週間 1~2週間 1~2週間

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀にあった課題 ❌ 不具合が多い ○ クリティカルなバグが本番で起きる ❌ 開発のリードタイムが長い ○ 開発終わるまで大きいと数ヶ月とか ❌ デプロイ頻度が少ない ○ 数ヶ月に1度程度 ❌ プロダクトロードマップがない ○ 次の優先順位がわからない開発生産性UP 目指す不具合↓ リードタイム↓ デプロイ頻度↑ ＝

Slide 20

Slide 20 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発組織の改善品質 Quality 作業量 Velocity 改善速度 Delivery ❏ コミット量 ❏ チケット数 ❏ ストーリーポイント ❏ 不具合チケット数    ❏ サービス稼働率    ❏ SLA / SLO  ❏ チケット数 ❏ デプロイ時間 ❏ リリース頻度開発プロセスにおいて以下の３つの観点に分け、それぞれを最大化開発の生産性を最大化しプロダクト品質上げてリリース早くしたい

Slide 21

Slide 21 text

Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀の開発組織変遷開発手法ウォーターフォールアジャイル（独自スクラム）スクラム社内人数規模 2名 4名 10名 24名社内開発チケット数 0 34 439 962 2168 テストリリース頻度 1人エンジニアエンジニアデザイナーエンジニアデザイナーエンジニアビジネスデザイナー QAチーム 2~3ヶ月に1度不定期 2週間~2ヶ月に1度不定期 2週間~2ヶ月に1度不定期 1ヶ月に1度程度不定期 2週間に1度 6名

Slide 22

Slide 22 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発プロセス（2023年初）社内24名開発組織規模オフショア 2~4名 ➢ 開発プロジェクトを完全に内製化 ○ オフショアは基本サポート ➢ スクラム開発を導入 ○ 2週間のSprintでアウトプットを出せるように ○ 全員がSprintイベントに参加することで事業理解UP ➢ ストーリーポイントを導入 ○ 各チケットを見積もる際にストーリーポイントを使用 ➢ QAチームの結成 + 戦力増強 ○ Sprintの開発サイクルに合わせて高品質なQAを実施 ○ 社内の不具合率の可視化やSLOの策定なども可能に ➢ ユニットテストをしっかり書く文化に ○ バックエンドから始め、フロント側にも波及開発手法主なリリーススクラム

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話 ✓ 色々経てちゃんとしたスクラム開発に移行 → 安定したリリースができるように ✓ エンジニアのタスクを定量化 → ストーリーポイントで計測 ✓ QAチームの組成とユニットテスト → プロダクト品質が保てるようにこれまで ❏ さらに開発生産性を上げていきた ❏ 組織の拡大に耐えられるように ❏ 他の可視化/定量化手法は？

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

Slide 31

Slide 31 text

Copyright©2021 Sukedachi Inc. All Right Reserved 実際に計測してみた結果 ✓ Backend チーム改善の余地はあるが、そこまでの課題感はなかった(そもそも)ユニットテストがあるので、不具合の可能性を考慮してロジックを追うケースが少なくレビュー工数が低い。設計やコードの書き方にフォーカスしたレビューが実現できている。 ✓ iOS / Android チームよくなかった　テストもないし … すぐテストを入れられるかというと、リアーキテクチャが必要...どうしよう → 今回はアプリにフォーカスして話します 

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright©2021 Sukedachi Inc. All Right Reserved 発生した課題 3. タスクの性質や仕組み上、小さく出来ないPRが存在する → タグを付けて除外。小さくすることにこだわりすぎない。・ライブラリのアップデートなど影響範囲が大きいPR ・チームでやったことがない、根本に影響するリアーキテクチャ例：SwaggerからModelを自動生成する・リリースブランチ

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright©2021 Sukedachi Inc. All Right Reserved PRを小さくした結果わかったこと ✓ レビュー自体のクオリティも上がっている → PRが小さいので、普段指摘しないことも指摘でき、細かいミスに気づける。仮説が実感に変わった。 ✓ アーキテクチャの課題に気づける → 依存関係が大きいと変更も大きくなる。毎週大きくなったPRを振り返ることによって、アーキテクチャ上の課題がチームで共有される。

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀のサービス構造 ✓ 助太刀は2C向けのアプリや2B向けのwebサービスを展開 ✓ ビジネス的にもコード的にもモノリシックな構造 ✓ チーム構成は職能型チーム iOSチーム Androidチーム Web Frontチーム Backendチーム助太刀アプリ助太刀法人向けマッチング助太刀求人サービス BtoC BtoB CTO

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀の開発プロセス ✓ 開発生産性を上げるためにプロセスの改善をしてきた ✓ 結果として各チームで負債について考える時間が生まれたプロダクトバックログ iOSチーム Androidチーム Web Front チーム Backendチームスプリント1 スプリント2 機能A 機能B 機能C ・・・機能A 機能A 機能B 機能A 機能B 機能A’ 機能A’ 負債返済負債返済負債返済負債返済機能C

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み As is Fat View Controller Front側に多数のロジック規約のない自由なコード複雑なテーブル設計機能の責務があいまい意図しないモノリシック古いversionのFW/DB 責務毎に整理されたテーブル構造ドメイン毎に整った MS / Module 責務毎に整理されたテーブル構造ドメイン毎に整った MS / Module 依存関係が限定的最低限のロジック unitテスト To be

Slide 48

Slide 48 text

Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み長期的なリアーキテクチャ短期的なリアーキテクチャタスク内容ゴールタイムライン MSAやモジュラーモノリスなどアーキテクチャを刷新しスケーラブルなサービス基盤を構築今後の大掛かりなアーキテクチャ刷新やリファクタリングができるようにサービス毎の責務を明確にし、コードに反映サービスドメインを再定義し各ドメイン毎にマイクロサービス（or モジュール）にしていく各チームで課題を洗い出し、コードの可読性や保守性を向上させるためのリファクタリング 2~3年 ~1年

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み組み込むルールとスプリントのやり方 - 開発部の負債返済ロードマップに従って順番に開発スプリントに負債返済タスク入れる - 開発スプリントの中で、各チームで30%以上のストーリーポイントを負債返済に割り振る - スプリント内で予定より早く終わった場合、負債返済か次のタスク進めるかはPMと都度相談 ✓ 基本ルール ✓ やらないこと - 緊急のバグ対応とかじゃない限り必ず負債返済に工数を使うこと（忙しいからやらないはダメ） - 振り返らないはダメ - 自由にやって良いが、自由を履き違えないこと（やる項目変えるときはロードマップ変えて共有しましょう）

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Copyright©2021 Sukedachi Inc. All Right Reserved まとめ ✓ ここ2年くらいで開発プロセスをちゃんと整えていったらエンジニアのアウトプットが徐々に見える化 ✓ チーム構成がプロダクト別にしづらいからこそ余った工数を使えるように ✓ 余った工数で各チーム毎に技術的負債に向き合うことを開発部で決めた ✓ 負債返済ロードマップを作成し、それに沿ってリファクタなど進められる体制に ✓ CTOだけでなく開発部全体で開発生産性に向き合うことができた ✓ CTOだけでなく開発部全体で技術的負債に向き合うことができた ✓ チーム同士で思ってることや問題点などの相互理解につながった ✓ エンジニアの精神衛生的にも良い取り組みこれまでの流れ結果どうなったか

Slide 56

Slide 56 text