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

Transcript

1. Copyright©2021 Sukedachi Inc. All Right Reserved 開発生産性を計測し、技術的負債返済ができ る開発体制を作ったお話 株式会社助太刀 執行役員CTO 月澤拓哉
2. Copyright©2021 Sukedachi Inc. All Right Reserved 自己紹介
3. 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- 株式会社助太刀　
4. Copyright©2021 Sukedachi Inc. All Right Reserved 株式会社助太刀の紹介
5. Copyright©2021 Sukedachi Inc. All Right Reserved 建設業界の課題 1 業界内で高齢化が進み、 若年層の就業者が少ない 60代の割合が全体の４分の１を占めており、 今後深刻な労働者不足に陥る可能性がある 2 需要に対する慢性的な人手不足 直近の建設投資額は増加傾向にあるのに対し、 慢性的な人手不足となっている 建設業界の衰退を防ぐため 人手不足の解消が急務
6. Copyright©2021 Sukedachi Inc. All Right Reserved 建設業界の課題 6 1 2 職人を囲い込む慣習 全く同じスキルを持つ職人でも、元請けを超えた つながりを持てていない 仕事や人材の手配に ITが活用されていない 仕事や人材を探す時は仲間からの紹介のみ、 今だに電話連絡がメイン 繁忙月 閑散月 or 受・発注者の最適な マッチングができていない
7. Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀の紹介 ❏ 提供サービス ◦ 建設業特化の事業者マッチング ◦ 建設業特化の求人サービス ❏ ユーザー数 ◦ 累計約20万事業者 助太刀が提供するサービス 建設業界の人手不足や人材確保の難しさ をITで解決するサービス
8. Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀の紹介 19万事業者突破！ 緊急事態 宣言 登録事業者数 圧倒的No.1 40マッチング/年 応募率 87% 登録事業者数 マッチング（取引先） 採用サービス（正社員） 1社あたりマッチング実績 ビジネス会員平均
9. Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀の紹介 行政との連携 国土交通省が主催する「令和2年度i-Construction大賞」 において国土交通大臣賞(最優秀賞)を受賞 国交省主導の建設キャリアアップシステム（CCUS）と連携 ESG経営の推進 サステナビリティサイトを公開 https://suke-dachi.jp/company/esg/index.html ESG・サステナビリティ投資家からの評価と参画 経済産業省が推進する「J-Startup企業」に選定
10. Copyright©2021 Sukedachi Inc. All Right Reserved ここから本題
11. Copyright©2021 Sukedachi Inc. All Right Reserved 本セッションで話すこと ◦ 助太刀は今まで開発プロセスの改善に取り組んできた（前回デブサミ2023） ◦ スクラムを導入し体系的に開発するサイクルは構築できた ◦ エンジニア単体やチーム単位での生産性は可視化がイマイチだった ✓ SPとかSLOだけでなく、4keysも並行して測ってみた ✓ 4keysを最適化できるような動きをチームでやってみた ✓ 開発生産性をより解像度高く可視化できた ✓ 効率化することで技術負債返済に時間を使えるようになった 今年初めまでの取り組み 今回取り組んでみたこと
12. Copyright©2021 Sukedachi Inc. All Right Reserved 前回デブサミ振り返り
13. Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀開発部にあった課題 ❌ 不具合が多い ◦ クリティカルなバグが本番で起きる ❌ 開発のリードタイムが長い ◦ 開発終わるまで大きいと数ヶ月とか ❌ デプロイ頻度が少ない ◦ 数ヶ月に1度程度 ❌ プロダクトロードマップがない ◦ 次の優先順位がわからない
14. Copyright©2021 Sukedachi Inc. All Right Reserved 開発生産性 ➢ 物的生産性 ◦ 物理的にどれだけの労働力でアウトプットを出したかの指標 ◦ 物的生産性（量／人）＝ アウトプット量／エンジニア数 ➢ 付加価値生産性 ◦ どれだけの労働力でどれだけの売上総利益が出たかを測る指標 ◦ 付加価値生産性（円／人）＝ 売上総利益／エンジニア数
15. Copyright©2021 Sukedachi Inc. All Right Reserved 開発生産性 ➢ 物的生産性 ◦ 物理的にどれだけの労働力でアウトプットを出したかの指標 ◦ 物的生産性（量／人）＝ アウトプット量／エンジニア数 ➢ 付加価値生産性 ◦ どれだけの労働力でどれだけの売上総利益が出たかを測る指標 ◦ 付加価値生産性（円／人）＝ 売上総利益／エンジニア数 エンジニアチームで解決した課題の数
16. Copyright©2021 Sukedachi Inc. All Right Reserved 開発生産性 ➢ 物的生産性 ◦ 物理的にどれだけの労働力でアウトプットを出したかの指標 ◦ 物的生産性（量／人）＝ アウトプット量／エンジニア数 ➢ 付加価値生産性 ◦ どれだけの労働力でどれだけの売上総利益が出たかを測る指標 ◦ 付加価値生産性（円／人）＝ 売上総利益／エンジニア数 現実 理想 2~3ヶ月 2~3ヶ月 要件定義 設計
 開発
 テスト
 要件定義
 設計
 開発
 テスト
 1~2週間 要件定義
 設計/開発
 テスト
 要件定義
 設計/開発
 テスト
 要件定義
 設計/開発
 テスト
 要件定義
 設計/開発
 テスト
 1~2週間 1~2週間 1~2週間
17. Copyright©2021 Sukedachi Inc. All Right Reserved 目指すサービス
18. Copyright©2021 Sukedachi Inc. All Right Reserved 目指すサービス 人と人の繋がりを軸に 建設業の抱えるさまざまな課題を 多角的に解決していく ワンストッププラットフォームを目指す
19. Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀にあった課題 ❌ 不具合が多い ◦ クリティカルなバグが本番で起きる ❌ 開発のリードタイムが長い ◦ 開発終わるまで大きいと数ヶ月とか ❌ デプロイ頻度が少ない ◦ 数ヶ月に1度程度 ❌ プロダクトロードマップがない ◦ 次の優先順位がわからない 開発生産性UP 目指す 不具合↓ リードタイム↓ デプロイ頻度↑ ＝
20. Copyright©2021 Sukedachi Inc. All Right Reserved 開発組織の改善 品質 Quality 作業量 Velocity 改善速度 Delivery ❏ コミット量 ❏ チケット数 ❏ ストーリーポイント ❏ 不具合チケット数
 
 ❏ サービス稼働率
 
 ❏ SLA / SLO
 ❏ チケット数 ❏ デプロイ時間 ❏ リリース頻度 開発プロセスにおいて以下の３つの観点に分け、それぞれを最大化 開発の生産性を最大化しプロダクト品質上げてリリース早くしたい
21. 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名
22. Copyright©2021 Sukedachi Inc. All Right Reserved 開発プロセス（2023年初） 社内24名 開発組織規模 オフショア 2~4名 ➢ 開発プロジェクトを完全に内製化 ◦ オフショアは基本サポート ➢ スクラム開発を導入 ◦ 2週間のSprintでアウトプットを出せるように ◦ 全員がSprintイベントに参加することで事業理解UP ➢ ストーリーポイントを導入 ◦ 各チケットを見積もる際にストーリーポイントを使用 ➢ QAチームの結成 + 戦力増強 ◦ Sprintの開発サイクルに合わせて高品質なQAを実施 ◦ 社内の不具合率の可視化やSLOの策定なども可能に ➢ ユニットテストをしっかり書く文化に ◦ バックエンドから始め、フロント側にも波及 開発手法 主なリリース スクラム
23. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のメインのお話
24. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話 ✓ 色々経てちゃんとしたスクラム開発に移行 → 安定したリリースができるように ✓ エンジニアのタスクを定量化 → ストーリーポイントで計測 ✓ QAチームの組成とユニットテスト → プロダクト品質が保てるように これまで ❏ さらに開発生産性を上げていきた ❏ 組織の拡大に耐えられるように ❏ 他の可視化/定量化手法は？
25. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話 ✓ 色々経てちゃんとしたスクラム開発に移行 → 安定したリリースができるように ✓ エンジニアのタスクを定量化 → ストーリーポイントで計測 ✓ QAチームの組成とユニットテスト → プロダクト品質が保てるように ▪ 4keysを可視化してみた これまで
26. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話 4keys デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間
27. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話 4keys デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 リードタイム上がるとデプロイ頻度も上げることが可能 デプロイ頻度上げると小さいPRにする必要 お互い相関
28. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話 4keys デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 リードタイム上がるとデプロイ頻度も上げることが可能 デプロイ頻度上げると小さいPRにする必要 お互い相関 リードタイム減らすと復元時間も減りそう 細かくリリースできれば障害率減りそう
29. Copyright©2021 Sukedachi Inc. All Right Reserved 4keys可視化してみた
30. Copyright©2021 Sukedachi Inc. All Right Reserved 実際に計測してみた (2023/03/01 - 2023/03/31) よくない
31. Copyright©2021 Sukedachi Inc. All Right Reserved 実際に計測してみた 結果 ✓ Backend チーム 改善の余地はあるが、そこまでの課題感はなかった(そもそも)ユニットテストがあるので、不具合の可能性を考慮して ロジックを追うケースが少なくレビュー工数が低い。設計やコードの書き方にフォーカスしたレビューが実現できてい る。 ✓ iOS / Android チーム よくなかった　テストもないし … すぐテストを入れられるかというと、リアーキテクチャが必要...どうしよう → 今回はアプリにフォーカスして話します

32. Copyright©2021 Sukedachi Inc. All Right Reserved 現場の課題感 タスクの割り方が大きいのでは？ タスクが大きいので ・実装も時間かかる ・レビューの時間かかる ・レビューもすべては見きれない → 品質下がる → タスクを 意味のある最小単位にする必要がある
33. Copyright©2021 Sukedachi Inc. All Right Reserved 仮説 レビューの しやすさ レビューの 適切さ 品質 SP ↑ 私達がアクションすること 
 サイクルタイム分析 フィードバック の速さ 実装の速度 PRの粒度 ↓ モニタリングすること 
 PRを小さくすることにより、サイクルタイムを改善できる
34. Copyright©2021 Sukedachi Inc. All Right Reserved 実際にやったこと UI層 ✓ アーキテクチャのレイヤーごとにPRを分けるようにした ✓ CI/CD ◦ PRが大きくなっている場合警告を出す ◦ 放置されているPRを定期的にSlack通知 ✓ モニタリング → 週ごとの振り返り ロジック層 API層 それぞれの層で1PR (最低3PR)
35. Copyright©2021 Sukedachi Inc. All Right Reserved 発生した課題 1. 心理的ハードル(管理されている感...)があり浸透しない → 実際に数字を共有して早くなっている(=改善している)ことを示す → これはあくまで指標の1つであり、健康診断として使うこと(大事) → 全体的に背景をちゃんと説明し、心理的に腹落ちしてもらう
36. Copyright©2021 Sukedachi Inc. All Right Reserved 発生した課題 2. PRを小さくし始めたはいいが、SPの1が増えすぎてベロシティが急増してしまう → 基準を適宜見直し
37. Copyright©2021 Sukedachi Inc. All Right Reserved 発生した課題 2. PRを小さくし始めたはいいが、SPの1が増えすぎてベロシティが急増してしまう → 基準を適宜見直し
38. Copyright©2021 Sukedachi Inc. All Right Reserved 発生した課題 3. タスクの性質や仕組み上、小さく出来ないPRが存在する → タグを付けて除外。小さくすることにこだわりすぎない。 ・ライブラリのアップデートなど影響範囲が大きいPR ・チームでやったことがない、根本に影響するリアーキテクチャ 例：SwaggerからModelを自動生成する ・リリースブランチ
39. Copyright©2021 Sukedachi Inc. All Right Reserved 結果：サイクルタイム分析 (2023/06/01 - 2023/06/30) 良くなった！
40. Copyright©2021 Sukedachi Inc. All Right Reserved 比較 1PRがマージされる時間が、200時間以上削減された
41. Copyright©2021 Sukedachi Inc. All Right Reserved PRを小さくした結果わかったこと ✓ レビュー自体のクオリティも上がっている → PRが小さいので、普段指摘しないことも指摘でき、細かいミスに気づ ける。仮説が実感に変わった。 ✓ アーキテクチャの課題に気づける → 依存関係が大きいと変更も大きくなる。毎週大きくなったPRを振り返 ることによって、アーキテクチャ上の課題がチームで共有される。
42. Copyright©2021 Sukedachi Inc. All Right Reserved 生産性上がったので 技術的負債に取り組んでみた
43. Copyright©2021 Sukedachi Inc. All Right Reserved 助太刀のサービス構造 ✓ 助太刀は2C向けのアプリや2B向けのwebサービスを展開 ✓ ビジネス的にもコード的にもモノリシックな構造 ✓ チーム構成は職能型チーム iOSチーム Androidチーム Web Frontチーム Backendチーム 助太刀アプリ 助太刀法人向けマッチング 助太刀求人サービス BtoC BtoB CTO
44. Copyright©2021 Sukedachi Inc. All Right Reserved 今回のお話（再掲） 4keys デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 リードタイム上がるとデプロイ頻度も上げることが可能 デプロイ頻度上げると小さいPRにする必要 お互い相関 リードタイム減らすと復元時間も減りそう 細かくリリースできれば障害率減りそう
45. 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
46. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み As is Fat View Controller Front側に多数のロジック 規約のない自由なコード 複雑なテーブル設計 機能の責務があいまい 意図しないモノリシック 古いversionのFW/DB
47. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み As is Fat View Controller Front側に多数のロジック 規約のない自由なコード 複雑なテーブル設計 機能の責務があいまい 意図しないモノリシック 古いversionのFW/DB 責務毎に整理された テーブル構造 ドメイン毎に整った MS / Module 責務毎に整理された テーブル構造 ドメイン毎に整った MS / Module 依存関係が限定的 最低限のロジック unitテスト To be
48. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み 長期的な リアーキテクチャ 短期的な リアーキテクチャ タスク内容 ゴール タイムライン MSAやモジュラーモノリスなど アーキテクチャを刷新しスケーラブルな サービス基盤を構築 今後の大掛かりなアーキテクチャ刷新や リファクタリングができるようにサービス 毎の責務を明確にし、コードに反映 サービスドメインを再定義し 各ドメイン毎にマイクロサービス （or モジュール）にしていく 各チームで課題を洗い出し、 コードの可読性や保守性を向上 させるためのリファクタリング 2~3年 ~1年
49. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み 長期的な リアーキテクチャ 短期的な リアーキテクチャ タスク内容 ゴール タイムライン MSAやモジュラーモノリスなど アーキテクチャを刷新しスケーラブルな サービス基盤を構築 今後の大掛かりなアーキテクチャ刷新や リファクタリングができるようにサービス 毎の責務を明確にし、コードに反映 サービスドメインを再定義し 各ドメイン毎にマイクロサービス （or モジュール）にしていく 各チームで課題を洗い出し、 コードの可読性や保守性を向上 させるためのリファクタリング 2~3年 ~1年
50. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み 各チーム毎の課題の洗い出し/整理 ✓ クラス設計だったり使用するライブラリだったりいろんな観点でとりあえず 出してもらう ✓ 各チーム内で優先度を決めてロードマップ（仮）に落とし込んでいく ✓ 一旦自分たちのチームでやりたいことだけ書く
51. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み 開発部全体で負債返済のロードマップを作成 ✓ 他のチームの開発や機能自体に影響がある項目は関連するチームで議論 ✓ すごくざっくりと着手する順番だけ決める（チーム単位、タスク単位） ✓ 全チームで重要度などの認識合わせ
52. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み 組み込むルールとスプリントのやり方 - 開発部の負債返済ロードマップに従って順番に開発スプリントに負債返済タスク入れる - 開発スプリントの中で、各チームで30%以上のストーリーポイントを負債返済に割り振る - スプリント内で予定より早く終わった場合、負債返済か次のタスク進めるかはPMと都度相談 ✓ 基本ルール ✓ やらないこと - 緊急のバグ対応とかじゃない限り必ず負債返済に工数を使うこと（忙しいからやらないはダメ） - 振り返らないはダメ - 自由にやって良いが、自由を履き違えないこと（やる項目変えるときはロードマップ変えて共有し ましょう）
53. Copyright©2021 Sukedachi Inc. All Right Reserved 技術的負債への取り組み
54. Copyright©2021 Sukedachi Inc. All Right Reserved まとめ
55. Copyright©2021 Sukedachi Inc. All Right Reserved まとめ ✓ ここ2年くらいで開発プロセスをちゃんと整えていったらエンジニアのア ウトプットが徐々に見える化 ✓ チーム構成がプロダクト別にしづらいからこそ余った工数を使えるように ✓ 余った工数で各チーム毎に技術的負債に向き合うことを開発部で決めた ✓ 負債返済ロードマップを作成し、それに沿ってリファクタなど進められる 体制に ✓ CTOだけでなく開発部全体で開発生産性に向き合うことができた ✓ CTOだけでなく開発部全体で技術的負債に向き合うことができた ✓ チーム同士で思ってることや問題点などの相互理解につながった ✓ エンジニアの精神衛生的にも良い取り組み これまでの流れ 結果どうなったか
56. Copyright©2021 Sukedachi Inc. All Right Reserved ちょっとした告知 エンジニア向けのMeetupを開催予定です！ 日時：9月７日(木)19:00~20:30 「CTOが語る、プロダクト開発と組織づくり」 お申し込みはこちら