- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
解答例
設問ア
１．プロジェクト概要と外部環境の変化
１．１．プロジェクト概要とチーム特性
私が担当したプロジェクトは、金融機関のシステム移行に伴う、約１千万件のデータの大規模移行プロジェクトである。私はプロジェクトマネージャ（ＰＭ）として本プロジェクトを統括した。顧客業務部門、データ移行専門のＡ社、新システム開発のＣ社から成る混成チームであり、Ａ社とＣ社の間では、開発文化が違いによって、日常的に小さな意見の対立が発生していた。また、このプロジェクトは、システムの保守切れや法規制の関係で、システムの稼働日を延期できないという制約があった。
１．２．想定外の外部環境の変化
プロジェクト開始時のリスク分析にて、「監督官庁によるガイドライン変更」のリスク対策として、小規模な手戻りを想定したバッファ要員２名・１か月を用意していた。しかし、終盤に発表された新ガイドラインの内容は、この想定を遥かに超えていた。具体的には、「参照権限に応じた動的なマスキング」という高度な要件が明記された。これは、既存の仕組みでは対応できず、全く新しい機能実装が必要になる事態だった。
１．３．プロジェクト活動の阻害要因
この新機能の要求が、プロジェクトの活動を阻害すると判断した。理由は以下の二点である。
１）対応計画を大幅に超過する工数
新機能の実装に必要な追加工数は、約５０人月と試算され、当初確保していた約２人月のバッファでは明らかに吸収できない規模だった。
２）責任分界点の未定義と、それに伴う意思決定の停滞
新機能はＡ社とＣ社の責任分界点の境界領域にあり、どちらが開発の主導権を握るのか契約上定義されていなかった。この責任の曖昧さが両社の対立を顕在化させ、定例会は責任範囲と費用負担に関する議論に終始し、技術的な意思決定が停滞する事態を招いた。この進捗の停滞を、最大の懸念事項と判断した。
（７９８文字）
設問イ
２．プロジェクトチームの状況悪化とその対策
２．１．悪化したプロジェクトチームの状態
大規模な仕様変更は、チームの状態を三つの側面から悪化させた。第一に「対立」である。これは、定例会議の議事録に記録された、Ａ社とＣ社のリーダーによる責任範囲を巡る否定的な発言の応酬から判断した。第二に「疲弊」である。顧客リーダーであるＤ氏からの時間外労働の増加報告と、勤怠記録上の高稼働状態から判断した。第三に「品質低下」である。若手技術者のＥ氏が担当したプログラムにおいて、単体テスト工程での不具合検出件数が増加傾向にあることを、品質管理指標から把握した。
２．２．状況に応じたリーダーシップの選択と行動
１）対立するベンダーリーダーへの対応
当初、私は過去の類似プロジェクトの経験から、こうした問題は担当ベンダーの技術力で解決できるという思い込みがあり、原因の早期特定と指示による迅速な解決が最善策と判断した。しかし、緊急会議の場で私が「原因はＣ社のデータ設計にある」と判断し、Ｃ社に修正を指示したところ、予期せぬ反発を招いた。Ｃ社だけでなく、修正作業の大部分を担うことになるＡ社からも、「責任の所在が不明確な段階で、一方的に作業負担の増加を強いることは認められない」という強い反発があり、関係をさらに悪化させる結果となった。この事実から、両社の反発が「技術的な解決ができる・できない」という趣旨ではなく、「なぜ我々がその責任や作業負担を負うのか」という、費用や契約に直結する責任範囲の観点によるものだと認識した。
この認識に基づき、トップダウンによるアプローチではなく、関係者から意見を引き出し、合意形成を促進する対話型リーダーシップを行った。私がファシリテータとなり、まず両者の懸念点を付箋に全て書き出させ、次にそれを収集した意見を類似性でグループ化し課題の構造を明らかにする手法（親和図法）で「技術課題」「責任分界点」「コミュニケーション」の３つに構造化した。このプロセスを通じ、彼らの課題認識を統一させ、最終的にＷＢＳを共同で作成することで、彼らの当事者意識と納得感を醸成することに成功した。これにより、チーム内の対立は解消され、プロジェクトは正常な意思決定プロセスを回復した。
２）他の主要メンバーへの個別対応
Ｄ氏とＥ氏に対しては、以下の個別対応を行った。
・Ｄ氏への支援的アプローチ
Ｄ氏については、高い専門能力を持つ一方、過大な負荷から業務遂行への意欲が低下している状態と見受けられた。このようなメンバーには、業務遂行を直接指示するのではなく、意欲を阻害している要因を取り除く支援が有効だと考えた。１ｏｎ１での対話を通じて彼の負荷が報告業務に集中していることを特定し、その作成を私が代行することを提案した。これにより、彼が本来の業務である業務仕様の再定義に集中できる環境を確保した。
・Ｅ氏へのコーチング的アプローチ
Ｅ氏については、今回の複雑な修正タスクに対する経験が浅く、品質低下が自信の喪失につながっていると判断した。このようなメンバーには、具体的な指示を与えつつ、精神的な支援も行うアプローチが有効と考えた。タスクを細分化して具体的な手順書を作成すると共に、彼の不安の根源が「自分の修正が他に影響を及ぼすことへの懸念」であることを対話で引き出し、ペアプログラミングと手厚いレビュー体制を約束することで、彼の技術的な不安を取り除き、品質の安定化を図った。
私がこれらの行動を使い分けたのは、画一的なアプローチが失敗を招いた最初の経験から、メンバーの状態を個別に見極めることの重要性を再認識したからである。客観的な事実に基づき、それぞれの状況に合わせた対応を行うことで、的確な介入が可能となった。
（１５７１文字）
設問ウ
３．プロジェクトの成果と得られた教訓
３．１．改善したプロジェクトチームの状態
複数のリーダーシップを適用した結果、チーム状態は著しく改善された。ベンダー間の対立は解消され、疲弊していたリーダーは本来のパフォーマンスを回復し、品質が低下していた若手も安定した成果を出せるようになった。何より、チームには当初の困難な状況を共に乗り越えたことで、健全な協力関係が醸成された。具体的に、それまでは個別に作業報告を行っていたＡ社とＣ社が、自発的に合同で日次の課題共有会を始めるなど、具体的な行動の変化が見られた。これはその後の困難なテストフェーズを遂行する上での、重要な基盤となった。
３．２．成果の評価と組織への展開
今回の仕様変更への対応から、以下の成果と教訓が得られた。
１）プロジェクト目標の達成と定量的・定性的評価
再結束したチームの尽力により、最終的なスケジュールの遅延は「７営業日」にまで圧縮できた。これを実現できた最大の要因は、私がステークホルダとの合意形成の末、「影響の少ない付随機能Ｘのリリースを次フェーズに延期する」というスコープ変更を決定したことである。当初、機能Ｘの所管である営業部門は強く反対したが、私は直接対話の場で、プロジェクトが頓挫した場合の事業機会損失額の試算データと、機能Ｘの具体的な代替運用案を提示した。この合意形成における重要な点は、私がプロジェクトの遅延リスクを自組織だけの問題とせず、営業部門の事業計画に対する「機会損失リスク」として定量的に提示し、リスクの当事者意識を共有したことである。これにより、交渉は単なる依頼ではなく、共通の事業課題に対する解決策の共同選択という形に変化した。品質面においても、本件に起因する重大な障害は発生しておらず、厳しい制約下でプロジェクトの主要目標は達成できたと評価している。
２）本経験からの教訓と組織標準への反映
一方で、今回の経験は私自身の課題も浮き彫りにした。当初の判断の誤りは、私のマネジメントの未熟さの表れであり、大きな反省点である。しかし、最大の教訓は、プロジェクト開始時のリスク分析において、ガイドライン変更の影響範囲を楽観視していたことにある。この失敗を形式知化し、今後のプロジェクトで繰り返さないことが私の責務だと考えた。その具体的なアクションとして、私は本件の事例を組織のナレッジベースに登録し、全社的なリスク管理プロセスの標準テンプレートに「外部規制の変更影響度評価マトリクス」を追加することをＰＭＯに提案し、採用された。このマトリクスは、「法的拘束力」「影響システム数」「代替手段の有無」「想定対応工数」の４軸で影響度を客観的に評価するものであり、組織全体のマネジメント能力向上に貢献できた点で、今回の対応は大きな価値があったと確信している。
（１１８３文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント