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

by Rakus_Dev

Slide 1

Slide 1 text

急成長するプロダクト・チームのマネジメント課題とアプローチ楽楽精算開発部高橋康弘楽楽精算開発部開発1課小宮山和彦楽楽精算開発部開発1課涌井友輔

Slide 2

Slide 2 text

登壇者紹介開発本部東京開発統括部楽楽精算開発部高橋康弘 2016年7月にラクス入社。前職はソフトウェアベンダーで建設設計ソフトや会計処理ソフトなどを開発。新規事業や技術推進にも携わる。ラクスでは楽楽精算、楽楽明細の開発マネージャーから楽楽勤怠の部長職を経て、現在は楽楽精算の開発チーム全体を統括する楽楽精算開発部の部長に就任。 2

Slide 3

Slide 3 text

本セッションでお話しすること楽楽精算開発チームが急速に拡大する中で起きた問題をお話しします。１．組織的な課題（高橋）２．開発プロセスの課題（小宮山）３．技術的課題（涌井） 3

Slide 4

Slide 4 text

現在の課題１．組織課題・マネジメント負荷の増大・開発効率の低下２．開発プロセス課題・サービス拡大とともに肥大化するコードと認知負荷・増える人員と分業化の進行・顧客視点の希薄化３．技術課題・サービス成長によるインフラコストの増加・技術的負債（コード上の負債） 4

Slide 5

Slide 5 text

ラクスの開発組織について基本的にはプロダクトごとに分かれている → 楽楽精算開発部 → 楽楽販売開発部 → 楽楽明細開発部 → 楽楽請求開発部 → 楽楽勤怠開発部プロダクトごとに開発組織が分かれている理由それぞれのドメインにおける顧客の問題を素早く最適な方法で解決することにフォーカスするため最近の変化・楽楽クラウドシリーズ間の連携・メインサービスから発展・派生したプロダクトの登場 5 楽楽明細から楽楽勤怠から

Slide 6

Slide 6 text

その他の横断的な開発組織 6 開発本部東京開発統括部楽楽精算開発部フロントエンド開発課インフラ開発課楽楽明細開発部楽楽勤怠開発部製品管理課（PDM） QA課プロダクトデザイン課開発推進部インフラ開発部徐々に役割を分離

Slide 7

Slide 7 text

開発チームの分割楽楽精算開発 1つの開発チームから役割を分離 → 人数増加による開発効率の低下に対抗役割を切り出して専門職化 7 上流（PdM）機能開発定期運用作業／問合せ1次受けオフショア（ブリッジSE）品質管理（QA）

Slide 8

Slide 8 text

次のトピック１．組織課題・マネジメント負荷の増大・開発効率の低下２．開発プロセス課題・サービス拡大とともに肥大化するコードと認知負荷・増える人員と分業化の進行・顧客視点の希薄化３．技術課題・サービス成長によるインフラコストの増加・技術的負債（コード上の負債） 8

Slide 9

Slide 9 text

急成長する大規模プロダクト開発のマネジメント課題とアプローチ～開発プロセス課題～楽楽精算開発部開発1課小宮山和彦

Slide 10

Slide 10 text

登壇者紹介楽楽精算開発部開発1課小宮山和彦大学卒業後、SI企業で16年勤務しプログラム、設計、プロジェクトマネジメントを経験。その後2018年にラクスに入社。 SaaS開発はラクスで行うのが初で最初はプロジェクトマネージャーとして2年間担当。その後、楽楽精算のエンジニアリングマネージャーとして組織課題の解決などに従事。 10

Slide 11

Slide 11 text

開発プロセス課題概要以下の内容をお話しします。・サービス拡大とともに肥大化するコードと認知負荷・増える人員と分業化の進行・顧客視点の希薄化 11

Slide 12

Slide 12 text

