プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問１　未経験の技術やサービスを利用するシステム開発プロジェクトについて

　プロジェクトマネージャ（ＰＭ）は、システム化の目的を実現するために、組織にとって未経験の技術やサービス（以下、新技術という）を利用するプロジェクトをマネジメントすることがある。
　このようなプロジェクトでは、新技術を利用して機能、性能、運用などのシステム要件を完了時期や予算などのプロジェクトへの要求事項を満たすように実現できること（以下、実現性という）を、システム開発に先立って検証することが必要になる場合がある。このような場合、プロジェクトライフサイクルの中で、システム開発などのプロジェクトフェーズ（以下、開発フェーズという）に先立って実現性を検証するプロジェクトフェーズ（以下、検証フェーズという）を設けることがある。検証する内容はステークホルダと合意する必要がある。検証フェーズでは、品質目標を定めたり、開発フェーズの活動期間やコストなどを詳細に見積もったりするための情報を得る。ＰＭは、それらの情報を活用して、必要に応じ開発フェーズの計画を更新する。
　さらに、検証フェーズで得た情報や更新した開発フェーズの計画を示すなどして、検証結果の評価についてステークホルダの理解を得る。場合によっては、システム要件やプロジェクトへの要求事項を見直すことについて協議して理解を得ることもある。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わった新技術を利用したシステム開発プロジェクトにおけるプロジェクトとしての特徴、システム要件、及びプロジェクトへの要求事項について、８００字以内で述べよ。

設問イ

設問アで述べたシステム要件とプロジェクトへの要求事項について、検証フェーズで実現性をどのように検証したか。検証フェーズで得た情報を開発フェーズの計画の更新にどのように活用したか。また、ステークホルダの理解を得るために行ったことは何か。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた検証フェーズで検証した内容、及び得た情報の活用について、それぞれの評価及び今後の改善点を、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と要求事項

１．１．プロジェクト概要

　私が担当したプロジェクトは、老朽化した顧客向け業務処理システムを、クラウド基盤上に再構築するプロジェクトであった。私はプロジェクトマネージャとして、このプロジェクトに参画した。
　本プロジェクトの特徴は、組織にとって初めてクラウドネイティブ技術を採用することであった。組織内にこれらの新技術に関する知識や経験が乏しいという、人的リソースの制約を抱えていた。また、プロジェクトには短納期での完了と、年間運用コストの大幅削減という、厳しい要求があった。

１．２．システム要件

　本プロジェクトでの主なシステム要件は、次の通り。

１）機能要件
　現行システムの主要業務処理を踏襲しつつ、一部プロセスは新技術を活かした改善を行う。
２）非機能要件
　主に以下の５点が重要であった。
・性能
　ピーク時応答時間を１秒以内に抑え、同時に５０件／秒以上のスループットを安定維持する。
・セキュリティ
　クラウド環境特有のリスクに対応し、組織基準及び外部規制に準拠する。
・可用性
　目標稼働率９９．９％とし、障害時の影響最小化する。
・運用容易性
　環境構築の自動化、効率的な監視・ログ収集・デプロイメント手法を確立する。
・スケーラビリティ
　将来のアクセス増加や拡張に柔軟対応できるアーキテクチャとする。

１．３．プロジェクトへの要求事項

　プロジェクトへの主な要求事項は以下の通りであり、ビジネス目標に結びついたものだった。
・新たな事業計画に合わせ、１年後の年度末までに本番稼働する。
・初期開発コストを抑えつつ、稼働後の年間運用コストを現行比で３０％以上削減する。
・性能、セキュリティ、可用性の目標値を達成し、目標稼働率９９．９％を安定維持する。

（７９０文字）

設問イ

２．検証フェーズにおける実現性検証と計画更新

２．１．検証フェーズでの実現性検証

　システム要件とプロジェクト要求事項について、未経験のクラウドネイティブ技術の実現性を検証するため、開発フェーズに先立って検証フェーズを設けた。主に、技術的適用可能性の評価、開発フェーズのリスク早期特定、計画策定に必要な情報収集が目的だった。制約事項を考慮し、検証範囲を絞り、最も技術的リスクが高い要件に焦点を当てた。

　検証内容は、技術部門、運用部門、情報セキュリティ部門と協議し、プロジェクトの早い段階で検証が必要な「性能」「セキュリティ」「運用容易性」の３つを検証することで合意した。
１）性能に関する検証
　ボトルネックになりやすい主要業務処理をサーバーレス機能として実装し、模擬データと負荷ツールを用いて応答時間とスループットを計測、評価した。
２）セキュリティに関する検証
　クラウド基盤セキュリティ機能とコンテナ／サーバーレス環境の組み合わせで、組織セキュリティ基準を満たせるか検証した。脆弱性管理、通信暗号化、アクセス制御などを確認した。
３）運用容易性に関する検証
　ＩａＣツールを用いた検証環境の自動構築と、アプリケーションの自動デプロイを試み、効率性や運用負荷削減の実現性を確認した。監視・ログ収集機能の活用も検証した。

　残りの「可用性」「スケーラビリティ」は、検証フェーズでの網羅的検証が困難であり、開発フェーズでの実装や稼働後のチューニング・監視強化で対応可能と判断し、対象外とした。

２．２．検証結果の開発フェーズ計画への活用

１）性能検証の結果
　主要業務処理の一部で想定応答時間が得られず、データベース連携設計に起因することが判明した。開発フェーズで設計を見直し、キャッシングやクエリ最適化に重点を置く必要性が生じ、関連タスク工数が増加予測された。
２）セキュリティ検証の結果
　クラウド基盤標準機能だけでは対応困難な要件や、脆弱性スキャンの組み込みが必要と判明し、開発計画に、セキュリティツールの追加導入等のタスクを追加した。これは当初予算外であり、予算増加要因となった。
３）運用容易性検証の結果
　デプロイ手順の複雑化と技術者の知識不足が明らかになった。開発計画に、デプロイメントパイプライン構築工数の追加と、新技術研修の実施期間を含めた。特に技術者スキルギャップは、短納期下での遅延リスクとして要員計画見直しに活用した。

　これらの結果から、開発フェーズのＷＢＳを詳細化し、見積もりを更新した。その結果、開発期間延長と予算増加が必要となった。特定されたリスクと対策は、リスク管理計画に反映させた。

２．３．ステークホルダの理解を得るための活動

　検証で得た情報や更新計画について、主要ステークホルダ（経営層、利用部門、ＩＴ部門など）の理解と承認を得るため、報告会を実施した。
　報告会では、検証結果（特に新技術の適合性と明らかになった、技術的課題）を、性能データやセキュリティ脆弱性パターンなど、定量的データや事例を交えて具体的に報告した。課題の深刻度や対策の必要性を理解させる狙いがあった。
　また、検証結果に基づく計画の変更が、ビジネス影響やプロジェクト成功に寄与するという観点で説明し、経営課題解決に不可欠であることを示した。
　さらに、質疑応答時間を十分に設け、懸念事項に対して具体的に回答した。予算増加や納期延長について、客観的データと代替案を示し、妥当性を説明した。報告会後、必要に応じて個別説明を行い、更新計画の正式承認を得た。検証結果を踏まえたシステム要件見直しについても協議し、関係者間の認識を統一した。この活動でステークホルダの納得を得られ、円滑な推進に繋がった。

（１５９７文字）

設問ウ

３．検証結果と情報活用の評価及び改善点

３．１．検証フェーズで検証した内容の評価と改善点

１）評価
①良かった点
・ＰｏＣによる事前検証は、未経験技術の適用可能性と、性能やセキュリティの技術的ボトルネック早期特定に極めて有効であった。具体的な課題把握で、開発フェーズでの手戻りリスクを大幅に低減できた。
・検証計画策定段階からの関係部門（技術、運用、セキュリティ）巻き込みと合意形成プロセスは、当事者意識を高め、協力体制構築に効果があった。
②課題点
　運用容易性に関する検証スコープが限定的で、ＢＣＰ／ＤＲやバックアップといった非機能要件を網羅できなかった。また、周辺機能や既存連携の検証が不十分で、開発フェーズで新たな課題が発見された。これは、人的リソースと期間の制約下での優先度付けの反省点である。
２）今後の改善点
　検証スコープに周辺機能、非機能要件（ＢＣＰ／ＤＲ、バックアップ、監視体制）を含める検討を行う。そのため、計画段階でシステム全体リスクを詳細分析し、制約下での優先度とスコープをステークホルダと十分協議し決定する必要がある。十分な検証のため、適切な期間とリソース確保の重要性を早期に訴求するスキルを向上させたい。

３．２．検証で得た情報の活用の評価と改善点
１）評価
①良かった点
　検証で特定された課題や必要な追加作業に基づき開発計画を更新したことは、見積もり精度を向上させ、現実的な計画策定に非常に有効であった。予期せぬ課題による計画崩壊リスクを低減できた。客観的な検証結果を根拠にステークホルダへ報告し承認を得たことは、計画変更への納得感を高め、協力的な姿勢を引き出す上で有効であった。リスク管理計画にリスクと対策を反映できたことも重要であった。
②課題点
　検証で得られた「技術者スキル不足」情報を、開発開始前の具体的なスキルアップ研修計画や要員計画に十分連動させきれなかった。結果、開発序盤で技術習得に時間を要し、一部遅延やリソース負荷増加を招いた。予算制約下での外部専門家確保不足も影響した。
２）今後の改善点
　検証で特定されたスキル情報を、開発フェーズ人的リソース計画と密接に連動させるプロセスを強化する。スキル評価に基づき、研修計画を具体的に策定・実行する。制約下では、外部専門家活用も含む要員計画全体を柔軟に見直す体制を構築する。開発フェーズ以降も技術知見を継続収集・共有し、計画やリスク管理に反映される仕組み（技術レビュー会議など）を強化し、技術リスクを継続管理する。

（１０８１文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

「この問題のこんなテーマの解答案を作ってほしい」などのご希望があれば、ぜひコメント欄でご要望いただけると嬉しいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

プロジェクトマネージャ試験の午後Ⅱの小論文を作成してみました。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

問題の原本はIPAにてご確認ください。

問題文

問２　システム開発プロジェクトにおける要員のマネジメントについて

　プロジェクトマネージャには、プロジェクト目標の達成に向けて、プロジェクトの要員に期待した能力が十分に発揮されるように、プロジェクトをマネジメントすることが求められる。
　プロジェクト目標の達成は、要員に期待した能力が十分に発揮されるかどうかに依存することが少なくない。プロジェクト組織体制の中で、要員に期待した能力が十分に発揮されない事態になると、担当させた作業が目標の期間で完了できなかったり、目標とする品質を満足できなかったりするなど、プロジェクト目標の達成にまで影響が及ぶことになりかねない。
　したがって、プロジェクトの遂行中に、例えば、次のような観点から、要員に期待した能力が十分に発揮されているかどうかを注意深く見守る必要がある。
・担当作業に対する要員の取組状況
・要員間のコミュニケーション
　要員に期待した能力が十分に発揮されていない事態であると認識した場合、対応策を立案し、実施するとともに、根本原因を追究し、このような事態が発生しないように再発防止策を立案し、実施することが重要である。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴、プロジェクト組織体制、要員に期待した能力について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトの遂行中に、要員に期待した能力が十分に発揮されていないと認識した事態、立案した対応策とその工夫、及び対応策の実施状況について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた事態が発生した根本原因と立案した再発防止策について、再発防止策の実施状況を含めて、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と体制

１．１．プロジェクト概要

　私がＰＭとして参画したプロジェクトは、大手小売業向け顧客情報分析システム開発である。目的は、ＡＩによる顧客行動分析でマーケティング精度を向上させ、売上拡大を図ることだった。期間１２か月、予算１億円で、プロジェクトの特徴は次のようなものだった。
１）技術的特徴
　社内初のＡＩエンジン導入と既存ＤＷＨとの大量データ連携であり、ＡＩ技術習得が鍵だった。機械学習ライブラリで購買予測モデルを構築、コストとサポートを期待し選定した。
２）体制的特徴
　自社社員１０名と協力会社５名で構成し、ＡＩ技術は中堅Ｂ氏に習得とコア機能開発を担当させる計画だった。Ｂ氏は新技術導入経験と能力を評価しての人選である。
３）業務的特徴
　マーケティング部門の要求が高度かつ変化しやすいため、アジャイル開発を採用した。
　経営資源の制約として納期厳守が絶対で、社内ＡＩ専門要員不足からＢ氏への期待と負荷集中は初期からのリスク認識事項だった。

１．２．プロジェクト組織体制とＢ氏に期待した能力
　組織体制は、私（ＰＭ）の下に開発リーダーＡ氏を置き、Ａ氏配下にＡＩ技術担当Ｂ氏を含む開発チーム５名、インフラ２名、品質管理１名を配置した。報告ラインは担当者からＡリーダー経由で私に集約し、Ｂ氏のＡＩ技術習得状況は週次定例で報告を受ける計画だった。私とＢ氏も隔週で１ｏｎ１ミーティングを設定した。Ｂ氏には、重要な下記の役割を期待した。
１）１ヶ月以内のＡＩエンジン基本操作・主要アルゴリズム習得と、プロトタイプ作成
２）３ヶ月以内の顧客セグメンテーション用ＡＩモデル設計と、コアモジュール高品質開発
３）習得技術の他メンバーへの展開と、チーム技術力向上貢献である
　これらは、Ｂ氏の過去実績と学習意欲から達成可能と判断した。

（７９６文字）

設問イ

２．Ｂ氏の能力が発揮されなかった事態と対応

２．１．期待した能力が発揮されていないと認識した事態

　プロジェクト開始２ヶ月後、Ｂ氏担当のコアモジュール開発が計画比で２週間遅延した。進捗ツール上の遅延とＢ氏からの報告遅れで判明した。設計書等のレビューではＡＩライブラリ誤用が散見され品質に懸念が生じた。具体的には、モデル学習データ前処理ロジック不備で、特定条件下での精度低下の可能性が指摘された。週次会議でのＢ氏の報告は曖昧で、質問への回答も不明瞭だった。リーダーＡ氏から、Ｂ氏が技術課題を抱え込み周囲に相談せず、チームへの技術共有も滞っていると報告を受けた。
　このことから、Ｂ氏の能力が十分に発揮されていない状況と認識した。

２．２．立案した対応策とその工夫

　前述の事態に対して根本的問題の把握が最優先と考え、Ｂ氏と非公式な個別面談を設定した。公式な場では本音を話しにくいと考え、心理的安全性の確保が必要と判断したからである。面談では、Ｂ氏が心を開きやすく本音を話しやすい雰囲気作りに努めた。面談から、Ｂ氏の問題は①新技術の難易度と情報不足、②重圧と期待、③責任感からの孤立、④失敗への恐れ、の複合要因と推察した。これに基づき以下の対応策を立案した。
１）技術支援体制強化
　リーダーＡ氏によるＢ氏とのペアプログラミングを実施。特に「指導」でなく「共同技術検証・課題解決セッション」と位置付けし、Ｂ氏の自尊心を傷つけないように配慮する工夫をした。これは、Ｂ氏に「管理されている」のではなく、あくまで「共に問題解決に取り組むパートナー」としてＡ氏の役割を明確にすることで、Ｂ氏の主体性を引き出す狙いがあった。Ａ氏にはコーチング的アプローチを依頼し、Ｂ氏・Ａ氏専用タスクボードで細かな進捗と達成感を共有させた。
２）心理的サポートとコミュニケーション再構築
　私とＢ氏の１ｏｎ１を週１回に増やし「何でも話せる場」と伝えた。業務上の指示や確認だけでなく、Ｂ氏が抱える不安や懸念を自由に表現できる場を提供することが、信頼関係の再構築と精神的な安定に不可欠と考えた。最初は雑談から入り、リラックスを促し、発言を否定せず共感・受容を徹底する工夫をした。
３）タスク再計画と期待値再調整
　Ｂ氏のタスク優先度を見直し、ＡＩエンジンの特定機能習得と開発に集中できるよう一時的にスコープを調整し、具体的目標を再提示した。過度なプレッシャーの軽減と小さな成功体験を積ませる狙いがあった。
　これらの対策は、単に技術的なテコ入れを行うだけでなく、Ｂ氏の心理面に配慮し、自律的な回復を促す必要があると判断した結果である。

２．３．対応策の実施状況と結果

　前述の対応策は、Ｂ氏とＡリーダー協力のもと速やかに実施した。ペアプログラミング開始後、Ｂ氏はＡリーダーのサポートで、技術課題への具体的な質問や相談が活発になり、表情も明るくなった。難解だったデータ前処理ロジックは、Ａ氏との議論が新たな解決方法を導くきっかけになった。私との１ｏｎ１では、Ｂ氏は徐々にプレッシャーや不安も話すようになった。私はＢ氏の努力を認め、小さな進捗も称賛し自己肯定感を高めるよう努めた。タスク再計画はＢ氏の精神的負担を軽減し、目の前のタスクに集中できる環境を提供した。これらの結果、約１か月後、Ｂ氏担当コアモジュールは、計画に対し３日遅延で完了。品質も、再テストで他モジュール同等レベルに改善された。
　特筆すべきはＢ氏自身の変化だった。終盤には習得技術のチーム内勉強会を自ら企画・開催するなど、期待したチーム技術力の向上に貢献し、他メンバーからも好評価を得た。この対応でＢ氏の能力発揮不全という危機を乗り越え、プロジェクトへの致命的影響を回避し後続フェーズへ円滑に移行できた。

（１５９６文字）

設問ウ

３．根本原因と再発防止策

３．１．事態が発生した根本原因

　事態の根本原因は、以下と結論付けた。
１）私の過度な期待とリスク評価の甘さ
　ＰＭとしてＢ氏の過去実績を過信し、ＡＩ技術の難易度やＢ氏の性格を考慮せず、高難度タスクを実質単独でアサインした。Ｂ氏が成果を出せない場合のリスク評価やサポート体制計画が初期段階で不十分だった。これがＢ氏を精神的に追い込み、能力発揮を妨げた最大の要因と分析した。
２）組織的な技術習得支援体制の不備
　社内初のＡＩ技術導入という重要課題に対し、特定個人に依存する体制だった。Ｂ氏が技術的困難に直面した際、相談できる専門家や体系的教育プログラム、ナレッジ共有の仕組みが組織として未提供だった。これがＢ氏の孤独感を深め、問題解決を遅延させた一因であり、組織の構造的問題だった。

３．２．立案した再発防止策

