- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
解答例
設問ア
１．プロジェクトの概要と直面した問題
１．１．プロジェクトの概要とチームが抱えていた課題
私が担当したプロジェクトは、ある製造業の基幹システム老朽化対応で、在庫管理機能を汎用機のＣＯＢＯＬからオープン系のＪａｖａへ移行する内容であった。私はプロジェクトマネージャ（ＰＭ）として本プロジェクトに発足時から参画した。
チームの構成は、現行システムの仕様に精通するベテラン技術者２名と、Ｊａｖａ開発経験が豊富な中堅・若手技術者５名の計７名である。この体制には、現行システムの仕様、特に文書化が不十分な業務ロジックの知識が特定のベテラン要員に集中している課題があった。過去の度重なる仕様変更が、納期優先で場当たり的に行われ、ドキュメントの更新が後回しにされてきた経緯がある。これは担当者の不在が即、業務停滞に繋がる典型的な属人化リスクであり、当初から懸念事項として認識していた。
１．２．発生した複合的な問題とその影響分析
プロジェクト開始６ヶ月後、二つの予期せぬ外部環境の変化が発生した。一つは、属人化リスクの中心であったベテラン技術者のうち１名が、家庭の事情で急遽退職したことである。もう一つは、主要顧客の事業計画変更に伴い、当初１８ヶ月の開発期間を３ヶ月短縮するよう経営層から強い要求を受けたことである。
私はこの二つの変化に対し、その問題の性質が根本的に異なると判断し、影響の大きさと対応の緊急度で評価した。「担当者固有のノウハウ喪失」は、対策を講じなければ確実に品質低下に繋がる内部の問題である。一方、「納期短縮要求」は、交渉によって解決策を模索できる外部との調整の問題である。この性質の違いから、まずはコントロール可能で緊急度の高い、内部の問題解決に最優先で着手した。開発チームを立て直すことが、あらゆる外部交渉の前提となると判断したからである。
（７８４文字）
設問イ
２．悪化したチーム状態の改善に向けたリーダーシップの選択と行動
２．１．外部環境の変化によって悪化したプロジェクトチームの状態
ベテラン技術者の退職と納期短縮要求の結果、プロジェクトチームの状態は深刻に悪化した。まず、現行システムの解析作業が、残された１名のベテランメンバーに集中してボトルネック状態に陥り、全体の進捗が停滞した。
次に、チームの士気が著しく低下した。中堅・若手メンバーは、自身の持つＪａｖａスキルでは目の前のＣＯＢＯＬ解析に貢献できず、「貢献したい」という高い意欲を持ちながら、具体的な行動に移せないことへの無力感を個人面談で口にした。週次の進捗会議では、責任の所在を巡って非難めいた発言が交わされ、活発な議論は失われた。チーム内の心理的安全性は損なわれ、協力体制の連携が著しく損なわれていた。
２．２．把握した個々のメンバーの状況とリーダーシップ方針の決定
この状況を打開するため、私はメンバーの業務遂行能力と意欲の組み合わせによって、自身の関与の仕方を変える方針を立てた。
１）過負荷状態のベテランメンバー
個人面談を通じ、本人が強い責任感から問題を一人で抱え込み、精神的・肉体的に疲弊していると把握した。どの作業から手をつけるべきか判断できず、思考が停止しかけている様子であった。このままでは本人の健康問題だけでなく、プロジェクトが深刻な停滞に陥る懸念があったため、トップダウンで明確な方向性を示す「指示的リーダーシップ」を選択した。
２）不安を抱える中堅・若手メンバー
個人面談において、彼らがプロジェクトへの強い貢献意欲を示す一方で、「ＣＯＢＯＬの知識がないため、どう手伝えばよいか分からない」と、行動に移れないことへの不安を表明していると把握した。高い貢献意欲がありながら行動手段を欠く状態が、彼らの無力感と士気の低下に繋がっていると判断し、具体的な作業機会と、それを円滑に進めるための支援を提供することが不可欠と考え、「支援的リーダーシップ」及び「参加型リーダーシップ」を選択した。
２．３．方針に基づく具体的な行動とステークホルダーとの調整
私は選択したリーダーシップに基づき、具体的な行動を段階的に実施した。
１）初期対応
まず、疲弊しているベテランに対し、彼の責任範囲と明確に定めた上で、事業影響度が最も高い「リアルタイム在庫照会」「棚卸し差分更新」「出荷指示データ連携」の３機能に絞って作業するよう指示をした。
２）チーム再建
次に、チーム全体の課題解決のため、「ペアプログラミング制度」の導入を提案した。当初、外部専門家を一時的に活用することも検討したが、当社の特殊な業務知識の習得に時間を要し、即戦力にはなり得ないと判断したため、この案は採用しなかった。「ただでさえ時間がないのに、二人がかりの作業は非効率だ」との反対意見が出たが、類似プロジェクトのデータを基に試算した生産性の情報を提示し、また影響範囲の小さい「商品マスタ参照機能」の開発で試行し、効果を実証することで合意にこぎつけた。この際、ペア作業に伴う新たなリスクとして、メンバー間の相性問題も想定し、いつでも相談できるよう、私との週１回の個別面談を制度に組み込むことで、メンバーの不安を軽減した。
３）外部との調整
並行して、納期短縮要求に対しては、私が作成した影響分析の結果を経営層に報告した。その資料には、「このままでは進捗が最大で２ヶ月遅延する見込みであること」「チーム再建策を実施すれば遅延は１ヶ月に圧縮できる可能性があること」「しかし、それ以上の短縮は品質を著しく損なうリスクがあること」を定量的に記述した。この報告を基に、チーム再建策の実施を条件に、１ヶ月の猶予期間を確保することで正式に合意した。
（１５８３文字）
設問ウ
３．リーダーシップ発揮後の成果と評価
３．１．改善したプロジェクトチームの状態
リーダーシップを発揮した結果、プロジェクトチームの状態は大幅に改善した。
定量的には、導入したペアプログラミング制度により、週次で計測していた解析済みのファンクションポイント数が導入前の平均１．５倍に向上し、遅延していたスケジュールが回復軌道に乗った。
定性的には、チーム内の雰囲気が大きく改善し、若手からベテランへ仕様の意図を問う質問が活発に出るようになった。しかし、試行導入したペアの一つで、生産性が上がらない問題が発生した。ペア双方の週次報告書で成果の記述が少なく、進捗が形式的であったことから問題を察知した。個別の面談を行った結果、技術的なスキル差から若手側が遠慮し、ベテラン側もどう教えてよいか戸惑っていることが原因だと判断した。そこで私が仲介し、ペアの役割を「コードを書く人」と「横で助言・レビューする人」として明確化することで、関係が改善し、生産性が向上した。
３．２．プロジェクトへの貢献と今後の改善点
チームの生産性向上は、外部環境の変化への対応においても大きな力となった。１ヶ月後、私は経営層と再交渉の場を設け、以下の二点を提示した。第一に、生産性が１．５倍に向上した実績データを基に、現実的に達成可能な納期は「当初計画の１ヶ月前倒し」であること。第二に、これ以上の短縮は、文書化不足という品質リスクを顕在化させ、長期的な保守コストの増大を招くこと。その上で、最重要機能である「リアルタイム在庫照会」と「出荷指示データ連携」を１ヶ月前倒しで先行リリースし、残りの「棚卸し関連機能」は当初納期通りとする分割納入案を提示した。
この提案に対し、営業部門の担当役員から「一部の機能だけでは、現場の業務プロセスが分断されて混乱する」という強い懸念が示された。私はその懸念に同意を示した上で、「新製品の販売戦略に不可欠な在庫照会機能を先行リリースして、機会損失という事業リスクを回避する」「残りの機能は、現行プロセスを１ヶ月だけ維持すれば、業務影響は最小化できる」と、事業継続の観点でのメリットを示し、最終的に全部門の理解を得るに至った。
今回の対応には、文書化を促す明確なプロセスや動機付けが、仕組みとして組み込まれていなかったという反省点もある。
この経験から、私は二つの改善策を所属組織に提案し、標準化を進めている。一つは、計画段階で「スキルマップ」を用い、属人化リスクを定量的に評価し、対策を具体化しておくプロセス。もう一つは、今回のような問題解決の経験を組織知として蓄積するため、プロジェクト横断の事例共有会を定期開催する仕組みの構築である。この共有会では、単なる成功事例だけでなく、失敗事例とその原因分析も共有することで、組織全体の学習効果を高めることを狙いとしている。
（１１９８文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント