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

Copyright©2021 Sukedachi Inc. All Right Reserved
スクラム開発を導入し
開発生産性を最大化するまでの軌跡
株式会社助太刀執行役員CTO 月澤拓哉

View Slide

今日話すこと
● 自己紹介 
 
● 助太刀の会社/事業紹介 
 
● 建設業界の問題 
 
● 助太刀開発部にあった課題 
 
● 開発プロセスをアップデートしてきた歴史 
 
● まとめと考察 

View Slide

自己紹介

View Slide

自己紹介
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- 株式会社助太刀　

View Slide

株式会社助太刀の紹介

View Slide

株式会社助太刀の紹介
❏ 職人さんと工事会社の事業者マッチング 
❏ 建設業の正社員求人サービス 
❏ 2017年創業 
❏ 累計18万事業者 
❏ 累計約40億の資金調達済み 
助太刀が提供するサービス
建設業界の人手不足や人材確保の難しさ
をITで解決するサービス

View Slide

建設業界の課題

View Slide

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

View Slide

9
9
1
2 職人を囲い込む慣習
全く同じスキルを持つ職人でも、元請けを超えたつな
がりを持てていない
仕事や人材の手配に
ITが活用されていない
仕事や人材を探す時は仲間からの紹介のみ、
今だに電話連絡がメイン
忙しい時と暇な時の波が大きく、経営が安定しない。
繁忙月閑散月
or
受・発注者の最適な
マッチングができていない

View Slide

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

View Slide

本題

View Slide

話すこと要約
✓ 創業当初のオフショア開発メインから内製開発に切り替えてきました 
 
✓ その中で開発部のアウトプットを（できる限り）最大化しようと試行錯誤してきまし
た 
 
✓ 今日はこれまでの試行錯誤の結果を組織のフェーズ毎に分けてお話ししようと
思います 

View Slide

助太刀開発部にあった課題

View Slide

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

View Slide

助太刀の目指すサービス

View Slide

助太刀の目指すサービス
人と人の繋がりを軸に 
建設業の抱えるさまざまな課題を 
多角的に解決していく 
ワンストッププラットフォームを目指す 

View Slide

助太刀開発部の課題
❌ 不具合が多い
○ クリティカルなバグが本番で起きる
❌ 開発のリードタイムが長い
○ 開発終わるまで大きいと数ヶ月とか
❌ デプロイ頻度が少ない
○ 数ヶ月に1度程度
❌ プロダクトロードマップがない
○ 次の優先順位がわからない
理想
1~2週 / リリース
SLO99.9%
エンジニアが
Whyを十分理解
した上で開発

View Slide

開発生産性
➢ 物的生産性
○ 物理的にどれだけの労働力でアウトプットを出したかの指標
○ 物的生産性（量／人）＝アウトプット量／エンジニア数
➢ 付加価値生産性
○ どれだけの労働力でどれだけの売上総利益が出たかを測る指標
○ 付加価値生産性（円／人）＝売上総利益／エンジニア数

View Slide

開発生産性
➢ 物的生産性
エンジニアチームで解決した課題の数 

View Slide

開発生産性
➢ 物的生産性
現実 
理想 
2~3ヶ月 2~3ヶ月
要件定義  設計  開発  テスト  要件定義  設計  開発  テスト 
1~2週間
要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  要件定義  設計/開発  テスト 
1~2週間 1~2週間 1~2週間

View Slide

開発生産性
➢ 物的生産性
現実 
理想 
2~3ヶ月 2~3ヶ月
要件定義  設計  開発  テスト  要件定義  設計  開発  テスト 
1~2週間
要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  要件定義  設計/開発  テスト  要件定義  設計/開発  テスト 
1~2週間 1~2週間 1~2週間
❏ できるだけ短い間隔で改善し続けたい
 
❏ 同期間における課題解決数を最大化したい
 
❏ より品質の高いプロダクトを出していきたい
 

View Slide

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

View Slide

助太刀開発部の歴史

View Slide

助太刀のこれまでのリリース

View Slide

助太刀の開発組織変遷
① 開発をほぼ全てオフショア会社でやってもらってた時期。速度とリリース優先。
② 初めて社内エンジニアでプロダクト改善。開発の内製化に着手。
③ 開発の内製化が進み、開発プロセスなどの効率化を本格的に目指した時期。
④ 開発プロセスもプロダクト品質もこれまでで一番安定した時期。

View Slide

開発手法
ウォーターフォール
アジャイル（独自スクラム）
スクラム
社内人数
規模
2名 4名 10名 24名
社内開発
チケット数
0 34 439 962 2168
テスト
リリース頻度
1人
エンジニアエンジニア
デザイナー
エンジニア
デザイナー
エンジニア
ビジネス
デザイナー
QAチーム
ユニットテスト
2~3ヶ月に1度
不定期
2週間~2ヶ月に1度
不定期
不定期
1ヶ月に1度程度
不定期
2週間に1度
6名

