数字と感情で語る スクラム導入効果 「楽楽勤怠」開発チームの変革の軌跡 楽楽勤怠開発部 開発1課　加藤 祐也 

登壇者紹介 2
 楽楽勤怠開発部 開発1課 加藤 祐也 ● 新卒で自社ERP開発会社に入社。 ○ 人事・給与・勤怠などHR系のシステム開発に10年近く携わる。 ○ エンジニア・プロジェクトマネジメントなどを経験 ● 2020年に転職サイト・転職エージェント会社に転職。 ○ 求人案件、候補者の紹介、ダイレクトソーシング等のシステムに携わる ○ スクラムマスターとしてアジャイル開発を初めて経験する ● 2023年2月にラクスに入社 ○ 楽楽勤怠のプロジェクト・組織マネジメントに従事 

楽楽勤怠とは？ 勤怠管理・給与計算を楽にするクラウド型の勤怠管理システム 3
 

本日のテーマ 4
 数字と感情で語るスクラム導入効果 「楽楽勤怠」開発チームの変革の軌跡 ラクスでは「ウォーターフォール型開発」が主流ですが、 楽楽勤怠は開発プロセスを刷新し「アジャイル（スクラム開発）」を採用しました。 なぜ開発プロセスを刷新したのか 定量・定性面でどのような効果が出たのか 成功させるために必要なことは何か。 具体的な成果・エンジニアの声も交えつつ、チーム変革の軌跡をお伝えしていきます。 

目次 5
 ● 開発プロセス刷新の背景 ● 楽楽勤怠としての導入 ● 導入の成果・エンジニアの声 ● 失敗事例・現状の課題 ● 今後の展望 ● 開発プロセス刷新から学んだこと 

開発プロセス刷新の背景 

マーケット・プロダクトの状況 7
 シェア1位の企業でも17%程。 圧倒的なマーケットリーダーはおらず 群雄割拠。 マーケットリーダー不在 市場の成長 システム未導入企業の減少 働き方改革の追い風を受け市場成長 率は年16%。(FY22→FY26) システム化は加速。未導入企業は 44.5％→33.1%まで急速に減少 (FY21→FY23) プロダクト特性 勤怠管理システムは労働基準法に準 拠する必要がある。 競合との機能差異が出づらい 市 場 ・ 製 品 

取るべき事業戦略とは？ 8
 ● システム未導入企業にいち早くアプローチしシェア拡大 ● 製品力を高め、競合優位性を獲得する ● 継続的かつ高品質なアップデートで満足度・信頼感を高め、他システムへの 離脱を防止する ● 競合からのリプレイスを視野にした機能追加、移行負荷軽減に寄与する仕 組み 事業 戦略 楽楽勤怠は勤怠管理サービスとしては後発であり、 トップシェアの企業とは数倍の差が開いていた 

開発としてやるべきことは？ 9
 開発スピードアップ・ボリュームのアップが必須 ラクスでは「ウォーターフォール型」の開発手法を採用しているプロダクトもあるが、楽楽勤怠では開 発スピード・ボリュームを向上させ、早期にシェアを拡大する必要があった。 アジャイル（スクラム）開発の導入 最終的には市場シェアＮｏ．１を目指す 

楽楽勤怠での導入・運用方法 

導入に至るまで 11
 導入のハードルになること・決めておくべきことを洗い出し 組織構成・役割・マインド・スケジュール・ルール・目標への影響・メンバー教育など 導入するに当たり、課題となりうることを予め洗い出し、議論をしておいた 

導入に至るまで 12
 まずは1チームから試験導入→改善を繰り返し拡大 試験導入 ラクスのリーダーシッププリンプルにもある「小さく試して大きく育てる」を意識して導入。 試験導入→課題の洗い出し→改善…を繰り返し、他チームにも展開していった。 組織運営も「アジャイル方式」を意識し、組織に徐々に根付かせていった 改善を繰り返す 拡大 

楽楽勤怠としての導入（チーム体制） 13
 ● PO(プロダクトオーナー） ○ プロダクトの責任者 ○ プロダクトバックログの管理 ○ ステークホルダーとの折衝交渉 ● SM(スクラムマスター） ○ PO・開発チームの支援 ○ 開発の障害・課題を取り除く ○ スクラム開発がうまく機能するようにプロセス促進 ● 開発チーム ○ 成果物を完成させることに責任を持つ ○ 自己組織化・機能横断的なチーム ○ 開発手法・進め方に責任を持つ ステークホルダー 企画/CS/営業 

楽楽勤怠としての導入（リリースサイクル） 14
 開発 社内 本番 短期 週１回 月１回 長期 週１回 週１回 リリースサイクルは顧客影響も鑑みながら段階的に変えていく 

「レトロスペクティブ」を有効活用し細かな課題を少しずつ改善 15
 KPT形式でスプリントを振り返り→改善を繰り返す メンバー全員でレトロスペクティブまでにKPTを記入しておいてもらう。 レトロスペクティブの場では、特に共通した課題をメインに議論し、改善策を検討する 

開発プロセス刷新の成果 

開発プロセス刷新の成果（リリース案件数） 17
 ● 2024年5月のスクラム開発の導入以降、リリース案件数は大幅に増加している。 ● 開発スピードのアップ＋案件の細分化の成果が表れている →スクラム開発導入 

開発プロセス刷新の成果（受注件数） 18
 ● 受注件数も過去最高を記録。ビジネス戦略＋開発戦略がうまくマッチしている証拠 ● 案件ごとに効果を明確にし、ビジネス側で「今まさにほしいもの」をスピーディーに開発 

開発プロセス刷新の成果（エンジニアの満足度・定性面） 19
 8pt 10pt中 現在のスクラム開発に対する満足度を教え てください ウォーターフォール開発に戻りたいと思い ますか？ 

開発プロセス刷新の成果（エンジニアの満足度・定性面） 20
 スクラムの効果として実感している項目を選択してください（複数選択可） 

開発プロセス刷新の成果（エンジニアの満足度・定性面） 21
 スクラム開発を導入する上で注意するポイント、戸惑ったポイントがあれば教えてください。 ● 開発に対する前向きなマインドが必須。失敗を恐れず積極的な変化や発信をしていく必要があ る。このマインドがないと間違いなくうまくいかないと思う。 ● チーム内の雰囲気が気軽に話せることが重要だと思います。 ● スクラム開発に変わって、個人的に最初は少しきついですが、少し時間を立てって適応できまし た。 ● ステークホルダーが多く、要件がなかなか決まらない組織だとキツイ。事業部門とも価値観・プ ロセスの合意を得て、プロダクト関係者が一体となって進めていくことが必要。 プロセスの導入だけでなく、価値観・マインドの醸成が大切 

失敗事例・現状の課題 

初めのうちは「失敗」も多く経験してきた 23
 設計 開発 テスト 設計 開発 テスト リリース 受入 ウォーターフォール開発をスプリントの区切りでやるだけ プロダクトバックログが大きすぎる、要求・プログラムを分割できない 

現状の課題(開発スピードと品質の両立） 24
 ● スピード：リリース案件数は頭打ちの感が出てきた。さらなるスピードアップが必要 ● 品質：リリース件数は大幅に増加したが、マイナーリリースも定期的に発生させてしまっている 

今後の展望 

今後の展望①：上流・下流プロセスの改善 26
 上流プロセスは事業部を巻き込んだ改善を実施、下流プロセスは自動化を推進 企画 要件 設計 開発 テスト レビュー 準備 リリース 要件の細分化 1週間単位で価値提供できるサイ ズまで要件の細分化・優先度判断 を行う 事業部PMM 開発 事業サイドを巻き込んだ開発 事業サイドにも1週間単位でレ ビューに参加してもらい迅速な フィードバックを得る 自動化の推進 準備：リリース資材作成の自動化、 GitHub Actionsの活用 リリース：ansible(サーバーの設定管理、 自動デプロイ)、Terraform(インフラの 構築)を用いた自動化 

今後の展望②：品質高度化、均一化、属人化排除 27
 開発工程の効率化を促進し、品質を強化。開発に注力できる組織へ。 設計 開発 単体テスト コードレビュー マージ スクラム開発プロセス内の詳細 コーディング規約 楽楽勤怠の作法、セキュリティ・パフォーマ ンスを担保した開発を定義 テストの強化・効率化 静的解析(PHPStan),単体テスト (PHPUnit),E2Eテストを導入、品質の 均一化 相互レビューの導入 規約化・自動化が進め、品質が高度化・均 一化することでメンバー間でのレビュー を促進し、属人化を排除 CI/CDパイプラインの導入 GitHub Actionsによる開発工程のWF 化。テスト～デプロイをすべて自動化。 

開発プロセス刷新から学んだこと 

アジャイル開発で重要視していること 案件を細分化し、顧客へ価値を提供するスピードを速める アジャイル開発は、細かく改善サイクルを繰り返すことが何よりも大切。 1つの案件が大きすぎると、改善サイクルが回らず、開発スピードが落ちる。 　　　案件が大きくなると発生する課題 ・1スプリントで終わらない→開発メンバーのモチベーションがダウン→負のスパイラル… ・リリースまでのリードタイムが長くなる→改善サイクルを回すことが出来ない ・プルリクエストが大きくなる→レビューも長くなる→開発サイクルタイムも長くなる 29
 

どうすれば「案件の細分化」をすることが出来るのか？ 「顧客理解・ドメイン理解を深める」ことが最も大切 顧客は何に困っているのか、業務上何が課題となるのか、 顧客理解・ドメイン理解を深めることで顧客にとって価値提供できる最小単位まで案件を細分化す ることが出来る。 　　　案件の細分化が出来ない理由 ・ビジネスサイド、顧客が言うことをそのまま実現することが正解と思ってしまう ・業務理解、関連法規、ドメイン理解が足りておらず、「機能は多ければ多いほど良い」と思ってしまう ・「本質的な課題」と「出来たらよいな」「便利機能」を同じスコープで扱ってしまう 30
 

ご清聴ありがとうございました。 31