老朽化システム再構築

　私が担当したプロジェクトは、１５年間稼働した基幹業務システムの全面再構築である。私はプロジェクトマネージャ（ＰＭ）として、保守性の課題解決を責務として担っていた。本プロジェクトでは、経営陣が中期経営計画に不可欠な投資と位置づけ、予算５億円、納期１２ヶ月という厳格な制約条件を設けていた。この予算には、将来的な運用保守費削減への強い期待も含まれていた。

１．２．不確かさの内容、コストへの影響、及び認識共有

１）コスト見積りに影響を与える不確かさ

　本プロジェクトのコスト見積りには、性質の異なる二種類の不確かさが存在した。第一は、長年の改修で既存システムの仕様書が現存せず、技術的負債も不明という、多くの関係者が認識済みの「技術的な不確かさ」である。
　一方で私は、これとは別に、より検知が困難な第二の「ビジネスプロセスに起因する不確かさ」の存在を強く懸念していた。１５年の運用の中で、公式手順とは異なる非公式な業務ルールが定着し、それに伴うデータの非整合性が蓄積されている可能性を危惧していた。

２）不確かさの影響と認識共有のために実施したこと

　ステークホルダ説明会において、私は二つのリスクを段階的に提示した。まず、技術的リスクだけでもコストが予算を超過する可能性が高いという分析結果を、三点見積りを用いて示した。その上で、「この試算は、業務ルールが論理的に一貫しているという前提に立つ。もし業務プロセス自体に根深い問題が発見された場合、コストはこれを更に上回る」と明確に注意喚起した。
　この報告の狙いは、安易な楽観論を牽制し、プロジェクトが抱える課題は技術面だけでなく業務面にも存在するという共通認識を、初期段階でステークホルダと形成することにあった。

（７９７文字）

設問イ

２．不確かさに関する計画段階でのステークホルダとの合意事項

２．１．予測活動の内容とステークホルダとの協力内容

１）技術的な不確かさを解消するための予測活動

　前述の二種類の不確かさに対し、私は計画段階でまず、具体的に着手可能な「技術的な不確かさ」の解消を優先する方針を立て、ステークホルダと合意した。そのための予測活動として、技術リスクを体系的に評価するため、第一に３か月間をかけた現行システムの詳細調査を、第二にＰｏＣ（概念実証）の実施を定義した。調査では仕様や技術的負債を、ＰｏＣでは性能要件や移行方式のリスクを定量化することが目的であった。重要な点は、これらの活動目的を「ＩＴ側面における見積り精度向上」に主眼を置くと定義し、ビジネスプロセスに内在する課題までを保証するものではない、という前提を確立したことである。

２）予測活動における協力体制

　予測活動における協力体制では、各ステークホルダとの役割を明確にした。業務部門には、現行業務フローの説明に加え、データの品質や例外処理の実態に関する情報提供も依頼した。しかし、日常業務に追われる担当者レベルでは具体的な問題として認識されておらず、協力を得ることに困難が伴った。私は、この情報不足が将来的な手戻りの原因となりうる重大なリスクであると月次の報告会で繰り返し指摘し、部門長との交渉の末、月次の定例会で必ず状況を確認することを約束させた。情報システム部門には、技術調査における専門知識の提供と環境準備で協力を取り付けた。経営陣には、月次報告会での迅速な意思決定、特に部門間の調整が難航した場合のトップダウンでの判断を期待すると伝えた。

２．２．再見積りの条件とコスト差異への対応方針

１）コストの再見積りのタイミングを決める条件

　見積り精度を段階的に向上させるため、再見積りのタイミングとして五つの条件を設定し、合意を得た。計画的なタイミングとして、①現行システム調査完了時点、②ＰｏＣ結果評価完了時点、③要件定義書承認時点、④基本設計完了時点の四つを設定した。
　これに加え、私は前述のビジネスプロセスへの懸念から、⑤「予測活動で想定していなかった重大なビジネス課題が発覚した場合」にも緊急で再見積りを実施するという条件の追加を提案した。当初、経営陣からは「予測活動で全てを明らかにするべきだ」との意見も出たが、私は数年前に同様の課題で頓挫した他部門のプロジェクトの失敗事例を提示した。その上で、初期調査の網羅性には限界があり、未知のリスクを許容しない計画はかえって非現実的であること、そしてリスク顕在化時の迅速な再計画こそがプロジェクトの損失を最小化する、と説得し最終的に承認された。これは、私が最も危惧していた潜在リスクへの対応をプロジェクトの正式な管理手順に組み込む、重要な取り決めであった。

２）再見積りコストと予算との差異への対応方針

　差異発生時に備え、４段階の対応方針を定義し合意した。第一に、差異が１０％以内の場合は、私の裁量で優先度の低い機能の延期等で吸収する。第二に、差異が１０％超２０％以内の場合は、段階的リリースにより費用を複数年度に分散させる。第三に、差異が２０％を超える場合は、ステアリングコミッティで、スコープ調整や予算見直し、最悪の場合にはプロジェクトの中止も含む、総合的な経営判断を仰ぐ。第四に、これらの対応とは別に、コンティンジェンシー予算を１０％確保した。ただしこの予算は、主に予測活動で特定が見込まれる技術的リスクを対象とすると明確化した。ビジネスプロセスに起因する課題は、その影響規模が事業そのものに影響を与えるため、経営層が判断すべき重大事項であると定義したためである。この事前合意が、後の円滑な意思決定に繋がった。

（１５７５文字）

設問ウ

３．実行段階における再見積りと差異への対応

３．１．ビジネスリスク顕在化に伴う再見積りの実施

１）再見積りの実施タイミング

　データ移行テストのフェーズにおいて、かねてから危惧していたビジネスプロセス上のリスクが顕在化した。新旧システムで計算結果が合わない事象が多発し、原因を詳細に調査した結果、ＩＴシステムの不具合ではなく、長年の運用で現場に定着した非公式な業務ルールと、それに起因するデータの不整合が根本原因であると特定した。これは、もはやＩＴチームだけでは解決不可能な、全社的な業務プロセスの見直しを要する問題であった。この重大な業務課題の発覚を受け、私は計画時に合意した条件に基づき、緊急でコストの再見積りを実施した。

２）再見積りしたコストと予算との差異の内容

　再見積りの結果、このビジネス課題を解決するには、非公式ルールを整理し業務プロセスを再定義した上で、大規模なデータクレンジングと追加開発が必要だと判明した。これは実質的なスコープ追加であり、この解決に１．２億円の追加コストが発生した。結果、総コストは６．２億円となり、当初予算５億円に対し２４％の超過となった。私は、このコスト増は当初のＩＴ開発における見積りの失敗ではなく、解決すべき業務上の課題が明らかになったことによるものと分析の上で報告した。

３．２．承認を得た対応策と組織的改善への貢献

１）困難な合意形成を経て承認された差異への対応策

　ステアリングコミッティにおいて、経営陣からは当初、「見積りの甘さではないか」と厳しく追及された。しかし、私は初期に注意喚起していたビジネスリスクが顕在化した事実をデータに基づき説明し、本プロジェクトを単なる「システム刷新」から会社の業務そのものを見直す「業務改革プロジェクト」へと再定義することを提案した。これにより、目先のコストではなく、将来の事業競争力強化という、より高い視点での投資対効果を訴えた。このロジックが功を奏し、プロジェクト中止という最悪の事態を回避し、段階的リリースを主軸とする対応策について最終的な承認を得た。

２）仕組みの課題分析と組織への提言

　私は、今回の予算超過という結果を、まず自身の課題として真摯に受け止め反省した。その上で、これを個人の問題に留めず、根本原因は技術リスクだけでなく業務プロセスに内在するリスクを初期段階で体系的に評価する「仕組み」が、我々の組織に欠如していたことにあると結論付けた。この学びに基づき、私は再発防止策として、今後の大規模プロジェクトでは計画フェーズの前に、専門チームによる事前の業務プロセス評価を必須プロセスとして導入することを、ＣＩＯに正式に提言した。この提言は承認され、本プロジェクトの教訓は、組織全体のプロジェクトマネジメント標準を一段引き上げるという、大きな成果に繋がった。

（１１９４文字）

まとめ

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

参考図書

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

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

created by Rinker

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

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

created by Rinker

【令和６年度：問２：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Sat, 02 Aug 2025 05:11:55 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

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

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

問題文および設問は、下記にてご確認ください。

【令和６年度：問２：クラウド移行編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

令和6年度プロジェクトマネージャ試験午後Ⅱ（問2）のクラウド移行をテーマにしたサンプル解答を掲載。実務経験者が実際にまとめた合格レベルの論文例で、試験対策や答案作成の参考に役立ちます。

解答例

設問ア

１．プロジェクトの概要と直面した問題

１．１．プロジェクトの概要とチームが抱えていた課題

　私が担当したプロジェクトは、ある製造業の基幹システム老朽化対応で、在庫管理機能を汎用機のＣＯＢＯＬからオープン系のＪａｖａへ移行する内容であった。私はプロジェクトマネージャ（ＰＭ）として本プロジェクトに発足時から参画した。
　チームの構成は、現行システムの仕様に精通するベテラン技術者２名と、Ｊａｖａ開発経験が豊富な中堅・若手技術者５名の計７名である。この体制には、現行システムの仕様、特に文書化が不十分な業務ロジックの知識が特定のベテラン要員に集中している課題があった。過去の度重なる仕様変更が、納期優先で場当たり的に行われ、ドキュメントの更新が後回しにされてきた経緯がある。これは担当者の不在が即、業務停滞に繋がる典型的な属人化リスクであり、当初から懸念事項として認識していた。

１．２．発生した複合的な問題とその影響分析

　プロジェクト開始６ヶ月後、二つの予期せぬ外部環境の変化が発生した。一つは、属人化リスクの中心であったベテラン技術者のうち１名が、家庭の事情で急遽退職したことである。もう一つは、主要顧客の事業計画変更に伴い、当初１８ヶ月の開発期間を３ヶ月短縮するよう経営層から強い要求を受けたことである。
　私はこの二つの変化に対し、その問題の性質が根本的に異なると判断し、影響の大きさと対応の緊急度で評価した。「担当者固有のノウハウ喪失」は、対策を講じなければ確実に品質低下に繋がる内部の問題である。一方、「納期短縮要求」は、交渉によって解決策を模索できる外部との調整の問題である。この性質の違いから、まずはコントロール可能で緊急度の高い、内部の問題解決に最優先で着手した。開発チームを立て直すことが、あらゆる外部交渉の前提となると判断したからである。

（７８４文字）

設問イ

２．悪化したチーム状態の改善に向けたリーダーシップの選択と行動

２．１．外部環境の変化によって悪化したプロジェクトチームの状態

　ベテラン技術者の退職と納期短縮要求の結果、プロジェクトチームの状態は深刻に悪化した。まず、現行システムの解析作業が、残された１名のベテランメンバーに集中してボトルネック状態に陥り、全体の進捗が停滞した。
　次に、チームの士気が著しく低下した。中堅・若手メンバーは、自身の持つＪａｖａスキルでは目の前のＣＯＢＯＬ解析に貢献できず、「貢献したい」という高い意欲を持ちながら、具体的な行動に移せないことへの無力感を個人面談で口にした。週次の進捗会議では、責任の所在を巡って非難めいた発言が交わされ、活発な議論は失われた。チーム内の心理的安全性は損なわれ、協力体制の連携が著しく損なわれていた。

２．２．把握した個々のメンバーの状況とリーダーシップ方針の決定

　この状況を打開するため、私はメンバーの業務遂行能力と意欲の組み合わせによって、自身の関与の仕方を変える方針を立てた。

１）過負荷状態のベテランメンバー

　個人面談を通じ、本人が強い責任感から問題を一人で抱え込み、精神的・肉体的に疲弊していると把握した。どの作業から手をつけるべきか判断できず、思考が停止しかけている様子であった。このままでは本人の健康問題だけでなく、プロジェクトが深刻な停滞に陥る懸念があったため、トップダウンで明確な方向性を示す「指示的リーダーシップ」を選択した。

２）不安を抱える中堅・若手メンバー

　個人面談において、彼らがプロジェクトへの強い貢献意欲を示す一方で、「ＣＯＢＯＬの知識がないため、どう手伝えばよいか分からない」と、行動に移れないことへの不安を表明していると把握した。高い貢献意欲がありながら行動手段を欠く状態が、彼らの無力感と士気の低下に繋がっていると判断し、具体的な作業機会と、それを円滑に進めるための支援を提供することが不可欠と考え、「支援的リーダーシップ」及び「参加型リーダーシップ」を選択した。

２．３．方針に基づく具体的な行動とステークホルダーとの調整

　私は選択したリーダーシップに基づき、具体的な行動を段階的に実施した。

１）初期対応

　まず、疲弊しているベテランに対し、彼の責任範囲と明確に定めた上で、事業影響度が最も高い「リアルタイム在庫照会」「棚卸し差分更新」「出荷指示データ連携」の３機能に絞って作業するよう指示をした。

２）チーム再建

　次に、チーム全体の課題解決のため、「ペアプログラミング制度」の導入を提案した。当初、外部専門家を一時的に活用することも検討したが、当社の特殊な業務知識の習得に時間を要し、即戦力にはなり得ないと判断したため、この案は採用しなかった。「ただでさえ時間がないのに、二人がかりの作業は非効率だ」との反対意見が出たが、類似プロジェクトのデータを基に試算した生産性の情報を提示し、また影響範囲の小さい「商品マスタ参照機能」の開発で試行し、効果を実証することで合意にこぎつけた。この際、ペア作業に伴う新たなリスクとして、メンバー間の相性問題も想定し、いつでも相談できるよう、私との週１回の個別面談を制度に組み込むことで、メンバーの不安を軽減した。

３）外部との調整

　並行して、納期短縮要求に対しては、私が作成した影響分析の結果を経営層に報告した。その資料には、「このままでは進捗が最大で２ヶ月遅延する見込みであること」「チーム再建策を実施すれば遅延は１ヶ月に圧縮できる可能性があること」「しかし、それ以上の短縮は品質を著しく損なうリスクがあること」を定量的に記述した。この報告を基に、チーム再建策の実施を条件に、１ヶ月の猶予期間を確保することで正式に合意した。

（１５８３文字）

設問ウ

３．リーダーシップ発揮後の成果と評価

３．１．改善したプロジェクトチームの状態

　リーダーシップを発揮した結果、プロジェクトチームの状態は大幅に改善した。
　定量的には、導入したペアプログラミング制度により、週次で計測していた解析済みのファンクションポイント数が導入前の平均１．５倍に向上し、遅延していたスケジュールが回復軌道に乗った。
　定性的には、チーム内の雰囲気が大きく改善し、若手からベテランへ仕様の意図を問う質問が活発に出るようになった。しかし、試行導入したペアの一つで、生産性が上がらない問題が発生した。ペア双方の週次報告書で成果の記述が少なく、進捗が形式的であったことから問題を察知した。個別の面談を行った結果、技術的なスキル差から若手側が遠慮し、ベテラン側もどう教えてよいか戸惑っていることが原因だと判断した。そこで私が仲介し、ペアの役割を「コードを書く人」と「横で助言・レビューする人」として明確化することで、関係が改善し、生産性が向上した。

３．２．プロジェクトへの貢献と今後の改善点

　チームの生産性向上は、外部環境の変化への対応においても大きな力となった。１ヶ月後、私は経営層と再交渉の場を設け、以下の二点を提示した。第一に、生産性が１．５倍に向上した実績データを基に、現実的に達成可能な納期は「当初計画の１ヶ月前倒し」であること。第二に、これ以上の短縮は、文書化不足という品質リスクを顕在化させ、長期的な保守コストの増大を招くこと。その上で、最重要機能である「リアルタイム在庫照会」と「出荷指示データ連携」を１ヶ月前倒しで先行リリースし、残りの「棚卸し関連機能」は当初納期通りとする分割納入案を提示した。
　この提案に対し、営業部門の担当役員から「一部の機能だけでは、現場の業務プロセスが分断されて混乱する」という強い懸念が示された。私はその懸念に同意を示した上で、「新製品の販売戦略に不可欠な在庫照会機能を先行リリースして、機会損失という事業リスクを回避する」「残りの機能は、現行プロセスを１ヶ月だけ維持すれば、業務影響は最小化できる」と、事業継続の観点でのメリットを示し、最終的に全部門の理解を得るに至った。
　今回の対応には、文書化を促す明確なプロセスや動機付けが、仕組みとして組み込まれていなかったという反省点もある。
　この経験から、私は二つの改善策を所属組織に提案し、標準化を進めている。一つは、計画段階で「スキルマップ」を用い、属人化リスクを定量的に評価し、対策を具体化しておくプロセス。もう一つは、今回のような問題解決の経験を組織知として蓄積するため、プロジェクト横断の事例共有会を定期開催する仕組みの構築である。この共有会では、単なる成功事例だけでなく、失敗事例とその原因分析も共有することで、組織全体の学習効果を高めることを狙いとしている。

（１１９８文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【令和６年度：問２：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Tue, 29 Apr 2025 10:00:25 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2020r02.html#aki_pm

問題文

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

　プロジェクトマネージャ（ＰＭ）は、プロジェクトの計画時に、プロジェクトの目標の達成に影響を与えるリスクへの対応を検討する。プロジェクトの実行中は、リスクへ適切に対応することによってプロジェクトの目標を達成することが求められる。
　プロジェクトチームの外部のステークホルダはＰＭの直接の指揮下にないので、外部のステークホルダに起因するプロジェクトの目標の達成にマイナスの影響がある問題が発生していたとしても、その発見や対応が遅れがちとなる。ＰＭはこのような事態を防ぐために、プロジェクトの計画時に、ステークホルダ分析の結果やＰＭとしての経験などから、外部のステークホルダに起因するプロジェクトの目標の達成にマイナスの影響を与える様々なリスクを特定する。続いて、これらのリスクの発生確率や影響度を推定するなど、リスクを評価してリスクへの対応の優先順位を決定し、リスクへの対応策とリスクが顕在化した時のコンティンジェンシ計画を策定する。
　プロジェクトを実行する際は、外部のステークホルダに起因するリスクへの対応策を実施するとともに、あらかじめ設定しておいたリスクの顕在化を判断するための指標に基づき状況を確認するなどの方法によってリスクを監視する。

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

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴と目標、外部のステークホルダに起因するプロジェクトの目標の達成にマイナスの影響を与えると計画時に特定した様々なリスク、及びこれらのリスクを特定した理由について、８００字以内で述べよ。

設問イ

設問アで述べた様々なリスクについてどのように評価し、どのような対応策を策定したか。また、リスクをどのような方法で監視したか。８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べたリスクへの対応策とリスクの監視の実施状況、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクトの特徴と目標、及び特定したリスク

１．１．プロジェクト概要と目標

　私が担当したプロジェクトは、化学メーカーＡ社の基幹システム刷新であり、私はプロジェクトマネージャ（ＰＭ）を務めた。目標は、保守契約が切れる次年度末までの安定稼働と、承認された総予算６０百万円の遵守であった。これらは、Ａ社の事業継続と競争力維持のため、経営上の必須要件とされていた。

１．２．外部ステークホルダに起因するリスクと特定した理由

　プロジェクト計画時にステークホルダ分析と業界動向調査を行い、ＰＭが直接管理できない外部要因から、特に以下の３点を重要リスクとして特定した。

１）利用部門からの無秩序な要求仕様変更リスク

　現行システムへの強い不満から新システムへの期待が過剰な状態であり、要件定義完了後も複数部門から個別最適化の要求が多発すると予見した。部門間の利害も絡み調整は難航し、スコープ増大によって目標達成が困難になると判断した。この内部調整の失敗はプロジェクトを最も停滞させる。

２）現行システム保守ベンダーからの情報提供遅延リスク

　本プロジェクトはリプレースであり、データ移行等のため現行システム情報の把握が不可欠だった。しかし保守契約終了を控えたベンダーは協力意欲が低く、ドキュメント不備も多かった。情報提供が遅延すれば致命的な手戻りを招き、厳格な納期達成を危うくすると判断した。

３）法規制の変更に伴う開発手戻りリスク

　私が所属する化学業界では、化学物質管理等の法規制が頻繁に強化される。業界動向から、プロジェクト中に新たな報告義務が課される可能性が高いと予測した。この種の外部からの強制的な要求変更は、開発終盤に致命的な手戻りを発生させ、プロジェクト計画を破綻させる影響があると分析した。そのため、受動的に待つのではなく能動的に情報を追跡すべきリスクだと判断した。

（８００文字）

設問イ

２．リスクの評価と対応策、及び監視方法

２．１．リスク評価の全体方針と優先順位付け

　特定した３つのリスクに対し、客観的・定量的な評価基準を定義した。具体的には、発生確率と影響度をそれぞれ５段階で評価し、両者を掛け合わせたリスクスコア（最大２５）を算出した。影響度は納期・コストへのインパクトに基づき、「影響軽微（１）」から「プロジェクト目標の達成が困難（５）」までとした。特に影響度５は、追加費用が予算の３割を超過するような致命的なレベルと定義した。
　この基準による評価の結果、各リスクスコアは、①要求仕様変更リスクが２０（発生確率４、影響度５）、②情報提供遅延リスクが１５（発生確率３、影響度５）、③法規制変更リスクが１０（発生確率２、影響度５）となった。
　このスコアに基づき、私は具体的な対応戦略を決定した。スコア１５以上のリスク（①、②）には「予防」「軽減」の両面から対策を講じ、スコア１０のリスク（③）には「予防」「監視」を主軸にコンティンジェンシ計画を厚くすることで、限られたリソースを効率的に配分する方針を採った。これにより、優先順位は①、②、③と決定した。

２．２．要求仕様変更リスクへの対応

１）評価と対応策

　スコア２０の本リスクに対し、予防策としてプロトタイピングを活用し、利用部門との認識齟齬を防止した。軽減策として、利用部門長、ＩＴ部門、ＰＭＯで構成される変更管理委員会を設置し、全ての変更要求は影響分析を経た上で当委員会で審議する。その際、要求の必要性を「緊急度」と「事業貢献度」のマトリクスで客観的に評価するよう工夫した。コンティンジェンシ計画として、承認済変更に対応するため、詳細設計フェーズの工数に１０％のバッファを確保した。

２）監視方法

　監視指標を「変更要求の週次発生件数」とし、閾値は「週に３件を超過」に設定した。超過時はＰＭＯが直ちに原因を分析しＰＭへ報告するルールとした。これにより、問題の兆候を早期に捉え、迅速な対応を可能にすることを狙った。

２．３．情報提供遅延リスクへの対応

１）評価と対応策

　スコア１５の本リスクに対し、公式な合意形成を重視した。予防策として、現行ベンダーとＳＬＡを含む覚書を締結し、「問い合わせ後３営業日以内の一次回答」等、具体的なＫＰＩを明記し協力を義務化した。コンティンジェンシ計画として、ＫＰＩ未達時の段階的なエスカレーションプロセスを事前に文書で合意した。

２）監視方法

　監視指標は覚書で定めた「回答期限遵守率」、閾値は「月次遵守率８０％未満」とした。状況は「情報提供依頼リスト」で一元管理し、週次で進捗を確認した。閾値を下回った際は、即時臨時会議で原因と対策を協議する体制を整えた。

２．４．法規制変更リスクへの対応

１）評価と対応策

　スコア１０の本リスクに対し、予防と監視に注力した。予防策として、Ａ社の法務部担当者をアドバイザとし、月次で情報共有会を実施するなど常時モニタリング体制を構築した。また業界団体の会報等の定期確認をＷＢＳに組み込んだ。軽減策として、影響を受けやすい機能を独立性の高いモジュールとして設計し、将来の改修範囲を局所化するアーキテクチャ採用を指示した。コンティンジェンシ計画として、スコアの数値から顕在化時の影響は甚大と判断し、私は経営層に働きかけ、プロジェクト総予算の５％を本リスク対応専用の予備費として確保することについて、承認を得た。

２）監視方法

　監視指標を「関連法規制の改正案に関する公表の有無」とし、前述のモニタリング体制で監視した。改正の動きを察知した際、その確度を法務部と連携して評価し、「法令の成立」をトリガーにシステムへの影響分析を即座に開始するルールとした。これにより能動的なリスクコントロールを目指した。

（１５９２文字）

設問ウ

３．リスク対応の実施状況と今後の改善点

３．１．リスク対応策と監視の実施状況と評価

１）要求仕様変更リスクへの対応結果と評価

　変更管理委員会を計画通り運営し、提出された１８件の要求を全て影響分析と客観的評価に基づき審議した。結果、８件をスコープ内で承認、残る１０件は利用部門と合意して次期開発課題とした。無秩序なスコープ増大は抑制され、納期・予算目標の達成に大きく貢献できた。客観的指標に基づく議論が円滑な合意形成に繋がったと評価している。

２）情報提供遅延リスクへの対応結果と評価

　プロジェクト中盤、現行ベンダーからの仕様書提出が２週間遅延したが、私は週次の監視でこれを２日以内に検知し、直ちにエスカレーションを発動した。まず相手方ＰＭへ催促したが解決せず、次の段階である事業部長間の会議を設定した。会議の場で私は、本遅延がプロジェクト全体に与える金銭的損失額を具体的に提示し、相手方ＰＭへの配慮をしつつも断固たる姿勢で協力を要請した。この上位レベルでの介入が功を奏し、問題発生から１週間後には情報を受領、クリティカルパスへの影響を３日間の遅延に抑制できた。リスクは顕在化したが、計画的な監視と対応が損害を最小化したと評価している。

３）法規制変更リスクへの対応結果と評価

　仕様に直接影響する法規制の成立はなかった。しかしプロジェクト終盤、モニタリング体制下の法務部より関連法改正の動きがあるとの情報を得た。私はこれをトリガーと判断し直ちに影響分析を開始、この予備調査にコンティンジェンシ予算から３０万円を使用する承認を経営層から得た。影響は軽微と判明したが、これは問題発生を待たずに能動的に兆候を捉え、計画的に対応する予防的管理の有効性を示したと評価している。

３．２．今後の改善点

　今回のリスクマネジメントは有効であったが、より高度化するため以下の改善点を認識した。

１）ステークホルダとの合意形成プロセスの強化

　情報提供遅延の解決に工数を要した反省から、次回はＳＬＡに少額のペナルティ条項を追加するなど、より強い協力への動機付けを契約段階で行うことを検討する。これにより、問題の未然防止を一層強化したい。

２）変更管理における要求元への意識改革を促す仕組み

　要求数を抑制できなかった反省から、次回は各主要部門へ「変更対応枠」として工数で提示し、超過分は部門予算とする仕組みを検討する。これにより、要求元にコスト意識と優先順位付けを促し、要求の質を高めたい。

３）組織的なリスク情報共有の仕組み化

　法務部との連携が属人的であった反省から、この経験を形式知化するため、私はＰＭＯに「組織横断的なプロジェクトリスク情報共有プロセス」の標準化を提案した。個人の経験を組織の資産とし、会社全体のリスク対応能力向上に貢献することが最終的な目的である。

（１１９６文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【令和５年度：問１】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Sat, 26 Apr 2025 04:46:13 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2023r05.html#aki_pm

問題文

問１　プロジェクトマネジメント計画の修整（テーラリング）について

　システム開発プロジェクトでは、プロジェクトの目標を達成するために、時間、コスト、品質以外に、リスク、スコープ、ステークホルダ、プロジェクトチーム、コミュニケーションなどもプロジェクトマネジメントの対象として重要である。プロジェクトマネジメント計画を作成するに当たっては、これらの対象に関するマネジメントの方法としてマネジメントの役割、責任、組織、プロセスなどを定義する必要がある。
　その際に、マネジメントの方法として定められた標準や過去に経験した事例を参照することは、プロジェクトマネジメント計画を作成する上で、効率が良くまた効果的である。しかし、個々のプロジェクトには、プロジェクトを取り巻く環境、スコープ定義の精度、ステークホルダの関与度や影響度、プロジェクトチームの成熟度やチームメンバーの構成、コミュニケーションの手段や頻度などに関して独自性がある。
　システム開発プロジェクトを適切にマネジメントするためには、参照したマネジメントの方法を、個々のプロジェクトの独自性を考慮して修整し、プロジェクトマネジメント計画を作成することが求められる。
　さらに、修整したマネジメントの方法の実行に際しては、修整の有効性をモニタリングし、その結果を評価して、必要に応じて対応する。

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

設問ア

あなたが携わったシステム開発プロジェクトの目標、その目標を達成するために、時間、コスト、品質以外に重要と考えたプロジェクトマネジメントの対象、及び重要と考えた理由について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトマネジメントの対象のうち、マネジメントの方法を修整したものは何か。修整が必要と判断した理由、及び修整した内容について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた修整したマネジメントの方法の実行に際して、修整の有効性をどのようにモニタリングしたか。モニタリングの結果とその評価、必要に応じて行った対応について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と重要視したマネジメント対象

１．１．プロジェクトの目標と概要
　私が担当したプロジェクトは、大規模な基幹業務システムのリプレースである。約２年間かけ、老朽化した現行システムを刷新し、新機能を導入することを目標とした。目標は運用保守コスト年間約２０％削減と、主要業務処理時間平均約１５％短縮であった。チームは社内開発・利用部門、外部パートナーで構成されたが、要員追加は困難で人的リソースに制約があった。システムは多様な業務を持つ複数部門が利用し、要求や利害が複雑に絡む可能性が高かった。また、全社的なＩＴリテラシにばらつきがあり、システム理解度や関与度に差があった。

１．２．重要視したプロジェクトマネジメントの対象と理由

　時間、コスト、品質に加え、特に重要と考えた対象は「ステークホルダマネジメント」であり、中でも「コミュニケーションと関与度」の管理であった。重要と考えた理由は以下の通りである。

１）部門間の認識齟齬の解消
　複数部門の要求調整やコンフリクト解消が重要だが、標準的な会議体では潜在的な懸念や認識齟齬を把握・解消しきれない。
２）ＩＴリテラシの底上げ
　利用者ＩＴリテラシにばらつきがあるため、システム仕様や変更点を分かりやすく伝え、共通理解を促す丁寧なコミュニケーションが不可欠である。
３）利用部門の積極的な参加
　プロジェクト成否は要件定義での正確な要求収集と利用部門による受け入れテスト（ＵＡＴ）への積極的な関与にかかるが、日常業務で多忙な利用部門にいかに主体的に関わってもらうかが課題となる。
　これらの課題に対処し、ステークホルダとの関係を築き、積極的な関与を促すことが、手戻り防止、仕様変更リスク低減、納期遵守と品質確保に繋がると判断し、ステークホルダマネジメントを最重要視した。

（７８８文字）

設問イ

２．ステークホルダマネジメントの修整とその内容

２．１．修整が必要と判断した理由

　前述の通り、本プロジェクトは複数利用部門とＩＴリテラシのばらつきという特性を持っていた。標準的なステークホルダマネジメント（計画説明会、定例報告会、議事録配布、個別ヒアリング）だけでは、以下のような深刻なリスクを回避できないと判断し、修整が必要と考えた。

１）大規模な手戻りや変更要求
　利用者ＩＴリテラシにばらつきがあるため、標準的な説明ではシステム仕様や業務影響の正確な理解が得られにくい。専門用語多用の資料や開発プロセスの説明はＩＴ不慣れな利用者には難しく、疑問や不安が表面化しにくい。これは、要件定義や設計段階で要求の曖昧さが残り、後工程での手戻りや仕様変更多発を招くリスクを高めた。
２）重大な品質問題の発生
　利用部門担当者は定常業務で多忙であり、標準的な依頼だけでは仕様確認やＵＡＴに十分な時間を割いてもらえない。ＵＡＴは品質確保に必須だが、関与が得られないと形骸化や遅延リスクがあり、潜在的問題が見過ごされ本番稼働後の重大な業務停止やデータ破損に繋がる可能性があった。
　これらの状況は、厳しい納期と限られた開発予算という制約下で、プロジェクト目標達成を極めて困難にする。手戻りや品質問題はコスト超過と納期遅延に直結するため、標準方法ではなく、プロジェクト特性に合わせた積極的・丁寧なマネジメントへの修整が必須と判断した。特に、初期フェーズでのステークホルダ理解・関与を徹底し、後工程のリスクを減らし全体最適を目指すことが重要と考えた。

２．２．修整した内容

　修整の必要性に基づき、コミュニケーション多様化と関与度向上の施策を具体的に実行した。

１）コミュニケーション方法の多様化と頻度増加
　定例報告会に加え、部門の業務・ＩＴリテラシに合わせた「部門別・階層別ワークショップ」を週１回程度実施。ここでは、技術説明より各部門業務への適合や操作に焦点を当てた。資料は専門用語を避け、画面イメージや図を多用してイメージしやすい工夫を行った。また、少人数制やブレイクアウトルームで質問しやすい雰囲気を作る、「プロトタイプを用いたシステム操作デモ」を隔週実施するなど、具体的な利用イメージと早期フィードバックを促進した。さらに、複雑な要求や部門間認識差は「個別説明会」で関係者を集め合意形成を図った。
２）ステークホルダ関与度向上のための工夫
　利用部門から「部門内キーパーソン」を２～３名選定し、早期に集中的な「研修プログラム」（２週間）を実施。キーパーソンが自部門内での一次対応、情報展開、ＵＡＴサポートを担えるように育成した。キーパーソンを研修プログラムに参加させることで、利用部門に一時的な負荷増が見込まれたが、部門自身の業務効率化・理解度向上に繋がるメリットを説明して理解を求めた。さらに利用部門の部門長からも、現場メンバーにプロジェクトの重要性を説明してもらい、さらなる理解を求めた。
３）経営資源配分
　要件定義～ＵＡＴ準備といった初期・中盤工程にこれらリソースを、当初よりも５％分追加して配分することにした。これは、初期段階でステークホルダ理解と仕様確定精度を高める目的があった。当初計画での、後工程（開発、テスト、移行）での大規模な手戻りコストを、１５％増と試算したため、リソース追加は全体を通して効率的な配分であるとと考えた。

（１４４９文字）

設問ウ

３．ステークホルダマネジメントのモニタリングと評価

３．１．モニタリング方法

　修整したステークホルダマネジメントの有効性を把握するため、以下の方法でモニタリングした。

１）問い合わせ内容の分析
　プロジェクト専用問い合わせ窓口への「件数・内容」を週次で集計・分析した。利用者の疑問や懸念が集中する箇所、内容の変化（仕様→操作）を把握。件数の多い項目はパレート図で可視化し、理解不足箇所の特定に活用した。その結果は、その後のワークショップに反映した。
２）アンケート実施
　ワークショップ等の終了後、参加者に「システム理解度・満足度、懸念事項」に関する簡単なアンケートを実施した。回答率、理解度・満足度の推移を追跡し、施策効果を定量評価した。理解度が低い参加者や特定の懸念を挙げた参加者には、個別にフォローアップを実施した。
３）ＵＡＴでの課題分析
　ＵＡＴフェーズでは、「進捗率と課題発生状況」を日次で追跡し、進捗、発生課題の件数・内容・重要度・解決状況から傾向を分析した。課題は管理ツールに記録し、重要度の高い課題については、関係者を集めた緊急会議で迅速な解決策を協議した。

３．２．モニタリング結果と評価

　上記のモニタリングの結果、修整したステークホルダマネジメント方法は概ね有効に機能した。

１）モニタリングの結果
　初期の仕様問い合わせはワークショップ等で減少し、後半は操作質問中心になった。問い合わせ分析で頻出箇所特定により、活動焦点を絞れた。アンケートでワークショップ等の理解促進・満足度向上を確認した。キーパーソンが自部門理解促進・一次解決に貢献し、問い合わせ集中を防いだ。ＵＡＴは計画通り完了した。課題は想定範囲で少なく軽微なものが中心だった。これは手戻り抑制、早期理解、迅速課題解決体制の効果であった。
２）評価
　修整（コミュニケーション多様化、キーパーソン育成等）は、ステークホルダ理解と関与度向上に効果的だった。懸念された手戻りやＵＡＴ不備による品質問題といった、コスト超過・遅延に直結する重大リスクを大幅に低減できた。限られた予算・人的リソース制約下での初期フェーズ重点投入は、後工程リスク回避に繋がり、全体コスト・納期遵守に対し費用対効果が高かった。
３）必要に応じて行った対応
　モニタリング結果に基づき迅速に対応した。具体的には、理解不足箇所や懸念項目はＦＡＱ更新・拡充、追加ワークショップで再説明したり、ＵＡＴ重要課題は緊急会議で原因究明・迅速に対応した。特定の部門ＵＡＴ遅延時は、キーパーソンと連携し、原因特定、計画見直し、追加支援を実施することにした。

　本プロジェクトでの経験は、テーラリング、モニタリング、迅速対応の重要性を再認識させ、今後のノウハウとなった。

（１１８６文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【令和３年度：問１：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Sun, 27 Apr 2025 08:13:24 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2021r03.html#aki_pm

問題文

問１　システム開発プロジェクトにおけるプロジェクトチーム内の対立の解消について

　プロジェクトマネージャ（ＰＭ）は、プロジェクトの目標の達成に向け継続的にプロジェクトチームをマネジメントし、プロジェクトを円滑に推進しなければならない。
　プロジェクトの実行中には、作業の進め方をめぐって様々な意見や認識の相違がプロジェクトチーム内に生じることがある。チームで作業するからにはこれらの相違が発生することは避けられないが、これらの相違がなくならない状態が続くと、プロジェクトの円滑な推進にマイナスの影響を与えるような事態（以下、対立という）に発展することがある。
　ＰＭは、プロジェクトチームの意識を統一するための行動の基本原則を定め、メンバに周知し、遵守させる。プロジェクトの実行中に、プロジェクトチームの状況から対立の兆候を察知した場合、対立に発展しないように行動の基本原則に従うように促し、プロジェクトチーム内の関係を改善する。
　しかし、行動の基本原則に従っていても意見や認識の相違が対立に発展してしまうことがある。その場合は、原因を分析して対立を解消するとともに、行動の基本原則を改善し、遵守を徹底させることによって、継続的にプロジェクトチームをマネジメントする必要がある。

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

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴、あなたが定めた行動の基本原則とプロジェクトチームの状況から察知した対立の兆候について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトの実行中に作業の進め方をめぐって発生した対立と、あなたが実施した対立の解消策及び行動の基本原則の改善策について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた対立の解消策と行動の基本原則の改善策の実施状況及び評価と、今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクトの特徴、行動の基本原則、及び対立の兆候

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

　私がプロジェクトマネージャとして参画したプロジェクトは、企業の基盤を支える顧客管理システム（ＣＲＭ）を刷新する大規模開発だった。老朽化による運用コスト増大と、事業変化の対応遅れ解消が目的だった。このプロジェクトは、複数の事業部門、外部開発・運用ベンダーなどの多様な関係者が参画、既存システムのブラックボックス化による関係者間の前提知識のばらつき、という特徴があった。

１．２．行動の基本原則

　多様なチームメンバーが一体となるため、私が定めた「行動の基本原則」は以下の３点である。

１）事実に基づき、建設的に対話する。
２）相手の立場を理解し、尊重する。
３）プロジェクト全体の成功を最優先とする。

　これらの原則は、キックオフや週次会議で繰り返し説明し、プロジェクト憲章に明記して周知した。

１．３．対立の兆候

　設計後半から開発フェーズで、仕様詳細化やデータ移行方法の検討が進む中、開発チームと事業部門（オペレーション担当者）間で意見の相違が見られた。データ移行時のクレンジングや突合処理の自動化範囲で認識の乖離が顕著になった。議論が深まらず、定例会議での発言が減る一方、会議後に非公式な場で「現場の作業が大変になる」「やり方が違いすぎる」といった不安や不満が漏れ始めた。これは、事業部門が新システムをイメージできず漠然とした不安を抱え、それを開発チームに効果的に伝えられていないことを示唆していた。開発チーム側も懸念の具体像を把握できていなかった。このコミュニケーション停滞と非公式な不満増加は、行動原則に基づいた対話ができていない兆候であり、明確な対立に発展し遅延を招くリスクが高いと判断した。

（７７２文字）

設問イ

２．発生した対立、解消策、及び行動の基本原則の改善策

２．１．発生した対立とその原因

　前述の兆候は、顧客データの移行におけるデータクレンジングと突合処理の方法論に関する、開発チームと事業部門間の対立に発展した。開発チームは、納期・コスト制約の中で効率性を優先し、自動化ツールを用いた高度なデータクレンジング・突合処理を提案した。人的ミスを減らし、短期間で大量処理できる技術的優位性を主張した。一方、事業部門は過去の品質問題から、手作業による目視確認と経験に基づいた個別判断による突合を主張した。自動化では対応できない複雑なデータや顧客個別の判断が必要なケースが多く、正確性には現場の知見が不可欠と考えた。
　この対立の原因を理解するため、両チーム主要メンバーにヒアリングした結果、以下の要因が判明した。

・技術的知識の格差とコミュニケーションの壁
　開発チームは技術的合理性を優先したが、事業部門の業務や運用上の懸念への配慮が不足。事業部門は技術知識が乏しく説明を理解できず、「慣れた手作業が安全」と考えた。
・「行動の基本原則」の実践不足
　特に「相手の立場を理解し、尊重する」原則が機能せず、互いの状況理解に努めなかった。「事実に基づき対話する」原則も知識差により困難だった。
・情報の非対称性
　データ移行の詳細手順や懸念（特殊ケース、手作業の具体例）が両チーム間で十分に共有されていなかった。

　対立の結果、データ移行方式の決定が遅れ、後続のテスト・研修計画に遅延が発生し、納期遵守が困難になった。チーム間の信頼関係も損なわれ、他の検討事項にも非協力的な態度が見られた。

２．２．対立の解消策

　この対立を解消するため、以下の施策を実施した。

１）対立の構造の可視化と原因の共有
　ヒアリング結果を合同ワークショップで共有した。対立が個人間でなく、知識・コミュニケーション不足といった構造要因であると説明し、共通課題として認識させた。
２）相互理解のための体験会と説明会の実施
　開発チームは、自動化ツールの「体験型デモンストレーション」を事業部門向けに実施し、処理の様子、自動判断ケース・困難ケースを業務用語で解説した。事業部門は、複雑なデータ構造や過去問題事例を「懸念事例共有会」で具体的に説明した。これにより、互いの技術や業務を具体的に理解できた。
３）ＰｏＣ（概念実証）の実施提案
　事実に基づく意思決定のため、限定データで自動化処理のＰｏＣを提案した。処理速度、誤り率、手作業工数を定量評価し、事業部門の不安を具体データで検証し、両チームの共通理解を深めた。
４）共同での折衷案検討と合意形成
　ＰｏＣの結果に基づいて両チームで議論を再開し、「自動化ツールによる一次処理＋手作業による最終確認」のハイブリッド方式で合意した。私は中立的なファシリテーターとしてリードし、行動原則に立ち返るよう促した。

２．３．行動の基本原則の改善策

　今回、知識差がコミュニケーションの阻害要因となることが判明したため、行動基本原則に以下２点を追加した。

１）専門知識のギャップを埋める努力をする
　互いの専門領域を理解し合う双方向の努力をし、専門用語回避、図やデモ活用を推奨する。
２）分かりやすい情報共有に努める
　重要な情報は、全ての関連ステークホルダーに早期に、彼らの視点で分かりやすく共有する。共有タイミングと質にも配慮する。

　上記追加は、対立解消後の全体会議で経緯と共に周知した。具体的な行動例を交え、メンバーが自分事として捉えられるよう努めた。また、チーム間連携が必要なマイルストーンでは、必ず懸念点を共有するプロセスを定義した。具体的な行動を定着させる狙いがあった。

（１５９４文字）

設問ウ

３．解消策と改善策の実施状況、評価、及び今後の改善点

３．１．解消策と改善策の実施状況と評価

１）対立解消策の実施状況と評価
　対立解消策（原因可視化、ワークショップ、ＰｏＣ、共同検討）は狙い通り機能した。ＰｏＣで自動化技術の能力・限界をデータで確認できたことが、事業部門の不安をリスクとして捉え直すのに有効だった。開発チームも事業部門のこだわりを理解でき、問題解決型の議論に転換できた。ハイブリッド方式に合意できたことで、遅延していた計画策定を速やかに開始でき、納期遅延リスクを回避できた。最も重要な成果は、損なわれかけていた開発チームと事業部門間の信頼関係が回復し、互いに協力する姿勢が見られたことである。これにより、要求再確認やＵＡＴが円滑に進み、品質向上に繋がった。
２）行動の基本原則改善策の実施状況と評価
　改善・追加した行動基本原則の周知と、コミュニケーション計画への反映は、プロジェクト後半のチーム間連携を強化する上で有効であった。ＵＡＴフェーズでは、開発チームが環境やデータ状況を事業部門に分かりやすく共有し、迅速かつ丁寧に対応するようになった。事業部門側も、発見した不具合や改善要望を、具体的な操作手順や期待する結果を明確に記載した形で開発チームに報告するようになった。運用引き継ぎに向けては、技術情報の非対称性解消と運用部門の不安軽減を期待して、開発チームと運用部門は合同勉強会や手順書レビューを早期に実施した。結果、後半は認識齟齬による大きな問題なく、円滑な情報連携が可能となった。追加した基本原則は行動指針として受け入れられ、チーム全体の協調性・問題解決能力を高める上で期待以上の効果があった。結果、品質目標を達成し、無事本番稼働を迎えることができた。

３．２．今後の改善点

　今回、対立の兆候を早期察知し、予防的な働きかけが重要性であると痛感した。今後は以下の点を改善する。

１）非公式コミュニケーションチャネル強化
　主要メンバーとの１対１ミーティングや、ランチミーティングなどの非公式な交流機会を設定し、公式な場では出にくい懸念や人間関係の機微を早期に吸い上げる。
２）チーム状態診断サーベイ定期実施
　匿名アンケートで、連携満足度、行動原則遵守度等を定期的にデータで把握し、潜在的問題の早期対策を可能にする。
３）全メンバー対象コミュニケーション研修導入
　対立の予防と解消に主体的に貢献できる能力を高めるため、異なるバックグラウンドを持つ人との対話、相手視点での説明、アクティブリスニング研修を実施する。

　これらの改善点により、多様な意見を建設的議論に繋げられる、レジリエントでパフォーマンスの高いチームを構築できると考える。

（１１６０文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【平成３０年度：問１：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Fri, 02 May 2025 05:41:11 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2018h30.html#haru_pm

問題文

問１　システム開発プロジェクトにおける非機能要件に関する関係部門との連携について

　システム開発プロジェクトにおいて、プロジェクトマネージャ（ＰＭ）は、業務そのものに関わる機能要件に加えて、可用性、性能などに関わる非機能要件についても確実に要件が満たされるようにマネジメントしなければならない。特に非機能要件については、利用部門や運用部門など（以下、関係部門という）と連携を図り、その際、例えば、次のような点に注意を払う必要がある。
・非機能要件が関係部門にとってどのような意義をもつかについて関係部門と認識を合わせる
・非機能要件に対して関係部門が関わることの重要性について関係部門と認識を合わせる
　このような点に注意が十分に払われないと、関係部門との連携が不十分となり、システム受入れテストの段階で不満が続出するなどして、場合によっては納期などに大きく影響する問題になることがある。関係部門と連携を図るに当たって、ＰＭはまずプロジェクト計画の段階で、要件定義を始めとする各工程について、非機能要件に関するＷＢＳを設定し、ＷＢＳの各タスクの内容と関係部門を定め、関係部門の役割を明確にする。次に、関係部門と十分な連携を図るための取組みについて検討する。それらの内容をプロジェクト計画に反映した上で、関係部門を巻き込みながら一体となってプロジェクトを推進する。

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

設問ア

あなたが携わったシステム開発プロジェクトの特徴、代表的な非機能要件の概要、並びにその非機能要件に関して関係部門と連携を図る際に注意を払う必要があった点及びその理由について、８００字以内で述べよ。

設問イ

設問アで述べた代表的な非機能要件に関し、関係部門と十分な連携を図るために検討して実施した取組みについて、主なタスクの内容と関係部門、及び関係部門の役割とともに、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた取組みに関する実施結果の評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクトと非機能要件の概要

１．１．プロジェクト概要
　私が担当したプロジェクトは、全国数百店舗を持つ大手小売業向け新ＰＯＳシステムの導入である。目的は、既存システムの老朽化対策と、リアルタイムの売上・在庫連携強化による迅速な経営判断、顧客サービス向上であった。特徴は、既存システムとの複雑なデータ連携、クリスマス商戦前の１１月完了というタイトな納期、予算と情報システム部の運用要員という経営資源の制約であった。

１．２．代表的な非機能要件の概要
　本プロジェクトで特に重視した非機能要件は「性能」と「運用性」であり、関係部門との連携で注意が必要だった。
１）性能要件：ピーク時応答時間３秒以内
　これは、顧客満足度維持に直結する重要要件だった。しかし、関係部門間で認識のずれがあり、注意が必要だった。利用部門（店舗運営部、商品部）は感覚的に速さを求める一方、目標値のビジネスインパクト（レジ待ち短縮効果等）への理解が不足していた。対して運用部門（情報システム部）は、高性能インフラのコスト増を懸念し、目標値の妥当性に慎重だった。このずれは、テストでの性能未達や過剰スペックのリスクを生む。顧客満足度向上という経営戦略達成のため、関係部門間で性能要件の意義と目標値の根拠ある合意形成が不可欠だった。
２）運用性要件：目標復旧時間（ＲＴＯ）１時間以内、および限られた運用要員での対応可能な障害手順の簡便化。
　運用部門（情報システム部）と外部保守ベンダー間で、障害時の役割分担（作業範囲、責任、スキル）が曖昧だった点に注意が必要だった。特に、一次切り分けの主体やエスカレーション基準が不明確だった。この状態は、迅速な対応を阻害しＲＴＯ未達や販売機会損失のリスクを生む。限られた人的リソース下での効率的な運用体制構築のため、役割分担の明確化が急務だった。

（７９３文字）

設問イ

２．関係部門との連携強化のための取組み

　非機能要件に関する部門間連携の課題解決のため、以下の取組みを実施した。

２．１．プロジェクト計画段階での取組み

　計画段階で、非機能要件のタスクと責任体制を明確化した。
１）非機能要件に関するＷＢＳの明確化
　非機能要件定義、性能目標設定、性能テスト、運用テスト、障害復旧検証等のタスクをＷＢＳに設定した。非機能要件に関する作業をプロジェクト全体の中で可視化する必要があると考えたからである。
２）役割分担の明確化
　ＷＢＳタスク毎に、関係部門の役割と責任を役割分担表（ＲＡＣＩ）で定義し、関係部門代表者会議で合意した。例えば「性能目標設定」では、利用部門を「協業先（ビジネス要件提示）」、運用部門を「協業先（実現可能性・コスト評価）」、開発チームを「実行責任者」、ＰＭを「説明責任者」と定義した。「誰が何に責任を持ち」「誰と協力し」「誰に報告・相談すべきか」を、明確にすることが目的だった。
３）非機能要件専門チーム設置
　ＰＭ、開発リーダー、インフラ担当、利用・運用部門代表から成るチームを組成し、週次定例会議を設定した。非機能要件の課題を、部門横断での解決する機能が必要だからである。

２．２．性能要件に関する取組み

　性能要件の認識ずれ解消と合意形成のため、以下を実施した。
１）ワークショップ開催
　共通目標に向けた建設的な議論の場として、利用・運用部門、開発チームの主要メンバーで、応答時間とビジネスインパクト（レジ待ち時間等）の関係分析、性能目標値（３秒以内）の妥当性検証と合意などを行う、ワークショップを開催した。利用部門は実オペレーションに基づく要件提示、運用部門はインフラ構成案とコスト・実現可能性評価、開発チームは技術的実現方法提示を担った。特に、応答時間悪化時の影響をシミュレーションしたことが、目標値の妥当性合意に有効だった。
２）性能テスト計画への早期関与
　性能要件が確実に満たされることを確認するため、性能テスト計画の策定段階から利用部門と運用部門に関与してもらった。主なタスクは、業務シナリオに基づくテストケースの作成、本番環境に近いテスト環境の準備協力、テスト結果の評価であった。利用部門は「ピーク時の業務シナリオ（商品点数、同時利用レジ数など）の提供」、運用部門は「本番環境のインフラ構成や運用負荷を考慮したテスト環境の評価や、テスト結果からインフラサイジングの妥当性判断」の役割を担った。

２．３．運用性要件に関する取組み

　役割分担の曖昧さ解消と迅速な復旧体制構築のため、以下を実施した。
１）障害復旧手順の共同策定と役割明確化
　障害パターン洗い出し、切り分け・復旧手順書作成、ＲＡＣＩに基づく各手順書における役割明確にするため、運用部門、外部保守ベンダー、開発チームが共同で障害復旧手順を策定するタスクを設けた。運用部門は「主体的な手順策定と実現性評価」、外部ベンダーは「技術知見の提供とサポート範囲・連携方法の明確化」、開発チーム「技術情報の提供」を担った。これは、共同策定を通じて、運用部門の当事者意識を向上する狙いがあった。
２）運用テスト（障害復旧訓練）の共同実施
　障害復旧手順の実効性確認と連携強化のため、運用部門と外部ベンダーが共同で障害復旧訓練を実施した。具体的には、訓練シナリオ作成、訓練実施、結果評価と手順書へのフィードバックを実施した。運用部門は訓練計画・実行と評価、外部ベンダーはサポート体制機能確認を担った。また、訓練結果に基づき、手順書の不明確な点や連携上の課題を洗い出し、改善サイクルを回すプロセスとした。共同訓練は、机上の手順を実践的にスキルに昇華させ、スムーズな連携を確実にする上で不可欠だった。

（１５９６文字）

設問ウ

３．取組みの評価と今後の改善点

３．１．実施結果の評価
　前述の取組みは、プロジェクト目標達成と非機能要件充足に貢献し、有効であったと評価する。
１）性能要件評価
　「ピーク時応答時間３秒以内」の目標を達成した。また、受入れテストでの性能指摘は過去比約７０％削減され、テスト期間短縮にも繋がった。本番稼働後のピーク時も安定稼働し、レジ待ち時間短縮により顧客満足度向上という目的に貢献できた。これは、ビジネスインパクトの可視化による目標値の妥当性への合意形成と、早い段階で利用部門と運用部門に性能テストに関与してもらった結果である。
２）運用性要件評価
　共同での復旧手順策定と訓練で役割分担は明確化し、連携はスムーズになった。責任の所在を明確し図解された手順書は、運用部門から「分かりやすく自信を持って対応できる」と評価された。本番稼働後の障害発生時も、目標ＲＴＯである１時間以内を達成でき、店舗運営への影響を最小化できた。運用部門の、当事者意識と実践スキルを高めた結果と評価する。
３）全体評価
　プロジェクトは、計画通り納期・予算内で完了できた。これは、関係部門を巻き込みんで、非機能要件実現に取り組んだことが成功要因と考える。

３．２．今後の改善点

　今回の経験を踏まえ、今後のプロジェクトで非機能要件連携を改善するため、以下を強化したい。
１）非機能要件定義の早期化・網羅性向上
　今回は性能と運用性中心だったが、他非機能要件の検討開始がやや遅れた。今後は、非機能要求グレードなどのチェックリストを活用し、企画段階での要求レベル早期具体化と関係部門間で初期合意形成を目指す。これにより、手戻りはさらに削減できると考える。
２）関係部門間のコミュニケーション活性化
　情報共有が特定の担当者に集中したり、会議外での部門間のコミュニケーションが不足したりする場面も見られた。今後は、プロジェクト管理ツールやチャットツールを活用し、非機能要件に関する質疑応答、課題共有、意思決定プロセスをオープンかつ迅速に行う環境を整備する。
３）運用部門の計画的スキル向上支援
　新システムの導入に伴い、運用部門には新たな技術スキルが求められたが、その習得支援はプロジェクト終盤に集中しがちであった。今後は計画段階で必要スキルを定義し、体系的トレーニング計画（座学、技術移管、ＯＪＴ等）を策定・実行する。
４）外部ベンダー連携の早期化・精緻化
　外部ベンダーとの連携は、開発がある程度進んでから本格化するケースが多いが、今回は役割分担の細部で調整が必要な場面があった。今後は、計画段階あるいはベンダー選定段階から、運用部門／開発チーム／外部ベンダーで、ＳＬＡ／連携フロー／責任分界点を合意文書化し、契約上のリスク低減と、シームレスな保守運用体制を早期確立する。

（１２００文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【平成２８年度：問１：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Mon, 05 May 2025 07:35:31 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2016h28.html#haru_pm

問題文

問１　他の情報システムの成果物を再利用した情報システムの構築について

　情報システムを構築する際、他の情報システムの設計書、プログラムなどの成果物を部分的又は全面的に再利用することがある。この場合、品質の確保、コストの低減、開発期間の短縮などの効果が期待できる一方で、再利用する成果物の状況に応じた適切な対策を講じることをあらかじめ計画しておかないと、有効利用することが難しくなり、期待どおりの効果が得られないことがある。プロジェクトマネージャ（ＰＭ）は、成果物の有効利用を図る上での課題を洗い出し、プロジェクト計画に適切な対策を織り込む必要がある。
　そのためには、ＰＭは、再利用を予定している成果物の状況を、例えば、次のような点に着目して分析し、情報システムの構築への影響を確認しておくことが重要である。
・成果物の構成管理が適切に行われ、容易に再利用できる状態になっているか。
・本稼働後の保守効率の観点から、成果物を見直す必要がないか。
・成果物を再利用するに当たって、成果物の管理元の支援が受けられるか。
　成果物の有効利用を図る上での課題が見つかったときには、有効利用に支障を来さないようにするための対策を検討する。これらの結果を基に、成果物の再利用の範囲を特定した上で、再利用の方法、期待する効果などを明確にし、成果物の再利用の方針として取りまとめ、プロジェクト計画に反映する。

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

設問ア

あなたが携わった情報システム構築プロジェクトにおけるプロジェクトの特徴、並びに他の情報システムの成果物を再利用した際の再利用の範囲方法、及びその決定理由について、８００字以内で述べよ。

設問イ

設問アで述べた成果物の再利用に関し、期待した効果、有効利用を図る上での課題と対策、及び対策の実施状況について、特に工夫をした点を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた期待した効果の実現状況と評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と成果物再利用の概要

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

　私がＰＭを担当したプロジェクトは、製造業Ａ社の特定産業向け見積作成支援システム構築である。基幹システムのサブシステムで、見積業務の効率化・精度向上が目的だった。目標は６ヶ月での開発完了。特徴は、この短納期と、複雑な計算ロジック開発に必要な専門スキル要員の不足という経営資源の制約である。一方で社内に類似の既存システムがあり、その成果物再利用を当初から検討していた。

１．２．成果物再利用の範囲・方法と決定理由

　既存システムの設計書、プログラム、テスト仕様書を再利用対象とし、再利用の範囲は、機能の中核で最も複雑な計算ロジック部分に限定した。画面・ＤＢ設計は新規性が高く対象外とした。再利用の方法は、「計算ロジックプログラムを新システムの仕様に合わせる」「パラメータ変更や微修正を加える」方法を採用した。設計書・テスト仕様書も修正箇所を反映したうえで再利用した。
　再利用の範囲と方法は、以下の観点で評価して決定した。
・品質
　複雑な計算ロジックを新規開発する際のバグ混入リスクを避け、稼働実績のある既存ロジック活用で品質確保が可能。
・コスト
　計算ロジック部分の新規開発工数（約３人月と試算）及び関連テスト工数の削減が見込める。
・期間
　開発期間の約１ヶ月短縮が見込める。
・リスク
　再利用によって将来的に余計なコストがかかる（技術的負債）などのリスクを考慮し、影響範囲を計算ロジック部分に限定することがリスク管理上適切。画面やＤＢは新規性が高く、再利用のメリットが少ない。
　これらの評価に基に関係者と協議・合意し、計画に反映した。決定した再利用の範囲と再利用方法は、限られたリソース下での適切なリスク管理と効果の最大化を狙った最善策と考えた。

（７８８文字）

設問イ

２．期待した効果、課題と対策

２．１．成果物の再利用で期待した効果

　既存成果物の再利用において、主に次の効果を期待していた。
１）品質面
　複雑な計算ロジック部分の不具合発生率を新規開発比で５０％以上削減することを目標とした。テスト効率化や安定稼働による顧客信頼確保に繋がると考えた。
２）コスト面
　計算ロジック部分の新規開発工数（約３人月と試算）及び関連テスト工数の削減を期待し、合計で約３人月の工数削減を目標とした。限られた予算内での開発完了に重要だった。
３）期間面
　計算ロジック部分の開発・テスト期間を約１ヶ月短縮し、６ヶ月という短納期達成に貢献することを期待した。後続工程確保、手戻りリスク低減、ビジネス機会損失防止に不可欠だった。

２．２．有効利用を図る上での課題

　成果物を有効利用して期待効果を得るにあたって、事前調査等から以下の課題が明らかになった。

１）成果物の構成管理不備
　既存システムの詳細設計書の一部が最新でなく、ソースとの不整合が見られた。また、ソースのバージョン特定が困難な箇所があった。管理元の構成管理ルール運用不徹底が原因と考えた。これは「誤情報に基づく改修による手戻り発生」「不具合調査の長期化によるプロジェクト遅延」に繋がるリスクだった。
２）保守効率の懸念
　再利用対象プログラムが、旧システム固有のフレームワーク等に強く依存していた。新システムで採用する技術スタック（プログラミング言語のバージョン、基盤となるデータベースなど）が旧システムのものと異なり、そのまま流用すると新旧の異なる技術で作られた部品が混在し、保守性・拡張性を低下させる技術的負債を生む懸念があった。これは、将来の保守工数増大、特定技術者にしか修正できない属人化の進行、改修時のコスト増大、そしてシステム全体の陳腐化を促進するリスクだった。

２．３．課題に対する対策と実施状況

　これらの課題に対し、以下の対策を実行した。
１）構成管理不備への対応
　管理元と協力し、対象範囲のドキュメント・ソースの棚卸しと精査を実施した。具体的には「ソースを正としたドキュメント修正」「不足箇所を解析や管理元へのヒアリングで補完」「バージョン管理システム上の特定のリビジョンを再利用ベースラインとして明確化」を行った。認識齟齬の防止と、確認責任の所在を明確化を狙った工夫として、「成果物の存在とバージョン」「ドキュメントとソースコードの整合性」などを確認するチェックリストを作成し、管理元と当ＰＪで共同レビューすることにした。不明点は課題管理表で管理した。
　この取り組みは計画通り約３週間で完了し、開発着手可能なレベルでソース特定とドキュメント整備を達成した。チェックリストによる共同確認は手戻り防止に有効だった。課題対応状況は週次定例会で確認した。
２）保守効率懸念への対応
　依存関係を静的解析ツール等も用いて詳細に分析・評価し、リスクが高い箇所は、将来の改修容易性と技術標準への適合を目的として、アダプタパターン等を適用し疎結合化するリファクタリングを実施。品質担保と将来の回帰テスト効率化のため単体テストコードを作成。リスクを局所化し早期にフィードバックを得るための工夫として、機能単位で段階的にリファクタリングを実施する計画とし、各段階で変更前後の動作比較テストを徹底することにした。また、再利用部分専門のレビュー会を複数回実施し、設計・実装の妥当性を多角的な視点で検証した。
　本件は計画期間内に完了した。単体テストカバレッジも確保し保守性・拡張性を確保した。リファクタリング工数は若干超過したが、技術的負債の懸念は軽減され、将来的な保守コスト削減に繋がった。段階的実施とレビュー会は品質確保に寄与した。

（１６００文字）

設問ウ

３．効果の実現状況、評価と改善点

３．１．期待した効果の実現状況

　前述の課題への対策を実施した結果、期待した効果の実現状況は以下の通りであった。

１）品質面の実現状況
　品質面では、期待（５０％削減）を上回る効果が得られた。再利用部分の不具合密度は、新規開発部分比で約６０％低減した。これは既存ロジック再利用の効果であり、事前の精査やリファクタリング、テストコード作成等の対策が寄与した。リリース後も安定稼働している。
２）コスト面の実現状況
　コスト面では、全体として期待（約３人月削減）を上回る約３．５人月の工数削減を達成した。リファクタリング等の追加工数（約０．５人月）は発生したが、既存ロジック流用による直接的な削減効果が大きく、予算超過を回避できた。
３）期間面の実現状況
　期間面では、期待通り計算ロジック部分の開発・テスト期間を約１ヶ月短縮できた。これにより後続工程の期間が確保され、手戻りリスクを低減し、短納期（６ヶ月）でのリリース達成に貢献した。

３．２．成果物再利用の取り組みに対する評価

　今回の既存成果物の再利用に関する一連の取り組みは、リファクタリング工数の見積もり課題はあったものの、総合的に見て成功であったと評価する。品質向上と期間短縮という、再利用における主要な目的を達成し、コスト削減目標も達成できた。
　成功と評価する主な根拠は、以下の通り。
・品質・期間・コストの期待効果達成である。特に短納期制約下での期間短縮意義は大きい。
・事前課題（構成管理不備、保守性懸念）に対し適切な対策を実行しリスク管理できた。
・副次的に将来の保守性向上に繋がった。

　プロジェクトマネジメントとしては、初期段階での再利用判断（範囲・方法）の妥当性、及び管理元との必要な協力体制を構築できたことは評価できる。一方で、リファクタリング工数見積もり精度には改善の余地があったと反省している。

３．３．今後の改善点

　今回の経験を踏まえ、今後同様の成果物再利用を行う際には、以下の点を改善していきたい。
１）再利用計画段階での改善点
　定量的な指標を用いた事前アセスメントを詳細化し、リファクタリング要否判断や工数見積もりの精度向上を図る。また、リスク評価も深化させ代替策も具体的に検討する。
２）再利用プロセスにおける改善点
　再利用元との連携プロセス（責任分界点、情報共有ルール等）を標準化・強化する。再利用部分の品質管理プロセス（レビュー・テスト・受入基準等）も明確化し標準化する。
３）組織的な改善提案
　組織的な再利用資産の管理・整備と品質基準策定を進める。また、ナレッジ共有基盤を構築・活用し、組織全体の生産性・品質向上を目指す。

（１１７０文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【平成２８年度：問２：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Mon, 05 May 2025 08:37:27 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2016h28.html#haru_pm

問題文

問２　情報システム開発プロジェクトの実行中におけるリスクのコントロールについて

　プロジェクトマネージャ（ＰＭ）には、情報システム開発プロジェクトの実行中、プロジェクト目標の達成を阻害するリスクにつながる兆候を早期に察知し、適切に対応することによってプロジェクト目標を達成することが求められる。
　プロジェクトの実行中に察知する兆候としては、例えば、メンバの稼働時間が計画以上に増加している状況や、メンバが仕様書の記述に対して分かりにくさを表明している状況などが挙げられる。これらの兆候をそのままにしておくと、開発生産性が目標に達しないリスクや成果物の品質を確保できないリスクなどが顕在化し、プロジェクト目標の達成を阻害するおそれがある。
　ＰＭは、このようなリスクの顕在化に備えて、察知した兆候の原因を分析するとともに、リスクの発生確率や影響度などのリスク分析を実施する。その結果、リスクへの対応が必要と判断した場合は、リスクを顕在化させないための予防処置を策定し、実施する。併せて、リスクの顕在化に備え、その影響を最小限にとどめるための対応計画を策定することが必要である。

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

設問ア

あなたが携わった情報システム開発プロジェクトにおけるプロジェクトの特徴、及びプロジェクトの実行中に察知したプロジェクト目標の達成を阻害するリスクにつながる兆候について、８００字以内で述べよ。

設問イ

設問アで述べた兆候をそのままにした場合に顕在化すると考えたリスクとそのように考えた理由、対応が必要と判断したリスクへの予防処置、及びリスクの顕在化に備えて策定した対応計画について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べたリスクへの予防処置の実施状況と評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と察知した兆候

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

　私が担当したのはＡ銀行の顧客管理（ＣＲＭ）システム刷新プロジェクトである。既存システムの老朽化対応と営業力強化のための新機能追加が目的だった。私はPMとして要件定義からリリースまで担当した。期間１８か月、予算３億円、体制３０名規模のプロジェクトだった。最終目標は品質・予算遵守に加え、法改正対応システムを４月１日に安定稼働させることだった。
　本プロジェクトには、以下の特徴があった。
１）システム特性と開発規模
　刷新対象ＣＲＭは複数の基幹系と連携しインターフェースが複雑だった。また、膨大な顧客データの移行精度と効率が課題だった。開発規模は約５００人月だった。
２）体制とステークホルダー
　開発は協力会社との混成チームだった。利用部門が多岐にわたり要求調整が必要だった。
３）経営資源の制約
　制約として法改正対応のための納期（４月１日）厳守があった。利用部門のＵＡＴ要員確保にも制約があった。採用技術の経験者が少ないスキル制約もあった。

１．２．プロジェクト目標達成を阻害するリスクの兆候

　結合テスト中盤で以下の、兆候を察知した。
１）特定モジュールの品質問題
　週次レビューやツール分析から、顧客情報連携モジュールのバグが突出して多いことが判明した。全バグの約３割が集中していた。さらに、修正後のバグ再発も散見された。バグ密度は目標値の２倍超だった。
２）担当メンバーの高負荷状態
　勤怠データとヒアリングから、担当メンバー２名の残業が、計画値比１５０％超で２週間以上継続していた。ヒアリングでは「連携仕様理解不足や考慮漏れ」「仕様の曖昧な点を自己判断で実装」などが原因との声があった。これはメンバー疲弊による品質低下や遅延を示唆する危険な兆候だと考えた。

（７９１文字）

設問イ

２．リスク分析と対応

２．１．顕在化すると考えたリスクとその理由

　前述の兆候（特定モジュールの品質問題、メンバー高負荷）を放置した場合、以下のリスク顕在化を強く懸念した。
１）品質の大幅低下
　バグ多発・再発は設計の根本欠陥を示唆し、本番での重大障害（業務停止、信用失墜）につながる。影響度「甚大」、発生可能性「高」と判断した。客観的データ（バグ密度、再発率）が欠陥の深刻さを示したためである。
２）致命的なスケジュール遅延
　バグ修正・再テストの工数増とメンバー高負荷により、結合テスト以降が大幅に遅延し、最重要目標の「法改正対応システムの納期内稼働」が不可能になる。影響度「甚大」、発生可能性「高」と判断した。問題の複雑性とメンバー状況から自然回復は見込めず、遅延累積が必至だったためである。
３）コスト超過
　残業代増や修正長期化、後工程でのリカバリ対応で予算超過の恐れがあった（影響度「中」、発生可能性「中」）。
４）モチベーション低下・生産性悪化
　メンバー疲弊によるミス増加や離脱、チーム全体の士気低下を招く恐れがあった（影響度「中」、発生可能性「高」）。

２．２．対応が必要と判断したリスクへの予防処置

　品質低下・遅延リスクはプロジェクト成否に関わるため、即時かつ根本的な対策が必要と判断した。コスト超過・モチベーション低下のリスクも考慮し、以下の予防処置を優先順位を付けて実施した。
１）予防処置１（最優先）：緊急品質レビューと根本原因特定
　対処療法脱却のため、設計・開発・テスト担当に加え、連携先の基幹システム有識者も招集し、３日間集中レビューを実施。レビュー対象は仕様書、設計書、コード、テスト結果とし、なぜなぜ分析で原因を深掘りした。関係者間で事実に基づき原因を特定・共有し、効果的な対策の土台を築く狙いがあった。
２）予防処置２（処置３と並行）：根本原因に基づく修正と再テスト
　レビューで特定した「連携仕様解釈違い」と「異常系考慮漏れ」に対し、設計・コードを修正。影響範囲を再評価し、不足していたテストケース（エラー応答、特定データでの異常系）を追加し再テスト計画を策定・実行した。原因に直接対処しバグ再発を防止、品質を抜本改善すると共に、デグレードを防ぐ効果を期待した。
３）予防処置３（処置２と並行）：開発支援体制の強化
　メンバー負荷軽減と修正・再テスト加速のため、上位承認を得て他チームから連携経験のあるベテラン１名を１ヶ月間、支援要員として緊急アサインした。人的リソース制約に対応し、負荷分散とスキル活用で作業加速・品質向上を図り、遅延を最小化するためである。

　実施優先度は、原因特定（予防処置１）を最優先とし、次に修正・再テスト（予防処置２）と体制強化（予防処置３）を並行して進めた。

２．３．リスクの顕在化に備えて策定した対応計画

　予防処置でもリスク顕在化の可能性は残るため、万一に備え以下の対応計画（コンティンジェンシープラン）を策定し、事前にステークホルダーと合意した。
１）対応計画１（品質リスク残存時）
　総合テスト完了時点で、当該モジュールに重要バグ残存や目標品質未達（トリガー）の場合、リリース判定会議で「（Ａ案）機能制限付きリリース」「（Ｂ案）リリース延期」を提案。経営層が最終判断できるよう、リスク評価と影響試算等の判断材料を準備する。
２）対応計画２（スケジュール遅延顕在化時）
　結合テスト完了が計画比２週間以上遅延（トリガー）の場合、まず後続テストを優先度で見直し短縮する。それでも納期遵守困難なら、最終手段として追加予算確保の上でさらなる要員追加や休日稼働を検討する。

