急成長する大規模プロダクト開発のマネジメント課題とアプローチ / RAKUSTechCon2024_Seisan

◆イベント名
RAKUS Tech Conference 2024
https://techcon.rakus.co.jp/2024/

◆発表タイトル
急成長する大規模プロダクト開発のマネジメント課題とアプローチ

◆登壇者
東京開発統括部 楽楽精算開発部 部長　髙橋康弘
楽楽精算開発部 開発1課 課長　小宮山和彦
楽楽精算開発部 開発1課　涌井友輔

Transcript

1. 急成長する プロダクト・チームの マネジメント課題とアプローチ 楽楽精算開発部 高橋康弘 楽楽精算開発部 開発1課 小宮山和彦 楽楽精算開発部 開発1課 涌井友輔
2. 登壇者紹介 開発本部 東京開発統括部 楽楽精算開発部 高橋康弘 2016年7月にラクス入社。 前職はソフトウェアベンダーで建設設計ソフトや会計処理ソフトなどを開発。新規事業や技術推進に も携わる。ラクスでは楽楽精算、楽楽明細の開発マネージャーから楽楽勤怠の部長職を経て、現在 は楽楽精算の開発チーム全体を統括する楽楽精算開発部の部長に就任。 2
3. 本セッションでお話しすること 楽楽精算開発チームが急速に拡大する中で起きた問題をお話しします。 １．組織的な課題 （高橋） ２．開発プロセスの課題 （小宮山） ３．技術的課題 （涌井） 3
4. 現在の課題 １． 組織課題 ・ マネジメント負荷の増大 ・ 開発効率の低下 ２． 開発プロセス課題 ・ サービス拡大とともに肥大化するコードと認知負荷 ・ 増える人員と分業化の進行 ・ 顧客視点の希薄化 ３． 技術課題 ・ サービス成長によるインフラコストの増加 ・ 技術的負債（コード上の負債） 4
5. ラクスの開発組織について 基本的にはプロダクトごとに分かれている → 楽楽精算 開発部 → 楽楽販売 開発部 → 楽楽明細 開発部 → 楽楽請求 開発部 → 楽楽勤怠 開発部 プロダクトごとに開発組織が分かれている理由 それぞれのドメインにおける顧客の問題を素早く最適な方法で 解決することにフォーカスするため 最近の変化 ・ 楽楽クラウドシリーズ間の連携 ・ メインサービスから発展・派生したプロダクトの登場 5 楽楽明細から 楽楽勤怠か ら
6. その他の横断的な開発組織 6 開発本部 東京開発統括部 楽楽精算開発部 フロントエンド 開発課 インフラ開発課 楽楽明細開発部 楽楽勤怠開発部 製品管理課 （PDM） QA課 プロダクト デザイン課 開発推進部 インフラ開発部 徐々に役割を分離
7. 開発チームの分割 楽楽精算開発 1つの開発チームから役割を分離 → 人数増加による開発効率の低下に対抗 役割を切り出して専門職化 7 上流（PdM） 機能開発 定期運用作業／ 問合せ1次受け オフショア （ブリッジSE） 品質管理 （QA）
8. 次のトピック １． 組織課題 ・ マネジメント負荷の増大 ・ 開発効率の低下 ２． 開発プロセス課題 ・ サービス拡大とともに肥大化するコードと認知負荷 ・ 増える人員と分業化の進行 ・ 顧客視点の希薄化 ３． 技術課題 ・ サービス成長によるインフラコストの増加 ・ 技術的負債（コード上の負債） 8
9. 急成長する 大規模プロダクト開発の マネジメント課題とアプローチ ～開発プロセス課題～ 楽楽精算開発部 開発1課 小宮山和彦
10. 登壇者紹介 楽楽精算開発部 開発1課 小宮山 和彦 大学卒業後、SI企業で16年勤務しプログラム、設計、プロジェクトマネジメントを経験。 その後2018年にラクスに入社。 SaaS開発はラクスで行うのが初で最初はプロジェクトマネージャーとして2年間担当。 その後、楽楽精算のエンジニアリングマネージャーとして組織課題の解決などに従事。 10
11. 開発プロセス課題 概要 以下の内容をお話しします。 ・サービス拡大とともに肥大化するコードと認知負荷 ・増える人員と分業化の進行 ・顧客視点の希薄化 11
12. 開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷 楽楽精算の概要 楽楽精算は、経費精算システムとして2009年にサービスを開始しました。 15年間の間に様々な機能が追加され、現在は110万行以上のコード行数を持つシステムに成長し ました。 またその間は技術的負債の返済よりも機能拡大や法要件対応を優先して開発をしていた、サービス 開始時から中心となって開発していたエンジニアが既に退職済みといった状況でもあります。 12
13. 開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷 楽楽精算のコード構成 楽楽精算はコアとなるモジュールとその周辺に独立し て動くサブモジュールから構成されています。 コアモジュールが全体の9割以上を占め（約100万 行）、機能追加のほとんどがこのコアモジュールに対し て行われています。 13
14. 開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷 発生している認知負荷 このような状況であるため、開発時には以下の認知負荷が発生しています。 • コード理解の負荷 • 変更の影響範囲の把握 • デバッグとテストの負荷 • 知識の共有と継承の負荷 • 設計の一貫性の維持の負荷 14
15. 開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷 開発プロセスから見た認知負荷 2010年代までエンジニアは事業部門との調整、要件定義、設計、実装、テスト、リリース、運用をす べて担当していました。 これにより、エンジニアの認知負荷がさらに増大し、多様なスキルセットが必要でした。 15
16. 開発プロセス課題：増える人員と分業化の進行 開発人数の推移 サービス成長のために積極的な採用採用 を行い、開発人数はこちらのように年々 増加しています。 16 年 人数 2019 18 2020 22 2021 25 2022 38 2023 39 2024 44
17. 開発プロセス課題：増える人員と分業化の進行 エンジニア以外の新しい役割 増えた仲間全員が開発工程の全てを担当するのではなく、役割を分担して仕事をするようになりました。 ・プロダクトマネージャー(PdM) ・デザイナー ・エンジニア ・オフショア開発エンジニア ・モバイル開発エンジニア ・QAエンジニア(運用業務も兼務） 17
18. 開発プロセス課題：増える人員と分業化の進行 分業の効果 • 担当する開発プロセスが多いという認知負荷の軽減効果がありました。 • エンジニアが開発稼働も20%程度上昇 18
19. 開発プロセス課題：増える人員と分業化の進行 役割分担に基づいた現在の開発フロー 19
20. 開発プロセス課題：顧客視点の希薄化 希薄化の要因 役割分担が進んだ開発フローにより、開発効率は向上しました。 伴ってエンジニアの顧客視点が希薄化する問題が発生しています 20 要因 詳細 顧客課題の把握の分業化 エンジニアは設計や開発に専念し、顧客課題の把握は事業部門 やPdMが中心となった。 問い合わせ対応のエスカレーション変更 以前はCSが1次受けし、エンジニアにエスカレーションしていた が、現在はQAがエスカレーション先となった。 仮説のモニタリングと検証の欠如 要求で立てた仮説が正しいかどうかをモニタリングし、リリース 後に検証するプロセスが不足している。
21. 開発プロセス課題：顧客視点の希薄化 希薄化対策 希薄化に対する現時点で取り組んでいる事例を4つ紹介します。 21
22. 開発プロセス課題：顧客視点の希薄化 希薄化対策1: PdMとエンジニアのディスカッション 取組：PdMから要求の説明を受けるだけではなく、PdMとエンジニアが要求に至った背景などを 直接ディスカッションを行い、顧客の課題やニーズを深く理解する。 効果：要求を深く理解することでエンジニアが顧客の視点を持ち、より適切なソリューションを提供 できるようになる。 22
23. 開発プロセス課題：顧客視点の希薄化 希薄化対策2: エンジニア間での要求共有 取組：ディスカッションを通じて得た顧客要求を、参加したエンジニアが他のエンジニアに説明する。 効果：チーム全体で要求に対する理解が深まり、一貫性のある開発が可能になる。 23
24. 開発プロセス課題：顧客視点の希薄化 希薄化対策3: 顧客の声を直接聞く機会の提供 取組：エンジニアが営業同行や営業動画を視聴することで、顧客の声を直接聞く機会を提供する。 効果：顧客の実際の使用状況やフィードバックを理解し、開発に反映させることができる。 24
25. 開発プロセス課題：顧客視点の希薄化 希薄化対策4: 仮説のモニタリングと検証 取組：要求で立てた仮説が正しいかどうかをデータでモニタリングし、リリース後に仮説を検証する。 効果：製品の改善サイクルを確立し、顧客のニーズに迅速に対応できる。 25
26. 開発プロセス課題：まとめ 認知負荷の問題: 15年のサービス提供で認知負荷が増大。早めの対策が重要。 役割分担の効果: 役割分担はエンジニアの認知負荷軽減に効果あり。 顧客視点の希薄化対策: 顧客視点の希薄化を防ぐため、エンジニアの顧客視点養成が必要。 今後の取り組み: 要求理解、顧客の声の直接聴取、仮説のモニタリングと検証。効果は次回報告予定。 26
27. 急成長する 大規模プロダクト開発の マネジメント課題とアプローチ ～楽楽精算 技術負債解消の取り組み～ 楽楽精算開発部 開発1課 涌井友輔
28. 登壇者紹介 楽楽精算開発部開発1課 涌井 友輔 2024年2月にラクス入社。 SIer、通信ソフト開発、転職サイト・Webメディア開発、EMを経てラクスに参画。 前職では、技術負債解消のためにサイトの作り直しをエンジニアとして経験し、その後EMとしてスク ラム立ち上げや採用・技術広報などを担当。ラクス入社後は楽楽精算の技術負債解消チームのプロ ジェクトマネジメントに従事。 28
29. 開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷 再掲 楽楽精算の概要 楽楽精算は、経費精算システムとして2009年にサービスを開始しました。 15年間の間に様々な機能が追加され、現在は110万行以上のコード行数を持つシステムに成長し ました。 またその間は技術的負債の返済よりも機能拡大や法要件対応を優先して開発をしていた、サービス 開始時から中心となって開発していたエンジニアが既に退職済みといった状況でもあります。 29
30. 技術的負債の影響 • 開発生産性低下 • セキュリティリスク • インフラコスト増大 • 機能開発の制約増加 • 採用難易度上昇 • エンジニアの技術的キャリア構築が難しい 30
31. 技術負債解消の目的 生産性向上により顧客価値提供の最大化 • 生産性向上のために機能開発チームの学習支援まで伴走する • 技術負債解消の成果をモニタリングして、効果を計測する • 顧客価値提供の高い機能の負債解消から取り組む 31
32. 技術負債解消専任チーム 32 楽楽精算開発部 開発１課 コード刷新チーム ・PjM 1名 ・エンジニア 4名 インフラ刷新チーム ・PjM 1名 ・エンジニア 4名
33. 技術負債解消 ～ コード刷新 ～ プロダクトコードの技術的負債を解消するチーム • 課題の分析 • リファクタリング方針 • リファクタリングの進め方 33
34. 技術負債解消 ～ コード刷新 ～ 課題の分析 課題の分析 • コードを分析して、問題点と原因の洗い出しを実施 ◦ 問題点を整理してそれぞれの原因を深堀り 34
35. 技術負債解消 ～ コード刷新 ～ リファクタリング方針 リファクタリング方針 • 厳密な三層アーキテクチャの適用 ◦ 処理をプレゼンテーション層、アプリケーション層、データ層に分離する • ドメインクラスの導入 ◦ データは適切な型と構造を持ったドメインクラスに入れる • ロジックの委譲 ◦ 共通ロジックはユースケースと独立したクラスに記述し、明示的に呼び出す 35
36. 技術負債解消 ～ コード刷新 ～ リファクタリングの進め方 リファクタリングの進め方 • 対象のドメインの選定 ◦ ボリュームが極端に大きくない ◦ 変更頻度が高い • インテグレーションテストの実装 ◦ エンドポイント毎にテストコードを実装 • リファクタリングの実施 ◦ 品質はインテグレーションテストの結果で担保 36
37. 技術負債解消 ～ インフラ刷新 ～ アプリケーションのアーキテクチャに起因するインフラの技術的負債を解消するチーム • 課題 • 原因 • 解決策 • 効果 • 新システム移行の課題と対策 37
38. 技術負債解消 ～ インフラ刷新 ～ 課題： インフラコスト増大 • 800以上の仮想マシンで運用しているためインフラコスト・保守・運用コストが高い • 現在のペースで運用を続けていくと将来的に保守・運用が回らなくなる可能性がある 38
39. 技術負債解消 ～ インフラ刷新 ～ 原因： モノリシックなシステム構成 • Web・バッチ・DBが1台のマシン上で動いている(マルチテナント型) • 1台のマシンに収容上限(ユーザー上限数)を設定して上限を超えた場合新しい環境を建ててい る 39
40. 技術負債解消 ～ インフラ刷新 ～ 解決策: Webサービス・バッチ・DBを分離する 段階的に分離を進める • バッチ分離 ← いまここ • Web/DB分離 40
41. 技術負債解消 ～ インフラ刷新 ～ バッチ分離：採用技術 Apache Kafka × Debezium × Spring によるメッセージキューイングシステム 41 Developer Experience Knowledge Base.「Apache Kafka」. https://developerexperience.io/articles/kafka,（参照2024-08-02）
42. 技術負債解消 ～ インフラ刷新 ～ 42 メッセージキューイングシステム詳細 • Producer: Debezium ◦ メッセージを送信する役割 ◦ DBのトランザクションのコミットログを監視 してKafkaにメッセージを送信する • Broker: Apache Kafka ◦ メッセージキューの管理 • Consumer: Spring ◦ メッセージを受信する役割 ◦ 受信したメッセージのバッチを実行する Developer Experience Knowledge Base.「Apache Kafka」. https://developerexperience.io/articles/kafka,（参照2024-08-02）
43. 技術負債解消 ～ インフラ刷新 ～ 効果 • バッチシステムの統合による保守・運用コスト低下 • インフラリソースの最適化 43
44. 技術負債解消 ～ インフラ刷新 ～ 新システム移行の課題 • 稼働中のシステムへのリリース方法の検討 ◦ クラスター毎のリリース ◦ システム無停止 ◦ 旧システムへの切り戻しを保証 44
45. 技術負債解消 ～ インフラ刷新 ～ 新システム移行の解決策 • フィーチャーフラグによるリリース ◦ 現行システムのバッチ処理にフィーチャーフラグを仕込む ▪ フラグはDBで管理(無停止リリースを実現するため) ◦ フラグのON/OFFで新・旧システムの切り替えを実現 45
46. 技術負債解消 これからの取り組み 開発生産性向上から顧客価値の最大化へ • 現在はエンジニアの生産性向上を軸に技術的負債の解消に取り組んでいる • 今後は顧客価値の最大化を軸にシフトしていく 46
47. 技術負債解消 これからの取り組み 顧客価値提供の最大化 • 技術的負債が障壁となり実現できない機能を優先 • 競争優位性が高い機能を優先 • 競争優位性が低い機能をアウトソース 顧客提供価値の高い機能に開発を集中させることで最大化を図る 47
48. ご清聴ありがとうございました。 48