- 午後Ⅱ(小論文)でいつもつまづいている
- 小論文のネタを探している
- 合格者のアドバイスを受けたい
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題の原本はIPAにてご確認ください。
問題文
問1 システム開発プロジェクトにおけるプロジェクトチーム内の対立の解消について
プロジェクトマネージャ(PM)は、プロジェクトの目標の達成に向け継続的にプロジェクトチームをマネジメントし、プロジェクトを円滑に推進しなければならない。
プロジェクトの実行中には、作業の進め方をめぐって様々な意見や認識の相違がプロジェクトチーム内に生じることがある。チームで作業するからにはこれらの相違が発生することは避けられないが、これらの相違がなくならない状態が続くと、プロジェクトの円滑な推進にマイナスの影響を与えるような事態(以下、対立という)に発展することがある。
PMは、プロジェクトチームの意識を統一するための行動の基本原則を定め、メンバに周知し、遵守させる。プロジェクトの実行中に、プロジェクトチームの状況から対立の兆候を察知した場合、対立に発展しないように行動の基本原則に従うように促し、プロジェクトチーム内の関係を改善する。
しかし、行動の基本原則に従っていても意見や認識の相違が対立に発展してしまうことがある。その場合は、原因を分析して対立を解消するとともに、行動の基本原則を改善し、遵守を徹底させることによって、継続的にプロジェクトチームをマネジメントする必要がある。
あなたの経験と考えに基づいて、設問ア~ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴、あなたが定めた行動の基本原則とプロジェクトチームの状況から察知した対立の兆候について、800字以内で述べよ。
設問イ
設問アで述べたプロジェクトの実行中に作業の進め方をめぐって発生した対立と、あなたが実施した対立の解消策及び行動の基本原則の改善策について、800字以上1,600字以内で具体的に述べよ。
設問ウ
設問イで述べた対立の解消策と行動の基本原則の改善策の実施状況及び評価と、今後の改善点について、600字以上1,200字以内で具体的に述べよ。
解答例
設問ア
1.プロジェクトの特徴、行動の基本原則、及び対立の兆候
1.1.プロジェクトの特徴
私がプロジェクトマネージャとして参画したプロジェクトは、企業の基盤を支える顧客管理システム(CRM)を刷新する大規模開発だった。老朽化による運用コスト増大と、事業変化の対応遅れ解消が目的だった。このプロジェクトは、複数の事業部門、外部開発・運用ベンダーなどの多様な関係者が参画、既存システムのブラックボックス化による関係者間の前提知識のばらつき、という特徴があった。
1.2.行動の基本原則
多様なチームメンバーが一体となるため、私が定めた「行動の基本原則」は以下の3点である。
1)事実に基づき、建設的に対話する。
2)相手の立場を理解し、尊重する。
3)プロジェクト全体の成功を最優先とする。
これらの原則は、キックオフや週次会議で繰り返し説明し、プロジェクト憲章に明記して周知した。
1.3.対立の兆候
設計後半から開発フェーズで、仕様詳細化やデータ移行方法の検討が進む中、開発チームと事業部門(オペレーション担当者)間で意見の相違が見られた。データ移行時のクレンジングや突合処理の自動化範囲で認識の乖離が顕著になった。議論が深まらず、定例会議での発言が減る一方、会議後に非公式な場で「現場の作業が大変になる」「やり方が違いすぎる」といった不安や不満が漏れ始めた。これは、事業部門が新システムをイメージできず漠然とした不安を抱え、それを開発チームに効果的に伝えられていないことを示唆していた。開発チーム側も懸念の具体像を把握できていなかった。このコミュニケーション停滞と非公式な不満増加は、行動原則に基づいた対話ができていない兆候であり、明確な対立に発展し遅延を招くリスクが高いと判断した。
(772文字)
設問イ
2.発生した対立、解消策、及び行動の基本原則の改善策
2.1.発生した対立とその原因
前述の兆候は、顧客データの移行におけるデータクレンジングと突合処理の方法論に関する、開発チームと事業部門間の対立に発展した。開発チームは、納期・コスト制約の中で効率性を優先し、自動化ツールを用いた高度なデータクレンジング・突合処理を提案した。人的ミスを減らし、短期間で大量処理できる技術的優位性を主張した。一方、事業部門は過去の品質問題から、手作業による目視確認と経験に基づいた個別判断による突合を主張した。自動化では対応できない複雑なデータや顧客個別の判断が必要なケースが多く、正確性には現場の知見が不可欠と考えた。
この対立の原因を理解するため、両チーム主要メンバーにヒアリングした結果、以下の要因が判明した。
・技術的知識の格差とコミュニケーションの壁
開発チームは技術的合理性を優先したが、事業部門の業務や運用上の懸念への配慮が不足。事業部門は技術知識が乏しく説明を理解できず、「慣れた手作業が安全」と考えた。
・「行動の基本原則」の実践不足
特に「相手の立場を理解し、尊重する」原則が機能せず、互いの状況理解に努めなかった。「事実に基づき対話する」原則も知識差により困難だった。
・情報の非対称性
データ移行の詳細手順や懸念(特殊ケース、手作業の具体例)が両チーム間で十分に共有されていなかった。
対立の結果、データ移行方式の決定が遅れ、後続のテスト・研修計画に遅延が発生し、納期遵守が困難になった。チーム間の信頼関係も損なわれ、他の検討事項にも非協力的な態度が見られた。
2.2.対立の解消策
この対立を解消するため、以下の施策を実施した。
1)対立の構造の可視化と原因の共有
ヒアリング結果を合同ワークショップで共有した。対立が個人間でなく、知識・コミュニケーション不足といった構造要因であると説明し、共通課題として認識させた。
2)相互理解のための体験会と説明会の実施
開発チームは、自動化ツールの「体験型デモンストレーション」を事業部門向けに実施し、処理の様子、自動判断ケース・困難ケースを業務用語で解説した。事業部門は、複雑なデータ構造や過去問題事例を「懸念事例共有会」で具体的に説明した。これにより、互いの技術や業務を具体的に理解できた。
3)PoC(概念実証)の実施提案
事実に基づく意思決定のため、限定データで自動化処理のPoCを提案した。処理速度、誤り率、手作業工数を定量評価し、事業部門の不安を具体データで検証し、両チームの共通理解を深めた。
4)共同での折衷案検討と合意形成
PoCの結果に基づいて両チームで議論を再開し、「自動化ツールによる一次処理+手作業による最終確認」のハイブリッド方式で合意した。私は中立的なファシリテーターとしてリードし、行動原則に立ち返るよう促した。
2.3.行動の基本原則の改善策
今回、知識差がコミュニケーションの阻害要因となることが判明したため、行動基本原則に以下2点を追加した。
1)専門知識のギャップを埋める努力をする
互いの専門領域を理解し合う双方向の努力をし、専門用語回避、図やデモ活用を推奨する。
2)分かりやすい情報共有に努める
重要な情報は、全ての関連ステークホルダーに早期に、彼らの視点で分かりやすく共有する。共有タイミングと質にも配慮する。
上記追加は、対立解消後の全体会議で経緯と共に周知した。具体的な行動例を交え、メンバーが自分事として捉えられるよう努めた。また、チーム間連携が必要なマイルストーンでは、必ず懸念点を共有するプロセスを定義した。具体的な行動を定着させる狙いがあった。
(1594文字)
設問ウ
3.解消策と改善策の実施状況、評価、及び今後の改善点
3.1.解消策と改善策の実施状況と評価
1)対立解消策の実施状況と評価
対立解消策(原因可視化、ワークショップ、PoC、共同検討)は狙い通り機能した。PoCで自動化技術の能力・限界をデータで確認できたことが、事業部門の不安をリスクとして捉え直すのに有効だった。開発チームも事業部門のこだわりを理解でき、問題解決型の議論に転換できた。ハイブリッド方式に合意できたことで、遅延していた計画策定を速やかに開始でき、納期遅延リスクを回避できた。最も重要な成果は、損なわれかけていた開発チームと事業部門間の信頼関係が回復し、互いに協力する姿勢が見られたことである。これにより、要求再確認やUATが円滑に進み、品質向上に繋がった。
2)行動の基本原則改善策の実施状況と評価
改善・追加した行動基本原則の周知と、コミュニケーション計画への反映は、プロジェクト後半のチーム間連携を強化する上で有効であった。UATフェーズでは、開発チームが環境やデータ状況を事業部門に分かりやすく共有し、迅速かつ丁寧に対応するようになった。事業部門側も、発見した不具合や改善要望を、具体的な操作手順や期待する結果を明確に記載した形で開発チームに報告するようになった。運用引き継ぎに向けては、技術情報の非対称性解消と運用部門の不安軽減を期待して、開発チームと運用部門は合同勉強会や手順書レビューを早期に実施した。結果、後半は認識齟齬による大きな問題なく、円滑な情報連携が可能となった。追加した基本原則は行動指針として受け入れられ、チーム全体の協調性・問題解決能力を高める上で期待以上の効果があった。結果、品質目標を達成し、無事本番稼働を迎えることができた。
3.2.今後の改善点
今回、対立の兆候を早期察知し、予防的な働きかけが重要性であると痛感した。今後は以下の点を改善する。
1)非公式コミュニケーションチャネル強化
主要メンバーとの1対1ミーティングや、ランチミーティングなどの非公式な交流機会を設定し、公式な場では出にくい懸念や人間関係の機微を早期に吸い上げる。
2)チーム状態診断サーベイ定期実施
匿名アンケートで、連携満足度、行動原則遵守度等を定期的にデータで把握し、潜在的問題の早期対策を可能にする。
3)全メンバー対象コミュニケーション研修導入
対立の予防と解消に主体的に貢献できる能力を高めるため、異なるバックグラウンドを持つ人との対話、相手視点での説明、アクティブリスニング研修を実施する。
これらの改善点により、多様な意見を建設的議論に繋げられる、レジリエントでパフォーマンスの高いチームを構築できると考える。
(1160文字)
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント