- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題の原本はIPAにてご確認ください。
問題文
問1 システム開発プロジェクトにおけるコスト超過の防止について
プロジェクトマネージャ(PM)には、プロジェクトの計画時に、活動別に必要なコストを積算し、リスクに備えた予備費などを特定してプロジェクト全体の予算を作成し、承認された予算内でプロジェクトを完了することが求められる。
プロジェクトの実行中は、一定期間内に投入したコストを期間別に展開した予算であるコストベースラインと比較しながら、大局的に、また、活動別に詳細に分析し、プロジェクトの完了時までの総コストを予測する。コスト超過が予測される場合、原因を分析して対応策を実施したり、必要に応じて予備費を使用したりするなどして、コストの管理を実施する。
しかし、このようなコストの管理を通じてコスト超過が予測される前に、例えば、会議での発言内容やメンバの報告内容などから、コスト超過につながると懸念される兆候をPMとしての知識や経験に基づいて察知することがある。PMはこのような兆候を察知した場合、兆候の原因を分析し、コスト超過を防止する対策を立案、実施する必要がある。
あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴とコストの管理の概要について、800字以内で述べよ。
設問イ
設問アで述べたプロジェクトの実行中、コストの管理を通じてコスト超過が予測される前に、PMとしての知識や経験に基づいて察知した、コスト超過につながると懸念した兆候はどのようなものか。コスト超過につながると懸念した根拠は何か。また、兆候の原因と立案したコスト超過を防止する対策は何か。800字以上1,600字以内で具体的に述べよ。
設問ウ
設問イで述べた対策の実施状況、対策の評価、及び今後の改善点について、600字以上1,200字以内で具体的に述べよ。
解答例
設問ア
1.プロジェクト概要とコスト管理の概要
1.1.プロジェクト概要
私がPMを担当したプロジェクトは、A銀行のオンラインバンキングシステム機能追加開発である。目的は、新たな認証方式導入やアプリ連携強化による顧客利便性向上であった。プロジェクト期間は10ヶ月、予算は1億円であった。
1.2.プロジェクトの特徴
1)技術的な特徴
本プロジェクトでは、当行初の試みとしてマイクロサービスアーキテクチャを採用した。また、既存の勘定系システム等、複数システムとの連携が不可欠であり、その仕様調整やテストが複雑であった。
2)体制的な特徴
開発体制は、自社メンバーと協力会社メンバーの混成チームであった。マイクロサービス開発経験者は一部に限られ、メンバーのスキルレベルにばらつきがあり、認識合わせが課題となる可能性があった。
1.3.コストの管理の概要
1)計画時のコスト積算方法
コスト計画は、WBSに基づきボトムアップ方式で積算した。不確実性の高い部分にはリスクを考慮し、コンティンジェンシー予備費として総コストの10%を計上し、承認を得た。
2)実行中のコスト管理方法
EVMを導入し、月次でコスト効率(CPI)やスケジュール効率(SPI)を測定・把握した。完了時総コスト予測(EAC)と共に定例報告会でステークホルダーに報告し、透明性を確保した。
3)コスト管理上の課題認識
計画段階から、新技術、連携複雑性、スキルばらつきといった特徴がコスト超過リスクを高める考えた。そのため、EVMによる定量監視に加え、メンバーの発言等の定性情報にも注意し、早期にリスク兆候を捉えるべきと判断した。
(725文字)
設問イ
2.コスト超過の兆候と対策
2.1.コスト超過の兆候とそう考えた根拠
プロジェクト開始3ヶ月後、EVM上の数値に大きな乖離はなかったが、以下のコスト超過の兆候があった。
1)特定メンバーの発言の変化
中心的メンバーA氏の進捗報告が、具体的でなく抽象的になった。詳細を質問しても回答が曖昧になる場面が増えた。これは、A氏が問題を抱え込み、報告を躊躇しているサインと考えた。
過去の類似プロジェクトで、メンバーが問題を抱え込み報告が曖昧になった結果、大幅なコスト超過と納期遅延を招いた事例があった。A氏の発言の変化は、この状況と酷似しており、放置すれば同様の事態を招くと判断した。
2)報告される課題の性質の変化
課題管理ツールに起票される課題が、当初はマイクロサービス開発内部の技術課題が多かったが、勘定系システムとの連携に関する仕様確認等の課題が急増した。これは、連携部分の作業が難航し、手戻りや遅延リスクの高まりを示していた。
外部システム連携の課題は、自チームだけでは解決できず、相手側の都合で時間を要することが多い。解決遅延は後続タスクの遅延や手待ちを発生させ、コスト超過に直結する。連携課題の急増と解決遅延は、このリスクが顕在化する証拠と考えた。
2.2.兆候の原因分析
1)スキルギャップとメンバーの抱え込み
A氏及び関連するメンバー数名と、個別に1on1形式でのヒアリングを実施した。心理的な安全性を確保し、プレッシャーを与えずに率直な意見や困りごとを聞き出すことを心掛けた。
その結果、「A氏は採用した特定フレームワークの実践経験が浅く、技術的障壁に直面していたが、プライドと責任感からスキル不足を認められず、長時間労働で解決しようとしていた」ことが判明した。これが進捗報告の曖昧さにつながっていた。
2)暗黙知化された連携仕様の存在
課題管理票に登録された連携関連の課題を再レビューし、ボトルネックとなっている箇所を特定した。さらに、ソースコード管理ツールのコミットログ・チーム内のチャットツールの履歴なども確認し、客観的な情報からも状況把握を試みた。
その結果、長年の運用で形成された暗黙のルールや特殊なデータ形式など、仕様書未記載の事項が、連携課題の増加と長期化の要因となっていたことが判明した。新規開発メンバーはこれを知らず、仕様書通り開発した結果、テスト段階で問題が発覚し手戻りが発生していた。
2.3.コスト超過の防止策
コスト超過リスクを抑制させるため、次の対策を講じた。
1)技術支援体制の強化
A氏の課題解決とスキル向上を支援するため、行内の経験豊富なエンジニアB氏に週2日、技術支援(レビュー、相談対応)を依頼した。具体的には、A氏とのペアプログラミング時間を設定し、課題解決を加速させ、スキル移転を促進した。これは内部リソース融通による工夫であり、追加コストを抑制する狙いがあった。
2)潜在的な連携仕様の洗い出しとドキュメント化
暗黙知による手戻りを防止するため、勘定系システムのベテラン担当者にヒアリングを実施した。洗い出した仕様書未記載のルールやノウハウを、情報共有基盤(Wiki)に記録・整理し、全員が参照可能とした。これにより、認識齟齬による手戻りを防止し、品質向上を図った。
これ以外にも、「合同課題検討会」開催や「デイリースタンドアップミーティング」導入も検討した。両施策とも有効性は認めたが、リソースを根本原因対策に集中させるため即時実施は見送った。合同検討会は仕様洗い出しの効果次第、デイリースタンドアップは既存の週次定例改善等で代替可能と判断した。
(1555文字)
設問ウ
3.対策の実施状況と評価、今後の改善点
3.1.対策の実施状況
1)技術支援体制の強化の実施
シニアエンジニアB氏による技術支援を開始した。A氏とのペアプログラミング等を通じて、A氏の技術課題解決が促進され、負荷が緩和された。
2)潜在的な連携仕様の洗い出しとドキュメント化の実施
ベテラン担当者へのヒアリングを実施し、約15項目の暗黙知を特定した。内容はWikiに記録・共有し、開発・テスト担当者が参照した。これにより認識齟齬と手戻りを抑制できた。
3.2.対策の評価
1)コスト超過の防止効果
低下傾向にあったCPIは目標通り回復し、最終コストは予算内に収まった。対策を講じなければ予算超過に至っていた可能性が高く、対策はコスト超過防止に貢献したと判断した。
2)品質確保への効果
連携仕様の認識齟齬が減少し、暗黙知が形式知化されたことで、テストフェーズでの連携起因の不具合が削減され、品質向上に寄与した。
3)納期遵守への効果
一時的な遅延はあったが、対策による課題解決の迅速化で最小限に食い止め、計画通りサービスインできた。
4)メンバーへの影響
A氏の負担が軽減され、他のメンバーも手戻りの不安なく作業を進められるようになった。ボトルネック解消でチームの停滞感が払拭され、モチベーション向上に繋がった。
上記定量的・定性的効果に加え、連携課題の平均解決日数が約50%短縮した。これは仕様明確化により質疑応答が効率化したためと考えられる。これらの状況変化から、実施した2つの対策は有効であったと評価した。
3.3.今後の改善点
今回の経験を踏まえ、今後の改善点として以下の3点を把握した。
1)プロジェクト計画段階でのリスク認識と対応計画の精度向上
新技術導入や外部連携に伴うリスク(スキルギャップ、暗黙知等)をより深く特定・評価し、単なる予備費計上だけでなく、具体的な予防策や対応策を計画に盛り込むべきである。特に人的スキル依存リスクへの対応を重視したい。
2)コミュニケーション計画の早期具体化と能動的な実行
関係者間のコミュニケーション計画を早期に具体化・合意形成し、PMが主体的に実行・レビューし、形骸化を防ぐ必要がある。特に混成チームではツール利用ルール等の明確化が重要である。
3)コスト超過の兆候監視の仕組み化とチームへの意識付け
PMの経験則だけに依存せず、定例報告でのチェック項目追加やEVM指標変動へのアラート等、客観的・早期に兆候を捉える仕組みを検討したい。また、コスト意識と早期の課題共有の重要性をチームに浸透させ、心理的安全性の高い文化醸成に努めたい。
(1141文字)
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント