分割と統合で学んだサイロ突破術 『楽楽販売』開発組織10年の軌跡と持続的成長の仕組み 楽楽販売開発部　藤井 高志 楽楽販売開発部　山内 覚 

2
 登壇者紹介 楽楽販売開発部　部長 藤井 高志 ● 大学卒業後約10年、SIやSESとしてシス テム構築・運用・保守対応を経験 ● 2016年ラクス入社 ● 開発からリリース、顧客サポートまで、製品 開発全般を一貫して経験 ● 2021年4月より楽楽販売開発課長、現在 は楽楽販売開発部の部長職を担当 楽楽販売開発部 テックリード 山内 覚 ● 前職ではパッケージソフトウェアの設計か ら保守まで経験 ● 2019年ラクス入社 ● 新バージョンのリリースやサービス基盤の 改善といった運用関連の業務を担当 ● 現在は運用チームのリーダー 

3
 楽楽販売について ● 2008/10月リリース ● 3500社を超えるお客様がご利用中 ● 2025年3月期で55億円超の年間売上を達成、Saas型販売管理システムのシェアNo1 

4
 楽楽販売について ● 業界や個社ごとの業務フローに合わせたカスタマイズが可能 ● 販売管理業務だけでなく、様々な業務の手間や面倒な作業を減らすことが可能 建設・不動産 IT 商社 広告・メディア メーカー コンサルティング 通信 人材サービス 

5
 本日の発表の目的 年間売上高が50億円を超える開発組織の10年間の変遷 ● 組織変更の試行錯誤の歴史 ● その時々で向き合ってきた課題 ● 管理者視点での悩み・改善と、現場視点での変化向き合い方 ● 振り返って効果的だった点や、効果が少なかった点の整理 プロダクトの変化と共に成功と失敗を繰り返しながらも前に進もうとした 私たちのやり方をお伝えします 今後スケールしていく組織の改善アイディアとして皆さんの参考事例となれば幸いです 

組織・チーム構成の変遷 6
 10年前：2015年頃 要件・実装 運用・保守 基盤構築 7名 ● 担当領域の固定はせず、全員で全ての領域をカバー ● タスク：個人 ● 育成や標準化はなく、個人の力とチームワークで打破 

組織・チーム構成の変遷 7
 10年前：2015年頃 要件・実装 運用・保守 基盤構築 7名 ● 担当領域の固定はせず、全員で全ての領域をカバー ● タスク：個人 ● 育成や標準化はなく、個人の力とチームワークで打破 スケールしづらい組織 トラブルに弱い体制 開発ロードマップなし 課題 

組織・チーム構成の変遷 8
 5年前：2020年頃 企画 要件・実装 運用・保守 14名 ● 製品企画(PdM)担当を作り、確度の高い案件創出を計る ● 個人で推進していた領域をチームで取り組みスピードアップを計る ● タスク：チーム ● 標準化や各種手順を整備し、誰でも作業できるように 基盤構築 

組織・チーム構成の変遷 9
 5年前：2020年頃 企画 要件・実装 運用・保守 14名 ● 製品企画(PdM)担当を作り、確度の高い案件創出を計る ● 個人で推進していた領域をチームで取り組みスピードアップを計る ● タスク：チーム ● 標準化や各種手順を整備し、誰でも作業できるように 基盤構築 要件の標準化遅れ チーム間の認識ずれ 課題 

10
 5年前：2020年頃 企画 要件・実装 運用・保守 14名 ➢ チーム分けによる効果 ○ 職能別のチームになることで開発フローの標準化が進む ➢ チーム間の連携 ○ 別のチームがやっていることはだいたい分かる 基盤構築 組織・チーム構成の変遷　現場視点 

組織・チーム構成の変遷 11
 3年前：2022年頃 企画 実装 運用・保守 18名 ● 要件担当をチーム化し、標準化や育成整理、再現性を高める動きへ ● 標準化が進んだものの、各チームでの取組みの協業がうまくいかず 基盤構築 要件 

組織・チーム構成の変遷 12
 3年前：2022年頃 企画 実装 運用・保守 18名 ● 要件担当をチーム化し、標準化や育成整理、再現性を高める動きへ ● 標準化が進んだものの、各チームでの取組みの協業がうまくいかず 基盤構築 要件 サイロ化 チーム間のゴールずれ 課題 

13
 3年前：2022年頃 企画 実装 運用・保守 18名 ➢ チーム分けによる効果 ○ 要件定義が進んで半年〜1年先の開発内容が決まるように ➢ チーム間の連携 ○ 要件と実装チームの間で調整が必要になった 基盤構築 要件 組織・チーム構成の変遷　現場視点 

組織・チーム構成の変遷 14
 2年前：2023年頃 企画 要件・実装 運用・保守 21名 ● １チームで要件～実装を進めるように ● 要件・実装が安定してきたので、手をつけられていなかった 技術負債改善を専任で取組む ● これまでできなかった大規模な技術負債改善の成果 基盤構築 技術負債改善 

組織・チーム構成の変遷 15
 2年前：2023年頃 企画 要件・実装 運用・保守 21名 ● １チームで要件～実装を進めるように ● 要件・実装が安定してきたので、手をつけられていなかった 技術負債改善を専任で取組む ● これまでできなかった大規模な技術負債改善の成果 基盤構築 技術負債改善 実装の曖昧な責任範囲 終わりのない負債改善 課題 

16
 2年前：2023年頃 企画 要件・実装 運用・保守 21名 ➢ チーム分けによる効果 ○ 要件と実装担当者のやり取りがスムーズに ○ 複雑な機能の技術負債改善が進む ➢ チーム間の連携 ○ 技術負債改善の取り組みに温度差が出てきた 基盤構築 技術負債改善 組織・チーム構成の変遷　現場視点 

組織・チーム構成の変遷 17
 1年前～現在 企画 要件・実装・技術負債改善 運用・保守 24名 ● 技術負債改善も含めて１チームで実施 ● 当事者意識・深い認識の共有 ● 新機能追加と中長期の改善を1チームへ ● 次は運用・保守、基盤構築にもどう展開するか 基盤構築 

開発特化チーム チーム毎にテーマに取組む 18
 要件・実装・技術負債改善 メンバ 要件 技術 リード メンバ 運用・保守 基盤構築 開発特化チーム メンバ 要件 技術 リード メンバ 開発＋運用・保守 メンバ 要件 技術 リード メンバ 運用・保守＋基盤構築 メンバ 要件 技術 リード メンバ 新規機能追加 UI改善 リファクタリング E2E拡充 リリース準備 トラブル対応 問い合せ対応 ＭＷ検討 セキュリティ 自動化推進 

開発特化チーム 開発特化チーム 開発＋運用・保守 運用・保守＋基盤構築 役割毎に発生するテーマについては横断でレビュー・相談 19
 メンバ 要件 技術 リード メンバ メンバ 要件 技術 リード メンバ メンバ 要件 技術 リード メンバ メンバ 要件 技術 リード メンバ 相互レビュー　相談 

20
 1年前～現在 企画 要件・実装・技術負債改善 運用・保守 24名 ➢ チーム分けによる効果 ○ 要件／実装／技術負債改善のバランスが取れるようになりスピード感が出る ➢ チーム間の連携 ○ 運用・保守チームの担当領域が増えてきた 基盤構築 組織・チーム構成の変遷　現場視点 

21
 組織・チーム構成の変遷のまとめ ● 日々接点の多い作業を別チームで推進してはいけない ○ もし別チームで構成する場合は工夫が必要 ○ 楽楽販売の開発組織においてはうまくいかないケースが多かった ■ うまくいったのはチームの過半数が製品理解度が高い状態 ● 技術的負債解消など改善に取組む組織は期間限定とする ○ 停滞していた改善は一気に進む ○ 長期間の改善組織はしんどい ■ 知見が広がりきらない ■ 新機能を開発すれば新たな負債は生まれる ■ 何よりも担当メンバーの心理的負荷が強い 

22
 現在の課題 ● チーム横断での取り組みは不足 ● 同じような悩みをそれぞれのチームで抱え、解決する動き ● プロダクトの歴史や暗黙的な知識が揃っていない ○ どこまで考えればいいか分からない ○ 有識者は知っていると思って動くので説明の不足による認識齟齬 ● チーム横断で相談する機会が少ない ○ 聞けば分かる、聞いた方が早い ○ 他チームに時間を取ってもらってまで相談していいかどうか不安 

23
 取り組み　過去の歴史説明会 プロダクトの担当歴が浅いメンバーが中心で、 各種機能やプロダクトコードにある特殊な内容などの背景・経緯が想定しづらい状況だった 2008年から遡って、プロダクトがどのような歴史をたどってきたのかを説明会実施 担当期間 5-10年 担当期間 10年超 担当期間 2-4年 担当期間 0-2年 

