受け入れテストのリスクコントロール～Visual Studio 2012 ソリューションシナリオ
<<クロスポスト：この Blog は、「Visual Studio 日本チーム Blog」へ投降した「受け入れテストのリスクコントロール～Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>>
<< ”Visual Studio 2012 ソリューションシナリオ" では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>
ソフトウェア開発において、受け入れテストがなぜ重要なのでしょうか？
受け入れテスト、は開発チームが実施してきた開発プロセス～要求定義、開発、そしてテスト～の最後の活動として、ユーザーによって実施される活動です。受け入れテストが完了することにより、開発チームの努力が具体的なものとして認められ、そしてその価値をユーザーに届けることができる、重要な区切りとなるのです。
このソリューション シナリオでは、受け入れテストにおけるリスクコントロールのためにどのようなプラクティスがあり、Visual Studio 2012 がどのようにその実践を支援するのかを紹介します。
受け入れテストにおけるビジネス上の課題、リスクにはどのようなことがあるのでしょうか？
例えば、以下のようなことが起こりがちです。
- 要求で明示されていない事柄に対する期待値と実現内容のギャップが存在する（例：表形式の一覧情報の表示画面において、任意の項目をキーにしたソートができない、等必要な機能が実装されていない）
- 要求と実際の開発のギャップに開発後期で気づくため、スケジュール的に後戻りできず、また責任の所在もあいまいなまま不十分なソフトウェアを受け入れてしまう。
これらの原因の一つは「あいまいな要求」によって引き起こされます。
「ソフトウェア開発」は、ユーザーと開発チームの共同作業であり、その認識を如何にすり合わせることができるか、が成功のカギを握っています。
「あいまいな要求」をそのまま放置し、お互いに「行間を読む」ことで、自身に都合のよい内容を「期待」しつつ、ギャップを埋める努力をせずに開発を進めていると、受け入れテスト間際や、あるいは受け入れテストのその瞬間に、ギャップが顕在化し、問題になってしまうのです。
このような問題を解決し、受け入れテストにおけるリスクをコントロールするための本質的な方法は、ユーザーと開発チーム（および、関連するその他の関係者）の認識を早期からすり合わせ、ギャップの顕在化を早めに行うことです。
これを実現するための代表的なプラクティス（行動）として、以下のような項目が挙げられます。
早期から、頻繁にユーザーを巻き込み、要求の定義と検証を段階的に行おう。
「あいまいな要求」への対策としてはいくつかの方法が考えられますが、「ユーザーを巻き込む」というのが最も本質的で、かつ効果的な対策といえるでしょう。 もし、「顧客があまりに多忙で、そもそもこのソフトウェアを「なぜ作らねばならないのか」といったプロジェクトの本質を説明する時間すらさけぬだと知ったら、本来そんなソフトウェアは作られるべきではない」のです（※）。まずは、開発の予算だけでなく、プロジェクトに関わろうとするコミットをユーザーから得ましょう。そして、要求定義を一度だけ行うのではなく、プロジェクトのチェックポイントを設定し、段階的に要求の定義と検証を行うようにしましょう（アジャイルプロジェクトであればイテレーションやデリバリーごとに。ウォーターフォール型であっても各フェーズ毎に見直すことは可能です）。
※ 「アジャイルサムライ ― 達人開発者への道」 ISBN978-4-274-06856-0 P.70
文書だけでなく、「動くソフトウェア」でフィードバックを得よう。
開発プロジェクトにユーザーを巻き込むことに成功したら、次のステップとして「実際に動くソフトウェア」によって、文書では表しきれないギャップの解消を目指しましょう。ユーザーは複雑でかつ変更に時間のかかる「文書」が欲しいわけではありません。応答性能が期待する値よりも低くても、全体としてのエクスペリエンスが満足できるレベルであるのであれば、応答性能の向上に割く必要のあるリソースを、他の機能の実装に費やしたい、と思うかもしれません。詳細で正確な「文章」よりも、実際に動くソフトウェアで、ユーザーと会話をしましょう。
様々な立場の関係者が、簡単に開発プロジェクトに参加できるようにしよう。
ユーザーや開発チームにおけるプロジェクトマネージャー、開発者、テスト担当者、といったメンバーはもちろん、運用チームやサポートチーム、顧客窓口といった関係者など、様々な立場の関係者が、参加できるようにしましょう。様々な立場の関係者が、ソフトウェア開発に関わることによって、要求のギャップを最小化し、受け入れテストをスムーズに実施することができるようになります。また、それぞれの関係者が、気軽に質問をしたりフィードバックを行うことができるように環境を整えることで、少しでも多くのフィードバックを収集できるようにしましょう。
End-To-End のトレーサビリティを確保しよう。
開発プロジェクトに積極的にかかわってくれる関係者が増え、また多様なツールでフィードバックを送ってくれるようになったら、それらをしっかり記録し、開発チームで共有を行い、ソフトウェアに反映できるようにしましょう。 また、それらに対する活動内容や、他の項目とのトレードオフ関係などをオープンに議論したり、その結果を残すことで、開発チームの活動の透明性が増し、関係者の期待値を適切なものに調整し、成果物に対する納得性を高めることができます。
Visual Studio 2012 では開発チームがこれらのプラクティス実践をスムーズに行えるように、様々な支援機能を提供しています。
プラクティス１：早期からユーザーを巻きこもう
ユーザーをプロジェクトに巻き込む上で、障害となるのはどんなことでしょうか？
開発プロジェクトにおけるユーザーは、プロジェクトのオーナーとして限られた予算で、何を実現し、何を行わないか、といったビジネス判断を行う必要があります。また、ソフトウェア開発の分析においては、ドメインエキスパートとしてソフトウェアのコア要素の整理を共同で行う必要があります。一方では、ソフトウェアの使用者としての最新のユーザー エクスペリエンスに対する理解も必要でしょう。さらには、サーバーやクライアントにおける要素技術を理解し、今後の運用においての体制やコストを考慮した技術選択を行う必要もあります。
ユーザーが開発プロジェクトの意義を理解しながらも、あまりに多いタスクに忙殺されているのであれば、ユーザーが参加しやすい仕組みを用意することも必要です。
次に、ユーザーは開発プロジェクトを通じて、何を手に入れたいと思っているのでしょうか？
開発プロジェクトにおけるもっとも本質的な成果物は、現在のビジネスを支える、あるいは今後のビジネスを切り開くための「ソフトウェア」です。開発プロジェクトにおいて様々なドキュメントが作成されるのは、プロジェクト進捗のチェックポイントとして「わかりやすい」からで、多くの場合、決してそれ自体に価値があるわけではありません（ユーザーにとって価値のあるドキュメントも、もちろんあります）。
では、要求定義やユーザーエクスペリエンス、運用のための機能などを表現するのに適していて、ユーザーがそれらを確認するうえでドキュメントよりも適しているものはないのでしょうか？
Visual Studio 2012 のストーリーボード機能を使うと、そんなニーズに応え、ユーザーが開発プロジェクトに早期から「参加しやすく」「ドキュメントより」もわかりやすい形で、これから作り上げるソフトウェアに対してのイメージを広げることが可能です。
具体的にはストーリーボード機能を使うと、開発チームは「動く」ソフトウェアのモックアップを簡単に作成することができ、またユーザーは特別な環境なしにそれらを「動かしながら」ソフトウェアの仕様を検討することが可能になります。
これまで、ソフトウェアのモックを作成する方法としては、紙ベースの “ペーパー ウェア” を使用したり、Visual Studio に代表されるようなビジュアル開発が可能な IDE を使ってプロトタイプを 作成する、といった方法がありました。Visual Studio 2012 のストーリーボード機能は、これらの方法の “いいとこどり” のソリューションを提供しています。
具体的には以下のようなメリットがあります。
(1) PowerPoint を使用するので、開発者以外でも自由にアイディアを出しやすい。
Visual Studio 2012 のストーリーボード機能は PowerPoint を使ったモックアップ作成の機能です。PowerPoint という使い慣れたツールをベースにしていることで、“ペーパーウェア” のように、様々な関係者が自由に作業できるので、発散系のブレインストーミングなどでも利用できます。
(2) PowerPoint を使用するので、ユーザーが確認する場合に特別な環境構築が不要。
プロトタイピングを行う場合、ユーザー環境で確認するために、作成したソフトウェアのインストールや Web サーバーの構築等が必要になることがあります。また、開発チームの環境にユーザーを招いて確認を行う場合は、確認のための時間が十分に取れない、といったこともあります。ストーリーボード機能を使うと、PowerPoint ベースで、「動く」ソフトウェアのモックアップを確認できるので、ユーザーが自分のPC環境で、自分のペースでじっくりとソフトウェアの機能を確認することが可能です。
(3) 無駄なドキュメントを減らすことができる。
要求定義やユーザーエクスペリエンス、運用のための機能を設計、確認するさいに、「動かない」ドキュメントでそれらの活動を進めるよりも、「動く」ソ��トウェアで確認したほうが、素早く正確に行うことが可能です。また、基本的な機能や、動作をストーリーボード機能で定義していくことによって、受け入れテストにおけるテスト基準をより明確に定義することができ、ユーザーと開発チームにおける認識のギャップを減らすことができます。
ストーリーボード機能の使用イメージは「PowerPoint Storyboarding」のビデオ（英語）をご参照ください。
ストーリーボード機能を利用できるVisual Stduio 2012 のエディションは「Visual Studio 2012 の機能比較」のページの「コラボレーション」の項目をご確認ください。ストーリーボード機能は PowerPoint のアドインとして使用できる機能です。ストーリーボード機能で作成されたモックアップは、ストーリーボードのアドインがない PowerPoint 環境でも表示、編集が可能です（アドインを使用しない場合、ライセンスは不要です。ライセンスについては「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください）。
プラクティス2：動くソフトウェアでフィードバックを得よう
ユーザーを巻き込むために、「動く」ソフトウェアが用意できたとして、ユーザーからより良いフィードバックを得るためには何が必要でしょうか？
例えばユーザーが実際に行ってみたソフトウェアの操作や、その中で感じた内容を、メールやWord で文章としてまとめようとすると、個別に画面ショットを撮ったり、「動的な」動きを説明するために多くの文章を書く必要があったり、意外と手間がかかるのではないでしょうか？また、開発チームと同席し、実際に操作しながら口頭でフィードバックを行う、といった方法では手間はかからないかもしれませんが、フィードバックの正確性に問題が残ります。
Visual Studio 2012 のフィードバック機能を使うと、ユーザーは、実際に「動く」ソフトウェアを利用しながら、その操作を動画として記録したり、音声やスクリーンショットを使って実際の操作イメージを共有しながら、開発チームにフィードバックを行うことが可能です。
フィードバック結果は、Visual Studio Team Foundation Server に記録され、開発チームで共有されます。また、ユーザーがフィードバックにおいて 「★」 を使ってフィードバックの重みを定量的に表現することができるので、開発チームがユーザーのフィードバックを検討する際に、ユーザーにとって、どの項目に重きを置いているのか、を共通の認識として持つことが可能です。
Visual Studio 2012 のフィードバック機能によってユーザーは、
(1) ストーリーボード機能をつかったモックアップ
(2) プロトタイプとして作成したソフトウェア
(3) 開発中のソフトウェア
など、開発プロジェクトのフェーズに応じた様々な「動く」ソフトウェアを使って、大きな負荷を感じることなく、積極的にソフトウェアに対するフィードバックを行うことが可能です。
一方で、開発チームはユーザーからのフィードバック情報をもとに、より良いソフトウェアを構築するために、要求の修正を行い、新しいタスクを割り出します。これらの情報、つまりユーザーからの 「A」というフィードバックをもとに、要求「B」が修正され、タスク「C」が新たに作成された、といった情報は、Team Foundation Server にて一元管理されます。従って、要求定義のドキュメントを、Team Foundation Server にて管理している開発プロジェクトでは、どのようなフィードバックによって要求が変更されたのか、といった変更履歴を煩雑な作業を行うことなく残すことができます。
また、複数の関係者から、様々なフィードバックが返された場合でも、「★」による重要度の定量表現や、要求とのトレードオフ関係を記録しておく（Team Foundation Server にて、フィードバックに関係する作業項目を関連付けておく）ことができるために、ユーザーのフィードバックを取り入れることができなかった場合でも、プロジェクト全体の観点に立って、説明を行いやすくなります。
Visual Studio 2012 のフィードバック機能を使った具体的な作業イメージは「Request and Manage Feedback」のビデオ（英語）をご参照ください。
フィードバック機能を利用できるVisual Stduio 2012 のエディションは「Visual Studio 2012 の機能比較」のページの「コラボレーション」の項目をご確認ください。フィードバックを行うユーザーはフィードバック クライアントのインストールが必要になります。また、ユーザー側は特別なライセンス等を必要としません（開発チーム側のみ、必要なライセンスをご用意ください。ライセンスについては「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください）。
プラクティス3：関係者が簡単に参加できるようにしよう
開発プロジェクトの遂行において、いわゆるフォーマルなドキュメントが不要になることはありません。
ユーザーや開発チーム、あるいは運用チームや顧客の窓口（営業）メンバー等の関係者が、それぞれの責務を明確に理解し、プロジェクトのスコープとスケジュールといった重要事項に合意するためにもこれらのドキュメントは省けないものでしょう。
一方で、開発プロジェクトに関わるメンバーの最終目的がドキュメントではなく、ソフトウェアにあることも明らかです。
全ての関係者が開発プロジェクトに積極的にかかわり、それぞれの立場でベストなプロジェクト遂行を目指すためにも、自由に（建設的な）意見を述べ、より良いソフトウェア開発を目指すことのできる雰囲気が重要です。
もし、意見を交換する際に、フォーマルなドキュメントでしか表明できないのであれば、多くの意見を集めることは難しくなってしまうかもしれません。従って、様々な手段で、気軽にプロジェクトに貢献できる手段を用意することは重要です。
Visual Studio 2012 では、前述したストーリーボード機能や、フィードバック機能等、ユーザーからの意見を取り入れ、またそれを管理するための機能を提供しています。またさらに、これらを運用チームや顧客の窓口とも活用することで、プロジェクト全体の透明性を高め、貢献の機会を増やすことができます。
また、単一リポジトリとなる Visual Studio Team Foundatin Server に対しては、開発ツールである Visual Studio だけでなく、Excel や Project、あるいは Web ブラウザ、と複数の方法が用意されているので、 関係者はそれらの使い慣れたツールで情報にアクセスし、フィードバックを行うことも可能です。
Visual Studio において、Team Foundation Server が提供する単一リポジトリに接続し、その情報にアクセスする機能は基本機能の一つです。
この機能と利用するためには、Team Foundation Server の CAL (Client Access License)が、すべてのユーザー毎、あるいはデバイス毎に必要となります（一般的には、Visual Studio 自体がユーザー単位のライセンスとなるので、Team Foundation Server のライセンスに関してもユーザー単位でご購入いただくことが多いです）。また Team Foundation Server のユーザー CAL に関しては、Visual Studio with MSDN (Ultimeta、Premium、Test Professional、Professional の4種類）にも付属するため、これらを購入いただいている開発者であれば、別途 CAL を購入いただく必要はありません。詳しくは、「Visual Studio 2012 の機能比較」をご参照ください。
また、ユーザーがフィードバック機能を使ってフィードバックを行う際など、いくつかのシナリオで、Team Foundation Server の CAL が不要なシナリオがあります。詳しくは「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください。
プラクティス4：トレーサビリティを確保しよう
フィードバックを集めるうえで、最も重要なことはなんでしょうか？
関係者がフィードバックを行う際に、そのモチベーションを支えている最も重要な要素は、「開発チームからの応答」です。
多くのフィードバックが集まったとしても、そのフィードバックに回答しなかったり、あるいは機能として盛り込もうとする意欲が感じられなければ、関係者のフィードバックを行おうとする意欲は次第に下がってしまいます。
従って、集まったフィードバックに対しては、どのような検討を行ったのか、またそれに伴って追加、変更されたタスクがどのような状況なのかを明らかにする必要があります。受け取ったフィードバックに対して対応が難しい場合であっても、トレードオフがある要求との関連性を明らかにしたり、全体的な進捗状況とその中での優先度を明らかにすることで、関係者の納得性を高め、次回のフィードバックの機会にも積極的に関わろうという意欲を持ってもらうことが、結果としてプロジェクトの成功につながるのです。
Visual Studio Team Foundation Server では、関係者から得られたフィードバックを、単一のリポジトリで管理することができ、また関係者はいつでもその情報にアクセスすることができます。さらに、Team Foundation Server に登録したフィードバックや意見を、フォーマルなドキュメントと関連付けたり、全体としての優先順を明示することで、開発チームが実施する作業の透明性を高めすことが可能です。
また関係者は、ブラウザから利用できる開発チームのポータルにアクセスすることで、それぞれのタスクに関連してどの程度の実装が行われており、またテストが実施されているのか、といった情報をグラフ等のわかりやすい形で確認することが可能です。
Team Foundation Server が提供するブラウザベースのポータル機能にアクセスし、利用するには、Team Foundation Server の CAL (Client Access License)が、すべてのユーザー毎、あるいはデバイス毎に必要となります（一般的には、Visual Studio 自体が��ーザー単位のライセンスとなるので、Team Foundation Server のライセンスに関してもユーザー単位でご購入いただくことが多いです）。また Team Foundation Server のユーザー CAL に関しては、Visual Studio with MSDN (Ultimeta、Premium、Test Professional、Professional の4種類）にも付属するため、これらを購入いただいている開発者であれば、別途 CAL を購入いただく必要はありません。
また、Team Foundation Server のバックログ管理や、Sprint Plannning 等の一部の機能は、Visual Studio Ultimate with MSDN、Visual Studio Premium with MSDN、および Visual Studio Test Professional with MSDN に限定されています。詳しくは、「Visual Studio 2012 の機能比較」のページの「Team Foundation Server」の項目をご確認ください。
一方で、Team Foundation Server のレポート機能を閲覧するためだけに Team Foundation Server にアクセスする場合など、Team Foundation Server の CAL が不要なシナリオがあります。詳しくは「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください。
今回は、受け入れテストにおけるリスクコントロールのためのプラクティスと、Visual Studio 2012 の支援機能を紹介しました。
ソリューションシナリオには、以下のシナリオがあります。
・受け入れテストのリスクコントロール（本エントリ）
それでは！