とつげき★マトはどこだ?(後藤くりこBlog)

コンサルタントくりこのBlog ・コンサルタントとして思うこと ・サラリーマンとして思うこと ・ディベートを世の中に広めていて思うこと ・女性として妊娠していて思うこと その他諸々思うことについて発信しています

カテゴリ:★Blog★ > プロジェクトマネージャ試験

タイトルの通り。
PM試験、落ちてしまいました。

午後1まではなんとか通過したようでしたが、午後2がB…
正直とても悔しいです…
来年の春に再チャレンジですね。。

秋試験はストラテジスト受けようと思っています。
PM試験に向けての勉強で学んだことを生かして頑張ります(・ω・)ノ

午後2問題の再現答案も、公開してみます。
たぶん、すっごく酷いんだけど。自戒も込めて。
選択は【問2】 でした。

以下、超架空設定です。
正しいのは自分が独立系SIerのN社に勤めてることくらい。
(但し、SIer的仕事はしてない。あくまでコンサル部隊なので。)

1.プロジェクトの目標・特徴と、設定した評価指標について
(1)プロジェクトの目標・特徴
 ・私は独立系SIerであるN社に勤めている
 ・医療機器の卸売業をいとなむK社の基幹システム再構築のPMを担当した
 ・開発期間は1年間、リリース厳守
 ・このシステムのうち、伝票処理にかかる部分については、度重なる改変で
  障害が発生しやすいので、特に品質重視でとまらないようによろしく
 ・開発工数は120人月
 ・プロジェクトメンバは、自社メンバだが、約半数とは
  これまでに一緒に仕事をしたことがない 
(2)実績値が評価指標の目標値を逸脱した工程と設定した評価指標
 ・逸脱したのはテスト工程
 ・設定した評価指標および目標値は以下のとおり
  ・リリース厳守のため、テスト消化率:10本/1日
  ・テスト項目は大目に、300項目/kstep
  ・バグは、40項目/kstep 
   累積数がゴンベルツ曲線に収束するかどうかチェック
2.評価指標の逸脱とその原因・影響の分析
(1)評価指標の逸脱
 ・4ヶ月でテスト工程へ。1日のテスト消化数が10本下回ることが出てくる。
  →まず静観。バグまで増えてきたので、チェック。
(2)評価指標逸脱の原因分析
 ・QC7つ道具のうち、パレート図を使用
 ・バグの発生原因を分析→プログラム設計書の誤り
 ・次にプログラム設計書の作成者別にパレート図を作成
  →Gさんに問題あり
 ・Gさんにヒアリングをしたところ、2つの問題がわかった
  ①Gさんの担当部分は伝票処理関係の部分だったが、
    これまでGさんにはこの分野の経験がなかった
  ②プログラム仕様書の元となった要件定義書が、難解だった
(3)特定した原因による影響の分析
 ・個々人のスキルを知らなかったため、急遽メンバと面談
  →どしろーとAさん、Bさんがいた
 ・要件定義書のわかりにくい部分を他に探した
  →ほかにはなし

3.原因・影響への対応策・改善策とその監視
(1)原因・影響への対応策・改善策
 ・Gさん担当領域について、テスト開始している部分のバグつぶしに
  別スケジュールを引いた。テスト入っていないものについては、
  プログラム仕様書 をインスペクション形式でレビューした
 ・Aさん、Bさんにはベテランのインストラクタをつけた
 ・保守性工場のため、伝票処理部分の要件定義書の修正を実施した
(2)策の実施状況の監視方法
 ・メンバとの月1回の1対1面談を行い、そのときの作業内容と
  その人のスキルとのミスマッチがないかを確認した。 
・・・あとなんか書いた気がするけど忘れた←


こんなかんじです。
使用したテキストから引っ張ってきたものをつぎはぎ。
この答案がどう評価されるのか、ちょっぴり楽しみで、
かなり不安。 

午後1についても答案が出るのは合格発表の1週間前のようなので、、、
とりあえず覚えている範囲で午後1問題の答案再現をここに書こうと思います。

字数適当。書いた内容をざっくりかき連ねます。
なお、選択した問いは【問1】【問2】です。
この2問を選んだ理由はフィーリング。
ぱらぱらめくってて、なんとなーく問3からいやな感じがした(笑)

【問1】
設問1
 (1)H社の業務手順をX社標準業務プロセスに沿って見直す作業。
 (2)稼動開始前のX社による監査。
設問2
 高影響度なステークホルダのプロジェクトへの関与度が低い状態。
設問3
 (1)見直し委員会とプロジェクトの一体感と関与度を高める効果。
 (2)高影響度・高関与度でプロジェクトを推進する役割。 
 (3)新業務プロセスに対する抵抗感を予め抑止するため。
   →この設問、特に自信がない、、、
   →抵抗感を抑止、ではなく、真剣に検討をさせる、というか
    プロジェクトへの関与度?を高めるため、のような気がする、、
 (4)H社の情報子会社であり、X社システム稼動後は運用業務を
   実施するという背景。
 (5)X社のH社スキルに対する不安の軽減とY氏の関与度を高める狙い。 


