- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題文および設問は、下記にてご確認ください。
解答例
設問ア
１．プロジェクトの概要とステークホルダ分析
１．１．プロジェクトの概要と目標
私が担当したプロジェクトは、ＩＳＰ事業者の法人営業部門向け「統合型メールマーケティングプラットフォーム」（以下、本システム）の新規開発である。私は情報システム部に所属し、プロジェクトマネージャを務めた。
プロジェクトの背景には、メール配信業務の属人化で担当者間の成約率に最大５倍の格差（０．５％～２．５％）が生じ、これが部門目標の達成を阻害する要因となっていた。また効果測定が手作業であるためにＰＤＣＡサイクルが停滞する課題もあった。
これらの課題解決のため、最重要目標を「業務の標準化とデータ駆動型の営業活動への転換」と定め、定量的目標として「メール配信準備工数の３０％削減」（現状平均４．０時間から２．８時間へ）及び「メール経由での成約率向上」（現状平均２．０％から２．１％へ）を掲げた。測定はリリース後半年間の実績値と、過去１年間の平均値とを比較することとした。開発期間は１２か月と設定された。
１．２．主要ステークホルダと潜在的リスク
本プロジェクトの主要ステークホルダは、ユーザである法人営業第一部、法人営業第二部、技術基盤を担う情報システム部、そして投資判断を行う経営層の四者であり、私は彼らの期待と影響度をステークホルダ登録簿で管理した。
特に、中小企業を担当する営業第二部は「業務効率化」への期待が非常に高く、「誰でも使える簡単さ」を強く要求していた。しかし、ヒアリング初期の段階で、その「簡単」という言葉の解釈に、担当者のＩＴスキルによって幅があることが判明した。これは、実行段階でシステムのＵＩ／ＵＸを巡る深刻な認識の不一致に繋がりかねない、潜在的なリスクであると私は初期から認識し、プロジェクトにおける最重要の管理対象であると位置付けた。
（７７９文字）
設問イ
２．計画段階におけるステークホルダとの期待調整とリスク対応
２．１．主要ステークホルダの期待と潜在的リスク
１）相反する期待と過大な期待
計画段階のヒアリングで、主要ステークホルダの期待について、部門間の要求が相反し、経営層からは過大な期待が寄せられていることを確認した。営業第一部は個別対応を重視し複雑なセグメンテーション機能を、一方、営業第二部は効率を最優先し徹底的に簡素化された操作性を要求した。また、経営層からは、予算を大幅に超えるＡＩ活用機能や、短期的な投資対効果への過大な期待が寄せられていた。
２）最重要リスクとしての「認識の不一致」の特定
私はこれらの期待のズレから生じる様々なリスクの中でも、特に「実行段階で、システムのＵＩ／ＵＸを巡って営業第二部との間に深刻な認識の不一致が生じる」リスクを、最重要リスクとして特定した。その根源は、彼らの「簡単さ」と「柔軟性」という、両立が難しい曖昧な要求にあった。このリスクが顕在化すれば、システムの受け入れが拒否され、最重要目標を達成できない判断した。
２．２．リスクを管理するためのコミュニケーション計画
私はこの最重要リスクを管理するため、予防処置と是正処置計画から成る、計画的なコミュニケーションを設計した。
１）発生確率を低減させるための予防処置
まず、リスク発生確率を低減させるため、両営業部門と合同ワークショップを開催した。特に工夫したのは、要求を「必須」レベルに分類する際、「『必須』と定義できるのは、”この機能がなければ定量的目標の達成が不可能になる”と全員が納得できるものに限る」という明確な判断基準を提示した点である。さらに、曖昧な「簡単さ」という要求を、「初回操作のタスク完了時間３分以内」等の非機能要件に定義しようと試みたが、操作イメージが固まらず、完全な合意には至らなかった。これにより、スコープの膨張は抑制できたものの、リスク残存を再認識した。
２）リスク顕在化に備えた是正処置計画
予防処置を講じてもリスクは残存すると判断し、顕在化に備えた是正処置計画を事前に策定した。具体的には、「プロトタイプ提示の際、ＵＩの根本的な作り直しに繋がる不満が表明された場合」をトリガーとし、その際は「ＰＭによる一次対応→経営層への報告と協力要請→ペーパープロトタイピングによるワークショップの再実施」という三段階の是正処置を発動する、と定義した。
２．３．コミュニケーション計画に基づく合意形成
私は、策定したリスク対応計画等の実行許可を、事前のコミュニケーションによってステークホルダから得ることが不可欠だと考えた。
１）過大な期待の正常化
経営層の過大な期待に対し、まず定例報告会で客観的データを用いて対処した。具体的には、ＡＩ活用機能には「追加開発で２千万円、効果による利益増は年１千万円程度」というＲＯＩの概算を提示し、「回収に２年以上を要し、今回の投資基準には合致しない」と説明した。その上で、「まず今回の製品で確実に成果を出し、その投資効果を原資に、フェーズ２でＡＩ機能を検討する」という段階的ロードマップを提案し、経営層の期待を現実的な水準に導いた。
２）残存リスクに関する事前合意
次に、ＵＩ／ＵＸに関するリスク登録簿を正式な議題とし、経営層および営業第二部の部長と個別レビュー会議を設定した。そこで「ＵＩに関する認識のズレというリスクの残存」「顕在化した場合、手戻りによる１か月の遅延と５人月の追加工数が見込まれる」「その際は、この計画に沿った是正処置実行の許可が欲しい」と提示した。当初、経営層からは予防策が万全でない点を厳しく指摘されたが、リスクを透明化し計画的に管理しようとする私の姿勢が最終的に評価され、事前承認を得ることができた。
（１５９１文字）
設問ウ
３．実行段階における認識の不一致への対応
３．１．予見された認識の不一致とその状況
１）リスク発生の状況
実行段階でプロトタイプを提示した際、計画段階で予見していたリスクが顕在化した。営業第二部のマネージャから「テンプレート機能が期待と全く違う。作業が煩雑になり、我々の求める『簡単さ』が実現されていない」という強い不満が表明された。これは、是正処置計画で定義したトリガーに該当する事態であった。
２）リスク顕在化に対する状況判断と対応
私は、この事態をリスク登録簿に記載された「想定内のリスクの顕在化」として判断し、プロジェクトメンバと、不満を表明する営業第二部の双方に対して、状況がコントロール下にあることを示した。具体的には「リスク登録簿の通り、この事態は事前に予見したものであること」「対応計画も準備済みであること」を伝えた。その上で、関係者に事前に合意していた是正処置計画の発動を正式に宣言した。
３．２．計画に基づき実行したコミュニケーションと評価
１）事前に合意した是正処置の実行プロセス
私は、事前に策定・合意した三段階の是正処置計画に従い、コミュニケーションを主導した。第一に、営業第二部の不満を詳細にヒアリングし、共感を示しつつ、計画に沿った対応を約束することで、感情的な対立への発展を抑えた。第二に、計画通り担当役員に状況を報告し、追加工数とスケジュールの承認を得ると同時に、次のワークショップへの参加を要請した。役員からは「計画的な対応を評価する。責任をもって解決せよ」との支持を得た。第三に、ペーパープロトタイピングを用いたワークショップを開催し、ユーザ自身に理想のＵＩを描いてもらうことで、曖昧だった「簡単さ」の具体的なイメージを初めて共有できた。その結果、「テンプレートの基本構造は固定しつつ、カスタマイズ可能な項目を選択式で増やす」という現実的な修正案で、円滑に合意形成するに至った。
２）リスクマネジメント活動の有効性評価
今回の是正処置による手戻りは、結果としてスケジュールの３週間の遅延と４人月の追加コストを発生させた。しかし、これはリスク対応計画の策定時に見積もった「１か月の遅延、５人月の追加工数」という許容範囲内に収まり、マネジメント計画が有効に機能したと評価する。この「４人月の追加コスト」は、「５人月以上の追加コストはＣＣＢ（変更管理委員会）による承認が必要」という当社の規定に基づき、ＰＭによる裁量の範囲内で吸収可能と判断した。
今回の教訓を活かすため、ＵＩ／ＵＸに関する要求の合意形成において、プロトタイピングによる段階的な検証を義務付けるプロセスを標準化した。具体的には、「非機能要件定義ガイドライン」と「コンティンジェンシ計画標準テンプレート」を作成し、全社のプロセス資産として共有・展開した。
（１１９１文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント