Project Siena Beta3: 一般ユーザーがビジネス プロセスを変革するカスタムアプリケーションの作成が可能に

本記事は、マイクロソフト本社の Somasegar’s blog の記事を抄訳したものです。 【元記事】Project Siena Beta 3: Enabling business users to create custom apps to transform business processes  2014/7/14 9:45 PM このたび、Project Siena Beta3 をリリース いたしましたことをお知らせいたします。今回のリリースは、ビジネス エキスパート、ビジネス アナリストおよびアプリケーションの企画者向けに、企業のサービス、大手 SaaS、人気のウェブサイトおよびソーシャル サービスに接続することができるパワフルなカスタム モバイル アプリをより簡単に開発していただくことを目的としました。 Project Siena はその公開以来、法人のお客様やソリューション パートナー様から非常に高い評価をいただき、素晴らしい方法でご利用していただいている様子を目にしてまいりました。一般ユーザーの皆さまが、パワフルなモバイル ファーストのカスタム アプリを、一切のプログラミングなしで、ほんの数時間で作成されています。また、これまでのモバイル機器では想像もできなかったほどのシグナル リッチかつメディア リッチなエクスペリエンスとともに、バック エンド サービスや SaaS の拡張によって ビジネス プロセスを変化させたモバイル アプリが開発されたことも存じ上げています。 しかし、もっとも重要なことはユーザーの皆さまがアイディアをアプリに転換することをどのように考えるのかについて、変化の兆しがあらわれたことです。 ビジネス プロセスの変革 ビジネス プロセスの変革についての完全な例として、革新的なターフ、景観管理機械の販売およびレンタルのリーディング プロバイダー、Toro 社…


チーム総合力の強化 ~ Visual Studio ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>> 開発プロジェクトが成功するか、不満足な結果に終わってしまうかは、開発メンバーが「チーム」として総合力を如何に発揮できるかにかかっています。開発メンバーに何人かの優れた開発者がいたとしてもチーム全体としての開発力にばらつきがあったり、チーム連携のための負荷が高く作業に集中できない環境であってはチームとしての総合力を十分に発揮することができません。 プロジェクト マネージャーやリーダーは、チームメンバー全員がそれれぞれのスキルや経験をベースに「個」として活躍する一方で、「チーム」全体としても優れた結果を出せるようチームのに総合力強化を進める必要があります。   チームでの開発においては以下のような課題が発生します。 会社や部門単位で設計ガイドや基本アーキテクチャーを定めてドキュメント化しているが、ほとんどのメンバーがドキュメントを参照せずにプロジェクト毎に独自アーキテクチャーを検証、構築してしまう。 開発時にサブシステムやコンポーネント単位で担当を割り振っているため、コードレビューのタイミングでしか他の開発者のコードを確認する機会がない。そのため、優秀な開発者からのスキル伝搬が十分でなく、また担当者が不在の際に他のメンバーで開発業務をカバーできない、といった問題が発生している。 プロジェクトのステークホルダーへの状況報告を行う際に、現状のプロジェクトステータスを把握するために多大な労力と時間がかかってしまう。   開発プロジェクトの成功を期待しないメンバーはいませんが、チームで必要となる作業を手間と感じて後回しにしたり、他のメンバーとのタイムリーなコミュニケーションができていない等のちょっとしたずれが、チームの成果物の品質に大きな影響を与えることがあります。   チームの総合力を高めるために以下のプラクティスを活用しましょう。   参照アーキテクチャーはコードで用意しよう 企業や部門において参照アーキテクチャーを定める場合、その目的は「参照アーキテクチャーを作ること」ではなく、参照アーキテクチャを活用することで「開発における品質のばらつきを押さえ、効率的なプロジェクト運営を支援する」ことではないでしょうか。ドキュメントとしてのみ用意された設計のガイドラインや参照アーキテクチャーは結局のところ実プロジェクトにおいて利用されないことがほとんどです。 開発の目的はソフトウェアの構築それ自体にあるのですから。参照アーキテクチャを用意するのであればこれから開発するソフトウェアの基盤として利用できるコードとして用意し、それをもとに開発を開始すべきです。   コードの共同所有を推進しよう 開発者それぞれに “こだわりのある” コーディングスタイルがあったり、開発スキルにばらつきがある場合、開発するコード領域を分割する(例えば、サブシステムとして分割する)ことで互いの開発者が他のコーディングに立ち入らないようにすることがあります。これは結局のところコーディングスタイルやスキルのばらつきをそのまま放置することと同じであり、チームの総合力の強化には役立たないアプローチになってしまいます。 チームとしての総合力を強化するのであれば、コードの所有者を分離せずに全ての開発メンバーがすべてのコードに対して責任を持ち、アクセスできるようにコードの共同所有を推進すべきです。 コードを共同所有にすることで、経験の少ない開発メンバーも経験豊富なメンバーのコードに触れることができ、またそのコードの改変等を通じてコーディングスタイルを学んでいくことが可能になります。またメンバーが急に休んだ場合などでも、他のメンバーによって作業をリカバリーできるようになりますので、開発プロジェクトのリスクを低減させることにも役立ちます。   使いやすいツールで情報にアクセスしよう プロジェクトの状況把握にコストがかかる一つの原因は、状況把握の際に利用するツールを使用するために手間がかかったり、あるいはそのようなツールを利用していないために手動で状況把握を行う必要がある、といった点にあります。理想的な環境としては、プロジェクト マネージャーは Excel や MS Project といったツール、開発者であれば開発ツール、といった普段から使い慣れたツールで状況報告や状況の把握ができるように環境を設定すべきです。使い慣れた、普段から使用するツールにそれらの機能が統合されることで、開発メンバーはよりこまめに状況の報告、記録を行うことが可能になり、またプロジェクト状況を確認したい際には新しく情報を集める必要はなく、それら記録された情報をまとめることで状況把握が可能になります。     Visual Studio 2012 では開発チームがこれらのプラクティス実践をスムーズに行えるように、様々な支援機能を提供しています   プラクティス1:参照アーキテクチャーはコードで用意しよう Visual Studio 2012 においては、開発プロジェクトのテンプレートを独自で作成するための機能があります。  …