開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷楽楽精算の概要楽楽精算は、経費精算システムとして2009年にサービスを開始しました。 15年間の間に様々な機能が追加され、現在は110万行以上のコード行数を持つシステムに成長しました。またその間は技術的負債の返済よりも機能拡大や法要件対応を優先して開発をしていた、サービス開始時から中心となって開発していたエンジニアが既に退職済みといった状況でもあります。 12

Slide 13

Slide 13 text

開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷楽楽精算のコード構成楽楽精算はコアとなるモジュールとその周辺に独立して動くサブモジュールから構成されています。コアモジュールが全体の9割以上を占め（約100万行）、機能追加のほとんどがこのコアモジュールに対して行われています。 13

Slide 14

Slide 14 text

開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷発生している認知負荷このような状況であるため、開発時には以下の認知負荷が発生しています。 ● コード理解の負荷 ● 変更の影響範囲の把握 ● デバッグとテストの負荷 ● 知識の共有と継承の負荷 ● 設計の一貫性の維持の負荷 14

Slide 15

Slide 15 text

開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷開発プロセスから見た認知負荷 2010年代までエンジニアは事業部門との調整、要件定義、設計、実装、テスト、リリース、運用をすべて担当していました。これにより、エンジニアの認知負荷がさらに増大し、多様なスキルセットが必要でした。 15

Slide 16

Slide 16 text

開発プロセス課題：増える人員と分業化の進行開発人数の推移サービス成長のために積極的な採用採用を行い、開発人数はこちらのように年々増加しています。 16 年人数 2019 18 2020 22 2021 25 2022 38 2023 39 2024 44

Slide 17

Slide 17 text

開発プロセス課題：増える人員と分業化の進行エンジニア以外の新しい役割増えた仲間全員が開発工程の全てを担当するのではなく、役割を分担して仕事をするようになりました。・プロダクトマネージャー(PdM) ・デザイナー・エンジニア・オフショア開発エンジニア・モバイル開発エンジニア・QAエンジニア(運用業務も兼務） 17

Slide 18

Slide 18 text

開発プロセス課題：増える人員と分業化の進行分業の効果 ● 担当する開発プロセスが多いという認知負荷の軽減効果がありました。 ● エンジニアが開発稼働も20%程度上昇 18

Slide 19

Slide 19 text

開発プロセス課題：増える人員と分業化の進行役割分担に基づいた現在の開発フロー 19

Slide 20

Slide 20 text

開発プロセス課題：顧客視点の希薄化希薄化の要因役割分担が進んだ開発フローにより、開発効率は向上しました。伴ってエンジニアの顧客視点が希薄化する問題が発生しています 20 要因詳細顧客課題の把握の分業化エンジニアは設計や開発に専念し、顧客課題の把握は事業部門やPdMが中心となった。問い合わせ対応のエスカレーション変更以前はCSが1次受けし、エンジニアにエスカレーションしていたが、現在はQAがエスカレーション先となった。仮説のモニタリングと検証の欠如要求で立てた仮説が正しいかどうかをモニタリングし、リリース後に検証するプロセスが不足している。

Slide 21

Slide 21 text

開発プロセス課題：顧客視点の希薄化希薄化対策希薄化に対する現時点で取り組んでいる事例を4つ紹介します。 21

Slide 22

Slide 22 text

開発プロセス課題：顧客視点の希薄化希薄化対策1: PdMとエンジニアのディスカッション取組：PdMから要求の説明を受けるだけではなく、PdMとエンジニアが要求に至った背景などを直接ディスカッションを行い、顧客の課題やニーズを深く理解する。効果：要求を深く理解することでエンジニアが顧客の視点を持ち、より適切なソリューションを提供できるようになる。 22

Slide 23

Slide 23 text

開発プロセス課題：顧客視点の希薄化希薄化対策2: エンジニア間での要求共有取組：ディスカッションを通じて得た顧客要求を、参加したエンジニアが他のエンジニアに説明する。効果：チーム全体で要求に対する理解が深まり、一貫性のある開発が可能になる。 23

Slide 24

Slide 24 text

開発プロセス課題：顧客視点の希薄化希薄化対策3: 顧客の声を直接聞く機会の提供取組：エンジニアが営業同行や営業動画を視聴することで、顧客の声を直接聞く機会を提供する。効果：顧客の実際の使用状況やフィードバックを理解し、開発に反映させることができる。 24

Slide 25

Slide 25 text

開発プロセス課題：顧客視点の希薄化希薄化対策4: 仮説のモニタリングと検証取組：要求で立てた仮説が正しいかどうかをデータでモニタリングし、リリース後に仮説を検証する。効果：製品の改善サイクルを確立し、顧客のニーズに迅速に対応できる。 25

Slide 26

Slide 26 text

開発プロセス課題：まとめ認知負荷の問題: 15年のサービス提供で認知負荷が増大。早めの対策が重要。役割分担の効果: 役割分担はエンジニアの認知負荷軽減に効果あり。顧客視点の希薄化対策: 顧客視点の希薄化を防ぐため、エンジニアの顧客視点養成が必要。今後の取り組み: 要求理解、顧客の声の直接聴取、仮説のモニタリングと検証。効果は次回報告予定。 26

Slide 27

Slide 27 text

急成長する大規模プロダクト開発のマネジメント課題とアプローチ～楽楽精算技術負債解消の取り組み～楽楽精算開発部開発1課涌井友輔

Slide 28

Slide 28 text

登壇者紹介楽楽精算開発部開発1課涌井友輔 2024年2月にラクス入社。 SIer、通信ソフト開発、転職サイト・Webメディア開発、EMを経てラクスに参画。前職では、技術負債解消のためにサイトの作り直しをエンジニアとして経験し、その後EMとしてスクラム立ち上げや採用・技術広報などを担当。ラクス入社後は楽楽精算の技術負債解消チームのプロジェクトマネジメントに従事。 28

Slide 29

Slide 29 text

開発プロセス課題：サービス拡大とともに肥大化するコードと認知負荷再掲楽楽精算の概要楽楽精算は、経費精算システムとして2009年にサービスを開始しました。 15年間の間に様々な機能が追加され、現在は110万行以上のコード行数を持つシステムに成長しました。またその間は技術的負債の返済よりも機能拡大や法要件対応を優先して開発をしていた、サービス開始時から中心となって開発していたエンジニアが既に退職済みといった状況でもあります。 29

Slide 30

Slide 30 text

技術的負債の影響 ● 開発生産性低下 ● セキュリティリスク ● インフラコスト増大 ● 機能開発の制約増加 ● 採用難易度上昇 ● エンジニアの技術的キャリア構築が難しい 30

Slide 31

Slide 31 text

技術負債解消の目的生産性向上により顧客価値提供の最大化 ● 生産性向上のために機能開発チームの学習支援まで伴走する ● 技術負債解消の成果をモニタリングして、効果を計測する ● 顧客価値提供の高い機能の負債解消から取り組む 31

Slide 32

Slide 32 text

技術負債解消専任チーム 32 楽楽精算開発部開発１課コード刷新チーム・PjM 1名・エンジニア 4名インフラ刷新チーム・PjM 1名・エンジニア 4名

Slide 33

Slide 33 text

技術負債解消～コード刷新～プロダクトコードの技術的負債を解消するチーム ● 課題の分析 ● リファクタリング方針 ● リファクタリングの進め方 33

Slide 34

Slide 34 text

技術負債解消～コード刷新～課題の分析課題の分析 ● コードを分析して、問題点と原因の洗い出しを実施 ○ 問題点を整理してそれぞれの原因を深堀り 34

Slide 35

Slide 35 text

技術負債解消～コード刷新～リファクタリング方針リファクタリング方針 ● 厳密な三層アーキテクチャの適用 ○ 処理をプレゼンテーション層、アプリケーション層、データ層に分離する ● ドメインクラスの導入 ○ データは適切な型と構造を持ったドメインクラスに入れる ● ロジックの委譲 ○ 共通ロジックはユースケースと独立したクラスに記述し、明示的に呼び出す 35

Slide 36

Slide 36 text

技術負債解消～コード刷新～リファクタリングの進め方リファクタリングの進め方 ● 対象のドメインの選定 ○ ボリュームが極端に大きくない ○ 変更頻度が高い ● インテグレーションテストの実装 ○ エンドポイント毎にテストコードを実装 ● リファクタリングの実施 ○ 品質はインテグレーションテストの結果で担保 36

Slide 37

Slide 37 text

技術負債解消～インフラ刷新～アプリケーションのアーキテクチャに起因するインフラの技術的負債を解消するチーム ● 課題 ● 原因 ● 解決策 ● 効果 ● 新システム移行の課題と対策 37

Slide 38

Slide 38 text

技術負債解消～インフラ刷新～課題：インフラコスト増大 ● 800以上の仮想マシンで運用しているためインフラコスト・保守・運用コストが高い ● 現在のペースで運用を続けていくと将来的に保守・運用が回らなくなる可能性がある 38

Slide 39

Slide 39 text

技術負債解消～インフラ刷新～原因：モノリシックなシステム構成 ● Web・バッチ・DBが1台のマシン上で動いている(マルチテナント型) ● 1台のマシンに収容上限(ユーザー上限数)を設定して上限を超えた場合新しい環境を建てている 39

Slide 40

Slide 40 text

技術負債解消～インフラ刷新～解決策: Webサービス・バッチ・DBを分離する段階的に分離を進める ● バッチ分離 ← いまここ ● Web/DB分離 40

Slide 41

Slide 41 text

技術負債解消～インフラ刷新～バッチ分離：採用技術 Apache Kafka × Debezium × Spring によるメッセージキューイングシステム 41 Developer Experience Knowledge Base.「Apache Kafka」. https://developerexperience.io/articles/kafka,（参照2024-08-02）

Slide 42

Slide 42 text

技術負債解消～インフラ刷新～ 42 メッセージキューイングシステム詳細 ● Producer: Debezium ○ メッセージを送信する役割 ○ DBのトランザクションのコミットログを監視してKafkaにメッセージを送信する ● Broker: Apache Kafka ○ メッセージキューの管理 ● Consumer: Spring ○ メッセージを受信する役割 ○ 受信したメッセージのバッチを実行する Developer Experience Knowledge Base.「Apache Kafka」. https://developerexperience.io/articles/kafka,（参照2024-08-02）

Slide 43

Slide 43 text

技術負債解消～インフラ刷新～効果 ● バッチシステムの統合による保守・運用コスト低下 ● インフラリソースの最適化 43

Slide 44

Slide 44 text

技術負債解消～インフラ刷新～新システム移行の課題 ● 稼働中のシステムへのリリース方法の検討 ○ クラスター毎のリリース ○ システム無停止 ○ 旧システムへの切り戻しを保証 44

Slide 45

Slide 45 text

技術負債解消～インフラ刷新～新システム移行の解決策 ● フィーチャーフラグによるリリース ○ 現行システムのバッチ処理にフィーチャーフラグを仕込む ■ フラグはDBで管理(無停止リリースを実現するため) ○ フラグのON/OFFで新・旧システムの切り替えを実現 45

Slide 46

Slide 46 text

技術負債解消これからの取り組み開発生産性向上から顧客価値の最大化へ ● 現在はエンジニアの生産性向上を軸に技術的負債の解消に取り組んでいる ● 今後は顧客価値の最大化を軸にシフトしていく 46

Slide 47

Slide 47 text

技術負債解消これからの取り組み顧客価値提供の最大化 ● 技術的負債が障壁となり実現できない機能を優先 ● 競争優位性が高い機能を優先 ● 競争優位性が低い機能をアウトソース顧客提供価値の高い機能に開発を集中させることで最大化を図る 47

Slide 48

Slide 48 text

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