B2C Commerce プロジェクト管理の理解

学習の目的

この単元を完了すると、次のことができるようになります。

B2C Commerce 実装プロジェクトのフェーズについて説明する。
B2C Commerce 実装プロジェクトにおけるパートナー側のプロジェクトマネージャーの責任を特定する。
B2C Commerce プロジェクトチームの主な機能的役割と責任について説明する。

はじめに

重大ニュースが飛び込んできました。Northern Trail Outfitters (NTO) の e コマースサイトの開設をあなたの会社が落札し、あなたがパートナー側のプロジェクトマネージャーになりました。またとないチャンスに胸が高鳴りますが、当然のことながら若干の不安も湧いてきます。十分なスキルを備えているとはいえ、あなたにとって B2C Commerce プロジェクトを実装するのはこれが初めてで、顧客に気に入られるサイトを開設したいと意気込みます。

B2C Commerce は、世界各地の小売業で大きな役割を果たしています。そして、B2C Commerce プロジェクトを成功させるためには、あなたが大きな役割を果たします。あなたにプロジェクト管理の経験があることは大きなアドバンテージですが、B2C Commerce プロジェクトには独自の特徴があります。このモジュールでは、B2C Commerce を使用したプロジェクト管理を検討し、若干異なるやり方によってプロジェクトが管理しやすくなる理由を見ていきます。

このモジュールでは、プロジェクトに関する B2C Commerce 独自の概念を説明するため、あなたが何をすべきかがわかります。また、よくある落とし穴も指摘するため、あなたが何をすべきでないかも習得できます。「コンサルティングパートナーの Salesforce B2C Commerce」バッジをまだ獲得していない場合は、まずこのモジュールを受講してください。上記のモジュールには、あなたがすでに認識しているものと想定するいくつかの概念が説明されています。

このモジュールでは、B2C Commerce プロジェクトを 8 つのフェーズに分割します。あなたが各フェーズに独自の名前を付けていたり、若干異なる方法で分類していることがあるかもしれませんが、どのプロジェクトも次の一般的なフェーズと大まかなタスクで構成されます。

ディスカバリー: チームを編成し、プロジェクトの範囲を定める。
計画: 作業明細書をまとめ、プロジェクト計画を作成する。
設計: ワイヤーフレームやビジュアルデザインを作成してレビューする。
要件の記録: サイトのカスタマイズや、システムとサードパーティの統合を記録する。
構築: サイトのコーディングと構成を行う。
テスト: テスト計画を作成して実行する。
立ち上げ: ライブサイトを立ち上げる。
立ち上げ後: サポートや最適化を担当するメンテナンスチームにサイトを引き継ぐ。

プロジェクトのフェーズは線形であるとは限りません。特にスプリントで作業する場合は、フェーズが重複したり反復したりすることがあります。このモジュールで学んだ内容は、どの開発手法にも適用できます。

プロジェクトの目標と範囲のディスカバリー

成功するプロジェクトはどれもディスカバリーフェーズから始まります。このフェーズは、顧客のビジネス目標を明確にし、プロジェクトの範囲を定める段階です。パートナー側のプロジェクトマネージャー (PM) であるあなたは、B2C Commerce プロジェクトという列車の車掌で、プロジェクトの範囲の定義、プロジェクト計画の作成、そして計画の実行の最終的な責任を担います。けれども、どのような PM もこのすべてを 1 人で行うことはできません。B2C Commerce 特急の快適な進行の第一歩は、チームを編成することです。

チームの招集

出発時刻が近づいています。ドアを開け、B2C Commerce のスペシャリストを迎え入れます。最初に乗り込んだのは、ファンクショナルアーキテクトの Mindy です。Mindy は顧客と協力して、要件や機能仕様を定義します。Mindy の切符を見て、e コマースの経験があり、B2C Commerce を熟知していることを確認します。B2C Commerce のファンクショナルアーキテクトのロールについて学習するには、「Salesforce B2C Commerce 機能コンサルティング」トレイルを受講してください。次に乗車したのはテクニカルソリューションデザイナーの Alex で、彼はソリューションを計画します。その切符に「Salesforce 認定 B2C Commerce テクニカルソリューションデザイナー」試験に合格していることが示されていれば言うことありません。

この 2 つのロールは、社内のリソースの中から適任者を見つけてもよいですし、Salesforce B2C Commerce プロフェッショナルサービスチームのメンバーとプロジェクト単位の契約を結ぶこともできます。質の高い実装を行い、カスタマーサクセスを実現できるように、プロフェッショナルサービスチームの信頼できるエキスパートがパートナーをサポートします。

あなたもよく知っている他のロールは、デベロッパーとユーザーエクスペリエンス (UX) デザイナーです。認定 B2C Commerce デベロッパーを選びます。認定デベロッパーは、開発環境の設定、データモデルの操作、その他の不可欠なタスクのノウハウを備えています。「SiteGenesis の設計」コースに合格しているデザイナーを採用します。こうしたデザイナーは、Commerce Cloud Storefront Reference Architecture (SFRA) をカスタマイズして、独自の B2C Commerce ストアフロントを作成する方法を心得ています。参照アーキテクチャは、オンラインストアフロントの設計の出発点です。

