ウェブサイトを再設計することを計画していますか？
それとも、新しいものが必要ですか？
作業範囲記述書と要件定義書が必要です。
ビジョンを伝え、成功への道を切り開くために、
ウェブ開発チームから必要なすべてのことを概説します。

ここでは、新しいWebプロジェクトを提案するプロセスをガイドし、最初の作業範囲記述書と詳細なWebサイト提議書の両方を作成する方法についてアドバイスします。
また、ダウンロードできる無料のテンプレートがいくつか含まれているため、各ドキュメントを簡単に作成できます。

**コンテンツ : **

最初の作業範囲記述書とは何ですか？
作業範囲記述書に含めるもの
プロジェクトの概要とチーム情報
目標と目的
オーディエンスとターゲット市場
フェーズとマイルストーン
バジェット
除外
期限とタイムスケール
ウェブサイト要件定義書とは何ですか？
Webサイト要件定義書に含めるもの
コンテンツとサイト構造
ページテンプレートのワイヤーフレームとモックアップ
デザイン要素
機能と技術仕様
非機能上の考慮事項

最初の作業範囲記述書とは何ですか？

最初の作業範囲記述書は、Webプロジェクトの概要を示しています。目標と目的、予算、期限とタイムスケール、および対象者、ターゲット市場、リスクなどの他の関連情報の概要を説明する必要があります。また、プロジェクトの作業と監督を担当する担当者も含める必要があります。

適切な作業範囲記述書は、次のことを行う必要があります:

Webプロジェクトの目的を明確にする
正確なコスト見積もりを提供する
プロジェクトの予測されるタイムスケールと完了日を強調表示する
予見可能な問題の概要(リスク評価)
主要なオーディエンスを特定し、彼らがサイトにアクセスしている理由を理解する

作業範囲記述書に含めるもの

プロジェクトの概要とチーム情報

ドキュメントの最初のセクションは、プロジェクトの基本的な概要を概説し、関係する主要な利害関係者をリストする機会です。概要では、次の領域に焦点を当てて、開発者と設計者にビジネスの有用な紹介と、新しいサイトから達成したいことを提供します。

あなたの会社の紹介
簡単な歴史と背景、提供する製品/サービスの概要、注目すべき成果、および従業員と部門の内訳が含まれます。
問題を説明する
さらに重要なことに、新しいWebビルドがそれを解決するのにどのように役立つか。おそらくあなたはより多くの顧客を引き付けたいですか？または、サイトをより魅力的にしますか？問題が何であれ、ここにそれを含め、プロジェクトがどのように役立つかを説明してください。
プロジェクト要件の概要
選択したWeb開発チームから何が必要ですか？完全に新しいサイトまたは数ページが再設計されましたか？必要なものを高レベルの観点から設定し、開発者にプロジェクトから必要なものの明確なビジョンを提供します。
A high-level outline of your target audience
while the target audience deserves its own full section in the document, a brief outline will set the tone and help the developers get to grips with your objectives.

プロジェクトの概要に続いて、関係する利害関係者とその連絡先の詳細をリストすることをお勧めします。名前、役職、連絡先情報、および開発者が特定の問題に取り組む相手を知るのに役立つその他のメモを含めます。

例)
- **John Doe (Project Manager)**
- Web Content Director / johndoe@business.org

目標と目的

次のステップは、あなたの目標と目的を概説することです。あなたはあなたのウェブサイトに何を望みますか？そして、プロジェクトの成果を具体的にどのようにしたいと思いますか？これは、達成したいことを開発者に伝えるため、Webサイト要件定義書の最も重要なセクションです。また、ニーズを明確に理解できるため、最終ビルドに統合する要素やソリューションに影響を与えるのにも役立ちます。

Webの再設計または構築から達成したい成果について考えてください。プロジェクトの目標は、測定可能で、具体的かつ現実的であり、既存のサイトのパフォーマンスからの定量化可能なデータに基づいている必要があります。

Webサイトの要件定義書で概説する合理的な目標の例をいくつか示します。

月間閲覧者をX％増やす
今後2年間で特定の製品の売上をX％増加させる
特定のサービスのランディングページで電話による問い合わせをX％増やす
X日までにInstagramで1,000人の新しいフォロワーを獲得する
ユーザーエクスペリエンスを改善して、リードをX％増やします

