次の方法で共有

ビジョンの定義

  • [アーティクル]

 

メアリー カートランド
Microsoft Corporation

2001 年 1 月 10 日

先週のコラムでは、Web サービス ガイダンス チームと、サンプル Web サービスの構築、展開、運用というミッションを紹介し、同じ操作を行うときに考慮する必要がある問題の種類を示しました。 最初のサンプル プロジェクトである Favorites Service も紹介しました。

ご意見やご意見をお寄せいただき、ありがとうございます。 発生した問題を追跡しているので、今後も続けてください。

サンプルをリリースするのに 3 か月かかる理由と、アイデアを発表する前にサンプルを開始しなかった理由を尋ねられた人がいました。 実際、私たちは過去2ヶ月間かなりフルタイムでお気に入りに取り組んでいます。 機能の多くは、正常に 機能しています... しかし、自分のマシンにインストールしたり、インターネット経由で試したりできるサンプルにすべてがうまくパッケージ化される前に、まだ少しの作業があります。 また、サンプル ソースと共に出荷するすべての記事の作成、技術レビュー、編集、処理にも時間がかかります。 そのため、3 か月間のプロジェクト サイクルを目指しています。 2 月中にお気に入りの最初のリリースを取得できるように、指を交差させておきます。 (私がこれを書いているように、チームはリリース日のより良い見積もりを得るためにスケジューリング演習を行います。

コメントの中には、このサンプルを開発するために.NET Frameworkを使用していることを前提とするものもあります。 必ずしもそうであるとは限りません。 ジョブに最適と思うテクノロジを使用します。 そして、ベストは、常に技術的に優れている、使いやすい、またはニュースのほとんどを意味するとは限りません。 何を選択した場合でも、その理由をお知らせし、使用しようとしたときに発生した問題について説明します。

今週は、お気に入りサービスの構築中にチームが遭遇した問題を見始めます。 バックログはかなりありますが、最初から始めます。プロジェクトの目標と目標を考え出します。

作業の開始

Microsoft Solution Framework プロセス モデルでは、プロジェクトの最初のフェーズは構想フェーズです。 構想フェーズでは、プロジェクト チームと顧客がプロジェクトの目標と制約の概要を作成します。 このフェーズの主な成果物は、ビジネスの問題の分析、製品の目標の説明、ソリューションの概念の概要、製品のユーザーのプロファイル、設計目標、プロジェクトのスコープの定義を含むビジョン ドキュメントです。 構想フェーズは、 ビジョン/スコープ承認マイルストーン で最高潮に達します。

私たちのチームは、通常とは異なる出発点から始めました。Web サービスを作成したいと思っていましたが、特定の問題領域を念頭に置いていなかったり、既存のアプリケーションを使用する必要もありませんでした。 そのため、まず、スケーラブルで信頼性の高いなどの構築を正当化できる合理的に現実的なビジネス シナリオを考え出す必要がありました。Web サービス。

私たちは、多くの人を部屋に閉じ込め、潜在的なビジネスや業界、サービス、およびガイダンスに適したトピックとなる技術的な問題をブレーンストーミングすることから始めました。 その過程で、Web サービスを構築する理由がいくつか考え出されました。

  • エンド ユーザーや他の企業が使用する時間の影響を受けるデータまたはパラメーター化されたデータのソースです。 データが頻繁に変化せず、クライアントがほとんどの場合、すべてのデータを必要としている場合は、Web サイトに XML ドキュメントを投稿することもできます。 ただし、クライアントがデータに対してクエリを実行する場合は、Web サービスが多くの意味を持ちます。 クライアントにデータをプッシュする場合は、サブスクリプションと通知の操作も Web サービスの可能性があります。
  • 他の企業が自分自身を実装できない、または実装したくないアルゴリズムを実装します。 この場合、各アルゴリズムは潜在的な Web サービスです。クライアントはデータを渡し、答えで応答します。
  • 他のいくつかのサービスを集約して、より高いレベルのサービスを提供します。 この場合、クライアントは必要な情報の組み合わせを提供し、既存のサービス自体を組み合わせる作業を保存するため、サービスを使用します。
  • ビジネス プロセスをパートナーと統合したいと考えています。 エンタープライズ境界を越えるビジネス プロセスの各ステップは、Web サービスまたは Web サービス操作の可能性があります。
  • 異種または地理的に分散されたエンタープライズ アーキテクチャがあり、アプリケーション統合にプライベート ネットワークまたは密結合プロトコルを使用することは実用的ではありません。 統合する各アプリケーションの API は、潜在的な Web サービスです。
  • 他の Web アプリケーションおよび Web サービス開発者 (ID サービスや課金サービスなど) にインフラストラクチャ サービス ("プラミング") を提供します。 すべてのクライアント プラットフォーム用のカスタム API ライブラリを構築する代わりに、API を Web サービスとして公開できます。

もちろん、これらの理由から、サービスを実装して運用するコストを正当化するのに十分な数の潜在的なクライアントがあるかどうかを検討する必要もあります。

また、一般的な開発者の対象ユーザーを教育するためのサンプル サービスを構築する際に、他にもいくつかの考慮事項があることにもすぐに気付きました。 まず、ビジネス シナリオでは、特定の業界に関する広範な知識を必要としてはなりません。 次に、独自のマシンにサンプルをインストールして実行できるようにしたいと考えています。 第 3 に、多くの興味深いシナリオでは、1 つ以上のデータ ストアまたはフィードが必要です。 所有していないデータ ソースにアクセスする方法を示すサンプル ソース コードの配布には、多くの問題があります。 また 、データ ソース は所有していません...少なくとも、私たちはサンプルを提供する自由を持っているわけではありません。

これにより、オンライン バンキング、ホーム デジタル ビデオ レコーダーの制御、フライト状態のチェック、毎日のコミック サーバーなどのシナリオから、インフラストラクチャ サービスのラインに沿ってさらに多くのシナリオに移行しました。 MSDN が提供できる Web サービスの種類 (サンプルではなく実際のサービス) について考え始めました。 人々が本当に気に入ったアイデアの1つは、MSDNにアクセスするために使用したマシンに関係なく、再び見つけたいMSDNの記事を追跡する方法でした。 その結果、サーバー側のお気に入りのアイデアが得られます。

ビジョン、Rev 1

構築するサービスの大まかなアイデアを得た後、それを中心にビジネス シナリオを構築しました。

  • Web 開発プラクティスのためにクライアント ベースを拡張し、通常の収益ストリームを生成する方法を探しています。 Web サイトが使用する高品質の Web サービスを提供することで、両方の目的を達成できると考えています。 Web サービスは新しい概念であるため、潜在的な顧客は、ビジネスの一部を当社のサービスに賭けることができると確信する必要があると考えています。 したがって、次のティーザー Web サービスが必要です。
    • 潜在顧客の Web サイトに明らかな価値を提供します。
    • ミッション クリティカルなサービスを提供しません。
    • 開発と運用のプラクティスの品質を示します。
    • 適切なコストで実装およびデプロイできます。

プロジェクトのビジョンの最初のカットを次に示します。

  • The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. このプロジェクトのフェーズ 2 では、Web サイトに追加のサービスのライセンスを付与します。 次に例を示します。
    • サイトのページがブックマークされている統計情報。
    • すべてのユーザーのお気に入りのアフィニティ分析に基づく推奨リンク。

技術的な観点から見ると、このシナリオは、お客様から寄せられる多くの質問に対処しているように見えました。 ビジネス ロジックは実装が難しすぎたり、読者に説明するのが難しすぎたりしませんでした。 しかし、誰もが見るためにビジョンステートメントが書き留まった後、いくつかの大きな赤い旗が上がりました:

  • グローバルユーザー識別スキームが必要です。Web サイトがユーザー識別子をサービスに渡すことができるほど一般的なスキームです。
  • エンド ユーザーから直接ではなく、Web サイトから要求が送信された場合、エンド ユーザーを認証するにはどうすればよいですか? 委任が必要なように思えます。または、エンド ユーザーが実際にサイトを使用している場合にのみ、ユーザーの代理で要求を行うために Web サイトを信頼する必要があります。
  • 別の Web サイトから追加されたエンド ユーザーのお気に入りを取得する Web サイトを許可する必要がありますか? その場合、Web サイトにサービスを使用させるか、サービスへのアクセスをライセンスされたサイトに制限する必要がありますか? エンド ユーザーからの何らかの入力なしで、お気に入りサービスに格納されているすべてのデータにサイトがアクセスできるようにすると、大きなプライバシーの問題のように聞こえます。
  • 同様に、Web サービスがユーザーのお気に入りの情報を維持するための更新方法を提供した場合も同様です。 ある Web サイトで、別の Web サイトから追加されたエンド ユーザーのお気に入りを変更できるようにする必要がありますか?
  • エンド ユーザーは、複数の Web サイトから収集されたデータに対してアフィニティ分析などを行っていることがわかった場合、怒鳴ったり叫んだりしませんか? これらのサイトが私たちのサービスを使用していることをどのように知っていますか? エンド ユーザーがサービスに登録してプライバシー設定を行う必要がある場合は、サイトがデータにアクセスする前に行う必要がありますか? エンド ユーザーはどのようにして当社に登録する必要がありますか?

おそらく、いくつかの追加の研究が整っていました。

ビジョン、Rev 2

ユーザーのプライバシーに関して見つけることができるすべてを確認した後、Microsoft の企業プライバシー グループのメンバーと数時間を過ごし、サービスによって有効になる可能性のあるシナリオとプライバシーへの影響について説明しました。 私はノートのページの後にページを取ったが、まだいくつかの未解決の問題があった。 しかし、あるサイトが別のサイトから追加されたデータにアクセスしたり変更したりできるシナリオは、プライバシーの観点から見ると、ひどい目に見えました。 これは、許可すべきではない、つまり、これらのシナリオをカバーするために正確で理解しやすいプライバシー ポリシーを記述するのが難しく、エンド ユーザーがシナリオに慣れていない可能性があるということです。

また、認証の問題に関する予備調査も行いました。 アプリが途中にあるとき、インターネット経由でユーザーをグローバルに識別して認証する良い方法は今のところありません。 Microsoft Passport は、ユーザーがブラウザーを介して Web サイトを操作している場合に最適に機能します。 ただし、Web サイトがユーザーの資格情報を別の Web サイトに渡す安全な方法はありません。 Passport のシングル ログイン機能では、ユーザーが別の Passport 対応サイトに移動するときにユーザー名とパスワードを再入力する必要はありません。 これは、クライアント側のリダイレクトを使用します。 また、Web サービスはエンド ユーザーのマシンと直接対話することはありません。

この予備調査に基づいて、お気に入りを段階的に実装することにしました。 これにより、プライバシーへの影響を整理する時間が長くなります。また、昨年の PDC で複数回言及された IDENTITY Web サービスは、グローバル ID スキームが必要な時点で利用できるようになる可能性があります。

改訂されたビジョンは次のようになります。

  • CY2001 では、エンド ユーザーが Web サイトから選択したページをブックマークして後でアクセスできるようにするお気に入り Web サービスを実装して展開します。 これらのお気に入りは、お気に入りサービスによって格納されるため、エンド ユーザーが使用している任意のマシンまたはデバイスからアクセスできます。
  • お気に入りサービスは潜在的な顧客に広告を出すために使用されるため、質と個人のプライバシーに対する会社のコミットメントを示す高可用性でスケーラブルで安全なサービスである必要があります。

純粋主義者は、これはビジョンステートメントにするには長すぎると主張するかもしれません。 しかし、重要なことは、誰もがそれを何と呼びたいかを理解していることです。

次のようにフェーズを定義しました。

  • フェーズ 1 では、顧客のお気に入りを管理するためにバックグラウンドで使用するために Web サイト開発者にライセンスを付与できる [お気に入り] Web サービスを実装して展開します。 (実質的に、各ライセンシーには、ユーザーのお気に入りのプライベート データ ストアがあります)。また、お気に入りサービスを Web サイトに統合する方法を示すサンプルも提供します。 サービスとサンプルは、2001 年 3 月 1 日までにライセンスを取得できるようになります。 この目標は、2001 年 3 月 1 日までに、1 か月あたり約 10,000 人の新しいエンド ユーザーを表す 5 から 10 個のサイトにサービスのライセンスを付与することです。 (現在のスタッフを考えると、これは管理しやすい成長率だと考えています。
  • フェーズ 2 では、インターネット エクスプローラーと Netscape Navigator 用のブラウザー拡張機能を実装します。この拡張機能を使用すると、エンド ユーザーは、現在のクライアント側のお気に入りを管理するのと同じ方法で、任意の Web サイトに対するお気に入りを安全かつ安全に管理できます。 また、お気に入りの管理、プライバシーに関する声明の読み取り、個人情報の使用に関するユーザー プロファイル オプションの設定、ブラウザー拡張機能のダウンロードに使用できる Web サイトのエンド ユーザーを実装および展開します。 ブラウザー拡張機能と Web サイトは、2001 年 5 月 1 日までに配信されます。 目標は、1 か月あたり 1,000 人の新しいエンド ユーザーに到達することです。
  • フェーズ 3 では、エンド ユーザーが直接保存したお気に入り (ブラウザー アドインまたはお気に入り Web サイトを使用) と、お気に入りサービスのライセンシーを通じて保存されたお気に入りの両方を表示できるように、お気に入り Web サービスを拡張します。 ライセンシーには、コンサルティングのお気に入りサービスが使用されていることをエンド ユーザーに知らせる特別なロゴを表示するオプションがあります (そのため、これらのお気に入りにはブラウザー アドインまたはお気に入りの Web サイトからアクセスすることもできます)。 ライセンシーは、バックグラウンドでお気に入りサービスを引き続き使用する場合があります。その場合、そのサイトを通じて保存されているお気に入りは、ブラウザー アドインまたはお気に入りの Web サイトから使用できなくなります。 フェーズ 3 は、2001 年 6 月 1 日までに配信されます。
    フェーズ 3 は、将来の Web サービスの基盤を提供します。 たとえば、ユーザーが Web ページにアクセスすると、そのページを気に入った他のユーザーも気に入った Web ページの一覧がサイトに表示されます。 Web サイトは、Web サービスからページの一覧を取得します。 この種のプロファイリング サービスを実装するかどうかはまだ決定していません。

その場で、ビジョン文書の残りの部分を肉付けすることができます。

次の手順では、いくつかのユーザー プロファイルを定義しました。 Web サービス プロジェクトのビジョンを定義するときは、 すべての ユーザーが誰なのかを慎重に検討することが重要です。 構想フェーズで識別したユーザー カテゴリは次のとおりです。

  • エンド ユーザー - Web ブラウザーを使用して Web サイトにアクセスするユーザー。
  • ライセンシー - お気に入りサービスを使用する Web サイトを持つビジネス。
  • ライセンシー開発者 - ライセンシーの Web サイトを構築する開発者。
  • ライセンシーオペレーター: ライセンシーの Web サイトのオペレーター。
  • オペレーター - お気に入りサービスの運用を担当するユーザー。

この列に付属する[お気に入りビジョン] ドキュメントで、完全なユーザー プロファイルを読むことができます。 マネージャーとライセンシーのマネージャーといういくつかのカテゴリが見つからなかったことが判明しました。 レポートの要件について考え始めたときに、これらの情報がトリミングされました。 テスト担当者も別のカテゴリとして分割する必要があります。 この一覧は、ほとんどの Web サービス プロジェクトに適した出発点となります。

また、ビジネス目標と設計目標について少し時間を費やしました。 メインの質問の 1 つは、Web サービスを構築する理由です。 あなたはお金を稼ごうとしていますか? ビジネス プロセスを合理化しようとしていますか? それとも、完全に何か他のもの? 何を決めたとしても、要件に影響を与える可能性があります。 たとえば、お気に入りサービスの主な目標は次のとおりです。

  • 品質の高い製品への取り組みを紹介します。
  • 信頼性の低いサービス、セキュリティの問題、または個人のプライバシーの問題による不適切なプレスを避けます。

この目標の組み合わせにより、特にライセンスと機能要件 (スケーラビリティ、可用性など) の分野で、サービスにかなりの数の要件が追加されました。 しかし、お金を稼することは、このプロジェクトの完全な非目標です。 それが目標だったら、ライセンス要件の多くが少し異なる方法で出てくるでしょう。

設計の観点から、ユーザーのプライバシー、セキュリティ、およびその他の機能以外の要件に関する全体的な理念について考える必要があります。 また、世界中のクライアントが Web サービスを使用するかどうか、およびグローバリゼーションとローカライズについて何を意味するのかも考慮する必要があります。 たとえば、設計目標の 2 つを次に示します。

  • 世界中のソリューションを提供する。 サービスとすべてのサポート アプリケーションをグローバル化する必要があります。
  • 信頼性の高いセキュリティで保護されたサービスを提供します。 サービスは高可用性である必要があり、データを失う必要はありません。また、承認されたユーザーによるアクセスのみを許可する必要があります。

残りのビジネス目標と設計目標は、Favorites Vision ドキュメントで確認できます。

まとめ

プロジェクト チームと顧客が全体的な目標、目標、およびスコープを前もって合意している場合は、プロジェクトをいつ完了したかを常に簡単に把握できます。 Web サービス フロントエンドを既存の Web サイトに追加するだけの場合でも、ビジョン ドキュメントを作成する時間を取る価値があります。 フロントエンドを追加する理由 誰がそれを使用すると思いますか? 運用担当者が期待していない、サイトに追加の負荷はどれくらいですか?

お気に入りのビジョンドキュメントを書くことは、私たちにとって貴重な演習でした。 それがなければ、機能仕様に終わった要件の少なくとも半分を逃していたでしょう。たとえば、おそらく、ゲームの後半までプライバシーとセキュリティの問題を認識しなかったでしょう。 ビジョンドキュメントは、私たちのためにも他のことを行います。 機能要求を評価し、要件を優先するための基準を提供します。 このドキュメントでは、将来のフェーズで何を行いたいかを示しています。サンプル設計でそのことを説明できるため、作業を完全に書き直す必要はありません。

来週、ここに記載されているプライバシーの問題について詳しく説明します。 企業プライバシー グループから学んだことをお知らせし、延期した難しい問題についてお話しし、フェーズ 1 に残っているプライバシーの問題と、これらが設計と実装にどのように影響するかについて説明します。

それでは、お会いしましょう。

Mary Kirtland は MSDN Web サービス ガイダンス チームのアーキテクトであり、コーディング、テスト、運用以外のすべてを行います。たとえば、仕様を最新の状態に保つ試み、チームが MSDN の記事で学んだことをすべて書き留め、レビュー中に煩わしい質問をしたり、昼食の注文を行ったりします。