こんにちは。オノコムの斧山です。今回は技術説明やAI時代における戦略の話から少し離れて、クラウドが登場してから年月が経ち、以前から言われてきたリスクが現実に顕在化してきた身の回りのことを、備忘録として書いてみました。※本稿は筆者の経験に基づく所感であり、個別案件の事実認定ではありません。

寿命が切れたシステムたち

今、一斉にOSやミドルウェアのサポート期限切れや、新しい認証方法についていけないメールサーバーが現れてきています。なぜそのようなことになっているのでしょうか。

当時は、サーバーハードウェア（機械）の寿命がシステムの寿命でした。機械は5年から7年で入れ替わります。寿命もありますが、ほとんどは機械の保守サポートの終了が理由です。そして減価償却もおおむねその期間なので、税務面から考えても入れ替えが検討されます。

ハードウェアを入れ替えると、自然とOSもバンドルされてバージョンアップされます。

そしてシステム自体も、どうせ入れ替えるなら、お金をかけて新しい機械に古い仕組みをわざわざ載せるかというと、そういうことはしません。同じお金がかかるのであれば、ほんの少しプラスして新しいものにしようとなるのが普通です。なにせ入れ替えたら次の5年から7年間はそれを使います。毎回入れ替えないにしても、2回に1回はそうなるでしょう。

結果としてハードウェア更改のタイミングに依存してきました。

それが昨今、AWSをはじめとするクラウドにシステムを載せると、この切り替えタイミングを失ってしまいます。レガシーシステムをクラウドにReHostまたはRePlatformすると延命はするが、リニューアルのタイミングを失う。これは当初から言われてきたことです。

2011年にAWSクラウドが東京リージョンに来て、そこから数年のうちに普及し、だいたい2015年から2018年あたりから稼働を始め、データセンターからReHostまたはRePlatformする形でマイグレーションしてきたシステムが、ハードウェアのライフサイクルから逃れ、リニューアルのタイミングを見失い、2026年の今年あたりに悲鳴を上げ始めています。

また、自社で運用していた旧来のメールサーバーも、2000年代当初から仕組みが変わらず使えるからといって今日まで稼働させているところもあります。しかし、DKIMや暗号化を実施していないメールサーバーは、大手プロバイダーにメールが正しく届きにくくなる傾向にあります。

この記事は、クラウドにおけるリニューアルのタイミングを失うことを問題提起しているのかというと、そうではありません。

クラウドではハードウェアのライフサイクルがお任せになり、曖昧になったのはその通りです。しかし、システムの入れ替えは、たまたまハードウェアのライフサイクルにただ乗りしていただけであり、本質的なものではありません。

これは顧客が開発ベンダーにすべて一式でお願いしていた弊害でもあり、導入当初にライフサイクルへの対応を定義していなかった落ち度でもあります。

クラウドネイティブに対応していない開発方式は、お客様の指示の場所へ設置して、運用はお客様で、という話も多いです。そうなると、ライフサイクルのことはすっぽり抜け落ちてしまいます。

お願いしている方はやってくれていると考え、やっている方はそこは契約外だと考えて、気が利く担当者が現れない限り先送りされ続けます。

登場人物の全員が、相手がやってくれるものだろうと考え、実際には誰もライフサイクルを受け止めて運用していないケースがあるのです。

そんな話があるかと思われるかもしれませんが、実際に存在します。

なぜ従来の委託式からDevOpsでなければならないのか

従来の委託式では、運用は委託元、ライフサイクルもお任せ、そういうケースもあるというのは前述でお話ししたとおりです。

では委託元が適切にライフサイクルを管理して、アップデート運用を行えばよいのかというと、無理が生じます。OSだけインプレースアップグレードして事なきを得られるかというと、それは成立しません。おそらく、モジュールの1つでもバージョンアップすると環境が変わり、システムが動かなくなる恐れがあるくらいです。

そうなると、バージョンアップのたびに開発ベンダーへ作業を依頼しなければなりません。それはコスト面でも手間の面でも、おそらく成り立ちません。だからステージング環境を作って、そこでテストして、本番環境に投入するというサイクルを作るわけですが、ReHostまたはRePlatformされただけのシステムには、OSやミドルウェアのバージョンアップを含んだサイクルとして設計されていることはまれです。

なぜなら、OSやミドルウェアのバージョンアップには破壊的変更が入っていることもあり、軽微な修正や変更で用いる開発サイクルでは対応できないものが多いからです。結局、再開発に近いコストを支払って委託するしかなくなります。

