Windows 10 UWPで業務デスクトップアプリ開発はどう変わるのか?特集:UWPとは何か(3/3 ページ)

» 2015年06月23日 05時00分 公開
[山本康彦BluewaterSoft/Microsoft MVP for Windows Platform Development]
前のページへ 1|2|3       

UWPへのハードル

 「UWPアプリのメリットは分かった、よし移行しよう!」となったとき、どんなハードルがあるだろうか?

 業務アプリの場合、最大のハードルは前述した「クラウド型」システムアーキテクチャであろう。従来のデスクトップアプリで採用していなかったとしたら(恐らく採用していないだろう)、要件定義がひっくり返る話であるし、既存のITインフラも再構築を迫られるかもしれない。セキュリティ面での制限も、従来のデスクトップアプリで行っていた設計を覆すだろう。

 内部設計や実装では、Windowsランタイム(API)の習得に時間がかかるだろう。UIの記述は、XAMLで行うならばWPFからの移行は難しくない。また、UWPアプリでは非同期処理を多用する(.NET Framework 4.5で導入されたasync/awaitキーワードを使ったプログラミング)。従来のデスクトップアプリ開発で非同期処理を利用していなかったならば、これも習熟を要する。

デスクトップアプリ開発からUWPアプリ開発へ移行するときのハードル デスクトップアプリ開発からUWPアプリ開発へ移行するときのハードル
すでにデストップアプリ開発でasync/awaitを活用したWPFアプリを作っているのなら、大きなハードルはUWP固有のものだけだ(右端)。もしもWindowsフォームの開発しか経験していないようだと、大きなハードルを三つ越えなければならない。

UWPへの移行戦略

 いつかはUWPアプリ開発に移行しなければならない。考えてもみよう。現在でも、MS-DOS用の業務アプリを開発してWindows 7/8で使うことは可能だ(サポートを受けられるかという問題はおくとして)。しかしそんなことはしないだろう。日本でWindows 3.1が広まり始めた当時に、「業務プログラムをそんなオモチャ(=Windowsのこと)で動かす意味はない!」などと筆者はさんざん諭されたものだったのだが。あるいは、今でも.NET以前のVisual Basicを使った業務アプリの新規開発を考えるだろうか? 10年20年というスパンで考えるとき、新しいプラットフォームでの開発に移行することは避けられないのである。

 移行が避けられないとすれば、問題は「いつ」「どうやって」移行するかである。筆者のように1人で独立してやっているなら「すぐに!」となるのだが、組織のためのアプリをチームで開発しているとそうはいかない。組織の都合やチームの習熟度合に見合った移行戦略を立てる必要がある。そのためのヒントをいくつか紹介しよう。

数年後にはWindows 10だけになる

 今から4年半〜7年半の後には、Windows 10だけになるのだ。そのときが、UWPアプリ開発に移行するチャンスになるだろう。

 Windows 7の延長サポートは2020年1月14日に終了する(今から4年半後)。同様にWindows 8.1は2023年1月10日までである(今から7年半後)*3。そのときまでに、クライアントとして使っているWindows PCは全てWindows 10になっているはずなのだ。Windows 10だけになる時期が、移行戦略のスケジュールを考えるときの一つの目安となるだろう。

*3 Windows 8から8.1へのアップグレードはサービスパック(以降、SP)扱いであった。SPの場合、一般公開後2年でSP以前のバージョンのサポートが打ち切られる。そのため、Windows 8のサポートは今から半年後の2016年1月12日で終了する(マイクロソフトサポートライフサイクルの検索結果参照)。筆者は、Windows 8.1から10へのアップグレードもSP扱いになる可能性があるのではないかと考えている。もしもそうなった場合には、Windows 8.1のサポート期間が短縮されることになるだろう。


新しいWindowsデバイスの導入意欲

 あなたの組織やその顧客の組織は、Windows 10搭載のスマートフォンやSurface Hubといった新しいWindowsデバイスを導入しようとするだろうか? それら新しいWindowsデバイス用には、UWPアプリを開発することになる。

早急に「クラウド型」システムアーキテクチャへの移行計画を

 UWPへのハードルで最も難しいのは、「クラウド型」システムアーキテクチャへの対応であろう。あなたが今まで開発してきたデスクトップアプリとは、恐らく根本的に違っているだろう。そこで、段階的に移行する計画を立てることをお勧めしたい。UWPアプリ開発へ移行する前に、WindowsフォームやWPFで「クラウド型」システムアーキテクチャのアプリを開発してみるのだ。いっぺんに越えるには高過ぎるハードルでも、いくつかに分解して一つ一つ越えていけば楽になるのである。

 なお、「クラウド型」システムアーキテクチャではWebサービスの開発も伴う。その経験にも乏しいようなら、Webサービス開発に習熟するための計画も必要となる。

WPFは得意ですよね?

 もしそうでなかったとしたら、WPFへの移行計画を進めよう。XAMLでUIを構築する手法は、UWPアプリでもほぼ同じである。UWPアプリへ移行するハードルの一部を先に越えておくために、WPFアプリ開発をやってみるとよい。

 3年ほど前の調査では、WPFで開発している人はWindowsフォームの5分の1ほどだった。当時はまだWindows XPのサポートも必要とされたので、WPFに移行できないこともあっただろう。Windows XPがなくなった現在では、WPFアプリにしてはいけない理由はないはずだ。

Project Centennialの活用

 UWPへの移行を進めるとき、既存の業務アプリをどうするかという問題も出てくるだろう。全てを一気に作り直すのは現実的ではない。デスクトップPC専用でよければ、Project Centennialを使って既存の業務アプリをUWPアプリに変換できる。

 既存の業務アプリをUWPアプリのAPPXにラッピングし直すことで、UWPアプリのメリットを受けられるようになるのだ。Windowsが「腐る」ことはなくなり、Windowsストアで配布もできる。ただし、UWPによる制限も加えられるので*4、Project Centennialがリリースされたらすぐに検証しておこう。

*4 Project Centennialについては「特集:Build 2015:全ての開発者が押さえておくべきマイクロソフトの最新技術動向」で簡単に紹介した。Build 2015のセッション2-692/2-617で行われた説明によると、レジストリやファイルの読み書きは仮想化されるのだという。このことから、通常のUWPアプリと同じかどうかは分からないが、UWPによってセキュリティ面での制限が加えられるものと予想される。その詳細は、この夏に公表されるという。


まとめ

 Windows 10がリリースされたからといって、業務デスクトップアプリの開発現場がいきなりすっかり変わってしまうということはないだろう。Windows 7/8.1のPCをサポートする必要がある間は、Windows 10だけで動作するUWPアプリを作るわけにはいかないからだ。

 UWPアプリの主なメリットは、マルチデバイス対応(=ユニバーサルアプリ)、Windowsが「腐らない」、そしてセキュアなシステムを構築しやすいことだ。このUWPの価値を高く評価するならば、UWPへの移行時期は早くなるだろう。そうでなくても、数年後にはWindows 10だけになるときが到来し、そこでUWPアプリのニーズが急上昇することになるだろう。そのときに備えて、今からUWPへの移行計画を考えて実行に移していこう。

 UWPへのハードルは低くはない。特に、つい最近までWindows XP用のアプリをやっていたような現場では、大きなハードルがいくつもある。それをいっぺんに飛び越えようというのは無理がある。ハードルを小分けにして、少しずつ越えていけるような計画を立てよう。

「特集:UWPとは何か」のインデックス

特集:UWPとは何か

前のページへ 1|2|3       

Copyright© Digital Advantage Corp. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。