ドキュメント要件とストアフロントの構築
学習の目的
この単元を完了すると、次のことができるようになります。
- 機能仕様ドキュメントの重要性を説明する。
- 機能仕様ドキュメントの内容を説明する。
- 範囲のギャップ分析の重要性を理解する。
要件のドキュメントへの記録
チームは旅を続けながら、さまざまな重要なタスクを完成させてきました。ここからはさらに奥深い領域に入っていきます。次の停車駅は要件村です。ここは一風変わった場所で、あらゆるものに ID と、どのように機能するかの説明が付けられています。あなたのチームも、要件をドキュメントに記録しないとという気持ちに駆られます。
機能設計仕様
機能仕様ドキュメント (FSD) は、「このサイトは何を行うのか?」という質問に答えるものです。サイトの動作をユーザーの視点で説明します。NTO のストアフロントはかなり大きなサイトです。このすべての動作を説明するとなると、かなりの作業になります。幸いなことに、この作業の一部はすでに完了しています。標準機能用のワイヤーフレームは SFRA にあらかじめ存在するため、チームがカスタマイズ用の設計ワイヤーフレームのみを作成したことを覚えていますか? FSD についても同じような下準備がなされています。チームが記述するのは、SFRA にまだ存在しない動作の機能仕様のみです。このため時間が大幅に節約されます。
ファンクショナルアーキテクトの Mindy の指示に従って、チームがすべてのカスタム機能の仕様を記述します。Mindy はまた、NTO サイトで SFRA の機能が意図的に除外される場所も記録するよう指示します。チームの作業をのぞきに来たあなたは、チームが Mindy にもラベルを付けているのを見て笑ってしまいます。どのような説明だったのでしょうか? それは機能仕様を見てのお楽しみです。
技術設計仕様
技術仕様ドキュメント (TSD) は FSD の姉妹品で、「このサイトはそのことをどのように行うのか?」という質問に答えます。FSD に説明されている機能の構築方法に関する綿密な技術的詳細が記載されています。TSD は極めて有用なドキュメントです。開発チームは TSD を使用してストアフロントを構築します。テクニカルサポートチームは TSD を使用してストアフロントの実装の詳細を理解します。
TSD に掲載すべき情報は電車の車両が埋まるほどたくさんあります。経験豊富なプロジェクトマネージャーであるあなたは、TSD に記載すべき内容の大半をすでに認識しています。以下に、B2C Commerce の実装で見逃したり軽視したりすることの多い領域について説明します。
データマッピング
NTO は、巨大な商品カタログを専有データベースに格納しています。このデータを、B2C Commerce で実行される Web サイトが認識するデータモデルに変換するための計画が必要です。
あるデベロッパーはデータベースの達人です。テクニカルソリューションデザイナーの Alex がこのデベロッパーに、NTO のデータを保存するフィールドとして使用する SFRA の定義済みデータフィールドのリストを渡します。デベロッパーは、NTO のデータのフィールド、タイプ、値を SFRA のフィールドとどのようにマッピングするのかを記録したデータマッピング計画を完成させます。
次の重要なデータの全ファイルにマッピングを繰り返し実行します。
- カタログ
- 価格表
- 在庫
- 注文のエクスポート
顧客のデータを SFRA のデータモデルにマッピングしながら、デベロッパーは SFRA の保存先に整然とマッピングされないフィールドに注意を払います。また、通常とは異なるデータ要件をすべて記録します。Alex はデータマップを確認して、潜在的な影響を特定し、データ処理の特殊な要件を TSD に記録します。
システム統合
システム統合計画には、各種の外部システムが NTO の新しいサイトといつ、どのようにやりとりするのかがまとめられます。B2C Commerce の平均的なサイト実装では、4 種のサードパーティ統合が行われます。Alex は TSD の多大なスペースを割いて、システム統合について綿密に説明します。
検索エンジン最適化と分析
検索エンジン最適化 (SEO) はそれ自体が一種の芸術です。顧客が SEO に特化した他の Salesforce パートナーとコラボレーションしていることは多く、NTO も例外ではありません。NTO の SEO パートナーと連携して SEO の仕様を入手することはあなたの責任です。
プロジェクトで既存のサイトの移行を行う場合は、301 リダイレクトを使用してユーザーと検索エンジンの両方を新しい URL に送信する仕様を追加します。リダイレクトの決定方法と完了方法を指定します。
B2C Commerce には Web 分析のサポートが付属しますが、大半の顧客は別のシステムも使用しています。NTO がどのシステムを採用するのかを確認し、TSD にリストします。
負荷テスト SOW
Salesforce は負荷テストのサードパーティと提携しています。負荷テストを実施するには、あなたか顧客のどちらかに SOW またはサードパーティとの契約が必要です。このプロジェクトでは、NTO が直接サードパーティと契約します。あなたが NTO のプロジェクトマネージャーにサードパーティを紹介し、負荷テストの詳細を選定できるようにします。
アクセシビリティ
W3C の「Web コンテンツのアクセシビリティに関するガイドライン」 (WCAG) には、障害のある人々が Web コンテンツにアクセスしやすくする方法が説明されています。WCAG は技術標準です。一部の国では、WCAG への適合が義務付けられています。Mindy は国が定めた適合要件をチェックし、NTO のサイトにはどれが適用されるかを調べます。そして、サイト設計がその国固有の要件を満たしているかそれ以上であることを確認します。
範囲のギャップ分析
この時点で、チームは細かな要件をくまなく調べ、そのすべての説明を FSD と TSD に記録しました。ここでもう一度、範囲がなし崩し的に変容していることがないか確認することをお勧めします。SOW と HLD をレビューします。この 2 つのドキュメントを作成後に変更された点はありませんか? 変更されていれば、それが範囲のギャップになります。変更注文を作成し、それに応じてプロジェクト計画を更新します。
SRA 仕様のレビュー
SRA 仕様のレビューも NTO プロジェクトの一環です。プロジェクトの仕様ドキュメントやサイト設計のレビューには、Salesforce B2C Commerce プロフェッショナルサービスチームが協力します。要件フェーズで、仕様レビューのマイルストーンに合格する必要があります。そして、レビュー時に明らかになった問題をチームで解決しなければなりません。あなたはプロジェクト計画に、チーム全体でレビューの準備をして、問題を解決するための時間をあらかじめ確保していました。そのため、レビューのマイルストーンに順調に合格します。
チームがストアフロントを構築する前に、FSD と TSD ドキュメントに日付とバージョン番号のスタンプを適用します。どれが正式な要件であるのか混乱することがないように、要件と変更注文に対するサインオフを NTO から取り付けます。反復的なやり方で開発している場合は、サインオフも反復的に取り付けます。同時に、テストデータと本番データを準備しておくよう NTO に伝えます。構築、テスト、立ち上げ時に使用するサンプルの商品データと本番対応データを提供することは NTO の責任です。要件に対する説明責任を 1 つ残らずすべて果たしてレビューします。次はいよいよ構築です! チームが列車に戻って、開発に取りかかります。
ストアフロントの構築
開発チームがストアフロントの構築に着手すると、さまざまな情報が飛び交い騒がしくなります。パートナーごとに、ウォーターフォール型、アジャイル型、ハイブリッド型など独自の実装手法があります。Salesforce では、ウォーターフォール型とアジャイル型の両方の手法の要素を取り入れた適応型アプローチを愛用しています。B2C Commerce プロジェクトの場合、適応型スプリントの期間は通常 2 ～ 3 週間です。実用的なソフトウェアを迅速に制作し、成果物を予定どおり提供するために、この手法を採用することをお勧めします。特定の開発手法に頼ることなく、独自のコードリポジトリの管理と開発のベストプラクティスを実践します。
要件と構築の成果物
- FSD
- TSD
- SFRA の注釈付きワイヤーフレーム
- データマップ
- 更新済みのプロジェクト計画
- サンプルの商品データ (顧客側が用意)
- 本番対応のデータ (顧客側が用意)
- テスト計画
- 負荷テスト SOW
リソース
- 外部: Q3C Web Content Accessibility Guidelines (Q3C Web コンテンツのアクセシビリティに関するガイドライン)
- 外部: アジャイルソフトウェア開発宣言
- Trailhead: Salesforce B2C Commerce クライアント分析
- Trailhead: Salesforce B2C Commerce ファンクショナルアーキテクト用のプロジェクトドキュメント