- 合格レベルの論文がどんなものか、具体的な完成形を知りたい方
- 自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
- 設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方
プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。
問題文および設問
問題の原本はIPAにてご確認ください。
問題文
問２ プロジェクト目標の達成のためのステークホルダとのコミュニケーションについて
システム開発プロジェクトでは、プロジェクト目標（以下、目標という）を達成するために、目標の達成に大きな影響を与えるステークホルダ（以下、主要ステークホルダという）と積極的にコミュニケーションを行うことが求められる。
プロジェクトの計画段階においては、主要ステークホルダへのヒアリングなどを通じて、その要求事項に基づきスコープを定義して合意する。その際、スコープとしては明確に定義されなかったプロジェクトへの期待があることを想定してプロジェクトへの過大な期待や主要ステークホルダ間の相反する期待の有無を確認する。過大な期待や相反する期待に対しては、適切にマネジメントしないと目標の達成が妨げられるおそれがある。そこで、主要ステークホルダと積極的にコミュニケーションを行い、過大な期待や相反する期待によって目標の達成が妨げられないように努める。
プロジェクトの実行段階においては、コミュニケーションの不足などによって、そこ主要ステークホルダに認識の齟齬や誤解（以下、認識の不一致という）が生じることがある。これによって目標の達成が妨げられるおそれがある場合、主要ステークホルダと積極的にコミュニケーションを行って認識の不一致の解消に努める。
あなたの経験と考えに基づいて、設問ア～設問ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトの概要、目標、及び主要ステークホルダが目標の達成に与える影響について、８００字以内で述べよ。
設問イ
設問アで述べたプロジェクトに関し、“計画段階”において確認した主要ステークホルダの過大な期待や相反する期待の内容、過大な期待や相反する期待によって目標の達成が妨げられるおそれがあると判断した理由、及び“計画段階”において目標の達成が妨げられないように積極的に行ったコミュニケーションについて、８００字以上１，６００字以内で具体的に述べよ。
設問ウ
設問アで述べたプロジェクトに関し、“実行段階”において生じた認識の不一致とその原因、及び“実行段階”において認識の不一致を解消するために積極的に行ったコミュニケーションについて、６００字以上１，２００字以内で具体的に述べよ。
解答例
設問ア
１．プロジェクト概要と目標、主要ステークホルダの影響
１．１．プロジェクト概要
私が担当したプロジェクトは、既存の法人向けクラウドサービスに、顧客要望が多かった高度なデータ分析・可視化機能を追加開発するプロジェクトである。私はプロジェクトマネージャとして、企画からリリースまでを担当した。プロジェクト期間は約６か月、開発チームは社内エンジニア約１０名で構成された。既存サービスの基盤上に新たな機能を構築する点が特徴であった。
１．２．プロジェクト目標
本プロジェクトの主要目標は、期日（約６か月後）までの新機能本番リリース（納期遵守）と品質基準の達成（品質確保）であった。加えて、当初予算内での完了（コスト目標）、新機能による既存顧客満足度向上および新規顧客獲得への貢献（ビジネス目標）も重要な目標であった。
１．３．主要ステークホルダと目標達成への影響
本プロジェクトの主要ステークホルダは、「顧客」（代表ユーザー数社）、「営業部門」、「開発部門」、「運用部門」、「事業責任者」であった。
これらのステークホルダは目標達成に大きな影響を与えると判断した。顧客からの要求提示や受け入れテスト協力は、スコープ、設計、品質に直結する。営業部門による要望整理や顧客調整は、スコープ、手戻り、納期に影響する。開発部門の技術力、品質、進捗管理は、品質、納期、コストに直接影響する。運用部門の運用要件や準備は、サービスインや安定稼働に不可欠である。事業責任者による意思決定やリソース提供は、プロジェクト推進や課題解決のスピードを左右する。これらの主要ステークホルダ間の密な連携と早期の合意形成なしには、特に納期と品質目標の達成は極めて困難であると判断した。
（７４２文字）
設問イ
２．計画段階におけるステークホルダとのコミュニケーション
２．１．確認された過大な期待や相反する期待
計画段階で、主要ステークホルダとのコミュニケーションを通じ、過大な期待や相反する期待を確認した。
顧客や営業部門からは、新機能に対する過度な汎用性やパフォーマンスに関する期待が顕著だった。「どんなデータでも取り込める」「大量データも瞬時に分析」といった、期間・予算で実現困難な要求や、当初スコープ外の「機械学習による予測機能」への期待も確認された。
営業部門内では、ヘビーユーザー向けニッチ機能（個別最適）と、幅広い顧客向け汎用機能（全体最適）という相反する期待が生じていた。
開発部門内でも、最新技術による拡張性追求と、実績技術による安定性・納期重視という、技術的なアプローチに関する意見対立が生じていた。
２．２．目標達成が妨げられるおそれと判断した理由
これらの期待は、プロジェクト目標達成を妨げる重大なリスクとなると判断した。
過大な期待はスコープの肥大化を招き、設計難易度上昇、手戻り、テスト不足による納期遅延、品質低下、予算超過リスクに直結する。特に６ヶ月の短期間、約１０名、追加予算なしという経営資源の制約下では致命的と考えた。クラウドサービスとしての運用負荷増大も懸念された。
相反する期待は、仕様確定の停滞、手戻り多発、合意困難化を招き、計画の遅延、チーム内の不和、最終成果物への不満に繋がる。特に個別最適と全体最適、異なる技術アプローチの対立は設計根幹に関わるため、早期解消しないと後続工程への影響が大きいと判断した。これらのリスクを放置すれば、納期、品質、コスト目標の達成が困難になると強く認識した。
２．３．目標達成のため計画段階で行ったコミュニケーション
目標達成のため、計画段階で主要ステークホルダと積極的にコミュニケーションを行った。
過大な期待や相反する期待の真のニーズを理解するため、顧客や営業担当者に対し、要望の背景や目的、業務プロセスを深掘りするヒアリングやワークショップを実施した。これは、本質的な課題解決や段階的な実現可能性を探ることが目的だった。
現実的なスコープと目標について認識合わせをするため、事業目標、技術的可能性、期間・コスト、運用負荷等を評価する仕様検討会議を毎週開催。ＭｏＳＣｏＷ分析（必須／優先／できれば／今回見送り）で要望の優先順位とその根拠を明確にした。経営資源の制約や全体最適の観点から、なぜ過大な期待に応えられないか、なぜ一部要望を見送るかを論理的に説明した。個別最適と全体最適の対立は、事業全体の成長から汎用機能優先とする事業責任者の判断を示し合意形成を図った。
具体的な成果物イメージを早期に共有するため、プロトタイプやモックアップを作成し、顧客や営業、運用部門を含むレビュー会で提示した。これにより抽象的な仕様書での認識齟齬を防ぎ、具体的な議論を可能にし、期待値を現実的なラインに調整した。
コミュニケーション活動の記録として議事録を作成し、決定事項、ペンディング事項、宿題を速やかに共有。重要な決定事項は署名・承認プロセスを設け、後からの翻意を防いだ。
最終的に、合意されたスコープ、目標、スケジュール等を明記したプロジェクト計画書を主要ステークホルダから正式承認を得た。これは「この計画で進める」という意思統一を図る重要な活動であった。これらの積極的なコミュニケーションにより、計画段階の潜在リスクを顕在化させ、共通認識と強いコミットメントを醸成できた。
（１５１０文字）
設問ウ
３．実行段階におけるステークホルダとのコミュニケーション
３．１．生じた認識の不一致とその原因
実行段階で、計画段階の努力にもかかわらず、認識の不一致が生じた。特に以下の２つの影響が大きかった。
１）開発中の分析機能の「分析結果の解釈」
顧客や営業担当者から、システム出力値が既存ツールや手計算の結果と異なり「間違っているのでは」と指摘された。開発側は仕様通りの正確な値と主張した。
認識の不一致の原因は、計画段階での「正確性」定義の不十分さにあった。開発側は数学的精度、顧客側は既存ツールとの一致を「正確」と捉えていた。仕様書に計算ロジックはあったが、具体的な検証基準が欠けていた。
２）特定の操作における「レスポンスタイム」
アルファテストで顧客から「業務で使うには遅すぎる」と指摘された。開発環境では非機能要件基準を満たしていたが、体感速度に差があった。
認識の不一致の原因は、テスト環境と実利用環境の乖離にあった。標準的なテスト環境が、顧客の多様な利用シーンや体感速度を考慮できていなかった。これは計画段階での非機能要件やユーザーシナリオの深掘り不足に起因した。
３．２．認識の不一致解消のため実行段階で行ったコミュニケーション
認識不一致による目標達成への影響を避けるため、実行段階で積極的なコミュニケーションを行った。
まず、問題報告を受け、関係者を集め状況把握・原因究明を行った。根本原因に辿り着くため「なぜなぜ分析」を活用した。表面的な事象ではなく、仕様定義やテスト計画の不備といった根本原因に辿り着くことが目的だった。
原因究明結果を基に、不一致内容、原因、解決策を関係者全員に説明し、特に解決策については、複数の選択肢とそれぞれのトレードオフを示すようにした。これは、経営資源の制約下で現実的な判断をしてもらう狙いがあった。
提示した解決策について、顧客含む主要関係者会議で議論することにした。会議では、各立場の意見を丁寧に聞き、双方向対話で納得感を醸成するように配慮した。これは、限られた期間・予算で何を優先するかを、全員が納得できるようにする狙いがあった。
合意した内容に基づき、関連仕様書を改訂し周知した。特に分析結果の検証基準などを具体化し、今後の曖昧さを排除するようにした。認識不一致の再発防止・品質確保のため、顧客利用シーンに近いテストデータを用いた、実環境に近い状態でのテストを強化することにした。
解消活動の進捗は定例会議で常に共有し、透明性を維持することにした。これらのコミュニケーションを通じ、顕在化した課題に対し関係者協力で原因特定・現実的な解決策の合意形成し、目標達成に向けた軌道修正が可能となった。
（１１６２文字）
まとめ
自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。
参考図書
自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。
上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。
コメント