🪶
著名人はシステムの再構築をどう考えているのかレポート
企業の事例や一般論、著名なエンジニアの見解をまとめた
ソースコードレベルの再生成を観点とする
言葉の定義
リプレイス？リアーキテクト？混乱しやすかったので、主要な指標
この記事では IPA の定義をベースにする
IPA 「システム再構築を成功に導くユーザガイド」
| 戦略 | 詳細設計 | プログラム設計 | ソースコード |
|---|---|---|---|
| ハードウェア更改 | 変更あり | 変更なし | 変更なし |
| リホスティング | 変更なし | 変更なし | 変更なし |
| リライト | 変更なし | 変更なし | 再生成 |
| リビルド | 再生成 | 再生成 | 再生成 |
Gartner「5 つの R」
| 戦略 | 説明 | 例 |
|---|---|---|
| リホスティング | 既存の App をほぼそのままクラウドに移行する方法 | リフト&シフト |
| リファクタリング | App のコードをクラウドに最適化するために変更する方法 | クラウドネイティブ化 |
| リバイス（更新） | App のコードを一部変更してクラウドに最適化する方法 | 一部の機能追加や修正 |
| リビルド（再構築） | App をゼロから再構築してクラウドに最適化する方法 | マイクロサービス化 |
| リプレイス（置き換え） | App を別の App に置き換える方法 | 新しい SaaS への移行 |
AWS「7R」
クラウド移行が観点なのでリンクのみ
著名人の見解 フルリライト賛成派
(完全肯定は見つからなかった…)
著名人の見解 フルリライト中立・段階的置き換え派
Martin Fowler （リファクタリングの著者）
代替手段は、古いシステムの周辺に新しいシステムを徐々に構築し、数年かけて古いシステムを絞め殺すことだ
An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled
所感
- 一気にフルリライトというより、「段階的フルリプレース」を推奨
- 部分的（段階的）に新しく置き換えることでリスクを分散できる
- 価値やフィードバックを段階的に得られる
- 失敗時のロールバックによる影響が小さい
著名人の見解 フルリライト反対派
Joel Spolsky (Stack Overflowの中の人)
ソフトウェア企業が犯しうる最悪の戦略的ミスは、コードをゼロから書き直すことだ
The single worst strategic mistake that any software company can make: rewriting the code from scratch.
所感
- 古いコードには長年のバグ修正や改善が蓄積されている
- 「汚いコード」は重要なエッジケースを扱っていることが多い
- NetScapeはフルリライトで時間をかけた結果、市場のシェアを失った
Kent Beck （XPの提唱者）
変更を容易にしてから、容易な変更を行え
Make it easy to change, then make the easy change.
所感
- 大規模リプレイスに踏み切る前に「テスト＋リファクタリングでどこまで戦えるか」を検討すべきという思想
- 現行システムをテストで守りながら、徐々に構造を変えていく
- ただし、「テストがない・設計崩壊・変更コストが高すぎる」場合はリプレイスも検討すべき
日本企業の事例
ZOZO
食べログ
メルカリ
teratail
経産省は「老朽化したシステム」が企業のDXの阻害要因となっており、
それによる機会損失を含めた影響が最大で年間12兆円に達すると試算したわけです。
「2025年の崖」というパワーワードを生み出した「DXレポート」にまとめられています。
Discussion