令和6年度秋期 プロジェクトマネージャ 午後Ⅰ 問1

問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課長はプロジェクト計画を完成させた。 設問1〔要件定義に関するプロジェクト計画〕について答えよ。 （1） R 課長が，ヒアリングの対象者を，これまで付加サービスを利用したこと がある無償ユーザーではなく，利用したことがない無償ユーザーから選定した 狙いを35字以内で答えよ。 （2） R 課長は，ヒアリング対象者として，どのような条件を満たす利用者を選 定したのか。本文中の［a］に入れる適切な利用者を30字以内で答えよ。 （3） R 課長は，利用時間に関するニーズとして，何の時間に関するニーズを収 集したのか。20字以内で答えよ。 設問2 〔設計に関するプロジェクト計画〕について，R 課長が，検証してもらうため に，要件定義段階でのヒアリング対象者を再度選定した狙いは何か。35字以内 で答えよ。 設問3 〔結合テストに関するプロジェクト計画〕について答えよ。 （1） R 課長は，操作性・視認性がUXに適合するかどうかを，設計段階だけでな く，結合テスト段階でも検証する計画としたのはなぜか。25字以内で答えよ。 （2） R 課長が，結合テストで，付加サービスの利用を今はやめている無償ユー ザーに検証してもらう内容は何か。25字以内で答えよ。 設問4 〔総合テストに関するプロジェクト計画〕について答えよ。 （1） R課長が，簡単サービスの UXに関心がある無償ユーザーにも総合テストに 参加してもらった事業上の狙いを25字以内で答えよ。 （2） R課長が，総合テストでも UXに対するニーズなどの追加提示をしてもらっ た理由は何か。35字以内で答えよ。