ソフトウェアの保守におけるアーキテクチャの理解 ~ Visual Studio ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   ソフトウェアのライフサイクルについて考えると、その時間のほとんどは「開発」ではなく「保守」や「運用」に費やされることになります。ところで、保守を行う際に、開発を行ったチーム、メンバーがそのままプロジェクトに残っている、というプロジェクトはどの程度存在するのでしょうか?ほとんどの場合、開発プロジェクトにおいて開発を担当したメンバーは、プロジェクトが順調に進めば進むほど、運用、保守フェーズへの切り替えに伴いプロジェクトを卒業し、別のメンバーが運用、保守を担当することが多いのではないでしょうか?   今回のソリューションシナリオでは、ソフトウェアの保守を担当するチームが Visual Studio の機能を活用し、どのように保守に役立てることができるかを紹介します。   開発メンバーと異なるメンバーが保守を担当する場合、以下のような問題が起こりがちです。   設計ドキュメントに関して、設計フェーズで作成されたものが存在していたとしても、最終的にリリースされ、運用されているソフトウェアの状態をカバーしている最新かつ全体的な設計ドキュメントが存在しておらず、アーキテクチャの全体像がつかめない。   機能強化やデザインの改善のためにコードの変更を行ったところ、他の画面やロジックにおいて副作用が発生してしまい、ソフトウェア全体の整合性が崩れてしまう。   ソフトウェアをより長く、価値あるものとして活用するためには、保守作業を効率化し、変更によるリスクを下げつつ機能強化を積極的に行えるようにすることが銃重要です。   保守におけるこのような課題に対応するためには、以下のようなプラクティス(行動)が挙げられます。   ドキュメントではなくコードを中心に最新のアーキテクチャを理解しよう 開発プロジェクトにおける最終的な成果物は「ドキュメント」ではなく「ソフトウェア」あるいは「コード」そのものです。「コード」を素早く理解するために「ドキュメント」を活用することは重要ですが、本質的なアーキテクチャの理解には「コード」をそのものを活用するのが最も効率的です。   コード変更の前に副作用の範囲やリスクを正しく把握しよう アーキテクチャに対する思い込みや仮定をもとにしてコードの変更を行ってしまうと、思わぬ副作用を引き起こす可能性があります。コード変更に関しては、単体テストを用意することで変更のリスクを低減させることができますので、変更前に十分な単体テストを用意しておき、コードの変更後にもそれらの単体テストが期待通りに「成功」となるかを確認しましょう。     Visual Studio ではコードを作成する際の支援だけでなく、アーキテクチャレベルでのコードの理解を支援し、副作用の少ないコードの改善を実現するための機能を提供しています。   プラクティス1:ドキュメントではなくコードを中心に最新のアーキテクチャを理解しよう Visual Studio 2012 では、アーキテクチャの理解のために「依存関係グラフ」という機能を用意しています。この機能を活用すると、ソリューションやプロジェクトにおけるアセンブリ、名前空間、あるいはクラスごとの関係性をグラフとして視覚化することが可能です。   例えば、以下のスクリーンショットでは、”Tailspin Toys” というソリューションに含まれるアセンブリ(Dll)単位の依存性を表示したものです。   それぞれの情報は、さらにブレイクダウンして詳細情報を確認することが可能です。例えば、先ほどの DLL に含まれる名前空間とその関連情報を表示すると以下のような表示となります。     一方で、各メソッドやクラスといったコード側からアーキテクチャの理解を深めたい場合は同様に「コードマップ」の機能を活用することでコードの内容を視覚化することが可能です。例えは、以下の画面ショットでは、OrderLine…


Web アプリのテストの自動化 ~ Visual Studio ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>> Web アプリケーションは企業における様々な活動において、ユーザーあるいはパートナー企業と直接的にコンタクトを持つことを可能にするシステムです。そのため Web アプリケーションによるユーザー体験(User Experience)は、直接的にサービスや企業のイメージに結び付きやすい傾向にあります。つまり、高い品質のユーザー体験を提供できればサービスや企業の印象もよくなりますし、その逆も成り立ってしまうということです。 従って Web アプリケーションの開発においてはアプリケーションの品質を十分に確認し、また誤ったデータ操作や顧客対応が行われないようにテストを行うことが重要になります。Web アプリケーションは通常は3階層(ブラウザ、アプリケーションサーバー、データベースサーバー)以上に分割され、また他のシステムやサービスと連携を行うことがほとんどです。そのためテストを用意する場合には、それらの階層関係を考慮しつつテストの目的を明確にしたうえでテストを作成する必要があります。    Web アプリケーションのテストを行う際には、以下のような課題を意識する必要があります。   Web アプリケーションは通常は3階層(ブラウザ、アプリケーションサーバー、データベースサーバー)以上に分割され、また他のシステムやサービスと連携を行うことがほとんどです。そのため、それらの階層関係を考慮しつつテストの目的を明確にしたうえで適切なテストを作成する必要があります。   テストの自動化を行う場合に個別にテスト用のツールを調達するとテストを実施するために必要となる教育コストや、情報一元化のためのコストが追加で必要になります。   通常 Web アプリケーションのユーザー数は C/S 方式のアプリケーションよりも多くなる傾向にあるため、ユーザーに対する高品質な体験を提供する重要性は相対的に高くなります。そのため、開発プロジェクトにおいてはこのような課題を以下に解決し、アプリケーションの品質を高めるかが重要になります。     Visual Stuio 2012 では、Web アプリケーション開発において使用可能な様々なテスト機能を用意しており、また品質向上やチームコラボレーションのツールと合わせて利用することによって、高品質な Web アプリケーション開発をサポートします。   Web アプリケーションのアーキテクチャを考慮し、シンプルなテストを作成しよう 通常 Web アプリケーションにおいては次の図のような階層構造をとることがほとんどです。   例えば、ASP.NET の MVC フレームワークを使用した場合、「ブラウザー」の階層には、Vew のコード(JavaScript のスクリプトを含む)が、「サーバー…


コード品質の向上(その1)~ Visual Studio 2012 ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   開発プロジェクトにおける最大の成果物は “動くソフトウェア” であり、またその “ソースコード” でもあります。 一方で全く同じように “動くソフトウェア” であったとしても、「ユーザーからのフィードバックを受け、継続的に価値を提供し続けていく」という視点で考えた際に、メンテナンスが容易な “ソースコード” と、冗長なコードが多かったり、メソッド名がわかりづらい “ソースコード” では、ソフトウェアのライフサイクルを勘案した時に前者のほうがより価値があるのは明らかです。 今回のソリューションシナリオでは、「コード品質の向上 ~その1~」と題して、ソースコードの品質を向上し、よりメンテナンス性の高いコードを書くための Visual Studio 2012 の支援機能を紹介します。   開発チームにおいてコードのメンテナス性に関する取り組み姿勢や基準を共有しないままプロジェクトを進めてしまうと、以下のような問題が発生します。 チームメンバーそれぞれが勝手な命名規則や、独自のコーディングルールに基づいてコードを書いてしまい、プロジェクト全体としてのまとまりがなくなってしまう。また、そのためにコードの可読性が大幅に落ちてしまう。   メンバーによって「メンテナンス性」、に対する意識が異なるために、チーム全体としての基準があいまいになってしまう。またプロジェクトが進むにつれ、どうしても「甘い」基準に引きずられてしまう。   場当たり的なコーディングにより、コピー&ペースト等で似たようなコードが散在してしまい、問題が発生した際に修正個所が複数個所にまたがってしまう。   コードに集中するあまり、実行時のパフォーマンスに関して十分に考慮されていないプログラムができてしまう。   開発プロジェクトにおいてはアプリケーションのライフサイクルの観点から長期的な視野に立ち、メンテナンス性もソフトウェアの品質の一部であるととらえ、コードの品質を向上させることが重要になります。   コードのメンテナンス性、品質に関する課題に対し、以下のようなプラクティスを推進することで、コードの品質の向上への取り組みを進めることが可能です。   コーディング規則やコーディングのプラクティスを活用しよう チームで開発を行う場合、それぞれの開発者が自分の基準で命名を行ったり、コードの見た目を変更したりすると、コード全体としての統一性がかけてしまい、保守性が犠牲になってしまいます。コードの共同所有を進め、チーム全員でコードのメンテナンスがスムーズに行えるよう、標準的なコーティング規則を定めておきましょう。 また、過去の経験から得られた知識や守るべきガイドラインをまとめておき、共有することでチーム全体でのコード品質に対する意識やナレッジを高めましょう。 例えば、MSDN において公開されている「C# のコーティング規則」、「安全なコーディングのガイドライン」、「クラス ライブラリ開発のデザイン ガイドライン」等のドキュメントを活用し、コードの品質向上を進めましょう。     コードの保守容易性を数値で測定しよう コードの保守容易性に関しては、カーネギーメロン大学の研究をもとに提唱されている「サイクロマティック複雑度」と呼ばれる指標があります。具体的にはコードにおける分岐(if…


手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   開発プロジェクトにおける手動テストは、開発者が行う単体テストや結合テストと異なり、ユーザーの代弁者としてアプリケーションに対する操作を通じて品質検証を行う活動です。従ってアプリケーションに対しては技術的な視点よりも、ビジネス的な視点に立って検証を進める必要があります。    このソリューションシナリオでは、手動テストの実施に当たって、どのようなことを考慮することで手動テスト自体の品質向上を図っていくことができるのか、またその中で Visual Studio 2012 のどのような機能を活用できるのかを紹介します。   開発の現場において手動テストを実施する際には、経験豊富なテスト担当者によって用意されたテストドキュメントをもとに、担当者が実際にアプリケーションを操作しながらアプリケーションの検証を進める、といったスタイルがとられることが多いのではないでしょうか? この過程においては、以下のような課題が発生しがちです。   経験豊富なテスト担当者に依存しがちになり、他のメンバーにとって十分なドキュメントが用意されていなかったり、品質基準の定義があいまいなままテストが進んでしまう。   手動テスト(特に探索的テスト)においてバグに遭遇した場合に、再現性のあるシナリオの特定に手間がかかってしまう。   手動テストによってアプリケーションのどれだけの割合がテストできたのかが把握しづらい。   いくつかの条件の組み合わせが必要なテストシナリオの場合、アプリケーションの操作が長くなってしまい、テスト途中における操作の抜けや誤りによって、再度テストを初期状態からやり直す必要がある。   同様の場合に、操作の誤りに気づかないままテストを続けてしまい、間違ってアプリケーションのバグを報告してしまう。あるいは、アプリケーションのバグに気づかずにアプリケーションをリリースしてしまう。   自動化が行いやすい単体テストや負荷テストと異なり、手動テストは人による関与が大きいため、設定したテストシナリオによってアプリケーションの品質が十分に検証できるのか、テストにおけるアプリケーションの操作自体に誤りがないのか、等の基準があいまいなまま、担当者の経験に依存して実施されることが多くあります。   このような問題を解決し、手動テストの品質を向上するには、以下のようなプラクティス(行動)の実践が挙げられます。   手動テストの実施環境を整えよう 手動テストにおいては、特別な実施環境を用意することなく、テストシナリオが書かれたドキュメント(多くの場合は Excel や Word に書かれた操作手順)と、アプリケーションを使用するであろう一般的なユーザーと同様のPC環境でテストを実施することがほとんどです。 しかし、テストにおけるアプリケーション操作の間違いを最小化し、またバグ(あるいはその可能性)を発見した際に、再現性のあるシナリオ特定をスムーズに進めるためにも、テスト担当者に対する支援環境を用意し、テストメンバー全員が同じ手順で、同じ品質基準をもとにテストを実施できる環境を用意すべきなのです。 手動テストの実施環境としては、(1) アプリケーション操作を間違わないためにもわかりやすくシナリオ(操作手順)を伝える環境、(2) テスト実施時の操作やアプリケーションのふるまいを効率的にまとめることのできる環境、(3) バグ発見時にその報告を簡単に実行できる環境、などの環境が考えられます。 このような手動テストの実施環境を用意することで、手動テストの品質を向上していくことを心がけましょう。     手動テストシナリオの品質を高めるために、数値データを活用しよう 手動テストにおける課題の一つが、テスト自体の品質が、テスト担当者の技量に強く依存してしまう、ということです。この問題に対処するためには、メンバー全員が共有できる指標として、「数値データ」を活用するのがよいでしょう。 例えば、手動テスト自体の品質指標として、以下の二つの数値データの活用が考えられます。 (1) ユーザーの要件(ユーザー…


チーム開発における単体テストの実践(その2) ~Visual Studio 2012 ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>    このエントリは、「チーム開発における単体テストの実践~その1~」の後編です。   プラクティス3:既存の単体テスト資産も活用しよう 既存のプロジェクトを受け継いだり、あるいはプロジェクトの統合によって、既存のコード資産とともに、単体テストも「プロジェクト資産」として受け継ぐことがあります。 しかしそれらの単体テストの資産が、これから使おうとしている Unit Testing Framework と異なるものであったり、また、開発チームの違いから、使用している Testing Framework が異なる場合などが起こるかもしれません。 そのような場合においては、単体テストの実行においては、それぞれのフレームワークにあわせたテスト実行が必要でした。   Visual Studio 2012 では、Visual Studio に付属する Microsoft Test 以外のサードパーティ製のフレームワーク、例えばマネージコード用の NUnit や、ネイティブコード用の xUnit++ といったオープンソースの Testing Framework を利用した単体テストに関しても、「テスト エクスプローラー」で一元管理を行うことが可能です。   「テスト エクスプローラー」において、既存の単体テスト資産を表示し、テストの実行等を行うためには、それぞれのフレームワークにあわせた Adaptor を拡張機能マネージャーからインストールします。         このアダプターを利用することにより、既存の単体テスト資産の活用が容易になります。 (もちろん、開発メンバーが Microsoft Test よりも…


チーム開発における単体テストの実践(その1)~Visual Studio 2012 ソリューションシナリオ

<< ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>> ソフトウェア開発において、「開発者テスト」とも位置づけられる「単体テスト(Unit Test)」は、Java における JUnit、.NET 開発における NUnit、また Visual Studio 2005 から提供されている Microsoft Test、といった様々な Unit Testing Framework の登場により、開発現場において広く受け入れられるようになってきました。 また一方で、Test Driven Developmenr (TDD)に代表される方法論の浸透により、単体テストは単なる「テスト」という位置づけではなく、「設計」ツールの一部としても活用されるようになりました。   通常のコードに加えてテストを書く必要のある単体テストの実践は、一見すると、書くべきコードが増え、生産性および保守性の両面でマイナスの影響を与えるように思われがちですが、実際には洗練された設計とコード変更に対する自信をもたらし、開発者に多くのポジティブな影響をもたらしています。     このソリューションシナリオでは、チーム開発における単体テスト実践の際にどのようなプラクティスがあり、また Visual Studio 2012 の機能をどのように活用できるのかを紹介します。   単体テストは手軽にできるテストである反面、チーム開発においては以下のような課題が発生しがちです。      チーム開発においてはメンバー間でのテストに対する「レベル感」の違いがあり、テストの抜け、漏れが起こったり、あるいは必要以上のテストを用意してしまい余計な工数を消費してしまう。   現場においては、新規のコードに新規のテストを書く、というだけでなく、既存のコードに対する単体テストのニーズや、異なる Testing Framework によって構築されている既存の単体テストの活用等の課題が発生する。   開発が進むにつれ、コードとともに管理を行う必要のあるテストコードが増えてしまい、その管理自体が手間になってしまう。   数多くの単体テストを用意していても、変更を行った際に、その変更に対応する単体テストが用意されていなかったり、膨大なテストケースに埋もれて、必要な単体テストが活用されなければ、単体テスト実践の効果は得ることは難しくなってしまうのです。   このような問題を解決し、チーム開発における単体テストの実践をより良いものにするためには、以下のようなプラクティス(行動)が挙げられます。  …


受け入れテストのリスクコントロール~Visual Studio 2012 ソリューションシナリオ

 << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   ソフトウェア開発において、受け入れテストがなぜ重要なのでしょうか?   受け入れテスト、は開発チームが実施してきた開発プロセス~要求定義、開発、そしてテスト~の最後の活動として、ユーザーによって実施される活動です。受け入れテストが完了することにより、開発チームの努力が具体的なものとして認められ、そしてその価値をユーザーに届けることができる、重要な区切りとなるのです。   このソリューション シナリオでは、受け入れテストにおけるリスクコントロールのためにどのようなプラクティスがあり、Visual Studio 2012 がどのようにその実践を支援するのかを紹介します。   受け入れテストにおけるビジネス上の課題、リスクにはどのようなことがあるのでしょうか? 例えば、以下のようなことが起こりがちです。   要求で明示されていない事柄に対する期待値と実現内容のギャップが存在する(例:表形式の一覧情報の表示画面において、任意の項目をキーにしたソートができない、等必要な機能が実装されていない)   要求と実際の開発のギャップに開発後期で気づくため、スケジュール的に後戻りできず、また責任の所在もあいまいなまま不十分なソフトウェアを受け入れてしまう。   これらの原因の一つは「あいまいな要求」によって引き起こされます。   「ソフトウェア開発」は、ユーザーと開発チームの共同作業であり、その認識を如何にすり合わせることができるか、が成功のカギを握っています。 「あいまいな要求」をそのまま放置し、お互いに「行間を読む」ことで、自身に都合のよい内容を「期待」しつつ、ギャップを埋める努力をせずに開発を進めていると、受け入れテスト間際や、あるいは受け入れテストのその瞬間に、ギャップが顕在化し、問題になってしまうのです。    このような問題を解決し、受け入れテストにおけるリスクをコントロールするための本質的な方法は、ユーザーと開発チーム(および、関連するその他の関係者)の認識を早期からすり合わせ、ギャップの顕在化を早めに行うことです。 これを実現するための代表的なプラクティス(行動)として、以下のような項目が挙げられます。   早期から、頻繁にユーザーを巻き込み、要求の定義と検証を段階的に行おう。 「あいまいな要求」への対策としてはいくつかの方法が考えられますが、「ユーザーを巻き込む」というのが最も本質的で、かつ効果的な対策といえるでしょう。 もし、「顧客があまりに多忙で、そもそもこのソフトウェアを「なぜ作らねばならないのか」といったプロジェクトの本質を説明する時間すらさけぬだと知ったら、本来そんなソフトウェアは作られるべきではない」のです(※)。まずは、開発の予算だけでなく、プロジェクトに関わろうとするコミットをユーザーから得ましょう。そして、要求定義を一度だけ行うのではなく、プロジェクトのチェックポイントを設定し、段階的に要求の定義と検証を行うようにしましょう(アジャイルプロジェクトであればイテレーションやデリバリーごとに。ウォーターフォール型であっても各フェーズ毎に見直すことは可能です)。 ※ 「アジャイルサムライ ― 達人開発者への道」 ISBN978-4-274-06856-0 P.70   文書だけでなく、「動くソフトウェア」でフィードバックを得よう。 開発プロジェクトにユーザーを巻き込むことに成功したら、次のステップとして「実際に動くソフトウェア」によって、文書では表しきれないギャップの解消を目指しましょう。ユーザーは複雑でかつ変更に時間のかかる「文書」が欲しいわけではありません。応答性能が期待する値よりも低くても、全体としてのエクスペリエンスが満足できるレベルであるのであれば、応答性能の向上に割く必要のあるリソースを、他の機能の実装に費やしたい、と思うかもしれません。詳細で正確な「文章」よりも、実際に動くソフトウェアで、ユーザーと会話をしましょう。   様々な立場の関係者が、簡単に開発プロジェクトに参加できるようにしよう。 ユーザーや開発チームにおけるプロジェクトマネージャー、開発者、テスト担当者、といったメンバーはもちろん、運用チームやサポートチーム、顧客窓口といった関係者など、様々な立場の関係者が、参加できるようにしましょう。様々な立場の関係者が、ソフトウェア開発に関わることによって、要求のギャップを最小化し、受け入れテストをスムーズに実施することができるようになります。また、それぞれの関係者が、気軽に質問をしたりフィードバックを行うことができるように環境を整えることで、少しでも多くのフィードバックを収集できるようにしましょう。    End-To-End のトレーサビリティを確保しよう。 開発プロジェクトに積極的にかかわってくれる関係者が増え、また多様なツールでフィードバックを送ってくれるようになったら、それらをしっかり記録し、開発チームで共有を行い、ソフトウェアに反映できるようにしましょう。…