【問2】
設問1
 過去に稼動直前の総合テストで性能に関する問題が発見され
 稼動が遅れたことがあったため。
設問2
 (1)早期に新業務プロセスの操作性に なれることで、円滑に
   利用者トレーニングできるようにする期待。
   (なんか日本語へん
 (2) 無線ハンディ端末導入
設問3
 (1)既存業務プロセスからの変更が多く、新業務プロセスになじむことが
   できない可能性があるから(後半はどうかいたかわすれた・・・)
 (2)同様の事例を見ることにより、新業務プロセスの設計が
   スムーズになるという効果。
   (いまふりかえるとこの答案安直過ぎてあれだな、、、)
 (3)新業務プロセスに追加開発の内容も含める必要があるため。
設問4
 (1)追加開発内容についてM社パッケージ効率化で補完できないかの検討。
 (2)倉庫統合と業務効率の向上


こうして再現してみると、午後1の問2・・・酷い・・・。
といている最中の印象と、こうやって振り返るときの印象って、
ぜんぜん違いますね。。。

2015年春のPM試験が終わりました。
後半更新が滞っていたのは、
正直、試験直前ノイローゼ気味だったからですw 

仕事もそこそこ忙しく、PM試験勉強時間が確保できない・・・
挙句の果てに、「まーなんやかんやいいつつよゆーだろー」と思っていた
午前1問題の過去問(H26春試験、秋試験など)を通しでといてみたところ、

18/30(6割ジャスト) 
16/30(不合格)
17/30(不合格)

・・・という散々な結果だったんですよね。
これは本気で焦りました。

ただ、どーにかこうにか当日は帳尻が合って
自己採点の結果

【午前1】22/30 73%
【午前2】18/25  72%

・・・ほっと胸をなでおろす結果でした。 
午前1については、試験中に自信があって解答したものだけで
6割越えていたのですが、午前2は自信があるものだけでは6割を
越えていなかったので、まるつけてみて72%あったのはびっくり。

ちなみに。今回の教訓
【試験直前の直前の直前まで、あきらめずに、過去問に目を通すべし】

なんと午前1、午前2ともに、直前に見ていた問題と
全く同じ問題、計算問題の数字まで同じ、という問題が、
はっきり覚えているだけでそれぞれ3問も出題されました。
こういうのは本当にラッキー。

試験直前の直前の直前まであきらめずに過去問見ててよかったなあ、
と心底思いました。

今後も試験を受けるときはこの気概を忘れないようにしたいと思います。 

2015年春のPM試験が終わりました。
試験勉強をふりかえってみると、自分がIPAの高度試験について、
いかに知らなかったかを、いやというほど思い出します。

特に午後2問題は、ほんと、無知だった。

ただ、以下に書く内容を知っていたことは、午後2試験を受ける上で、
かなり大きな自信につながった。試験問題をめくったときに、
まず、何をすべきか?の指針がつかめたから。
そして、自分にPM経験が全くないことについて、
引け目が(すこし)やわらいだから。

わたしがPMの本来的な勉強以外で、
午後2の「お作法」として知っておいて得したような気がすることは、
以下にかいたとおり。※もしかしたら他の高度も一定同じかも?

・答案の内容は、事実にこだわる必要はない
 →しってはいたけど。初めはやっぱりちょっと抵抗あった。
   とはいえ、PM未経験者なので「事実がなくてかけない・・」では、
   合格はそもそも無理。試験勉強後半は割り切って考えた。
   そしたら、だんだん、割り切ることに慣れてきて
   「PMになりきって書く」という行為を少し楽しめるようになった。

・章タイトルをつける
 →設問の問いごとにかきわけじゃいい・・・わけではない。
   たいていの問いが、1つの問いの中で複数の事項に関する回答を
   求めている。したがって、読みやすさのためには、設問の問いを、
   さらに細分化(章立てをつくる)必要がある、ようす。
   これ、初め知らなかった。

・プロジェクトに関する記述は「完了したもの」として記述すること。
 →要求は「携わっている」ではなく「携わっ【た】」だから、過去のものにしましょう、
   とのこと。ちょっとかんがえれば判ったことかもしれないけど、
   私ははじめて論文書いた模試のとき、これやらかした。

・要求されていないプロジェクトの「特徴」をくどくど書く
 →自分が「携わった」プロジェクトについて仔細を人に伝えようとするあまり、
   要求されていない・・・つまり、設問に関係ない、プロジェクトの特徴までくどくどと
   書いてしまっていた。 

などなど

まあ、 今よみかえすとものすごく普通のことしか書いていな、
と思うけれど。わたし にとっては割と斬新だったので書き残してみた。

↑このページのトップヘ