- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題の原本はIPAにてご確認ください。
問題文
問1 プロジェクトマネジメント計画の修整(テーラリング)について
システム開発プロジェクトでは、プロジェクトの目標を達成するために、時間、コスト、品質以外に、リスク、スコープ、ステークホルダ、プロジェクトチーム、コミュニケーションなどもプロジェクトマネジメントの対象として重要である。プロジェクトマネジメント計画を作成するに当たっては、これらの対象に関するマネジメントの方法としてマネジメントの役割、責任、組織、プロセスなどを定義する必要がある。
その際に、マネジメントの方法として定められた標準や過去に経験した事例を参照することは、プロジェクトマネジメント計画を作成する上で、効率が良くまた効果的である。しかし、個々のプロジェクトには、プロジェクトを取り巻く環境、スコープ定義の精度、ステークホルダの関与度や影響度、プロジェクトチームの成熟度やチームメンバーの構成、コミュニケーションの手段や頻度などに関して独自性がある。
システム開発プロジェクトを適切にマネジメントするためには、参照したマネジメントの方法を、個々のプロジェクトの独自性を考慮して修整し、プロジェクトマネジメント計画を作成することが求められる。
さらに、修整したマネジメントの方法の実行に際しては、修整の有効性をモニタリングし、その結果を評価して、必要に応じて対応する。
あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトの目標、その目標を達成するために、時間、コスト、品質以外に重要と考えたプロジェクトマネジメントの対象、及び重要と考えた理由について、800字以内で述べよ。
設問イ
設問アで述べたプロジェクトマネジメントの対象のうち、マネジメントの方法を修整したものは何か。修整が必要と判断した理由、及び修整した内容について、800字以上1,600字以内で具体的に述べよ。
設問ウ
設問イで述べた修整したマネジメントの方法の実行に際して、修整の有効性をどのようにモニタリングしたか。モニタリングの結果とその評価、必要に応じて行った対応について、600字以上1,200字以内で具体的に述べよ。
解答例
設問ア
1.プロジェクト概要と重要視したマネジメント対象
1.1.プロジェクトの目標と概要
私が担当したプロジェクトは、大規模な基幹業務システムのリプレースである。約2年間かけ、老朽化した現行システムを刷新し、新機能を導入することを目標とした。目標は運用保守コスト年間約20%削減と、主要業務処理時間平均約15%短縮であった。チームは社内開発・利用部門、外部パートナーで構成されたが、要員追加は困難で人的リソースに制約があった。システムは多様な業務を持つ複数部門が利用し、要求や利害が複雑に絡む可能性が高かった。また、全社的なITリテラシにばらつきがあり、システム理解度や関与度に差があった。
1.2.重要視したプロジェクトマネジメントの対象と理由
時間、コスト、品質に加え、特に重要と考えた対象は「ステークホルダマネジメント」であり、中でも「コミュニケーションと関与度」の管理であった。重要と考えた理由は以下の通りである。
1)部門間の認識齟齬の解消
複数部門の要求調整やコンフリクト解消が重要だが、標準的な会議体では潜在的な懸念や認識齟齬を把握・解消しきれない。
2)ITリテラシの底上げ
利用者ITリテラシにばらつきがあるため、システム仕様や変更点を分かりやすく伝え、共通理解を促す丁寧なコミュニケーションが不可欠である。
3)利用部門の積極的な参加
プロジェクト成否は要件定義での正確な要求収集と利用部門による受け入れテスト(UAT)への積極的な関与にかかるが、日常業務で多忙な利用部門にいかに主体的に関わってもらうかが課題となる。
これらの課題に対処し、ステークホルダとの関係を築き、積極的な関与を促すことが、手戻り防止、仕様変更リスク低減、納期遵守と品質確保に繋がると判断し、ステークホルダマネジメントを最重要視した。
(788文字)
設問イ
2.ステークホルダマネジメントの修整とその内容
2.1.修整が必要と判断した理由
前述の通り、本プロジェクトは複数利用部門とITリテラシのばらつきという特性を持っていた。標準的なステークホルダマネジメント(計画説明会、定例報告会、議事録配布、個別ヒアリング)だけでは、以下のような深刻なリスクを回避できないと判断し、修整が必要と考えた。
1)大規模な手戻りや変更要求
利用者ITリテラシにばらつきがあるため、標準的な説明ではシステム仕様や業務影響の正確な理解が得られにくい。専門用語多用の資料や開発プロセスの説明はIT不慣れな利用者には難しく、疑問や不安が表面化しにくい。これは、要件定義や設計段階で要求の曖昧さが残り、後工程での手戻りや仕様変更多発を招くリスクを高めた。
2)重大な品質問題の発生
利用部門担当者は定常業務で多忙であり、標準的な依頼だけでは仕様確認やUATに十分な時間を割いてもらえない。UATは品質確保に必須だが、関与が得られないと形骸化や遅延リスクがあり、潜在的問題が見過ごされ本番稼働後の重大な業務停止やデータ破損に繋がる可能性があった。
これらの状況は、厳しい納期と限られた開発予算という制約下で、プロジェクト目標達成を極めて困難にする。手戻りや品質問題はコスト超過と納期遅延に直結するため、標準方法ではなく、プロジェクト特性に合わせた積極的・丁寧なマネジメントへの修整が必須と判断した。特に、初期フェーズでのステークホルダ理解・関与を徹底し、後工程のリスクを減らし全体最適を目指すことが重要と考えた。
2.2.修整した内容
修整の必要性に基づき、コミュニケーション多様化と関与度向上の施策を具体的に実行した。
1)コミュニケーション方法の多様化と頻度増加
定例報告会に加え、部門の業務・ITリテラシに合わせた「部門別・階層別ワークショップ」を週1回程度実施。ここでは、技術説明より各部門業務への適合や操作に焦点を当てた。資料は専門用語を避け、画面イメージや図を多用してイメージしやすい工夫を行った。また、少人数制やブレイクアウトルームで質問しやすい雰囲気を作る、「プロトタイプを用いたシステム操作デモ」を隔週実施するなど、具体的な利用イメージと早期フィードバックを促進した。さらに、複雑な要求や部門間認識差は「個別説明会」で関係者を集め合意形成を図った。
2)ステークホルダ関与度向上のための工夫
利用部門から「部門内キーパーソン」を2~3名選定し、早期に集中的な「研修プログラム」(2週間)を実施。キーパーソンが自部門内での一次対応、情報展開、UATサポートを担えるように育成した。キーパーソンを研修プログラムに参加させることで、利用部門に一時的な負荷増が見込まれたが、部門自身の業務効率化・理解度向上に繋がるメリットを説明して理解を求めた。さらに利用部門の部門長からも、現場メンバーにプロジェクトの重要性を説明してもらい、さらなる理解を求めた。
3)経営資源配分
要件定義~UAT準備といった初期・中盤工程にこれらリソースを、当初よりも5%分追加して配分することにした。これは、初期段階でステークホルダ理解と仕様確定精度を高める目的があった。当初計画での、後工程(開発、テスト、移行)での大規模な手戻りコストを、15%増と試算したため、リソース追加は全体を通して効率的な配分であるとと考えた。
(1449文字)
設問ウ
3.ステークホルダマネジメントのモニタリングと評価
3.1.モニタリング方法
修整したステークホルダマネジメントの有効性を把握するため、以下の方法でモニタリングした。
1)問い合わせ内容の分析
プロジェクト専用問い合わせ窓口への「件数・内容」を週次で集計・分析した。利用者の疑問や懸念が集中する箇所、内容の変化(仕様→操作)を把握。件数の多い項目はパレート図で可視化し、理解不足箇所の特定に活用した。その結果は、その後のワークショップに反映した。
2)アンケート実施
ワークショップ等の終了後、参加者に「システム理解度・満足度、懸念事項」に関する簡単なアンケートを実施した。回答率、理解度・満足度の推移を追跡し、施策効果を定量評価した。理解度が低い参加者や特定の懸念を挙げた参加者には、個別にフォローアップを実施した。
3)UATでの課題分析
UATフェーズでは、「進捗率と課題発生状況」を日次で追跡し、進捗、発生課題の件数・内容・重要度・解決状況から傾向を分析した。課題は管理ツールに記録し、重要度の高い課題については、関係者を集めた緊急会議で迅速な解決策を協議した。
3.2.モニタリング結果と評価
上記のモニタリングの結果、修整したステークホルダマネジメント方法は概ね有効に機能した。
1)モニタリングの結果
初期の仕様問い合わせはワークショップ等で減少し、後半は操作質問中心になった。問い合わせ分析で頻出箇所特定により、活動焦点を絞れた。アンケートでワークショップ等の理解促進・満足度向上を確認した。キーパーソンが自部門理解促進・一次解決に貢献し、問い合わせ集中を防いだ。UATは計画通り完了した。課題は想定範囲で少なく軽微なものが中心だった。これは手戻り抑制、早期理解、迅速課題解決体制の効果であった。
2)評価
修整(コミュニケーション多様化、キーパーソン育成等)は、ステークホルダ理解と関与度向上に効果的だった。懸念された手戻りやUAT不備による品質問題といった、コスト超過・遅延に直結する重大リスクを大幅に低減できた。限られた予算・人的リソース制約下での初期フェーズ重点投入は、後工程リスク回避に繋がり、全体コスト・納期遵守に対し費用対効果が高かった。
3)必要に応じて行った対応
モニタリング結果に基づき迅速に対応した。具体的には、理解不足箇所や懸念項目はFAQ更新・拡充、追加ワークショップで再説明したり、UAT重要課題は緊急会議で原因究明・迅速に対応した。特定の部門UAT遅延時は、キーパーソンと連携し、原因特定、計画見直し、追加支援を実施することにした。
本プロジェクトでの経験は、テーラリング、モニタリング、迅速対応の重要性を再認識させ、今後のノウハウとなった。
(1186文字)
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント