ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall

Slide 1

Slide 1 text

1 ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う株式会社ビズリーチ（Visionalグループ）リクルーティングプロダクト本部プラットフォーム開発部部長菊池信太郎

Slide 2

Slide 2 text

＃略歴前職はSIerで大小様々なプロジェクトの開発を経験し、2018年に株式会社ビズリーチに入社。現在はビズリーチ事業のプラットフォーム開発部部長として、プロダクト開発および組織づくりに取り組む。＃得意領域 ● Java / Kotlin を使ったバックエンド開発 ● システム / 組織 / 業務のデザイン ● プロジェクトマネジメント ● エンジニア採用 2 @be11 菊池信太郎自己紹介

Slide 3

Slide 3 text

3 グループ概要 (2022年7月末日時点) 6,226百万円資本金（2022年7月末日時点） 1,821名従業員数東京・大阪・名古屋・福岡静岡・広島拠点 2009年4月創業（株式会社ビズリーチ創業） 2020年2月設立（ビジョナル株式会社設立）

Slide 4

Slide 4 text

4 グループミッション

Slide 5

Slide 5 text

インキュベーション（新規事業領域）採用プラットフォーム人財活用プラットフォーム人材マネジメント（HR Tech）エコシステム M&A 物流Tech Sales Tech サイバーセキュリティ 5 運営サービス

Slide 6

Slide 6 text

急成長するサービスを支えるレガシーコード改善戦略と組織変革のアプローチ 6 本日のテーマ

Slide 7

Slide 7 text

レガシーコード改善戦略 ● レガシーコードを発端とする技術的負債とどう戦ってきたのか ● 開発・運用しやすいプロダクトへ生まれ変わるために何を考えているのか組織変革のアプローチ（チェンジマネジメント） ● 事業も組織も成長する中で、様々な課題が日々生まれている ● 技術的負債もリアーキテクチャして終わりではなく、開発をする限り生まれ続ける ● 組織変革するためにどのように考えているのか 7 本日のテーマ

Slide 8

Slide 8 text

1. レガシーコードが生まれた背景 2. 前哨戦（リスク対応） 3. 品質改善のアプローチ 4. あるべきアーキテクチャ・組織構造への変革 5. 組織変革のアプローチ 6. まとめ 7. 今後の展望 8 目次

Slide 9

Slide 9 text

9 レガシーコード改善ガイド、曰く、「レガシーコードとは、単にテストのないコードである」そもそもレガシーコードとは？ https://www.shoeisha.co.jp/book/detail/9784798116839

Slide 10

Slide 10 text

テストがないコードは変更しづらいので、改修にかかるコストが増えていく。結果、様々な技術的負債が解消されないまま残る。 10 レガシーコードは何がつらいのか？

Slide 11

Slide 11 text

11 変更容易性が失われると品質劣化のループに入る変更容易性が失われる場当たり的な修正がされるコードが複雑化するテストが書きづらくなる

Slide 12

Slide 12 text

12 質とスピード（2022春版、質疑応答用資料付き） P.49 品質劣化はリードタイムの増加を招く

Slide 13

Slide 13 text

13 レガシーコードが生まれた背景

Slide 14

Slide 14 text

14 ビズリーチ事業 C側 (ビズリーチ会員様) と B側 (直接採用企業様/ヘッドハンター様) の転職プラットフォームを提供ビジョナル株式会社 2022年7月期通期決算説明資料より

Slide 15

Slide 15 text

15 創業以来、業績は右肩上がりに成長ビジョナル株式会社 2022年10月事業計画及び成長可能性に関する説明資料より

Slide 16

Slide 16 text

16 事業を成長させるため、短期戦略が重視されてきた短期戦略利益リスク/品質短期長期組織戦略デザイン戦略プロダクトロードマップセキュリティ戦略　イノベーション SRE戦略 DevOps QA戦略プロセス改善業績コミットの施策が中心で、中長期視点での開発は計画的に進められていなかった。

Slide 17

Slide 17 text

17 技術的負債が積み重なり、生産性が低下時間保守コスト生産性次第に影響調査、障害対応などに時間がとられるようになってしまった。品質劣化がリードタイムの増加を招いた。

Slide 18

Slide 18 text

デリバリに過度なプレッシャー ● 事業が急成長していると、技術的負債を生んでしまう意思決定が起こりやすい ● QCDSのうちコスト、納期、スコープが固定されると品質が下がる密結合で凝集度が低いプログラム構造が原因でテストが書きづらい ● プレゼンテーションロジックとドメインロジックがちゃんと分離されていない ● API呼び出しやDBアクセスなど副作用がドメインロジックと同じ場所にあった ● 度重なる変更でスパゲッティ化したコードは何をやってるのかを読み解くのも一苦労大規模プロジェクトを計画し、実行しきる組織力が不足 ● 過去これまでに何度か技術的負債解消プロジェクトは立ち上がってはいた ● 短期間の課題解決能力は高いが、プロジェクトマネジメントの経験が浅い傾向があった 18 レガシーコードの生まれた原因分析

Slide 19

Slide 19 text

19 前哨戦（リスク対応）

Slide 20

Slide 20 text

20 ● 過去何度か技術的負債解消のアプローチはとられていたが、中途半端に終わっていたため、アーキテクチャに関する認知負荷が拡大 ● データ量が激増したことで、スロークエリが発生し、パフォーマンス低下 ● 簡易なログ監視しかできておらず、モニタリングが不足 ● 暗黙知が多く、大きい機能修正を入れると緊急リリースが多発 2018年サービス成長が加速し、綻びが見え始めた

Slide 21

Slide 21 text

21 CTOによる緊急事態宣言で半年間新規開発をストップ重要度（高）重要度（低）緊急度（低）緊急度（高）セキュリティ対応経営や事業部へプロダクトの状況を説明し、新規開発を完全にストップ。緊急かつ重要な課題にフォーカスして対応。モニタリングできてないスロークエリが頻発プロセスが開発規模に追いついてない緊急リリースが多いエラーログが多い大規模プロジェクトの計画・実行がうまくできないジュニア比率が多いアーキテクチャが古いテストがなく、変更しづらい会計監査/ 内部統制監査対策

Slide 22

Slide 22 text

Datadogによるモニタリング強化 ● 現状把握と改善の効果がわかるようにスロークエリを改善する ● 地道にIndex張ったり、N+1の処理を発見して修正したり ● テーブル設計に起因するものはテーブルリファクタリングオオカミ少年化していたエラーログを減らす ● ログレベルを見直し、 error である必要がないものは warn に変更 ● とにかく地道に1つずつ潰す 22 リスク対応①

Slide 23

Slide 23 text

社内のセキュリティ室/ホワイトハッカーによる脆弱性検査を継続的に実施 ● 会社にとって最も大きいリスクの1つはセキュリティリスク ● 都度検出した脆弱性は対応する運用を確立脆弱性の多いWebフレームワークのリプレース（Struts2→SpringMVC） ● 主要アプリケーションを全て作り直す選択肢もあったが、時間がかかりすぎる ● いつ上場してもおかしくなかったので、まずは最速でリスク排除を優先 ● プロジェクト化し、段階的にSpringMVCに置き換えていった 23 リスク対応②

Slide 24

Slide 24 text

24 QAコストをかけて緊急リリースを減らす QAコストで品質を買いにいく・検証環境での人力担保・根本的改善により徐々に削減・最低限のE2Eテストを運用開始根本的改善を進める・プロセス改善による、より上流での検知・疎結合化による責任分離、自動的な担保時間品質 QAコスト

Slide 25

Slide 25 text

根本的な改善には至っていないものの、いったん止血はできた ● モニタリングを強化することによって、システムの健康状態を把握できるようになった ● データ量が伸び続ける中で、パフォーマンス問題が一定解消した ● エラーログが減ったので監視しやすくなった ● E2EテストとQAテストによる品質担保がされるようになった ● 少しずつ開発チームが品質を意識するようになっていった同じ過ちを繰り返さないために ● 変更容易性を失うと後手に回るので、早い段階でレガシーコードを生む構造はなくす ● プロダクト開発のあらゆる活動をモニタリングすることで現状を把握し続けることが大事 25 緊急事態宣言とリスク対応の振り返り