　今回のケースを踏まえ、以下の再発防止策を立案した。
１）要員アサインメントプロセスの見直しと強化
　スキル評価を多角的に行い、ＰＭが対象要員と面談し期待役割との整合性を確認する。特に新規技術や高難度タスクでは、単独アサインを禁止し、メンター付与か複数名体制を必須とする。初期学習期間や研修予算を計画に明示し、現実的目標設定を徹底する。アサイン時点のミスマッチを減らし、要員が安心して挑戦できる環境を提供することで、能力発揮を最大化する狙いがある。
２）ＰＭによるプロアクティブな要員ケアと早期問題発見の仕組み化
　ＰＭ等が全メンバーと月１回以上の１ｏｎ１を制度化し、業務進捗、課題、キャリア、メンタル等を対話する。リスクが高い要員には、より頻繁なコミュニケーション機会を設け重点モニタリングする。要員の潜在の問題や阻害要因を早期察知し、深刻化する前に対処することで、リスク低減と成長支援を行うことが目的である。

３．３．再発防止策の実施状況と効果

　立案した対策は、所属開発部門のＰＭ標準プロセスに反映し、後続プロジェクトで実践した。　次期システムで新フレームワーク導入時、若手Ｃ氏をアサインする前に本人と面談し、Ｄ先輩をメンターとし初期学習時間を計画、結果Ｃ氏は計画通り開発完了。Ｂ氏のような孤立や遅延は対策後発生していない。１ｏｎ１はメンバーの不安や課題兆候を早期に捉え、大きな問題への発展前に対処可能となった。定量的には早期介入で手戻り工数が平均約１０％削減された。
　これらの施策は部門内の他のＰＭにも共有され、組織展開中である。要員のモチベーション維持とスキルアップへの組織的意識が高まり、若手・中堅が新技術等へ前向きに挑戦しやすい風土が醸成されつつあり、組織のプロジェクト遂行能力向上と人材育成に貢献すると期待している。

（１１６５文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

上記はプロジェクトマネージャ試験の対策本ですが、ITサービスマネージャ試験でも通用する内容です。

ITサービスマネージャ合格論文の書き方・事例集第5版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場

プロジェクトマネージャ試験の午後Ⅱの対策として、自分が実際に練習用に作成した小論文を紹介します。小論文のネタ探しや午後Ⅱ対策の参考にしてもらえるとうれしいです。

合わせて読みたい

解答作成のコツを掲載しています

連続で一発合格した実務経験者によるＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ論文のコツ

合格ラインを超えるには「戦略」が必要！午後Ⅱ論文の構成・展開のコツを、実体験ベースでわかりやすく解説。

ojisan2355.com

合わせて読みたい

この記事以外にも、サンプル論文を多数掲載しています。

ＩＴサービスマネージャ・プロジェクトマネージャ試験 午後Ⅱ 論文過去問サンプル集【連続一発合格者が作成】

「ネタがない」「何を書けば…」午後Ⅱ論文の悩みを一掃！実例とヒント満載の対策ページです。

ojisan2355.com

問題文および設問

具体的な問題はIPAにてご確認ください。

問題文

問１　システム開発プロジェクトにおけるコストのマネジメントについて

　プロジェクトマネージャ（ＰＭ）には、プロジェクトの予算を作成し、これを守ることが求められる。そのためには、予算の基となるコスト見積りの精度を高めるとともに、予算に沿ってプロジェクトを遂行することが必要となる。
　プロジェクトのコストは開発要員にかかわるコスト、開発環境にかかわるコストなど多くの要素から構成される。ＰＭは、コストの各構成要素についてコスト見積りを行い、予算を作成する。その場合、例えば、開発要員にかかわるコストについては、過去の類似プロジェクトから類推したり、生産性の基準値をプロジェクトの特徴を踏まえて修正して利用したりするなど、コスト見積りの精度を高めるための工夫を行う。また、収集できるコスト情報の精度が低い場合には予算に幅をもたせたり、リスク管理の観点から予備費を設定したりするなどの考慮も重要である。
　一方、プロジェクトの遂行中において、ＰＭは、完了時のコストが予算の範囲に収まるように管理する必要がある。そのためには、各アクティビティの完了に要した実コストと予算を比較するなど、コスト差異を把握するための仕組みを確立することが重要である。差異を把握した場合には、その原因と影響度合いを分析し、プロジェクトの完了時のコストを予測する。予算超過が予想されるときには、例えば、生産性の改善策を実施し、状況によっては、委託者や利用部門とプロジェクトのスコープの調整を行うなどの対策をとることも検討し、予算超過を防がなくてはならない。

　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトの特徴、及びプロジェクトにおけるコストの構成とその特徴について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトにおけるコスト見積りの方法とコスト見積りの精度を高めるための工夫、及び予算の作成に当たって特に考慮したことについて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問アで述べたプロジェクトの遂行中におけるコスト差異を把握するための仕組み、及び差異を把握した場合にとったプロジェクトの予算超過を防ぐための対策について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクトの特徴

１．１．プロジェクトの特徴

　私は、情報システム開発およびアウトソーシングを手がける会社に勤務しており、プロジェクトマネージャを８年間経験している。これまでは主に、ＩＳＰ事業者であるＡ社の顧客管理システムの開発に関わってきた。

　今回対象とするプロジェクトは、Ａ社の「顧客向けプロモーションメール配信管理システム（以下、Ａシステム）」の構築プロジェクトである。このプロジェクトに私は、プロジェクトマネージャとして参加した。

　このプロジェクトのもっとも大きな特徴は今後のＡ社との取引拡大に繋がる重要なプロジェクトという点である。

　Ａシステムの構築にあたっては、Ａ社が独自に開発した開発言語（以下、α）による開発をＡ社から要求されている。Ａ社は最近、Ａ社のシステム開発の標準言語としてαの適用を推進している。

　当社はαの経験はなく、コスト見積の精度に問題が出ることが予想されたが、今後のＡ社との取引拡大を見据えてプロジェクトに参加することにした。

１．２．コスト構成および特徴

　今回のプロジェクトにコスト構造は次の通りであり、開発工数がプロジェクトのコストに与える影響が最も大きいのが特徴である。
・開発環境…ゼロ（ハード・ソフトともにＡ社の既存設備を利用）
・運用環境…ゼロ（同上）
・外部委託…ゼロ（当社社員で対応）
・社員工数…８千万（開発工数）
・その他…１０万（交通費など）

（５９３文字）

設問イ

２．コスト見積・予算作成

２．１．コスト見積方法と精度を高める工夫

プロジェクトのコストに最も大きな影響を与える社員の開発工数は、下記の手続きによって算出することとした。
①ファンクションポイント法による見積り
②類似物件の生産性を元に開発工数を算出
③ＷＢＳ上の成果物との突合せによる補正

具体的には、以下の通り。

①Ａシステムの入出力データや、データベースの項目数などのパラメータから開発規模を試算した。

②今回のプロジェクトと同様、開発規模や工数の算出がしづらかった過去のプロジェクトの工程別の生産性を入手し、ファンクションポイント法によって算出した開発規模と掛け合わせることで、工程別の開発工数を算出した。

③算出した工数をＷＢＳ上の成果物に按分した上で、プロジェクトメンバーで、工数の過不足が発生しそうな箇所がないかレビューを行った。

上記の手続きによる工数見積を行った理由は以下の通り。

①今回のプロジェクトは、当社がαでの開発実績がないことから、過去の類似プロジェクトから規模を類推することは困難と判断し、開発規模の見積はファンクションポイント法を採用することにした。

②従来の開発よりも生産性が低下すると考え、当社が過去に担当したプロジェクトの中で、開発言語のスキルが十分でなかったプロジェクトの生産性の平均を、今回のプロジェクトで想定する生産性としてコストを見積もることにした。

③算出した規模と生産性によって得られた開発工数をＷＢＳの成果物に按分することで、プロジェクトメンバー内で具体的な作業ボリュームを共有することができるため、メンバーでレビューを行うことで、工数見積の補正が出来ると考えた。

２．３．予算の作成で特に考慮したこと

