商品モデリングを知る
学習の目的
この単元を完了すると、次のことができるようになります。
- 商品モデルの重要性について説明する。
- 共有カタログのコンポーネントと機能を挙げる。
- 商品モデリングの決定に影響する考慮事項について説明する。
- コマーシャルプロダクトとテクニカルプロダクトを定義する。
- 商品モデリングワークフローのステップをまとめる。
始める前に
このモジュールを開始する前に、「商品デザイナー入門」トレイルの他のバッジを獲得してください。ここでの作業は、そのバッジで学習した概念に基づいて行います。
また、次の推奨コンテンツを受講することも検討してください。
しっかりした計画
Infiwave の商品デザイナーである Devi Jacob を覚えていますか? 彼は会社のコマーシャルプロダクトとサービスのカタログの管理を担当しています。
共有カタログと Product Designer の実務的な知識を習得した彼は、商品の作成を開始しようと張り切っています。ただし最初に、どのように Infiwave の商品カタログを設定して、新しいシステムを最大限に活用するかについて、しっかりした方針を定める必要があります。まず何よりも、データモデルが会社の全般的なビジネス目標に沿ったものであることを確認しなければなりません。さらに彼は自分の商品管理作業をすぐにでも合理化したいと考えています。
商品モデルの重要性
商品モデルとは、商品の特定のバージョンや設定のことです。たとえば、スマートフォンとスマートウォッチのバンドル販売がその例です。階層的な商品モデルは組織がお客様に提供する商品を表し、モデル間の関係が定義されます。商品モデルがシンプルであれば、お客様は提供されるオファーを理解しやすくなります。
商品モデルの計画には、図などの視覚的な表現の作成が含まれます。次の図は商品モデルの例です。1 つのバンドルにさまざまなレイヤーの商品カタログコンポーネントが含まれています。また、重要なのはコンポーネント間のリレーションが示されていることです。
1 つの方法は、この図を手書きでスケッチし、任意の商品モデリングツールを使用してそれを整えることです。ほとんどの商品モデルには、この図のように図の要素と記号を定義する汎用が含まれています。
このモジュールのほとんどの商品モデルや例は通信業界に基づいています。幸い、モデリングのパターンやガイドラインはメディア、エネルギー、公益事業など、他の業界にも適用できます。これらの業界についてはモジュールの中で後ほど取り上げます。
商品モデリングの考慮事項
Devi が Infiwave の商品をモデリングするのに最適な方法は何でしょうか? その方法には、業界とビジネスのコンテキスト、お客様の場所、プロビジョニングのニーズ、ユーザーインターフェースなど、いくつかの要素が影響します。また、商品間の関係も理解する必要があります。たとえば、別個に販売されるのか、一緒に販売されるのかといったことです。
価格設定やお客様の対象資格など、商品の一部の側面は時が経つにつれて変化することがよくあります。そのため Devi は、カタログのアーキテクチャを作成する前に、商品設定を管理するために必要な労力について考慮する必要があります。
商品モデリングの決定は、下流でその商品を参照する注文管理システムやプロビジョニングシステムにも影響します。そのため、カートで商品をどのように表示して販売するかや、どの基盤情報を下流システム向けに保存するかを考慮することが重要です。
このすべての要素を考慮すると、すべてのコンテキストに対応する商品モデルを作成するのは容易なことではありません。そこでソリューションを提供するのが共有カタログです。共有カタログは柔軟性が高いため、会社に最適な商品モデルを構築できます。
商業用カタログと技術的カタログ
Industries 共有カタログを使用すると、コマーシャルプロダクトとテクニカルプロダクトの両方を追跡できるため、全体を把握できます。コマーシャルプロダクトとテクニカルプロダクトの違いは何でしょうか? 例としてレストランを使用しましょう。
コマーシャルプロダクトとは、メニューに載っている食べ物や飲み物とその値段など、お客様が買い物をするときに目にするものです。一方、テクニカルプロダクトはお客様には見えません。レシピ、食品取扱手順、サービスガイドライン、レストランの在庫データベースなどが技術的エンティティの例です。これらは商品のために必要ですが、お客様の目には触れません。
コマーシャルプロダクトはカタログの商業レイヤーを形成し、技術的エンティティは技術レイヤーを形成します。
共有カタログを使用すると、コマーシャルプロダクトの詳細がお客様のカートに表示され、そこには見積、契約、請求など、お客様が参照できるすべてのエンティティが含まれます。カタログには商品オファー、商品仕様、商品バンドルが含まれていて、そのそれぞれに独自の特徴やリレーションがあります。
テクニカルプロダクトは注文履行を実現するための基盤となる商品、サービス、リソースで構成されます。例として、配送、有効化、請求の要件や、コマーシャルプロダクトを使用できるようにするためのハードウェアやソフトウェアなどが挙げられます。前述のとおり、お客様にはこのような品目は表示されず、それを自分で購入することもできません。
商品モデルでは、テクニカルプロダクトをそれがサポートするコマーシャルプロダクトに対応付けます。この対応付けにより、商品注文がさまざまなソリューションに分解されて、お客様が商品を入手できるようになります。
コマーシャルプロダクトとテクニカルプロダクトを分けることには、いくつかのメリットがあります。
- 簡略化: お客様のカートビューで表示される商品情報には、無関係な技術情報は表示されません。
- 再利用性と拡張性: たとえば、共通する 1 つの技術サービスをいくつかのコマーシャルプロダクトに対応付けることができます。
- 柔軟性: 商品の技術的コンポーネントを変更しても、その商品の商業的構造には影響しません。
- システムパフォーマンスの強化: 商品やオファーのエンティティを重複させる必要がなくなります。
商品モデリングワークフロー
共有カタログを使用した商品モデリングの基礎を学んだ Devi は、Infiwave の商品カタログの作成を開始する準備ができています。彼は 3 つのフェーズの手法を使用します。
最初のフェーズは要件収集です。これは基本的には検出です。次に、モデリングパターンを適用して、商品カタログの構造を作成します。最後に、ステークホルダーが彼の商品モデルをレビューして承認します。
各フェーズを詳しく見ていきましょう。
| フェーズ | 説明 |
|---|---|
|
要件収集 |
この検出フェーズでは、ソリューションアーキテクトがステークホルダーから、ビジネス、機能、技術に関するすべての要件を収集します。主な目的は、商品カタログに何が必要であるかを完全に理解し、後のプロセスに影響するようなエラーや見落としを避けることです。 |
|
適用 |
このフェーズではモデリングパターンを定義します。商品デザイナーまたはアーキテクトが、前のフェーズで収集した情報を使用して、すべての必要なデータとプロセスを表すモデリングパターンの図を作成します。このフェーズの主な目標は、会社の構造、商品、関連ワークフローを反映させることです。 |
|
レビューと承認 |
この最後のフェーズでは、ステークホルダーがモデルデザイン全体を機能やパフォーマンスに関する主な要件と照らし合わせて評価し、承認します。1 つのアーキテクチャソリューションで全員を喜ばせるのは難しいことです。結局のところ、最適な手法であっても、すべての貢献者が思い描いていたものだとは限りません。妥協が鍵となります。 |
このプロセスに従うことに加えて、Devi は商品チームと協力して Infiwave のお客様の多くのユースケースを理解する必要があります。そうすることで、お客様が望む内容に合う商品をモデリングできます。初回から完璧な商品モデルはできないかもしれませんが、それでも問題ありません。新しい状況やベストプラクティスが判明すれば、いつでもそれに基づいて戻って調整することができます。
今後の展望
この単元では、商品モデルとは何かということと、商品のモデリングの重要な考慮事項について学習しました。また、コマーシャルプロダクトとテクニカルプロダクトについて知り、共有カタログで商品モデルを作成する手法についても学習しました。
次の単元では、要件収集についてと、商品モデリングを行う際に従うべき基本原則について学習します。