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

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

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

株式会社助太刀

July 27, 2023
Tweet

More Decks by 株式会社助太刀

Other Decks in Programming

Transcript

  1. Copyright©2021 Sukedachi Inc. All Right Reserved
    開発生産性を計測し、技術的負債返済ができ
    る開発体制を作ったお話
    株式会社助太刀 執行役員CTO 月澤拓哉

    View full-size slide

  2. Copyright©2021 Sukedachi Inc. All Right Reserved
    自己紹介

    View full-size slide

  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- 株式会社助太刀 

    View full-size slide

  4. Copyright©2021 Sukedachi Inc. All Right Reserved
    株式会社助太刀の紹介

    View full-size slide

  5. Copyright©2021 Sukedachi Inc. All Right Reserved
    建設業界の課題
    1
    業界内で高齢化が進み、
    若年層の就業者が少ない
    60代の割合が全体の4分の1を占めており、
    今後深刻な労働者不足に陥る可能性がある
    2 需要に対する慢性的な人手不足
    直近の建設投資額は増加傾向にあるのに対し、
    慢性的な人手不足となっている
    建設業界の衰退を防ぐため
    人手不足の解消が急務

    View full-size slide

  6. Copyright©2021 Sukedachi Inc. All Right Reserved
    建設業界の課題
    6
    1
    2
    職人を囲い込む慣習
    全く同じスキルを持つ職人でも、元請けを超えた
    つながりを持てていない
    仕事や人材の手配に
    ITが活用されていない
    仕事や人材を探す時は仲間からの紹介のみ、
    今だに電話連絡がメイン
    繁忙月 閑散月
    or
    受・発注者の最適な
    マッチングができていない

    View full-size slide

  7. Copyright©2021 Sukedachi Inc. All Right Reserved
    助太刀の紹介
    ❏ 提供サービス
    ○ 建設業特化の事業者マッチング
    ○ 建設業特化の求人サービス
    ❏ ユーザー数
    ○ 累計約20万事業者
    助太刀が提供するサービス
    建設業界の人手不足や人材確保の難しさ
    をITで解決するサービス

    View full-size slide

  8. Copyright©2021 Sukedachi Inc. All Right Reserved
    助太刀の紹介
    19万事業者突破!
    緊急事態
    宣言
    登録事業者数
    圧倒的No.1
    40マッチング/年
    応募率 87%
    登録事業者数
    マッチング(取引先)
    採用サービス(正社員)
    1社あたりマッチング実績
    ビジネス会員平均

    View full-size slide

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

    View full-size slide

  10. Copyright©2021 Sukedachi Inc. All Right Reserved
    ここから本題

    View full-size slide

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

    View full-size slide

  12. Copyright©2021 Sukedachi Inc. All Right Reserved
    前回デブサミ振り返り

    View full-size slide

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

    View full-size slide

  14. Copyright©2021 Sukedachi Inc. All Right Reserved
    開発生産性
    ➢ 物的生産性
    ○ 物理的にどれだけの労働力でアウトプットを出したかの指標
    ○ 物的生産性(量/人)= アウトプット量/エンジニア数
    ➢ 付加価値生産性
    ○ どれだけの労働力でどれだけの売上総利益が出たかを測る指標
    ○ 付加価値生産性(円/人)= 売上総利益/エンジニア数

    View full-size slide

  15. Copyright©2021 Sukedachi Inc. All Right Reserved
    開発生産性
    ➢ 物的生産性
    ○ 物理的にどれだけの労働力でアウトプットを出したかの指標
    ○ 物的生産性(量/人)= アウトプット量/エンジニア数
    ➢ 付加価値生産性
    ○ どれだけの労働力でどれだけの売上総利益が出たかを測る指標
    ○ 付加価値生産性(円/人)= 売上総利益/エンジニア数
    エンジニアチームで解決した課題の数

    View full-size slide

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

    1~2週間
    要件定義
 設計/開発
 テスト
 要件定義
 設計/開発
 テスト
 要件定義
 設計/開発
 テスト
 要件定義
 設計/開発
 テスト

    1~2週間 1~2週間 1~2週間

    View full-size slide

  17. Copyright©2021 Sukedachi Inc. All Right Reserved
    目指すサービス

    View full-size slide

  18. Copyright©2021 Sukedachi Inc. All Right Reserved
    目指すサービス
    人と人の繋がりを軸に
    建設業の抱えるさまざまな課題を
    多角的に解決していく
    ワンストッププラットフォームを目指す

    View full-size slide

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

    View full-size slide

  20. Copyright©2021 Sukedachi Inc. All Right Reserved
    開発組織の改善
    品質
    Quality
    作業量
    Velocity
    改善速度
    Delivery
    ❏ コミット量
    ❏ チケット数
    ❏ ストーリーポイント
    ❏ 不具合チケット数


    ❏ サービス稼働率


    ❏ SLA / SLO

    ❏ チケット数
    ❏ デプロイ時間
    ❏ リリース頻度
    開発プロセスにおいて以下の3つの観点に分け、それぞれを最大化
    開発の生産性を最大化しプロダクト品質上げてリリース早くしたい

    View full-size slide

  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名

    View full-size slide

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

    View full-size slide

  23. Copyright©2021 Sukedachi Inc. All Right Reserved
    今回のメインのお話

    View full-size slide

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

    View full-size slide

  25. Copyright©2021 Sukedachi Inc. All Right Reserved
    今回のお話
    ✓ 色々経てちゃんとしたスクラム開発に移行
    → 安定したリリースができるように
    ✓ エンジニアのタスクを定量化
    → ストーリーポイントで計測
    ✓ QAチームの組成とユニットテスト
    → プロダクト品質が保てるように
    ■ 4keysを可視化してみた
    これまで

    View full-size slide

  26. Copyright©2021 Sukedachi Inc. All Right Reserved
    今回のお話
    4keys
    デプロイの頻度
    変更のリードタイム
    変更障害率
    サービス復元時間

    View full-size slide

  27. Copyright©2021 Sukedachi Inc. All Right Reserved
    今回のお話
    4keys
    デプロイの頻度 変更のリードタイム
    変更障害率 サービス復元時間
    リードタイム上がるとデプロイ頻度も上げることが可能
    デプロイ頻度上げると小さいPRにする必要
    お互い相関

    View full-size slide

  28. Copyright©2021 Sukedachi Inc. All Right Reserved
    今回のお話
    4keys
    デプロイの頻度 変更のリードタイム
    変更障害率 サービス復元時間
    リードタイム上がるとデプロイ頻度も上げることが可能
    デプロイ頻度上げると小さいPRにする必要
    お互い相関
    リードタイム減らすと復元時間も減りそう
    細かくリリースできれば障害率減りそう

    View full-size slide

  29. Copyright©2021 Sukedachi Inc. All Right Reserved
    4keys可視化してみた

    View full-size slide

  30. Copyright©2021 Sukedachi Inc. All Right Reserved
    実際に計測してみた (2023/03/01 - 2023/03/31)
    よくない

    View full-size slide

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


    View full-size slide

  32. Copyright©2021 Sukedachi Inc. All Right Reserved
    現場の課題感
    タスクの割り方が大きいのでは?
    タスクが大きいので
    ・実装も時間かかる
    ・レビューの時間かかる
    ・レビューもすべては見きれない → 品質下がる
    → タスクを 意味のある最小単位にする必要がある

    View full-size slide

  33. Copyright©2021 Sukedachi Inc. All Right Reserved
    仮説
    レビューの
    しやすさ
    レビューの
    適切さ
    品質
    SP
    ↑ 私達がアクションすること 

    サイクルタイム分析
    フィードバック
    の速さ
    実装の速度
    PRの粒度
    ↓ モニタリングすること 

    PRを小さくすることにより、サイクルタイムを改善できる

    View full-size slide

  34. Copyright©2021 Sukedachi Inc. All Right Reserved
    実際にやったこと
    UI層
    ✓ アーキテクチャのレイヤーごとにPRを分けるようにした
    ✓ CI/CD
    ○ PRが大きくなっている場合警告を出す
    ○ 放置されているPRを定期的にSlack通知
    ✓ モニタリング → 週ごとの振り返り
    ロジック層
    API層
    それぞれの層で1PR
    (最低3PR)

    View full-size slide

  35. Copyright©2021 Sukedachi Inc. All Right Reserved
    発生した課題
    1. 心理的ハードル(管理されている感...)があり浸透しない
    → 実際に数字を共有して早くなっている(=改善している)ことを示す
    → これはあくまで指標の1つであり、健康診断として使うこと(大事)
    → 全体的に背景をちゃんと説明し、心理的に腹落ちしてもらう

    View full-size slide

  36. Copyright©2021 Sukedachi Inc. All Right Reserved
    発生した課題
    2. PRを小さくし始めたはいいが、SPの1が増えすぎてベロシティが急増してしまう
    → 基準を適宜見直し

    View full-size slide

  37. Copyright©2021 Sukedachi Inc. All Right Reserved
    発生した課題
    2. PRを小さくし始めたはいいが、SPの1が増えすぎてベロシティが急増してしまう
    → 基準を適宜見直し

    View full-size slide

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

    View full-size slide

  39. Copyright©2021 Sukedachi Inc. All Right Reserved
    結果:サイクルタイム分析 (2023/06/01 - 2023/06/30)
    良くなった!

    View full-size slide

  40. Copyright©2021 Sukedachi Inc. All Right Reserved
    比較
    1PRがマージされる時間が、200時間以上削減された

    View full-size slide

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

    View full-size slide

  42. Copyright©2021 Sukedachi Inc. All Right Reserved
    生産性上がったので
    技術的負債に取り組んでみた

    View full-size slide

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

    View full-size slide

  44. Copyright©2021 Sukedachi Inc. All Right Reserved
    今回のお話(再掲)
    4keys
    デプロイの頻度 変更のリードタイム
    変更障害率 サービス復元時間
    リードタイム上がるとデプロイ頻度も上げることが可能
    デプロイ頻度上げると小さいPRにする必要
    お互い相関
    リードタイム減らすと復元時間も減りそう
    細かくリリースできれば障害率減りそう

    View full-size slide

  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

    View full-size slide

  46. Copyright©2021 Sukedachi Inc. All Right Reserved
    技術的負債への取り組み
    As is
    Fat View Controller
    Front側に多数のロジック 規約のない自由なコード
    複雑なテーブル設計
    機能の責務があいまい 意図しないモノリシック
    古いversionのFW/DB

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  50. Copyright©2021 Sukedachi Inc. All Right Reserved
    技術的負債への取り組み
    各チーム毎の課題の洗い出し/整理
    ✓ クラス設計だったり使用するライブラリだったりいろんな観点でとりあえず
    出してもらう
    ✓ 各チーム内で優先度を決めてロードマップ(仮)に落とし込んでいく
    ✓ 一旦自分たちのチームでやりたいことだけ書く

    View full-size slide

  51. Copyright©2021 Sukedachi Inc. All Right Reserved
    技術的負債への取り組み
    開発部全体で負債返済のロードマップを作成
    ✓ 他のチームの開発や機能自体に影響がある項目は関連するチームで議論
    ✓ すごくざっくりと着手する順番だけ決める(チーム単位、タスク単位)
    ✓ 全チームで重要度などの認識合わせ

    View full-size slide

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

    View full-size slide

  53. Copyright©2021 Sukedachi Inc. All Right Reserved
    技術的負債への取り組み

    View full-size slide

  54. Copyright©2021 Sukedachi Inc. All Right Reserved
    まとめ

    View full-size slide

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

    View full-size slide

  56. Copyright©2021 Sukedachi Inc. All Right Reserved
    ちょっとした告知
    エンジニア向けのMeetupを開催予定です!
    日時:9月7日(木)19:00~20:30
    「CTOが語る、プロダクト開発と組織づくり」
    お申し込みはこちら

    View full-size slide