Webサイトの要件定義書で設定した目標は、現実的で測定可能であることが重要です。 Webビルドは、多くの場合、迅速な成功ではなく、長期的な利益をもたらすことを忘れないでください。

オーディエンスとターゲット市場

あなたはあなたの顧客、聴衆、そしてターゲット市場が誰であるかを理解していますが、外部のウェブ開発者は理解していません。目的を確実に達成するには、効果的なWebサイト要件定義書を作成するために、Webサイトが誰をターゲットにしているかを概説することが重要なステップです。

ターゲット市場を強調することは、Webサイトの構築または再設計を通じて達成しようとしていることを開発者に受け入れさせるための便利な方法です。見込み客や新しいサイトのクライアントをターゲットにしている場合でも、新しいスタッフを採用するためのスタンドアロンポータルを構築している場合でも。開発者は、対象読者を知り、要件を満たし、概要を確認する必要があります。

ターゲットオーディエンスの概要を説明するだけでなく、Webサイトがターゲットオーディエンスに対して何をすべきかについての情報も追加する必要があります。おそらく、販売を促進するためにユーザージャーニーを改善したいですか？それとも、ブログやニュースフィードを通じてエンゲージメントを高めたいですか？あなたの目標と目的が何であれ、彼らはあなたのターゲットとする聴衆と彼らがあなたのサイトに望むものと一致するべきです。

Webサイトの要件定義書を作成するときは、ターゲットとするオーディエンスのタイプを開発者がより理解できるようにする資料を含める必要がある場合があります。関連するデータと統計を含めてオーディエンスを検証し、詳細な顧客ペルソナを作成して、開発者があなたのあなたがするように顧客ベース。

フェーズとマイルストーン

大規模なWebビルドプロジェクトが現実的で成果物であることを保証するには、特定のマイルストーンと期限をそれぞれに割り当てて、プロジェクトを個別のフェーズに分割する必要があることがよくあります。 Webビルドをフェーズに分割すると、プロジェクトが関係するすべての人にとって実行可能であり続けると同時に、次のフェーズに進む前に主要なステージを確認、テスト、および改良する機会が与えられます。

これは、3つの主要なフェーズに分割されたWebビルドプロジェクトの例です。

Phase 1 : 基本的なWebビルド:
これはサイト構築の基盤を形成し、設計、構造、および主要なサイト要素の改良に焦点を合わせています。
Phase 2 : 高度な要素を組み込む:
次のフェーズでは、eコマース機能などの特定の要素を組み込むことに焦点を当てます。
Phase 3 : UXとCRMの展開:
このフェーズでは、オンサイトのユーザージャーニーとエクスペリエンスを改善し、個々の要素を調整してプロセスを改善し、マーケティング活動のROIを最大化することに重点を置きます。

すべてのWebビルドと再設計に個別のフェーズが必要なわけではありませんが、大規模なプロジェクトを計画している場合は、確かに検討する必要があります。

バジェット

このセクションでプロジェクトの予算の概要を説明し、必要に応じて制約をリストします。あなたが投資している金額はプロジェクトの範囲に影響を与えるので、最初から予算を明確にすることが重要です。

プロジェクトのコストが高すぎることが心配な場合でも、開発者に要件を提示する価値はあります。多くの場合、彼らはあなたが考慮していなかったあなたの要件と調和するより手頃な解決策を見つけることができるかもしれません。

場合によっては、プロジェクトを指定された予算内に維持するために妥協が必要になります。開発者は、進行中のプロジェクトコストを節約するのに役立つ、ほぼ違いのないアプローチを考え出すことができる可能性があるため、期待について現実的に考え、開発者が提案する代替ソリューションに心を開いてください。

除外

ビルドチームが知っておくべき除外事項の概要を説明するセクションを含めます。これには、次のようなものが含まれる場合があります。

コンテンツ開発(コピーライティング、コピー編集、ビデオ作成など)
ホスティング料金
要件定義書に概説されているものを超えた、サイトの他の部分との統合
ストック画像、ビジュアル、イラスト、写真の購入
要件定義書で概説されているものを超えるコンテンツエントリ
プロジェクトが上級の利害関係者から承認を受けた後の、サイトの機能の変更、またはワイヤーフレームの修正