Slide 26

Slide 26 text

26 品質改善のアプローチ

Slide 27

Slide 27 text

解消すべき運用課題をリストアップ ● 機能追加及び変更のしやすさ ● テスタビリティ ● オーナーシップ ● デプロイメント ● 監視 ● スケーラビリティ ● オンボーディング ● etc… 27 運用課題の解消に向けて作戦を練る

Slide 28

Slide 28 text

変更容易性とテスト容易性の改善 ● 変更とテストがしやすいように実装されていればなんとでもなる ● オブジェクト指向プログラミングおよびDDDの考え方をベースに作り変えるあるべきアーキテクチャ・組織構造への変革 ● 事業戦略と課題分析をもとに、あるべきアーキテクチャ・組織構造を描く ● 段階的に新システムへ移行していくことで、戦略を実現できるプロダクトへ変える組織・プロセスの改善 ● 採用、育成、マネジメント強化によって、戦略実現に必要なケイパビリティを獲得する ● DevOps、QA、セキュリティ戦略を実現できるプロセスへ変える 28 基本方針

Slide 29

Slide 29 text

ソフトウェアは変更に晒され続けるため、 5つの品質特性は「保守性」に依存しているとも考えられる 29 6つのソフトウェア品質特性（ISO/IEC9126） http://objectclub.jp/technicaldoc/object-orientation/OO_redefine/redefine03 から引用保守性信頼性機能性使用性効率性移植性

Slide 30

Slide 30 text

● 変更とテストがしやすいように、凝集度を高める ● 変更とテストがしやすいように、疎結合にする ● 変更とテストがしやすいように、テストピラミッドを形成する ● 変更とテストがしやすいように、関心事を分ける ● 変更とテストがしやすいように、ドメインモデルを作る ● 変更とテストがしやすいように、単体テストを書く ● 各チームが変更とテストがしやすいように、アーキテクチャを考える ● 各チームが変更とテストがしやすいように、組織を考える ● 各チームが変更とテストがしやすいように、プロセスを考える ● ・・・ 30 特に変更容易性とテスト容易性にフォーカス

Slide 31

Slide 31 text

機能拡充は品質改善もできるチャンスなので有効活用 ● 機能拡充前に単体テストを整え、リファクタリングする ● 各所に散らばっていたロジックをドメインモデルに集約する ● テスト設計を行い、仕様をドキュメントに残すことで暗黙知を減らす ● 可能であれば、仕様および設計をシンプルに再構成して、PdMや事業部と調整する 31 短期的成果を出しつつ変更容易性を少しずつ改善会員様向けアプリのリニューアルプレミアム会員様向けサービス新規開発

Slide 32

Slide 32 text

リアーキテクチャを成功させるために、成功確率が高いものから着手する ● まずはステークホルダーが少ないヘッドハンター様向けプロダクトから着手 ● ステークホルダーが多いと合意形成に時間がかかる ● また、お客様のペルソナが様々だと時間がかかり、リスクも高い 32 リアーキテクチャ（SPA化・API化）事始め

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

戦略とは、「われわれの事業は何か、何になるか、何であるべきか」との問いへの答えである。組織構造を決めるのは、この戦略である。戦略が組織の基本活動を決める。優れた組織構造とは、それらの基本活動が成果をあげる構造にほかならない。ドラッカー. マネジメント［エッセンシャル版］ (Japanese Edition) (Kindle の位置No.2418-2420). ダイヤモンド社. Kindle 版. 37 組織は戦略に従う

Slide 38

Slide 38 text

コンウェイの法則システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう。逆コンウェイ戦略コンウェイの法則を逆手にとって、チームや組織構造を進化させ、望ましいアーキテクチャを推進すること。テクノロジー・アーキテクチャが、ビジネス・アーキテクチャと同型になるようにする。出典：Inverse Conway Maneuver | Technology Radar | Thoughtworks 38 アーキテクチャと組織構造は表裏一体

