IBM i のウンチクを語ろう：その102
－ オープン系とIBM i の寿命を比べてみる －
皆さん、こんにちは。企業用システムを評価する上での尺度ないし指標と言えば、何を思い付かれるでしょうか。例えば日経コンピュータが毎年実施する顧客満足度調査のエンタープライズサーバー部門においては、信頼性、性能・機能、運用性、コスト、サポートといった5つの指標に基づいて各製品を評価し、それぞれの重要度を加味しながら満足度を算出してランキングを作成しています。私自身の経験に照らしても、営業支援の名目でお客様に製品説明を行う際に投げ掛けられる懸念や質問は、多少のバリエーションはあるにしても、概ねこれらのどれかであると言うことができます。最近ですとこれに、日本のIT業界全体の問題ともされる人材不足、といった要素も加わることが多くなりました。
これら5つないし6つの要素は良いとして、企業用ならば「寿命（ライフサイクル）」という要素にも注意を払うべきではないか、と常々考えております。昔から存在していた概念であるにも関わらず、何故かこれに目を向ける方はあまりいないように感じています。寿命を重視するべき理由は極めてシンプルです。事業を継続するのであれば、それを支援するシステムの寿命が尽きる前に、世代交代のための投資を行い、その作業を実施しなければなりません。寿命の長さは投資と作業発生の頻度であり、一回あたりの投資の大きさと相まって、長期的な累積コストを決定します。
さて、一言システムと言っても様々なコンポーネントの集合体であるわけですが、多くの方は最初にハードウェアやソフトウェアなどの「製品」を思い浮かべるのではないでしょうか。この事自体は間違っていないと思うのですが、企業用システム、すなわち企業が抱えるビジネス上の課題を解決するためのシステムであれば、遥かに重要なのは各企業のアプリケーションやデータの寿命であるべきですね。例えば、何らかの事故があってシステムが完全に失われてしまった場合に、製品ならばカネさえ用意すれば比較的短期で復旧させることができますが、アプリケーションやデータといったソフトウェア資産の復旧にはカネだけではなく、年単位に及ぶ時間を必要とするかもしれません。これらは各企業の長年にわたるビジネスの蓄積そのものでもあるからです。
IBM i に携わっている方は既に察してくださっていると思うのですが、開発部門が資産継承性と呼ばれる価値を維持し続けているのは、製品の代替わりがあったとしても、お客様のアプリケーションやデータの寿命は無限であり続けるようにしよう、という意識が根底にあるためです。それが実現できなかった製品は、市場からの撤退を余儀なくされているのも現実です。そしてIBM i の設計者が資産継承性というコンセプトを実現する背景については、「IBM i とは」の「IBM i の長期的コスト削減をもたらす「アプリケーション資産継承性」」セクションにて述べておりますので、目を通していただければ幸いです。
ここで、製品側にも目を向けてみたいと思います。いくつか考え方はあると思いますが、メーカーによる公式の標準ないし延長サポートの提供終了をもって、寿命と見なすのが妥当なところでしょう。そして最近のニュースとしては、Power9プロセッサ搭載モデルである、Power S914, S924, S922などのハードウェア向けサポートの提供を2026年1月31日付けで終了する、という発表がなされたことは記憶に新しいところです。
念のためですが、Power9モデルには内部のシステム・バスとしてPCIe Gen3（第三世代）を採用するAモデルと、2年4ヶ月遅れて登場した、PCIe Gen4（第四世代）を採用するGモデルの二種類があることはご存知のことと思います。世代が進むことでシステム・バスの高速化が図られており、例えば同じS914にもAとGの二つのモデルがあります。そして今回対象になったのはAモデル、型番・型式で言うと9009-41Aのみであり、Gモデルまたは9009-41Gは対象外ですのでサポートは継続されます。
メーカーから営業活動終了やサポート終了といった発表があると、もしかしたら最近は製品の寿命が短くなってきているのではないか、などと疑いたくなるので、念のためにここで事実を確認してみましょう。以下表は比較的最近の、世代毎に最も出荷台数が多い、最下位クラスのモデルのGA（出荷開始）からサポート終了までの月数をまとめたものです。先行するS814の寿命が10年間近かったのは例外として、今回発表対象となったS914の寿命は、従来並みだったことがわかります。
| モデル | 型番・型式 | GA | 標準サポート終了 | 寿命月数 |
|---|---|---|---|---|
| Power 720 | 8202-E4C | 2011/10/21 | 2019/9/30 | 95 |
| Power 720 | 8202-E4D | 2013/2/20 | 2020/12/31 | 94 |
| Power S814 | 8286-41A | 2014/6/10 | 2024/5/31 | 119 |
| Power S914 | 9009-41A | 2018/3/20 | 2026/1/31 | 94 |
| Power S914 | 9009-41G | 2020/7/24 | 未発表 | - |
S814の寿命は何故このように長かったのでしょうか。IBMはいくつかの要素を総合的に評価した上でサポート終了日を決定しています。例えばサポートを終了するためには前提として、次期モデルがGAを迎え、一定以上の新旧両モデルの並行営業期間を設けてから旧モデルの営業活動を終了し、その後さらに一定期間を置かなくてはなりません。ここで仮に次期モデルのGAから先行モデルのサポート終了日までの期間を固定するとしたら、次期モデル登場までの期間が長いほど、先行モデルの寿命は長くなるはずです。例えばS814は次期のS914（9009-41A）が登場するまでの、3年9カ月にもわたって最新モデルでした。他と比べてこの期間が突出して長くなっていることが、S814の寿命の長さに影響していると思われます。
さて、製品のもう一つの要素、オペレーティング・システム（OS）であるIBM i の寿命についても目を向けてみましょう。ハードウェア・モデルと異なりバージョン番号が1から順に繰り上がっているのと、各バージョンの寿命がIBMのサイト「Release life cycle」に一覧化されているので、全貌を把握し易くなっています。
製品寿命の長さと次期バージョン登場までの期間の相関性は、上記ハードウェアと同様に見ることができます。極端な例ですが例えばV2R2が最新だった期間は1年3カ月、寿命は23カ月だったのに対して、バージョン7.1はそれぞれ4年・168カ月と大きく伸びています。最近の全体的な傾向として、次期新バージョン登場までの期間は長くなり、延長サポートの概念が取り入れられるなどして、寿命の方も長くなってきていると言えます。一方で最新とひとつ前のバージョンについては、TR（Technology Refresh）というパッケージを通じて年に二度のペースで機能強化が実施されています。機能強化の頻度は従来よりも上がっていると言えますね。
| バージョン | GA日 | 標準サポート終了日 | 延長サポート終了日 | 寿命月数 |
|---|---|---|---|---|
| V2R2 | 1992/09/18 | 1994/09/06 | なし | 23 |
| V2R3 | 1993/12/17 | 1995/12/29 | なし | 24 |
| 7.1 | 2010/04/23 | 2018/04/30 | 2024/04/30 | 168 |
| 7.2 | 2014/05/02 | 2021/04/30 | 2026/04/30 | 143 |
サポート終了日の決定は、その時点における市場の情勢次第とされており、バージョン7.4と7.5については当コラム執筆時点（2024年11月）では未発表です。ですがここ数世代の寿命を見てみると、概ね7年間の標準サポートと3 年間の延長サポート、すなわち計10年間のサポート期間というのが基本的な考え方になっています。
比較のために、同じOSとしてWindows Serverの方はどうなっているのかを見てみましょう。以下表はマイクロソフト社サイト「製品およびサービスのライフサイクル情報の検索」からの抜粋です。多少のバラツキはありますが、サポート開始日からメインストリーム（標準）サポート終了日まで5年、さらに延長サポート終了日まで5年、であることがわかります。
| Windows Server | サポート開始日 | メインストリーム サポート終了日 |
延長サポート終了日 |
|---|---|---|---|
| 2016 | 2016/10/15 | 2022/01/11 | 2027/01/12 |
| 2019 | 2018/11/13 | 2024/01/09 | 2029/01/09 |
| 2022 | 2021/08/18 | 2026/10/13 | 2031/10/14 |
| 2025 | 2024/11/11 | 2029/10/09 | 2034/10/10 |
最後にアプリケーションを記述するプログラム言語の寿命についても見てみましょう。IBM i 上の上で稼働するRPGやCOBOLについては無限であることは上に述べたとおりですが、日本のソフトウェア開発で最も使用されている言語であるJava（「ソフトウェア開発分析データ集2022」独立行政法人情報処理推進機構）について見てみたいと思います。情報源は「Oracle Java SE Supportロードマップ」です。
Javaリリースには、業務用途を想定し長期的なサポート期間が設けられているLTS（Long Time Support）と、開発・学習用を想定しサポート期間の短い非LTSの二種類が存在します。IBM i との比較をするわけですから、LTSのみを拾い上げ、以下表にまとめてみました。ちなみに非LTSの標準サポート期限は利用開始日の半年後で、延長サポートも提供されません。
| LTSリリース | 利用開始日 | 標準サポート期限 | 延長サポート終了日 |
|---|---|---|---|
| 11 | 2018年9月 | 2023年9月 | 2032年1月 |
| 17 | 2021年9月 | 2026年9月 | 2029年9月 |
| 21 | 2023年9月 | 2028年9月 | 2031年9月 |
| 25 | 2025年9月 | 2030年9月 | 2033年9月 |
14年以上もの寿命があるリリース11を例外として、Javaの寿命は概ね8年であることがわかります。また当然と言えば当然なのですが、Windows Serverのサポート期限と同期しているわけではありません。
例えば本日（2024年11月）現在の最新バージョンを使おうとしたら、Windows Server 2025とJava21の組合せになる可能性があるわけですが、それぞれの標準サポート期限は2029年10月と2028年9月、延長サポート期限は2034年10月と2031年9月、といったずれがあります。そしてどちらのバージョン刷新であっても、アプリケーションの見直しが必要になる可能性があります。どの節目をターゲットに次期システムへの入れ替えを完了させるべきか、考えなくてはなりません。
一方IBM i とRPGの組合せの最新バージョンは2022年5月のGAですから、これまでの慣例に従えば2029年に標準サポート期限、2032年に延長サポート期限を迎えることになります。念のためですが、これら期限はこの場の私の勝手な想定です。システム刷新のタイミングの見極めは比較的容易ですし、新たな要件が無い限り、アプリケーションの見直しは必要ありません。
今回はシステムの寿命の側面から、サンプル的にオープン系とIBM i との比較をやってみた次第です。あらゆるケースに当てはまるわけではありませんが、IBM i の管理は楽そうだということを感じていただけたのではないでしょうか。
ではまた