（１５６２文字）

設問ウ

３．予防処置の評価と今後の改善点

３．１．予防処置の実施状況と評価

１）実施状況
　計画した予防処置を迅速に実施した。予防処置１の緊急品質レビューを３日間行い、基幹システム有識者も含む関係者で根本原因（連携仕様解釈違い、異常系考慮漏れ）を特定・共有した。次に予防処置２として、原因に基づき設計・コード修正、テストケースを追加し、再テストを約２週間で完了した。並行した予防処置３では、他チームの経験豊富な支援要員１名が１ヶ月間、修正・再テストをサポートした。

２）有効性評価
　一連の予防処置は、以下の点でリスク抑制に有効だったと評価する。
・品質
　根本原因への対策が奏功し、バグ再発率は約８０％減少し品質目標を達成できた。これにより後工程での重大問題発生を防いだ。
・スケジュール
　迅速な対応により結合テストの遅延を１週間に抑制できた。この遅延は後工程で吸収し、最終納期である４月１日稼働を遵守できた。早期判断とリソース投入が重要だった。
・コスト面
　追加要員費用は発生したが、品質問題長期化による深刻なコスト増大リスクを回避し、予算超過を１％未満に抑制できた。
・メンバー負荷
　担当者の残業は計画値内に回復し、モチベーション低下や生産性悪化を防ぐ効果があった。
　以上から、予防処置は品質・納期・コスト・メンバー健全性の観点から有効に機能し、プロジェクト目標を達成した評価する。

３．２．今後の改善点

　「計画・設計段階でのリスク特定・評価と予防策織り込みの重要性」「スキルミスマッチへの早期対応の必要性」を今回の教訓と捉え、今後の改善点を以下のように考える。
１）リスク評価プロセスの重点化と早期化
　今後のプロジェクトでは、計画段階でシステム連携部など特定リスク領域の評価を強化する。専門家を交えたリスク分析を行い、より実効性のある予防策を早期に計画へ組み込むプロセスを標準化する。
２）スキル管理とタスクアサインメントの最適化
　メンバーとタスクのスキルマッチング精度を高める仕組みを導入する。スキルギャップがある場合は、早期に教育計画やメンター制度などのサポート体制を確立し、スキル不足リスクを未然に防ぐ。
３）定量的データに基づくリスク兆候モニタリングの高度化
　バグ密度や稼働状況に加え、課題解決リードタイム等の指標も活用し、計画時に閾値を設定する。定量的データに基づく早期の兆候モニタリング仕組みを強化し、迅速な対応を可能にする。
４）組織的なナレッジマネジメントの推進
　今回のリスク対応の経験（兆候、原因分析、対策、効果）を具体的な教訓として整理し、組織ナレッジとして共有する。これにより、組織全体のプロジェクト遂行能力向上と類似問題の再発防止に貢献する。

（１１７８文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【平成２７年度：問１：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Mon, 05 May 2025 16:12:16 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2015h27.html#haru_pm

問題文

問１　情報システム開発プロジェクトにおけるサプライヤの管理について

　プロジェクトマネージャ（ＰＭ）は、自社で保有する要員や専門技術の不足などの理由で、システム開発の成果物、サービス、要員などを外部のサプライヤから調達して、情報システムを開発する場合がある。
　システム開発の調達形態には、請負、準委任、派遣などがあるが、成果物が明確な場合、請負で調達することが多い。請負で調達する場合、サプライヤは成果物の完成責任を負う一方、発注者はサプライヤの要員に対して指揮命令することが法的にできない。したがって、プロジェクトを円滑に遂行できるように、発注者とサプライヤは、その進捗や品質の管理、リスクの管理、問題点の解決などについて協議する必要がある。
　仮に、プロジェクトの進捗の遅延や成果物の品質の欠陥などの事態が生じた原因がサプライヤにあったとしても、プロジェクトの最終責任は全て発注者側のＰＭにある。そのため、発注者とサプライヤの間で進捗の管理と品質の管理の仕組みを作成し、実施することが重要になる。

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

設問ア

あなたが携わった情報システム開発プロジェクトにおけるプロジェクトの特徴、及び外部のサプライヤから請負で調達した範囲とその理由について、８００字以内で述べよ。

設問イ

設問アで述べたプロジェクトにおいて、発注者とサプライヤの間で作成した進捗の管理と品質の管理の仕組みについて、請負で調達する場合を考慮して工夫した点を含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた進捗の管理と品質の管理の仕組みの実施状況と評価、及び今後の改善点について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要とサプライヤからの調達

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

　私が担当したプロジェクトは、老朽化したオンプレミス販売管理システムの再構築である。発注側のＰＭとして、プロジェクトに参画した。
　プロジェクトの目的は、保守切れリスク解消、業務効率化、将来の拡張性確保であった。期間１年半、予算約３億円の規模である。このプロジェクトの特徴は、受注・在庫・出荷など販売管理の広範な業務が対象である点、及びＷｅｂ化やＡＰＩ連携等の新技術採用である。体制は自社とサプライヤＡ社の混成チームだが、自社要員は既存システム保守で逼迫し、新技術スキル・工数確保が困難であった。

１．２．サプライヤへの請負調達の概要

　本プロジェクトでは、外部サプライヤＡ社に対し、要件定義書に基づき、外部設計の一部、内部設計、実装、単体テスト、結合テストの一部工程を請負契約で調達した。具体的には、業務の中核であり、新技術を多用する受注管理、在庫連携、出荷管理の３サブシステムを対象とした。検収は工程ごとに成果物と基準に基づき実施した。
　請負で調達した主な理由は、以下の通り。
１）自社のリソース不足とスキルミスマッチ
　既存システム保守により新規開発要員が不足し、Ｗｅｂ化やＡＰＩ連携の開発経験者もほぼ不在であった。この人的リソース制約から、自社のみでの開発は困難と判断した。
２）Ａ社が有する専門技術の必要性
　Ａ社は採用技術の開発実績とノウハウが豊富であり、高品質・効率的な開発にはその活用が不可欠と考えた。
３）納期遵守
　１年半という厳しい納期を達成するには、経験豊富なＡ社の開発力でスピードを確保する必要があった。

　これらの理由から、特定範囲の工程と機能をＡ社へ請負で委託することが、最適解と判断した。

（７７１文字）

設問イ

２．進捗管理と品質管理の仕組みと工夫点
　本プロジェクトで、サプライヤＡ社との請負契約下、円滑な遂行と成功のため、以下の進捗・品質管理の仕組みを作成・実施した。請負では直接指揮命令できないため、役割責任を明確化し、客観情報に基づく協力関係の構築が目的だった。

２．１．進捗管理の仕組み

　請負契約下の進捗管理は、直接作業指示ではなく、成果物の納期遵守を促し、遅延リスクを早期に発見・共有し、協力して対策を講じることを主眼とした。具体的には、週１回の定例進捗会議を設け、当社（ＰＭ、リーダー）、Ａ社（ＰＭ、リーダー）が参加し、ＷＢＳに基づく各タスクの進捗、ＥＶＭ指標、重要課題・懸案事項、リスク、次の打ち手を確認し、定期的な意思疎通と認識齟齬の防止を図った。また、Ａ社からの週次進捗報告書フォーマットを統一し、ＷＢＳワークパッケージ毎の計画・実績工数、進捗率、完了予定日、遅延理由・対策を記載させ、客観評価と比較を容易にした。
　進捗管理において工夫した点は、以下の通り。
・ＥＶＭ（出来高管理）の導入と共有
　請負で直接把握しにくい作業実態を補うため、客観的な進捗評価手法としてＥＶＭを導入した。Ａ社には、ワークパッケージ毎のＰＶ、ＥＶ、ＡＣの週次報告を義務付け、当社側でＳＰＩ、ＣＰＩを算出し定例会議で共有した。ＳＰＩ低下時には、単に遅延指摘でなく、原因（仕様不明確、技術課題等）をＡ社と共に分析し対策協議の材料とした。これにより客観指標管理を実現し、早期の遅延検知と建設的な対策議論を促した。
・課題管理表の共同利用
　仕様疑問点、技術問題、環境制約等の課題を一元管理するため、クラウド上のプロジェクト管理ツールに課題管理表を作成し、当社・Ａ社で共同利用した。発生部門、起票者、内容、担当者、期日、ステータスをリアルタイムで共有・更新可能とし、特に当社側確認待ちによるＡ社作業停滞を防ぐため、当社側にも迅速対応を促した。これにより課題の見える化、ボトルネック特定、迅速な解決を促進した。

２．２．品質管理の仕組み

　請負でも最終的な品質責任は発注者にあるため、サプライヤ任せにせず、品質確保の仕組みを構築した。プロジェクト開始前に、Ａ社と協議の上で定量的な品質目標（レビュー指摘密度、テストバグ密度、重要バグ件数、バグ収束曲線、性能目標等）を設定し、契約書等で合意することで、目指す品質レベルを明確化し管理指標とした。また、各工程で納品される成果物（設計書、コード、テスト仕様書・報告書等）に対する受け入れ基準を具体的なチェックリストで定義し、事前にＡ社と合意することで、検収の客観性と効率性を高めた。設計書の網羅性・標準準拠、テスト報告書の消化率・バグ状況などを基準とした。
　品質管理において工夫した点は、以下の通り。
・合同レビューの実施
　Ａ社内の設計・コードレビューの一部に、当社の業務有識者やＩＴアーキテクトも参加する「合同レビュー」形式を採用した。これは、品質確認への主体的関与を示すと共に、業務要件の解釈や技術実装方針の認識齟齬を早期解消し、品質基準の目線合わせを目的とした。Ａ社には発注者意図を直接確認できるメリット、当社には開発プロセスの透明性確保の狙いがあった。
・品質状況の定量的報告と分析
　月次で品質報告会を実施し、Ａ社から品質目標に対する実績、テスト工程別バグ発生・収束状況、バグ原因分類と傾向の定量的報告を受けた。報告されたデータに基づき、パレート図等でバグ原因の集中箇所を特定するなど、共同で品質状況を分析した。特定された問題に対しては根本原因分析と再発防止策検討をＡ社に依頼し、実施状況もフォローした。これにより継続的な品質改善活動を促した。

（１５６６文字）

設問ウ

３．管理の仕組みの実施状況、評価、今後の改善点

３．１．管理の仕組みの実施状況と評価

１）進捗管理
　週次定例会議でのＥＶＭ指標の確認は、客観的な進捗把握に有効だった。結合テスト中盤のＳＰＩ低下時には、原因（ＡＰＩ連携仕様の当社側の情報提供遅延、Ａ社の技術者不足）を早期特定できた。
　ＥＶＭ導入は、請負下での客観的進捗把握に有効であり、具体的な数値共有がＡ社の主体的対応を促した。遅延が特定された箇所への集中対策で、納期遵守に貢献した。共同利用した課題管理表も迅速な問題解決に寄与。仕組み全体でオープンな連携を促し、早期発見・対応を実現した。
２）品質管理
　品質目標値はＫＰＩとして常に意識され、月次品質報告会で実績が評価された。合同レビューでは当社業務担当者から複雑な業務ロジック等への指摘・改善要望が出され、Ａ社はこれを反映した。品質報告会でのパレート図によるバグ分析では、特定モジュールの製造バグが多発傾向にあることを掴み、Ａ社の重点レビューとテスト強化に繋がった。
　合同レビューは、請負で伝わりにくい業務背景等を早期伝達でき、認識齟齬を防止し品質向上に大きく貢献、信頼関係構築にも繋がった。定量的目標と報告・分析プロセスは、客観的な把握に基づく具体的な品質改善を可能にした。結果、システムテスト以降の重大不具合は抑制され、品質目標を達成できた。発注者の主体的関与の重要性を示し、成功に不可欠だった。

　以上から、これらの仕組みは、当社・Ａ社が協力して目標達成する上で有効に機能したと評価する。

３．２．今後の改善点