Slide 39

Slide 39 text

● アーキテクチャは、組織構造とセットで考える ● 目的・戦略から考えないと、成果をあげる構造を作り出せない ● HOW先行でマイクロサービス化などを推進してもうまくいかないので、常に目的に立ち返る 39 戦略によってあるべきアーキテクチャ、組織構造は決まる

Slide 40

Slide 40 text

Explicitly deﬁne the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within speciﬁc parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside. ― 『Domain-Driven Design: Tackling Complexity in the Heart of Software』モデルが適用されるコンテキストを明示的に定義する。チーム組織、アプリケーションの特定の部分における使用、コードベースやデータベーススキーマのような物理的な表現など、境界を明示的に設定します。これらの境界内ではモデルの一貫性を厳密に保ちますが、境界外の問題に惑わされたり混乱したりしないようにします。 40 境界づけられたコンテキストでシステムを分離する https://martinfowler.com/bliki/BoundedContext.html

Slide 41

Slide 41 text

一気通貫で開発できるチームを目指す ● チームに責務を割り当て、ステークホルダーとのコミュニケーションから任せる ● APIを通して他のチームとコミュニケーションをとる境界を定める時はコミュニケーションパスを事前に設計する ● 他の開発チームおよびステークホルダーとのコミュニケーションが最小限で済むようにする ● ステークホルダーを早期から巻き込み、議論していく 41 境界づけられたコンテキストでシステムを分離する

Slide 42

Slide 42 text

切り出すことで受けられる恩恵が大きいコンテキストをマイクロサービスとして作り直すことを決定 42 境界づけられたコンテキストでシステムを分離する

Slide 43

Slide 43 text

ストラングラーパターンで段階的に移行 ● 『モノリスからマイクロサービスへ』でも紹介されている手法 ● 新規システムでAPIを実装し、旧システムから少しずつ置き換えていく ● 移行が完了したら旧システムのコードは消す 43 境界づけられたコンテキストでシステムを分離する https://martinfowler.com/bliki/Stran glerFigApplication.html https://www.oreilly.co.jp/books/9 784873119311/

Slide 44

Slide 44 text

チームでドメイン知識を獲得する ● もともとドメイン知識を持っているメンバーが少数で属人化しているという課題があった ● モブプロを通して設計意図を伝えながらチームビルディング ● 業務フローからデータモデルに至るまで必要十分な設計情報をドキュメント化 ● ドメインモデリングを通じて新たなモデルの発見とコード改善 44 境界づけられたコンテキストでシステムを分離するユースケース図状態遷移図ドメインモデリングとクラス設計

Slide 45

Slide 45 text

45 組織変革のアプローチ

Slide 46

Slide 46 text

マッキンゼーの7Sを用いて整理する 46 戦略を実現するためのチェンジマネジメント Strategy （戦略） Structure （組織構造） Systems （経営システム） Shared Value （共通の価値観） Staﬀ （人材） Skills （組織のスキル） Style （組織文化）

Slide 47

Slide 47 text

マッキンゼーの7Sを用いて整理する 47 戦略を実現するためのチェンジマネジメント Strategy （戦略） Structure （組織構造） Systems （経営システム） Shared Value （共通の価値観） Staﬀ （人材） Skills （組織のスキル） Style （組織文化）ハードの3S （戦略・構造・システム） →着手しやすいソフトの4S （共通の価値観・文化・スキル・人材） →変更に時間がかかる

Slide 48

Slide 48 text

1. 組織の現状を分析する 2. 7Sに沿って問題の原因を深堀る 3. 優先度の高い課題を抽出する 4. 改善案を出す 5. アクションプランを立てる 6. 実行する 7. 振り返る 48 改善の流れ

Slide 49

Slide 49 text

Strategy（戦略） ● 「キャリアインフラ」はどうあるべきか、どのように達成するか言語化 ● ロードマップを作り、適宜更新しながら必要なリソースを再配置 Structure（組織構造） ● ミッションに基づいた各組織ユニットの再設計 ● 縦・横の兼務を解消し、ラインマネジメントをあるべき形へ Systems（システム） ● 予算管理、目標管理、採用管理の予実を可視化 ● 経営指標をモニタリングするために必要な仕組みづくり ● 組織変更に合わせた会議体の再設計 49 まずはハードの3Sから改善を着手

