「事業をエンジニアリングする技術者たち（3章）」 の読書メモ
本の概要はこちらから
この本に期待していたこと
具体的な事例を通して、事業にインパクトを与えるようなエンジニアリングのカルチャーや手法を学んで真似したい。
事業をエンジニアリングするとはどういう意味か、フルサイクル開発者とはどんなエンジニアか、のヒントを得たい。
前回の記事
https://note.com/yutaka_88/n/nba70f7a72343
「第3章 ECナビ 20年級大規模レガシーシステムとの戦い」より
20年以上の歴史をもつ老舗のポイントサイトを改修したお話。巨大で複雑化したレガシーシステムとどう戦っていくのか？
レガシーシステムの課題 = 影響調査の工数
いわゆる「*2025年の壁」があった。
当時の事業責任者による方針説明資料によると「既存システム変更のためには、既存領域を入念に調べ上げないといけない。しかし、それだとスピードが出ないから、既存は修正せず、機能追加していく」とあり、ある種のひずみがでていた。
具体的には…基幹DBが脈略なく乱立、使用されない・生産性の低い機能が放置、レガシー改善や保守性を上げていく試みもなく、インフラは部門が違って融通が効かない…といった状態。
*「2025年の壁」
経産省のレポートより、DXの課題として以下が挙げられている。
なおDXとは「将来の成長、競争力強化のために、新たなデジタル技術を活用して新たなビジネス・モデルを創出・柔軟に改変する」ことを指す。
・既存システムが事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化
・経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められるなか、現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている。
「技術的な課題」と「事業課題」、両方の対応が必要だった
技術的負債はエンジニアリングからも積まれていくが、多くは事業起因。そこにメスを入れる必要があった。事業として今後どうやって進めていくかをまず考え、売上成長だけでなく効率的な運営を取り入れていくべきではないかと検討した。
そこで、事業とシステムを両方とも同時に検討する横断プロジェクトを立ち上げた。結果、中長期で事業として収益を維持しつつ、時代にあったサービスを提供できるようシステムを進化させていく、という方針となった。
MEMO：システムや機能の要・不要もビジネス要件から決まってくる
まずは淡々と現状把握
方針が決まって、まずは現状把握から手をつけた。当時システム全体を把握していた人はおらず、システムをつくったエンジニアもいない状態。メンテナンスされたドキュメントも存在しなかった。
銀の弾丸はないので、地道に進めた。一般的なシステム設計書のような形で情報収集を始め、サーバーの構成図やネットワーク構成図を描き、サーバーごとの役割を解き明かしていった。
さらに、その中で実際にどんなサブシステムがあるのか、管理画面やユーザー向け画面にどんなものがあるのかを一覧表に起こし、説明を加え、分類する作業をひたすら行なった。
リバースエンジニアリングのようなツールも利用したが…ただカオスであることが分かった
自作ツールでアプリケーションのエンドポイントとそこから利用するテーブル群を動的解析し可視化してみた。しかし、事業としてまったく使われてなさそうな機能が多数出力され、機能間に謎の依存関係があったり、本来は相関性が高い機能群がまったく異なる領域に存在しているなど、現実のカオスがそのまま展開されただけだった。（この図は「お花畑」と呼ばれていた）。リバースエンジニアリングはある程度きれいに作られているシステムでないと機能しない。
ではどのように現状把握したか？
一般的なサーバー構成図、ネットワーク構成図、画面一覧は、比較的あつめやすい情報ではあるものの、それだけでは把握には不十分だった。そこで、これらの事実を集約しつつも、その行間にある文脈を担当者と泥臭く調査・ディスカッションして書き込んでいく、という合わせ技で対処した。
だいたい全ての情報をつかむまでに約1ヶ月強かかった。
MEMO：本当に必要な情報は「人」が知っている
現状把握から、レガシー攻略の大戦略を立てる
ざっくり以下のような課題が見つかった。
「1200テーブルを超えている」
「基幹システムの多くは、保守性をあげればまだ使い続けられる」
「保守するより事業価値が低い機能群が大半を占めるが、依存がありすぐ消せない」
「システム基盤のメンテナンス状況が10年単位で遅れている」
「オンプレで改善スピードがあがらない」
これだけテーブル数があり巨大になってしまうと、エンジニアが資料や一覧を真面目に読んでくれなくなる。そこで、全体を一気にビッグリライトするのではなく、コツコツ段階的に改善していく方針をとった。
具体的な方針
テーブル数が1200もあると、コツコツ改善していくにはゴールが遠すぎて厳しいものがあった。事業リスクを背負いすぎない程度に大胆な手を打つことで成功体験を積み重ねたかった。そこで、既存の基幹システムに応急処置を施して、安全に延命できるようにしてから改善に取り組むことにした。
突破策として、以下の2つがあがった。
インフラ基盤のクラウド化：できるだけ早い段階で自由度の高いインフラに移行することで、開発スピードをあげる
カオスなアプリケーション群をダイエットさせる：古くて見直しが必要な事業や業務を仕分け、コンパクトにしていく
インフラ基盤のクラウド化
長期での取り組みを考えた場合に、全体期間を短縮させる（=スピードを上げる）ため最初に取り組んだ。当時（2015年）の時点でサービスを取り巻くオンプレ環境は先行きが厳しい状態にあり、調達や運用で今後すぐに困ることも想像がついた。また、クラウド化によってアプリ開発側がインフラをコントロールできるようになり、非効率さが1つ解消されるメリットもあった。
Infrastucture as Codeも意識しており、アプリケーションエンジニアでサービス運営していくためには手順書や手作業によってサーバー構築プロセスがブラックボックス化するのを防ぐ必要があった。コード化されていればクラウド移転後に検証やテストを繰り返すことは簡単にできるので、バージョン管理システム上で運用できる状態にしておきたかった。
カオスなアプリケーション群のダイエット（=葬り）
いらないテーブルとコードを削除し、システム全体のボリュームを必要十分にする、という作戦だった。これをチーム内では「葬り」と読んでいた。これはリファクタリングではなく、機能提供そのものをやめることを含んでいる。
葬りには3つの粒度があった。
事業葬り：個別事業の取り組み自体をやめること。「売上は上がっているけど営利では赤字」のような個別事業を経営上のジャッジで切り落とす
機能葬り：重要性が落ちていて使われない機能を削ること。ログなどから使用頻度が低い、または使用されていないことを確認して削除。
コード葬り：機能は残すが、あまりうまく使われていない、もしくは消し忘れているコードを静的解析や動的解析で見つけて消し込む。
「事業葬り」 インパクトは大きいが、手間がかかる
たとえ収益性が悪くとも収益がゼロということはないし、関係者も存在する。段階的な撤退案や折衷案を出しつつ、関係者と協議しながら時間をかけて下準備する必要があった。単にシステムサイドのメリットを主張するのではなく、費用対効果や人的生産性などの経営指標で判断してもらった。
技術的負債としては根深くても、事業課題がないところは諦めて先送りにした。
「機能葬り」 地道だが確実に改善できる
事業葬りと違って収益を失うようなリスクを考慮する必要はなく、内部の運用効率の指標で判断することができる。サービスとして形は残るが、裏側はダウンサイジングして作り替えてしまうようなケース。
外部との調整が不要でフットワークが軽い反面、システムの作業としては重いケースもある。たとえば、機能としては使われていないが、既存システムと密結合で整理が必要な場合があった。スリム化のためにはまず密結合をほぐす必要があり、その後に不要となった機能を1つずつ削除、最後にテーブルを削除するような方針で行なった。コードの解析や運用関係者と相談しながら要不要を見極める必要があった。
「コード葬り」 なるべく機械的に葬る
特定のタイミングで行うようなものではなく、いまではパッケージアップデートや機能追加のときに随時行っている。葬り案件として専任で取り組むこともあるが、いま解消することのコスパを考えながら、完璧主義に陥らず、手間をかけすぎない程度に継続的に進めている。
使われていないコードを探すには機械的解析を組み合わせたり、ログやデータの更新日時を確認することで、テストがなくても「使われていなければ削除して問題なし」としている。
MEMO：コスパを見つつ、通常の開発の一部をコード葬りにつかって継続的に行う
改善の振り返り
2つの成功要因があった。
クラウド移転を先行詞、その後もシステム基盤の整備に投資し続けたこ
→足回りが飛躍的に向上し、その恩恵にうまく乗った何をやるにしても、タイミングやコスパの感覚的判断を「いい感じ」にやれたこと
→「いい感じ」＝当初決めたことに拘りすぎない・完璧主義に陥らない・バンラスよくやる・変化を恐れない
感想
巨大な問題に対峙したとき、どこから手をつけて糸口をみつけるか？の良いケーススタディだった。まずは地道に現状把握すること、その後はビジネスサイドと足並みをそろえて、全体最適で課題と対策を整理する。
長期のプロジェクトでは、時間経過とともに状況も変化していく。完璧になりすぎず、アジャイル的に「いい感じに」に進めていく柔軟さも必要になってくるだろう。
「コード葬り」については、普段の実装のなかでも意識し、継続的に取り組んでみたい。
この記事が気に入ったらサポートをしてみませんか？