ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall

2022年11月27日に開催された「JJUG CCC 2022 Fall」の登壇資料です。
https://ccc2022fall.java-users.jp/

-----
Visionalのエンジニアリングに関する最新情報はTwitter、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING Twitter
https://twitter.com/VISIONAL_ENG

Transcript

1. 1 ユーザー数100万人規模の事業成長を止めずに、 レガシーコードと戦う 株式会社ビズリーチ（Visionalグループ） リクルーティングプロダクト本部 プラットフォーム開発部部長 菊池 信太郎
2. ＃略歴 前職はSIerで大小様々なプロジェクトの開発を経験し、2018年に株 式会社ビズリーチに入社。 現在はビズリーチ事業のプラットフォーム開発部部長として、プロダク ト開発および組織づくりに取り組む。 ＃得意領域 • Java / Kotlin を使ったバックエンド開発 • システム / 組織 / 業務のデザイン • プロジェクトマネジメント • エンジニア採用 2 @be11 菊池 信太郎 自己紹介
3. 3 グループ概要 (2022年7月末日時点) 6,226百万円 資本金 （2022年7月末日時点） 1,821名 従業員数 東京・大阪・名古屋・福岡 静岡・広島 拠点 2009年4月 創業 （株式会社ビズリーチ創業） 2020年2月 設立 （ビジョナル株式会社設立）
4. 4 グループミッション
5. インキュベーション（新規事業領域） 採用プラットフォーム 人財活用プラットフォーム 人材マネジメント（HR Tech）エコシステム M&A 物流Tech Sales Tech サイバーセキュリティ 5 運営サービス
6. 急成長するサービスを支える レガシーコード改善戦略と 組織変革のアプローチ 6 本日のテーマ
7. レガシーコード改善戦略 • レガシーコードを発端とする技術的負債とどう戦ってきたのか • 開発・運用しやすいプロダクトへ生まれ変わるために何を考えているのか 組織変革のアプローチ（チェンジマネジメント） • 事業も組織も成長する中で、様々な課題が日々生まれている • 技術的負債もリアーキテクチャして終わりではなく、開発をする限り生まれ続ける • 組織変革するためにどのように考えているのか 7 本日のテーマ
8. 1. レガシーコードが生まれた背景 2. 前哨戦（リスク対応） 3. 品質改善のアプローチ 4. あるべきアーキテクチャ・組織構造への変革 5. 組織変革のアプローチ 6. まとめ 7. 今後の展望 8 目次
9. 9 レガシーコード改善ガイド、曰く、 「レガシーコードとは、単にテストのないコードである」 そもそもレガシーコードとは？ https://www.shoeisha.co.jp/book/detail/9784798116839
10. テストがないコードは変更しづらいので、 改修にかかるコストが増えていく。 結果、様々な技術的負債が解消されないまま残る。 10 レガシーコードは何がつらいのか？
11. 11 変更容易性が失われると品質劣化のループに入る 変更容易性が 失われる 場当たり的な 修正がされる コードが 複雑化する テストが 書きづらくなる
12. 12 質とスピード（2022春版、質疑応答用資料付き） P.49 品質劣化はリードタイムの増加を招く
13. 13 レガシーコードが生まれた背景
14. 14 ビズリーチ事業 C側 (ビズリーチ会員様) と B側 (直接採用企業様/ヘッドハンター様) の 転職プラットフォームを提供 ビジョナル株式会社 2022年7月 期通期決算説明資料より
15. 15 創業以来、業績は右肩上がりに成長 ビジョナル株式会社 2022年10月 事業計画及び成長可能性に関する説明資料より
16. 16 事業を成長させるため、短期戦略が重視されてきた 短期戦略 利益 リスク/品質 短期 長期 組織戦略 デザイン戦略 プロダクトロードマップ セキュリティ戦略 　イノベーション SRE戦略 DevOps QA戦略 プロセス改善 業績コミットの施策が中心で、 中長期視点での開発は計画的に進められていなかった。
17. 17 技術的負債が積み重なり、生産性が低下 時間 保守コスト 生産性 次第に影響調査、障害対応などに時間がとられるようになってしまった。 品質劣化がリードタイムの増加を招いた。
18. デリバリに過度なプレッシャー • 事業が急成長していると、技術的負債を生んでしまう意思決定が起こりやすい • QCDSのうちコスト、納期、スコープが固定されると品質が下がる 密結合で凝集度が低いプログラム構造が原因でテストが書きづらい • プレゼンテーションロジックとドメインロジックがちゃんと分離されていない • API呼び出しやDBアクセスなど副作用がドメインロジックと同じ場所にあった • 度重なる変更でスパゲッティ化したコードは何をやってるのかを読み解くのも一苦労 大規模プロジェクトを計画し、実行しきる組織力が不足 • 過去これまでに何度か技術的負債解消プロジェクトは立ち上がってはいた • 短期間の課題解決能力は高いが、プロジェクトマネジメントの経験が浅い傾向があった 18 レガシーコードの生まれた原因分析
19. 19 前哨戦（リスク対応）
20. 20 • 過去何度か技術的負債解消のアプローチはとられていたが、中途半端に終わっていたため、アーキテ クチャに関する認知負荷が拡大 • データ量が激増したことで、スロークエリが発生し、パフォーマンス低下 • 簡易なログ監視しかできておらず、モニタリングが不足 • 暗黙知が多く、大きい機能修正を入れると緊急リリースが多発 2018年サービス成長が加速し、綻びが見え始めた
21. 21 CTOによる緊急事態宣言で半年間新規開発をストップ 重要度（高） 重要度（低） 緊急度（低） 緊急度（高） セキュリ ティ対応 経営や事業部へプロダクトの状況を説明し、新規開発を完全にストップ。 緊急かつ重要な課題にフォーカスして対応。 モニタリン グできてな い スロークエ リが頻発 プロセスが開 発規模に追い ついてない 緊急リリー スが多い エラーログ が多い 大規模プロ ジェクトの計 画・実行がう まくできない ジュニア比 率が多い アーキテク チャが古い テストがな く、変更し づらい 会計監査/ 内部統制監 査対策
22. Datadogによるモニタリング強化 • 現状把握と改善の効果がわかるように スロークエリを改善する • 地道にIndex張ったり、N+1の処理を発見して修正したり • テーブル設計に起因するものはテーブルリファクタリング オオカミ少年化していたエラーログを減らす • ログレベルを見直し、 error である必要がないものは warn に変更 • とにかく地道に1つずつ潰す 22 リスク対応①
23. 社内のセキュリティ室/ホワイトハッカーによる脆弱性検査を継続的に実施 • 会社にとって最も大きいリスクの1つはセキュリティリスク • 都度検出した脆弱性は対応する運用を確立 脆弱性の多いWebフレームワークのリプレース（Struts2→SpringMVC） • 主要アプリケーションを全て作り直す選択肢もあったが、時間がかかりすぎる • いつ上場してもおかしくなかったので、まずは最速でリスク排除を優先 • プロジェクト化し、段階的にSpringMVCに置き換えていった 23 リスク対応②
24. 24 QAコストをかけて緊急リリースを減らす QAコストで品質を買いにいく ・検証環境での人力担保 ・根本的改善により徐々に削減 ・最低限のE2Eテストを運用開始 根本的改善を進める ・プロセス改善による、より上流での検知 ・疎結合化による責任分離、自動的な担保 時間 品質 QAコスト
25. 根本的な改善には至っていないものの、いったん止血はできた • モニタリングを強化することによって、システムの健康状態を把握できるようになった • データ量が伸び続ける中で、パフォーマンス問題が一定解消した • エラーログが減ったので監視しやすくなった • E2EテストとQAテストによる品質担保がされるようになった • 少しずつ開発チームが品質を意識するようになっていった 同じ過ちを繰り返さないために • 変更容易性を失うと後手に回るので、早い段階でレガシーコードを生む構造はなくす • プロダクト開発のあらゆる活動をモニタリングすることで現状を把握し続けることが大事 25 緊急事態宣言とリスク対応の振り返り
26. 26 品質改善のアプローチ
27. 解消すべき運用課題をリストアップ • 機能追加及び変更のしやすさ • テスタビリティ • オーナーシップ • デプロイメント • 監視 • スケーラビリティ • オンボーディング • etc… 27 運用課題の解消に向けて作戦を練る
28. 変更容易性とテスト容易性の改善 • 変更とテストがしやすいように実装されていればなんとでもなる • オブジェクト指向プログラミングおよびDDDの考え方をベースに作り変える あるべきアーキテクチャ・組織構造への変革 • 事業戦略と課題分析をもとに、あるべきアーキテクチャ・組織構造を描く • 段階的に新システムへ移行していくことで、戦略を実現できるプロダクトへ変える 組織・プロセスの改善 • 採用、育成、マネジメント強化によって、戦略実現に必要なケイパビリティを獲得する • DevOps、QA、セキュリティ戦略を実現できるプロセスへ変える 28 基本方針
29. ソフトウェアは変更に晒され続けるため、 5つの品質特性は「保守性」に依存しているとも考えられる 29 6つのソフトウェア品質特性（ISO/IEC9126） http://objectclub.jp/technicaldoc/object-orientation/OO_redefine/redefine03 から引用 保守性 信頼性 機能性 使用性 効率性 移植性
30. • 変更とテストがしやすいように、凝集度を高める • 変更とテストがしやすいように、疎結合にする • 変更とテストがしやすいように、テストピラミッドを形成する • 変更とテストがしやすいように、関心事を分ける • 変更とテストがしやすいように、ドメインモデルを作る • 変更とテストがしやすいように、単体テストを書く • 各チームが変更とテストがしやすいように、アーキテクチャを考える • 各チームが変更とテストがしやすいように、組織を考える • 各チームが変更とテストがしやすいように、プロセスを考える • ・・・ 30 特に変更容易性とテスト容易性にフォーカス
31. 機能拡充は品質改善もできるチャンスなので有効活用 • 機能拡充前に単体テストを整え、リファクタリングする • 各所に散らばっていたロジックをドメインモデルに集約する • テスト設計を行い、仕様をドキュメントに残すことで暗黙知を減らす • 可能であれば、仕様および設計をシンプルに再構成して、PdMや事業部と調整する 31 短期的成果を出しつつ変更容易性を少しずつ改善 会員様向けアプリのリニューアル プレミアム会員様向けサービス新規開発
32. リアーキテクチャを成功させるために、成功確率が高いものから着手する • まずはステークホルダーが少ないヘッドハンター様向けプロダクトから着手 • ステークホルダーが多いと合意形成に時間がかかる • また、お客様のペルソナが様々だと時間がかかり、リスクも高い 32 リアーキテクチャ（SPA化・API化）事始め
33. 33 新旧プロダクトの並行稼動 お客様の体験が変わる場合、新旧プロダクトの並行稼動を検討 • 並行稼動期間中にお客様の声をもとに改善していった • ログイン状態を維持しながら、新旧システムをシームレスに切り替えて利用可能に • いくつか発生したリリース後不具合も旧システムをご利用いただくことでクリティカルな状況を回避でき た ※こちらはヘッドハンター様向けサービスの画面です 【新】 【旧】
34. 34 サポートサイトを新設 ※こちらはヘッドハンター様向けサービスの画面です
35. 35 リアーキテクチャの成果 大規模な改善を行ったチームとのコード量の差 レガシーシステムに携わっているチームのコード量 大規模な改善を行ったチームのコード量 プロダクト課題の改善が最低限しか行えていないプロダク トではコードの削減量（濃い色）と追加量（薄い色）の差 分が少なく、付加価値を生み出せていない。 リアーキテクチャを行ったプロダクトでは、安定的に付加 価値を生み出せている。コード量も安定している。
36. 36 あるべきアーキテクチャ・組織構造への変革
37. 戦略とは、「われわれの事業は何か、何になるか、何であるべきか」との問いへの答えである。 組織構造を決めるのは、この戦略である。戦略が組織の基本活動を決める。 優れた組織構造とは、それらの基本活動が成果をあげる構造にほかならない。 ドラッカー. マネジメント［エッセンシャル版］ (Japanese Edition) (Kindle の位置No.2418-2420). ダイヤモンド社. Kindle 版. 37 組織は戦略に従う
38. コンウェイの法則 システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう。 逆コンウェイ戦略 コンウェイの法則を逆手にとって、チームや組織構造を進化させ、望ましいアーキテクチャを推進すること。 テクノロジー・アーキテクチャが、ビジネス・アーキテクチャと同型になるようにする。 出典：Inverse Conway Maneuver | Technology Radar | Thoughtworks 38 アーキテクチャと組織構造は表裏一体
39. • アーキテクチャは、組織構造とセットで考える • 目的・戦略から考えないと、成果をあげる構造を作り出せない • HOW先行でマイクロサービス化などを推進してもうまくいかないので、常に目的に立ち返る 39 戦略によってあるべきアーキテクチャ、組織構造は決まる
40. Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific 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
41. 一気通貫で開発できるチームを目指す • チームに責務を割り当て、ステークホルダーとのコミュニケーションから任せる • APIを通して他のチームとコミュニケーションをとる 境界を定める時はコミュニケーションパスを事前に設計する • 他の開発チームおよびステークホルダーとのコミュニケーションが最小限で済むようにする • ステークホルダーを早期から巻き込み、議論していく 41 境界づけられたコンテキストでシステムを分離する
42. 切り出すことで受けられる恩恵が大きいコンテキストを マイクロサービスとして作り直すことを決定 42 境界づけられたコンテキストでシステムを分離する
43. ストラングラーパターンで段階的に移行 • 『モノリスからマイクロサービスへ』でも紹介されている手法 • 新規システムでAPIを実装し、旧システムから少しずつ置き換えていく • 移行が完了したら旧システムのコードは消す 43 境界づけられたコンテキストでシステムを分離する https://martinfowler.com/bliki/Stran glerFigApplication.html https://www.oreilly.co.jp/books/9 784873119311/
44. チームでドメイン知識を獲得する • もともとドメイン知識を持っているメンバーが少数で属人化しているという課題があった • モブプロを通して設計意図を伝えながらチームビルディング • 業務フローからデータモデルに至るまで必要十分な設計情報をドキュメント化 • ドメインモデリングを通じて新たなモデルの発見とコード改善 44 境界づけられたコンテキストでシステムを分離する ユースケース図 状態遷移図 ドメインモデリング とクラス設計
45. 45 組織変革のアプローチ
46. マッキンゼーの7Sを用いて整理する 46 戦略を実現するためのチェンジマネジメント Strategy （戦略） Structure （組織構造） Systems （経営システム） Shared Value （共通の価値観） Staff （人材） Skills （組織のスキル） Style （組織文化）
47. マッキンゼーの7Sを用いて整理する 47 戦略を実現するためのチェンジマネジメント Strategy （戦略） Structure （組織構造） Systems （経営システム） Shared Value （共通の価値観） Staff （人材） Skills （組織のスキル） Style （組織文化） ハードの3S （戦略・構造・システム） →着手しやすい ソフトの4S （共通の価値観・文化・スキル・人材） →変更に時間がかかる
48. 1. 組織の現状を分析する 2. 7Sに沿って問題の原因を深堀る 3. 優先度の高い課題を抽出する 4. 改善案を出す 5. アクションプランを立てる 6. 実行する 7. 振り返る 48 改善の流れ
49. Strategy（戦略） • 「キャリアインフラ」はどうあるべきか、どのように達成するか言語化 • ロードマップを作り、適宜更新しながら必要なリソースを再配置 Structure（組織構造） • ミッションに基づいた各組織ユニットの再設計 • 縦・横の兼務を解消し、ラインマネジメントをあるべき形へ Systems（システム） • 予算管理、目標管理、採用管理の予実を可視化 • 経営指標をモニタリングするために必要な仕組みづくり • 組織変更に合わせた会議体の再設計 49 まずはハードの3Sから改善を着手
50. 50 • 月次でロードマップを見直す • 週次で施策の提案、共有、相談を実施 • リスクの早期発見と対処、優先順位付け 反復的、継続的な意思決定で計画と実行のリズムを作る 各プロダクトオーナー + 経営メンバー 中長期ロード マップ 短期ロード マップ 月次報告 トピックス確 認 優先順位をつける 評価 振り返り 実施計画 ROIの責任を負う 提案、共有、相談持 ち込み
51. 51 開発チームも計画と実行のリズムを作って改善し続ける プロダクトオーナー プロダクト バックログ スプリント計 画 スプリントレ ビュー レトロスペク ティブ スプリント カンバンボー ド 開発チーム 優先順位をつける 実施計画 評価 振り返り 生産性を向上させる ROIの責任を負う デイリー スクラム
52. Shared Value（共通の価値観） • 創業以来続けている通り、採用で見極め、 Mission / Value を日々体現 Style（組織文化） • 良いエンジニアリング文化の形成（QCDS意識 / ドキュメンテーション / DevOpsなど） Skills（組織のスキル） • ミドルマネジメントの強化 • 個々のプロジェクトマネジメント力向上 Staff（人材） • あるべきアーキテクチャ、組織構造に足りない人材の採用 • 適所適材の実現 52 ソフトの4Sは継続して改善中
53. 53 まとめ
54. 現状を把握し、課題分析から始める プロダクトや組織の状況は会社ごとに様々。 まずは現状を把握し、何をやらなければいけないのか考える。 54
55. 古典と歴史に学ぶ ソフトウェア開発の現場でよくある課題への対策方針は大体ある。 55
56. ベストプラクティスに学ぶ 現在のプロダクトとの差分はなにか？を問い続ける。 ただし、オーバーエンジニアリングには気をつける。 56
57. 改善は段階的に 極力ビッグバン・リリースは避ける。 経営との合意形成や期待値調整をちゃんとやる。 57
58. 経営の意思も必要 ボトムアップだけでは継続的な品質改善はできない。 トップダウンとボトムアップの調和こそ目指す姿。 58
59. 銀の弾丸はない 目的・戦略から逆算し、やるべきことをやる。 （As-Isを把握、To-Beを描く、課題分析、優先順位づけ、振り返り） 59
60. 60 今後の展望
61. 61 基本方針は変わらず、やるべきことをやる 変更容易性とテスト容易性の改善 • 変更とテストがしやすいように実装されていればなんとでもなる • オブジェクト指向プログラミングおよびDDDの考え方をベースに作り変える あるべきアーキテクチャ・組織構造への変革 • 事業戦略と課題分析をもとに、あるべきアーキテクチャ・組織構造を描く • 段階的に新システムへ移行していくことで、戦略を実現できるプロダクトへ変える 組織・プロセスの改善 • 採用、育成、マネジメント強化によって、戦略実現に必要なケイパビリティを獲得する • DevOps、QA、セキュリティ戦略を実現できるプロセスへ変える
62. 62 ソフトウェア開発プロセスをさらに改善する取り組み https://confengine.com/conferences/devopsdays-tokyo-2022/proposal/16436/leandevops
63. 63 2023年1月のイベントでも改善活動をご紹介予定 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17617/-
64. 64 BlogとTwitterで発信中！ Blog Twitter https://engineering.visional.inc/blog/ @VISIONAL_ENG Visionalの技術的な取り組みや、イベント・登壇情報などをお届けします