ＤＸ推進

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

合わせて読みたい

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

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

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

参考図書

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

created by Rinker

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

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

created by Rinker

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

おじさん2355 — Sat, 19 Apr 2025 06:20:46 +0000

こんな人におすすめ

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

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

合わせて読みたい

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

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

合わせて読みたい

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

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2022r04.html#aki_pm

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

問題文および設問

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

問題文

問１：システム開発プロジェクトにおける事業環境の変化への対応について

　システム開発プロジェクトでは、事業環境の変化に対応して、プロジェクトチームの外部のステークホルダからプロジェクトの実行中に計画変更の要求を受けることがある。このような計画変更には、プロジェクトにプラスの影響を与える機会とマイナスの影響を与える脅威が伴う。計画変更を効果的に実施するためには、機会を生かす対応策と脅威を抑える対応策の策定が重要である。
　例えば、競合相手との差別化を図る機能の提供を目的とするシステム開発プロジェクトの実行中に、競合相手が同種の新機能を提供することを公表し、これに対応して営業部門から、差別化を図る機能の提供時期を、予算を追加してでも前倒しする計画変更が要求されたとする。この計画変更で、短期開発への挑戦というプラスの影響を与える機会が生まれ、プロジェクトチームの成長が期待できる。この機会を生かすために、短期開発の経験者をプロジェクトチームに加え、メンバーがそのノウハウを習得するという対応策を策定する。一方で、スケジュールの見直しというマイナスの影響を与える脅威が生まれ、プロジェクトチームが混乱したり生産性が低下したりする。この脅威を抑えるために、差別化に寄与する度合いの高い機能から段階的に前倒しして提供していくという対応策を策定する。
　策定した対応策を反映した上で、計画変更の内容を確定して実施し、事業環境の変化に迅速に対応する。
　あなたの経験と考えに基づいて、設問ア～設問ウに従って論述せよ。

設問ア

あなたが携わったシステム開発プロジェクトの概要と目的、計画変更の背景となった事業環境の変化、及びプロジェクトチームの外部のステークホルダからプロジェクトの実行中に受けた計画変更の要求の内容について、８００字以内で述べよ。

設問イ

設問アで述べた計画変更の要求を受けて策定した、機会を生かす対応策、脅威を抑える対応策、及び確定させた計画変更の内容について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた計画変更の実施の状況及びその結果による事業環境の変化への対応の評価について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．システム開発プロジェクトの概要と計画変更

１．１．プロジェクトの概要と目的
　私が担当したプロジェクトは、全国に店舗展開する小売チェーン向けのモバイル顧客管理システムの開発である。このシステムは、顧客の購買履歴分析と個別化された販促メッセージの配信を目的としていた。具体的には、顧客の購買傾向に応じて最適なクーポンを提案し、来店促進と客単価向上を図るものであった。私はプロジェクトマネージャとして参画し、開発期間は１２ヶ月、予算３０００万円の中規模プロジェクトであった。

１．２．計画変更の背景となった事業環境の変化
　プロジェクト開始から６ヶ月が経過した時点で、業界最大手の競合他社が位置情報を活用した同様のサービスを３ヶ月後に開始すると公表した。この新サービスは、顧客が店舗近くを通過した際にリアルタイムでクーポンを配信する機能を含んでおり、我々のシステムには当初予定していなかった機能であった。この発表を受け、顧客企業のマーケティング部門から強い危機感が示された。具体的には、競合他社に顧客を奪われるリスクが高まり、新システム導入の効果が大幅に減少する可能性が指摘された。

１．３．受けた計画変更の要求内容
　クライアント企業のマーケティング部門から、位置情報連動機能を追加し、当初予定していた納期を２ヶ月前倒しするという計画変更の要求を受けた。具体的には、位置情報を活用したリアルタイムクーポン配信機能を最優先で実装し、競合他社のサービス開始よりも１ヶ月早く市場投入することを求められた。この要求には、差別化要素として位置情報の精度を高め、来店確率の高い顧客を選別するアルゴリズムの実装も含まれていた。ただし、追加予算は全体の２０％増までという制約条件も提示された。

（７５１文字）

設問イ

２．計画変更への対策と確定内容

２．１．機会を生かす対策
　今回の計画変更は、プロジェクトチーム成長の機会と捉え、以下の対応を策定した。

１）専門人材の緊急投入とナレッジ共有体制の構築
　位置情報処理の専門人材を社内の他部門から２名招集し、チームに加えた。この専門人材がもつノウハウを共有するため、週３回の短時間レビュー会議を設定した。チーム全体のスキル向上を図り、特定個人への依存を避けつつ、専門知識の分散化を実現できると考えた。

２）ビジネスインパクト重視の実装順序設計
　位置情報機能の中でも、ビジネスインパクトが最も大きい「店舗周辺滞在顧客の検知」と「パーソナライズドクーポン自動生成」の２機能を最優先で実装することとした。成果を早期に可視化できると判断し、位置精度の調整と検知範囲の最適化については、実店舗での実験を繰り返し行った。

３）アジャイル開発手法の部分導入
　計画変更に柔軟に対応するため、位置情報機能に限定してスクラム開発手法を導入した。２週間のスプリントサイクルを設定し、各スプリント終了時にはステークホルダと機能レビューを行った。

２．２．脅威を抑える対策
　計画変更がもたらす脅威に対しては、以下の対策を実施した。

１）機能のモジュール化と段階的リリース戦略
　全機能を一度にリリースするのではなく、中核機能と付加機能を分離し、３段階のリリース計画を立案した。第１フェーズでは位置情報検知機能、第２フェーズではパーソナライズ機能、第３フェーズでは高度な分析機能というように分割した。特に第１フェーズは、競合よりも１ヶ月早くリリースすることを最優先目標とした。

２）テスト自動化
　開発スピード向上に伴う品質低下リスクを抑えるため、回帰テストを自動化するフレームワークを導入した。位置情報の正確性とリアルタイム性を検証するテストシナリオを重点的に設計し、テストエンジニアを１名増員した。

３）既存機能の簡素化による工数捻出
　当初予定していた優先度の低い機能を第３フェーズへ後回しすることで、位置情報機能への工数を確保した。機能の優先順位付けはマーケティング部門と協議し、差別化に直結しない機能を特定して合意した。

２．３．確定させた計画変更の内容
　これらの対策を反映し、以下の内容で計画変更を確定した。

１）目標リリース日程と開発スコープ
　当初の納期から２ヶ月前倒しし、３段階のリリースプランを採用することとした。具体的には、競合他社のサービス開始予定の１ヶ月前に第１フェーズをリリースし、その後１ヶ月ごとに第２・第３フェーズを展開するスケジュールとした。特に第１フェーズでは他社より高精度な位置検知アルゴリズムを実装することで差別化を図ることとした。

２）リソース配分と予算の再設定
　追加予算は当初の１５％増で承認を得た。この予算を主に専門人材の確保とテスト自動化環境の構築に配分した。開発チームの編成も見直し、位置情報処理チーム、ＵＩ設計チーム、バックエンド処理チームの３チーム制に再編成した。

３）プロジェクト管理方法の変更
　全体のプロジェクト管理はウォーターフォール型を維持しつつも、位置情報機能の開発に限ってはアジャイル手法を導入する混合型の管理方法を採用した。具体的には、日常の進捗管理とステアリングコミッティでの意思決定を効率化するため、バーンダウンチャートを用いた。

　このような計画変更を実施することで、競合他社の動きに対応しつつ、プロジェクトチームの成長機会を最大化し、クライアントの事業競争力強化に貢献できると判断した。位置情報という新技術領域への挑戦は、チームメンバーのスキル向上と組織の技術資産蓄積につながると考えた。

（１５９３文字）

設問ウ

３．計画変更の実施状況と評価

３．１．計画変更の実施状況
　計画変更の実施においては、緻密な進捗管理と柔軟な対応を心がけた。

１）３段階リリースの実施状況
　第１フェーズは当初目標より１週間の遅延が生じたものの、それでも競合他社より３週間先行してリリースすることに成功した。主な遅延要因は、都市部の高層ビル街での位置精度向上の技術的課題であった。第２フェーズも計画通りに進行し、第３フェーズは一部機能を簡素化することで、全体スケジュールへの影響を最小限に抑えた。

２）チーム体制と知識共有の実施状況
　位置情報処理の専門人材の参画により、当初想定した以上の知識移転が実現した。週３回のレビュー会議は非常に効果的に機能し、プロジェクト終盤には専門人材に依存することなく、チームメンバー全員が位置情報関連の問題解決に対応できるようになった。

３．２．事業環境の変化への対応の評価
　計画変更の実施による事業環境の変化への対応は、以下の観点から評価できる。

１）市場競争力の維持・向上
　競合他社に先駆けてサービスを市場投入できたことで、クライアント企業は市場での差別化ポジションを確保することに成功した。特に位置情報の精度において、店舗から２００メートル以内の顧客を９５％の精度で検知できる機能を実現し、競合他社の同機能（精度約８０％）を大きく上回ることができた。この技術的優位性により、サービス開始から３ヶ月間で、クライアント企業の既存顧客の約６０％がシステムを利用するという高い普及率を達成した。

２）ビジネス成果への貢献
　位置情報を活用したリアルタイムクーポン配信機能により、クライアント企業の来店率が導入前と比較して平均１５％向上した。特に、位置情報に基づく来店喚起は、従来のメール配信と比較して３倍の反応率を達成した。また、競合他社のサービスに顧客を奪われるリスクも最小化でき、クライアント企業の売上は前年同期比で８％増加した。

３）プロジェクトチームの成長
　計画変更に対応するプロセスを通じて、チームメンバーの技術力と問題解決能力が向上した。位置情報処理という新技術領域への挑戦は、チーム全体の技術的視野を広げる結果となり、アジャイル開発手法の部分導入を通じて、柔軟な開発プロセスの経験値も蓄積された。

３．３．今後の課題
　今回の計画変更対応はおおむね成功し、市場競争力の維持・向上やクライアント企業の成果に大きく貢献した。さらに、新技術への対応力を獲得できた点は組織にとって大きな資産である。一方で、競合動向が計画変更リスク要因であると判明したため、今後は計画段階から情報収集と分析を行い、リスク低減を図っていく。

（１１４９文字）

まとめ

参考図書

created by Rinker

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

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

created by Rinker

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

おじさん2355 — Thu, 14 Aug 2025 07:23:16 +0000

こんな人におすすめ

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

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

合わせて読みたい

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

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

合わせて読みたい

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

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

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

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

問題文および設問

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

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

解答例

設問ア

１．プロジェクトの概要とステークホルダ分析

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

　私が担当したプロジェクトは、ＩＳＰ事業者の法人営業部門向け「統合型メールマーケティングプラットフォーム」（以下、本システム）の新規開発である。私は情報システム部に所属し、プロジェクトマネージャを務めた。
　プロジェクトの背景には、メール配信業務の属人化で担当者間の成約率に最大５倍の格差（０．５％～２．５％）が生じ、これが部門目標の達成を阻害する要因となっていた。また効果測定が手作業であるためにＰＤＣＡサイクルが停滞する課題もあった。
　これらの課題解決のため、最重要目標を「業務の標準化とデータ駆動型の営業活動への転換」と定め、定量的目標として「メール配信準備工数の３０％削減」（現状平均４．０時間から２．８時間へ）及び「メール経由での成約率向上」（現状平均２．０％から２．１％へ）を掲げた。測定はリリース後半年間の実績値と、過去１年間の平均値とを比較することとした。開発期間は１２か月と設定された。

１．２．主要ステークホルダと潜在的リスク

　本プロジェクトの主要ステークホルダは、ユーザである法人営業第一部、法人営業第二部、技術基盤を担う情報システム部、そして投資判断を行う経営層の四者であり、私は彼らの期待と影響度をステークホルダ登録簿で管理した。
　特に、中小企業を担当する営業第二部は「業務効率化」への期待が非常に高く、「誰でも使える簡単さ」を強く要求していた。しかし、ヒアリング初期の段階で、その「簡単」という言葉の解釈に、担当者のＩＴスキルによって幅があることが判明した。これは、実行段階でシステムのＵＩ／ＵＸを巡る深刻な認識の不一致に繋がりかねない、潜在的なリスクであると私は初期から認識し、プロジェクトにおける最重要の管理対象であると位置付けた。

（７７９文字）

設問イ

２．計画段階におけるステークホルダとの期待調整とリスク対応

２．１．主要ステークホルダの期待と潜在的リスク

１）相反する期待と過大な期待

