昨日はCCHリリースの話もアナウンスしましたが、ここ最近はメンテナンスリリース（MR）の提供間隔が非常に長くなりました。
MRはまとまった形での修正提供として積極的に検討して頂けるお客様や、適用の計画やテスト、そのためのコストなども考えると簡単には適用の判断は出来ないお客様など色々な背景・事情があるのではないかと思います。　　MRの間隔が長くなったのはこのようなお客様への配慮をしたものですが、ちょっと長文になるのですが、少しこの辺の経緯などを書いてみたいな、て思いました。

　はじめに、「最新のMRの適用」と言うとそれだけで嫌悪感を持たれるお客様も多いのですが、実際には以下のように運用に組み込む事によって安定稼動をしている事例もあり、逆に変更不能とか環境凍結を前提にしていると問題解決が難しくなるケースも多いので、何かしらMR 適用を行う基準や間隔について指針を持っていたほうがいいのではないかと思います。

Lotus Notes/Domino安定稼働のベスト・プラクティス

　MRの話をすると始めに思い出すのはR5時代のQMR （ Quarterly maintenance releases）を思い出す方は多いのではないでしょうか。これはその名の通り、3ヶ月毎にリリースする事を目的としていました。　修正がMRと言う形態で市場に出るのは早かったのですが、最新のMRを適用しようとしても3ヶ月に一度新しいものが出てしまうので実際は適用が間に合わず、逆にお客様には最新のMRが適用してもらえない状態が発生していました。

　これは出荷するにもテスト期間が十分でない、と言う議論が発生し、2001年頃には「Q」が除かれ、4ヶ月毎にリリースし、テスト期間も十分に確保するようにしよう、と言うことになりました。
　このあと、複数のコードストリームが市場に出回るようになると（例：R5.xと、R6.xと R6.5x）、4ヶ月毎、のような目標期間を設ける事は行われなくなり、最新のコードストリームは相対的に短い間隔で出荷し、古いコードストリームの出荷間隔は空けるようになりました。R5.0.12 から R5.0.13が出るのに13ヶ月ほどかかったのを覚えておられる方もいるのではないかと思います。

　このような中、6.5.x が出たあたりから、リリースされるHotfix 量が激増している事が製品品質上の懸念事項として大きくクローズアップされるようになりました。 MRのようなテストが行われていないHotfix　を多くのお客様が適用している状態になると、製品品質上も望ましくないのではないか、と言う事が懸念材料になってきていました。　これを受けて、色々なアクションが取られたのですが、まずリリースされたHotfix を分析すると以下のような傾向がある事が分かってきました。

・　MRに対してほぼ 5%程度の割合の問題に対するHotfix がほとんどを占めている。
・　MR適用に追いつけなくなったお客様が古いMRに対するHotfix 要求をする割合が増加している

このような分析を受けて、Fix Pack と言う形式が採用されるようになりました。
MRのリリース頻度を下げて、報告の多い問題修正をまとめたMRより変更範囲を限定したものを提供したほうがよいのではないか、と言うことです。
　MRでは1000-1500の修正が含まれますが、FPでは20-50の修正だけにとどめてあり、適用時の修正リスクも抑え、MRより適用しやすくなっています。これは予防保守の観点でのメリットも高いので適用していただけるお客様も多く、それなりに受け入れられたのではないかと思います。

それに対し、なぜクライアントはHotfixもFPも提供されないのでしょうか？
私はクライアントサポートをしていることが多い身だったので、これは本当に苦しい対応になることが多かったのですがいくつか理由があります。

　よく「クライアントはインパクトや重要度が小さいから提供されない」と言う言い方をされるのを耳にしますが、これは正しい話ではありません。　たとえば、全クライアントでヒットする可能性のあるクライアントクラッシュ、などがあったらサーバーの問題以上に深刻と言えるのは言うまでも無いことですので。。
　一つは、累積Fix Packのような形態について、いくつかのお客様からヒアリング調査でのフィードバックとして「予防保守目的でFix Packを適用するか？」と言う問いに対し、ほとんどのお客様はサーバーに対しては積極的に検討したい、と言ったのですがクライアントについては「実際にヒットしていないのであれば特に実施したくない」と言う声が多かった事があったそうです。
　もう一つの理由はクライアントのHotfixはサーバーのHotfix よりも影響度やRegression のリスクが大きく、難しいのでサーバーほど簡単に出す事は出来ず、MRのようなQAテストを経たものを出来るだけ渡すようにしたい、と言う事があったからです。サーバーのほうが難しそうだと思われる方も多いかもしれませんが、様々なGUIや複雑なWindowメッセージなどが処理されるクライアントの方が複雑なのです。　ただ、この辺は昨今のCCHリリースなどでも表れております通り、どんどん変わっている部分です。

　現在に至るまでMR/FP/Hotfixなどは色々な経緯を経ていますが、現在の提供形態が最善のものではない、と言う事はサポートや開発でも常に議論されている事です。　そして、問題を出来る限り迅速に沈静化させる必要があるサポートシーンと、出来るだけ安定し、テストも十分に行われたものを管理可能な形で多くの人にリリースしたい、と言う開発視点の発想はどちらも重要なものですので、安易にどちらかへ偏る事も出来ません。　またそもそもHotfixや種々のFIXが必要ない製品を出して欲しい、と言う声もそれ以上にあるのではないかと思います。
　
この点については今後も改善に努めてまいりますので、今後共よろしくお願いいたします。


# ここで掲載された話の多くはこのBlogにも引用されているScott Vrushoのコメントを参考にさせて頂いています。興味のある方は御一読下さい。
　IBM: Update on maintenance schedule (Guest Blogger: Scott Vrusho)