デプロイするソフトウェアバージョンの選択
ITの世界でよく議論されるテーマの一つが「どのバージョンのソフトウェアをインストールすべきか」という問題です。これはデータベース、アプリケーション、ファームウェア、あるいは最も頻繁にはオペレーティングシステムに適用され、Windows XPのサポート終了が迫る中、この話題は熱を帯びています。
効果的には、この議論には二つの立場があります。一方は最新で（おそらく）最も優れたソフトウェアを常に使用すべきだと考えます。もう一方はソフトウェアは成熟する必要があるとして「様子見」のアプローチを取るか、各バージョンをまったく異なる製品として、連続的な開発ではなく捉えます。
どちらのアプローチにもメリットがあり、どちらも完全に単独で存在するべきではありません。闇雲にソフトウェアを更新することは賢明ではなく、理由もなくパッチや更新を避けることも賢明ではありません。これらの決定を下す際には、要因を慎重に検討し、ソフトウェア開発プロセスへの共感を持つことが重要です。
まず、まったく異なる2つのシナリオを考慮する必要があります。一つは現在の既存ソフトウェアの更新です。現在の状態が「動作している」という前提で、「動作している」には、発見され閉じるために更新が必要なセキュリティ上の脆弱性が含まれている可能性があります。もう一つのシナリオは、現在何もなく、ゼロから始める新規デプロイです。
2番目のケースから始めましょう。こちらの方が指針を提供しやすいためです。
新しいソフトウェアのデプロイ（または新しいオペレーティングシステム）の場合、既知のバグやソフトウェアの非互換性といった技術的な制限が明確に知られていない限り、常に最新バージョンのソフトウェアを使用してください。
ソフトウェアは他の種類の製品とは異なります。特に今日のオンラインパッチリリースと更新の世界においては。古いバージョンのソフトウェアが現在のものよりも好ましい場合があるという考え方は、特定の年やモデルがさまざまな理由で新しいモデルよりも優れている物理製品（時計、車、食器、家具、ワイン）や、完成したソフトウェア製品が「壁越しに投げられ」、最終状態が更新、パッチ、修正の合理的な機会なしにただ最終状態であるだけのレガシーなソフトウェア配信モードの組み合わせに由来すると思われます。これらのケースはどちらも現代のビジネスソフトウェアには当てはまりません（ごくまれな例外を除いて）。
ソフトウェア開発は大まかに連続的なものです。通常の開発プロセスでは、新しいソフトウェアが古いソフトウェアの上に直接（既存のコードベースへの更新を作成することで）または間接的に（ソフトウェアの以前のバージョンを構築したことで得た知識に基づいて再構築することで）構築されます。各後続バージョンのソフトウェアは前のものより優れているという考え方です。もちろん、これは保証されていません。リグレッションエラーや単純な開発上の問題という概念も存在します。しかし全体的に、ソフトウェアは時間とともに改善されます。特にビジネスで使用されるエンタープライズクラスのソフトウェアで、活発に開発されているものについては。新しいソフトウェアは単に古いソフトウェアの次のフェーズではなく、ほぼすべての場合において、パッチ、バグ修正、更新の現在の状態、そして必要に応じてアプローチや技術の変更も表しています。品質のある開発元からの新しいソフトウェアは、ほぼ独占的に古いソフトウェアよりも優れています。ソフトウェアは進化し、成熟します。
ソフトウェア自体の品質を超えて、将来への投資という概念があります。ソフトウェアは永遠に棚に置いておけるものではありません。ある程度最新の状態を保つ必要があります。そうしないと、動作するプラットフォームが変わったり、新しいアーティファクトが出てきたり、セキュリティホールが発見されたり、ニーズが変わったりすることで機能しなくなります。古いソフトウェアをインストールするということは、過去への投資、つまり古い技術のインストール、学習、使用、サポートへの投資を意味します。これを「技術的負債」と呼びます。この古い技術は何年も、場合によっては何十年も続く可能性がありますが、古いソフトウェアは時間とともに価値を失い、ベンダーが引き続きサポートする場合はそのために、エンドユーザーはサポートするためにますます費用がかかるようになります。
技術的負債という同じ概念は、対象となるソフトウェアベンダーにも当てはまります。ソフトウェアを作成することには非常に大きなコストがかかり、特にそのソフトウェアの複数バージョンを維持することには。ソフトウェアベンダーは、現在のソフトウェアリリースにリソースを集中させるために、古いバージョンのサポートを削減する大きなインセンティブを持っています（これはSaaSデプロイが非常に人気な主な理由の一つです。ベンダーは利用可能なバージョンを制御し、更新を通じてレガシーバージョンを排除できます）。顧客が古いバージョンのサポートを必要とする場合、そのコストはどこかで吸収されなければならず、しばしばすべての顧客への金銭的影響と、開発チームが古いバージョンのパッチ適用と新しいバージョンの開発の両方をサポートするために分割されなければならないため、新製品への集中が低下します。古いバージョンに費やす労力が多いほど、新しい改善に向けられる努力が少なくなります。
私がすでに述べたことの枠組みの中で、コードの成熟度について話すことが重要です。コードの成熟度は、「古いコード」をデプロイする理由としてよく述べられますが、これはソフトウェア開発プロセスのITによる誤解だと思います。リリースされたコードのラインについて考えると、リリースされて使用されているからといって、それが本当に成熟しているわけではありません。コードは現場では変化せず、そこに置かれているだけです。その成熟度はリリースされた日に「固定」されます。パッチが当てられた場合はリリース後に「成熟」するでしょう。同じコードベースに基づいた同じソフトウェアの後のバージョンは、より多くの程度でレビュー、更新、テストなどが行われているため、本当により「成熟した」コードです。
これは、例えば車とは逆説的です。各リリースが新しいものであり、機械的な問題の新しい機会と異なる信頼性の懸念がある車では、数年待つことで信頼性の問題が明らかになる機会があります。ソフトウェアはこのようなものではありません。そのため、より成熟したソフトウェアを求めるという概念は、「実績のある」ものよりも「最新で最高の」ものをデプロイするよう押しやることになります。
ソフトウェアのバージョン番号を年齢のように考えると、これが見えてきます。Linux 3.1は、ソフトウェアの成熟という観点から、Linux 2.4よりもはるかに古いです。10年分の追加開発があります。
今日非常に関連性の高い実際の例を使ってみましょう。あなたは初めてサーバーをインストールしようとしています。Windows Server 2012 R2がちょうどリリースされました。Windows Server 2008、2008 R2（2010年）、Server 2012、Server 2012 R2（2013年末）のどれをインストールすべきでしょうか？
多くの組織にとって、これはそれぞれを選ぶ異なる理由を持つ2から4の異なる製品の話をしているように聞こえるかもしれません。しかし、これは大部分において誤りです。各新しいバージョンは単純に前のバージョンのアップグレード、更新、パッチ、機能追加に過ぎません。各バージョンは順番に前のものよりも先進的で成熟しています。各新バージョンは、その前身の元のリリースで行われた作業と、元のリリースから後継リリースまでの間に行われたバグ修正、パッチ、機能追加の恩恵を受けています。各新リリースは実際のところ、前のものの「マイナーリリース」です。マーケティング名の代わりにカーネルのリビジョン番号を見れば、より理解しやすくなるかもしれません。
Windows Server 2008はWindows NT 6.0でした。Windows Server 2008 R2はWindows NT 6.1で、明らかに前のリリースのマイナーリビジョンまたは「パッチ」です。Windows Server 2012はWindows NT 6.2で、現在のWindows Server 2012 R2はWindows NT 6.3です。マーケティング名の代わりにリビジョン番号を使用した場合、古く、成熟度が低く、更新が少なく、パッチが少ないバージョンを意図的にインストールするのはほとんどおかしなことに聞こえます。最新の更新、最新のバグ修正、最新のセキュリティ問題への対処が必要です。
新しいソフトウェアのデプロイでは、インストールされるソフトウェアが新しいほど、最新機能を活用するより多くの機会があり、避けられない陳腐化が訪れるまでより多くの時間があります。すべてのソフトウェアは老化するため、新しいソフトウェアをインストールすることで、そのソフトウェアが最も長く続く可能性が最も高くなります。未知の将来に対して最高の柔軟性を提供します。
この考え方に従うと、プレリリースやベータソフトウェアのデプロイも意味があると感じるかもしれません。そして、例えばリリース前に企業全体にリリースする前にソフトウェアをチェックするための「テストグループ」などの特定のケースではそれが意味をなすかもしれませんが、一般的にはそうではありません。プレリリースソフトウェアの性質上、サポートされておらず、決してサポートされないコードが含まれる可能性があります。そのようなコードを単独で使用することは有益ですが、一般的な使用には推奨されません。製品全体の成熟度レベルに関わらず、プレビューやベータリリースと最終リリースの間には、重要なプロセスが踏まれます。
これにより、既存のソフトウェアを更新するもう一つの状況に移ります。もちろん、これは新規インストールとはまったく異なるシナリオであり、関係する要因もはるかに多くあります。
多くの状況で最大の要因の一つはライセンスです。ソフトウェアを定期的に更新すると、利点とコストの方程式に組み込む必要があるライセンス料が発生する場合があります。ほとんどのオープンソースソフトウェアなどの一部の製品にはこのコストがなく、新しいバージョンが利用可能になり次第更新できます。
ソフトウェアの更新においてもう一つ非常に大きな要因は、更新のための人的労力コストです。新規インストールとは異なり、そこでは古いソフトウェアと新しいソフトウェアのインストール労力は事実上トントンです。実際には、改善や進歩により、新しいソフトウェアは古いソフトウェアよりもインストールが容易な傾向があります。10年間ソフトウェアの単一バージョンを維持するということは、その期間中にアップグレードプロセスにリソースが割かれていなかったことを意味します。その間に毎年アップグレードするということは、別々のアップグレードを実施するために10回リソースが使用されたことを意味します。これにより、更新のコスト正当化がはるかに難しくなります。しかし、更新プロセス自体の労力だけではありません。継続的なアップグレードにより変更がより頻繁に経験されるエンドユーザーへの継続的なトレーニングも必要です。
これはソフトウェアの更新がマイナスに聞こえるかもしれませんが、そうではありません。単純に各サイドを比較検討する必要がある方程式です。定期的な更新は大きな跳躍ではなく小さな段階的な変更を意味することが多く、エンドユーザーがより自然に適応できます。定期的な更新は、更新プロセスがより簡単で予測可能であることを意味します。定期的な更新は、技術的負債が常に管理され、機能、効率性、またはセキュリティ改善である可能性がある新しいバージョンの利点がより早く利用可能になり、より長い期間にわたって活用できることを意味します。
上記の2つのシナリオから学んだことから、もう一つ重要な教訓があります。更新を実行する決定が下されたら、「どのバージョンに更新すべきか」という疑問がよく生じます。しかし実際には、標準的なパッチプロセス以上のすべての更新は、ミニチュアの「新しいソフトウェア」購入決定のようなものであり、新規インストール時に「常に」最新バージョンをインストールする理由の論理はここにも適用されます。そのため、更新を実行する際には、ほぼ常に可能な限り最新バージョン（現在のバージョン）に更新するべきです。
Microsoft の例を再び適用すると、今日Windows XPをデプロイしている組織を例に取ることができます。ビジネスは、単なる継続的なパッチ適用ではなく、新しいバージョンへのアップデートサイクルに投資することを決定します。Microsoftからまだ積極的なサポートを受けているWindowsデスクトッププラットフォームのバージョンがいくつかあります。これにはWindows Vista、Windows 7、Windows 8、Windows 8.1が含まれます。現在のバージョン未満のバージョンに更新すると、そのバージョンのサポート終了までの時間が短くなり、組織のリスクが増加します。古いバージョンを使用するということは、すでに古い技術への投資が続くことを意味し、技術的負債の増加と、利用可能になれば有益であることが証明される可能性のある新機能へのアクセスが少なくなることを意味します。この特定の例では、新しいバージョンはより安全であり、より少ないハードウェアリソースを必要とすると見なされています。
すべてのビジネスは、既存のソフトウェア更新サイクルに対して自分たちに合った適切なバランスを見つける必要があります。すべてのビジネスとすべてのソフトウェアパッケージは異なります。Microsoft Windows、Microsoft Office、Oracle Databaseなどのエンタープライズソフトウェアはこれらのモデルに非常によく従います。小規模なソフトウェアプロジェクトやビスポーク領域に近いものは、より動的で予測不可能なリリースサイクルを持つ可能性がありますが、一般的にはほとんどのルールに従います。ソフトウェア開発プロセスへの共感を適用して、あなたとソフトウェアベンダーが最高の価値を組織に提供するために最も良いパートナーシップを築く方法を理解し、それを技術的負債を削減して組織に最も適した方法でソフトウェア投資を活用する必要性と組み合わせることを検討してください。
しかし、経験則は比較的簡単です：
新規デプロイまたは更新を行う際は、最新の合理的なバージョンのソフトウェアを目指してください。あらゆるデプロイの機会を活用して、技術的負債をできる限り排除してください。
ソフトウェアがすでに存在する場合は、人的労力、ライセンスコスト、環境の一貫性、互換性テストなどの要因を、機能、パフォーマンス、技術的負債の利点と比較検討してください。
広告