※ このセクションにリストされている除外を警告し、それらがプロジェクトの一部として含まれていない理由を説明すると役立つ場合があります。これは、Webビルドのすべてのフェーズが完了した後に必要になる可能性のある追加の作業をアップセルする機会でもあります。

期限とタイムスケール

ここで、プロジェクトの希望する期限とタイムスケールを設定します。 Webプロジェクトは複雑になる可能性があり、関連する作業の範囲に応じて、平均的な作業が完了するまでに6週間から6か月かかるため、ここでは現実的である必要があります。

Webサイトの要件定義書書に希望の期限を設定しますが、開発者と話し合った後、それについて交渉する準備をしてください。多くの場合、プロジェクトに関連するフェーズに応じて、より正確な完了日を提供できるようになり、プロジェクトを前進させるために、サイトの特定の側面を定期的に立ち上げることを決定する場合があります。

ウェブサイト要件定義書とは何ですか？

Webサイト要件定義書には、Webサイトの特性、機能、機能、およびビルドを完了するために必要な手順の概要が記載されています。技術仕様、ワイヤーフレーム、機能設定、および個々の設計要素に関する注記を含める必要があります。

優れたWebサイト要件定義書では、次のことを行う必要があります。

サイトマップ、デザイン、ユーザーエクスペリエンスなど、Webサイトの機能要件を設定します。
サイトが稼働しているときのメンテナンスとサポートの要件。

また、次のようにする必要があります。

具体的で焦点を絞った;新しいサイトに対するあなたの意図は明確でなければなりません。
考慮され、完全であり、見逃したり見落としたりすることはありません。
主要な目的によって優先順位が付けられ、明確な期限とマイルストーンが概説されています。

このガイドは、上記の基準を満たすWebサイト要件定義書を作成するのに役立ちます。

Webサイト要件定義書に含めるもの

コンテンツとサイト構造

ここで、Webサイトの「情報アーキテクチャ」(IA)を特定します。その構造から、サイトマップ全体で使用する予定のコンテンツの種類までです。暫定的なサイト構造は、開発者にサイトから何を見たいかについて明確なビジョンを与えるのに役立ちますが、予算の制約や技術的要件が関係するようになると、後で変更される可能性があります。

サイトマップ

Webサイトのサイトマップを作成することから始めます。これは、Webサイトのページの階層構造を表示する「ツリー」チャートの形式を取ります。典型的なサイトマップがどのように見えるかの例を以下に示します。

効果的なサイトマップを作成する秘訣は、オーディエンスを検討し、現在のサイトの制限と不足を示す定量的データを分析することです。そこから、Webサイトのナビゲーションと構造によって提供されるユーザージャーニーとエクスペリエンスの向上を検討できます。新しいサイトマップに影響を与えるはずの洞察。

タクソノミーの作成

Webサイトの分類構造の概要を示すことは、ユーザーに優れたエクスペリエンスを提供すると同時に、検索結果で最適なパフォーマンスを確保するための優れた方法です。ページの分類システムを作成すると、サイトのナビゲートが容易になるため、ユーザーや検索エンジンにとってより魅力的なものになります。

サイト全体の分類法を作成するときは、次のことを考慮してください。

ユーザーはあなたのウェブサイトに何を望んでいますか？
コンテンツの目的は何ですか？何を達成したいと思っていますか(販売、エンゲージメントなど)？
ユーザーがサイトにアクセスしたときに何を探していますか？これにより、ページがどのように分類されるかがわかります。たとえば、製品またはサービスのページは通常、eコマースWebサイトの情報ページよりも先に分類されます。

Webサイトの分類法の意味の例を次に示します。

レコード店の新しいウェブサイトを構築しているとしましょう。 1つの分類法は、メインの「ジャンル」ページから「ロック」、「フォーク」、「ソウル」などが続く「ジャンル」である可能性があります。これはサイト全体の分類法ではない場合がありますが、サイト上の特定のタイプのコンテンツ(たとえば、情報コンテンツ)のみを参照する場合があります。

サイトの分類法を構築すると、全体的な構造を操作し、構築の初期段階から簡単にナビゲートできるサイトの基盤を確実に確立するのに役立ちます。

ページテンプレートのワイヤーフレームとモックアップ

Webサイトの特定のページをどのように表示するかについて明確なビジョンがありますか？あなたのウェブサイトの要件文書にそれらを含めることを恐れないでください。通常、開発者は、ホームページ、製品/サービスページ、ブログページ、連絡先ページなど、サイトのコンテンツページの種類ごとにテンプレートを作成するため、これらのテンプレートのモックアップの作成に集中することは、あなたが満足しているサイト。

デザイン要素

Webサイト要件定義書のこのセクションに含める情報の量は、サイトのデザイン(特定のスタイル要素を含む)が既にあるかどうか、またはデザイン作業がプロジェクトに組み込まれているかどうかの2つの要因によって異なります。

以下のインタラクティブガイドは、サイトにデザインが存在するか、プロジェクトの一部として必要かによって、開発者と共有する販促素材の種類を決定するのに役立ちます。

デザイン作業が存在する

注釈付きPDF
フラット画像ファイル
Invisionプロジェクトのリンクとメモ
Zeplinプロジェクトのリンクとメモ
Sketchファイル
XD ファイル
PSD ファイル
ブランドのスタイルガイド
ブランドガイドライン

デザイン作業はプロジェクトの一部です

ブランドガイドライン
あなたのブランドのスタイルガイド
他のサイトの例、およびそれらについてあなたが好きなもの
競合サイトの分析
デジタルデザインに情報を与えることができる関連する印刷媒体

機能と技術仕様

これはあなたがあなたのウェブサイトの望ましい機能をリストし、あなたがそれが何をしたいのかを強調するところです。また、ライブInstagramフィードに接続されたインターフェイスなど、サイトに必要なサードパーティの統合について概説する機会でもあります。

機能の観点から、サイトの目的とユーザーがサイトに期待することを理解することが重要です。そのため、オーディエンス調査と顧客のペルソナが非常に重要です。機能要素は、サイト構造内のコンテンツとページのタイプに合わせて調整する必要があり、目的のKPIへのユーザージャーニーを合理化するように調整する必要があります。

Webサイトの要件定義書に記載したい技術仕様の例を次に示します。

EC機能
支払いゲートウェイ、ショッピングカート、「後で使用するために保存」オプション、ストックチェッカー
多言語オプション。ユーザーはさまざまなデフォルト言語を切り替えることができます
ソーシャルメディアの統合
お問い合わせまたは会員登録フォーム
SSL認証
レスポンシブでモバイル対応のバージョンのサイト/すべてのデバイスでの総合的なユーザビリティ

非機能上の考慮事項

サイトの技術要件とは別に、考慮して開発者に伝達する必要のある非機能要素がいくつかあります。サイトのニーズに応じて、このセクションにリストしたいもののいくつかを次に示します。

アクセシビリティ
アクセシビリティはすべてのWebデザインの不可欠な部分であり、WCAGガイドラインは、サイトをすべての人が使用できるようにするのに役立ちます。ただし、サイトに特定のアクセス要件がある場合、または特定のタイプのユーザー(子供や高齢者など)が頻繁に使用する場合は、開発者に通知する必要があります。
安全
サイトは、PCI標準などの特定のセキュリティ法に準拠する必要がありますか？ここで開発者に伝えてください。
法的
サイトに特定のコンプライアンスまたは法的要件がある場合、または顧客が特定の契約条件に同意する必要がある場合は、これらをここにリストする必要があります。この例として、アルコールや18のビデオゲームサイトなどの法定年齢のサイトの生年月日があります。
ページの読み込み速度
ページの読み込み速度が2019年の上位SEOランキング要因の1つであることを考えると、開発者にとってその重要性を強調することが重要です。 /特にeコマースサイトを運営している場合。
ホスティング
あなたはすでにあなたのサイトに座らせたいホスティングプラットフォームを持っていますか？ここにリストしてください。
ブラウザとデバイス
現在の訪問者と顧客はどのブラウザとデバイスを使用していますか？そして、もしあれば、どのプラットフォームをターゲットにしますか？サイトのパフォーマンスを向上させたいブラウザとデバイスを一覧表示すると、開発者はサイトをより効果的にテストおよび改良するのに役立ちます。
メンテナンスとサポート
あなたのウェブサイトは、セキュリティを維持し、最高のパフォーマンスを継続するために、継続的なメンテナンスとサポートを必要としますか？開発者に、必要なメンテナンスと、サイトの技術的側面を維持する上での制限について通知します。