ここで車内に揃ったロールを確認しましょう。

経験豊富なプロジェクトマネージャー
e コマースの経験を有するファンクショナルアーキテクト
B2C Commerce 認定テクニカルソリューションデザイナー
B2C Commerce 認定デベロッパー
B2C Commerce UX デザイナー

場合によっては、あなたまたは顧客が、ストアフロント設計のビジュアルデザインに特化した別の Salesforce パートナーを雇うことがあります。その場合は、そのパートナーの設計チームが SiteGenesis のコースを受講し、必要なリソースを利用できることを確認します。顧客側のデベロッパーと仕事をする場合は、社内のデベロッパーと同じ認証資格があることを確認します。外部のリソースが参加する場合は、各リソースを調整するためにプロジェクト管理にやや時間がかかります。特に初めて共同作業をする場合は、この点を考慮して、プロジェクト計画に多めの時間を確保します。

プロジェクトの後半で、テストチームも編成します (この点は単元 6 で詳述します)。テストでは顧客のリソース、チームメンバー、サードパーティのテスターを手配します。この時点で NTO やサードパーティ側のプロジェクトマネージャーと、テストフェーズや、提供してもらうリソースの人数について打ち合わせておきます。

テストチームは通常、次のメンバーで構成されます。

プロジェクトマネージャー (顧客側)
マーチャンダイザー (顧客側)
テクニカルリソース 1 人以上 (顧客側)
パートナー側とサードパーティ側の QA チーム
テストを管理するリソース (PM であるあなたが兼任可)

列車が動き出したところで、チームに関連資料に目を通してもらいます。B2C Commerce 製品ドキュメントを確認しておいてもらいましょう。これは B2C Commerce のデジタルライブラリで、ワイヤーフレーム、機能仕様、リリースノート、その他の関連リソースが掲載されています。また、Salesforce パートナーコミュニティサイトの [Education (教育)] タブで有益なトレーニングリソースもチェックしてもらいます。

プロジェクトの範囲の特定

適切なチームを組んだら、次は顧客と会って、このプロジェクトで何を追求するのかを見極めます。列車を停めて Mindy を呼び、顧客である Northern Trail Outfitters と打ち合わせるために一緒に下車します。

B2C Commerce には何百種もの機能が標準搭載されていますが、大半のクライアントは何らかの機能、あるいはすべての機能のカスタマイズを希望します。NTO もその例外ではありません。NTO の会議室に足を踏み入れるとすぐ、希望する機能がホワイトボード一杯に羅列されていることに気が付きます。

あなたの最初のタスクは、希望する機能のどれが標準搭載され、どれがカスタムかを選り分けていくことです。カスタマイズを調べて範囲を定める一番の方法は、概要ディスカバリー (HLD) プロセスを実施することです。「コンサルティングパートナーの Salesforce B2C Commerce」モジュールに出てきたこの用語を覚えているでしょう。HLD 時に、顧客がその目標を明らかにします。ファンクショナルアーキテクトの Mindy は、顧客が目標を絞り込み、その目標を機能要件に変換できるようサポートします。

Mindy は HLD ドキュメントのサンプルを持って来ています。ここに、B2C Commerce に標準搭載されている機能が説明されています。NTO は標準機能セットに含まれていない機能も求めています。Mindy が NTO のカスタム要件を HLD ドキュメントに書き込みます。これでどれが標準機能で、どれがカスタム機能なのかが明らかになります。また、どの部分に相当の労力やリソースを投入する必要があるかを NTO が理解しやすくなります。

どれほどの労力やリソースを要するかを認識することなく、顧客が機能を求めることも珍しくありません。たとえば、NTO はオンライン購入後の店舗受け取りをカスタマイズしたいと考えています。けれども、このカスタマイズにコストのかかる統合作業を伴うことを認識していません。そこで Mindy は「できること」と「すべきこと」について話し合い、クライアントを誘導していきます。NTO が運営上、店舗のプロセスとオンラインのプロセスを統合できる段階にあるかどうかを見極めるために、相手に検討を促す質問をします。その結果、そうした準備がまだ整っていないことがわかりました。両者は、この統合は今後のリリースで取り組んだほうがよいという結論に至ります。

あなたと Mindy は検討後の機能リストを手に電車に戻り、その内容を見直します。車内で Mindy と Alex がカスタマイズのリストに目を通します。ソリューション設計を担当する Alex が、カスタマーレビューのサポートを NTO が望んでいることに気が付きました。自身の経験から、この機能は外注したほうが時間の節約になり、開発コストも削減されることがわかっています。そこで、Salesforce B2C Commerce パートナーマーケットプレースでサードパーティのソリューションを探します。このマーケットプレースは、Salesforce のテクノロジーパートナーが B2C Commerce に統合可能な製品や互換性のある製品を提供する場所です。NTO が求める機能をすべて備えたソリューションを Alex が見つけます。費用便益分析から、マーケットプレースのソリューションが適切なチョイスであることがわかりました。

当初の範囲が確定しました。次は、サイトの開設を成功させる方法を計画します。

ディスカバリーの成果物

HLD ドキュメント