Windowsプラットフォームで新しくビジネスアプリケーションのラインナップをそろえるのは本当に難しいことです。問題に対する明確な選択肢があった時代は終わりました。この20年間、私たちは優れた選択肢を手に入れました。素早く開発したいならVisual Basic、性能と機能性を確保したいならMFC、というような選択肢です。さらにWinFormsとWPFが現れました。さらにWinFormsの次はSilverlightというWPFよりパワフルではないものの簡単に配置できるという特徴を持った選択肢もあります。
しかし、以前よりもたくさんの選択肢があるにも関わらず、どれを選択しても憂鬱です。WinRTは3つの配置モデルを提供しますが、どれも、ビジネスアプリケーションには向いていません。そして、WPFはSilverlightとWinFormsと同様に遺物になりつつあります。
WinRT: 準備不足
Windows 8で要求されるプラットフォームの問題点について指摘するつもりはありません。最終的にはビジネスはWindows 8に適応するでしょうから。現時点でWinRT 8が抱えている問題、たとえば、ひとつのウィンドウに制限されていることやデバイス統合がないことなどについて指摘するつもりもありません。Build 2013でMicrosoftはこれらの問題はWinRT 8.1で解消されると発表しました。
この記事で問題にしたいのは、これらのことよりシンプルで本当に愚かしいことです。すなわち、配置のシナリオが率直に言って狂っているということです。Microsoftのコンシューマ部門とエンタープライズ部門は戦争でもしているのではないでしょうか。コンシューマ部門はWinRTをWindows Storeにロックインさせてソフトウエア販売の上前を手に入れたいと思っています。AppleとGoogleでは成功したやり方です。その一方でエンタープライズ部門はコンシューマ部門が作った問題を認めずにWinRTを将来を担うものとして売り出そうとしています。
エンタープライズ分野でWinRTアプリを配布するには
まず、すべてのマシンがドメインに参加していなければなりません。大企業にとっては不合理なハードルではないかもしれませんが、ほとんどの小規模企業とある程度の中規模企業はアクティブディレクトリサーバを管理するためのリソースがありません。ほとんどの企業は技術系の企業ではなく、完全なITインフラではなく便利なカスタムのアプリケーションを欲しがっているという事実は忘れられがちです。
また、アクティブディレクトリを構成していてもすべてのマシンを参加させる必要のない会社もあります。理由はさまざまで、多くは正当化できるものではありません。しかし、それでもそのような企業のニーズも満たされるべきでしょう。
ドメインに参加していないマシン向けの方法も計画はされていたようです。2012年4月、Antoine Leblond氏はドメインに参加していないマシン向けのプロダクトキーを手に入れる方法についてブログで紹介するつもりだ、と約束しています。しかし、そのブログ記事は結局書かれませんでした。
また、“信頼したアプリケーションをすべてインストール”というグループポリシーが必要です。このポリシーはドメインに参加しているマシンにとっては十分に合理的です。しかし、ドメインに参加していないマシンはレジストリを手動で編集して設定する必要があります。これは間違いが発生しやすいやり方です。
そして、最後の条件は面白くありません。すべてのアプリケーションがすべてのマシンで信頼されている証明書でサインされていなければならないのです。この条件を満たすには自己署名証明書を作成してすべてのマシンにインストールするか、数百ドル使って実績のある証明局にコードサイン証明書を発行してもらうかしなければなりません。
これらすべてを実施してから、ユーザにどうやってインストール用のPowerShellコマンドを実行するかを教えます。ClickOnceインストーラーはありません。クリックすればインストールを完了させてくれるバッチファイルもありません。PowerShellはデフォルトでは Windows Explorer経由で実行できないからです。
WinRTアプリを更新する
Antoine氏は次のように書いています。
エンドユーザがアプリの更新を検知したり、アプリの更新を入手したりする標準的な方法はありません。
10年近くClickOnceによる自動更新を体験した後、また、手動で更新をしなければならないワークステーションの時代に戻ってきたようです。ユーザはここでもPowerShellのコマンドを実行する必要があります。違いは、更新の場合はバージョン番号をパスに含めなければならないという点です。例えば、
add-appxpackage \\fileserver\ContosoApp\v1.1\ExpenseApp.appx
Silverlight: リタイア
Silverlightは本質的には死んだ技術です。AdobeのFlashとは違い、Internet Explorer 10ですら完全にサポートされていません。ARMベースのマシンではまったく動きません。
Silverlight完成しているか。No。
Microsoftの元従業員や現従業員はSilverlightは“完成”しており、これ以上改善の余地はないと主張しますが、このような主張は馬鹿げていると思います。
Silverlight Toolkitは2011年の12月から更新されていません。これには重要なユーザコントロールが多数含まれていますが、その多くは実運用に耐えられるレベルのものではありません。
さらに悪いことに、Silverlightは利用しやすいユニットテストフレームワークがありません。前述のツールキットの中にプレビュー版がひとつ含まれていますが、設計に問題があり、テスト時間がO(n^2)になってしまいます。私たち独自の実験によれば、ひとつが数ミリ秒しかかからないテストでも数千のケースを実行すると1時間以上かかってしまいます。回避策はUIを変更して、成功したテストを表示しないようにすることです。
WPF: メンテナンスモード
このように言うのは忍びないのですが、WPFの未来はかつてないほど暗そうです。
性能問題は解決されていない
WPFは遅くなりがちです。多くの原因は非表示のタブに数千のスクリーン要素を読みこんだりするなど、開発者の無茶です。また、ユーザコントロールを過度に飾るのも性能劣化の原因です。私は、各テキストボックスの周りに９つのボーダーがあり、それぞれにグラデーションがかかっている画面を見たことがあります。
しかし、WPFのレンダリングパイプラインの性能改善のためにMicrosoftができることもまだたくさんあるはずです。WinRT/XAMLに導入した方法で意図的にWPFやSilverlightへはバックポートしていない方法があるはずです。
ロードマップの破棄
WPF Toolkitは2010年4月からリリースされていません。当初はリリースを一時的に保留にして新しい子供であるSilverlightに注目が集まるようにしたのかと思っていたのですが、WPF Ribbon Toolbar、AutoCompleteBox、AccordionコントロールなどWPFロードマップ上に記載されていることを完成される方向に進んでいません。
マシンパワーが低いと使えない
Windows RTは安価でマシンパワーが低く、バッテリが長持ちする、カジュアルユーザに適したエディションとして構成されています。現時点では安価ではありませんが、価格は下がりつつあります。しかし、“真の.NET”を走らせるのには不十分です。WPFを選択した企業にとってWindows RTは選択肢になりません。
未来像のヒントがない
MicrosoftはAppleのまねをして未来の計画に関する大きな発表を秘密にするのが好きです。この点を考慮すれば、WPFについて大きな機能拡張を準備しており、驚かすために発表していないだけという見立てもできます。しかし、Appleはハードウエアの会社です。もしiPodに投資するなら、その投資はiPodを使い込みきったときに終了します。そして、使いきったときにAppleが代替となる次の製品を発表するのを見るのはとても楽しいことです。
WPFやSilverlightでアプリケーションを作った場合、これから数年使い続けなければならないかもしれないプラットフォームに投資するということです。このような不確実な状態は面白くありません。恐ろしいものです。数年おきにこのような不安な気持ちにならなけらばならないのはとても恐ろしいことです。
さらに輪をかけて不安にさせるのは、Microsoftは自分達や他人に対して技術の放棄をほとんど認めないということです。WinFormsの終了の発表はありません。Silverlightチームがなくなり、メンバは他のプロジェクトへ散ったことも発表されませんでした。LINQ to SQLのために型付きデータセットがドロップされたことも誰も気付きませんでした。大好きだったLINQ to SQLが死ぬのを知ったのはADO.NETチームがLINQ to SQLを採用したときでした。ADO.NETチームはすでに独自の競合フレームワークを持っていたのです。
今可能なこと
では、WPFをどのように位置づければいいのでしょう。現在のWindowsユーザにとってはWPFは最も現実的なビジネスプラットフォームです。OSと深く統合し、Silverlightのような問題は抱えておらず、ClickOnceで自動的に更新され、リッチクライアント開発にこれ以上最適なプラットフォームはありません。しかし、現時点で上手く動作していない点は今後も修正されないでしょう。この点を考えるとWPFを新しいアプリケーション開発に利用するのは正当化し難いです。
ASP.NET: アプリケーションよりウェブサイト
私はインストール型アプリケーションはユーザにとって最高の体験を提供すると信じています。ウェブはどんどん進化していますが、開発者にはまだまだハンディキャップが多いです。F1を押してヘルプを見る、またはF5でリフレッシュするという基本的な動作ですら、ブラウザがショートカットに割り込んでしまうので実現できません。複数のウィンドウをサポートするというようなより複雑なシナリオはユーザと開発者双方にとってフラストレーションがたまります。複数ページのレポートの印刷はVisual Basic 1でも出来たことですが、ウェブではPDFの生成でもしない限り、実現できません。
ASP.NETは安定しており、進化し続けています。ネットブックやWindows XPが動いているディスクトップからWindows 8.1が動いている最新のタブレットまですべてのWindowsマシンをサポートします。さらに労力を割けば、Apple、Google、Blackberryのモバイルでアプリケーションを動かすようにもできます。
Microsoftが提供するASP.NETの利点の多くはMVCから生まれていますが、WebFormsもまだ進化しています。多くのMVCの特徴はWebForms 4.5にバックポートされています。ひとつのウェブサイトでMVCとWebFormsの両方を混ぜることもできます。どちらかの技術を破棄したいなら、段階的に実施することもできるのです。
また、HTML5も日に日に進化していることも見逃せません。それほど規模の大きくないチームにとって、TypeScriptのような技術で大規模な単一ページのウェブアプリケーションを作るのは実現可能な選択肢になりつつあります。または、サイトを小さな、特定の機能に特化したページに分割し、扱いやすいようにするというやり方もあるでしょう。
ウェブサイトの場合、性能も心配です。インストール型のアプリと同じ機能を提供しようとした場合、3倍から4倍の時間がかかってしまいます。しかし、ブラウザの互換性も向上しているためこの差異も小さくなっています。
このようなことを言うのは私にとっては心苦しいのですが、新しいビジネスアプリケーションを作ろうとしている企業は、そのような計画を辞めて、その代わりに社内サイトを立ち上げることを真剣に検討した方がいいかもしれません。
著者について
Jonathan Allen氏は2006年よりInfoQでニュースレポートを書いている。現在は.NETのリードエディタ。InfoQでニュースや役に立つ記事を書くことに興味があるなら jonathan@infoq.comで彼に連絡するとよいだろう。