ソリューションを構築して成果を証明する
学習の目的
この単元を完了すると、次のことができるようになります。
- ソリューションの作成に役立つガイダンスを見つける。
- デモを作成するためのベストプラクティスに従う。
- ストーリーのアウトラインを作成する。
- デモを実施してストーリーを語る。
デモを作成する
ユーザーストーリーを定義し、ビジネスケースを記述したら、いよいよ作成を開始します。これは (Trailhead プロジェクトのように従うべき詳細な手順がない状態で初めて取り組む場合は特に) 手強く感じるかもしれません。うろたえる必要はありません。何を作る場合でも、きっと誰かがすでに同じようなことをしているはずです。Trailhead では多くの Salesforce 設定、カスタマイズ、開発を取り上げているため、まずここから始めてみてください。ソリューションに含まれるスキルをすべて学習し、自信を持って作成し、語れるようにします。デモを作成する前に、2 つの Trailhead モジュール「デモのストーリーテリング」と「デモ実践の基本」を確認してください。
行き詰まったり、インスピレーションが必要になったりしたら、役に立つ優れたリソースが豊富に用意されています。Trailblazer Community のアンサーサイト、開発者フォーラム、Salesforce Stack Exchange にアクセスしてみてください。Dreamforce や TrailheaDX のイベントのセッション録画も、標準機能の拡張やカスタムアプリケーションの作成を行う場合の優れたリソースです。その方法に驚くかもしれません! こうしたリソースには「リソース」セクションのリンクからアクセスしてください。
アプリケーションは、Trailhead Playground ではなく Salesforce Developer Edition で作成することをお勧めします。この 2 つの組織にそれほど違いはありません。どちらも無料で幅広いライセンスがあり、さまざまな機能を試すことができます。多くのモジュールやプロジェクトで作業を行うために設定を変更する必要があるため、Trailhead Playground にはデモに使用しない設定やカスタマイズが含まれていることがあります。そのため、無料の Developer Edition にサインアップしてください。Trailhead Playground とは異なり、Developer Edition にはサンプルデータは含まれていません。
アプリケーションを作成したら、将来の雇用主に見せるためのデモを作成します。特定の会社にプレゼンテーションする機会がある場合は、まず Web サイトでそのビジネスを調査します。少し時間を取ってデモの目的について考えると、後で作業のし直しになるのを防ぐことができます。まず理解しておくべきことは、デモは 1 つとは限らないということです。デモを実施する会社に応じて複数のバージョンが必要になることがあります。Trailhead で身に付けたスキルと経験を応募する職務にどう適用するかを聴衆に示します。
見てほしい主要な項目のリストを作成します。自然なフローを作成し、アプリケーション内であちこちに飛ぶのを避けるには、主要な項目を機能領域別またはロール別にグループ化します。たとえば、社員募集アプリケーションの場合、採用担当マネージャーの観点と応募者の観点から 2 つのデモを作成します。
ストーリーのアウトラインを作成する
デモを実施するときには、ストーリーを伝える必要があります。ストーリーによって、聴衆は冒険のようにデモの中を進むことができます! どのストーリーも 3 部構成にする必要があります。
- 始まり: デモで取り上げる内容を明らかにし、期待事項を設定します。たとえば、質問で中断してもよいか、質問はデモの最後にまとめて受けるか、などです。扱う領域に関する議題を提示し、聴衆にデモの予定所要時間を伝えます。
- 中間: ビジネスが直面している問題を明らかにし、アプリケーションでどう解決するかを示します。デモのほとんどはここで行う必要があります。
- 終わり: 主要なポイントを要約し、聴衆にデモから覚えて欲しい重要な情報を強調します。特に、アプリケーションで具体的な問題がどのように解決されるかを強調し、ソリューションで節約できる時間とコストに言及します。
予定時間内に余裕を持って話せる内容に抑えます。急いだり、内容を盛り込みすぎたりすると、聴衆が混乱するおそれがあります。機能を素っ気なく挙げるのではなく、具体的なロールを使用してビジネスコンテキストの中で機能を説明します。たとえば、デモのナレーションをするときには、
「このメニューを開き、このボタンをクリックして応募者を受け入れるか、不採用にします。」
とは言わずに、
「採用担当マネージャーとして、私は沢山の応募者を審査して選ばなければなりません。審査後、私の決定を入力すると、システムで該当する連絡事項が各応募者に送信されます。」と話します。
デモで会社の具体的なロール (営業担当、マネージャー、サポートエージェントなど) が通常の業務内でアプリケーションをどう使用するかを示すと、より強い共感を得られます。
ストーリーを伝えるときには細部に立ち入らないようにします。聴衆の好奇心をかき立てるだけの情報を提供しつつ、質問が出る余地も残します。質問に詳細な回答をするのは、詳細が求められていることがわかっている場合だけです。
練習あるのみ
デモを作成したら練習します。さまざまな人々に対して実施し、正直なフィードバックを求めます。デモを録画して視聴します。問題のある領域を特定し、デモの内容と実施方法を改善します。
プレゼンテーションを作成する
プレゼンテーションはデモを補足する必要がありますが、聴衆がスライドではなくあなたに集中できるようにします。聴衆はあなたの話を聞いたり、記述した内容を読んだりできますが、同時に両方はできないため、表示内容はできるだけ簡潔にします。便利なガイドラインは「一段落分の話に対して箇条書き 1 つ」です。
言葉よりも画像を使用します。視覚の優位性効果により、スライドの画像は言葉よりも記憶に残ります。聴衆が集中して理解しなければならない複雑な画像よりも単純な絵を使用します。
スライドには一貫性を持たせます。
- 特定の用途のフォントとフォントサイズを決め (見出しテキストはすべて Arial 16 ポイント、など)、一貫して使用します。
- カラーテーマを選択し、互いに補完し合う色を使用します。
- 一体感のある画像を使用します。
反対に、テーマ内でさまざまなレイアウトを使用します。すべてのスライドが同じように見えると、聴衆がプレゼンテーションへの興味を失うおそれがあります。
移行スライドを使用して各トピックまたは機能領域の終わりを示します。移行スライドがあると、聴衆はあなたと一緒に次に進むことができます。
最後に、スライドプレゼンテーションが完成したと思ったら、もう一度目を通して、デモに不可欠なもの以外はすべて削除します。判断がつかない場合は、残しておきます。
これで、スキルを将来の雇用主に示す準備ができました。次の単元では、よい印象を与える方法を学習します。
