Part 5-a. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編①

  • Article

［大企業におけるレガシー業務アプリ資産について］

ここまで解説してきている通り、Windows 10 への移行における大きな障壁のひとつに、アプリ互換性検証の問題があります。特に大企業では、多数のレガシー業務アプリ資産を抱えていることが多く、従来は数年に一回の OS アップグレード、あるいはサービスパック適用時などに大規模な再テストを手作業で実施していたわけですが、WaaS のように頻度が高まると、同じやり方が通用しなくなります。 image

特に課題になるのは、非近代的なアプローチで開発された、作りっぱなしの既存の業務アプリ資産です。近代的な業務アプリ開発では、テストの自動化や CI/CD、DevOps といった手法を取り込み、リリース後の継続的な保守が容易になるように、常に技術的負債を一定以下に抑え込むような開発・保守スタイルを取ります（詳細は後述）。しかしこうした考え方が一般的ではなかった時に作られたアプリ（いや日本だと今でも、ですけど；）のほとんどは、作った後の保守や互換性検証のことがきちんと考えられておらず、作りっぱなしで後は場当たり的な保守が行われているというのが実態です。こうしたアプリはうっかりすると資産というより負債になっていますが；、既存アプリ負債とか呼ぶと切なすぎるので；、ここではレガシー業務アプリ資産と呼ぶことにしたいと思います。

現在のレガシー業務アプリ資産の大半は、おそらく従来のテクノロジ、すなわち .NET ランタイムや VB6 ランタイムなどで作られていることが多いと思いますので、ランタイム的にも以下のものだけを想定して解説を進めることにしたいと思います。

  • VB6
  • フル .NET Framework （CLR2, 4 系）※ .NET 2.0～4.6 のアプリ
  • IE11
  • ※ 上記のいずれもカーネル互換性のない業務アプリを想定しています

逆に、以下のようなランタイム上で作られているアプリは、今回は対象外として解説します。これらのランタイムはもともと頻繁にバージョンアップを繰り返しており、モダン（近代的）なアプリ開発アプローチを取らないと、そもそも開発・保守ができないためです。

  • エッジブラウザ向け Web アプリ（HTML5, JavaScript, CSS ）※ Microsoft Edge, Google Chrome, Mozzila FireFox など向けの Web アプリ
  • UWP (Universal Windows Platform)
  • ASP.NET Core
  • Xamarin

［既存レガシーアプリに対する互換性検証の基本的な考え方］

さて、ここから既存レガシーアプリに対する互換性検証の考え方を解説していきますが、細かい話をする前に、まず基本的なポイントとして、OS バージョン間の互換性は昔に比べて高まっている、という実態を抑えておく必要があります。 image

特にコンピュータ歴の長い方は、ご自宅でのパソコン利用に際して、98 から XP への移行、あるいは XP でのサービスパック適用、さらには XP から 7 への移行などにおいて、アプリの非互換問題が多発した、という記憶をお持ちの方が多いと思います。が、その一方で、7→8、8→8.1、8.1→10 への移行、さらには November Update や Anniversary Update においてはアプリ非互換問題が大幅に低減している、ということを体感されている方が多いのではないかと思います。

実際、カーネル依存性のないデスクトップアプリケーションの場合、Windows 7 以降では高い互換性が実現されています。もちろん、16 ビットアプリ、OS バージョン番号に基づいて制御をかけているアプリ（特にインストーラ）、デバイスドライバに依存するアプリなどのように、クラッシュしたり全く動かなかったりインストールできないアプリなども確かにありますが、カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ないと思います。Windows 7 で動作していた .NET 3.5 のアプリのほとんどは、Windows 10 上の .NET 3.5 でもまず十中八九動作するはずで、先行検証しているあるお客様からは、「まるで非互換問題が出てこないんだけれども、名前だけ変えてお金稼ごうとしてない？」とか言われたことがあるぐらいです；。

このようになった最大の理由は、Windows 7 以降、マイクロソフト社内の製品開発において互換性に関するアプローチが大きく変わったことです。簡単に言えば、従来の製品開発では、「とりあえず機能を追加しまくってから、出てきた非互換問題をモグラ叩きのように潰していく」というアプローチであったのに対して、現在の製品開発では、「設計段階から互換性の維持を念頭において開発を進める」というアプローチに変わっています。このため、OS バージョン間の互換性はそれ以前の Windows に比べて遥かに高くなっています。もちろん原理的に非互換問題がゼロになることはないが、かといって必要以上に恐れすぎる必要もない、ということです。

アプリケーションランタイムの観点から見てみると、下図にあるように、レガシー業務アプリの開発でよく利用されるランタイム（VB6, CLR2.0, CLR4.0, IE11）に関しては、細かいバグ修正などを除けば、Windows 7 以降、ほとんど手が入っていません。OS としての機能は継続的に強化されていますが、これらの機能（例えば Cortana など）は UWP などから使われることが多いため、既存のレガシー業務アプリはそのままお使いください、という構図があるわけです。 image

［「現実の」互換性検証で起こる問題点］

……などというオフィシャルな話をすると、「おいおいちょっとマテ、実際に Windows 10 を使うと UI の見た目が変わるじゃないか、これが非互換でなくてなんだというのだ！」と必ず怒られるのが日本の世界です；。例えば同じ .NET アプリを Windows 7, 10 それぞれで動作させてみると、以下のように違いが出てきます。 image