Slide 50

Slide 50 text

50 ● 月次でロードマップを見直す ● 週次で施策の提案、共有、相談を実施 ● リスクの早期発見と対処、優先順位付け反復的、継続的な意思決定で計画と実行のリズムを作る各プロダクトオーナー + 経営メンバー中長期ロードマップ短期ロードマップ月次報告トピックス確認優先順位をつける評価振り返り実施計画 ROIの責任を負う提案、共有、相談持ち込み

Slide 51

Slide 51 text

51 開発チームも計画と実行のリズムを作って改善し続けるプロダクトオーナープロダクトバックログスプリント計画スプリントレビューレトロスペクティブスプリントカンバンボード開発チーム優先順位をつける実施計画評価振り返り生産性を向上させる ROIの責任を負うデイリースクラム

Slide 52

Slide 52 text

Shared Value（共通の価値観） ● 創業以来続けている通り、採用で見極め、 Mission / Value を日々体現 Style（組織文化） ● 良いエンジニアリング文化の形成（QCDS意識 / ドキュメンテーション / DevOpsなど） Skills（組織のスキル） ● ミドルマネジメントの強化 ● 個々のプロジェクトマネジメント力向上 Staff（人材） ● あるべきアーキテクチャ、組織構造に足りない人材の採用 ● 適所適材の実現 52 ソフトの4Sは継続して改善中

Slide 53

Slide 53 text

53 まとめ

Slide 54

Slide 54 text

現状を把握し、課題分析から始めるプロダクトや組織の状況は会社ごとに様々。まずは現状を把握し、何をやらなければいけないのか考える。 54

Slide 55

Slide 55 text

古典と歴史に学ぶソフトウェア開発の現場でよくある課題への対策方針は大体ある。 55

Slide 56

Slide 56 text

ベストプラクティスに学ぶ現在のプロダクトとの差分はなにか？を問い続ける。ただし、オーバーエンジニアリングには気をつける。 56

Slide 57

Slide 57 text

改善は段階的に極力ビッグバン・リリースは避ける。経営との合意形成や期待値調整をちゃんとやる。 57

Slide 58

Slide 58 text

経営の意思も必要ボトムアップだけでは継続的な品質改善はできない。トップダウンとボトムアップの調和こそ目指す姿。 58

Slide 59

Slide 59 text

銀の弾丸はない目的・戦略から逆算し、やるべきことをやる。（As-Isを把握、To-Beを描く、課題分析、優先順位づけ、振り返り） 59

Slide 60

Slide 60 text

60 今後の展望

Slide 61

Slide 61 text

61 基本方針は変わらず、やるべきことをやる変更容易性とテスト容易性の改善 ● 変更とテストがしやすいように実装されていればなんとでもなる ● オブジェクト指向プログラミングおよびDDDの考え方をベースに作り変えるあるべきアーキテクチャ・組織構造への変革 ● 事業戦略と課題分析をもとに、あるべきアーキテクチャ・組織構造を描く ● 段階的に新システムへ移行していくことで、戦略を実現できるプロダクトへ変える組織・プロセスの改善 ● 採用、育成、マネジメント強化によって、戦略実現に必要なケイパビリティを獲得する ● DevOps、QA、セキュリティ戦略を実現できるプロセスへ変える

Slide 62

Slide 62 text

62 ソフトウェア開発プロセスをさらに改善する取り組み https://confengine.com/conferences/devopsdays-tokyo-2022/proposal/16436/leandevops

Slide 63

Slide 63 text

63 2023年1月のイベントでも改善活動をご紹介予定 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17617/-

Slide 64

Slide 64 text

64 BlogとTwitterで発信中！ Blog Twitter https://engineering.visional.inc/blog/ @VISIONAL_ENG Visionalの技術的な取り組みや、イベント・登壇情報などをお届けします