プロジェクトマネージャ午後Ⅱ論文対策|実務経験を持つ一発合格者が書いた解答例【平成24年度:問1】(別解)

こんな人におすすめ
  • 午後Ⅱ(小論文)でいつもつまづいている
  • 小論文のネタを探している
  • 合格者のアドバイスを受けたい

プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

問題文および設問

具体的な問題はIPAにてご確認ください。

問題文

問1 システム開発プロジェクトにおける要件定義のマネジメントについて

 プロジェクトマネージャには、システム化に関する要求を実現するため、要求を要件として明確に定義できるように、プロジェクトをマネジメントすることが求められる。
 システム化に関する要求は従来に比べ、複雑化かつ多様化している。このような要求を要件として定義する際、要求を詳細にする過程や新たな要求の追加に対処する過程などで要件が膨張する場合がある。また、要件定義工程では要件の定義漏れや定義誤りなどの不備に気付かず、要件定義後の工程でそれらの不備が判明する場合もある。このようなことが起こると、プロジェクトの立上げ時に承認された個別システム化計画書に記載されている予算限度額や完了時期などの条件を満たせなくなるおそれがある。
 要件の膨張を防ぐためには、例えば、次のような対応策を計画し、実施することが重要である。
・要求の優先順位を決定する仕組みの構築
・要件の確定に関する承認体制の構築
 また、要件の定義漏れや定義誤りなどの不備を防ぐためには、過去のプロジェクトを参考にチェックリストを整備して活用したり、プロトタイプを用いたりするなどの対応策を計画し、実施することが有効である。

 あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトにおける、プロジェクトとしての特徴、及びシステム化に関する要求の特徴について、800字以内で述べよ。

設問イ

設問アで述べたプロジェクトにおいて要件を定義する際に、要件の膨張を防ぐために計画した対応策は何か。対応策の実施状況と評価を含め、800字以上1,600字以内で具体的に述べよ。

設問ウ

設問アで述べたプロジェクトにおいて要件を定義する際に、要件の定義漏れや定義誤りなどの不備を防ぐために計画した対応策は何か。対応策の実施状況と評価を含め,600字以上1,200字以内で具体的に述べよ。

解答例

設問ア

1.プロジェクト概要とシステム化の要求

1.1.プロジェクト概要

1)プロジェクト概要
 私がプロジェクトマネージャを担当したプロジェクトは、全国展開するアパレル小売業A社向けの、次期顧客分析プラットフォーム構築である。散在する顧客データ活用によるLTV向上が目的である。期間は約1年半、予算は2億円。主要ステークホルダーは複数部門(マーケティング部、営業推進部、情報システム部など)であり、開発は自社と外部ベンダーの混成体制だった。
 本プロジェクトの技術面の特徴として、クラウドDWHの新規導入という特徴があった。既存のPOSシステムやECサイト等との複雑なデータ連携、及び将来的なデータ量増加への対応が目的だった。
 また、厳しい納期、追加予算なし、ノウハウを持つ要員不足、といった経営資源上の制約があった。

1.2.システム化要求の特徴

1)要求の背景とゴール
 システム化要求の背景には、市場競争力強化と多様な顧客ニーズの対応があった。従来の施策では効果が限定的となり、データに基づいた個別アプローチへの転換が急務だった。ゴールは、顧客一人ひとりの行動を深く理解し、最適な情報提供によるエンゲージメントとロイヤルティを高め、顧客LTVを最大化することだった。
2)要求の複雑性・多様性
 要求は多部門から寄せられ、それぞれ重視する点が異なり調整が複雑だった。マーケティング部からは高度な分析機能、営業推進部からは店舗活用ツール、情報システム部からは運用・セキュリティを強く求められた。また、分析結果に基づく新たな業務プロセス変革を伴う要求も含まれた。非機能要件として、数百万会員のデータを扱うための大量データ処理性能、個人情報保護法遵守のための高度なセキュリティ、将来のスケーラビリティが特に重要であり、これら非機能要求の実現難易度も高かった。

(795文字)

設問イ

2.要件膨張を防ぐための対応策

2.1.要件膨張を防ぐために計画した対応策

1)対応策立案の背景
 本プロジェクトでは、多様な部門からの期待が高く、要件が膨張するリスクを強く認識した。新しい分析プラットフォームへの期待から、想定外の要求が多発することを懸念した。厳しい納期と予算内でプロジェクトを成功させるため、スコープの厳格な管理が不可欠と判断した。客観的かつ合意形成を重視したプロセスを通じて、真に価値のある要件に絞り込み、プロジェクト目標を達成することが狙いだった。

2)計画した具体的な対応策
 要件膨張を防ぐため、以下の二つを計画した。
