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


WaaS におけるアプリ互換性問題を考える上では、Windows 10 → 10 への機能アップグレードにおいて、どの程度、既存レガシー業務アプリに影響を及ぼしうる変更が加えてられているのか、という点が重要になります。もちろん、将来のことはわからない部分もありますが、とはいえ November Update や Anniversary Update の内容を精査してみることは、FU(機能アップグレード)の中身の特性を理解する上で重要になりますので、もう少し細かく見てみることにします。

[Windows 10 FU 間の互換性の実態]

詳細は Part 7 にて解説しますが、Windows 10 の機能アップグレード(FU)で行われた内容については、非公式サイトですが changewindows.org というサイトが(英語ですが)非常によくまとまっており、このサイトを見ると、一覧形式で 8.1 → TH1, TH1 → TH2, TH2 → RS1 で行われた主な機能追加・変更を確認することができます。こちらを確認していただくと、Windows 10 の FU は大まかには以下のような傾向があることがわかります。

  • Windows 8.1 → Windows 10 TH1
    • UI まわりが大きく変更されている。(このため、.NET や VB6 アプリもその影響を受ける)
    • その他、OS 全体に比較的大きな機能追加・変更が加えられている
  • Windows 10 TH1 → TH2 および TH2 → RS1
    • TH1 → TH2 : Edge ブラウザの強化が中心で、他の機能強化はほとんどない
    • TH2 → RS1 : Edge ブラウザに加え、スタートメニューや設定画面、IME などの強化が中心であり、既存レガシーアプリには影響が出にくい変更内容がほとんど

image

changewindows.org サイトを見てみると、各 FU には 100~400 近くの機能追加・変更項目があることがわかりますが、私なりの視点で「レガシーアプリに対して非互換問題を起こしそうな」変更項目をざっとピックアップしてみたのが下のリストです(一部、日本語関係で私が追加した項目も入っています)。もちろん私なりの視点なので、当然、すべての業務アプリでこれだけチェックすれば十分、とはなりませんが、大半の機能追加・変更はスタートメニューなど既存レガシー業務アプリに影響を及ぼさない場所に入っているため、半年に一度の FU のつど、アプリ全体を入念に再テストしなければならない、というわけでもなさそう、という感覚は掴めるかと思います。

  • 8.1 → TH1
    • IME 関連
      • デスクトップアプリのテストボックスに触れるとスクリーンキーボードが表示されるようになった
      • テキスト入力キャンバスが改善された
    • UI デザイン関連
      • ウィンドウ枠のデザインが変更された
      • Win32 コントロールのデザインが変更された
      • タスクバーの既定の色がダークに変更された
      • ウィンドウ枠の色が白に変更された
      • 日本語の既定のフォントが Yu Gothic UI に変更された
    • インストーラ関連
      • Windows OS のバージョン番号が変更された
    • 拡張子関連
      • 既定のアプリの変更方法が変更された
    • ブラウザ
      • 既定のブラウザが IE から Edge に変更された
      • 全画面型 IE が廃止された
  • TH1 → TH2
    • IME 関連
      • テキスト入力パネルが改善された
      • 新しい絵文字が追加された
    • インストーラ関連
      • Windows OS のバージョン番号が変更された
    • 拡張子関連
      • 既定のアプリが “Windows 10 で推奨” と表示されるようになった
    • その他
      • タイムゾーンを自動的に補正する機能が備わった
      • 最後に利用したプリンタが「既定のプリンタ」として扱われるようになった
  • TH2 → RS1
    • IME 関連
      • 日本語 IME が大幅に機能強化された(クラウド候補、入力履歴、候補予測、片手入力キーボード、性能など)
      • 絵文字のイラストが変更された
    • UI デザイン
      • 認証ダイアログのデザインが変更された
      • 游ゴシックが小さい文字でも読みやすいように変更された
    • その他
      • NTFS が 260 文字以上のファイルパスをサポートするようになった

以上を加味すると、実際の Windows 10 への移行に関しては、7/8/8.1 → 10 の移行と、10 → 10 の移行とを分けて考えた方がよい、ということになるでしょう。具体的なやり方は後述しますが、おおまかな考え方は以下の通りです。

  • 7/8/8.1 → 10 : 比較的きっちりと検証作業を行う
    • 日本の業務アプリケーションの多くは UI が非常に複雑なため、若干の見た目の変更であってもエンドユーザからのクレームに繋がり兼ねないため。
    • ただし、以降の 10 → 10 の互換性検証を見据えながら検証作業を進めるのがポイント。
  • 10 → 10 : 極力、効率化・省力化を行う
    • 既存のレガシーアプリに対して影響を及ぼしうる OS への機能追加・変更はごくわずか。
    • このため、この互換性検証は、実施するとしても極力、効率的に実施する必要がある。

image

[アプリ互換性検証の効率化の手法]

では、実際にアプリ互換性検証を効率化するためにはどのような手法があるのか? ですが、代表的なものとしては以下の 3 つがあります。

  • ① テストケースの絞り込み
    • 実施する非互換検証の物理的な実施量を減らす
  • ② 見逃しリスクへの対応
    • テストケースを減らしたことによる見逃しリスクを緩和するための施策を打つ
  • ③ 更なる実施効率化
    • ①②を行った上で、さらに効率化を進めたい場合に追加の施策を打つ

主な具体的施策と併せて示すと、下図のようになります。

image

うちの開発現場ではすでに実施済みだよ、という施策も多いでしょうが、以下に順に、考え方ややり方を示していきます。

[アプリ互換性検証の効率化の手法① テストケースの絞り込み]

まず真っ先にやるべきことは、非互換問題を起こしそうなところに絞ってテストを実施する、というものです。絞り込み方については主に以下の 3 通りがあり、これらを組み合わせて効率的なテストケースを組み立てます。

  • A. アーキテクチャ情報を元に絞り込む(処理の類似性や技術要素などから絞る)
  • B. 業務的観点から絞り込む(重要度の高い業務に絞る)
  • C. 実践的な知見から絞り込む(過去の互換性検証の結果や探索的テストから絞る)

この 3 つの絞り込み方の中でも特に重要なのは A. アーキテクチャ情報を元に絞り込む(処理の類似性や技術要素などから絞る)の考え方です。というのも、実際の非互換問題は下記の図に示したような『技術的接点』で発生しやすいためで、むやみにテストケースを設計するのではなく、こうしたパスを少なくとも 1 度は通すようにテストケースを設計することで、効率的なテストケースを組みやすくなります。
image

上図ではデスクトップアプリの場合について考え方を示しましたが、Web アプリについては注意が必要です。特に既存レガシー業務 Web アプリの場合、Web アプリと言いながら、実際には ActiveX をはじめとするプラグイン技術を多用していることが多く、これらはデスクトップアプリと同様な非互換検証を必要とします。このため、IE11 自体が変わっていなくても、プラグイン部分については、デスクトップアプリ的な考え方でテストケースを組み立てる必要があります。(なお、IE11 は基本的に機能変更が入らない、という指針にはなっていますが、とはいえエンタープライズモードをはじめとする Edge ブラウザとの切り替え機能や、セキュリティ強化に伴う機能変更などは今後も入る可能性があります。このため、こうしたポイントについては念のため確認した方がよいでしょう。)

image

また、テストケースの効率的な絞り込みのためには、濃淡をつけるという考え方が重要です。技術要素に分解して考えた場合、場所ごとに非互換リスクの度合いはずいぶん違います。ですから、例えば下のような表を作成し、領域ごとにどの程度濃淡をつけてテストするのか? ということを意識しながらテストケースを組み立てていくと、費用対効果の高い互換性テストが実施できます。

image

さて、この「非互換情報との突合せによるテストケースの絞り込み」では、以下の 2 つが特に重要になります。

  • どのレベルで非互換情報を確認するのか?
  • どこから非互換情報を入手するのか?

どのレベルで非互換情報を確認するのか?

Part 5-a で述べたように、互換性検証の深さはアプリのミッションクリティカル度に応じて調整する必要があります。例えば、

  • 今まで月例パッチ(毎月のセキュリティパッチ)に対して互換性検証をしてこなかったというアプリの場合は…
    • 今後も、アプリ互換性検証は機能アップグレード(FU)が行われる際に、機能追加・変更に対してのみ行えばよい。
  • 毎月のセキュリティパッチに対しても互換性検証をきちんとしてきたというアプリの場合には…
    • 今後も、毎月のサービシングアップデート(SU)に対して、互換性検証を続けていけばよい。(ただしこの場合は事実上、自動化が必須)

となります。

image

どこから非互換情報を入手するのか?

非互換情報は、公式/非公式様々なサイトから提供されていますが、実のところ、このテストケース絞り込みの目的ですぐさま役に立つものは少ないのが実情です。詳細は Part 7. 「Windows OS の変更ログの入手方法」で解説しますが、例えば『機能アップグレード(FU)が行われる際に、機能追加・変更に対してのみ行う』のであれば、FU リリース時に、機能追加・変更の一覧情報を入手する必要があります。非公式サイトかつ英語という問題点はありますが、最も使いやすいサイトは最初に説明した ChangeWindows.org というサイトだと思います。ちょっと時間を取って実際に見てみていただければと思いますが、

  • ページ上部の「Milestones」を開くと FU の一覧が出てくる。(November Update, Anniversary Update など)
  • そこから FU を選択すると、中間ビルドの一覧(Windows Insider で公開された中間ビルドの一覧)が出てくる。各中間ビルドには、前回の中間ビルドからの差分情報が整理されている。
  • 最後のビルド(緑で示されている)が、最終的に公開されたビルド。これを選択すると、前回の FU からの変更点の積算情報が表示される

例えば、TH1 から TH2(November Update) での変更点はこのページに、TH2 から RS1 (Anniversary Update) での変更点はこのページに情報がありますが、(英語であるという難点を除けば;)使いやすい形で、機能追加・変更に関する変更ログが整理されていることが確認できます。こうしたリストを使って、特に重点的にテストする場所を決めていくとよいでしょう。

なお、SU(累積パッチ)での修正情報については、Windows 10 リリース情報ページが詳しいです。こちらは、今までに提供された SU の一覧と、それぞれに含まれている代表的な修正内容について情報が提供されています。(こちらは KB 情報なので日本語でも情報が提供されています。FU の情報が日本語で提供されてなくて SU の情報が日本語で提供されているというのは正直逆だろう、と思うのですが;

非互換情報を利用する場合の注意点 ~機能追加・変更・修正の境界線問題~

さて、こうした非互換情報を利用してアプリの互換性検証をする場合の注意点ですが、

「どのような非互換情報リストを利用しても、絞り込んだテストだけで非互換問題を事前に100% 洗い出すことは原理的にできない」

ということを理解しておく必要があります。このポイントは敢えて赤字で書くほどむちゃくちゃ重要なことなので、しっかり理解してください

こうした互換性検証のよくある誤解のひとつに、「ベンダーから提供される非互換情報(例えば KB などの情報)を使って検証することで、非互換問題を事前に(完全に)回避することができる」、というものがあります。しかし、この考え方は原理的に誤りです。なぜなら、マイクロソフトに限らず、ベンダーから提供される非互換情報そのものは、すべての変更点を網羅したリストにはそもそもなっていないから(=すべての変更点を網羅したリストを提供していない)であり、同時に、「何を機能追加・変更・修正とみなすのか?」に関しては、ある程度、人間の恣意的な判断が入ることが原理的に避けられないためです。このことを概念的に示したのが下図です。

image

まず、極端な話をしてみると、同一ソースコードをリビルドしても、完全に 1 バイト単位で同じバイナリにはなりませんから、リビルドするだけで、理屈上は挙動が変わる恐れがあります。けれども、我々は多くの場合、同一ソースコードをリビルドした場合には挙動は同じになると考えます。なぜかというと、コンパイラに不具合がない限り、現実的には論理的な挙動は同じになるだろうと考えるからです。あるいは、CPU として Core i7 のマシンを使う場合と、Core i5 のマシンを使う場合とで、理屈上は挙動が変わる恐れがありますが、現実的には業務アプリの挙動は変わらないと考えるのが普通です。このように、「理屈上、原理的に非互換問題が起こりうる」という話と、「現実的に、非互換問題が起こる可能性が高い」という話には、隔たりがあるのが普通です。

このことを Windows OS に当てはめて考えてみると、製品に対するあらゆる修正は、たとえ API 外部仕様が一致していても、挙動が 100% 同じになるとは言えないため、機能変更であるとも言えます。その一方で、あらゆる修正を機能変更であるとみなすと、非互換情報リストが膨大になり、突合せ確認を行うことが不可能になってしまいます。Windows OS の場合だと、細目レベルでは数千~数万件単位の修正が入っているそうなのですが、そんな API レベルの微修正の一覧リストをもらったところで、非互換検証の突合せを行うことは不可能です。このため、実際の業務アプリの非互換検証においては、「実用的なレベル感・粒度感」に整理された非互換情報リストを使うことが、最も重要になります。(項目数ベースでいえば、最大でも 100~500 個ぐらいの粒度に整理されていないと、リストとしては使い物にならないと思います)

実際、現場にいると、お客様から「Windows OS や .NET Framework のバージョンアップに際して、すべての変更点リストを提供してください」と言われることが多いのですが、本当にすべての変更点リストを提供してしまったら、項目数が多すぎて、実際には使い物にはなりません。実際にお客様が期待しているものは、適度な粒度感にまとめられつつ、なおかつそのリストを使うと自分の業務アプリの非互換問題が 100% 事前に洗い出せるという魔法のような非互換情報リストなわけですが、そのようなものを作ることは原理的に考えて不可能です。

結局、過去の経験に基づき、最も実用的なレベル感・粒度感で、最も非互換問題を起こしそうな項目を情報として取りまとめて提供するのがお客様側にとっても最もメリットがあるわけで、マイクロソフトをはじめ、多くのベンダーはそのような取り組みをしています。一方で、こうした情報の取りまとめでは、「何を機能追加・変更・修正とみなすのか?」に関して、ある程度、人間の恣意的な判断が入ることが原理的に避けられません。上図に示したように、機能追加はともかくも、「機能追加」と「修正」の境界線、あるいは「修正」と「微修正」の境界線は、どうしても曖昧になる、ということです。

ですから、非互換情報リストを使って絞り込み再テストを行う方法では、見逃しリスクを大きく低減できるものの、見逃しリスクをゼロにすることは原理的にできません。このため、より高い安全性を実現するためには、実際に見逃しにより不具合が発生した場合のリスクヘッジを考える必要があります。そのための施策が、次に述べる、リング配信と迅速な障害対応です。


Comments (0)

Skip to main content