プロジェクトマネージャ 2024年 午後1 問01

解答の導き方

1. この設問は、なぜ要件定義のヒアリング対象者を、付加サービスを利用したことがある無償ユーザーではなく、利用したことがない無償ユーザーから選んだのかを問うています。対象者の利用経験の違いが、ヒアリングで得られる意見にどう影響するかを考えます。
2. 本文では、簡単サービスについて「これまで付加サービスの固定観念にとらわれない新たな期待やニーズを多面的に把握」するとしています。つまり、既存の付加サービスを前提にせず、新たに提供するサービスに対する利用者の期待やニーズを把握することが狙いです。
3. 付加サービスを利用したことがある人は、その操作方法や提供内容に慣れており、意見も既存サービスの使い方や評価に引きずられる可能性があります。一方、利用したことがない人から意見を聞けば、付加サービスの経験を前提としない、新たな視点のニーズを把握しやすくなります。
4. さらに、ヒアリングでは操作性や視認性だけでなく、入力情報項目の量、お勧め情報項目、利用時間に関するニーズも確認します。利用経験のない人からも幅広く意見を得ることで、簡単サービスに必要な要件を多面的に捉えられます。

誤りやすいポイント

• 「付加サービスをやめた人の不満を詳しく聞くため」と考えることです。この設問では、付加サービスの利用経験がない人を選ぶことで、既存サービスの考え方にとらわれないニーズを把握する点が重要です。
• 「Webサービスに慣れていない人を選ぶため」とだけ答えることです。それは対象者の条件の一つですが、今回問われているのは、付加サービスを利用したことがない人を選ぶ狙いです。
• 「簡単サービスの操作性を確認するため」と答えることです。操作性などの確認もヒアリングの内容ですが、利用経験のない人を対象にする理由とは区別して考える必要があります。

FAQ

解答の導き方

1. aに入るのは、（i）の「Webサービスを使い慣れていない利用者」とは別の条件です。したがって、（i）の言い換えではなく、簡単サービスで実現するUXに関係する、もう一つの利用者像を考えます。
2. 本文の分析では、「希望に合ったレストランを簡単に探したい利用者」には付加サービスのUXが適合しないとされています。一方、新たに定義されたUXは「複雑な操作をせずに、希望するレストランがお勧めされ、すぐに予約できる。」というものです。
3. つまり、ヒアリング対象者には、Webサービスに不慣れな人だけでなく、自分の希望に合うレストランを簡単に見つけたい人も含める必要があります。したがって、aには「希望に合ったレストランを簡単に探したい利用者」が入ります。

誤りやすいポイント

• （i）の「Webサービスを使い慣れていない利用者」を、aにも重ねて書かないようにします。aは二つ目の条件です。
• 「レストランを探したい利用者」だけでは、希望との合致や簡単に探したいというニーズが表れません。
• 「良いレストランを探したい利用者」と一般化せず、本文にある「希望に合ったレストランを簡単に探したい」というニーズに沿って答えます。

FAQ

解答の導き方

誤りやすいポイント

• システムの応答時間だけを答えないようにします。設問は、利用者がサービスの利用場面で意識する時間について尋ねています。
• レストランを探す時間だけに限定しないようにします。本文では、検索から予約までの合計の時間が使いにくさの理由として挙げられています。
• 予約操作にかかる時間だけに限定しないようにします。検索から予約までの一連の流れを捉える必要があります。

FAQ

解答の導き方

1. 設計段階では、簡易な画面のモックアップを使い、操作性や視認性、表示項目がUXに適合するかを確認します。ここでは、画面の見た目や操作のイメージを中心に検証できます。
2. 一方、結合テストでは「本番稼働環境に近い環境」で複数の機能を連携させて確認します。また、「本番データに近い疑似的なレストランの予約データ」を使います。つまり、設計段階のモックアップだけでは確認しにくい、実際の機能が連携した状態での操作性や視認性を評価できます。
3. 画面の使いやすさや情報の見やすさは、実際の機能やデータを使ったときに、モックアップでの印象と異なる可能性があります。そのため、設計段階だけでなく、本番に近い環境とデータで改めて検証する必要があります。

誤りやすいポイント

• 「UXの品質を高めるため」のように、目的だけを述べて具体的な理由を示さないこと。
• 結合テストの目的を、機能間の連携確認だけに限定すること。この設問では、利用者が操作性・視認性を検証する理由を問われています。
• 設計段階のモックアップで確認できることと、結合テストで確認できることを同じだと考えること。本番に近い環境やデータを使う点が、結合テストで検証する理由になります。

FAQ

解答の導き方

1. まず、付加サービスの利用をやめた無償ユーザーが、なぜ利用をやめたのかを確認します。インタビューでは「対価に見合うサービスではなかった」という意見が多くありました。つまり、この利用者層が感じていた問題は、有償サービスの価値が支払う対価に見合っていないことです。
2. P社は、この利用者層にも再び有償サービスを利用してもらうため、付加サービスとは異なるUXを提供する簡単サービスを計画しています。そのため、新しいサービスのUXが対価に見合う価値になるかどうかを確かめる必要があります。
3. 結合テストでは、要件定義段階のヒアリング対象者に、操作性・視認性を含む実装内容がUXに適合するかを検証してもらいます。それに加えて、付加サービスの利用をやめた無償ユーザーにも参加してもらいます。過去に有償サービスを対価に見合わないと感じた人の視点から、新しいUXが支払う対価に見合うかを確かめるためです。

誤りやすいポイント

• 操作性・視認性がUXに適合するかという検証と、UXが対価に見合う価値かという検証を混同しないようにします。前者は要件定義段階のヒアリング対象者に確認してもらう内容として示されています。
• 結合テストでの機能連携や設計どおりの動作だけに注目すると、追加で参加する無償ユーザーに何を検証してもらうのかを見落とします。
• 問われているのは、サービスの料金を変更すべきかどうかではありません。新たに提供するUXが、支払う対価に見合う価値かどうかです。

FAQ

解答の導き方

1. 設問が問うているのは、無償ユーザーにテストで確認してもらう内容ではなく、総合テストに参加してもらう事業上の狙いです。したがって、テストでの検証目的と、事業として目指す成果を分けて考えます。
2. 総合テストの参加者には、「簡単サービスのUXに関心がある無償ユーザー」も含まれます。簡単サービスに関心がある無償ユーザーは、今後、有償サービスである簡単サービスを利用する可能性がある層です。
3. さらに、本文では簡単サービスについて、「より多くの簡単サービスの利用者（以下、廉価ユーザーという）の獲得を目指す」としています。つまり、この層にも参加してもらう事業上の狙いは、簡単サービスの利用者を増やすことです。

誤りやすいポイント

• 総合テストで行う「UXが対価に見合う価値であるかどうかの検証」を、事業上の狙いとして答えてしまうことです。これはテストの目的であり、設問が問う事業上の狙いとは異なります。
• 「UXに対するニーズなどの追加提示」を答えることです。これも総合テストで参加者にしてもらう内容であり、参加者を募る事業上の狙いではありません。
• 無償ユーザーが参加する理由を、既存のロイヤルユーザーの維持と捉えることです。簡単サービスは、より多くの利用者を新たに獲得するためのサービスです。

FAQ

解答の導き方

1. 設問は、総合テストでも利用者にニーズなどを追加提示してもらう理由を尋ねています。まず、ニーズを複数回確認する必要があるかを考えます。
2. 検討方針には、廉価ユーザーは「新たな利用者層」であり、期待やニーズを「一挙には把握できない」とあります。そのため、要件定義段階で確認しただけでは十分とは限らず、後の段階でもニーズを把握する必要があります。総合テストでの追加提示は、このように複数回にわたってニーズを把握するためです。
3. 次に、追加されたニーズをその後どう扱うかを確認します。総合テストでは、提示されたニーズなどを精査して改修し、「UXの品質が一定のレベル以上になったことを確認」してから本番稼働させます。つまり、追加のニーズを確認することは、UXを改善し、本番稼働に必要な品質に達しているかを確かめることにもつながります。

誤りやすいポイント

• ニーズの追加提示を求める理由を、単に「利用者の意見を聞くため」とだけ捉えないようにします。新たな利用者層の期待やニーズを一度で把握できないため、複数回確認するという方針が根拠です。
• ニーズを追加で集めることだけを理由にせず、その後の精査・改修を経て、一定以上のUX品質を確認してから本番稼働させる点も押さえます。
• 提示されたニーズをすべて採用するという意味ではありません。本文では、ニーズを精査した上で改修するとしています。

FAQ