　今回の経験を踏まえ、今後のサプライヤ管理で以下改善に取り組みたい。
１）リスク連動の進捗予測精度向上
　ＥＶＭは有効だったがＥＡＣ精度に課題があった。今後はリスク発生確率等を考慮した、より現実的な進捗予測（例：３点見積もり）をＡ社に依頼・共有する仕組みを導入し、遅延リスクのより高精度な察知と対策を可能にしたい。
２）非機能要件テスト早期具体化と品質データ分析効率化
　非機能要件（性能、セキュリティ等）の測定方法、基準、環境、目標値を設計早期段階でＡ社と詳細に詰め、早期合意するプロセスを強化し、リスク低減と手戻り防止を図る。また、品質報告会のデータ集計・分析工数を削減するため、各種開発支援ツールを連携させ、品質データを自動収集・ダッシュボード可視化する仕組み導入を検討し、分析効率化と迅速な改善に繋げたい。
３）契約段階での管理プロセス詳細化
　今回有効だったＥＶＭ報告、合同レビュー、品質目標設定、課題管理ツール利用等の管理プロセスについて、ＲＦＰや契約段階で実施内容・頻度・役割等をより具体的に明記し、初期段階で双方の期待値を明確にすり合わせ、認識齟齬防止と円滑な協力関係構築を徹底したい。

（１１９４文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker

【平成２６年度：問１：老朽化システム再構築編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Thu, 08 May 2025 14:32:24 +0000

こんな人におすすめ

合格レベルの論文がどんなものか、具体的な完成形を知りたい方
自分の実務経験を「評価される論文」に仕上げる書き方のコツを知りたい方
設問ア・イ・ウそれぞれの役割と、論理的な文章のつなげ方を学びたい方

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

合わせて読みたい

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

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

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

合わせて読みたい

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

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

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

問題文および設問
解答例
まとめ
参考図書

問題文および設問

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2014h26.html#haru_pm

問題文

問１　システム開発プロジェクトにおける工数の見積りとコントロールについて

　プロジェクトマネージャ（ＰＭ）には、プロジェクトに必要な資源をできるだけ正確に見積もり、適切にコントロールすることによって、プロジェクトの目標を達成することが求められる。中でも工数の見積りを誤ったり、見積りどおりに工数をコントロールできなかったりすると、プロジェクトのコストや進捗に大きな問題が発生することがある。
　工数の見積りは、見積りを行う時点までに入手した情報とその精度などの特徴を踏まえて、開発規模と生産性からトップダウンで行ったり、ＷＢＳの各アクティビティをベースにボトムアップで行ったり、それらを組み合わせて行ったりする。ＰＭは、所属する組織で使われている機能別やアクティビティ別の生産性の基準値、類似プロジェクトの経験値、調査機関が公表している調査結果などを用い、使用する開発技術、品質目標、スケジュール、組織要員体制などのプロジェクトの特徴を考慮して工数を見積もる。未経験の開発技術を使うなど、経験値の入手が困難な場合は、システムの一部分を先行開発して関係する計数を実測するなど、見積りをできるだけ正確に行うための工夫を行う。
　見積りどおりに工数をコントロールするためには、プロジェクト運営面で様々な施策が必要となる。ＰＭは、システム開発標準の整備と周知徹底、要員への適正な作業割当てなどによって、当初の見積りどおりの生産性を維持することに努めなければならない。また、プロジェクトの進捗に応じた工数の実績と見積りの差異や、開発規模や生産性に関わる見積りの前提条件の変更内容などを常に把握し、プロジェクトのコストや進捗に影響を与える問題を早期に発見して、必要な対策を行うことが重要である。

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

設問ア

あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴と、見積りのために入手した情報について、あなたがどの時点で工数を見積もったかを含めて、８００字以内で述べよ。

設問イ

設問アで述べた見積り時点において、プロジェクトの特徴、入手した情報の精度などの特徴を踏まえてどのように工数を見積もったか。見積りをできるだけ正確に行うために工夫したことを含めて、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問アで述べたプロジェクトにおいて、見積りどおりに工数をコントロールするためのプロジェクト運営面での施策、その実施状況及び評価について、あなたが重要と考えた施策を中心に、発見した問題とその対策を含めて、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と工数見積

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

　私が担当したプロジェクトは、小売業Ａ社向けの顧客管理システム（ＣＲＭ）刷新である。既存ＣＲＭの老朽化と機能不足の解決が目的であり、新ＣＲＭ導入による顧客データ一元化、マーケティング高度化、業務効率化を目指した。私はＰＭとして本プロジェクトを統括した。
　本プロジェクトの特徴は、第一に開発期間１０ヶ月という短納期、第二に厳格な予算上限であった。これらは経営戦略上の要請であり厳守が必須だった。第三に、既存機能をクラウドサービスへ移行し、スマホアプリ連携機能を新規開発する点で、組織として未経験技術を含み高リスクと認識した。第四に、営業、マーケティング等の複数部門が関与するという、組織的特徴があった。多部門の要求集約と優先順位付けに高度な調整が必要だった。

１．２．工数見積の時点と入手した主要情報

　工数見積は企画フェーズ完了後、要件定義フェーズ開始直前に実施した。選定理由は、目的・主要機能・範囲の大枠が合意され、実現性検討も進んでいたためである。これにより前提条件を固め現実的な数値を算出できると判断した。また、精度の高い見積りが後続の要件定義やリソース計画の指針となり、短納期・予算制約下での成功に不可欠なマイルストーンと認識していた。
　見積りのために入手した主要な情報は、次の二つである。
１）各業務部門キーパーソン等へのヒアリング結果
　現状業務、課題、新機能要求、期待効果等を把握した。新機能要求は多岐にわたり、規模見積と優先度付けの基礎とした。部門間要求の調整も必要だった。
２）社内の類似ＣＲＭ開発プロジェクト（３件）の実績データ
　ＷＢＳ、工数・生産性実績、課題レポート等を収集し、類推見積の客観的基準とした。ただし採用技術等の差異から補正が必要と判断した。

（７９０文字）

設問イ

２．工数の見積手法と精度向上

２．１．見積方針の策定

　ヒアリング結果は一部定性的であり、詳細化が必要あった。また、類似プロジェクトの実績データは、採用技術やプロジェクト規模が完全に一致するものがなく、特に未経験技術部分の生産性評価は慎重に行う必要があった。
　これらの状況から、トップダウンアプローチで概算を把握後、ボトムアップアプローチで詳細化・具体化する方法を選択した。早期に全体像を把握して精度向上を図り、リスク洗い出す目的があった。特に未経験技術部分は重点的にリスク評価し、なるべく定量的な根拠で見積もるようにした。

２．２．工数見積プロセス

１）開発規模の見積手法
　機能特性に応じて、複数の手法で開発規模を見積もった。既存機能の改修は、機能一覧とヒアリング結果から規模を３段階に分類し、類似の実績から類推して見積った。規模感を掴みやすく、過去実績が有用と考えたためである。一部ドキュメントが陳腐化しており、実機確認等で補完した。新規開発するウェブ機能は、定量的に評価でき客観性が高い、ファンクションポイント（ＦＰ）法で見積もった。ヒアリング結果から得た画面数等からＦＰを算出し、定性的な要求は、業務フロー等を作成する中で、具体的な機能に落とし込みＦＰを算出した。未経験のクラウド・スマホアプリ連携機能は、知見不足のためＦＰの算定を断念し、連携データ項目数等を基に、専門家の意見／先行事例／ベンダー情報を加味して見積もった。
２）生産性の見積方法
　組織標準のＦＰ単価を生産性の基本とし、要員スキルや顧客部門の多さといった本プロジェクト固有の要因で補正した。特に重視したのは未経験技術部分で、学習コスト、手戻り等のリスクを洗い出し、基本生産性に対し３０～５０％程度の低下を見込んだ。楽観的な見積りによる後半での問題発生の回避するため、難易度等に応じて悲観シナリオも考慮した。
３）工数の算出と調整
　算出した規模と生産性から各機能の開発工数を算出し、ＷＢＳで積算して開発工数を算出した。プロジェクト管理工数は、過去実績から総直接開発工数の２０％を計上した。コンティンジェンシバッファは、技術的・要件変更等のリスクを勘案し１５％を設定した。バッファは、リスク顕在化時に計画的に使用し、安易な消化を防ぐため、ＰＭ管理とした。

２．３．見積精度向上のための工夫

　見積精度向上のため、下記の点に注力した。
１）未経験技術部分のプロトタイピング実施
　未経験技術であるクラウド・スマホアプリ連携は不確実性が高く、手戻り・遅延リスク回避が必要だった。要件定義と並行し、技術的に不確実なコア部分のプロトタイプを技術リーダー含む２名で３週間開発した。技術的実現性検証、課題早期発見、実測データ取得が目的だった。結果、ＡＰＩ連携の複雑性やＯＳ互換性問題などが早期に判明し、楽観的過ぎた部分を特定し、約１０％の工数増を見積りに反映できた。これは、現実的な計画策定と後工程での手戻り防止の効果があった。
２）見積前提条件の明確化とステークホルダーレビュー
　多部門が関与する本プロジェクトでは、前提条件の認識齟齬が起こるリスクが高いと判断し、この工夫が必要と考えた。算出した工数結果と、その根拠（スコープ、機能一覧、実現レベル、前提スキル、顧客提供情報等）を網羅した「見積前提条件書」を作成した。これに基づき主要ステークホルダー参加の見積レビュー会議を開催し、見積り根拠と前提条件を説明し質疑応答で認識共有を図った。結果、見積りの透明性が高まり共通理解が醸成され、一部機能への期待値のズレが判明し、スコープ再調整のきっかけとなった。将来の変更要求への客観的な評価基準となり、プロジェクト運営安定化とステークホルダーからの信頼獲得に寄与した。　

（１５９６文字）

設問ウ

３．工数コントロールのための重要施策と評価

３．１．プロジェクト運営面の重要施策

　本プロジェクトは複数部門が関与するため、なし崩し的に要求が拡大する可能性があり、無秩序な変更受入れによる工数増大のリスクがあった。これを防ぐため、変更管理プロセスの厳格な運用と影響分析の実施を、最重要施策と位置付けた。変更要求に明確なプロセスを定義し、影響を定量分析・評価することで、計画安定性を確保し目標逸脱を防げると考えたからである。また客観的影響分析に基づくステークホルダー協議は、円滑な合意形成とＰＭのコントロール維持に不可欠と考えた。

３．２．重要施策の実施状況

　全変更要求は「変更要求書」での提出を義務化し、週に一度、ＰＭ、技術リーダー、各部門代表、開発リーダー、品質保証担当者で構成する変更管理委員会（ＣＣＢ）で審議することにした。ＣＣＢでは変更の妥当性、優先度、実現可能性、特に開発チームの詳細な影響分析（追加工数、スケジュール影響、リスク等）を審議し、承認・否認を決定した。承認された変更は計画に反映し、全関係者に周知した。否認の場合も、理由を丁寧に説明し理解を求めた。

３．３．発見した問題とその対策

　開発中盤、マーケティング部門から、顧客分析画面等の変更要求が複数発生した。システムの具体像が見え期待が高まった結果だが、対応を誤れば工数増・遅延は必至だった。
　対策として全要求を変更管理プロセスに乗せ、開発チームが定量的な影響分析（追加工数、遅延リスク等）を実施した。この客観的データをＣＣＢで提示し、全要求受け入れ時の影響を説明した結果、影響が許容範囲内の一部のＵＩ変更は受入れ、影響大のものは次期改修という合意に至った。ＣＣＢでの審議は、制約条件厳守を最優先としつつ、ステークホルダー満足度維持とモチベーション低下を防ぐ落としどころを見つける意図があった。

３．４．施策の評価と今後の教訓

　変更管理プロセスの厳格な運用と影響分析の徹底は、工数コントロールに最も重要な役割を果たした。影響分析によりステークホルダーは変更コスト・リスクを認識し安易な要求を抑制し、開発チームは安定して作業でき生産性の維持に繋がった。進捗管理では週次会議で課題共有し早期対策に努めた。例えばスマホアプリ開発の遅延兆候には、技術サポート追加等で早期対処できた。これも変更管理で計画の揺らぎが抑えられたため、個別課題に集中できた結果と評価する。
　結果、納期内に予算超過５％未満で完了、厳格な変更管理が機能した成果と判断する。
　教訓として、初期の期待値調整、特にスコープの認識合わせの重要性を再認識した。要件定義初期にユースケース等で「作る／作らない」を徹底共有し合意形成することが、変更要求削減とプロジェクト安定化に極めて有効と考える。

（１１９５文字）

まとめ

参考図書

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

created by Rinker

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

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

created by Rinker