#133 事業をエンジニアリングする技術者たち③
こんにちは。ITベンチャーエンジニアのこへいです。
前回に引き続き、最近チームメンバーと一緒に読んでいるこの本を紹介します。
前回の記事はこちら。
〇第3章 ECナビ ― 20年級大規模レガシーシステムとの戦い
メンテナンスが困難なレガシーシステムの存在は、いわゆるDX（デジタルトランスフォーメーション）の推進に伴ってリスクが表面化する可能性が指摘され、経済産業省でも『2025年の崖』と呼んで警鐘を鳴らしています。
第3章では、ECナビという20年以上の歴史がある巨大で複雑化したレガシーシステムを、メンテナンス可能な状態にするための地道な作業を続け、ビジネスを止めないシステムへと再構築したアプローチについて紹介されています。
レガシーシステムや巨大で複雑なシステムと付き合っている私にとっては、本書の中で一番味わい深い章でした。
私の印象に残った部分をピックアップしていきます。
レガシーシステムと戦う決意をする
事業責任者による方針説明資料に「既存のシステムを変更していこうと思うと、既存の領域を入念に調べ上げないといけない。しかし、それだとスピードがでないから、既存は修正せず、機能追加していく」といった趣旨の一文があり、ある種のひずみが出ていた
それぞれの組織が独立した事業計画と開発計画で動いており、「部分最適での機能開発がそこかしこで推進されているが全体的なガバナンスがない」という組織上の問題も抱えていた
この文から、よくあるシステム・組織の課題がいっぱいで非常に苦しい状況ということが推察できます。
同じことをやるにもかかる時間がだんだん増えてしまうという技術的負債のど真ん中です。
さらに、技術的負債が多すぎてもはや手遅れでどうしようもない、誰もが改善したほうがいいと口にするが、いざやるとなると重い腰が持ち上がらない状態だが、事業は拡大の一途で技術負債が事業課題として認識されていたとのことです。
技術的負債はエンジニアリングからも積まれていきますが、多くは事業起因です。
受託開発をしている私も、営業が顧客と約束してしまった機能を実現するために負債を抱える前提で開発を進めることになったり、負債の返済のために確保していた期間に他の顧客案件を対応することになったケースが多くあります。
ECナビでは、事業とシステムの両方を同時に検討するプロジェクトを立ち上げ、中長期で事業として収益を維持しつつ時代にあったサービスに提供していけるようにシステムを進化させるという方針をとりました。
淡々とした現状把握とレガシー攻略の大戦略
まずは現状把握から始めますが、現状把握にはいわゆる銀の弾丸はなく『鉛の弾丸を打ちまくっていく作戦』を採用しています。
まずは、一般的なシステム設計書のような形で情報収集を始めました。具体的には、一般的なサーバーの構成図やネットワークの構成図を描き、サーバーごとの役割を解き明かしていくという作業です。
ということから始め、お手製のツールでのアプリケーションの解析などを重ね、カオスな現状の可視化をしています。
レガシーシステムは、現状どんな機能があるのか、それらの機能が何のためにあるのかもわからない状態がありがちで、可視化を実現した泥臭さと技術レベルの高さが純粋にすごいと思いました。
レガシーシステムの改善には大きくわけて『コツコツ改善』と『ビッグリライト』の二つのアプローチがあり、ECナビでは前者を選択しています。
既存の大規模な事業の継続と合わせて『ビッグリライト』で進めるのはリスクが大きいことを考慮して『コツコツ改善』で進める決断をし、ゴールまで辿り着いています。
私は過去に、ある顧客システムの大規模開発時に技術的負債を一気に返済するために『ビッグリライト』を実施しました。
その際は、ここを逃すと次の機会はこないと考えエイヤで決断した部分もありますが、現状把握をし、開発プロジェクトの期間の長さも考慮して実現可能性を見出し、今後の運用を見据えて決断しました。
葬りで問題の分母を減らす
カオスなアプリケーションをダイエットするための『葬り』というアプローチは衝撃でした。
葬りには『事業葬り』『機能葬り』『コード葬り』の3段階があり、それぞれを着実に進めています。
『事業葬り』は効果は絶大ですが、少しでも売り上げを上げている事業を葬ることには関係者の調整が必要で手間がかかります。技術的負債と事業課題が交わるところに狙いを絞り事業側と合意して葬りを実施しています。
『コード葬り』はなるべく機械的に随時やっており、ガーデニング感覚でやる風土が出来上がっているとのことです。通常の開発の一部として、影響範囲の近い改修に合わせて不要なコードを葬る意識が根付いているのが素晴らしいですね。
事業葬りとコード葬りの中間に位置する『機能葬り』は、内部の運用効率のような指標で判断出来る葬りで、現場担当者レベルでの調整と工夫で済むため削除量としては一番多い手法です。
これらの手法を用いてテーブル数1200の巨大システムを180テーブルまで整理したという事実にただただ驚きました。
〇第3章での学び
ECナビという20年選手のレガシーシステムとの戦いの歴史は非常に学びが深かったです。
現状把握やコード葬り、機能葬りなど、技術的なアプローチは具体的に説明会されており、すぐにでも真似出来そうです。
そして、技術的なアプローチだけでなく、事業の成長に合わせて社内外との合意形成をしながら進めていくことで大きな成果に繋げている点はとても参考になりました。
また、葬りの手法を組み合わせて着実にレガシーの改善を進め、レガシーに勝ったECナビの事例に勇気をもらえました。
私も事業課題と技術課題の交わるところに狙いを定めて改善しながら事業とシステムを同時に成長させていくことに引き続きチャレンジしていきます。
ということで『事業をエンジニアリングする技術者たち』の第3章の紹介でした。
最後までお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？