そして委託式のアップデートでは、脆弱性の穴を埋めるという行為は売り上げに寄与せず、コストと手間がかかります。そして最も重要なのが、クラウドのアップデートを取り入れられないという点です。いわゆるモダナイゼーションされていないシステム開発においては、さまざまな便利な施策や、パフォーマンス向上やコスト削減につながる施策を取り入れることが難しいのです。

その原因として、従来の委託式は、設計 => 開発 => テスト => デプロイ => ローンチで1巡が終わります。変更を加えるたびにこのサイクルが走り、お金も手間もかかります。そのため、クラウドの新情報をキャッチアップしても、そのアップデートを取り入れる余地がないのです。

つまり、新前提の設計になっていない場合、委託モデルでは破壊的変更への追随コストが高くなりがちです。何を当たり前な、という話だと思われるかもしれませんが、体験してみて初めて言語化できたところです。

それではどうすればよいのか。開発とデプロイを統合してしまおう、という話です。表面的に形だけ取り入れると、期待した効果が出ず運用が立ち行かなくなる可能性があります。ではどうするのかというと、テストの自動化、デプロイの自動化、モニタリングやログ分析の自動化、CI/CDツールやIaCなどの自動化を用いて、従来作業としてやっていたことをなくしていくのです。

クラウドがこれだけ普及して浸透してきている今、クラウドと相性が悪い従来の委託式を続けるのは無理がある、ということに向き合い、新しいやり方に突入していかなければなりません。それが単純なDevOpsとなるか、内製化となるかは、それぞれの組織やチームごとに異なるでしょう。

なぜ提案は破壊的でなければならないのか

そしてここが本題ですが、なぜ提案は破壊的でなければならないのでしょうか。現在に至るまで抱えてきた問題は、適切に扱ってさえいれば回避できた問題かというと、そうではありません。ライフサイクルをいくら丁重に管理しても、運用が回りません。また、速度面でも、自社の中だけを見ればよくても、市場との競争を考えるとゆっくりでいいとは言いがたいのです。

つまり、AWSクラウドへデータセンターからマイグレーションされ、ReHostまたはRePlatformされたレガシーシステムは、従来の委託式の延長線上を走っており、また一部がモダナイゼーションされたからといって、開発ベンダーとの関係性を見直さない限り、問題は解消しないものなのです。

とどのつまり、従来の延長線上にある将来において、いくら正しい手続きを取っても、破壊的にやり方を変えない限り、未来はやってこないのです。

だからといって、すべて破壊して一斉に入れ替えろと無理を言うつもりもありませんし、全面更改はリスクも大きいため、段階的移行が現実的です。やり過ぎはいけませんが、やらないのはもっといけません。

破壊的変更を受け入れないとどうなるのか

ここでいう破壊とは、システムそのものではなく、「運用と開発の構造」を破壊することです。

では、段階的にやっていきましょう、次回のタイミングで、と言っていたら、おそらく次回も同じ開発ベンダーにお願いをして、同じ責任分界点のまま契約を結ぶことになるでしょう。これは開発ベンダーの責任ではなく、社内の構造による問題だからです。これは技術問題ではなく、経営問題です。

破壊的変更を受け入れて内製化やDevOpsに移行しない問題の本質は、従来の延長線上にいる限り、改善すればするほど構造的負債が増える、という点にあります。

• 穴埋めをするほど、工数がかかり、管理項目が増える
• 新しいアップデートを取り入れるほど、委託コストが増える

などです。やればやるほど、やることが増えて、管理するものも増えていきます。

提案をしないとどうなるか

現状維持と管理が正解となり、ビジネスインパクトを失います。ビジネスのためにあるはずのシステムが、システムに合わせたビジネスをやることになってしまいます。

新しい形に移行しないという選択は、目的を見ず、ひたすら手段に固執した結論とも言わざるを得ません。それは、古い構造に合わせて事業の速度を落とし、市場機会を失うことを選ぶ、ということです。

技術チームで技術的合意で選択しないこと

従来の委託式に携わっている社内チームは、従来方式の価値観がベースとなっていることが多いです。そしてDevOpsは技術選択ではなく、競争戦略です。

技術の面で評価すると、とにかく安い方がよい、手離れがよい方がよい、事故が起きない方がよい、と守りの戦略になることが多く、それでは従来どおりで、という話に帰結しがちです。

もちろん、新しい戦術に興味があり、方針を切れるチームがいれば素晴らしいことです。

そして、DevOpsや内製化は、現場の好みで選ぶ手法ではありません。変化に追従できる会社になるために、経営として選ぶべき構造改革なのです。