24
 取り組み　良いプルリクエスト紹介 プログラムは最重要資産、プルリクエストは背景や経緯を後からたどるための大切なもの 全員の共通資産であり、全員が適切に運用しないと歴史はたどれない 報告日 報告者 良いPRのリンク 良かった点 2024/10/04 担当者A ①https://github.com/rakus-xxxx/pull/5368 ②https://github.com/rakus-xxxx/pull/5378#issuecomment-238 7400539 ③https://github.com/rakus-xxxx/pull/5391/files#diff-25dace31 e654867961b30cdf86144c833910b72a14f801f90922e3adb94 7cca9R335 ④https://github.com/rakus-xxxx/pull/5413#discussion_r17870 44196 ①PRが小さくて〇。1つのPRで1つのことだけをやっている。 ②良いアドバイスコメント。たまたまこのPRに記載されたけど、みんな意識したほ うがいいこと ③機能開発の中でリファクタ（コメントのメンテ）もやってくれている ④機能開発の中でリファクタ（メソッド切り出し）もやってくれている 2024/10/11 担当者B ①https://github.com/rakus-xxxx/pull/5412 　https://github.com/rakus-xxxx/pull/5426 ②https://github.com/rakus-xxxx/issues/5414 ③https://github.com/rakus-xxxx/pull/5450 ①コミットメッセージになぜ？なにを？がある所が良き 　※PR説明も見やすいですね！ ②CDRの賞賛が良き ③経緯が追えるのが良き： 　・フィードバックが速くもらえる（手戻り防止、方針転換が可能） 　・実装案に至った経緯があるから本質的なレビューに注力出来る。 　・後からなぜ？がわかる 2024/10/18 担当者C https://github.com/rakus-xxxx/pull/5454#discussion_r1802212 972 pull requestのコメントで開発規約違反→原因究明→解決策の実施までやってい る。 2024/10/25 担当者D ①https://github.com/rakus-xxxx/pull/5486 　https://github.com/rakus-xxxx/pull/5432 ②https://github.com/rakus-xxxx/issues/5464 ③https://github.com/rakus-xxxx/pull/5444 ①descriptionの内容がよい。 　・画像をつかっていて見やすい（＋文字数も少ない） 　・修正内容だけでなく背景まで細かく書かれている ②最初にどこまでリファクタするかがしっかり検討されている 　＋その経緯細かく残っている⇒今後同じ箇所を修正する際に２度手間がなくな る！ 　＋PRの分け方まで記載されている！！ ③細かくPRを分割してくれていてレビュアーは非常に見やすい https://mattermost01.ssl.mdomain/cl-dev/pl/yy77mnwq4tdf5bfieji5x6ipyw 組織としてプルリクエストに対す る重要な考え方を定義 ● プルリクエストが小さい ● レビュアーに分かりやすい ● 経緯が読み取れる 良い行動と感じた工夫も積極的 に褒める 

25
 取り組み　各種改善取り組みをチームで推進 各種改善を複数人で共同で実施 チームで推進するため、取り組みは個人でCloseされず意図的にも無意識的にも展開される ● 暗黙知がチーム内で相互に補完できる ● 情報が発信される機会が多くなるため、チーム外のアドバイスも得られる ● 「車輪の再開発」が減る 最後にまとめ 共有します 経緯は都度相談します 

26
 ➢ 過去の歴史説明会 ○ 担当歴が長いメンバーの暗黙知の共有が進む ➢ 良いプルリクエスト紹介 ○ 良いプルリクエストを真似するようになる ➢ 各種改善取り組みをチームで推進 ○ 開発にAIを取り入れた場合の事例の共有が進む ○ AIコードエディタの導入が進む 取り組み　現場視点 

27
 今後の展望 ● １チームで実施できる領域を広げていきたい ● 最終的には開発全般を1チームで完結できる状態へ 企画 要件・実装・技術負債改善 運用・保守 基盤構築 企画 全チームがなんでも担当できる状態へ 

28
 まとめ ● プロダクトの変化と共に組織は変えないといけない ○ 3歩進んで2歩下がったとしても前進はしている ○ 失敗することもあるが、常に良い状態を模索する事が重要 ● 越境できる仕組みを意図的に運営し続けることが重要 ○ 組織設計しただけでは機能しない ○ 仕組みは継続できるシンプルさと再現性が鍵 

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