・要求の優先順位を決定する仕組み
 MoSCoW分析を採用。ワークショップで、要求をビジネスインパクトと実現容易性で評価・議論し、ステアリングコミッティで承認を得る。客観的な基準で合意形成を図り、初期リリースの必須要件を明確化を期待した。
・要件の確定に関する承認体制
 要件定義ワークグループと変更管理委員会(CCB)を設置。ワークグループで詳細化・合意した要件をCCBが承認しベースライン化。ベースラインの変更は全てCCBで審議。責任の所在を明確にし、適切な経営判断を仰ぐことが狙いだった。

2.2.対応策の実施状況

1)要求の優先順位付け
 約200件の要求を収集後、MoSCoW分析ワークショップを5回開催。「対応必須」を約80件に絞り、初期リリース対象とし、「対応すべき」以下は次期検討とした。要求の本質を深掘りする工夫をし、ワークショップでの議論が発散しないようにした。部門間対立もあったが、客観データ提示と経営層調整で合意した。
2)要件確定と変更管理の実施
 約2ヶ月で要件定義書を完成させ、CCB承認を得てベースライン化した。その後、15件の変更要求が発生。影響分析の上CCBで審議し、8件承認、3件取下げ、4件否決とした。例えば、「購買予測機能」の追加要望は、工数・納期影響大と判断し、初期リリース見送り、次期検討とした。こうして遅延を防止した。

2.3.対応策の評価

1)対応策の有効性
 優先順位付けと承認体制は、要件膨張抑制に極めて有効に機能した。最終機能数は当初の「対応必須」から約5%増に留まった。結果、プロジェクトは計画納期通り完了し、予算超過もなかった。成功要因は、明確な基準に基づく優先度付けと、CCBによる厳格な変更管理であった。
2)課題と今後の改善点
 課題として、優先度評価基準の解釈に揺れがあった。ビジネスインパクト定義をより定量化すべることが課題と考える。今後の改善点として、優先度評価基準の定義と合意形成に、より時間を割く。変更要求時のエスカレーションルールを明確化し、円滑化を図りたい。

(1178文字)

設問ウ

3.要件定義不備の予防策

3.1.要件定義漏れや定義誤りなどの不備を防ぐ対応策

1)対応策立案の背景
 本プロジェクトでは、既存システム連携の複雑さや新規システム故のUI/UX認識齟齬から、要件の定義漏れ・誤りリスクがあると認識した。これら不備は後工程での手戻りを招き、コスト増・納期遅延に直結するため、初期での対策が不可欠だった。私の狙いは、過去の知見を実用的な形で活用し、関係者間の認識合わせを徹底することで、要件定義品質を高め、手戻りを防ぐことだった。
2)計画した具体的な対応策
 定義漏れや誤りを防ぐため、次の策を計画した。
・チェックリスト整備と活用
 網羅性確保と効率的な運用を目指し、社内ナレッジ等を基に品質チェックリストを作成・活用。担当者の経験によらず一定品質を担保し、チェック工数を最適化する工夫として、単に項目を並べるだけでなく、確認レベルや重点箇所を定める計画とした。
・プロトタイプの活用
 認識齟齬解消のため、主要画面のプロトタイプを活用。手書きからモックアップへ段階的に作成。具体的なイメージを早期共有し、仕様の誤解を防ぐことを狙った。

3.2.対応策の実施状況

1)チェックリストの活用状況
 プロジェクト開始後、約150項目の品質チェックリストを作成。全項目リストとは別に、変更影響度やリスクに応じた「重点チェックリスト」を作成し、レビュー運用を分けた。要件定義書作成・レビュー時の確認ツールとして運用し、特に重点チェックリストは必ず担当者相互で確認を徹底した。例えば、データ連携時のエラー処理不備を発見し、リトライ処理等を追加定義でき、本番稼働後のリスクを未然に防いだ。
2)プロトタイプの活用状況
 主要分析ダッシュボード等、計8画面のプロトタイプを段階的に作成。マーケティング部門と週次で10回以上レビュー。ユーザーからのフィードバックでUIデザインや計算ロジックを改善。ある画面では「情報過多」との指摘から表示形式を変更し、操作性を大幅に改善した。これにより開発着手前の手戻りを防いだ。

3.3.対応策の評価と今後の課題
 チェックリストとプロトタイプ活用は、定義漏れ・誤り防止に有効だった。要件定義段階で約50件の不備を検出し修正。後工程での要件起因の手戻りは、過去比約30%削減できた。特に重点チェックリストの導入が、効率と効果の両立に寄与した。プロトタイプは、ユーザーとのコミュニケーションを活性化し、完成イメージ早期共有で認識齟齬解消に寄与した。これは開発効率化とユーザー満足度向上に繋がった。
 課題は、チェックリスト全体のメンテナンス負荷や、確認時間確保の難しさだった。今後は、チェックリストをシステム化し、メンテ負荷軽減と検索性向上を図る。

(1178文字)

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

コメント