　計画段階のヒアリングで、主要ステークホルダの期待について、部門間の要求が相反し、経営層からは過大な期待が寄せられていることを確認した。営業第一部は個別対応を重視し複雑なセグメンテーション機能を、一方、営業第二部は効率を最優先し徹底的に簡素化された操作性を要求した。また、経営層からは、予算を大幅に超えるＡＩ活用機能や、短期的な投資対効果への過大な期待が寄せられていた。

２）最重要リスクとしての「認識の不一致」の特定

　私はこれらの期待のズレから生じる様々なリスクの中でも、特に「実行段階で、システムのＵＩ／ＵＸを巡って営業第二部との間に深刻な認識の不一致が生じる」リスクを、最重要リスクとして特定した。その根源は、彼らの「簡単さ」と「柔軟性」という、両立が難しい曖昧な要求にあった。このリスクが顕在化すれば、システムの受け入れが拒否され、最重要目標を達成できない判断した。

２．２．リスクを管理するためのコミュニケーション計画

　私はこの最重要リスクを管理するため、予防処置と是正処置計画から成る、計画的なコミュニケーションを設計した。

１）発生確率を低減させるための予防処置

　まず、リスク発生確率を低減させるため、両営業部門と合同ワークショップを開催した。特に工夫したのは、要求を「必須」レベルに分類する際、「『必須』と定義できるのは、”この機能がなければ定量的目標の達成が不可能になる”と全員が納得できるものに限る」という明確な判断基準を提示した点である。さらに、曖昧な「簡単さ」という要求を、「初回操作のタスク完了時間３分以内」等の非機能要件に定義しようと試みたが、操作イメージが固まらず、完全な合意には至らなかった。これにより、スコープの膨張は抑制できたものの、リスク残存を再認識した。

２）リスク顕在化に備えた是正処置計画

　予防処置を講じてもリスクは残存すると判断し、顕在化に備えた是正処置計画を事前に策定した。具体的には、「プロトタイプ提示の際、ＵＩの根本的な作り直しに繋がる不満が表明された場合」をトリガーとし、その際は「ＰＭによる一次対応→経営層への報告と協力要請→ペーパープロトタイピングによるワークショップの再実施」という三段階の是正処置を発動する、と定義した。

２．３．コミュニケーション計画に基づく合意形成

　私は、策定したリスク対応計画等の実行許可を、事前のコミュニケーションによってステークホルダから得ることが不可欠だと考えた。

１）過大な期待の正常化

　経営層の過大な期待に対し、まず定例報告会で客観的データを用いて対処した。具体的には、ＡＩ活用機能には「追加開発で２千万円、効果による利益増は年１千万円程度」というＲＯＩの概算を提示し、「回収に２年以上を要し、今回の投資基準には合致しない」と説明した。その上で、「まず今回の製品で確実に成果を出し、その投資効果を原資に、フェーズ２でＡＩ機能を検討する」という段階的ロードマップを提案し、経営層の期待を現実的な水準に導いた。

２）残存リスクに関する事前合意

　次に、ＵＩ／ＵＸに関するリスク登録簿を正式な議題とし、経営層および営業第二部の部長と個別レビュー会議を設定した。そこで「ＵＩに関する認識のズレというリスクの残存」「顕在化した場合、手戻りによる１か月の遅延と５人月の追加工数が見込まれる」「その際は、この計画に沿った是正処置実行の許可が欲しい」と提示した。当初、経営層からは予防策が万全でない点を厳しく指摘されたが、リスクを透明化し計画的に管理しようとする私の姿勢が最終的に評価され、事前承認を得ることができた。

（１５９１文字）

設問ウ

３．実行段階における認識の不一致への対応

３．１．予見された認識の不一致とその状況

１）リスク発生の状況

　実行段階でプロトタイプを提示した際、計画段階で予見していたリスクが顕在化した。営業第二部のマネージャから「テンプレート機能が期待と全く違う。作業が煩雑になり、我々の求める『簡単さ』が実現されていない」という強い不満が表明された。これは、是正処置計画で定義したトリガーに該当する事態であった。

２）リスク顕在化に対する状況判断と対応

　私は、この事態をリスク登録簿に記載された「想定内のリスクの顕在化」として判断し、プロジェクトメンバと、不満を表明する営業第二部の双方に対して、状況がコントロール下にあることを示した。具体的には「リスク登録簿の通り、この事態は事前に予見したものであること」「対応計画も準備済みであること」を伝えた。その上で、関係者に事前に合意していた是正処置計画の発動を正式に宣言した。

