見出し画像

プロジェクトマネージャ試験に一発合格! 勉強方法・論文対策・過去問題集をまとめてみました 論文サンプル

この度プロジェクトマネージャ試験に一発合格!しました。

これからプロジェクトマネージャ試験を受験する方向けに勉強法などについて解説します。

画像1

今回合格率・難易度(平成29年度)


 13.1%(合格者/受験者 1521人/11596人)

画像1


■受験対象者像・役割と業務(IPAホームページ抜粋)


 高度IT人材として確立した専門分野をもち、システム開発プロジェクトの責任者として、プロジェクト計画を立案し、必要となる要員や資源を確保し、計画した予算、納期、品質の達成について責任をもってプロジェクトを管理・運営する者
情報システム又は組込みシステムのシステム開発プロジェクトの責任者として、当該プロジェクトを計画、実行、管理する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。


 (1) 必要に応じて個別システム化構想・計画の策定を支援し、策定された個別システム化構想・計画に基づいて、当該プロジェクトの実行計画をプロジェクト計画として立案する。
 (2) 必要となる要員や資源を確保し、プロジェクト体制を確立する。
 (3) 予算、工程、品質などを管理し、プロジェクトを円滑に運営する。進捗状況を把握し、問題や将来見込まれる課題を早期に把握・認識し、適切な対策・対応を実施することによって、プロジェクトの目標を達成する。
 (4) プロジェクトの上位者及び関係者に、適宜、プロジェクトの実行計画、進捗状況、課題と対応策などを報告し、支援・協力を得て、プロジェクトを円滑に運営する。
 (5) プロジェクトの工程の区切り及び全体の終了時、又は必要に応じて適宜、プロジェクトの計画と実績を分析・評価し、プロジェクトのその後の運営に反映するとともに、ほかのプロジェクトの参考に資する。
 
基本情報技術者に合格⇒応用情報技術者に合格した人が次のステップとして受験する方が大半です。

画像1

■合格率の推移


合格率は新制度になってからは12~14%を推移しています。

一言でいえば「高難易度国家資格」です。

国家試験の中でも上位5%に入るほどで、偏差値70と言われています

当試験自体、基本情報技術者合格(合格率20~30%)⇒応用情報技術者合格(合格率20%前後)

を突破した人が受ける試験なので、「かなりの難関試験」と言っていいでしょう。

実際、平均的な下請け企業で社員数が200名だったとしたら

基本情報取得者:50名くらい(4人に1人くらい)

応用情報技術者:10名くらい(20人に1人くらい)

プロジェクトマネージャ(高度試験):0~2人くらい(100人に1人くらい)感触です。

※実際には会社の入社難易度や専門業種によって変わってきますが、あくまで周りの会社を見ていての私見です。

画像1

■最も役に立った講座


 プロジェクトマネージャ試験7つの突破口(1万円以下で大手を超える動画解説)

画像1

■勉強するにあたって


 勉強の基礎ベースとなるのが、応用情報技術者試験の知識となります。
 ソフトウエア開発技術者(現:応用情報技術者)に合格して10年近くブランクがあったため、2年計画で取得しました。
 昨年春:応用情報の勉強+午前Ⅱ試験(午後の対策は3問程度過去問解いた程度⇒ほとんどしていない)  ⇒次回の午前Ⅰ受験免除資格取得

■出題形式・合格基準・概略


 すべて基準点以上で合格となる(60点以上、論文はA評価)


上記の表の赤枠部分が合格基準に達しているものになる。

午前2で不合格になった場合は午後1の採点はされない。同じく午後1で不合格になった場合は午後2の採点はされない(せっかく苦労して書いた論文もシュレッダー行き!?⇒一年目の私です!(^^;))

全体としては合格率13.1%とかなりの低い割合になるが、午前1~の4つの種類に分けた場合の合格率は以下となっている。

午前Ⅰ:50%前後(免除者が約半分)

午前Ⅱ:70%前後

午後Ⅰ:40%~60%(年度によって調整有)

午後Ⅱ:40%~60%(年度によって調整有)

単独で見ると合格率50%前後である!

2人に1人受かる試験を4つ取る!と考えると10人に1人の試験に受かるより楽な感じがしませんか?(実際には同じ意味だけど・・)

つまり、難関と言われる午後試験も上位50%に入れば合格できるということです。

実際50点~70点の間に全体の7割の人が固まっています。

ボーダラインを突き抜ける方法を説明します。

「午前」は応用情報技術者レベルの基礎知識問題(足切り試験)
「午後」は専門分野の長文読解、論文(難関)

になります。

それぞれの詳細について記載します。

 ・午前Ⅰ(50分 30問(四肢択一))
   応用情報技術者午前の問題から抜粋して出題される
   応用情報合格者・過去高度区分で午前Ⅰに合格している人は2年間免除

   足切試験に近い
   
 ・午前Ⅱ(40分 25問 (四肢択一)
   プロジェクトマネージメント基礎知識
   応用情報午前問題+過去問の答え(200問程度)さえ暗記していれば、楽に突破できる(今回も7割以上の方が突破) 足切試験に近い

 ・午後Ⅰ(90分 3問の内2問を選択)

12:30-14:00の90分の試験
   1題目当たりに設問が6~9題あり、記述式で解答する。
   出題数が少ないので設問1つ当たりの配点が非常に高い(1つのミスがそのまま不合格につながる)
   問題の本文が長文で時間内に解くには訓練が必要(1年目は午前対策しかしていなかった時間切れで敗退・・・)

   本文は約4ページで読むだけでも10分くらい時間がかかる

   45分で設問6~9問は時間が足りない

試験の概略について動画解説動画(youtube)載せておきます

・午後Ⅱ(120分 2問の内1問を選択し論述)※再現論文を含め添付
   出題されている論旨に即した文書を手書きで2,500字~3,000字(原稿用紙7枚)で論述する
   論述頭の中で考える時間は15分に抑えないと、時間切れになる可能性が高い

   「管理者」として論述しないといけないので、「メンバの設計作業を手伝った」と記載した時点で不合格となる(普通に現場ではあるとは思いますが)
    ⇒「設計品質が指標値を下回ったので、再レビューを指示した」と記載しなければならない
   (指定文字数書けないと、不合格決定)

  午前試験⇒午後Ⅰに集中力を使った後に、2時間の論文は体力的にもかなりきついと思われるが、みんな同じなので最後の2時間を乗り越える方法を解説します。

 ↓

論文テクニックの概要動画


プロジェクトマネージャ試験7つの突破口 NEW2


プロジェクトマネージャ試験7つの突破口 NEW2

■勉強方法・感想


 ◆午前Ⅰ(択一)
  今年は免除でしたので去年のやり方で・・
   -youtubeでの動画学習(無料)
   わくわくスタディワールド関係がおすすめ

わくわくスタディワールド動画

  -応用情報技術者過去問スマホアプリ(無料)

  昔と違って今は、youtubeで無料で応用情報技術者(基本情報含む)の動画解説を掲載している会社があります。
  ※たぶん、午前を無料(広告代わり)にして、午後対策講座で受講生を集める戦略だとは思いますが。

かなりのクオリティなので午前対策としては、本を読んで理解するより、この動画解説の方が分かりやすいし効率的です。
応用情報技術者午前過去5年分(400問程度)を電車の中など空き時間を見つけて学習しました。


  
 ◆午前Ⅱ(択一)


  -プロジェクトマネージャ午前過去問スマホアプリ(無料)
  午前Ⅰ対策+午前Ⅱ過去5年分の答え覚えておけば、突破できます。
  昨年80点だったので今回は殆ど勉強せず(今回68点に下がってしまいましたが・・)

ほとんど無料なので、試してみて自分に合うのを使ってみるとよい

 ◆午後Ⅰ(記述式)150時間位


  -プロジェクトマネージャ試験対策講座~7つの突破口~午後

画像1

 【おすすめの理由】

 ・動画解説なのに値段が安い!

 ・解法テクニックだけでなく 論文ネタが非常にたくさんあり動画で学べる

 ・過去問を15年分徹底分析して独自のノウハウを説明している


-情報処理教科書 プロジェクトマネージャ 翔泳社(600ページ)×3回

  【おすすめの理由】

 ・とにかく情報が豊富

 ・ダウンロードサイトで過去の書籍の内容をダウンロードして確認することができる

 ・試験会場に行ったらほぼ全員これ持っていたりする

情報処理教科書 プロジェクトマネージャ 2017年版
情報処理教科書 プロジェクトマネージャ 2017年版

Amazon


  -ポケットスタディ プロジェクトマネージャ(500ページ)×4回


 【おすすめの理由】

 ・書籍の値段が安い

 ・過去問のパターンが短文でまとまっている

 難点はちょっと情報が古い・・

ポケットスタディ プロジェクトマネージャ[第2版] (情報処理技術者試験)
ポケットスタディ プロジェクトマネージャ[第2版] (情報処理技術者試験)

Amazon


  -過去問題15年分 ×2回

  1問当たり45分以内で解く訓練とIPAの解答にたどり着くまでの文脈の探り方の訓練
  今回は150時間位午後Ⅰ対策に充てましたが、初めの100時間はなかなか効果が得られず。
  とにかく過去問を繰り返して、IPAの求める解答に行き着くまでの文脈の探り方を体で覚えるしかないという感想です。

 ◆午後Ⅱ(論述)50時間位


  -プロジェクトマネージャ試験対策講座~7つの突破口~午後
http://toppakou.com

画像1

  -午後Ⅰ問題から論文ネタ集め(過去15年分からネタ帳作成)

   7つの突破口では午後Ⅰベースの論文ネタが集められているのでおすすめ


  -過去問15年分(基本的に骨子作成のみ)


 -TAC出版⇒論文の基礎の基礎を学ぶ上ではいいテキスト(これだけでは合格は厳しい)


  一番初めに読む本としておすすめ

プロジェクトマネージャ 午後2 最速の論文対策 2015年度 (TACの情報処理技術者試験対策...
プロジェクトマネージャ 午後2 最速の論文対策 2015年度 (TACの情報処理技術者試験対策...

Amazon

  -合格論文の書き方・事例集 ITEC

   ⇒個人的には書いてる内容が難しくて流用できそうになかったので使用せず

小難しい文書が好きな方にはおすすめ(サンプルによってかなり質に差がある)

  -情報処理教科書 プロジェクトマネージャ 翔泳社 の論文対策部分

 -勉強手順

  論文をまともに手書きで書いていると時間がかかるので、書くべき内容の要点をまとめる学習方法にしました。


  実際に手書きで論文演習を行ったのは2回くらいです。

 「実際の経験に基づいて書け」とは言われていますが、論旨に従った内容を実際に経験しているのは、ほんの一握りだと思います。


  本番試験時はネタを考える時間は殆どないので、午後Ⅰの本文等を参考に、あらかじめ「プロジェクトネタ」を出来るだけ準備しておくのが重要です。


  後は論文を記載するにあたって、段落構成や漢字の勉強

  論文で書く内容が決まった後は、90分くらい絶え間なく手を動かして論述しないと時間オーバー(文字数不足)になる位の生産性が求められます。

  普段PCを使った業務なので、手書きで3,000字というのはかなりきついです。
  2,000字超えたあたりから手が痛くて思うように字が書けなくなりました。


  なんとか書き上げたのは試験時間残り5分だったので、見直しも半分しかできず。

  ラッキーだったのは今回の論旨が試験工程の品質管理だったことです。
  今の現場で結合試験チームの業務設計リーダを主に担当していることから、


  目の前の席のにいる品質管理者の立場で論文が書けました。(商用故障0件とはかけ離れた現場ですが・・)

画像1

■論文解法テクニック(プロジェクトの特徴)


プロジェクトマネージャ試験の論文対策として
どのテーマの論文でも問われるのが
『プロジェクトの特徴』であるびっくり

今回は、このプロジェクトの特徴での論文サンプルを紹介しますぶちゅー

まず、見てほしいのが採点講評
代表として平成27年のものを


じつは、これは平成27年だけではなく毎年のように、『プロジェクトの特徴』について「悪かった点」が述べられているガーン

つまり、「プロジェクトの特徴」についてちゃんと書ければ、A評価が近づくということになるラブ

「プロジェクトの特徴」とは何か!?

プロジェクトは無数に存在する
その中で今回のプロジェクトにおいての特徴を述べる必要がある。

で・・・・特徴とは???

ズバリ!
「納期」「品質」「予算」の観点である

しかし、
どんなプロジェクトでも納期・品質・予算(コスト)は大切!


特徴とは・・今回のプロジェクトでは他のプロジェクト比べて特に強調すべき点を挙げる必要がある

論文は出だしが肝心!

出だし=プロジェクトの特徴である!

後の設問2,3で問われている内容と整合性をが合う特徴を述べる必要がある。

例えば、品質についての設問なのに特徴を「納期」としていると後の文章との整合性を保つのに厳しくなる。


逆に「コスト」について問われているのに特徴を「納期」に特化するとこちらも後の文書を書くのが厳しくなる。

どんなことを論述すればいいの?
私の方で論文例を考えましたおねがい(とりあえず、納期について)

①納期
 ・今回のプロジェクトの特徴は、納期である。
  ライバル社A社は2017年4月にサービスを開始すると、公に周知している。
  ライバル社への顧客流出を防ぐために当社では2017年2月に稼働開始することが必須条件となっている。そのため、徹底した進捗管理を行うことが重要であると考えた。
プロジェクト期間は10か月間で余裕のないスケジュールとなっている。

上記は、プロジェクトの特徴の論文サンプルとしてそのまま流用できる場合が多いです!(使ってください)

②品質 ⇒ 信頼性、機能性、性能 等  ※定量的に表せるものを優先する
 ・今回のプロジェクトの特徴は、品質(信頼性)である。
 これまでのプロジェクトでは稼働開始後3ヵ月で平均5件の商用故障が発生した。
 商用故障は社の信頼を損ねる為、経営課題となっている。
 そこで、今回のプロジェクトでは、商用故障0件とする為の品質対策が求められている。

③コスト(予算)

 ・今回のプロジェクトの特徴は、予算(コスト管理)である。
  取引実績のないA社との今後の取引拡大を目的としている為、
  当社の能力をアピールする必要があった。
  そのため、採算ぎりぎりの契約とせざるを得なかった。 
  コスト超過は絶対に許されない為、徹底したコスト管理を行うため、
  アーンドバリューマネジメント手法(EVM)を採用した。

このプロジェクトの特徴について、論文サンプル本を買わずして集める方法がある。

それは、過去の午後Ⅰ問題からネタを集めるという方法である。

文章の冒頭部分に、納期、品質、コストなどのプロジェクトの特徴が必ず書かれているので、それを拝借する。

多くの場合は「納期」のネタが多い。

画像1

■論文解法テクニック(骨子作成)


実際にA判定をもらった論文(平成29年問2)を基に格子作成の流れを説明します。

論文の格子作成は5分が目標!

5分で行うためのテクニックを説明します。

まず、問題文は以下 平成29年 問2 品質(IPAホームページ参照)

設問は以下

ここで大切なのは、設問で問われている内容をもれなく答えること!

これが出来てなければ文書的に素晴らしくてもB評価以下となる場合がある。

まずは、設問部分をベースに題目を作成する。

画像1

■骨子案


 1プロジェクトの特徴と品質管理計画で考慮した点

  1.1プロジェクトの特徴

  1.2品質管理計画を策定する上で考慮した点

 2品質管理計画の策定と実施について

  2.1品質管理計画の策定

  2.2品質管理の実施について

 3実施計画の評価と今後の改善点について

  3.1実施内容と結果の評価について

  3.2今後の改善点について 

画像1

■本文から論文で問われている内容を当てはめる


先程作成した格子に対して、本文での説明内容が、どの項番の話題に当てはまるかを確認する。

上記と色で対応付けています

1プロジェクトの特徴と品質管理計画で考慮した点

  1.1プロジェクトの特徴

   ⇒品質目標について記載(全体の整合性)

  1.2品質管理計画を策定する上で考慮した点

   ・品質管理計画を策定して品質管理の徹底を図る必要がある

   ・プロジェクトの事例や全社的な標準として提供されている品質管理基準をそのまま適用しただけでは、プロジェクトの特徴に応じた品質状況の見極めが的確に行えず、品質面の要求事項を満たすことが困難になる場合がある。

   ※過去指標の流用×今回のプロジェクトの特徴⇒論点

 2品質管理計画の策定と実施について

  2.1品質管理計画の策定

 ・信頼性などシステムに要求される事項を踏まえて、品質状況を的確に表す品質評価の指標、適切な品質管理の単位などを考慮した、プロジェクトとしての品質管理基準を設定すること

 ・品質管理の単位が小さ過ぎると、プロジェクトの進捗及びコストに悪影響を及ぼす場合もある。

  2.2品質管理の実施について

   ・品質評価の為の情報の収集方法、品質評価の実施時期、実施体制などがプロジェクトの体制に見合った内容になっており、実現性に問題が無いこと

 3実施計画の評価と今後の改善点について

  3.1実施結果の評価について

   ・摘出した欠陥の件数などの定量的な観点に加えて、欠陥の内容に着目した、定性的な観点からの評価も行うこと

  3.2今後の改善点について 

  ⇒例無し

それぞれの例を参考にして、論文の具体的内容を組み立てていく

実際には、上記の内容は頭で対応づけて、

本文にキーワードを書いていく(とにかく時間を短縮する訓練をする事)

5分以内が目標!!!

今回の論文設計の流れ

★部分がないと多分B評価以下

7つの突破口講座で動画でも徹底解説します。

----

画像1

■再現論文


1.1 と1.2について 記載しておきます。

2017年4月16日 プロジェクトマネージャ試験 午後Ⅱ 問2 再現論文

◆事前アンケート


プロジェクト概要:情報通信機器販売会社(A社)顧客管理システム再構築プロジェクト

立場:大手SI企業 プロジェクトマネージャ 

管理対象人数最大:15名

工数:200人月

期間:2013年4月~2014年2月

制約事項(プロジェクトの特徴)

 納期:2014年3月から開始される春の商戦に間に合わせること

 品質:商用故障0件(商用故障多発が経営課題)

※過去の類似プロジェクトは商用開始後6カ月で平均4件の商用故障が発生

システムの利用人数:各都道府県に2店舗×4人=300人位(端末100台位)

-------------------------------------------------

■1章⇒800字以内 2章⇒800~1600字 3章⇒600字以上

1プロジェクトの特徴と品質管理計画で考慮した点

1.1プロジェクトの特徴

私は大手SI企業(B社)に勤めて15年になる。今回論述するのは情報通信機器販売会社(A社)の顧客管理システム再構築のプロジェクトである。

私がA社の現行システムに携わったことから、再構築プロジェクトのプロジェクトマネージャに任命された。

A社の現行システムは稼動開始されて10年が経過しており、度重なる要件追加の影響で保守性が著しく低下している。また、そのことに起因する商用故障も発生している。

そこで、システムの構造を見直し、保守性を高め現行と同等の案件を取り込む際にも10%の経費削減を目標としてプロジェクトが開始された。

プロジェクトの特徴としては、納期と品質である。

納期については、2014年3月から開始される春の商戦に間に合わせることが経営者会議での決定事項であり2014年2月末に稼動開始することが強く求められている。

品質に関しては、「稼動開始後の6ヶ月間の商用故障0件」が掲げられている。高い信頼性が求められている。

1.2品質管理計画を策定する上で考慮した点

プロジェクト立ち上げ時、今回の「商用故障0件」の高い品質目標を達成するため、品質管理基準を作成することとした。

そこで私は、現行システムのプロジェクト完了報告書や、類似プロジェクトの完了報告書の指標値を基に品質管理基準を策定することとした。

しかし、品質管理基準をそのまま適用しただけでは、今回の「商用故障0件」の目標を達成できない。なぜならば、過去の類似プロジェクトでは商用開始後6ヶ月間に平均4件の商用故障が発生しているからだ。

そこで私は、今回のプロジェクトの特徴に応じた重み付けを行うこととした。

2品質管理計画の策定と実施について

2.1品質管理計画の策定

納期とコスト超過を防ぐために私はアーンドバリューマネジメント手法(以下、EVM)を採用した。EVMを用いることで進捗とコストを定量的かつ客観的に管理することができる。WBSのワークパッケージを機能ごとに作成し、1週間単位で管理できるアクティビティに分割し、管理単位とした。

品質管理計画については、過去のプロジェクトの実績より、結合テスト工程で品質を保証できたものは商用故障も少ない傾向が見られた。そこで私は結合テスト工程の品質管理指標を重点的に管理、策定することとした

結合テスト工程の類似プロジェクトの品質管理指標は以下である。

・テスト項目数:1キロステップあたり上限40件、下限30件

・バグ密度:1キロステップあたり上限4件、下限2件

「商用故障0件」という信頼性を達成するためには、過去類似プロジェクトの指標に重みをつけなければらないと考えた。そこで私は、社内の品質管理部門と意識あわせを行い、今回のプロジェクトの特徴を踏まえて補正係数を導き出した。

テスト項目数の補正係数1.5 バグ密度の補正係数1.2 が導きだされた。

よって、今回のプロジェクトの品質管理指標は以下と決定した

・テスト項目数:1キロステップあたり上限60件、下限45件

・バグ密度:1キロステップあたり上限4. 8件、下限2.4件

2.2品質管理の実施について

結合試験工程が開始された10月はじめ、結合テスト実施メンバを集めて、品質管理指標について説明を行った。

・テスト実施状況を週次の定例会議で報告すること

・品質管理基準の指標値から外れたものに関しては、分析を行い対応策をみんなで検討する。

・分析についてはQCの7つ道具である、パレート図、特性要因図、管理図などを有効に利用すること

上記内容を結合テスト実施メンバに受け入れてもらいテスト工程が開始された。

もし大きな問題が起こった場合は、週次定例会議を待たずに、即時に報告・連絡・相談するように徹底した。

3実施計画の評価と今後の改善点について

3.1実施計画の評価について

結合テストが開始されて1ヶ月が経過した11月初旬、バグ密度が品質管理指標を10件上回る機能が発見された。

具体的には顧客管理機能の一部であるOCR読み取り機能のものである。欠陥の内容に着目した定性的な分析を行うため、パレート図を用いて原因を分析した。

そうしたところ原因の90%がOCR読み取り機能のインタフェース部分の理解不足であることがわかった。当機能はC君が作成しており、私はリーダに断りをもらってC君に直接話を聞いた。

OCR読み取り機能のインタフェースの理解不足ということがわかり、当機能の再点検と再テストを行った。そのほかのテスト項目については問題なく指標値内に収まった。

3.2今後の改善点について

2014年2月に予定通り稼動開始を迎えることができた。品質に関しては、稼動開始から今日まで商用故障0件という高品質を保っている。

A社の経営者からも今回のプロジェクトの結果に非常に満足していると伺っている。

しかし、結合試験工程において、OCR読み取り機能の設計再確認という品質管理指標を上回る、欠陥が発見されたのも事実である。

今後は、設計工程でのレビューも強化し、指標値内に収まるようにしていきたいと考えている。また、今回のプロジェクトの内容をプロジェクト完了報告書に詳しく記載し、社内で共有していきたい。

-以上-

------------

読んでみてどうでした?

一応A評価論文です。

こんな文章書けないよーと思った方!!
大丈夫です!僕がはじめはそう思ってました。

しかし、論文の引き出しを増やしていく中で、こういう論文がぱっと思いつくようになります。

論文ネタの増やし方はいかに紹介する、

「7つの突破口」に効率的な勉強方法や、論文ネタの増やし方に関するテクニックを満載しています。

また、今回紹介した論文について、どのような点に注意して書くべきか等、論文設計で気を付けることを動画で解説します。

画像1

■論文の「漢字」について


職業柄普段PCを使っていると、漢字を読めるが「書けない」(思い出せない)ことがあると思います。


論述試験では実は『致命的な問題』であるが、どのテキスト・問題集を見ても漢字に特化した練習がないんですね。

講評でも「誤字脱字の多さ」(文書が幼稚に見える)との指摘があったこともあります。

プロジェクトマネージャ試験7つの突破口の突破口5では、

論述でも多く使われる熟語を200以上集め、プロマネ漢字ドリルとしています。

youtubeあり

画像1

■まとめ


今回は午前Ⅰ免除でしたが、午後Ⅰ午後Ⅱ共にかなりの集中力を使うので試験が終わった時には放心状態でした。
論文がある高度区分を受けられる場合は、午前Ⅰ免除資格をあらかじめ取得した置いた方がいいと思います。

また、基本情報技術者に合格された方は、記憶が新しいうちに応用情報技術者の勉強を開始することをお勧めします。
  
以上、長くなりましたが、情報処理試験を目指している方に少しでも参考にして頂けると幸いです。

ここまで読んでいただきありがとうございました

試験会場行ってみると「ポケット○○」「○○教科書」の有名テキストを持ってる人の割合・・ほぼ全員・・


10%位しか合格しない試験で全員同じテキストで勉強してたら合格は非常に厳しいはずです。


そのようなライバルと差をつけるには


プロジェクトマネージャ試験7つの突破口 NEW2

f:id:riki12342000:20170826105603j:plain

上記の講座の突破口6

「論文ネタ」より一部を抜粋します(*^_^*)

論文のサンプルのテキストといわれる午後Ⅰベースに午後Ⅱ論文で使えそうなネタを集めているようです!!

画像1

■論文ネタ1 メンバ進捗管理


進捗報告時に メンバの報告を鵜呑みにしない

完了基準の意識の違い、責任感から遅延していると言えない、叱責されると思う

⇒実際の成果物と実績があっているかを突き合せる

■論文ネタ2 スコープマネジメント(変更管理)


変更管理の体制

優先度をつける

 稼働開始時の要否、工数と難易度、業務上の効果

定期案件チームと追加要件対応チームなど体制を分ける

 ※片方が確実に納期に間に合うような体制

⇒リーダや要員の理解を求める(経営陣に経緯を説明してもらう)

部分稼働⇒スケジュールの見直し

体制の見直し⇒立上げ体制

一部機能が遅れる場合、運用部門に大きな負担とならない代替案

⇒教育体制(トレーニング)

具体的な遅延工数

⇒どれくらい遅延して、その期間の運用カバー方法

スコープ変更時の会議体制

 変更管理表⇒見積もり⇒変更管理委員会(CCB)※開催頻度、参加者など詳細に

稼働開始日が変更できない理由

例)ライバル社よりも先にリリースしないと顧客の流出が考えられる

新規サービスに対抗するため

■論文ネタ3 品質マネジメント


信頼性⇒初期障害10件以下、4時間以内に復旧(稼働率)

性能⇒レスポンスタイム

操作性

品質を作りこむ工程

①レビュー

  レビュー方法

  ラウンドロビン、ウォークスルー、インスペクション

  レビュー量(ページ数)、レビュー時間(実績、予想)

指摘件数

②テスト

  品質管理指標

  テスト密度、バグ密度

■論文ネタ4 EVM


EVM手法を用いて進捗を定量的に可視化して管理することで遅延リスクへ対応を行うことにした。

しかし、4週間経過後もEVが回復していなかった。

■論文ネタ5 単体テストEVM(H20午後1 問1 抜粋)


・単体テストを含む製造工程では、機能ごとにプログラムモジュール、画面・帳票を製造する作業をWPとした。

機能ごとに見積もったモジュールする、画面・帳票数に対して、製造を完了したプログラムモジュール数、画面・帳票数の比率で計上する方法とした。

※(品質管理できないので)品質管理指標は別に設けておくとよい。

■論文ネタ6 EVMを使った背景(H24午後1 問3 抜粋)


過去にL社で行われたプロジェクト管理には次のような問題点があることが分かった。

・進捗管理は、開発担当者が自分で見積もった進捗率に基づいて行われており、客観的な基準による進捗の把握が行われていない。

・システム開発に関する利用部門の参加意識が低く、工程ごとの成果物の確認が、確実に行われていないので、テスト段階で仕様変更が多発する。

・客観的な基準によって進捗を把握するためにEVMを採用する。

・EVMを利用すれば、EACを求めることで常に完了予定日を意識してプロジェクト管理できる。

・EACを使えば、完了予定日を明確に把握して進められる(早い段階で進捗遅れを把握できるから)

・WP単位にPVの設定、ACの集計及びEVの計上を行うから

■論文ネタ7 要員マネジメント


大勢の前では話しにくいことを聞き出す為、リーダ配下のメンバと個別にヒアリングした

■論文ネタ8 要員マネジメント


連絡や相談を頻繁にしてくるメンバがいる一方で、発言しないメンバもいる。

そこで、ミーティングの場でメンバ全員に意見を言わせるようにし、問題や状況を全員に認識してもらうようにした。発言する意見に関しては事前に考えてきてもらうようにした。

そのうえで困っているメンバに対する相互支援等改善方針をまとめた。

■論文ネタ9 クラッシング(要員追加)


問題が発生したアクティビティの後続のアクティビティについて、5日分のクラッシングを行うために、緊急で要員を調達する承諾をもらっている。

クラッシングに充てる応援要員の人数は2人が妥当だと考えた。

過去の同種のアクティビティの生産性と応援要員の候補者のスキルを考慮して、作業に必要な工数を算出した。

さらに、仕様の理解やチームのノウハウの習得に要する応援要員の初期の立上げ工数、教育やレビューを行う受入れ側の工数を織り込んだ。

■論文ネタ10 契約形態(H20午後1 問2 抜粋)


要件定義、外部設計と総合テストを委任契約で、内部設計から結合テストまでを請負契約にする予定である。

稼働開始は4月初めであり、開発規模からすると余裕のないスケジュールである。

■論文ネタ11 請負契約(完成責任)


後から想定外の成果物を要求され、費用や期間が予定を超過するリスクを回避するため

請負契約の締結に向けて、発注元との間で作成すべき成果物の種類や記述レベルを合わせるようにした

■論文ネタ12 請負契約(コスト超過防止)


請負契約部分の見積り精度をあげてリスクを低減するために、外部設計終了後(請負契約直前)に再見積りを行うようにした

■論文ネタ13 請負契約(指揮命令権)


サービス提供部門からの仕様変更要求の多発などで,プロジェクト推進に問題が発生した場合、担当者ではなく、客先上長に相談するようにした。

請負契約部分の定期報告は行わないようにした。

請負契約部分については結合試験結果のみの報告にするようにした。

⇒請負契約部分は、最終成果物の納品を行うようにした。

これまでの追加開発の中で問題となる点がなかったかどうかを調べるために,ここ半年ほどのM 社内の報告資料を閲覧した。そこから,各リーダと配下の担当者の残業時間が多いという問題点をつかんだ。

Q 社との間に,報告内容の似た二つの定例会議があり,各リーダは会議の出席や準備に追われ,残業時間が増加していたことが分かった。


■論文ネタ14 プロジェクトの背景(H19午後1 問3 抜粋)


現在稼働しているプログラムは、度重なる機能追加によって構造が複雑になり保守性が低下している。

そのため、再構築を契機に全てのプログラムを構造化し新規に開発する。

■論文ネタ15 プロトタイプ


要件定義工程において、プロトタイプを作成することにした。

なぜならば、操作性に関する要望を仕様に反映するためだ。

具体的には、仕様検討の進め方として、業務経歴システムや研修管理システムへの改善要望を多く出している社員にプロトタイプを使ってもらい、意見を把握した。

■論文ネタ16 プロトタイプ(H28午後1 問1 抜粋)


日常点検を阻害しない操作性を確保できるかどうかを検証するため、設計段階でプロトタイプによる検証を行った。

■論文ネタ17 要件スコープ決定


起因する問題点の影響度から要求の優先順位をつけるため

要求の背景となる現状の業務の問題点を一覧表にまとめ、関係部門の要求がどの問題点に起因しているかを整理することを求めた。

ほかにも沢山!

さらに動画解説!!

画像1

1.論文ネタ一問一答

■問題1

進捗遅延の兆候として考えられるものを答えよ

■答え

・残業時間の増加

・生産性の悪化

・顔色が悪い、体調不良、遅刻欠席の多発

・レビュー指摘件数の多発

■問題2

以下の進捗遅延の兆候を察知するために事前に対策しておくべきことをそれぞれ答えよ

・残業時間の増加

・生産性の悪化

・顔色が悪い、体調不良、遅刻欠席の多発

・レビュー指摘件数の多発

■答え

 残業時間の増加

  稼働状態を監視し、週5時間以上の残業がある場合など、基準値を決めておく(勤怠管理)

 生産性の悪化

  生産性の評価指標を決めておく

 顔色が悪い

  定期的に対面で顔を合わせるようにする

 レビュー指摘件数

  品質管理指標を決めておき 設計書1ページ当たり〇〇件を上回った場合などの基準値を決めておく

■問題3

 進捗遅延のリスクが顕在化した場合に行うべき対応を答えよ(複数)

■答え

 ・クラッシング(要員追加)

 ・部分稼働

 ・本番稼働開始時期の見直し、納期の延期(情報処理試験ではプロジェクトとの特徴との兼ね合いであまりない)

 ・スケジュールの見直し 等

 

■問題4

 クラッシングを行う際に考えなければいけないことを答えよ

■答え

作業の引継工数

期待していたほど生産性が出ない場合の考慮

新たな人間関係の形成

追加コストの承認

■問題5

 レビュー指摘が基準値を上回った場合の分析方法

■答え

 QC7つ道具 

 ⇒例 パレート図 ※論文の差異は定量的に 指摘200件のうち120件が〇〇に原因がある

  例)誤字標準化違反⇒軽度な指摘で本質的な問題に目がいかない⇒自己レビューチェックシートであらかじめ誤字脱字を取り払う

  例)特定要員の設計に問題⇒特定要員の設計の再レビュー、要員交代

■問題6

 バグ累積を監視し品質状況を把握するにはどのような管理方法があるか。

■答え

信頼度成長曲線

縦軸:故障累積件数 横軸:日数or投入件数

※収束傾向にない場合に対策

※対策が必要な基準値をあらかじめ決めておく

■問題7

品質分析等で用いられるQC7つ道具はどのようなものがあるか

■答え

パレート図

管理図

特性要因図(フィッシュボーンチャート) 等

f:id:riki12342000:20170826105603j:plain

年度:平成24年問3 EVM

 進捗管理は、開発担当者が自分で見積もった進捗率に基づいて行われており
 客観的な基準による進捗把握は行われていない

 客観的な基準によって進捗を把握するためにEVMを採用する

 ■WBS策定
  ①工程別にレベル1のWBSを策定した

  ②工程ごとに必要となる成果物を洗い出す。
  ③次にそれらの成果物の構成要素となる要素成果物を洗す。
 
  ・これらの構造を明らかにするために、階層構造の形で表現し文書化した。
  ・上位成果物が全ての要素成果物を含んでいるか、下位の要素成果物で上位の成果物を確実に作成することが
   できるか確認しながら進める

  ④最下位の要素成果物をワークパッケージ(WP)として設定した

 ■EVMの導入
  ①進捗管理のベースラインとなるプラントバリュー(PV)を設定
   -WP(ワークパッケージ)ごとに、必要なタスク(アクティビイティ)を洗い出す。※各タスクは所要時間が1週間以内で収まる様に細分化
   -各タスクの予算、スケジュールを策定してPVを定めた

  ②アーンドバリュー(EV):出来高の計上方法
   -今回は途中計上は行わず、タスク完了時にEVを計上する
   -タスク完了基準を明確に定め、第三者による確認を受けて完了とする
 
  ③実コスト(AC)の集計方法
   -今回は社員の人件費が全て
   -社員の稼働時間の管理に焦点をあてる
    ⇒タスク単位に作業時間管理ができるようにシステム管理者へ依頼した(現状は、工程単位)
    プロジェクト開始までに対応できるとの回答あり

   上記をEVMガイドラインとして情報システム部部長の承認を得て、プロジェクトメンバに説明した

 ■EVM実施
  ・週次でEVMのレポートを確認する⇒定例ミーティングで詳細を確認
  ・SPI,CPIが悪化していないかを確認する
   風邪で欠勤⇒タスク完了していない⇒EV計上できていない⇒SPI,CPIが悪化
   着任が遅れる⇒同単価の人を入れる⇒完了⇒EVを計上 ⇒SPIが悪化

上記を基準として、問題が起こったのが、いつを明確化する
(例:内部設計が開始されて2週間が経過した頃、全体8週)か

ーーーーーーーーーーーー


年度:平成23年問2 ERP

・E社のERPパッケージを採用することにした

・開発期間には20%のスケジュールの余裕を含んでいる

・適合率が一定以上であれば、追加開発の規模で開発期間が決まるが
 現時点での適合率はその条件に当てはまる
・要件定義後にスケジュールを見直す

・要件定義担当者がE社メンバからERPパッケージの標準機能の説明をうけつつ、
 業務プロセスと業務内容の要件を記述したドキュメントを作成する。

・ERPの標準機能と業務要件のフィット&ギャップ分析を行う

・フィットした項目に関しては、業務ごとにERPで使用する機能をドキュメントに追記していく

・ギャップ項目に関しては、関係者で業務プロセスの変更、追加開発等の対策案を検討し、
 その結果をドキュメントに反映する。
・追加開発が必要な部分は、E社に対して情報を提供し、画面、帳票、機能などの
 追加開発の規模を見積もるために必要な情報をドキュメントに記載する。

・(業務プロセスが変わることに抵抗するのではなく)ERPの標準機能を出来るだけ使うように、
 経営層に依頼した。
・ギャップ項目への対応の為に追加開発を行うと、中規模開発の範囲に収まらなくなり予定の
 納期を超えてしまう
 (上部を通して、利用部門を説得しできる限り、ERPの標準機能を用いるようにしてもらう)

画像1

午後1で論文ネタになりそうな問題
年度 問 論文ネタ 概略 詳細(論文で使えそうな要点)
24 1 ◎ 品質管理 ・レビュー
2 △ プロジェクト引継 ・PMが倒れて引き継いだプロジェクトの現状整理から
3 ◎ 進捗管理(EVM) ・WPの作成方法
4 ◎ 品質管理 ・結合テストの品質管理指標
23 1 △ 進捗管理 (クリティカルパス法) ・クリティカルパス ・全体で2ヵ月短縮 ・クラッシングを行う(要員追加) ・クリティカルパス上の作業を2ヵ月短縮 ・クリティカルパス上にない作業だが、クリティカルパス上の作業を2ヵ月短縮すると、当作業がクリティカルパスになる為、全体を2ヵ月短縮するため1ヵ月短縮しないと全体的に短縮できない。
2 ◎ ERPパッケージ ・フィット&ギャップ
3 △ 同時開発 ・別機能の並行開発とIF調整 ・現行システムの障害発生時の対応
4 △ 品質管理 (前後工程の品質) 午後1問題として何度も解いてみる
22 1 × 品質管理 ・結合テストでの品質評価グラフ
2 △ 対立 ・これまでIT化を進めてきた部門からの抵抗が激しく協力を得るのが難しい状況 ⇒外部設計書の最終承認期限を委員会の場においてトップダウンで確定してもらう ・プロジェクトのスコープの確定
3 〇 移行方式 ・移行方式については当問題がそのまま使える
4   見積もり ※未回答(使えそう)
21 1 ◎ リスク分析 ・定性的リスク分析(発生確率×影響度のマトリクス) ・予防措置とコンティンジェンシプラン
2 ◎ 外部委託 ・委託先の選定方法⇒評価軸を設けて点数化(客観的、定量的に判断) ・適正価格で委託先を選定するため、複数社に見積り依頼
3 △ 契約形態 メンバ管理 ・後から想定外の成果物を要求されコストとスケジュール超過を防ぐために、成果物の種類や記述レベルを契約時に織り込んでおく ・外部設計終了後に再見積り※内部設計以降は請負 ⇒見積もり精度を上げてコスト超過のリスク回避するため ・担当者の残業が多い(スケジュール遅延のリスク要因) ⇒類似する会議が多くリーダが多忙⇒メンバに適切な指示が出来ずに作業誤りとそれによる手戻りが発生(残業時間が増加)
4 ◎ 品質管理 ・品質管理指標の基準値と実績値 ・内部設計レビュー(基準値に達しない場合の対処)
20 1 ◎ 進捗管理(EVM) ・EVの計上方法(要件定義、外部設計、内部設計、製造工程、結合テスト)
2 △ 要件追加対応 ・定期案件と追加案件 ・定期案件のプログラムを流用して新規に機能を作成する(相互の影響を少なくして作業を行うため) ・要員調整(定期案件の一部機能を先送りすることで、追加案件にリソースをシフト)
3 〇 要件定義遅延 ・要件定義の完了目処がたたずに、外部設計の契約締結の見通しが立たない
4 × 2段階開発 ・保守期限に間に合うように、現システムの移行を行った後に、追加開発を行う

画像1


この記事が気に入ったらサポートをしてみませんか?