ビジョン・ドキュメントは、プログラム、製品、またはプロジェクトの概略のスコープと目的を定義したものです。 問題の明確な記述や、提案ソリューション、および製品の概略のフィーチャーにより、予測を行い、リスクを削減することができます。 このトピックでは、ビジョン・ドキュメントで想定されるコンテンツの概要を説明します。
どのように製品所有者またはビジネス分析者が利害関係者と連携してビジョン・ドキュメントを作成するのかについては、
『ビジョンの作成』を参照してください。 同トピックは Collaborative Lifecycle Management のシナリオ・ガイダンスの一部であり、ビジョン作成のプロセスについて説明しています。 ここで説明するトピックでは、この文書の一般的なコンテンツについて概要を示します。 この概要をコピーして新規文書に貼り付けて、ビジョン・ドキュメントの土台として使用することができます。
この概要のなかで、ユーザーのプロジェクトに関連する部分を使用してください。
チームで Rational® solution for Collaborative
Lifecycle Management (CLM) 内の「要求管理 (RM)」機能を使用する場合は、ビジョン・ドキュメントを 1 つ以上のリッチ・テキスト文書またはモジュールで表現することができます。要求および関連成果物をリッチ・テキスト文書に埋め込むか、モジュールの番号付き階層構造を使用して、内容を編成することができます。
チーム・メンバーは、各成果物に属性 (優先順位やステータスなど) を設定でき、また関連文書、モジュール、および個々の成果物の間にトレース・リンクを作成することができます。
文書およびモジュールを作成およびリンクするためのステップを確認するには、以下を参照してください。
ビジョン・ドキュメントの概要
1: 概説
この概説では、ビジョン・ドキュメント全体の概要を示します。 これには、文書全体の目的、スコープ、定義、頭文字、省略形、参照、および概要が含まれています。
1.1 目的: このビジョン・ドキュメントの目的を記述します。
1.2 スコープ: この文書に関連付けられるプログラム、プロジェクト、アプリケーション、およびビジネス・プロセスなど、このビジョン・ドキュメントのスコープを簡潔に記述します。
この文書が影響を与える対象が他にあれば、記載してください。
1.3 定義、頭文字、および省略形: ビジョンを正しく解釈するために必要なすべての用語、頭文字、および省略形を定義します。 この情報は、プロジェクト用語集を参照することで提供される場合もあります。
プロジェクト用語集は、RM リポジトリーでオンラインで作成できます。
1.4 参照: ビジョン・ドキュメントが参照するすべての文書をリストします。 各文書は、タイトル、レポート番号 (該当する場合)、日付、発行元組織で特定します。
リーダーが参照先を入手できるソースを指定してください。RM またはその他のオンラインのリポジトリー内で使用可能であれば理想的です。
この情報は、付録または別の文書を参照することで提供される場合もあります。
1.5 概要: ビジョン・ドキュメントの内容を記述し、その編成方法について説明します。
2: 位置付け
2.1 ビジネス・チャンス: このプロジェクトの対象となるビジネス・チャンスについて簡潔に説明します。
2.2 問題記述: このプロジェクトが解決する問題を要約します。 以下の記述をモデルとして使用し、括弧付きの部分に実際のプロジェクト詳細を記述してください。
(問題の説明) の問題は、(問題によって影響を受ける利害関係者) に影響します。 問題の影響は、(問題による影響の内容) です。 成功ソリューションには、(成功ソリューションのいくつかの主要なメリットのリスト) が含まれます。
2.3 製品の位置付けに関する記述: 製品が市場で取得する、その目標とする独自の位置づけをごく大まかに要約した全体的な記述を示します。
以下の記述をモデルとして使用し、括弧付きの部分に実際のプロジェクト詳細を記述してください。
(ニーズまたは機会の記述) を持つ (ターゲットの顧客) 向け。
(製品名) は、(主要メリット、つまり魅力的な購買理由の記述) を備えた (製品カテゴリー) です。 (主要競合製品) とは異なり、本製品は (主要な差別化事項の記述) です。
製品の位置付けに関する記述は、アプリケーションの趣旨およびプロジェクトの重要性をすべての利害関係者に伝えます。
3: 利害関係者およびユーザーの説明
利害関係者およびユーザーのニーズに即した製品およびサービスを提供するために、要求定義プロセスの一部としてすべての利害関係者を特定して対象とする必要があります。 また、システムのユーザーを特定し、利害関係者のコミュニティーがユーザーを適切に表すようにする必要があります。
このセクションには、プロジェクトに関与する利害関係者およびユーザーのプロファイルを記載します。 また、このセクションは、利害関係者およびユーザーが提案ソリューションによって対処する必要があると考える、主要な問題を特定します。
このセクションでは、特定の要求または要件については記述しません。それらの項目は、利害関係者の要求成果物で別途記録されます。 主要な問題の記述により、要求の背景および理由付けを示します。
3.1
市場デモグラフィック: 製品決定を動機付ける主要な市場デモグラフィックについて要約します。
ターゲットとなる市場セグメントについて説明し、位置付けます。 潜在的なユーザーの数を使用して、市場の規模および成長を予測します。 あるいは、製品または機能強化が満たすニーズに応じて顧客が使用する金額を見積もります。 業界の主な傾向およびテクノロジーについて検討します。 次の戦略上の質問に回答してください。
- その市場での組織の評判はどのようなものですか?
- その評判をどのようにしたいですか?
- この製品またはサービスが目標をどのようにサポートしますか?
3.2
利害関係者の要約: 特定したすべての利害関係者をリストします。 利害関係者タイプごとに、以下の情報を指定します。
- 名前 : 利害関係者タイプの名前を記載します。
- 表す対象 : この利害関係者タイプが表す個人、チーム、または組織を簡潔に記述します。
- 役割 : この利害関係者タイプが開発作業で果たす役割を簡潔に記述します。
3.3
ユーザーの要約: 特定したすべてのユーザー・タイプをリストします。 ユーザー・タイプごとに、以下の情報を指定します。
- 名前 : ユーザー・タイプの名前を記載します。
- 説明 : このタイプのユーザーと開発中のシステムとの関係を簡潔に記述します。
- 利害関係者 : このユーザー・タイプに相当する利害関係者タイプをリストします。
3.4
ユーザー環境: ターゲット・ユーザーの作業環境を詳述します。 以下にいくつかのヒントを示します。
- タスクの実行に関与している人は何人ですか? この数は変化しますか?
- タスク サイクルの長さはどの程度ですか? ユーザーは各アクティビティーにどの程度の時間を費やしますか? この数は変化しますか?
- プロジェクトはどのような固有の環境制約の影響を受けますか? 例えば、ユーザーはモバイル・デバイスを必要とするか、屋外で作業するか、飛行中に作業するか、など。
- 現在使用しているシステム・プラットフォームは何ですか? 今後予定しているプラットフォームはありますか?
- その他に使用しているアプリケーションは何ですか? ご使用のアプリケーションをそれらに統合する必要がありますか?
このセクションには、関係するタスクおよび作業者の概要を示すために、ビジネス・モデルからの抽出を記載することができます。
3.5 利害関係者のプロファイル: 利害関係者ごとに以下の表に記入することで、プロジェクトの各利害関係者について説明します。 なお、利害関係者タイプとしては、ユーザー、戦略部門、法務またはコンプライアンス部門、技術開発者、運用チームなどが考えられます。 完全なプロファイルには、利害関係者タイプごとに以下のトピックが含まれます。
- 代表者 : プロジェクトの利害関係者を代表する人を記載します。(この情報は、別の場所に記述されている場合は任意指定です。) 代表者の名前を入力してください。
- 説明 : 利害関係者タイプについて簡潔に説明します。
- タイプ : 利害関係者の専門知識の評価を示します。例えば、「上級者」、「ビジネス専門家」、「一般ユーザー」、など。この指定によって、技術的背景や知識レベルを示すことができます。
- 責任 : 開発中のシステムに対する利害関係者の主要な責任 (つまり、利害関係者としての利害関係) をリストします。
- 成功基準 : 利害関係者がどのように成功を定義するかを記述します。 利害関係者が得る利益はどのようなものですか?
- 関与 : 利害関係者がどのようにプロジェクトに関与するかを説明します。 可能であれば、関与をプロセスの役割に関連付けてください。例えば、利害関係者は要求レビューアーとなることが考えられます。
- 成果物 : 利害関係者が要求する追加の成果物を特定します。 これらの項目は、開発中のシステムからのプロジェクト成果物またはアウトプットである場合もあります。
- コメントまたは問題 : 成功の障壁となる問題およびその他の関連情報を記述します。
3.6
ユーザー・プロファイル: ユーザー・タイプごとに以下の表に記入することで、システムの各ユーザーについて説明します。
ユーザー・タイプは専門家でも初心者でもあり得ることに注意してください。例えば、専門家がクロスプラットフォームのサポートを備えた高機能で柔軟なツールを求めるのに対し、初心者は使いやすいツールを求めることが考えられます。 完全なプロファイルには、ユーザー・タイプごとに以下のトピックが含まれます。
- 代表者 : プロジェクトのユーザーを代表する人を記載します。
(この情報は、別の場所で記述されている場合は任意指定です。) この代表者は多くの場合、一連のユーザーを代表する利害関係者になります (例えば、利害関係者: 利害関係者 1)。
- 説明 : ユーザー・タイプについて簡潔に説明します。
- タイプ : ユーザーの専門性を示します (上級者、一般ユーザーなど)。 この指定によって、技術的背景や知識レベルを示すことができます。
- 責任 : システムに関するユーザーの主要な責任をリストします (例えば、顧客詳細のキャプチャー、レポートの生成、作業のコーディネートなどを行う各担当者を記載します)。
- 成功基準 : ユーザーがどのように成功を定義するかを記述します。 ユーザーが得る利益はどのようなものですか?
- 関与 : ユーザーがどのようにプロジェクトに関与するかを説明します。
可能であれば、関与をプロセスの役割に関連付けてください。例えば、利害関係者は要求レビューアーとなることが考えられます。
- 成果物: ユーザーが作成する成果物と、その成果物を誰のために作成するのかを特定します。
- コメントまたは問題 : 成功の障壁となる問題およびその他の関連情報を記述します。 ユーザーのジョブを簡単または困難にする傾向について説明してください。
3.7
利害関係者/ユーザーの主要なニーズ: 利害関係者が認識する、主要な問題と既存のソリューションをリストします。
問題ごとに以下の事項を明確にします。
- この問題の原因は何ですか?
- この問題は現在どのように解決されていますか?
- 利害関係者が必要としているソリューションはどのようなものですか?
利害関係者が各問題の解決に置いている相対重要度を把握する必要があります。 ランキングおよび累積投票の手法により、解決する必要がある問題と利害関係者が対処を望む問題を対比的に示すことができます。 以下の表を使用して、利害関係者のニーズを表します。
表 1. 利害関係者のニーズ| ニーズ |
優先順位 |
懸案事項 |
現行ソリューション |
提案ソリューション |
|---|
| |
|
|
|
|
3.8 代替案および競合案: 利害関係者が選択可能であると認識している代替案を特定します。 これらの代替案としては、競合他社の製品の買収、自前のソリューションの構築、現状の維持などが考えられます。 既知の、あるいは選択可能な競合選択肢をリストしてください。 利害関係者が認識している、各競合案の主な強みおよび弱みも記載します。
4: 製品の概要
このセクションでは、製品機能、他のアプリケーションとのインターフェース、およびシステム構成の概略を示します。 このセクションは通常、次のような 3 つのサブセクションで構成されます。
4.1 製品の全体像: 他の関連製品およびユーザーの環境に関連して、製品の全体像を示します。
製品が独立していて、必要なものを完備している場合は、ここにそれを記述します。
製品がより大きなシステムのコンポーネントである場合は、これらのシステムがどのように対話するかに関係付けて、システム間の関連インターフェースを特定します。 より大きなシステムの主要コンポーネント、相互接続、および外部インターフェースを表示する 1 つの方法として、
ビジネス・プロセス・ダイアグラムまたはユースケース・ダイアグラムを使用することができます。
4.2
機能の要約: 製品が提供する主なメリットおよびフィーチャーを要約します。 例えば、顧客サポート・システムではこの部分を使用して、問題の文書化、ルーティング、およびステータス報告について、これらの各機能に必要な内容は詳述せずに記載することが考えられます。 顧客またはその文書を初めて読む人がリストを理解できるように機能を編成してください。 以下の例に示すように、主要なメリットおよびそれをサポートするフィーチャーをリストした単純な表で十分です。
表 2. メリットおよびフィーチャーの例| 顧客のメリット |
サポートするフィーチャー |
|---|
| 新しいサポート・スタッフが製品の使用方法を迅速に学べます。 |
サポート担当者が既知の修正や回避策を素早く特定できるように知識ベースが支援します。 |
| 見過ごしがなくなるため、顧客満足度が向上します。 |
解決プロセス全体にわたって、問題に対する一意的な項目化、分類、および追跡が行われます。 長期にわたる問題が生じた場合には、自動通知が行われます。 |
| 管理者は、問題領域を特定し、スタッフの作業負荷を測定することができます。 |
傾向レポートおよび分布レポートにより、問題ステータスの概要を確認できます。 |
| 分散したサポート・チームが、協力して問題を解決できます。 |
複製サーバーにより、現行データベースの情報を全社的に共有できます。 |
| 顧客は、自分で解決に当たることで、サポート・コストを節減し、応答時間を短縮できます。 |
インターネットを介して知識ベースを使用できます。 知識ベースには、ハイパーテキスト検索機能およびグラフィカル照会エンジンが含まれます。 |
4.3 前提条件と依存関係: ビジョン・ドキュメントに含まれるフィーチャーに影響を与える各要因をリストします。
変更されればビジョン・ドキュメントも変更される前提条件をリストします。
例えば、ソフトウェア製品用に指定されたハードウェアについて特定のオペレーティング・システムが利用できることが前提条件である場合があります。
そのオペレーティング・システムが利用できない場合、ビジョン・ドキュメントを変更する必要が生じます。
4.4 コストおよび価格設定: 関連するコストおよび価格設定による影響と制約を記録します。 例えば、配布コスト (CD の枚数および CD マスタリング)、またはその他の売上原価の制約 (マニュアルおよびパッケージ) は、
アプリケーションの性質によって、プロジェクトの成功にとって重要である場合もあれば、無関係である場合もあります。
4.5 ライセンス交付およびインストール: ライセンス交付およびインストールの問題も、開発作業に直接影響する可能性があります。 例えば、シリアル番号付け、パスワード・セキュリティー、ネットワーク・ライセンス交付などをサポートする必要がある場合には、開発作業で追加のシステム要件を考慮する必要が生じます。 インストール要件によっても、コーディングが影響を受けたり、別個のインストール・ソフトウェアが必要になったりする場合があります。
5: 製品フィーチャー
製品フィーチャーをリストして簡潔に説明します。 フィーチャーとは、ユーザーにメリットを提供するために必要な、システムの持つ機能の概要です。 各フィーチャーは要求されるサービスであり、通常は満足できる結果を得るために一連の情報提供を行う必要があります。 例えば、問題追跡システムのフィーチャーとして、傾向レポートの提供機能が考えられます。 ユースケース・モデルの形が明確になったら、ユースケースについて言及する説明を更新してください。
ビジョン・ドキュメントは関係するさまざまな人々によって読まれるため、詳細レベルは、すべての人が理解できるような一般的なレベルに留めてください。 ただし、ユースケース・モデルやその他の設計文書を作成するために必要な情報をチームに提供するには十分な詳細情報を記述してください。
アプリケーションの複雑性を管理する上で、新規システムまたは増分変更では、25 個から 99 個くらいのフィーチャーを含む程度の大まかなレベルで機能をリストしてください。
これらのフィーチャーにより、製品定義、スコープの管理、およびプロジェクト管理の基盤を得ることができます。 各フィーチャーは、ユースケース・モデルでさらに詳細に拡張されます。
このセクション全体を通じて、各フィーチャーを、ユーザー、オペレーター、または他の外部システムにとって適切なものにしてください。
機能の説明、および対処しなければならないユーザビリティーの問題に関する説明も記載してください。 以下のガイドラインが適用されます。
- 設計は避けてください。 フィーチャーの説明は一般的なレベルに留めてください。 必要な機能、およびそれらを (どのようにではなく) なぜ実装する必要があるのかに重点を置きます。
- 簡単に参照および追跡できるように、すべてのフィーチャーを特定のフィーチャー・タイプの要求として指定してください。
5.1 フィーチャー 1。
5.2 フィーチャー
2。
6: 制約
設計上の制約、外部制約 (運用要求、規制要求など)、またはその他の依存関係を記載してください。
7: 品質の範囲
フィーチャーのセットで説明されない、パフォーマンス、頑強性、耐障害性、ユーザビリティー、および類似の特性の、品質の範囲を定義します。
8: 優先順位
各種システム・フィーチャーの優先順位を定義します。
9: その他の製品要件
概要レベルで、適用される標準、ハードウェア要件またはプラットフォーム要件、パフォーマンス要件、および環境要件をリストします。
9.1
適用される標準: 製品が準拠する必要があるすべての標準をリストします。
このリストに含まれる標準としては以下のようなものが考えられます。
- 法的基準および規制基準 (FDA、UCC)
- 通信規格 (TCP/IP、ISDN)
- プラットフォームの準拠性に関する標準 (Windows、UNIX など)
- 安全基準および品質基準 (UL、ISO、CMM)
9.2 システム要件: アプリケーションのシステム要件を定義します。 サポートされるホストのオペレーティング・システムとネットワーク・プラットフォーム、構成、メモリー、周辺装置、およびコンパニオン・ソフトウェアが含まれる場合があります。
9.3 パフォーマンス要件: パフォーマンス要件について詳述します。 パフォーマンスの問題には、ユーザー負荷要因、帯域幅または通信容量、スループット、精度、信頼性、さまざまな負荷条件での応答時間などの項目が含まれる場合があります。
9.4 環境要件: 必要に応じて、環境要件について詳述します。 ハードウェア・ベースのシステムの場合、環境問題には、温度、衝撃、湿度、放射が含まれる場合があります。 ソフトウェア・アプリケーションの場合、環境要因には、使用条件、ユーザー環境、リソースの可用性、保守問題、エラー処理、およびリカバリーが含まれることがあります。
10: 文書要件
このセクションでは、正常なアプリケーション・デプロイメントをサポートするために作成する必要がある文書について説明します。
10.1 リリース・ノート、README ファイル: リリース・ノートまたは簡略化された README ファイルには、「新機能」セクション、
以前のリリースとの互換性の問題の説明、およびインストールとアップグレードに関する警告が含まれる場合があります。 また、この文書には、リリースでの修正および既知の問題と回避策が含まれるか、それらにリンクする場合もあります。
10.2 オンライン・ヘルプ: 多くのアプリケーションは、ユーザーを支援するためにオンライン・ヘルプ・システムを用意しています。 このようなシステムの性質は、プログラミングの側面 (検索可能な情報および Web のようなナビゲーション) と技術ライティングの側面 (編成およびプレゼンテーション) を組み合わせたものであるため、アプリケーション開発に固有のものです。多くのチームにとって、オンライン・ヘルプ・システムの開発は、スコープの管理およびプロジェクト着手時の計画からメリットが得られるプロジェクト内のプロジェクトです。
10.3 インストール・ガイド: インストール、構成、およびアップグレードの説明を含む文書は、完全なソリューション提供の一部です。
10.4 ラベルおよびパッケージ: 一貫性のある外観は、製品パッケージから始まって、インストール・メニュー、スプラッシュ画面、ヘルプ・システム、GUI ダイアログ・ボックスなどに適用されます。 このセクションでは、コードに組み込むラベルのニーズおよびタイプを定義します。 例えば、著作権および特許の通知、企業ロゴ、標準化されたアイコン、およびその他のグラフィック要素などがあります。
11: 付録 1 - フィーチャー属性
フィーチャーには、実装用に提案される製品アイテムを評価、トラッキング、優先順位付け、および管理するために使用できる属性を設定してください。 すべての要求タイプおよび属性について、別個の要求管理計画に概要を示してください。 ただし、選択したフィーチャーの属性をリストして簡潔に記述することもできます。 以下のサブセクションに、提案されるフィーチャー属性セットを示します。
11.1
ステータス: フィーチャーのステータスは、プロジェクト管理チームによる調整およびレビュー後に設定します。 ステータスは、プロジェクト全体にわたり進行ステータスを追跡します。 以下の表に、一般的なステータス属性値の例を示します。
表 3. ステータス値の例| ステータス |
説明 |
|---|
| 提案済み |
ディスカッション対象であるが、「公式チャネル」によってレビューおよび受諾されていないフィーチャーについて説明します。公式チャネルには、プロジェクト・チーム、製品管理、およびユーザー・コミュニティー
または顧客コミュニティーの代表者から成る作業グループなどが考えられます。 |
| 承認済み |
公式チャネルが便利で実現可能と考え、その実装を承認した機能。 |
| 組み込み済み |
製品のベースラインに組み込まれたフィーチャーです。 |
11.2
メリット: マーケティング・グループ、プロダクト・マネージャー、またはビジネス分析者が、フィーチャーのメリットを設定します。 すべての要求が等しく作成されるわけではありません。 ユーザーに対する相対的なメリットを基準に要求をランク付けすることは、
顧客、分析者、および開発チームのメンバーと話し合いをするきっかけになります。 メリットを使用して、プロジェクトのスコープを管理し、開発の優先順位を決定してください。 以下の表に、一般的なメリットまたは優先順位の属性値の例を示します。
表 4. メリットの優先順位の例| 優先順位 |
説明 |
|---|
| クリティカル |
必須フィーチャー。 重要なフィーチャーを実装できなかった場合は、システムが顧客のニーズを満たさないことを意味します。 すべてのクリティカル・フィーチャーがリリース時に実装されていないと、スケジュールが守れなくなります。 |
| 重要 |
ほとんどのアプリケーションで、システムの有効性と効率のために重要なフィーチャー。 これらの機能は、他の方法では簡単に提供できません。 重要なフィーチャーを省略すると、顧客またはユーザーの満足度、さらには売上にまで影響が出る可能性があります。 ただし、重要なフィーチャーが含まれていなくてもリリースは遅延されません。 |
| 有用 |
あまり一般的ではないアプリケーションで有用なフィーチャー、
あまり頻繁に使用されないフィーチャー、または十分効率的な回避策で対応することができるフィーチャー。 このような項目がリリースに含まれていなくても、売上または顧客満足度への大きな影響は出ないと考えられます。 |
11.3 工数: フィーチャーの実装に必要な工数を、開発チームが見積もります。 他のフィーチャーよりも多くの時間およびリソースが必要になるフィーチャーがあります。 期間、必要なコード、または機能を見積もることで、複雑さを測定し、特定の時間フレーム内に完了できる内容を予想します。 この見積もりを使用して、スコープを管理し、開発の優先順位を決定してください。
11.4 リスク: プロジェクトで望ましくない事象 (コスト超過、スケジュール遅延、さらには中止など) が生じる確率に基づいて、開発チームがリスク・レベルを設定します。
ほとんどのプロジェクト管理担当者にとっては、リスクを高、中、低に分類すれば十分ですが、より細かく分類することも可能です。 プロジェクト・チームのスケジュール見積もりの不確実性 (範囲) を測ることにより、間接的にリスクを評価できる場合も多くあります。
11.5 安定度: フィーチャーが変更されるか、チームによるフィーチャーの理解が変わる確率に基づいて、分析者および開発チームがフィーチャーの安定度を設定します。 安定度は、開発の優先順位を設定し、追加の引き出しが適切な次のアクションである項目を決定できるようにするために使用されます。
11.6 ターゲット・リリース: チームは、目標とする最も早い時期の、フィーチャーを含む製品バージョンを記録します。 このフィールドは、ビジョン・ドキュメントに含まれるフィーチャーを特定のベースライン・リリースに割り振るために使用できます。 ステータス・フィールドと組み合わせると、チームは開発に深く関与することなく、リリースのさまざまなフィーチャーについて提案、記録、議論することができます。 ステータスが「取り込み済み」に設定され、ターゲット・リリースが定義されているフィーチャーのみが実装されます。 スコープの管理では、ターゲット・リリースのバージョン番号を上げることができます。この場合、項目はビジョン・ドキュメントに残りますが、後のリリースにスケジュールされます。
11.7 割り当て先: 多くのプロジェクトで、フィーチャーは、さらなる引き出し、ソフトウェア要件の作成、および実装を担当するフィーチャー・チームに割り当てられます。 このプロセスにより、プロジェクト・チームのすべてのメンバーが、責任についてより深く理解できるようになります。
11.8 理由: チームはこのテキスト・フィールドを、要求されたフィーチャーのソースをトラッキングするために使用します。 要求は、特定の理由のために存在します。
このフィールドには、説明または説明への参照が記録されます。
例えば、参照先として、製品要求仕様書のページと行番号、あるいは顧客のインタビュー・ビデオの時刻 (分) マーカーなどが指定されることが考えられます。
