次の方法で共有

ALM Rangers

  • [アーティクル]

ALM の対応状況を巡る宝探し

ALM Rangers

コード サンプルのダウンロード

今回は、Windows ストア アプリのサンプルとして ALM Readiness Treasure Map (ALM の対応状況を示す宝の地図) を紹介し、このアプリを構築しながら設計、コーディング、およびテスト時に Visual Studio ALM Rangers が経験したことを共有します。このアプリは、開発者がアプリケーション ライフサイクル管理 (ALM) のプラクティスに習熟できるようなコンテンツのマスター カタログを提供するようデザインしています。ALM Rangers は、不足している機能に対処し、導入を妨げるものを取り除き、実社会の経験に基づいたベスト プラクティスとガイダンスを提供しながら、Visual Studio 製品グループ、Microsoft サービス、および Microsoft MVP コミュニティの連携を高める専門家グループです。

何を、なぜ行ったか

ここで告白しておくことがあります。私たちは Visual Studio と Visual Studio Team Foundation Server (TFS) を愛しています。マイクロソフトは、利用できる中でも最高のソフトウェア開発ツールをいくつか生み出してきました。これは現在マイクロソフトに勤務しているから言うのではなく、入社するずっと前から感じていたことです。これらの開発ツールは信じられないほど多くの機能を提供しますが、初めてのユーザーは機能が多すぎて困惑してしまうかもしれません。開発者は、このようなツールの使い方をどのように学べばよいのでしょう。この疑問はちょっと変わったかたちで私たちに示されました。

ALM Rangers は技術関連のカンファレンスに出席します。このようなカンファレンスは、通常、マイクロソフト開発ツールについての知識をどのように高めるかに関する多くのセッションから構成されています。カンファレンスでは、参加者がこれらの製品を作成した社内のグループにフィードバックを返す対話型のセッションが開催されることもあります。開発者やコンサルタントにとっては、このようなセッションはすばらしいチャンスになります。ALM Rangers チームに参加してから、それまで発行されているガイダンスの調査を始めたところ、すぐに膨大な量のコンテンツを読まなければならないことがわかり、どこから手を付ければよいかわからないほどです。

実際に求められていたのは、ALM のプラクティスを学ぶのに役立つリソースでした。そこで、私たちは ALM の対応状況を巡る宝の地図を表示する Windows ストア アプリ (ALM Readiness Treasure Map) を構築することに着手しました。ユーザーは、この宝の地図を使って旅をしながら、さまざまな資料を通じてエキスパートになっていきます。図 1 は、その作業の結果です。この地図には次の 5 つのカテゴリがあり、それぞれに複数の学習トピックがあります。

  1. 準備
  2. 概要
  3. ガイダンス
  4. ツール
  5. ワークショップ


図 1 宝の地図を示す Windows ストア アプリ

各カテゴリには、ユーザーができるだけ簡単に必要なスキルを迅速かつ効率的に習得できるようにするガイド、ハンズオン ラボ、およびビデオを含めています。資料のナビゲートは、Microsoft Surface などの新しいタッチ対応デバイスを使うと快適に機能します。

最適なエクスペリエンスになるように、ユーザー エクスペリエンス (UX) デザインの専門家と熟練の開発者の支援を受けながらこのアプリを構築しました。

ALM Readiness Treasure Map ソリューション: UX デザインのポイント

第一印象を良くする: 宝の地図のタイル (図 2 参照) は、砂を表すオレンジ色の背景を持ち、明るく、目を引くものにしました。ユーザーはこのアプリのテーマがすぐにわかります。やしの木や、宝の在りかを示す "X" 印に続く道のりから明らかです。アプリのタイトルも明確に示します。タイルからアプリの内容が明らかになるようにすると、第一印象が良くなります。そして最後に行うことは、ユーザーがアプリを開いて、なぜそのアプリを使っているのかわからなくなったら、助け舟をだすことです。


図 2 Treasure Map Windows ストア アプリのタイル

さらに、スプラッシュ スクリーン (図 3 参照) を活用してアプリの個性をもう少し強調し、起動時のエクスペリエンスを適切に保つようにしています。宝の地図を示すスプラッシュ スクリーンでは、宝への道のりを延ばして描きながら、アプリ読み込み時のエクスペリエンスをスムーズで洗練されたものにします。スプラッシュ スクリーンは、すっきりとしたわかりやすいデザインにし、UX がどのようなものかを示します。また、スプラッシュ スクリーンを個性的にすれば、ブランドが強調されます。


図 3 Treasure Map Windows ストア アプリのスプラッシュ スクリーン

アプリが読み込まれるとホームページ (宝の地図自体) が開きます。ここでも、わかりやすく、コンテンツを重視したデザインにして、アプリの目的がすぐにわかるようにします。ユーザーがさらにアプリを探索したくなるように、このページを魅力的にします。ホームページは旅の出発点になるので、ユーザーにはひと目でこれが旅の始まりになることがわかるようにします。タイトルはナビゲーションの情報源になるため、「クロムよりもコンテンツを重視する」デザインによって際立たせます。機能とは無関係の要素を極力排除して、アプリのコンテンツを強調します。すばやく情報を見つけたいと考えるユーザーはアプリをナビゲートしなくてもこの画面からすべてのリンクを見つけられるようにして、どのようなユーザーにもすばらしいエクスペリエンスになるようにします。

見過ごしがちな重要なこと: Windows 8 の UI では、どのようなアプリであっても、グリッド システムの原理を使用します。この原理により、わかりやすくて、すっきりしたデザインになります。

宝の地図アプリは、ホームページ以外はすべてグリッド システムを採用して、コンテンツを非常に見やすくしています (クロムを減らし、コンテンツを重視しています)。クロムよりもコンテンツを重視する原則は、Windows ストア アプリ スタイル特有の原則の 1 つで、表示に統一感が生まれ、優れた UX につながります。今回のホームページは、唯一この規則を当てはめていません。ホームページでは、旅と海賊風のテーマをビジュアルに表現しています。

文字体裁も見過ごされがちで、文字体裁によってアプリのブランドをどれほど強化できるかを認識していない開発者もたくさんいます。適切かつ一貫性のあるフォントを使うことで、明快さが得られ、わかりやすく、すっきりとした外観になり、アプリが読みやすく、使いやすいものになります。お勧めのフォントは Segoe UI (主にボタンなどの UI 要素に使用)、Calibri (電子メールなどの読み書きに使用)、および Cambria (テキストの大きめのブロックに使用) です。ここでは、見出しを除くすべてのテキストに Segoe UI を使用しました。見出しには Blackadder ITC を使用し、インパクトのあるテーマを実現しました (図 4 参照)。海賊風のテーマを強調するために、アプリの外観を紙の地図のようにしたかったので、見出しだけはフォントの規則を当てはめませんでした。今回の場合は、うまく機能しています。


図 4 Treasure Map Windows ストア アプリで使用した文字体裁

使いやすさと優れた UX を実現するには、シームレスでなめらかなナビゲーションが不可欠です。推奨するナビゲーション パターンには、階層型システムとフラット システムの 2 つの形式があります (図 5 参照)。ほとんどのアプリでは階層型システムが使用されます。これは最も一般的で、多くのユーザーにとって最も使い慣れたナビゲーションでしょう。使いやすく、なめらかな体感にするために最適なシステムでもあります。フラット システムは主にゲーム、ブラウザー、または文書作成アプリに使用され、ユーザーは同じ階層レベルで前後に移動することしかできません。宝の地図アプリでは階層型システムを採用していますが、うまく機能していると信じています。ホームページはハブに分類され、ホームページの各セクションが最初の階層の分岐を生み出し、分岐先から別の階層分岐を生み出します。たとえば、ホームページから準備セクションにナビゲートでき、そこから他の準備サブセクションを展開できます。


図 5 推奨ナビゲーション パターン

ユーザビリティ: アプリの UX が次のことを満たしているかどうかを評価することが重要です。

  • 使いやすい
  • ユーザーにとっての価値が高い (提供する機能など)
  • 使いたいと思わせる

デザインを評価することで優れた UX となり、ユーザーが便利さや使いやすさを感じて、気に入ってもらえるという自信が生まれます。

では、アプリの UX はどのように評価するのでしょう。評価の方法はたくさんありますが、自己評価と認知的ウォークスルーという 2 つの方法が一般的です (図 6 参照)。

図 6 アプリの UX の評価

  自己評価 認知的ウォークスルー
理由 ユーザーに達成してほしい目標や見つけてほしい目標を基準に評価します。アプリの目的とデザインの方向性が一致していることを確認します。 「VM ファクトリのツールとガイダンス」に関する情報を見つけるといった具合に、ユーザーが実現したい特定のタスクを中心にやや構造化して評価します。
時期 スプリントごと、またはそれぞれの目標が達したときに、最大 30 分程度継続して行います。 デザイン プロセス中、および各スプリントすべてで行います。

アプリの自己評価とアプリの認知的ウォークスルーはどちらも、次の 4 つの評価基準で成功しているかどうかを評価します。

  • 長所: アプリの長所は何か。外観で重視しているのは何か。
  • 使いやすさ: ユーザーが把握、認識すべきことは何か。アプリを利用して成功を収めることができるのは何か。
  • 便利さ: ユーザーが価値を感じることは何か。
  • 魅力: ユーザーが満足し、気に入るのはアプリのどの部分か。

今回は自己評価と認知的ウォークスルーを両方行いました。自己評価は、すべてのスプリントで実行し、毎週の会議でレビューしました。認知的ウォークスルーは、デザイン プロセス中と、すべてのスプリントで毎回実行しました。アプリの UX を評価することで、ユーザーが認識するエクスペリエンスに対する希望や感情的な結び付きを理解できるようになります。

UX デザインのまとめ

  • タイルでアプリの内容がわかるようにする。
  • 独特なスプラッシュ スクリーンを作成してブランドを強調する。
  • 明確さを重視してコンテンツを作成する。
  • 推奨のグリッド レイアウトを使って、シンプルかつ明確なデザインを作成する。
  • 文字体裁を忘れずに検討し、可能であれば、Segoe UI、Calibri、Cambria などの推奨フォントを使用する。
  • ナビゲーション パターンを明確にし、階層型システムかフラット システムのいずれかを選択する。
  • 開発サイクルを通してアプリのユーザビリティを評価する。

コーディングの重要事項

コーディングを始める前に、プロジェクトのコーディング目標をいくつか定めます。こうした目標が、コードベースの設計と開発の方法の道しるべになります。

  • 適応性: 要件は変わり、機能は追加または削除され、デザインはまったく違うものに代わることがあります。適応性があるコーディングが最も重要です。
  • 簡潔さ: 特にメンテナンスやバグの修正を考えると、ソフトウェア デザインの多くのメリットの基本は簡潔さです。
  • テストの容易性: あらゆるプロジェクトで品質保証に高い優先順位を付け、コードベースは包括的で "シンプル" なテストを可能にする必要があります。
  • パフォーマンスとなめらかさ: アプリの UX は当初から肯定的なものにする必要があります。適切なタイミングで情報を表示し、常にユーザー入力に対応し、遅延が生じないようにします。
  • チーム環境: アプリが個人の開発者、または 1 つのチームで構築されることはほとんどありません。多くのチーム メンバーに展開できるような方法でアプリを構築します。

このような目標を定義した後、短期間 (他にもやるべきことがある中) で、機能要件だけでなく、機能以外の要件も満たしつつ、このアプリを作成しました。私たちにとってさいわいだったのは、基礎部分は以前に作成したことがあり、実証済みのパターンとプラクティスを適用してアプリを作成できたことです。

  • C# と XAML: C# と XAML を使うことにした主な理由は、このプロジェクトの参加者の大半が使い慣れていたためです。言語自体だけでなく、ツールやサポートにも慣れていました。
  • モデル - ビュー - ビューモデル (MVVM: Model-View-ViewModel): これは、オブジェクトのビジネス ロジックをプレゼンテーション層から分離するためのパターンです。C# と XAML の技術はこのパターンに非常に適しているため選択しました。しかし、さらに重要なのは、1 つのパターンにすることで、機能以外の要件をちょっとずつ満たしていけるようになります。MVVM が最も効果を発揮するコーディング目標は、適応性、テストの容易性、チーム環境、および簡潔さです。アプリの機能単位を交換できるようにすることで、適応性が向上します。おそらく、特定のビュー モデルの新しいプレゼンテーションが完成したら、他のコードを変更することなくすぐに置き換えられます。コードの中核となる機能単位はそれぞれ独自の個別の役割に分けられるため、テストが容易になります。つまり、個々の役割ごとにテストを直接作成して、自動化できます。アプリの中で変化するパーツ間の関係には一連のコントラクトを定義して、複数のチームが他のチームと平行して作業できるようにしたため、チーム環境が向上します。変化するパーツがそれぞれ独自の定義済みパーツになっていて、明確な方法でやり取りするため、簡潔さが向上します。詳細については、「Microsoft Test Manager 2012 の新機能」( msdn.microsoft.com/magazine/jj618301) を参照してください。
  • リソース: MVVM、役割の分離、置き換え可能なパーツという考え方に従い、フォント、ボタンなどのデザイン要素の定義のためにリソースを追加することにしました。これにより、チーム環境、簡潔さ、および適応性が向上します。
  • パフォーマンスとなめらかさの点では、長時間実行するプロセス用の async/await パターンに従いました。これは、開発者が Windows ストア アプリの構築で苦労する領域の 1 つですが、必ずしも難しいわけではありません。さいわい、C# と XAML を使う Windows ストア アプリは Microsoft .NET Framework 4.5 のサポートを受けられるので、このパターンを使ってアプリに非同期ワークロードを簡単に含めることができます。そんなに簡単にできるのだとしたら、なぜ苦労する必要があるのでしょう。多くの場合、この疑問への答えは、つまるところ長時間実行し、.NET Framework が組み込みで提供していないロジックを使用することにあります。たとえば、グラフをプロットする点を複雑な数学に基づいて計算するような場合です。なめらかで、パフォーマンスの高いアプリを提供するためには、async と await をしっかりと理解することが重要です。詳細については、「非同期のパフォーマンス: 非同期と待機のコストについて」( msdn.microsoft.com/magazine/hh456402) を参照してください。

その他の考慮事項

  • タッチ言語: 開発の点からは、これほど簡単なものはありません。ほとんどすべての組み込みコントロールが、想定されるすべてタッチ手法をサポートします。コーディングの点からも、最も簡単に構築できた部分です。
  • チャーム: チャームの操作も、同様にシンプルです。チャームを appxmanifest に登録し、検索や共有など、登録する特定のチャームのイベント ハンドラーを各ページに追加します。チャームの処理には何も問題ありませんでした。チャームは、目的どおり適切に機能しました。
  • タイル、スプラッシュ スクリーン、および向き: これらはすべて appxmanifest で処理され、その後アプリ レベルのイベント フックで処理されます。これらはわかりやすく、すべてサンプル コードで詳しく示されています。

これらすべての実際の動作方法: 実際の実践でどのように動作するかを示します。

  • MVVM コマンド: MVVM は理論的にはすばらしいのですが、実際には、以前作成したサンプルが機能せず、特に実装コマンドに関して通常の Windows Presentation Foundation (WPF) や Silverlight の開発とは少し異なることが明らかになりました。さいわい、Command<T> は新しいフレームワークに非常に簡単に実装でき、以前のサンプル アプリでも確認できます。しかし、ListViewBase 項目にはアタッチされるコマンド プロパティがないため、コマンドの問題は解決しませんでした。そこで今回はデモのため、これを 2 つの方法で解決することにしました。

まず、未使用のプロパティを使ってこの問題を解決することにしました。

<ListView Grid.Column="2"
          SelectedItem="{Binding Selected,Mode=TwoWay}"

バインド先のプロパティは "null" を返し、例外を一切スローしません (例外をすべて有効にしても)。これはすばらしいのですが、キーがセット内にあります。セット内では、何かを設定する代わりに、選択した項目のインデックスをパラメータとして渡してナビゲーション呼び出しを行います。

次に、ICommand 型のアタッチされる依存関係プロパティを作成することにしました。サンプル実装は、"MVVMSupport" フォルダーの "ItemClickCommand" クラスにあります。

  • 複数のビュー ステートは膨大なビュー ファイルになる: ビュー ファイルは、非常に大きく、管理が困難になりました。これは、主にビュー ステートが複数あるためです。一般に、ビュー ステートごとに別のレイアウトが必要で、表示サイズが異なる場合やサイズが変化する場合は、それぞれ異なるビューを用意することになります。今回は、ビュー ステートごとに 1 つ .xaml ファイルを使い、これらを複数の .xaml ファイルに分割しました。たとえば、"HomePageView" という名前のビューがある場合、全画面用、スナップ画面用、塗りつぶし画面用のフォルダー内にビューステートごとに 1 つずつ "HomePageView.xaml" を用意します。
  • 実環境に適応する: これはうまくいきました。アプリの大部分を開発した後、データ プロバイダーの切り替え、UI の切り替え、およびすべての適切な場所への新しいチャーム操作の追加といった要件の変化に適応させるのは簡単でした。問題点は簡単に追跡でき、設計者が開発者やスポンサーと共同作業できたため、計画のほとんどは成功しました。

まとめると、コーディングの点では、Windows ストア アプリを正しく開発するのは簡単です。いくつかの定義済みの規則、考え方、およびパターンに従うと、優れたアプリをすばやく作成できます。主な懸念事項は、アプリのビュー ステート、アプリのライフサイクル ステート、チャーム操作、なめらかさ、および設計チームが設計を自由に再利用できるようにコードを作成することです。詳細については、 https://msdn.microsoft.com/ja-jp/windows/apps/ を参照してください。

ソリューションの品質のテストと検証

開発前に定義した中核となる受け入れ要件の 1 つは、サンプル コードの品質を高め、全体品質に関する社内プログラム ( aka.ms/df_tooling、英語) の一部にすることでした。地政学、名前空間、コード分析、StyleCop ( stylecop.codeplex.com、英語) コンプライアンスの厳密なクオリティ ゲートは、より良いソリューション (サンプルにすぎませんが) を生成するのに役立ちました。

テストは後から行うべきではありません。ミッション クリティカルなソリューションと同様に、サンプルでもテストが重要です。コンプライアンスの数百ものバグや、いらいらしたテスターを目の当たりにし、品質改良サイクルの遅れを伴い、機能やコード チャーンを処理する必要が生じるよりも、高い品質のコードを要求し、ユーザーの期待と要件を最初から管理する方が簡単です。

目的は簡単なサンプル ソリューションを作成することなので、主にシステムの一部としての動作に注目する "ブラック ボックス" テストとユーザー受け入れテストを採用しました。前者はチームが手動で実行し、想定する機能と機能以外の要件に注目して、内部のしくみが把握されているエッジ ケースを探索します。UAT の検証をサポートするためにコミュニティを招待し、実際のシナリオと想定に基づき探索的テストを実行し、バグ、および不足した、非実用的で不明確な機能を調べます。

図 7 に示すように (ここの数字は図の赤丸の数字と対応しています)、通常は Microsoft Test Manager 探索テスト機能 (1) とシミュレーター (2) を使用して Surface 型のデバイスでサンプル ソリューションを評価し、詳細なコメントを取得して (3)、将来の参照のためにテスト セッションを記録します (4)。


図 7 探索テスト

将来、より構造化されたテスト ケースの定義と Microsoft Fakes を使用してユニットとスモーク テストの実装に役立てることを真剣に検討します。それにより、機能の変化と、関連付けられたコードの変化を自動的かつ継続的に検証できるようになります。

今後の展望

ALM Readiness Treasure Map アプリを進化させ、ALM の対応状況の参照アセットのオンライン更新機能を検討しています。詳細については、「Visual Studio ALM Rangers を理解する」( aka.ms/vsarunderstand、英語)、「Visual Studio ALM Ranger ソリューション」( aka.ms/vsarsolutions、英語)、「ALM Readiness Treasure Map サンプル コード」( aka.ms/almtreasure、英語)、Windows ストアのアプリ自体 ( aka.ms/vsartmapapp) を参照してください。率直なご意見、ご感想をいただけるとさいわいです。

Anisha Pindoria は、英国のマイクロソフト コンサルティング サービスの UX 開発コンサルタントです。

Dave Crook は、マイクロソフト コンサルティング サービス東部の開発コンサルタントで、Visual Studio と Team Foundation Server に重点を置いています。

Robert Bernstein は、マイクロソフト コンサルティング サービス ワールドワイド パブリック セクター サイバー セキュリティ チームのシニア開発者です。

Robert MacLean は、BBD ( bbd.co.za、英語) の典型的なオープンプランの開発オフィスのソフトウェア開発者です。

WillyPeter Schaub は、Microsoft Canada Development Center で、Visual Studio ALM Rangers のシニア プログラム マネージャーを務めています。

この記事のレビューに協力してくれた技術スタッフの Patricia Wagner (マイクロソフト) に心より感謝いたします。