みなさん、こんにちは。
最近、Adobe Illustrator 2025の不具合が話題になっています。文字レイアウトの崩れ、フォントのランダムな置き換え、オブジェクトの予期せぬ移動、クラッシュ時の復元失敗、さらには保存最適化機能によるデータ破損など、ユーザーの間で「これでプロユースは厳しい」という不満が噴出しています。
これらは一見、単なる品質問題のように見えますが、根底には「レガシーコードとの戦い」という、ソフトウェア開発の永遠の課題が潜んでいます。
古いコードの上に新機能を積み上げるという地獄
Illustratorは30年以上の歴史を持つ老舗アプリケーションです。その間にOSは変わり、CPUアーキテクチャも変わり、そして今はAI機能の統合まで進んでいます。
これだけ長い年月を経ると、もはや「最初の設計者が想定していなかった状態」で動いている箇所が無数に存在します。
過去のコードベースを保ちつつ新機能を追加するというのは、まるで木造家屋の中に最新の電気配線を通そうとするようなもの。どこかに無理が出るのは当然です。
テストが足りないという指摘もありますが、実際には「何をテストすべきか分からない」ほど複雑に絡み合っているのかもしれません。
同じ苦しみを味わった企業たち – ドワンゴとMozillaの例
過去にも似た例があります。
ニコニコ動画を運営するドワンゴは、古いアーキテクチャのまま機能追加を続けた結果、サービス全体のレスポンスが遅くなり、大規模アップデートで長期間の混乱を経験しました。
一方、MozillaのFirefoxも同じように、かつての設計のままではブラウザとしての進化が限界に達し、Quantumプロジェクトで抜本的な刷新に踏み切りましたが、リリースまでに長期間を要しました。
結果として、どちらも新バージョンを出すことには成功しましたが、停滞していた時間の間に多くのユーザーが他のサービスへ移ってしまったのも事実です。
技術的には「成功」、しかしビジネス的には「痛みを伴うリセット」だったわけです。
そして今、Adobeも同じ岐路に立たされているように見えます。
レガシーコードとの向き合い方
根本にある問題は、レガシーコードとどう向き合うか、ということです。
多くの企業は、古いコードを「技術的負債」として見なし、書き直す方向に舵を切ります。しかし、現実には一度に全てを作り直すことは不可能です。
運用を止めるわけにもいかない。そこで登場するのが、「部分的な新陳代謝」という考え方です。
システムを皮膚のように少しずつ入れ替えていく、これは理想的に聞こえますが、開発の現場では「戻せばいい」という単純な話ではありません。
なぜなら、システムは「元に戻す」だけでなく、「新しい機能を追加する」ことを同時に求められるからです。
つまり、もともと足しかなかったものに、今度は手をつけてほしいという要望が出てくる。それが設計を根本から見直す必要を生み、開発工数を爆発的に増やしてしまうのです。
結果、多くのプロジェクトは「モダナイズと機能拡張の同時進行」で破綻してしまいます。
現実的な解決策 – 「壊さないリファクタリング」と「ユーザーとの共創」
では、どうすればいいのか。
一気に作り直さず、動く状態を保ちながら少しずつ新アーキテクチャへ移行する。
これが唯一、現実的なアプローチです。
SpotifyやAmazonが採用したように、モノリシックな構造をいきなり捨てるのではなく、外部APIやモジュール単位で段階的に分離していく。いわば「橋を架けながら向こう岸に渡る」やり方です。
そして、ここにもう一つ欠かせない視点があります。
それが「ユーザーとの共創」です。
これまでのソフトウェア開発では、開発者が機能を設計し、ユーザーはそれを受け取る存在でした。しかし、レガシーからモダンへ移行するような大規模変化では、「何を残し、何を変えるべきか」の判断にユーザー自身の声が不可欠です。
Adobe製品の一部やFigma、Notionなどでは、ユーザーフォーラムやβテスター制度を通じて、一般ユーザーが新機能の検証や改善提案に直接関与する仕組みを整えています。開発者が想定していなかった使われ方や、長年の利用経験に基づく「これだけは変えてほしくない」という知見が、開発判断を支える貴重な材料になります。
また、企業側から継続的にコミュニケーションを取ることも欠かせません。
単にユーザーの声を受け取るだけでなく、開発チームの意図や今後の方針を透明に共有し、互いに理解を深めていく。その対話の積み重ねによって、開発側は設計段階で優先度を最適化でき、ユーザーは「自分たちが関わって作った」という納得感を得られます。
つまり、共創とは信頼を再構築するプロセスそのものなのです。
技術と文化、両方の更新が必要
最後に重要なのは、これは技術の問題だけではなく文化の問題でもあるという点です。
レガシーコードを切り捨てるのではなく、そこに込められた知恵や背景を尊重する文化。
それを受け継ぎながら新しい技術へつなげていく姿勢が求められます。
そして、ユーザーとの共創が当たり前になる時代においては、開発者だけがプロダクトを作るのではなく、「使う人もまた開発の一員である」という認識が欠かせません。
古い仕組みを刷新するというのは、単なる技術刷新ではなく、「関係性の刷新」でもあるのです。
「変えない勇気」と「続ける覚悟」、そして「共に作る姿勢」
ユーザーが不満を持つのは、単にバグがあるからではありません。
長年使い慣れた「体験」が失われたとき、そこに信頼を裏切られたと感じるからです。
新しい技術を取り入れる勇気と同じくらい、「変えない勇気」も必要です。
そして、時間をかけてでも着実に古い部分を理解し、未来につなげていく「続ける覚悟」が求められます。
さらに、ユーザーと共にその道を歩む「共創の姿勢」が加われば、レガシーからモダンへの移行は、単なる技術刷新ではなく、信頼と文化を再構築するプロセスへと変わります。
レガシーコードとは、ただの負債ではなく、過去の知恵の結晶です。
それを捨てるか、受け継ぐか、この選択が、ソフトウェアの寿命を決めるのです。
本日も最後までお読みいただきありがとうございました。
それでは、よいシステム開発を！