予算作成にあたって、詳細設計・製造・単体テストのコストの２０％にあたる４００万円をプロジェクトの予備費として計上することにした。

今回のプロジェクトは、αでの開発経験者がプロジェクトメンバーにいないことから、詳細設計・製造・単体テストでの不具合が多発するリスクがあると考えた。

（８５５文字）

設問ウ

３．プロジェクト遂行中のコスト管理

３．１．コスト差異を把握するための仕組み

　社内のＷＥＢサーバにチケット管理システムを導入し、ＷＢＳに記載した成果物および実行タスクを１つのチケットとして登録することにした。

チケット管理システムは、チケットごとの見積工数および実績工数、タスクの開始時期、終了時期の予定と実績、作業タスクの実行状態（未着手、完了済み、など）をプロジェクトの全メンバーが登録・参照できる。

コスト差異を把握するために、このシステムを利用するように考えた理由は、コストの消化状況とスケジュールの進捗を把握するＥＶＭででのマネジメントを、ほぼリアルタイムで行うことでき、問題の発見と対処を素早く行うことが可能になるためである。

　製造工程に入って２週間が経過したころ、スケジュール予定通り進捗していたが、コストが徐々に増加し、３週間が経過したころには、メンバー１人当たり１人日超過するまでに至った。

対象のメンバーにヒアリングを行ったところ、「αにまだ慣れていないため、製造に手間取り、残業で対応している。慣れてきているの今までよりも生産性はあげられる」との回答であったため、もう２週間様子を見ることにした。

しかし、コスト超過は改善されず、メンバー１人あたり２日超過するまでに至った。

現在のコスト超過のペースが製造完了時点まで続いた場合のコストを試算したところ、コスト予備の４００万円を超過することが明らかになった。

３．２．予算超過を防ぐための対策

　プロジェクトメンバーへのヒアリングの結果、メンバーのαの理解が十分に進まないことがコスト超過の原因であったことから、生産性改善策として、Ａ社からαの開発経験者Ｂさんを講師として招いた勉強会をすることにした。

勉強会では、αの開発標準の解説だけでなく、プロジェクトメンバーが製造中の不明点を、Ｂさんに質問する場にすることにした。

勉強会を開催したのは、単にプロジェクトメンバーのスキル向上を目的としただけでなく、今後Ａ社との取引が拡大した場合に現場同士のコミュニケーションを取りやすくする狙いもあった。

３．３．実行結果と反省点

　勉強会でのプロジェクトメンバーのスキル向上と、勉強会実施後の作業において、プロジェクトメンバーからの問い合わせをＢさんが快く対応してくれた結果、勉強会以降の大きなコスト超過はなくなった。

結果として、予定したコストを超過したのは、勉強会までの製造コスト、勉強会にプロジェクトメンバーを参加させるためのコスト分のみで合計１００万円となり、コスト予備の範囲に収めることができた。

　今回、製造工程に入ってしばらくしてからＡ社からの支援を要請することになったが、プロジェクトの早い段階で技術支援を得られる体制をとることで、生産性の悪化を未然防止するべきであった点が、今回の反省点と考える。

（１，１７６文字）

まとめ

自分自身の論文のネタにするためには、サンプル論文はいくらあってもよいと思います。
このブログに記載したサンプル論文が役に立つとうれしいです。

参考図書

自分が受験したときに使用した参考図書は、下記の旧版です。
「最速の論述対策」で、回答文章のモジュール化と章立ての基本テクニックを学び、「合格論文の書き方」で自分の経験でモジュール化できなかった部分の補強を行い、過去問で実際に手書きの練習をしました。

2021年度版　プロジェクトマネージャ　午後2　最速の論述対策 [ 三好　隆宏 ]

created by Rinker

• Amazon
• 楽天市場

プロジェクトマネージャ合格論文の書き方・事例集第6版 情報処理技術者試験対策書 [ 岡山昌二 ]

created by Rinker

• Amazon
• 楽天市場