良い質問をする
顧客は尋ねられたことのみに回答するため、コンサルタントは、Dynamics 365 ソリューションを構築する際、部分的な情報に依存する場合が多いものです。 良い質問をすることは、全体像を把握し、ソリューションをより完全なものにするために不可欠です。
顧客は、間違ったり不完全であったりする情報を提供したいわけではありません。 むしろ、顧客から情報を得ようとする際に以下のような課題に直面することがあるかもしれません。
顧客側に詳細な回答を提供する時間がない。
簡単な回答しか得られない。
実際に顧客へのアクセスが限定されている、または許可されない。
受け取った要件や仕様が、本来完全であるべきにもかかわらず、明らかに不完全である。
相反する情報を受け取っている。
ハッピー パスについての話のみを聞かされる。
全員が新入社員であり、プロセスがどう機能するかを知らない。
顧客へのアクセス
プロジェクト チームでのロールやチームが顧客とどのようにやり取りを行うかによって、顧客に直接アクセスできる場合とできない場合があります。 いずれにしても、割り当てられた作業を完了するためには十分な情報が依然として必要です。 質問への回答が得られないからといって、十分な情報を得ないで作業を行うことは、決して許容されません。 顧客に直接アクセスできない場合は、顧客にアクセスでき、あなたの代わりに回答を得ることができる人物のために質問を準備しましょう。 良い質問をし、ソリューションに前向きな改良を加えることは、顧客へのより直接的なアクセスが適切であることを示す優れた方法です。
自由回答式の質問をする
質問に対する回答が短いことに気付くなら、自由回答式の質問をしていない可能性が高いでしょう。 急いでいる、または会話をすることに興味がない人々は、通常、短い回答に留め、役に立つ可能性がある詳細について説明しません。 理想的には、より良い質問して回答を導くことが役立ちます。 たとえば、「期限を過ぎた場合、サポート リクエストはエスカレートされますか」という質問を行ったとします。その質問に対する簡単な回答は「はい」です。「サポート リクエストがエスカレートされた場合のシナリオを理解するのを手伝っていただけますか」は、より良い質問のオプションです。この質問は実質的に詳細な回答を必要とし、より完全な理解へと導くのに役立ちます。
短い回答を受け取った場合は、いつでもフォローアップの質問を追加して取り戻すことができます。 たとえば、「サポート リクエストがエスカレートされた場合はどうなりますか」と尋ねることができます。場合によっては、はい/いいえの回答が役立ちます。 ただし、通常、これらは情報の検出へと導くため、または理解を確認するためのものでしかないのです。 はい/いいえ形式の適切な使い方は、自身の理解を別の言葉で言い換え、確認を求める場合です。たとえば、「サポート案件は期限切れになるかリクエストがあった場合にエスカレートされるという理解は正しいですか」と尋ねることができます。
質問方法の選択
情報を見つけるために質問をする際には、さまざまなアプローチを使用できます。 このアプローチは、得られる回答の品質と有用度に影響を与えることがあります。 次の例では、いくつかのアプローチとそれぞれの利点について説明します。
口頭での対話 - このアプローチは質問と回答のやりとりを可能にするため、有益です。 オンライン会議を通じてこのタイプの対話を行う場合は、レコーディング オプションを使用することでメモを取ることより聴くことに集中できます。 また、このアプローチでは、必要に応じてレビューができます。
デモ - ユーザーに対し、現行のシステムで彼らがプロセスを完了する方法を示すよう依頼します。 このアプローチは、ユーザーがプロセスを実演することで、彼らが話し忘れたことにあなたが気付く場合があるため、役立つことがあります。
メール - メール アプローチでは、顧客が自分の都合に合わせて応答できます。 ただし、このアプローチは先送りの原因となることもあるため、応答を促すためのフォローアップが必要です。 メールでは、質問が後日行われた場合に、どのように意思決定が行われたかの優れた証跡も提供します。
例の提示を求める - このアプローチは、あなたが質問した現行のレポートまたはその他の出力に関するインサイトを得るのに有効です。
既存の要件の使用
Dynamics 365 Field Service を実装をするシナリオについて検討しましょう。 顧客に時間をとってもらったので、質問ができます。 ただし、顧客の応答は、あなたが必要なことはすべてそこに書いてあるはずだと言って、現行のシステムのドキュメントをあなたに送信することでした。 ドキュメントは有用かもしれませんが、すべての質問に対応している可能性は低いでしょう。
一般に、企業は、最新の Dynamics 365 アプリの展開にレガシ システムをレプリケートしたいとは考えません。 既存のシステムのスコープを超える徹底的な質問をすることで、顧客の古いシステムのレプリケートではなく、Dynamics 365 の設定に必要な詳細情報を知ることができます。
競合している情報
顧客のプロセスを知るために質問をする際には、競合する情報を受け取ることへの心構えをする必要があります。 以下は最も一般的な理由の一部です。
さまざまなユーザーが古いシステムを使用する独自の方法を開発し、多くの場合、同じプロセスが異なる方法を使って完了されている。
マネージャーは、自ら毎日作業を行ってはいないので、スタッフがどのようにシステムを使用しているかを十分に理解していないことがある。
ユーザーは、自分たちが使うプロセスをさまざまなレベルで詳細に説明しつつ、重要な手順を省いていることがある。
あなたが説明を理解しなかった可能性がある。
理由にかかわらず、得た情報に競合があることを検出した場合は、何がおこなわれたか、何が行われる必要があるのかを解決するために、明確化のための質問をする必要があります。 場合によっては、得た情報をさらに多くのユーザーに拡大し、さらに多くの視点を理解することが必要となります。 マネージャーと話すことは、行われるべき、または行われる必要があると顧客が考えている内容への視点を獲得するのに役立ちます。
うまくいかないことはなかった
あなたの質問へのすべての回答が「すべてうまくいっている」ことを示す場合は、おそらく全体像を把握できていません。 発生している可能性がある例外や問題、そして現在それらに対処している方法について尋ねるよう、確実に質問を展開してください。 新しい Dynamics 365 アプリの展開のテスト時にこれらの例外が発見されるのを回避するため、新しいプロセスの展開の早い段階でこれらの例外に対処したいものです。
全員が新入社員である
置換する古いレガシ システムが古い場合は、その機能に関するドメインの知識が多くが、他の会社に移っている可能性が高くなります。 情報を得ようとする際に、「私はこの会社に入ったばかりでほんの一部のことしか知りません」と回答ばかりを受け取る場合は、不足している詳細の把握をサポートするリソースを探しましょう。 次の提案は、回答を得るのに役立ちます。
古いシステムのドキュメントやトレーニング 資料を探す。
前任者が、ユーザーに引き継ぐプロセスの方法を説明したドキュメントを提供したかどうかをユーザーに確認する。
詳細をドリルダウンする
質問をする際には、タマネギの皮を剥ぐように、各質問によって別の層とさらなる詳細を明らかにします。 これらの詳細を使用して、次の質問を用意します。 受け取った回答が別の詳細の層を明らかにしない場合は、明らかになるまで別のやり方で質問します。 状況の核心を把握するために徹底的な質問をすることで、すべての側面を十分に理解できます。
スコープまたは期待を拡大する
質問をする場合は、作業中のプロジェクトのスコープに留意してください。 通常、ほとんどのプロジェクトでは無制限の時間と予算があるわけではなく、プロジェクトの成功のためには顧客のスコープ内にとどまる必要があります。 ユーザーに対し、作業のスコープをはるかに超える機能を新システムが備える可能性を示唆する質問を行うと、問題に遭遇する場合があります。 たとえば、「使用中の現行の 5つのアプリのデータ入力を自動化できる可能性があれば、役立ちますか」とユーザーに尋ねるかもしれません。スコープがこのアプローチを含まないことを知りながらの質問は、ユーザーを間違った期待へと導くことになるでしょう。
同様に、現在のスコープを超えることを知りながら、ユーザーの提案したソリューションに応答するシナリオでは、「何ができるか見てみましょう」と言う方が簡単です。ゴールは現在割り当てられているスコープを完了するために情報を得ることであって、スコープを拡大することではない点に注意します。 ただし、顧客との作業が得意であれば、可能性を探ることが焦点となるソリューションの構想作業に参加することもできます。 ソリューションの構想作業は、特定のスコープを持つプロジェクトを進める営業プロセスの一部であることが一般的です。 ビジョンを実現するため、1 つ以上のスコープが設定されたプロジェクトが、構想された状態への進化を担うことになります。
顧客を質問を行う唯一の正しい方法は存在しません。 プロジェクトで実践しながら、自身の手法を進化させます。 Dynamics 365 アプリの適切な展開をサポートするために十分な情報を得られるまで、確実に質問を続けることが重要です。