View Slide

開発部黎明期

View Slide

開発手法
スクラム
社内人数
規模
2名 4名 10名 24名
社内開発
チケット数
0 34 439 962 2168
テスト
リリース頻度
1人
デザイナー
エンジニア
デザイナー
エンジニア
ビジネス
デザイナー
QAチーム
2~3ヶ月に1度
不定期
不定期
不定期
不定期
2週間に1度
6名

View Slide

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

View Slide

開発プロセス
CEO 
プロジェクト 
担当者 
社内 
開発担当者 
要件検討 
オフショア 
社内 
開発担当者 
仕様書作成 
開発 
マニュアルテスト
 
1ヶ月 
1.5ヶ月 
2,3ヶ月 
0.5ヶ月 
リリース 

View Slide

品質
Quality
作業量
Velocity
改善速度
Delivery
 
 
 
 
❏ SLA / SLO 
 
 
➢ 作業量の定量化、品質の定量化などできていなかった 
➢ デプロイまでのリードタイムも不安定 
➢ リリースまでは数ヶ月スパン 

View Slide

内製化初期

View Slide

開発手法
スクラム
社内人数
規模
2名 4名 10名 24名
社内開発
チケット数
0 34 439 962 2168
テスト
リリース頻度
1人
デザイナー
エンジニア
デザイナー
エンジニア
ビジネス
デザイナー
QAチーム
2~3ヶ月に1度
不定期
不定期
不定期
不定期
2週間に1度
6名

View Slide

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

View Slide

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

View Slide

品質
Quality
作業量
Velocity
改善速度
Delivery
 
 
 
 
❏ SLA / SLO 
 
 
➢ 改善系タスクをアジャイルに寄せることで小さな改善ができるように 
➢ デプロイまでのリードタイムは短くなり、小さいリリースが可能に 
➢ 品質はサービス拡大につれて低下 

View Slide

内製化中期

View Slide

開発手法
スクラム
社内人数
規模
2名 4名 10名 24名
社内開発
チケット数
0 34 439 962 2168
テスト
リリース頻度
1人
デザイナー
エンジニア
デザイナー
エンジニア
ビジネス
デザイナー
QAチーム
2~3ヶ月に1度
不定期
不定期
不定期
不定期
2週間に1度
6名

View Slide

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

View Slide

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

View Slide

品質
Quality
作業量
Velocity
改善速度
Delivery
 
 
 
 
❏ SLA / SLO 
 
 
➢ ストーリーポイントでチケット単位の作業量を定量化して管理 
➢ QAチームを入れたことでプロダクト品質が安定 
➢ QAフェーズが入ったことでリリースまでのリードタイムが増加 

View Slide

内製化後期

View Slide

開発手法
スクラム
社内人数
規模
2名 4名 10名 24名
社内開発
チケット数
0 34 439 962 2168
テスト
リリース頻度
1人
デザイナー
エンジニア
デザイナー
エンジニア
ビジネス
デザイナー
QAチーム
2~3ヶ月に1度
不定期
不定期
不定期
不定期
2週間に1度
6名

View Slide

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

View Slide

CTO 
Backend 
Frontend 
iOS  Android 
4名 4名 4名
QA  Designer 
2名
4名
Web 
1名
1名 1名 1名 1名
R&D 
1名

View Slide

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

View Slide

品質
Quality
作業量
Velocity
改善速度
Delivery
 
 
 
 
❏ SLA / SLO 
 
 
➢ スクラム開発に習った開発プロセスを実施 
➢ QAチームの強化とユニットテストを入れたことで品質向上 
➢ リリース頻度を２週間とし、デプロイ作業も自動化 

View Slide

まとめと考察

View Slide

まとめと考察
✓ 社内開発組織の人数が倍々で成長 
 
✓ 開発完了チケット数も人数比に合わせて倍増 
 
✓ プロダクト品質もSLO99.9%を維持できるように 
 
✓ リリース頻度も2週間毎にリリースできるように 
現在までの流れ

View Slide

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

View Slide

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

View Slide

ちょっとした宣伝
日時：3月7日(火)19:00~20:30
「CTOが語る、プロダクト開発と組織づくり」
エンジニア向けのMeetupを開催予定です！
お申し込みはこちら

View Slide

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

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

株式会社助太刀
PRO

Other Decks in Programming

Featured

Transcript

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

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

株式会社助太刀 PRO

Other Decks in Programming

Featured

Transcript

株式会社助太刀
PRO