プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例【平成２６年度：問１】

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

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問１　システム開発プロジェクトにおける工数の見積りとコントロールについて

　プロジェクトマネージャ（ＰＭ）には、プロジェクトに必要な資源をできるだけ正確に見積もり、適切にコントロールすることによって、プロジェクトの目標を達成することが求められる。中でも工数の見積りを誤ったり、見積りどおりに工数をコントロールできなかったりすると、プロジェクトのコストや進捗に大きな問題が発生することがある。
　工数の見積りは、見積りを行う時点までに入手した情報とその精度などの特徴を踏まえて、開発規模と生産性からトップダウンで行ったり、ＷＢＳの各アクティビティをベースにボトムアップで行ったり、それらを組み合わせて行ったりする。ＰＭは、所属する組織で使われている機能別やアクティビティ別の生産性の基準値、類似プロジェクトの経験値、調査機関が公表している調査結果などを用い、使用する開発技術、品質目標、スケジュール、組織要員体制などのプロジェクトの特徴を考慮して工数を見積もる。未経験の開発技術を使うなど、経験値の入手が困難な場合は、システムの一部分を先行開発して関係する計数を実測するなど、見積りをできるだけ正確に行うための工夫を行う。
　見積りどおりに工数をコントロールするためには、プロジェクト運営面で様々な施策が必要となる。ＰＭは、システム開発標準の整備と周知徹底、要員への適正な作業割当てなどによって、当初の見積りどおりの生産性を維持することに努めなければならない。また、プロジェクトの進捗に応じた工数の実績と見積りの差異や、開発規模や生産性に関わる見積りの前提条件の変更内容などを常に把握し、プロジェクトのコストや進捗に影響を与える問題を早期に発見して、必要な対策を行うことが重要である。

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

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴と、見積りのために入手した情報について、あなたがどの時点で工数を見積もったかを含めて、８００字以内で述べよ。

設問イ

設問アで述べた見積り時点において、プロジェクトの特徴、入手した情報の精度などの特徴を踏まえてどのように工数を見積もったか。見積りをできるだけ正確に行うために工夫したことを含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問アで述べたプロジェクトにおいて、見積りどおりに工数をコントロールするためのプロジェクト運営面での施策、その実施状況及び評価について、あなたが重要と考えた施策を中心に、発見した問題とその対策を含めて、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と工数見積

１．１．プロジェクト概要

　私が担当したプロジェクトは、小売業Ａ社向けの顧客管理システム（ＣＲＭ）刷新である。既存ＣＲＭの老朽化と機能不足の解決が目的であり、新ＣＲＭ導入による顧客データ一元化、マーケティング高度化、業務効率化を目指した。私はＰＭとして本プロジェクトを統括した。
　本プロジェクトの特徴は、第一に開発期間１０ヶ月という短納期、第二に厳格な予算上限であった。これらは経営戦略上の要請であり厳守が必須だった。第三に、既存機能をクラウドサービスへ移行し、スマホアプリ連携機能を新規開発する点で、組織として未経験技術を含み高リスクと認識した。第四に、営業、マーケティング等の複数部門が関与するという、組織的特徴があった。多部門の要求集約と優先順位付けに高度な調整が必要だった。

１．２．工数見積の時点と入手した主要情報

　工数見積は企画フェーズ完了後、要件定義フェーズ開始直前に実施した。選定理由は、目的・主要機能・範囲の大枠が合意され、実現性検討も進んでいたためである。これにより前提条件を固め現実的な数値を算出できると判断した。また、精度の高い見積りが後続の要件定義やリソース計画の指針となり、短納期・予算制約下での成功に不可欠なマイルストーンと認識していた。
　見積りのために入手した主要な情報は、次の二つである。
１）各業務部門キーパーソン等へのヒアリング結果
　現状業務、課題、新機能要求、期待効果等を把握した。新機能要求は多岐にわたり、規模見積と優先度付けの基礎とした。部門間要求の調整も必要だった。
２）社内の類似ＣＲＭ開発プロジェクト（３件）の実績データ
　ＷＢＳ、工数・生産性実績、課題レポート等を収集し、類推見積の客観的基準とした。ただし採用技術等の差異から補正が必要と判断した。

（７９０文字）

設問イ

２．工数の見積手法と精度向上

２．１．見積方針の策定

　ヒアリング結果は一部定性的であり、詳細化が必要あった。また、類似プロジェクトの実績データは、採用技術やプロジェクト規模が完全に一致するものがなく、特に未経験技術部分の生産性評価は慎重に行う必要があった。
　これらの状況から、トップダウンアプローチで概算を把握後、ボトムアップアプローチで詳細化・具体化する方法を選択した。早期に全体像を把握して精度向上を図り、リスク洗い出す目的があった。特に未経験技術部分は重点的にリスク評価し、なるべく定量的な根拠で見積もるようにした。

２．２．工数見積プロセス

１）開発規模の見積手法
　機能特性に応じて、複数の手法で開発規模を見積もった。既存機能の改修は、機能一覧とヒアリング結果から規模を３段階に分類し、類似の実績から類推して見積った。規模感を掴みやすく、過去実績が有用と考えたためである。一部ドキュメントが陳腐化しており、実機確認等で補完した。新規開発するウェブ機能は、定量的に評価でき客観性が高い、ファンクションポイント（ＦＰ）法で見積もった。ヒアリング結果から得た画面数等からＦＰを算出し、定性的な要求は、業務フロー等を作成する中で、具体的な機能に落とし込みＦＰを算出した。未経験のクラウド・スマホアプリ連携機能は、知見不足のためＦＰの算定を断念し、連携データ項目数等を基に、専門家の意見／先行事例／ベンダー情報を加味して見積もった。
２）生産性の見積方法
　組織標準のＦＰ単価を生産性の基本とし、要員スキルや顧客部門の多さといった本プロジェクト固有の要因で補正した。特に重視したのは未経験技術部分で、学習コスト、手戻り等のリスクを洗い出し、基本生産性に対し３０～５０％程度の低下を見込んだ。楽観的な見積りによる後半での問題発生の回避するため、難易度等に応じて悲観シナリオも考慮した。
３）工数の算出と調整
　算出した規模と生産性から各機能の開発工数を算出し、ＷＢＳで積算して開発工数を算出した。プロジェクト管理工数は、過去実績から総直接開発工数の２０％を計上した。コンティンジェンシバッファは、技術的・要件変更等のリスクを勘案し１５％を設定した。バッファは、リスク顕在化時に計画的に使用し、安易な消化を防ぐため、ＰＭ管理とした。

２．３．見積精度向上のための工夫

　見積精度向上のため、下記の点に注力した。
１）未経験技術部分のプロトタイピング実施
　未経験技術であるクラウド・スマホアプリ連携は不確実性が高く、手戻り・遅延リスク回避が必要だった。要件定義と並行し、技術的に不確実なコア部分のプロトタイプを技術リーダー含む２名で３週間開発した。技術的実現性検証、課題早期発見、実測データ取得が目的だった。結果、ＡＰＩ連携の複雑性やＯＳ互換性問題などが早期に判明し、楽観的過ぎた部分を特定し、約１０％の工数増を見積りに反映できた。これは、現実的な計画策定と後工程での手戻り防止の効果があった。
２）見積前提条件の明確化とステークホルダーレビュー
　多部門が関与する本プロジェクトでは、前提条件の認識齟齬が起こるリスクが高いと判断し、この工夫が必要と考えた。算出した工数結果と、その根拠（スコープ、機能一覧、実現レベル、前提スキル、顧客提供情報等）を網羅した「見積前提条件書」を作成した。これに基づき主要ステークホルダー参加の見積レビュー会議を開催し、見積り根拠と前提条件を説明し質疑応答で認識共有を図った。結果、見積りの透明性が高まり共通理解が醸成され、一部機能への期待値のズレが判明し、スコープ再調整のきっかけとなった。将来の変更要求への客観的な評価基準となり、プロジェクト運営安定化とステークホルダーからの信頼獲得に寄与した。　

（１５９６文字）

設問ウ

３．工数コントロールのための重要施策と評価

３．１．プロジェクト運営面の重要施策

　本プロジェクトは複数部門が関与するため、なし崩し的に要求が拡大する可能性があり、無秩序な変更受入れによる工数増大のリスクがあった。これを防ぐため、変更管理プロセスの厳格な運用と影響分析の実施を、最重要施策と位置付けた。変更要求に明確なプロセスを定義し、影響を定量分析・評価することで、計画安定性を確保し目標逸脱を防げると考えたからである。また客観的影響分析に基づくステークホルダー協議は、円滑な合意形成とＰＭのコントロール維持に不可欠と考えた。

３．２．重要施策の実施状況

　全変更要求は「変更要求書」での提出を義務化し、週に一度、ＰＭ、技術リーダー、各部門代表、開発リーダー、品質保証担当者で構成する変更管理委員会（ＣＣＢ）で審議することにした。ＣＣＢでは変更の妥当性、優先度、実現可能性、特に開発チームの詳細な影響分析（追加工数、スケジュール影響、リスク等）を審議し、承認・否認を決定した。承認された変更は計画に反映し、全関係者に周知した。否認の場合も、理由を丁寧に説明し理解を求めた。

３．３．発見した問題とその対策

　開発中盤、マーケティング部門から、顧客分析画面等の変更要求が複数発生した。システムの具体像が見え期待が高まった結果だが、対応を誤れば工数増・遅延は必至だった。
　対策として全要求を変更管理プロセスに乗せ、開発チームが定量的な影響分析（追加工数、遅延リスク等）を実施した。この客観的データをＣＣＢで提示し、全要求受け入れ時の影響を説明した結果、影響が許容範囲内の一部のＵＩ変更は受入れ、影響大のものは次期改修という合意に至った。ＣＣＢでの審議は、制約条件厳守を最優先としつつ、ステークホルダー満足度維持とモチベーション低下を防ぐ落としどころを見つける意図があった。

３．４．施策の評価と今後の教訓

　変更管理プロセスの厳格な運用と影響分析の徹底は、工数コントロールに最も重要な役割を果たした。影響分析によりステークホルダーは変更コスト・リスクを認識し安易な要求を抑制し、開発チームは安定して作業でき生産性の維持に繋がった。進捗管理では週次会議で課題共有し早期対策に努めた。例えばスマホアプリ開発の遅延兆候には、技術サポート追加等で早期対処できた。これも変更管理で計画の揺らぎが抑えられたため、個別課題に集中できた結果と評価する。
　結果、納期内に予算超過５％未満で完了、厳格な変更管理が機能した成果と判断する。
　教訓として、初期の期待値調整、特にスコープの認識合わせの重要性を再認識した。要件定義初期にユースケース等で「作る／作らない」を徹底共有し合意形成することが、変更要求削減とプロジェクト安定化に極めて有効と考える。

（１１９５文字）

まとめ

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

参考図書

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

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