- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題の原本はIPAにてご確認ください。
問題文
問2 システム開発プロジェクトにおけるトレードオフの解消について
プロジェクトマネージャには、プロジェクトの遂行中に発生する様々な問題を解決することによって、プロジェクト目標を達成することが求められる。
プロジェクトの制約条件としては、納期、予算、要員などがある。プロジェクトの遂行中に発生する問題の中には、解決に際し、複数の制約条件を同時に満足させることができない場合がある。このように、一つの制約条件を満足させようとすると、別の制約条件を満足させられない状態をトレードオフと呼ぶ。
プロジェクトの遂行中に、例えば、プロジェクトの納期を守れなくなる問題が発生したとき、この問題の解決に際し、制約条件である納期を満足させようとすれば予算超過となり、もう一つの制約条件である予算を満足させようとすれば納期遅延となる場合、納期と予算のトレードオフとなる。この場合、制約条件である納期と予算について分析したり、その他の条件も考慮に入れたりしながら調整し、トレードオフになった納期と予算が同時に受け入れられる状態を探すこと、すなわちトレードオフを解消することが必要になる。
あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトにおけるプロジェクトの概要とプロジェクトの制約条件について、800字以内で述べよ。
設問イ
設問アで述べたプロジェクトの遂行中に発生した問題の中で、トレードオフの解消が必要になった問題とそのトレードオフはどのようなものであったか。また、このトレードオフをどのように解消したかについて、工夫した点を含めて、800字以上1,600字以内で具体的に述べよ。
設問ウ
設問イのトレードオフの解消策に対する評価、残された問題、その解決方針について、600字以上1,200字以内で具体的に述べよ。
解答例
設問ア
1.プロジェクトの概要と制約条件
1.1.プロジェクトの概要
私がプロジェクトマネージャとして参画したプロジェクトは、中堅製造業A社における基幹業務システム再構築である。目的は、現行システムの老朽化対応、業務プロセスの標準化・効率化、経営判断の迅速化にあった。主要業務領域を対象とし、ERPパッケージをベースにアドオン開発を行った。期間は18ヶ月、予算3億円。体制は社内外の関係者から成る数十名規模であった。
背景には、現行システムのブラックボックス化による障害対応の遅れ、環境変化に対応できないという問題があった。特に競合のDX推進に対し、A社の対応遅れは深刻な経営リスクとなっていた。
目標は、月次決算処理の3営業日への短縮や在庫回転率10%向上など、業務効率化と経営判断迅速化による競争力強化であった。
1.2.プロジェクトの制約条件
本プロジェクト遂行上、特に厳守すべき以下の制約があった。
1)納期
システム本稼働日は、18ヶ月後の4月1日と厳格に定められていた。これはA社の会計年度開始日に合わせたもので、遅延は決算業務や中期経営計画に深刻な影響を与えるため、経営トップから絶対厳守を強く指示されていた。この納期は全期間を通じ、あらゆる意思決定の最優先事項となった。
2)予算
総予算3億円は過去最大規模のIT投資で、取締役会承認の上限額であり追加予算は原則不可能とされていた。予算超過はプロジェクト評価を著しく低下させ、経営層の信頼を損ないかねないため、予算枠内での完遂が納期達成と並び強く求められた。
加えて、要員に関する制約も留意点だった。社内メンバーは兼務が多く、ERP導入経験者不足という課題を抱え、外部ベンダー依存度が高まるものの、有能な専門人材の獲得は困難だった。これは計画時のリスク要因と認識していた。
(793文字)
設問イ
2.トレードオフの解消が必要になった問題とその解消策
2.1.発生した問題と直面したトレードオフ
プロジェクト開始13ヶ月後の結合テスト直前、生産管理モジュールで深刻な品質問題が顕在化した。A社特有の複雑な生産計画ロジックのアドオン開発部分で、データ連携不整合や性能劣化が多発した。要件定義の曖昧さ、ベンダー側の業務理解不足、テスト不足が原因はだった。
このままではテストが遅延し、最終納期に間に合わなくなる事態となるため、納期遵守と品質確保(要求機能の完全実現)という、深刻なトレードオフの解消が必要だった。
1)納期遵守を優先する場合
問題機能のフェーズ2対応(スコープ縮小)案は、製造部門の目標未達となるため現場が反発するリスクがあった。テスト簡略化案は、品質低下による本稼働後の業務停止リスクがあり許容できなかった。これらは予算超過は抑制できても根本的成功に繋がらないと判断した。
2)品質確保を優先する場合
納期延長は経営トップの厳命違反でプロジェクト失敗を意味し、追加リソース投入による予算超過も必至だった。
納期と品質はトレードオフ状態にあり、予算制約も考慮しつつ、全ステークホルダーに受入れ可能なバランス点を見出すことが最重要課題であった。
2.2.トレードオフの解消策
直ちに問題対策チームを招集し、なぜなぜ分析等で原因特定と影響評価を行い、解消策を立案・実行した。この初期対応においては、プロジェクト全体で一丸となって問題解決にあたるための工夫として、全関係者へ迅速かつ透明性の高い情報共有を行い、危機意識を共有することを徹底した。
1)生産計画ロジックの段階的リリースと業務運用による補完
納期遵守を最優先しつつ、稼働時の業務影響を最小化し、中長期的に品質と機能充足を目指す現実的折衷案と判断した。製造部門との合意形成を円滑に進める工夫として、PM自ら製造部門へ足を運び、現状と対策案を誠実に説明し意見を傾聴した上で、パレート図を用いて機能の利用頻度と業務インパクトをデータに基づき客観的に分析するようにした。日々の生産指示に必須のコア機能(MRP計算、確定オーダー引当等)を最優先で4月1日にリリース、高度な最適化ロジックや一部レポートは稼働後3ヶ月以内に追加リリースする段階的アプローチを採用した。この段階的リリース案と追加リリースまでの暫定運用については、業務部門の理解と協力を得るための工夫として、現状のリスクや納期遵守の重要性を丁寧に説明し、ステークホルダーの期待値を調整することで、最終的に合意形成に至った。
2)プライムベンダーとの協力体制再構築によるリソース最適化と品質向上
予算超過を最小限に抑え、品質問題の根本解決と納期内作業完了を目指すため、ベンダーとのパートナーシップに基づく協力体制が不可欠と判断した。ベンダー責任者と経営層に対し、客観的な交渉を進める工夫として、不具合データ等の具体的なデータを示し品質問題の原因一端がベンダー側にもあると指摘、パートナーとしての協力を強く要請した。結果、ベンダーは生産管理モジュールに精通したシニアエンジニア2名を費用を抑える形で追加投入し、既存開発チームの管理強化に合意。A社側も受入テスト要員増強や仕様確認迅速化を約束した。この交渉過程においても、建設的な議論と合意形成を促進するための工夫として、隠蔽せず透明性の高い情報共有を継続し、データに基づく判断を提示することを心掛けた。
なお、これらの解消策以外に「開発要員追加案」「品質基準引き下げ案」も検討対象に挙がったが、前者コスト効果が見込めず、後者は業務影響が甚大と判断し見送った。
(1554文字)
設問ウ
3.解消策の評価と残された問題の対応
3.1.解消策の評価
解消策はプロジェクト目標達成に貢献し、総じて有効だったと評価する。
定量的には、納期通りに本稼働を達成、生産管理高度ロジックも計画内(2.5ヶ月)で追加リリースし、コスト超過も約1.7%に抑制、経営層の評価を得た。定性的には、製造部門は混乱なく新システムへ移行し業務効率化を実感、経営層からは納期遵守とPMの解決能力、特に丁寧な説明と合意形成が高く評価され、ベンダーとの信頼も強化された。
早期の問題特定と、データに基づく分析により、ステークホルダーとの合意形成ができたことが、成功要因と考える。
一方、要件定義時のリスク評価の強化、業務理解不足解消によるが手戻りの予防は、今後の改善課題である。
3.2.残された問題と解決方針
トレードオフ解消策の結果、アドオン開発部分のドキュメント不備と保守ナレッジの属人化という、新たな問題が顕在化した。納期・品質確保を最優先したためドキュメンテーション作業が後回しとなり、保守に必要な技術情報が一部担当者に偏在するリスクが生じた。これは保守性の面での課題であり、放置すればシステム改修コスト増大や、障害対応遅延といったリスクを抱えることになる。
このドキュメント不備と属人化リスクに対し、システムの安定稼働を見据え、以下の方針で解決を図った。特に、ドキュメント整備を重点対応とした。
1)ドキュメント整備
プロジェクト完了後の1ヶ月を「ドキュメント整備期間」とし、情報システム部主体でベンダー協力のもと、アドオン部分の主要設計書や運用手順書等、保守運用に必要な情報を網羅的に整備した。標準テンプレートで作成・更新後、複数回のレビューで品質を担保した。これにより属人化リスク低減、改修コスト抑制等を目指した。ドキュメントの品質向上は、TCO削減に不可欠のため、最優先に取り組んだ。
2)ベンダーとの連携強化と社内体制構築
中長期的な対策として、保守契約にナレッジの定期的社内移管(詳細設計説明会等)を盛り込むことを、ベンダーに提案した。社内では、移管情報に基づき勉強会等で、複数担当者のスキル習得を目指し、ベンダー依存度低減と事業変化への柔軟な対応力確保を目指した。
今回得られた教訓は「トレードオフ解消では、制約条件のバランスを取ることが求められるが、その過程で影響を受ける要素(例えば、ドキュメント品質や保守性)にも目を配り、リスク対策を講じる必要がある」ということである。今回の場合は、納期と主要機能品質を優先した結果生じる保守性の課題に対し、プロジェクト完了後の活動として明確に計画することが重要であった。今後のプロジェクトでは、リスク管理の範囲をより広げ、プロジェクトライフサイクル全体の改善に繋げたい。
(1197文字)
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント