プロジェクトマネージャ 2024年 秋期 午後I 問題

共通の文章

次の記述を読んで,設問に答えよ。 P社はレストラン予約のサービス事業を展開しており,サービスを提供するシステ ムは自社で開発している。サービスの利用者には無償の基本サービスと有償の付加サ ービスを提供している。付加サービスでは,様々な条件で検索できたり,口コミの投 稿・関覧ができたり,特別メニューを選択できたりする。これまで提供情報の種別・ 量や検索手段増やすことで,付加サービスの利用者(以下,ロイヤルユーザーとい う)を開拓してきた。しかし近年,付加サービスの利用をやめて,ロイヤルユーザー から基本サービスの利用者(以下,無償ユーザーという)に戻る利用者が増えてきた。 P社の経営層はこの事態に危機感を抱き,早急に対策をとるために,営業部門の0 ok 長とIT部門のR課長に状況の分析を指示した。 〔状況の分析と対策] 0課長とR課長はサービスの利用者にインタビューした。付加サービスの利用をや めた無償ユーザーへのインタビューでは,"自分には付加サービスは対価に見合うサ ービスではなかった。例えば,Webサービスに慣れていないので,様々なボタンを押 LEY,いろいろな情報を入力したりすることができず,希望するレストランが見つ けられなかった。また,検索から予約までの合計の時間が掛かるので使いにくかった。 レストランを探す際に口コミを見てもどこが良いか分からないし,EK,口コミを目 分では投稿しない。自分に限らず,多少のお金を支払ってでも良いレストランを探し たい人は多いので,対価に見合うサービスを提供してほしい。”といった意見が多か った。一方.ロイヤルユーザーへのインタビューでは,時間を掛けてレストランを探 LEY,口コミの投稿・閲覧をしたり,特別メニューを利用したりする体験が高く評 価されていた。 0課長とR課長は収集したインタビュー結果などから,次のような分析をした。 Webサービスを使い慣れていない利用者と,希望に合ったレストランを簡単に探し たい利用者には,付加サービスのUXは適合しない。 .付加サービスの利用後にUXが対価に見合わないと感じて利用をやめる利用者が増 加した。このような利用者に再度有償のサービスを利用してもらうためには,付加 cs BB サービスとは異なる新たなUXを提供し,そのUXを対価に見合う価値にする必要が ある。 ・有償のサービスでは,UXを対価に見合う価値にすることが重要なので,有償のサ ービスを提供するシステムはUXを明確に定義して開発する必要がある。 ・無償ユーザーのうち,付加サービスのUXに関心がない利用者も,有償のサービス で対価に見合うUXが提供される場合は,有償のサービスを新規に利用する可能性 が高い。 この分析に基づき,P社の経営層は事業拡大のために"複雑な操作をせずに,希望 するレストランがお勧めされ,すぐに予約できる。"というUXを定義した。そして このUXを提供する新たな有償のサービス(以下,簡単サービスという)を開始する ことで,より多くの簡単サービスの利用者(以下,廉価ユーザーという)の獲得を目 指すことを決定した。P社は簡単サービスを提供するシステムを開発するプロジェク トを立ち上げ,R課長がプロジェクトマネージャ(PM)に任命された。 «(UX実現の検討方針 R課長は簡単サービスで十分な品質のUXを提供することが重要であると考え,次 のUX実現の検討方針でプロジェクト計画を作成することにした。 ・様々な利用者が対価に見合う価値であると感じるUXを実現し,より多くの廉価ユ ーザーを獲得して事業を拡大する。そのために,UXに対して品質の指標を設定し, 十分な品質を確保するように,要件定義,設計及びテストを実施する。 ・経営層の危機感を踏まえて,サービス開始の目標期限を設定し,予測型開発アプロ ーチでシステムを開発する。ただし,廉価ユーザーは新たな利用者層であることか ら期待やニーズを一挙には把握できないので,複数回にわたって把握する。 ・要件定義では,簡単サービスのUXに対してこれまでの付加サービスの固定観念に とらわれない新たな期待やニーズを多面的に把握し,簡単サービスで十分な品質が 確保できるようにする。 ・実装内容がUXに適合しているかどうか,及び実現するUXが対価に見合う価値であ るかどうかを,簡単サービスのUXに理解を示している利用者が設計,テストの各 段階で繰り返し検証する。 ・要件定義,設計及びテストでは利用者の参加が必要なので,各段階で行うニーズな ー3一 どの提示及び内容の検証にふさわしい利用者を,プロジェクトの協力者として営業 部門を通じて募る。 [要件定義に関するプロジェクト計画] UX実現の検討方針に従い,要件定義段階では,これまで付加サービスの利用がな く,かつ,利用回数が多い無償ユーザーのうち,次の二つの条件を満たす利用者を対 象者として選定し,ヒアリングすることにした。 (i)Webサービスを使い慣れていない利用者 a)ビュー ED,ワイヤーフレームを見てもらって,実際の利用場面をイメージしながら,操 作性。視認性,入力情報項目の量に対する許容度,レストラン選択の判断に使うお勧 め情報項目に対するニーズ,及び利用者が意識する時間(以下,利用時間という)に 関するニーズを提示してもらう。把握したニーズなどを分析し,実装する画面機能や レイアウト,入力情報項目,出力情報項目,及び利用時間を要件として定義する。 〔設計に関するプロジェクト計画〕 UX実現の検討方針に従い,設計段階では,簡易な条件入力画面とお勧め情報の表 示画面のモックアップを使って,要件定義段階でのヒアリング対象者に操作性,視認 性,表示項目などがUXに適合するかどうかを検証してもらうことにした。 [結合テストに関するプロジェクト計画〕 R課長は,本番稼働環境に近い環境で結合テストを行う計画とした。結合テストで は,複数の機能が連携して設計どおりに動作するかどうか,実装内容が要件に対して 適切なものであるかどうかを本番データに近い疑似的なしストランの予約データを用 いてテストする。この作業は4週間で終了するが,UX実現の検討方針に従い,R課長 は次の検証も結合テストで行うために,追加で1週間の期間を確保した。 ・要件定義段階でのヒアリング対象者に,操作性・視認性を含む実装内容がUXに適 合するかどうかを検証してもらう。 ・上記の対象者に加え,付加サービスの利用を今はやめている無償ユーザーにも結合 テストに参加してもらい,ある内容を検証してもらう。 ー4ォー [総合テストに関するプロジェクト計画] UX実現の検討方針に従い,総合テストでは,結合テストまでのテスト参加者に加 A,簡単サービスのUXに関心がある無償ユーザーにも参加してもらい,簡単サービ スのUXが対価に見合う価値であるかどうかの検証と,UXに対するニーズなどの追加 提示をしてもらう。追加提示されたニーズなどは精査の上対応する改修を行い。UX の品質が一定のレベル以上になったことを確認した上で,本番稼働させるスケジュー ルとする。 以上の整理を含め,R課長はプロジェクト計画を完成させた。

共通の文章

2プロジェクトマネジメントの計画に関する次の記述を読んで,設問に答えよ。 E社は,営業部門,工事部門,管理部門など複数の部門をもつ通信事業者である。 E社では,共通基盤上に仮想化技術によって部門の業務に最適化した部門ごとのシス テム(以下,現部門システムという)を構築しており,現部門システム間は疎な関係 で連携していた。LOL,共通基盤の老朽化と現部門システムの保守性の低下でシス テム投資が増え,E社の課題となっていた。そこで,共通基盤にPaaSを採用し,現 在と同様に部門ごとに新しいシステム(以下,新部門システムという)を再構築する 計画を決定した。この計画では,現在の共通基盤の保守期限切れとなる計画時点の2 年後に,全部門の新部門システムを同時稼働させることになっていた。 新部門システムの再構築は,6か月間で要件定義を行い,その後の18か月間で開 発を行う計画であったが,要件定義の期間中にE社の事業に影響する制度改正が決ま り,現部門システムを制度改正の施行までに改修することが必須となった。そこで, 新部門システムの要件定義を開始後3か月の時点で中断し,現部門システムの定常の 保守作業も中止して,現部門システムの制度改正対応の保守作業(以下,制度改正作 業という)に一時的に注力することになった。その結果,図1に示すように,新部門 システムの要件定義は計画より3か月遅れで完了した。なお,制度改正は,現時点か ら9か月後,新部門システムの稼働の6か月前に施行される。現在の共通基盤は保守 期限切れとなるので新部門システムの乏働時期を守ることが必須であり,新部門シス テムの再構築計画の見直しを行った結果,新部門システムの開発は,要件を優先度の 高いものに絞ることによって,計画より3か月間短縮した15か月間で実施するスケ ジュールとなった。 REAM a|#8|ve[oie]vais]vere]toes[ores| fe 制度改正作業要件定義開発 図1新部門システムの再構築と制度改正作業のスケジュール ー6一 E社のシステム部には,担当する部門ごとに課が置かれている。システム開発は, 担当する課がプロジェクトを立ち上げて実施している。各課では,営業部門向けでは 変化への適応スピード重視,工事部門向けでは安定性重視など,担当する部門の業務 特性や状況に合わせた部門ごとの“プロジェクトマネジメントの方法”(LIE,PMM という)によって部門に協力していたので,各課のメンバーと担当する部門のステー クホルダとの間には信頼関係が築かれていた。一方で,課ごとのPMMの違いによって, システム部のメンバーの育成の共通化や他の課への柔軟な異動ができず,システム部 内で他の課と情報を共有して共同作業を行うことが難しくなっていた。制度改正作業 の要件定義では,ある現部門システムでの課題への対応方針と他の現部門システムで の課題への対応方針がPMMの違いで対立するなど,部門を担当する課の間で課題への 対応の合意に時間を要し,制度改正の施行に問に合わないリスクの要因となっていた。 また,開発成果物の構成管理は,担当する現部門システムの品質と信頼性を維持する ために,担当する各課が,それぞれ異なるプロセス,ツールを適用するなど個別のや り方で実施しており,システム部全体としての開発効率が悪化する原因にもなってい com [プロジェクトの立ち上げ]〕 現在E社システム部の副部長で,長く管理部門を担当する課の課長であったKid, 新部門システムの再構築に要件定義から参加してきた。新部門システムの開発は,要 件定義の結果を基に,担当する各課でスコープを定義して作業する。F氏は,部門ご とに稼働時期を決めていた現部門システムとは異なり,①全部門の新部門システムの 同時稼働が必須であることから,全部門の新部門システムの開発の作業を一つのプロ ジェクトGAR,本プロジェクトという)としてマネジメントすることにし,自らが プロジェクトマネージャ(PM)を担うこととした。 F氏は,自身の経験が豊富な管理部門を担当する課のPMMを本プロジェクトに全面 的に適用することを考えたが,②特定の課のPMMを本プロジェクトに全面的に適用す St,スケジュール遅延のリスクが高まると判断した。そこで,各課のPMMを生かし つつ,一つのプロジェクトとしてマネジメントするために,共通化したPMM(以下, 共通PMMという)を適用するマネジメントプロセスと,各課のPMMを適用するマネジ メントプロセスを区分けすることにした。新部門システムの開発において,複数の課 の開発に影響するマネジメントプロセスには共通PMMを適用し,それ以外の課ごとに 異なっていても問題のないマネジメントプロセスには,各課のPMMを適用する。 [共通PMMのマネジメント組織の検討] F氏は,共通PMMを導入して実行するためのマネジメント組織を検討することにし, プロジェクトの特性を次のように整理した。 ・本プロジェクトのPMである氏自身は,担当してきた管理部門のステークホルダ との信頼関係は築けているが,それ以外の部門のステークホルダとの関係性は薄い。 ・本プロジェクトの開発のメンバーはシステム部の各課から選任するが,メンバーの 多くは,制度改正作業も兼任して稼働する。 ・各課長は,課内の各メンバーの本プロジェクトと制度改正作業との稼働割合を設定 し,設定した稼働割合を基に,新部門システムの開発スケジュールを作成する。 ・本プロジェクトの円滑な推進には,部門のステークホルダとの信頼関係の維持・構 築が欠かせない。 F氏は,上記を踏まえて,共通PMMの実行組織として,F氏の下にシステム部内の 関係する全課長をメンバーとするPMOを設置することにし,各課長に次の活動を指示 した。 (a)PMOのメンバーとして,課の垣根を越えてプロジェクト全体を見て共通PMMを 用いたマネジメント活動を行う。これに加えて,本プロジェクトを担当する課の長 として,各課のPMMを用いたマネジメント活動を行う。 (b)各課長は,課の個々のメンバーの乏働状況について問題があれば,本プロジェ クトに関する事項はF氏に,制度改正作業に関する事項はシステム部長に報告し 必要な調整をした上で対応を行う。 (c)本プロジェクト及び制度改正作業を担当する課の長として,これまでと同様に 担当する部門のステークホルダとの信頼関係の維持に努める。 また,F氏は,本プロジェクト又は制度改正作業のいずれかで作業の進捗遅れが発 生し,課内の本プロジェクト及び制度改正作業の中での対応が困難な場合には,シス テム部長,F氏,各課長が出席する③毎週の部会において全員で対策を協議すること とし,システム部長の承認を得た。 =8 m 〔共通PMMのマネジメント計画の検討] 本プロジェクトの最大のリスクは,新部門システムの開発スケジュールの遅延であ る。F氏は,課題管理について,制度改正作業で課題の対応の合意に時間を要したこ とから,新部門システムの開発においても,担当する課固有の課題以外に,課を横断 する課題が発生し,対応に時間を要する可能性があると考えた。そこで「氏は,OF 部門の新部門システムの進捗会議にPMOの全メンバーの参加を必須とし,課題対応の 調整をPMOの責務とすることを,共通PMMとして定めることにした。 F氏は,共通PMMの適用による,本プロジェクトでの開発効率の改善を図るために, ⑤各課が個別のやり方で開発成果物の構成を管理している方法を見直すことにした。 Malプロジェクトの立ち上げ})について答えよ。 (1)本文中の下線のについて,F KA,全部門の新部門システムの開発の作業 を一つのプロジェクトとしてマネジメントすることにした背景にある,現在の システム部の組織としての問題は何か。35字以内で答えよ。 (2)本文中の下線@について,F氏が,特定の課のPMMを本プロジェクトに全 面的に適用すると,スケジュール遅延のリスクが高まると判断した理由は何か。 30字以内で答えよ。

共通の文章

プロジェクト計画の修整(テーラリング)に関する次の記述を読んで,設問に答え よ。 A銀行は,中堅の地方銀行である。近年,地盤である地域の人口減少や高齢化で, 収益は年々減少傾向にある。この状況に危機感をもったA銀行は,グループ会社とし て新たなネット専業銀行(以下,H銀行という)を設立して,全ての取引をスマート フォン向けアプリケーションソフトウェア(以下,スマホアプリという)で完結させ るサービスを1年後に提供することを決定した。高金利の新商品や,ポイント林元な どの付加サービスを打ち出し,日本全国の顧窒をターゲットに事業を展開することに した。システム開発を含む銀行業務の立ち上げに必要なメンバーが,若手の行員を中 心にA銀行からH銀行に出向した。 H銀行は,1年という短期間で銀行業務を開始することが必達目標なので,勘定系 システムは,ITベンダーY社が提供するサービス(以下,Yサービスという)を利用 する。Yサービスは複数の銀行が共同で利用しており,A銀行でも利用している。ま た,新商品や付加サービスを提供するフロントシステム及びスマホアプリ(以下,新 システムという)は,H銀行システム部がY社の支援を受けて開発し,Yサービスの APLで連携する。新システムの開発プロジェクト(AF,Hプロジェクトという)が 立ち上げられ,H銀行システム部の1課長がプロジェクトマネージャ(PM)に任命さ れた。Yサービスの利用範囲は確定し,サービス導入はY社が担当することで合意し た。一方,新システムへの要求事項は,H銀行企画部が各業務部門と共同で市場ニー ズを調査しながら順次確定する。どの要求事項を,必達目標である1年後に実現する か,DEY,Hプロジェクトのスコープとなる要求事項(以下,開発項目という)は, H銀行として順次判断しながら確定させることになった。 [プロジェクト計画の検討] {課長は,開発項目を順次判断しながらHプロジェクトを進めるには適応型開発ア プローチが適合すると考えたが,A銀行グループではノウハウが不足しており,適応 型開発アプローチを適用するプロジェクト(以下,適応型プロジェクトという)のマ ネジメント標準が定まっていない。A銀行では,開発項目の変動が少ない予測型開発 アプローチを適用したプロジェクトのマネジメント標準(以下,A銀行マネジメント ー10一 標準という)が規定されていて,原則としてA銀行マネジメント標準にのっとってプ ロジェクトを進めていくことが求められている。そこで1課長は,期限厳守のHプロ ジェクトでは,メンバーが習熟しているA銀行マネジメント標準を基に,適応型開発 アプローチの要素を加味して修整を行いHプロジェクトに適用することにした。 H銀行システム部は,BR,1課長と一部のベテラン行員を除くと若手の行員が多 い。また,H銀行では,Hプロジェクト完了後も適応型プロジェクトが継続して立ち 上げられることが見込まれており,適応型プロジェクトをマネジメントできる若手の リーダー育成がH銀行システム部の喫緊の課題である。1課長は,リーダー育成にも 十分に配慮してプロジェクト計画を作成することにした。Hプロジェクトでは適応型 開発アプローチの要素を加味してA銀行マネジメント標準を修整するので,リーダー には適応型プロジェクトのマネジメントと,その実現に適したリーダーシップの両方 を習得してもらうことを育成の目標とした。プロジェクトチームの編成において,H プロジェクトでは若手でモチベーションが高く自発的に仕事に取り組む姿勢をもつメ ンバーを積極的にリーダーに登用することにした。また,マネジメントに当たっては, 支援型リーダーシップの習得が適していると考えた。 [開発項目の定義プロセスの検討] !課長は,H銀行企画部とHプロジェクトの進め方について協議した。H銀行企画部 は,“既に取り決めたとおり,要求事項は最新の状況において優先度を付けて順次判 断し,開発項目の更新を行っていく。予算は,戦略的な事業として,上限はあるが一 定の余裕をもって確保しているので,スケジュールは厳守しつつ予算内で要求事項の 取込みに最大限柔軟に対応してほしい。"。とのことであった。 I課長は,このように開発項目を順次更新していくに当たって,A銀行マネジメン ト標準の予測型開発アプローチを前提としたスコープ定義プロセスは適さないことか ら,スコープに関わる現状の変更管理プロセスを参考にしてHプロジェクトの開発項 目の定義プロセスを検討することにした。A銀行マネジメント標準の変更管理プロセ スは次のとおりである。 ・変更を要求する部門が,スコープの変更要求を,変更管理委員会(UF,COBとい う)に提示する。 ・A銀行システム部が,変更要求に基づく影響を調査し,変更を実施する際のリスク ー11一 や課題,追加コストなどを整理する。 ・A銀行システム部の影響調査結果に基づき,CCBが変更要求を承認又は否認する。 これまで,このプロセスの運用では変更の効果が不明確だったり,他の部門の変更 要求と相反したりして,A銀行システム部では,変更要求を提出した部門や他部門と のやり取りが何度か発生することが多かった。 I課長は,開発項目の定義プロセスにおいて,H銀行のシステム部長,企画部長, 企画部のメンバー,及び1課長から成る開発項目定義委員会(以下,DDBという)を 設置して適宜開催し,開発項目に取り込む要求事項の優先度の付与や開発項目の入替 えなどの開発項目の更新を決定することにした。その上で,OA銀行マネジメント標 準の変更管理プロセスを次のように修整して,開発項目の定義プロセスとした。 ・②要求事項の判定基準を設定し,各業務部門の要求事項がHプロジェクトに提示で きる基準を満たしているかどうかをH銀行企画部で判定する。 ・判定基準を満たしている要求事項は,H銀行企画部がHプロジェクトに提示する。 ・Hプロジェクトでは,新たに提示された要求事項について,その要求事項を開発項 目に取り込む際の課題,追加コストを整理する。その上で,要求事項の取込みに伴 う開発項目の更新によるスケジュール遅延リスクの発生確率のレベルを高,中,低 の3段階でHプロジェクト全体の作業状況や計画における余裕度に照らして評価 する。各レベルのスケジュール遅延リスクの発生確率は,レベル高が60%以上, レベル中が30%以上一60%未満,レベル低が30%未満である。 ・Hプロジェクトでは,レベル低の要求事項はPMによる承認で開発項目に取り込め る。レベル高及び中の要求事項の場合は,開発項目の更新をDDBに付議する。ただ しレベル高及び中の要求事項であってもDDBの③ある決定によって,スケジュール 遅延リスクの発生確率を再評価してレベル低である30%未満に軽減できれば,PM による承認でその要求事項の追加に伴う開発項目の更新を実施できる。 1課長は,④プロジェクトの進捗に伴って要求事項の取込みは困難となっていくこ とを含めて,開発項目の定義プロセスについてDDBのメンバーに合意を取った。 [チームのマネジメント計画の作成] A銀行マネジメント標準のチームのマネジメントでは,PMとリーダー間の明確な役 割と責任の分担,及びこれらに対応した指示・報告に基づいたプロセスが規定されて ー12一 おり,課題の解決方法やメンバーの活動を明確に指示し,指導を行うことを重視して いる。1課長は,⑤H銀行システム部の喫緊の課題の解決に,このようなチームのマ ネジメントは適さないと考えた。そこで,過去のプロジェクトの教訓を参照して,A 銀行における若手リーダーを登用した際の次の失敗事例を確認した。 ・PMが適切な情報共有やフォローをせず一方的に指示をした結果,若手リーダーの モモすずマージョシンを下げてしまった。 ・リーダーに登用された責任感から,メンバーの活動を細かく指示したり,過度にメ ンバーの課題解決に介入したりした結果.チームとしてのパフォーマンスが低下し て,進捗が遅れてしまうことがあった。 ・進捗に遅れがあるにもかかわらず,リーダー以上が参加する週次進捗会議で現実の 状況を報告すると皆の前で叱責されると考え,問題なしと報告を上げていた。その ER,遅延が表面化したときには状況が深刻になっており,対策の遅れとともに多 くの時間とコストを費やすことがあった。 I課長はこれらの教訓から,A銀行マネジメント標準のチームのマネジメントのプ ロセスを次のように修整して,チームのマネジメントの計画を作成した。 ・他社で適応型プロジェクトを経験して⑥支援型リーダーシップを習得してきたベテ ラン行具を若手リーダーの育成役としてアサインする。 ・⑦H銀行の必達目標を達成するために,メンバーの動機付けや自律的な課題解決の 促進などについて,育成役のベテラン行員が若手リーダーを後方で支援する。 ・進捗の遅れは,メンバーの問題ではなくチーム全体の問題として全員で解決に当た ることを行動の基本原則とし,原因究明するための問題の共有と早期解決に向けた 計画の作成をリーダーの責務とする。その上で,リーダー以上が参加する週次進 捗会議とは別に,チーム全員が参加する朝会を毎朝実施し,"昨日の進捗","今日 の予定","障壁となっている事項や不安要素"を簡潔に報告してもらうことにする。 {課長が修整したプロセスを反映したプロジェクト計画書は,H銀行内で合意が得 bn,Hプロジェクトが開始されることになった。