（これに関しては、私自身、米国本社と話しているときに温度感の違いとして強く感じる部分の一つでもあるのですが）、特にミッションクリティカルな業務システムの場合には、「アプリが起動すればよい」というものではありません。確かに上の図を見た場合、「だいたい動作は同じ」ですが、ウィンドウ枠のデザインの違い、UI 部品の見た目の違い、ドット単位の微妙な描画の違い、連動する標準ブラウザなどの細かい違いが出てきます。そしてこれらは、ミッションクリティカルアプリでは、時として業務継続を妨げる問題となり得るものであり、無視できるものとは言えません。

そもそもなぜ .NET ランタイムに変更が入っていないのに UI の見た目が OS によって変わるのか？　これは、アプリケーションランタイムが OS の機能を利用しているために他なりません。
image

例えば .NET アプリの場合、計算処理などは .NET ランタイムの中で行われるため、OS をバージョンアップした際に計算結果が変わる、といったリスクはほぼない、と考えてよいでしょう。しかし、UI 描画処理などは OS の API（Win32 API など）を呼び出して行われるため、OS がバージョンアップすれば挙動が変わることがあります。日本のお客様が「OS によるアプリ非互換」を問題にされる場合には、ここを問題にしているケースがほとんどで、これがあるが故に、安易に OS をバージョンアップできない、というケースが多いと思います。

ただ、その一方で現実論として我々が意識すべき点は、非互換問題の発生リスクの大きさです。OS やランタイムに対して加えられる「変更」というのは、その度合いや程度によっていくつかのランクに分けることができます。

  • A. 機能追加や機能変更
    • 例えば Win32 UI 部品の描画ロジックの変更や、既定のブラウザの変更。
  • B. 脆弱性や信頼性に関する修正
    • 例えばセキュリティパッチや、ブルースクリーン発生に対する修正パッチ。

このように分けて考えると、当たり前ですが非互換リスクが大きいのは前者の機能追加や機能変更です。脆弱性や信頼性に対する修正でも、非互換問題が発生しないとは言い切れませんが、そのリスクは前者に比べれば圧倒的に低いです。よって、我々がまずしっかり押さえるべきは A. 機能追加や機能変更、その上でさらに B. 脆弱性や信頼性に関する修正、という具合に、濃淡をつけて考える必要があります。

［アプリケーションのミッションクリティカル度による分類］

アプリの互換性検証を考える際、理屈上は「あらゆる修正に対して互換性を検証する」のが正しいです。このため、大企業の IT 部門の方と話をしていると、半年に一度の大規模再テストは無理だ！ と言われてしまうのですが、実態として（よいか悪いかは別として）、実際の開発現場ではそこまできちんとした互換性検証が行われていない場合が少なくありません。例えば、互換性検証の実施レベルを以下の 3 つに分類してみた場合、①または②のレベルでしか互換性検証をしていない、ということが実は非常に多いです。

  • ① 事前の互換性検証をしていない
  • ② サービスパックのような機能追加・変更がある場合のみ、互換性検証をする
  • ③ パッチを含め、あらゆる修正に対して互換性検証を行う

どこまでの互換性検証をすべきか？ はアプリケーションのミッションクリティカル度によって異なります。このため、例えば金融系システムや各種基幹系システムでは、③のレベルで互換性検証をしている場合もあるでしょう。しかし、すべてのレガシー業務システムが③のレベルで互換性検証をしていることはまず十中八九ないはずです。これは、③のレベルでの互換性検証が必要な場合には、毎月リリースされるセキュリティパッチに対して毎月テストを繰り返さなければならないためで、このようなテストは事実上手作業では無理（自動化が必須） です。手作業での互換性テストができるのは、現実的には②のレベルまでです。 image

そしてもう一つ、これに併せてご確認いただきたいのが、 （Windows 7 以降における）過去のサービスパックやセキュリティパッチの適用において、実際に非互換問題がどの程度発生したか、です。最初に述べたように、Windows 7 以降では OS バージョン間の互換性が高くなっているため、ほとんどのケースでは実態として非互換問題は発生していないはずです。もしそうであるのなら、Windows 10 への移行時に、現在の実施レベルをむやみに高める必要はありません。例えば、現在の実施レベルが②であるのなら、Windows 10 移行後も、②のレベルに留めるべきです。

なぜこのような話が重要になるのかというと、最大の理由は、IT 部門の方が、実際の業務部門側で行われているシステム開発の実態を完全に把握していないことが多いからです。実際にあった話ですが、ある大企業の IT 部門での Windows 10 導入検討において、当初、半年に一度の OS バージョンアップではアプリ互換性検証が間に合わない！ ということが大問題になりました。しかし実際の業務部門に確認してみると、Windows 7 の SP1 リリースの際に事前のアプリ互換性検証が行われていなかったこと、またその際に非互換問題が発生していなかった、という事実が判明し、必要以上に心配しすぎだということがわかった、ということがありました。

このアプリ互換性検証は（私もそうだったのですが）つい頭でっかちに考えやすい部分なので、IT 部門の方は、実際にいくかつの業務部門の方にヒヤリングしていただき、現在の互換性検証の実態がどうなっているのかを必ず確認してください。

……とはいえ、問題なのは、WaaS の FU（機能アップグレード）において実際にどの程度の機能追加・変更がなされているのか、そしてそれがどの程度、既存レガシー業務アプリに影響を及ぼしうるのか、という点です。もしそれがたくさんあるのであれば、結局は半年に一回、大規模な再テストを繰り返すことになります。これについては、「実際のところどうなのよ？」という議論が必要になるはずです。これについて引き続き見ていくことにします。