Upgrade to Pro — share decks privately, control downloads, hide ads and more …

営業支援システムと歩んだ7年半の変遷

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

 営業支援システムと歩んだ7年半の変遷

Avatar for Tech Leverages

Tech Leverages PRO

April 11, 2026

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © 2026 Levtech Co., Ltd. 2 レバテック開発部 DI開発 セールス開発グループ 岡田

    竜典 RYUSUKE OKADA #バックエンドエンジニア #Mr.Children  #ポーカー  #コーヒーは豆から挽くタイプ  #初登壇
  2. | © 2026 Levtech Co., Ltd. 10 • 1週間に1度だったリリースが、毎日数回リリースするようになった • チーム人数が最少5人だったのが、正社員だけで16人にまで増加した

    • 勉強会の実施頻度が0回だったのが、週1回開催されるようになった • レバレジーズグループ全体の売上が449億から1428億に増加し、グループを支え る基盤システムとなる 数字で見る変化
  3. | © 2026 Levtech Co., Ltd. 14 • 開発環境を構築するのに時間がかかる • 問い合わせや運用対応が多く開発に使える時間が少ない

    • リリース作業は手動で行っている手順もあり一部の人しかできない • 少人数でレバテックの事業領域を全てカバーしている • 施策優先でシステムのメンテナンスは後回し • 実装した機能のテストは全て手動で確認する必要があり時間と労力がかかる 何が大変だったのか
  4. | © 2026 Levtech Co., Ltd. 15 • 開発に集中する時間がなく新しいことの挑戦ができない • 機能が多く改修による影響範囲の調査をしても安心できない

    • 基盤システムだけどレガシーシステムになりつつあり開発したくない ◦ マイクロサービス化の流れもあり人が流れていったりと • 実装するものは依頼ベースでなんのために必要なのかがわからない ◦ 開発する範囲も広くドメイン知識も身につかない 開発者のメンタルモデル
  5. | © 2026 Levtech Co., Ltd. 16 • 開発環境を構築するのに時間がかかる • 問い合わせや運用対応が多く開発に使える時間が少ない

    • リリース作業は手動で行っている手順もあり一部の人しかできない • 少人数でレバテックの事業領域を全てカバーしている • 施策優先でシステムのメンテナンスは後回し • 実装した機能のテストは全て手動で確認する必要があり時間と労力がかかる 何を改善するべきかを決めて実行した
  6. | © 2026 Levtech Co., Ltd. 17 POINT 01 運用対応の工数を削減 POINT

    02 手動テストの自動化 POINT 03 改善ポイント 開発環境構築の手間を削減 放置されていたライブラリアップデートの定常化 POINT 04
  7. | © 2026 Levtech Co., Ltd. 18 POINT 01 運用対応の工数を削減 POINT

    02 手動テストの自動化 POINT 03 改善ポイント 開発環境構築の手間を削減 放置されていたライブラリアップデートの定常化 POINT 04
  8. | © 2026 Levtech Co., Ltd. 19 • 開発環境がオンプレサーバー上にあり、開発者ごとに個別の設定作業が必要 • サーバー設定も必要で不慣れだと特に時間がかかってしまう

    • 動作確認するためにはSFTPを設定しサーバーにアップロードする必要もあった • 構築コストの高さが障壁となり、別チームのメンバーが「ちょっと触ってみたい」と思っても敬 遠される 開発環境構築に1~2日かかる 開発環境構築の手間を削減
  9. | © 2026 Levtech Co., Ltd. 20 • 開発環境がオンプレサーバー上にあり、開発者ごとに個別の設定作業が必要 • サーバー設定も必要で不慣れだと特に時間がかかってしまう

    • 動作確認するためにはSFTPを設定しサーバーにアップロードする必要もあった • 構築コストの高さが障壁となり、別チームのメンバーが「ちょっと触ってみたい」と思っても敬 遠される 結果として、チーム外からのフィードバックや貢献、知見共有の機会が失われていた 開発環境構築に1~2日かかる 開発環境構築の手間を削減
  10. | © 2026 Levtech Co., Ltd. 21 簡単に環境構築をできるようにするために、Dockerを利用したクラウドベースの開発環境に移行する ことになりました。 これにより、構築までにかかる時間が、 8時間→2時間に短縮できました。

    ※2時間かかってしまう要因は数GBあるdumpデータの投入で 1.5時間かかっていましたがこのタイミングでは許容することに (補足:現在では、環境構築にかかる時間は 30分にまで短縮されました) オンプレ開発環境の脱却 開発環境構築の手間を削減
  11. | © 2026 Levtech Co., Ltd. 22 POINT 01 運用対応の工数を削減 POINT

    02 手動テストの自動化 POINT 03 改善ポイント 開発環境構築の手間を削減 放置されていたライブラリアップデートの定常化 POINT 04
  12. | © 2026 Levtech Co., Ltd. 23 • ① 問い合わせ対応 •

    ② リリース作業の属人化 • ③ バッチ処理の管理方法 改善したい運用対応 運用対応の工数削減
  13. | © 2026 Levtech Co., Ltd. 24 • ① 問い合わせ対応 •

    ② リリース作業の属人化 • ③ バッチ処理の管理 改善したい運用対応 運用対応の工数削減
  14. | © 2026 Levtech Co., Ltd. 25 • システムの仕様確認 • 担当者引き継ぎなどによるデータ修正依頼

    • 大量データの一括登録依頼 • 誤作成データの削除依頼 問い合わせ対応 運用対応の工数削減|問い合わせ対応
  15. | © 2026 Levtech Co., Ltd. 26 • システムの仕様確認 • 担当者引き継ぎなどによるデータ修正依頼

    • 大量データの一括登録依頼 • 誤作成データの削除依頼 特に大変だった依頼系は、月に60~80件も対応する必要があり データを直接更新したりして、開発者の心理的負担が大きかった 問い合わせ対応 運用対応の工数削減|問い合わせ対応
  16. | © 2026 Levtech Co., Ltd. 28 事業の経営層と相談し、2ヶ月間は施策開発をストップ 運用対応の機能化に集中することにしました その数なんと、 15機能

    定型化している依頼を機能として実装することにしました 運用対応の工数削減|問い合わせ対応
  17. | © 2026 Levtech Co., Ltd. 29 • ① 問い合わせ対応 •

    ② リリース作業の属人化 • ③ バッチ処理の管理 改善したい運用対応 運用対応の工数削減
  18. | © 2026 Levtech Co., Ltd. 33 • ① 問い合わせ対応 •

    ② リリース作業の属人化 • ③ バッチ処理の管理 改善したい運用対応 運用対応の工数削減
  19. | © 2026 Levtech Co., Ltd. 34 当時はRundeckというOSSのジョブ管理ツールを使っていました。 しかし、RundeckのDBがクラッシュしてしまいアクセスできなくなることが度々発生することがあり、 クラッシュしてしまうと業務に支障が出てしまう。 •

    リリース作業が実施できない • バッチ処理が実行できない ※補足:原因は、RundeckのDBをH2 Databaseという開発やテストでの利用が推奨されているDBを本番運用で利用してい たことでした。 実行ログが溜まりファイルサイズが数GBを超えてしまい、DB自体が壊れてしまい起動不能になってしまったようです。 定期的なバッチ処理を実行するツールの変更 運用対応の工数削減|バッチ処理の管理
  20. | © 2026 Levtech Co., Ltd. 36 POINT 01 運用対応の工数を削減 POINT

    02 手動テストの自動化 POINT 03 改善ポイント 開発環境構築の手間を削減 放置されていたライブラリアップデートの定常化 POINT 04
  21. | © 2026 Levtech Co., Ltd. 37 • PHP: 7.0 •

    Laravel: 5.5 • Webサーバ: Apache • DB: MySQL5.7 アップデートする前 運用対応の工数削減|手動テストの自動化&アップデート
  22. | © 2026 Levtech Co., Ltd. 38 • PHP: 7.0 ←

    2019年1月10日(公式セキュリティサポート終了) • Laravel: 5.5 ← 2020年8月30日(公式セキュリティサポート終了) • Webサーバ: Apache • DB: MySQL5.7 ← TiDBへの移行計画もありAWSの延長サポートを利用 どれもLTSFリリース当初からアップデート対応をしてこなかったです アップデートする前 運用対応の工数削減|手動テストの自動化&アップデート
  23. | © 2026 Levtech Co., Ltd. 40 いきなりアップデートを行うのではなく、まずは既存のバージョンのままテストを導入することに! • PHPUnitでテスト導入 •

    最低限の業務フローを担保できるように統合テストを実装 • 同時にGithubActionsでテスト実行できるようにCIの導入 • テストカバレッジは0%→4% 最低限のテスト実装が完了したので、PHPとLaravelのアップデートPJを実施。 レガシーシステムにテストを導入する 運用対応の工数削減|手動テストの自動化&アップデート
  24. | © 2026 Levtech Co., Ltd. 41 アップデートを実施するにあたって、まずはメンバーを集めるところから。 • アップデートをメインで進めるエンジニア •

    営業支援システムを開発している既存メンバー • インフラ担当 • QAエンジニア の合計4名で進めることに。 PHPとLaravelのアップデートを実施 運用対応の工数削減|手動テストの自動化&アップデート
  25. | © 2026 Levtech Co., Ltd. 42 見積もり3ヶ月のところ、ギリギリ収まる程度で下記のアップデートをすることができました! • PHP7.0から8.2(7世代新しくなる) •

    Laravel5.5から10(8世代新しくなる) リリース後は切り戻しを行うような大きな不具合の発生もなく、PJとしては大成功でした! PHPとLaravelのアップデートを実施 運用対応の工数削減|手動テストの自動化&アップデート 詳細は「レガシーな営業支援システムのPHPとLaravelをアップグレードした時の話」にも記載されています
  26. | © 2026 Levtech Co., Ltd. 43 また、このタイミングでシステムとしても色々とアップデートできました! • EC2のOSを最新化 ◦

    AmazonLinux2 → AmazonLinux2023 • GravitonCPUに変更してコスト微減して性能アップ • WebサーバーをNginxに変更 • OPcacheの導入 ◦ Preloadも導入 ◦ 元々開くのに10秒かかってしまっていた画面が1.5秒で開くように • Formatter導入でレビュー工数の削減 • docker環境のDBをレストアする時間を1.5時間→5分に短縮 ◦ dockerイメージをx86からARMに変更したため高速化に成功 PHPとLaravelのアップデートを実施 運用対応の工数削減|手動テストの自動化&アップデート
  27. | © 2026 Levtech Co., Ltd. 44 また、このタイミングでシステムとしても色々とアップデートできました! • EC2のOSを最新化 ◦

    AmazonLinux2 → AmazonLinux2023 • GravitonCPUに変更してコスト微減して性能アップ • WebサーバーをNginxに変更 • OPcacheの導入 ◦ Preloadも導入 ◦ 元々開くのに10秒かかってしまっていた画面が1.5秒で開くように • Formatter導入でレビュー工数の削減 • docker環境のDBをレストアする時間を1.5時間→5分に短縮 ◦ dockerイメージをx86からARMに変更したため高速化に成功 PHPとLaravelのアップデートを実施 運用対応の工数削減|手動テストの自動化&アップデート
  28. | © 2026 Levtech Co., Ltd. 45 POINT 01 運用対応の工数を削減 POINT

    02 手動テストの自動化 POINT 03 改善ポイント 開発環境構築の手間を削減 放置されていたライブラリアップデートの定常化 POINT 04
  29. | © 2026 Levtech Co., Ltd. 48 • PHPStanを導入して静的解析を始める ◦ 実行時エラーや潜在バグをCIで検出するため、LEVEL6から開始して現在はLEVEL8で運用

    している • オブザーバビリティの強化のためNewRelicの利用を開始 ◦ 障害発生時の迅速な原因究明と対応が可能にするために、SREチームに導入のサポートして もらい、システムのパフォーマンスを数値で見れたりログのトレーサビリティが向上しまし た • ライブラリの定期メンテナンスをチームの習慣として定着させた ◦ セキュリティリスクの低減と、最新の機能や改善を取り入れ続けられるために、 dependabotを導入して毎月アップデートをするようになりました 守備力の強化 更なる改善
  30. | © 2026 Levtech Co., Ltd. 49 • フロントエンドにReactを導入 ◦ ユーザ体験を向上するために、テクニカルイネイブリングチームのサポートを得て、部分的

    に実装をできるようなりました • 設計思想の変化 ◦ コードの保守性・可読性を高め、事業の変化に柔軟に対応するため ▪ Package by Featureを採用し、機能単位でソースコードを整理するようにしている ▪ 関数型スタイルを導入してドメイン層にロジックを集中させるようにしている ▪ Result型による副作用を意識したエラーハンドリングを実践している • 事業部と連携強化 ◦ 事業価値のある開発を推進するために、ドメインエキスパートと会話する機会を増やして開 発部としての事業理解を向上させ、より強固な協力体制を築けるようにしている 攻撃力の強化 更なる改善
  31. | © 2026 Levtech Co., Ltd. 53 • 開発に集中する時間がなく新しいことの挑戦ができない • 基盤システムだけどレガシーシステムなので開発したくない

    • 実装するものは依頼ベースでなんのために必要なのかがわからない どんなメンタルモデルに変わったか 改善をし続けて
  32. | © 2026 Levtech Co., Ltd. 54 • 新しいことをスモールステップで取り入れやすく挑戦できるようになった • 事業領域・ドメイン分割でチームを組みコアドメインを強めるようになった

    • 事業理解が進み開発が課題を知るところから入り事業価値のあるものを開発するようになった どんなメンタルモデルに変わったか 改善をし続けて
  33. | © 2026 Levtech Co., Ltd. 57 • TiDBへの移行 ◦ 事業規模の拡大にシステムが対応できるようにする

    ◦ スケールアウトを見据え移行を進めている • EC2からECS Fargateへ移行 ◦ サーバー管理を減らして運用をもっと楽にする • 生成AIを活用した開発速度の向上 ◦ Claude CodeやCursorを使い仕様駆動開発など実験的なことを実践で行っています ◦ 特に、UI/UXはプロトタイプを作成しFBをもらえるようになりました • DDDを意識したリファクタリング そして現在。更なる改善をしています まとめ