スクラム開発を導入し_開発生産性を最大化するまでの軌跡

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 10

Slide 10 text

Copyright©2021 Sukedachi Inc. All Right Reserved 建設業界の課題工事会社の人手不足を、マッチングと正社員採用で解決  求人掲載/ スカウト toB toC マッチング（取引先）アプローチ受注職人  工事会社  月額利用料月額利用料求人広告/スカウト応募協力会社/職人を集めたい社員を集めたい社員なりたい新しい取引先を見つけたい採用サービス（正社員）掲載/スカウト利用料（SaaS型）（アプリ課金）

Slide 11

Slide 11 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 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 27

Slide 27 text

Slide 28

Slide 28 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 29

Slide 29 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発部黎明期の開発プロセスと組織社内2名  開発組織規模  オフショア  30名  ➢ MVPの開発 > 組織作り = コード品質   ○ プロダクトを出すことを最優先  ○ ベトナムのオフショア拠点が大活躍     ➢ ウォーターフォール型開発  ○ 日本側で企画、デザインしたものを渡して開発     ➢ CPO = CEO  ○ 建設現場に詳しい代表のアイデアをプロジェクトに   ○ 続々と新しいサービスが生まれる   ウォーターフォール開発手法  主なリリース 

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発組織の改善品質 Quality 作業量 Velocity 改善速度 Delivery ❏ コミット量    ❏ チケット数    ❏ ストーリーポイント  ❏ 不具合チケット数    ❏ サービス稼働率    ❏ SLA / SLO  ❏ チケット数    ❏ デプロイ時間    ❏ リリース頻度  ➢ 作業量の定量化、品質の定量化などできていなかった  ➢ デプロイまでのリードタイムも不安定  ➢ リリースまでは数ヶ月スパン 

Slide 32

Slide 32 text

Slide 33

Slide 33 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 34

Slide 34 text

Copyright©2021 Sukedachi Inc. All Right Reserved 内製化初期の開発プロセスと組織社内6名  開発組織規模  オフショア  30名  ➢ マッチング機能以外のサービスを展開   ○ 開発は相変わらずオフショアがメイン   ○ バグ修正など一部を社内のメンバーで     ➢ 開発手法がハイブリッドに  ○ 大型の新規開発などはウォーターフォール   ○ 細かいUI改善などはアジャイルで開発   ○ Backlogでチケット管理、Sprintを区切って開発     ➢ 社内の要望などを集約できる体制に   ○ 各チームからの開発要望をまとめて精査   ○ エンジニアやデザイナーがチケットに集約   ウォーターフォール開発手法  主なリリース  アジャイル（独自スクラム）

Slide 35

Slide 35 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発プロセス内製(独自スクラム) 社内  要望を集約  優先度  を決定  EM  デザイナー  仕様書作成  EM  開発  開発者A  開発者B  ・  ・  ・  マニュアルテスト  出来たものから依頼  開発  開発  開発  開発  開発  修正  リリース  2週間で出来そうなものがリリース対象社内  修正 

Slide 36

Slide 36 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発組織の改善品質 Quality 作業量 Velocity 改善速度 Delivery ❏ コミット量    ❏ チケット数    ❏ ストーリーポイント  ❏ 不具合チケット数    ❏ サービス稼働率    ❏ SLA / SLO  ❏ チケット数    ❏ デプロイ時間    ❏ リリース頻度  ➢ 改善系タスクをアジャイルに寄せることで小さな改善ができるように  ➢ デプロイまでのリードタイムは短くなり、小さいリリースが可能に  ➢ 品質はサービス拡大につれて低下 

Slide 37

Slide 37 text

Slide 38

Slide 38 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 39

Slide 39 text

Copyright©2021 Sukedachi Inc. All Right Reserved 内製化中期の開発プロセスと組織社内10名  開発組織規模  オフショア  10名程度  ➢ 社内開発組織が拡大し開発のメインが社内に移管   ○ 採用に注力した結果、社内にエンジニアが増加   ○ バックエンドを皮切りに社内開発に切り替え   ○ オフショアはサポート    ➢ アジャイル開発の中でストーリーポイントを導入   ○ 各チケットを見積もる際にストーリーポイントを使用     ➢ 特にプロダクト品質が問題になったため改善   ○ サービス拡大に伴って意図しない不具合が多発   ○ 社内組織同士の関係性も悪化  ○ QAチームを結成し専門チームでQAを実施   ウォーターフォール開発手法  主なリリース  アジャイル（独自スクラム）

Slide 40

Slide 40 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発プロセス内製(独自スクラム) 社内  要望を集約  優先度  を決定  EM  PM  チケットアサイン  EM  開発  開発者A  開発者B  ・  ・  ・  QA  修正  リリース  2週間で出来そうなものがリリース対象開発担当者  ストーリーポイントの見積もり  開発  QAチーム  修正 

Slide 41

Slide 41 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発組織の改善品質 Quality 作業量 Velocity 改善速度 Delivery ❏ コミット量    ❏ チケット数    ❏ ストーリーポイント  ❏ 不具合チケット数    ❏ サービス稼働率    ❏ SLA / SLO  ❏ チケット数    ❏ デプロイ時間    ❏ リリース頻度  ➢ ストーリーポイントでチケット単位の作業量を定量化して管理  ➢ QAチームを入れたことでプロダクト品質が安定  ➢ QAフェーズが入ったことでリリースまでのリードタイムが増加 

Slide 42

Slide 42 text

Slide 43

Slide 43 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 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Copyright©2021 Sukedachi Inc. All Right Reserved 内製化後期の開発プロセスと組織 Planning 要件定義 / デザイン Daily Standup Refinement リリース判定 Deploy!! Development Week 1 QA Sprint Backlog Product Backlog Product Roadmap 戦略要望 Development Week 2 Retrospective Planning Sprint Backlog Product Backlog Daily Standup Retrospective Development Week 1

Slide 47

Slide 47 text

Copyright©2021 Sukedachi Inc. All Right Reserved 開発組織の改善品質 Quality 作業量 Velocity 改善速度 Delivery ❏ コミット量    ❏ チケット数    ❏ ストーリーポイント  ❏ 不具合チケット数    ❏ サービス稼働率    ❏ SLA / SLO  ❏ チケット数    ❏ デプロイ時間    ❏ リリース頻度  ➢ スクラム開発に習った開発プロセスを実施  ➢ QAチームの強化とユニットテストを入れたことで品質向上  ➢ リリース頻度を２週間とし、デプロイ作業も自動化 

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Copyright©2021 Sukedachi Inc. All Right Reserved まとめと考察 ✓ ストーリーポイントを運用することでタスクの量とその理解が向上  ✓ スクラムに習うことでチームが一体となって生産性が向上  作業量 (Velocity) 品質 (Quality) ✓ ユニットテストを開発のマスト条件にすることで整合性担保  ✓ QAチームを結成し戦力化したことでプロダクト品質が向上  改善速度 (Delivery) ✓ スクラムにQAフェーズを合わせてリリースまでのサイクルを最適化  ✓ 作業量と品質を担保した上で安定したリリースが可能に 

Slide 51

Slide 51 text

Copyright©2021 Sukedachi Inc. All Right Reserved まとめと考察組織のフェーズによって足りないところ(課題)が存在し、  それぞれがトレードオフの関係になっている。  助太刀は開発組織の成長に合わせて、課題を解決していった。    ✓ 結果として今の開発部の生産性は（助太刀史上）最大    開発組織の生産性を客観的に捉えて課題を見つけていくことが大事    課題を見つけて開発生産性を改善していきませんか？   

Slide 52

Slide 52 text