令和6年度 秋期 プロジェクトマネージャ試験 午後 I 問題 問1 UX品質を確保する利用者参加型プロジェクト計画

問1 顧客体験価値（以下，UXという）を提供するシステム開発プロジェクトに関する次の記述を読んで，設問に答えよ。

P社はレストラン予約のサービス事業を展開しており，サービスを提供するシステムは自社で開発している。サービスの利用者には無償の基本サービスと有償の付加サービスを提供している。付加サービスでは，様々な条件で検索できたり，口コミの投稿・閲覧ができたり，特別メニューを選択できたりする。これまで提供情報の種別・量や検索手段を増やすことで，付加サービスの利用者（以下，ロイヤルユーザーという）を開拓してきた。しかし近年，付加サービスの利用をやめて，ロイヤルユーザーから基本サービスの利用者（以下，無償ユーザーという）に戻る利用者が増えてきた。P社の経営層はこの事態に危機感を抱き，早急に対策をとるために，営業部門のQ課長とIT部門のR課長に状況の分析を指示した。

〔状況の分析と対策〕

Q課長とR課長はサービスの利用者にインタビューした。付加サービスの利用をやめた無償ユーザーへのインタビューでは，“自分には付加サービスは対価に見合うサービスではなかった。例えば，Webサービスに慣れていないので，様々なボタンを押したり，いろいろな情報を入力したりすることができず，希望するレストランが見つけられなかった。また，検索から予約までの合計の時間が掛かるので使いにくかった。レストランを探す際に口コミを見てもどこが良いか分からないし，また，口コミを自分では投稿しない。自分に限らず，多少のお金を支払ってでも良いレストランを探したい人は多いので，対価に見合うサービスを提供してほしい。”といった意見が多かった。一方，ロイヤルユーザーへのインタビューでは，時間を掛けてレストランを探したり，口コミの投稿・閲覧をしたり，特別メニューを利用したりする体験が高く評価されていた。

Q課長とR課長は収集したインタビュー結果などから，次のような分析をした。

• Webサービスを使い慣れていない利用者と，希望に合ったレストランを簡単に探したい利用者には，付加サービスのUXは適合しない。
• 付加サービスの利用後にUXが対価に見合わないと感じて利用をやめる利用者が増加した。このような利用者に再度有償のサービスを利用してもらうためには，付加サービスとは異なる新たなUXを提供し，そのUXに対価に見合う価値にする必要がある。
• 有償のサービスでは，UXに対価に見合う価値にすることが重要なので，有償のサービスを提供するシステムはUXを明確に定義して開発する必要がある。
• 無償ユーザーのうち，付加サービスのUXに関心がない利用者も，有償のサービスで対価に見合うUXが提供される場合は，有償のサービスを新規に利用する可能性が高い。

この分析に基づき，P社の経営層は事業拡大のために“複雑な操作をせずに，希望するレストランがお勧めされ，すぐに予約できる。”というUXを定義した。そして，このUXを提供する新たな有償のサービス（以下，簡単サービスという）を開始することで，より多くの簡単サービスの利用者（以下，廉価ユーザーという）の獲得を目指すことを決定した。P社は簡単サービスを提供するシステムを開発するプロジェクトを立ち上げ，R課長がプロジェクトマネージャ（PM）に任命された。

〔UX実現の検討方針〕

R課長は簡単サービスで十分な品質のUXを提供することが重要であると考え，次のUX実現の検討方針でプロジェクト計画を作成することにした。

• 様々な利用者が対価に見合う価値であると感じるUXを実現し，より多くの廉価ユーザーを獲得して事業を拡大する。そのために，UXに対して品質の指標を設定し，十分な品質を確保するように，要件定義，設計及びテストを実施する。
• 経営層の危機感を踏まえて，サービス開始の目標期限を設定し，予測型開発アプローチでシステムを開発する。ただし，廉価ユーザーは新たな利用者層であることから期待やニーズを一挙には把握できないので，複数回にわたって把握する。
• 要件定義では，簡単サービスのUXに対してこれまでの付加サービスの固定観念にとらわれない新たな期待やニーズを多面的に把握し，簡単サービスで十分な品質が確保できるようにする。
• 実装内容がUXに適合しているかどうか，及び実現するUXに対価に見合う価値であるかどうかを，簡単サービスのUXに理解を示している利用者が設計，テストの各段階で繰り返し検証する。
• 要件定義，設計及びテストでは利用者の参加が必要なので，各段階で行うニーズなどの提示及び内容の検証にふさわしい利用者を，プロジェクトの協力者として営業部門を通じて募る。

〔要件定義に関するプロジェクト計画〕

UX実現の検討方針に従い，要件定義段階では，これまで付加サービスの利用がなく，かつ，利用回数が多い無償ユーザーのうち，次の二つの条件を満たす利用者を対象者として選定し，ヒアリングすることにした。
(i) Webサービスを使い慣れていない利用者
(ii) a

まず，ワイヤーフレームを見てもらって，実際の利用場面をイメージしながら，操作性，視認性，入力情報項目の量に対する許容度，レストラン選択の判断に使うお勧め情報項目に対するニーズ，及び利用者が意識する時間（以下，利用時間という）に関するニーズを提示してもらう。把握したニーズなどを分析し，実装する画面機能やレイアウト，入力情報項目，出力情報項目，及び利用時間を要件として定義する。

〔設計に関するプロジェクト計画〕

UX実現の検討方針に従い，設計段階では，簡易な条件入力画面とお勧め情報の表示画面のモックアップを使って，要件定義段階でのヒアリング対象者に操作性，視認性，表示項目などがUXに適合するかどうかを検証してもらうことにした。

〔結合テストに関するプロジェクト計画〕

R課長は，本番稼働環境に近い環境で結合テストを行う計画とした。結合テストでは，複数の機能が連携して設計どおりに動作するかどうか，実装内容が要件に対して適切なものであるかどうかを本番データに近い疑似的なレストランの予約データを用いてテストする。この作業は4週間で終了するが，UX実現の検討方針に従い，R課長は次の検証も結合テストで行うために，追加で1週間の期間を確保した。

• 要件定義段階でのヒアリング対象者に，操作性・視認性を含む実装内容がUXに適合するかどうかを検証してもらう。
• 上記の対象者に加え，付加サービスの利用を今はやめている無償ユーザーにも結合テストに参加してもらい，ある内容を検証してもらう。

〔総合テストに関するプロジェクト計画〕

UX実現の検討方針に従い，総合テストでは，結合テストまでのテスト参加者に加え，簡単サービスのUXに関心がある無償ユーザーにも参加してもらい，簡単サービスのUXが対価に見合う価値であるかどうかの検証と，UXに対するニーズなどの追加提示をしてもらう。追加提示されたニーズなどは精査の上対応する改修を行い，UXの品質が一定のレベル以上になったことを確認した上で，本番稼働させるスケジュールとする。

以上の整理を含め，R課長はプロジェクト計画を完成させた。