３．２．計画に基づき実行したコミュニケーションと評価

１）事前に合意した是正処置の実行プロセス

　私は、事前に策定・合意した三段階の是正処置計画に従い、コミュニケーションを主導した。第一に、営業第二部の不満を詳細にヒアリングし、共感を示しつつ、計画に沿った対応を約束することで、感情的な対立への発展を抑えた。第二に、計画通り担当役員に状況を報告し、追加工数とスケジュールの承認を得ると同時に、次のワークショップへの参加を要請した。役員からは「計画的な対応を評価する。責任をもって解決せよ」との支持を得た。第三に、ペーパープロトタイピングを用いたワークショップを開催し、ユーザ自身に理想のＵＩを描いてもらうことで、曖昧だった「簡単さ」の具体的なイメージを初めて共有できた。その結果、「テンプレートの基本構造は固定しつつ、カスタマイズ可能な項目を選択式で増やす」という現実的な修正案で、円滑に合意形成するに至った。

２）リスクマネジメント活動の有効性評価

　今回の是正処置による手戻りは、結果としてスケジュールの３週間の遅延と４人月の追加コストを発生させた。しかし、これはリスク対応計画の策定時に見積もった「１か月の遅延、５人月の追加工数」という許容範囲内に収まり、マネジメント計画が有効に機能したと評価する。この「４人月の追加コスト」は、「５人月以上の追加コストはＣＣＢ（変更管理委員会）による承認が必要」という当社の規定に基づき、ＰＭによる裁量の範囲内で吸収可能と判断した。
　今回の教訓を活かすため、ＵＩ／ＵＸに関する要求の合意形成において、プロトタイピングによる段階的な検証を義務付けるプロセスを標準化した。具体的には、「非機能要件定義ガイドライン」と「コンティンジェンシ計画標準テンプレート」を作成し、全社のプロセス資産として共有・展開した。

（１１９１文字）

まとめ

参考図書

created by Rinker

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

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

created by Rinker

【平成２５年度：問３：ＤＸ推進編】プロジェクトマネージャ午後Ⅱ論文対策｜実務経験を持つ一発合格者が書いた解答例

おじさん2355 — Sun, 11 May 2025 05:11:06 +0000

こんな人におすすめ

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

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

合わせて読みたい

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

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

合わせて読みたい

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

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

https://www.ipa.go.jp/shiken/mondai-kaiotu/2013h25.html#haru_pm

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

問題文および設問

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

問題文

問３　システム開発プロジェクトにおける工程の完了評価について

　プロジェクトマネージャ（ＰＭ）には、プロジェクトの品質、予算、納期の目標を達成するために、プロジェクトの状況を継続的に評価し、把握した問題について対策を検討し、実施することが求められる。
　特に、各工程の完了に先立って、作業の実績、成果物の品質などの項目について、その工程の完了条件に基づいて評価する。また、要員の能力や調達状況などの項目について、次工程の開始条件に基づいて評価する。評価時に把握されるプロジェクト遂行上の問題としては、例えば、設計工程では、次のようなものがある。
・工程の成果物の承認プロセスが一部未完了
・次工程の開発技術者が、計画上の人員に対して未充足
　ＰＭはこのような問題を把握して、次工程にどのような影響を与えるかを分析し対応策を検討する。問題によっては、プロジェクトの納期は変えずにスケジュールの調整を行うなどの対応策が必要になる場合もある。そして、必要な関係者にその工程の完了及び次工程の開始の承認を得る。
　また、類似の問題が発生しないように問題の背景や原因を把握して、再発防止策を立案することも重要である。

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

設問ア

あなたが携わったシステム開発プロジェクトのプロジェクトとしての特徴と、完了評価を行った工程の一つについて、その概要、その工程の完了条件と次工程の開始条件を、８００字以内で述べよ。

設問イ

設問アで述べた工程の完了評価の結果はどのようなものであったか。その際、把握した問題と次工程への影響、検討した対応策について、８００字以上１，６００字以内で具体的に述べよ。

設問ウ

設問イで述べた問題の背景や原因、再発防止策とその評価、及び残された問題について、６００字以上１，２００字以内で具体的に述べよ。

解答例

設問ア

１．プロジェクト概要と完了評価を行った工程

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

　私がＰＭとして参画したプロジェクトは、年商約１０００億円規模の大手小売業Ａ社向け顧客データ分析基盤の新規構築である。全社システムに散在する顧客データを統合・分析し、マーケティング戦略を支援することが目的だった。予算８千万円、ピーク時１５名の体制だった。
　プロジェクトには、下記のような特徴的があり、ＰＭには徹底したスコープ管理とリソース最適化が求められた。
１）複雑なデータ処理
　１０以上の既存システムからのデータ収集と、高精度な名寄せが必要だった。
２）多数のステークホルダー
　主要５部門以上が関与し、分析軸の優先度での意見対立があった。
３）経営資源の制約
　絶対的な納期（９ヶ月）、抑制的な初期予算、専門スキル要員の不足（実質２名）。

１．２．完了評価を行った工程

　論述対象は最上流工程の「要件定義工程」である。後続工程への品質影響が大きく、曖昧さ排除と品質確保が最重要と判断した。ＰＭとして設定した完了条件・開始条件は次の通り。
１）要件定義工程の完了条件
・主要成果物の役員・部長承認が完了していること。組織の公式コミットメント獲得のため必須とした。
・全要件が経営戦略と整合し、ＳＭＡＲＴの原則を満たす。品質確保のため、過去の失敗事例を参考に基準を厳格化した。
２）次工程（外部設計）開始条件
・外部設計コアチーム（５名）が確定し、ＰＭが作成する要件理解度テストを、平均８５点以上をクリアする。専門スキル要員が不足しているため、スキルの底上げを狙った。
・プロトタイピング用の検証環境が利用可能で、技術的Ｑ＆Ａ体制が確立されていること。迅速な課題解決と早期の技術実現性確認ができる体制確立を意図してのものだった。

（７７７文字）

設問イ

２．工程完了評価によって把握した問題、次工程への影響と対策

２．１．工程完了評価時に把握した問題

　要件定義工程の完了判定会議（役員、部長出席）の結果は、「条件付き合格」だった。具体的には、下記の問題を次工程開始前に解決することが条件だった。
１）性能要件の具体性欠如
　マーケティング部門の期待に対し、「キャンペーン抽出処理５秒以内」等の具体的な目標値や測定条件が未定義だった。技術チームからは、低予算のインフラ構成案での性能劣化が懸念が示された。非機能要件の深掘り不足が背景にあり、放置するとシステムの信頼性にかかわると判断した。
２）特定業務部門からのスコープ外の追加要求
　工程終盤に店舗運営部から突然、「店舗別顧客リピート予測機能」の追加要求があり、２人月の工数増に相当した。初期ヒアリングの場に、キーマンがいなかったことが原因だった。予算・納期が極めて厳しい中での対応は、プロジェクト成否を左右する事態だった。

２．２．問題が次工程に与える影響

　これらの問題は、次工程以降への深刻な問題に発展すると分析した。
１）品質
　不明確な性能要件は、ユーザーから「使えない」と判断されるリスクがある。追加要求の安易な受諾は、テスト不足によるデグレード招き、システムの信頼性を失う。
２）スケジュール
　性能要件の再設計による手戻りで、外部設計が最低２週間の遅延。性能問題は１ヶ月以上遅延を招き、クリティカルパスへの影響は必至だった。追加要求の対応は１．５ヶ月の遅延が発生する。
３）コスト
　後工程での性能改善（ハードウェア増強など）は、数千万円単位の追加予算の投入が必要と試算。追加機能の開発も人件費と間接費の増加につながる。

　その他、チーム士気低下、ステークホルダー間の対立も懸念した。

２．３．検討した対策

　リソース（人・時間）の最大限の有効活用と、ステークホルダーへの積極的働きかけを重視し、危機的状況を打開する、以下の対策を実行した。
１）性能要件の早期具体化と合意形成【最優先】
　性能要件は主要関係者と緊急ワークショップ開催、目標レスポンスタイム等を定量化し、全員で署名合意した。クリティカル処理は、他部門と交渉してエース級エンジニアをアサインし、１週間の集中ＰｏＣで実現性を検証して設計に反映した。ＰｏＣチームには一時的な集中作業（一部時間外労働含む）を依頼したが、その必要性と期間を明確かつ丁寧に伝え、私自身も進捗管理や課題解決に積極的に関与することでチームの納得と協力を得た。
２）スコープ外の追加要求への体系的アプローチ
　この対策の狙いは、スコープの無秩序な拡大を防ぎ、予算・納期を遵守しつつ、ステークホルダーの満足度を可能な限り維持することにあった。具体的には、まず、少人数の「影響分析チーム」を組成し、「技術的な実現可能性」「必要な追加工数（人日）」「既存スケジュールへの影響度」「潜在的なリスク」を評価し、その結果を簡潔な報告書としてまとめた。次に、この影響報告書を基に、ステアリングコミッティ（情報システム担当役員、マーケティング担当役員、経営企画部長が参加）に対して、追加要求の採否について判断を仰いだ。その際、ＰＭとしての客観的な立場から、「今回のスコープから除外し、将来の検討課題とする」「次期フェーズでの開発対象とする」「現行スコープ内の優先度の低い機能とトレードオフ」の３案を、それぞれのメリット・デメリット、及び経営的インパクトと共に提示し、データに基づいた戦略的な経営判断を促す方針とした。特に、安易なスコープ追加はプロジェクト失敗に繋がるため、そのリスクを強調した。

　対策の優先順位は、システムの根幹にかかわる問題である、性能要件の対策を最優先とした。

（１５９６文字）

設問ウ

３．問題の原因と再発防止策、および残された問題

３．１．問題の背景と原因

　要件定義工程での問題の背景には、当時の当社プロジェクト推進体制や組織慣行に起因する問題があった。
１）性能要件の具体性欠如の直接原因は、初期ヒアリングが機能面に偏り非機能面の期待が定性的な把握に留まっていたことにあった。この背景には、非機能要件の重要性に対する組織全体の認識不足と、それを具体化する標準開発プロセスの不備があった。結果、性能目標設定は各ＰＭの裁量に委ねられがちだった。
２）スコープ外の追加要求があった直接原因は、スコープ定義時の議論不足にあった。その背景には、全社的視点から網羅的に要求を収集・評価する標準要求開発プロセスが組織的になかったことや、要求変更を客観的基準で管理する仕組みの形骸化にあった。

３．２．再発防止策と評価
　これらの組織的原因を踏まえ、下記の再発防止策を実行した。この活動はＰＭＯを巻き込んだ、全社横断の活動とした。
１）要件定義プロセスの標準化・強化
　非機能要件定義強化として、初期の目標設定とステークホルダー合意を必須化し、テンプレートも整備。ステークホルダーエンゲージメント強化として、関連部署の役割・責任とコミュニケーション計画を標準化。要求開発手法導入支援として、ワークショップ等の研修を実施し活用を推進する。
２）技術的リスク管理プロセスの導入とプロジェクトガバナンス強化
　新規技術採用時等では、本格開発前にＰｏＣ実施を原則化する。また、設計・テストレビュー等で専門家が参画する独立レビュー委員会を設置し、段階的なレビュープロセスの強化を図る。影響分析・優先順位付け・承認プロセスを明確化した変更管理委員会を設置し、変更管理プロセスを強化する。
　これらの策を複数プロジェクトで適用した結果、複合的効果を得たと評価。具体的には、非機能要件の手戻り削減（ある中規模ＰＪで約２５％減）、承認プロセス遅延減少、ＰｏＣによる技術選定リスクの早期発見と回避などが実現。これらは品質向上とコスト抑制に繋がり、組織的プロセス改善の有効性を示した。

３．３．残された問題とその対応方針
　前述のプロセス改善後の問題として、新たなプロセスや仕組みに対する、組織文化レベルでの変革の浸透と定着の難しさが残った。導入した標準プロセス等が、変化の激しいビジネス環境下で形式主義に陥ったり、従来の慣習に引き戻されたりする抵抗感に直面し、実効性継続に困難があった。
　この問題への対応方針として、変革の意義とメリットを経営層から現場まで粘り強く訴求し続け、導入プロセス自体の継続的改善と柔軟性確保に努める。例えば、リスクベースアプローチ導入やハイブリッドモデル開発検討等、現場実情に合わせた進化を許容するなど、組織文化への定着に貢献する。

（１１９６文字）

まとめ

参考図書