2020年（令和２年度）向け プロジェクトマネージャ試験 過去問 論文サンプル ２０１９年春 午後２問２
プロジェクトマネージャ試験の令和２年度向けに
２０１９年春 午後２問２の過去問解説をしたいと思います
以下が今回の問題になります。
■骨子作成
まず、設問に対する骨子作成をしていきましょう！
上記の赤線部分が骨子作成時の題目になります。
人によって誤差はあると思いますが、上記の赤文字部分の論旨を逃した時点でOUTになると思ってください。
私が作成した章立てはいかになります。
◆骨子 章立て
設問ア
１－１ プロジェクトの特徴
１－２ プロジェクト内の取り組みだけでは解決できなかった品質、納期、コストに影響し得る問題
設問イ
２－１ 解決に役に立つ観点や手段の分析
２－２ 問題解決の観点や手段の活用方法と取り組み
設問ウ
３－１ 問題解決の取組について有効性の評価
３－２ 今後の改善点
プロジェクトマネージャ試験 論文サンプル 2019年春_午後２問2_骨子作成【その２】
では、この章立てに本文に記載がある、例を当てはめていきましょう。
◆骨子 本文対応付け
設問ア
１－１ プロジェクトの特徴
※納期、品質、コストにつながる観点であなたの言葉で書く
１－２ プロジェクト内の取り組みだけでは解決できなかった品質、納期、コストに影響し得る問題
・（納期・品質・コストに影響し得る）問題発生時には、
ステークホルダへの事実関係の確認などを行ったうえで、プロジェクト内の取組によって解決を図る
↓（しかし）
・プロジェクト内の取組だけでは問題を迅速に解決できず、プロジェクトが計画通りに進まないと懸念される場合
PMはプロジェクト内の取組とは異なる観点や手段などを見いだし、原因の究明や解決策の立案を行うことも必要である。
設問イ
２－１ 解決に役に立つ観点や手段の分析
２－２ 問題解決の観点や手段の活用方法と取り組み
・プロジェクト内の取組だけでは問題を迅速に解決できず、プロジェクトが計画通りに進まないと懸念される場合
PMはプロジェクト内の取組とは異なる観点や手段などを見いだし、原因の究明や解決策の立案を行うことも必要である。
↓（このような場合）
・プロジェクト外の有識者に助言を求めたり、他のプロジェクトから得た教訓やプロジェクト完了報告書などの知見を参考にしたりすることがある。
↓（こうした助言、知見を活用する場合）
・プロジェクトの特徴のほか、品質、納期、コストに影響し得る問題の内容、問題発生時の背景や状況の類似性などから
有識者や参考とするプロジェクトを特定する。
↓
・有識者と会話して得た助言やプロジェクト完了報告書を調べて得た知見などに、プロジェクト内の取組では考慮していなかった観点や
手段などが見いだせれば、これらを活用して、問題の迅速な解決に取り組む
※複数の知見、助言があって良い →絞る！
設問ウ
３－１ 問題解決の取組について有効性の評価
※本文、具体例無し
３－２ 今後の改善点
※本文、具体例無し
■本文の分析
納期、品質、コストに影響する内容
というのが何なのかということが迷うと思われる。
・兆候をテーマにする（レビュー指摘件数、勤怠など）
PMのレベルとしては高いことをアピールしたいので
基本的な部分で、書いてしまうと、PMとしての資質を疑われるかもしれない
なので、顧客に非があるパターンで書いた方がいいと思われる。
１つの例として
「スコープ変更」というキーワードが思いつけるかが
合否の分かれ目となると思われる。
スコープ変更については過去の論文例で沢山例がある
こちらに非があるよりも、顧客都合にして
過去に同様にスコープ変更があったプロジェクトがあったかを
完了報告書を調べる、その時のプロマネに直接話を聞くというながれが
スムーズ
具体的に顧客との意識合わせなど、いつ、どこで、だれが、何をということを明確にして全体として整合性のある論文を書ければ合格レベルになると思われる。
------------------------------------
自分自身のプロジェクトの知見では解決できない為
他プロジェクトを参考にするネタを何にするかが制限時間内で
思いつくかが重要である。
突破口の論文例はすべて要点を暗記しておくことが前提。
その他の過去の例
・要員同士の対立
・キーマンの離脱
・顧客間の対立
・要件がユーザー内で決まらない状態での基本設計開始
◆骨子 詳細化（自身の体験と紐づけて具体化・定量化）
設問ア
１－１ プロジェクトの特徴
・プロジェクトの概要（内容）プロジェクト期間 自身の役割（PM!)は必ず書くこと
・納期/品質/コストの観点で後続につなげるために、プロジェクトの概要・体制（登場人物）はしっかり記載する必要がある
※突破口の例文がそのまま使えるため省略
１－２ プロジェクト内の取り組みだけでは解決できなかった品質、納期、コストに影響し得る問題
・（納期・品質・コストに影響し得る）問題発生時には、
ステークホルダへの事実関係の確認などを行ったうえで、プロジェクト内の取組によって解決を図る
↓（しかし）
・プロジェクト内の取組だけでは問題を迅速に解決できず、プロジェクトが計画通りに進まないと懸念される場合
PMはプロジェクト内の取組とは異なる観点や手段などを見いだし、原因の究明や解決策の立案を行うことも必要である。
いつどの工程で問題が起こったのかを具体的に記載する
・プロジェクトが開始されて４か月が経過した２０１７年４月（基本設計工程中盤）において
納期・品質・コストに大きく影響する問題が発覚した。
・ライバル社B社が新規のサービスを発表した、そのサービスに対応するため、新たな要件が追加になった。
要件追加に対する追加費用は出るが、新規に要員追加したとしても立ち上げ期間（既存メンバが教育）加味したら
納期が厳しく品質が保てなくなる。最悪手戻りが発生し、コストを圧迫する。
設問イ
２－１ 解決に役に立つ観点や手段の分析
観点の洗い出し※１－２の問題点と対応づけること！（類似性）
観点は以下である。
・基本設計途中での要件追加
・本来の機能のリリース時期と同じ時期にリリースすること
↓
上記を基に過去のプロジェクト完了報告書をベースにスコープ変更にが起こった事例を探す
↓
類似の事象が見つかる
↓
当時のPMが社内に存在
↓
プロジェクト完了報告書とともにアドバイスをもらう
２－２ 問題解決の観点や手段の活用方法と取り組み
解決の観点、手段（過去の午後１や午後２例）
・段階的リリースを行う
・機能ごとに優先度を決める
※顧客を巻き込みながら臨場感を出す
設問ウ
３－１ 問題解決の取組について有効性の評価
※本文、具体例無し
２－２で書いた内容の延長戦（今回のプロジェクトで有効性の評価）
３－２ 今後の改善点
※本文、具体例無し
反省点書かないといけないので、９０点とれたけどのこり１０点の改善点のイメージ
ほかのプロジェクトの情報を集めなくても今後は大丈夫という風に書きたい。
では、私が書いたサンプル論文です。
◆論文サンプル（読みやすいように、改行を多用してますが、本番時は基本は詰めて書いてください。）
設問ア
１－１ プロジェクトの特徴
私は大手ＳＩ企業（Z社）に勤めて１５年になる。
今回論述するのは情報通信機器販売会社（Ａ社）の顧客管理システム再構築のプロジェクトである。
私がＡ社の現行システムに携わったことから、再構築プロジェクトのプロジェクトマネージャに任命された。
Ａ社の現行システムは稼動開始されて１０年が経過しており、度重なる要件追加の影響で保守性が著しく低下している。
また、そのことに起因する商用故障も発生している。
そこで、システムの構造を見直し、保守性を高め現行と同等の案件を取り込む際にも
１０％の経費削減を目標としてプロジェクトが開始された。
プロジェクトの特徴としては、納期と品質である。
納期については、２０１７年３月から開始される春の商戦に間に合わせることが
経営者会議での決定事項であり２０１７年２月末に稼動開始することが強く求められている。
品質に関しては、「稼動開始後の６ヶ月間の商用故障０件」が掲げられている。高い信頼性が求められている。
１－２ プロジェクト内の取り組みだけでは解決できなかった品質、納期、コストに影響し得る問題
要件定義工程が完了し、基本設計工程が中盤に差し掛かった２０１６年６月、
客先A社のライバル会社であるB社から新規サービスが２０１７年３月から開始されると発表された。
A社においても、当サービスに対抗する施策を取り込まなくては、大幅な顧客流出が懸念された。
A社で緊急経営会議が開かれ、対抗するサービスをB社サービス開始までにリリースすることが必達とされ
顧客管理システム再構築のプロジェクトリリース時期に合わせることを依頼された。
要件追加に対する追加費用は出るが、新規に要員追加したとしても立ち上げ期間（既存メンバが教育）加味したら
再構築プロジェクトの納期が厳しく、プロジェクトの特徴である商用故障０件という品質が保てなくなる。
最悪手戻りが発生し、コストを圧迫する可能性も高い。
要件追加に伴う工数は１５人月で同時リリースの為には再構築プロジェクトを２か月延伸しなければならない状況である。
設問イ
２－１ 解決に役に立つ観点や手段の分析
要件追加（スコープ変更）に伴う、品質、納期、コストに影響し得る問題について
私自身が過去に経験したプロジェクトでは例がないため、プロジェクト内の取組だけでは解決が困難な状況であった。
私の所属するSI企業B社では過去のプロジェクト完了報告書をデータベース化し、社内でナレッジ共有を行っている。
プロジェクトの概要（スケジュール、規模）だけではなく、プロジェクト期間中に起きた問題点やその解決策の概要からも検索できるようになっている。
そこで、その社内システムを利用し以下の観点で類似プロジェクトを検索した。
・プロジェクト規模が今回のプロジェクト規模（１００人月）と同等（＋ー２０人月）であること。
・プロジェクト開始後の要件定義～基本設計工程において急なスコープ変更
そうしたところ、以下、２件の類似プロジェクトがヒットした。
①大手小売りシステムの再構築プロジェクト（以下、Kプロジェクト）
・プロジェクトの基本設計段階で顧客の急な依頼によりスコープ変更
②医療システム再構築プロジェクト（以下、Iプロジェクト）
・プロジェクトの基本設計段階で企業合併が発生し、大幅なスコープ変更
それそれのスコープ変更の概要はシステム上からも検索できるが、
幸い①②のプロジェクトともに社内に現在も在籍しているプロジェクトマネージャの為、プロジェクト完了報告書の内容をベースに直接話を伺うことにした。
２－２ 問題解決の観点や手段の活用方法と取り組み
スコープ変更が起こった類似プロジェクトのPMへのヒアリングの結果
問題解決方法はそれぞれ以下であることが、あることが分かった。
①クラッシング（Kプロジェクト）
要件追加自体の費用が出ることは同じだが、追加要件についてクラッシング（人員追加）を行い納期を守ることができた。
②段階リリース（Iプロジェクト）
クラッシングも視野に入れたが、システムの何度が高いため、クラッシングを行っても既存システムの教育に時間がかかり
既存メンバの稼働も教育にとられることからクラッシングを行うことは断念。
納期までに必ずリリースしなければいけない機能に優先度を決めて、納期必達機能とそれ以外の機能に分けて段階的にリリースした。
今回のプロジェクトと照らし合わせてみると、クラッシングを行う場合、人員教育にかかる時間を加味すると納期遅延と品質低下を招く可能性が高い。
そのため、Iプロジェクトで行った「段階リリース」の方向で、有効性を確認し顧客と調整することとした。
設問ウ
３－１ 問題解決の取組について有効性の評価
参考にしたIプロジェクトにおいて「段階リリース」行った際に、優先度の確認を行ったとのことで
今回のプロジェクトにおいても優先度の確認と段階リリースのスケジュール確認を行った。
２０１７年２月に必ずリリースしなければならない機能とリリース時期が遅れても大丈夫な機能にわけた。
観点は、リリースすることを公に周知しているか否かになる。
公に周知しているものはフロントエンド機能が中心で、バックエンド機能については周知はしていない為、
フロントエンド機能に直接関係するバックエンド機能以外はリリース時期を後にずらせる可能性がある。
全２２０機能のうち
２０１７年２月にリリースすべき機能は１５０機能であった。
上記の検討結果を元にスケジュールを決定した。
具体的には、２０１７年２月に１５０機能とB社サービス対抗機能をリリースし
上記の機能開発が終わり次第、リソースを残りの機能の開発に割り当てる計画だ。
今回のスコープ変更に伴うリリース第一弾は予定通り２０１７年２月にリリースし、
残りの機能は２０１７年６月にリリースする段階リリース案を顧客側に提示し、承認を得られた。
３－２ 今後の改善点
今回のプロジェクトで予定通り２０１７年２月と５月に無事にリリースすることができた。
段階リリースのおかげで、品質・コストともに目標値に収めることができた。
B社対向サービスも２月に同時リリースできたことから、A社経営層からは高い評価が得られた。
今回のスコープ変更に関して過去のプロジェクト実績のおかげでリスクを回避できた。
今後は、プロジェクトの計画段階でもこのようなスコープ変更のリスクを加味した対応策を顧客側と意識を合わせておく必要があると考える。
今回のプロジェクトで得た知見をプロジェクト完了報告書（社内データベース）に詳細にまとめて、今後同様のプロジェクトを行うプロジェクトマネージャへナレッジとして引き継ぎたい。
ーーーーーーーーーーーーーーーーー
上記のような感じです。
内容を思い浮かべるのが若干難しい問題なので、
最後まで整合性の取れた内容で書ければA判定になると思います。
更に詳しい解説は以下にアクセスお願いします。
突破口ドットコム
