PM未経験から1発でプロジェクトマネージャ試験合格体験記

なるものを一度は書いてみたかったよーめいです。（こういうのぐらい書かないとブログが永久凍結するので……）

ちょっと長めですが、ブログの展開は以下の通りです。

1. 2017年プロジェクトマネージャ試験結果
2. 合格までの勉強法
3. 午後2筆者回答例
4. まとめ

1.2017年プロジェクトマネージャ試験結果

2017年4月16日に受験したプロジェクトマネージャ試験（以下PM試験）の結果が6月21日に発表され、無事合格した。初めての試験で一発合格なので結構驚いたのである。

私のスペック

を簡単に書くとこんなところである。

• 3流文系大学卒のメーカー系SEに所属する30前後
• 普段の業務は運用がメイン。
• 資格取得で給料が上がるため、嫁さんの理解は高い。
• 年明けから3月中旬までは閑散期でほぼ定時帰りが可。3末から4月中旬まではほぼ毎日21時近くまで残業。
• 中規模以上の開発PJの参加経験なし、勿論PMの経験もなし
• 去年応用情報技術者試験に合格している。
• 今回がPM受けるの初めてである。
• 自分の周りには同年代でPMとITストラテジスト持ってる人や、不動産御三家資格（宅建、マン管、管業）を持ってる人がおり、資格取得に理解のある人がいる
• 将来PMを希望しており、そのために攻めて勉強しようとこの資格を取ることを決意（高度難関御三家（PM・監査・ストラテ）を取らないと給料が上がらないのもある）

 というものである。環境にはめぐまれているが、自分自身のスペックはそうでもないことが分かるだろう。（旧帝国大学出身者のような偏差値が高くテストは負けない人とか、教科書読んだらすぐ暗記できる人とかみたいに）

応用も4年連続で落ちる位なので、この手の資格で1発合格した経験は一度もない。ただ、応用に受かった年は自分の勉強に対する取り組み方を理解できたのはある。それは後で書くとする。

実務未経験だが、ITSSレベル3の知識はあり、応用受かってさほど月日が経ってないので、机に向かう習慣やテスト的な知識はそれなりにある。というのが私のスタートラインである。

だから、このブログ見て「今まで全く勉強してなかったけど、年齢も年齢だし、そろそろ資格取得頑張るかー」だと、もしかすると足りないかもしれない。

逆に日本語能力が高く、問題読めば何を聞いてるのかすぐわかるよ。なら私より勉強しなくても受かるかもしれない。

私はこういう短期間で合格した他の記事を読んだ人が、何だPMなんて1ヵ月でちょっと論文対策すれば受かるんだろ？と勘違いして自爆する人を防ぎたいからである。私と同じような凡人は諦めていっぱい勉強しよ^^という話なのだ。

2.合格までの勉強法

社会人で働きながら勉強する上で重要なのはテキスト以上に環境作りである。

応用に落ち続けた時は、他の人のように図書館やカフェで勉強していた。しかし、落ち続けた。答えは簡単だ。言い訳して逃げていたのである。

今日は席が空いてないから出鼻挫かれたわー、帰ろう。カフェで勉強してたけど隣が煩いから集中できないわ、帰ろう。昨日負けたあのキャラにリベンジしたいなー、ゲーセン行こう。etc

それぐらいには弱い人間で、意志力も1月経たない頃には脆く崩れるのである。

だから私は気づいた。絶対にそこに行ったら100％空いてて、基本煩い人がいなくて、周りも勉強していて、その場に行ったら絶対に勉強できる環境でないと、俺は勉強できない！と。

そうして私は色々調べて、TAC渋谷校に通うことにした。

上記の条件にぴったりマッチし、そこにさえ行けば嫌でも勉強するしかなくなる。これを1ヵ月繰り返していたら、そのうちTACに通うという動作にモチベーションと言う概念が無くなってきた。*1

よく言われる習慣化にかかる時間に沿って動くことができたのだ

その結果無事応用情報技術者試験に合格した。そのため、今回もこのやり方を踏襲し、年明け前の12月上旬からTACに申し込んだ。

お値段数回の授業と模試と2度の論文添削がついて4万円。これに試験日までフリーで使える空き教室が使い放題、を考えれば安い物である。

実際に勉強が本格化したのは1月半ば。大体週5でTACに通うことを目標にした。平日は18：30～21：30まで。休日は10～20時ぐらいまでである。途中抜けた期間や気が乗らなかった時もあるが、トータル300時間以上は勉強した。

勉強に使った教材

午前2

午前2は以下のテキストを使った。

プロジェクトマネージャ 合格トレーニング 2017年度 (情報処理技術者試験対策)

 正直問題解けるテキストなら何でも良かったが、TACに申し込んだのでこのテキストがついてきたので、これを使い倒した。

正直午前2については、応用の知識が残っていたのでさほど苦労しなかった。それに過去問が何度も繰り返し出題されると聞いていたので、3回解いて、近年の過去問3年分を3回解けば良いかなと思って、直前期まで放置した。

その代わり午前2は解くのにエネルギーを使わないので*2、どうしても気が乗らない時用に午前2を解く等はしていた。

 午後1

午後1は上記テキストに加えて、以下も参照した。

プロジェクトマネージャ 午後1 最速の記述対策 2017年度 (TACの情報処理技術者試験対策シリーズ)

 正直言って、これで解き方のコツやどういう観点で問題を解けばいいのか悩むぐらい全く解けなかったのだ。上記テキスト1周目の回答結果は以下の通りである。 

ご覧のようにできは散々である。とても7割から程遠いことが伺えるはずである。もし勉強時間が1ヵ月しかなかったら、結果は散々であっただろう。でもこれを解いたのが2月だったので、最終的に7割近く取れたのである。

PMの問題はこれだと思う箇所を抜き出すだけでは回答できない。その問題が品質・コスト・納期のどの観点からなのか把握し、どうすれば品質・コスト・納期の問題が解決するかを考えて、そこに該当する箇所を利用する。

テキストの問題20問と直近3年の過去問とTACオリジナル問題で間違えた箇所がどの観点からリスクと捉えたのか、どうすればそのリスクを解決できるのか、その考え方を徹底的に暗記するまで復習した。私みたいな凡人はその問題の一つ一つを覚えるしか点が取れなかったので仕方がないのである。

この頃には午後1の問題の流れも覚えるまでになっていた。午後1での問題文とその解決法は午後2の論文でも使えるネタなので、覚えて損はないはずである。*3

午後2

午後2は以下のテキストが大変参考になった。

プロジェクトマネージャ 午後2 最速の論述対策 2017年度 (TACの情報処理技術者試験対策シリーズ)

 このテキストは事前準備をしっかりすることが、午後2の論文に受かるコツであると記載されている。

準備とは論文に使えるモジュールをたくさん作り、当日の問題に沿ってモジュールを組み合わせることで論文を作る、というものである。

確かに問題に沿ったPJを経験していれば2時間で3000字書くのは訳ないはずだが、それでは運ゲーになってしまう。

しかし、そういう「運」に頼らずに、事前準備をして自分が直接経験がない問題でも、参加したプロジェクトにおいてPMがやっていた工夫や社内で紹介されていた実例等から、論文に「使える材料」を選び出してストックすれば、どんな問題が出ても答えることができるのである。

「自分が経験したA社案件のシステムを使って、PMの工夫については社内で紹介されていたB社の例、評価や課題については模範論文のあの内容を使おう」といった感じで回答できるようになるということだ。

そのために私は小さいノートに以下のようなモジュールを書き写した。

モジュール作成のためのネタは以下の参考書を参考にした。

プロジェクトマネージャ 合格論文の書き方・事例集 第4版 (論文事例集シリーズ)

 論文の記入例が30種類程あるので、その論文のエッセンスを20パターンほど作り、後は電車の中でPJの流れを徹底的に覚えた。

モジュールを作ったら、後はひたすら2000～3000字を2時間で作ることに慣れるのみである。最初は3時間半かかったが、書くにつれて2時間でまとまるようになった。大体本試験前に15問は論文を書いたと記憶している。

仕事後に2時間集中して論文を書くのは今までにない疲れとストレスを感じたが、ここが頑張り処と歯を食いしばった*4

 3.午後2筆者回答例

2017年4月、問1の問題は以下の通りである。

問1 システム開発プロジェクトにおける信頼関係の構築・維持について

　プロジェクトマネージャ（PM）には、ステークホルダとの信頼関係を構築し、維持することによってプロジェクトを円滑に遂行し、プロジェクト目標を達成することが求められる。

　たとえば、プロジェクトが山場に近づくにつれ、現場では解決を迫られる問題が山積みし、プロジェクトメンバの負荷も増えていく。時間的なプレッシャーの中で、必要に応じてステークホルダの協力を得ながら問題を解決しなければならない状況になる。このような状況を乗り切るには、問題を解決する能力や知識などに加え、ステークホルダとの信頼関係が重要となる。信頼関係が損なわれていると、問題解決に向けて積極的に協力し合うことが難しくなり、迅速な問題解決ができない事態となる。

　PMは、このような事態に陥らないように、ステークホルダとの信頼関係を構築しておくことが重要であり、このため、行動面、コミュニケーション面、情報共有面など、様々な切り口での取り組みが必要となる。また、構築した信頼関係を維持していく取組みも大切である。

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

設問ア：あなたが携わったシステム開発プロジェクトにおけるプロジェクトの特徴、信頼関係を構築したステークホルダ、及びステークホルダとの信頼関係の構築が重要と考えた理由について、800字以内で述べよ。

設問イ：設問アで述べたステークホルダとの信頼関係を構築するための取組み、及び信頼関係を維持していくための取組みはそれぞれどのようなものであったか。工夫した点も含めて、800字以上1600字以内で具体的に述べよ。

設問ウ：設問アで述べたプロジェクトにおいて、ステークホルダとの信頼関係が解決に貢献した問題、その解決において信頼関係が果たした役割、及び今後に向けての改善が必要と考えた点について、600字以上1200字以内で具体的に述べよ。

この論文は平成26年から登場した、具体的な指定が無いVerの問題である。近年までは問題文の指定に沿って論を進めないと不合格になることが多かったが、よりPMの実体験を反映した幅広い問題も出そう。というのがきっかけらしいが、指定が無い分下手をすると一般論を述べるだけになってしまう。

こっちのVerは難易度が高いため避けるのが無難であったが、問2が品質管理であり、私が一番苦手としている分野であり、ステークホルダとの調整は比較的得意な論点であったため、こちらを選択した。

この問題の注意点は三好隆宏先生が詳細に解説しているので、参考にすると良いだろう。私はステークホルダ系のモジュールにステークホルダとの関係性が出題された午後1の問題と、実体験でやりやすかったレビューを記入した合わせ技で作成した。

• 120～115分

開始5分は問題を瞬時に決めた後に、本PJの概要を別紙に記入する必要がある。タイトルや人数、予算や環境、期間等を記入する。勿論私は開発PJに参加したことないので全て適当であるｗ

ここはよっぽど非現実的なことを書かなければ減点の対象にはならないらしい。

• 115～100分

15分かけて、各論のタイトルと問題文の指定に沿った肉付けを行っていく。

実際に本試験で書いた概要は以下の通りである。

こんな感じの事を15分で構築する必要がある。この作成が論文の肝であり、ここで論の展開をミスると途中で矛盾が生じてしまう。しかしここで盛り込み過ぎると時間が足りなくなる。この塩梅は慣れるしかないのである。

 過去の傾向からここは少しバッファをもっているが、90分に近づいたらある程度まとまっても書き始めるようにしている。

• 100～5分

ひたすらに書く、ただただ書く、腕が痛くなっても書く。ここまで来たら無心で書くが、書いている内に字数が足りないなと思ったら追加情報を盛り込む。設問アならメンバーの人数とか彼らのスキルレベルとか。逆に書き過ぎだと感じたら余計な情報を省く。

ただし、設問イウは書きすぎると2時間に間に合わないことが多いので、設問イは1000字程、設問ウは800字程に抑えられると時間と質のバランスが良くなることが分かっている。

• 5～0分

誤字脱字が無いか、関係性に矛盾がないか、論点に整合性が欠ける展開がないか再度見直しを行う。文を挿入すると若干減点対象となるが、それでも論点ずれによる大幅減点に比べれば安い物である。

そしてその時間で作成した論文は以下の通りである。ただ、一部違う展開かもしれないし、これが合格確実な論文ではなく模範解答ではないことをご留意頂きたい。

問1 システム開発プロジェクトにおける信頼関係の構築・維持について

1-1.プロジェクトの特徴

私が携わったプロジェクトはおもちゃメーカーA社の販売支援システム（SFA）導入プロジェクトである。A社含むおもちゃ業界では競合他社とのシェア争いが過激化しており、A社の売上やシェア率は年々低下している状態であった。そこでA社経営陣は販売力強化による早期シェア率拡大を目標とするSFAパッケージの導入を経営者会議で決定し、その導入・開発に私が所属する情報システム開発会社のB社が選ばれ、私が本プロジェクトのプロジェクトマネージャを担うことになった。本プロジェクトの特徴は年末のクリスマス商戦に勝つためにSFA導入が必要であるため、納期の遅延は許されないことである。また、SFA導入はコスト削減の一環でもあるため、予算も厳守である。年末までは5ヵ月しかなく、類似プロジェクトより1ヵ月短いものであった。*5*6

1-2.信頼関係を構築したステークホルダと信頼関係が重要だと感じた理由

本プロジェクトではSFAを利用するA社営業部（以下利用部門）との信頼関係の構築が必要だと感じた。背景として別の類似プロジェクトにて、利用部門の要望を無視してパッケージ導入を推進したため、利用部門の協力をほとんど得る事ができなかった。そのため、抜け漏れやバグが多く、手戻りが多発し、大幅な納期遅延と予算超過を起こしてしまった。このような事例を本プロジェクトでも起こさないようにするためには、利用部門との信頼関係を築きながらプロジェクトを推進する必要があると私は考えた。そこで私は以下の作業を実施して信頼関係を築き、本プロジェクトを成功に導くことができた。

2-1.ステークホルダと信頼関係を構築する取組みと工夫について

ステークホルダである利用部門との信頼関係を構築する取組みとして、私はフィットギャップ分析を行うために、利用部門からパッケージの機能に沿った要望を幅広く聞くことにした。具体例として、利用部門とB社開発要員全員集めた会議を開き、ブレーンストーミング法で要望を集めるということを行った。利用部門のヒヤリングを密に行うことで、利用部門のことを考えたパッケージ導入を意識させる狙いがあった。ただし、要望はパッケージ機能に沿った叶えたい要望に限定させることには注意をはらった。これは制限なく要望を聞くと、現プロセスに沿った要望になってしまい、SFA導入による大きな業務改善が見込めないと感じたためである。*7

工夫した点としては、B社要員の開発環境をA社利用部門と同じフロアにさせて貰うようA社にお願いした点である。これは早期に信頼関係を構築する必要があるため、物理的な距離を近づけることでお互いの信頼関係が構築しやすくなると考えたためである。さらに、利用部門が要望に上げなかったが、本当に困っていることが発見しやすくなるという効果にも期待した。

2-2.信頼関係を維持していく取組みと工夫について

信頼関係を維持していくために、私はパッケージのプロトタイプを作成した。作成したプロトタイプを元に利用部門とウォークスルーを実施し、改善点はすぐに直すようにした。こうすることで、利用部門から機能面だけでなく、使用面からも要望を受け入れられて貰っていると感じさせることができ、より信頼関係の維持向上が図れると考えた。さらにプロトタイプに触れる機会が増えれば、SFA導入後の教育にかかる時間も減らせると考えた。

工夫した点としては、ウォークスルーを少人数でフランクに行う会を何度か設けた。これは肩の力を抜いて幅広い意見を求めることで、今まで気づかなかった指摘事項を発見させる効果と、利用部門とB社開発要員の距離感を今まで以上に縮める狙いがあった。実際、このレビュー以降利用部門の一部とかなりの信頼関係を築けているB社開発要員が何名かいたことが確認できている。さらに、ウォークスルー実施後に個別にヒヤリングを行うことにした。大人数によるレビューは声の大きな人の意見が多数寄せられ、声の小さな意見が埋もれてしまうことがある。このような声の小さな意見を逃さないために個別のヒヤリングを実施し、隠れた要望や指摘事項を逃さないようにしつつ、声の小さな意見も逃さないという姿勢から信頼関係を維持向上しやすいと感じていたためである。*8

3-1.ステークホルダとの信頼関係が解決した問題と信頼関係が果たした役割

ステークホルダとの信頼関係が解決した問題としては、外部設計まで工程が進んだ時である。B社開発要員のC氏が外部設計書を作成している際に気になることがあったため、隣にいたA社利用部門のD氏に設計書の確認をお願いしたところ、既に完成していた設計書に機能面の漏れがあることを発見した。該当の外部設計書はすぐに修正されたが、該当の箇所は他の設計書にも影響を及ぼすものであり、このタイミングで気づかなければ多大な戻り工数を計上するところであった。C氏とD氏は上記で記載した少人数のウォークスルーで最も信頼関係を築いた2人であり、席が近く、C氏のお願いに対してD氏がすぐに確認してくれたため、大事には至らなかったのである。*9

その後のプロジェクトは順調に進み、信頼関係の構築が寄与した結果、多くの協力を得ることができ、納期通りの予定通り類似プロジェクトよりも1ヵ月早い納品を達成することができた。この際予算超過もなく、A社利用部門からもSFAの使用感についてお褒めの言葉を頂いたため、私はこのプロジェクトは成功したと感じている。*10

3-2.今後の改善点

該当の外部設計書はB社内のレビューでは承認が得たものであったが、該当のレビュー時にA社要員がいなかった。A社利用部門が多忙であることを鑑みて、設計書作成直後のレビューはB社要員のみで行い、全ての外部設計書が作成したタイミングでA社要員も加えてレビューを行うことになっていた。今回は偶然D氏が発見してくれたが、今後も同じような偶然が起こるとは考えがたい。今後は設計書作成直後のレビューもできる限り利用部門の要員を加えるようにし、上記のような漏れを防げるように進めていきたい。

以上

太字は問題に対して答えた箇所です。基本的には問題に対する答えを書く⇒具体例として～orこうすることで～という流れで書けば基本的に落とさないと感じていました。

ただ、正直この展開が思いついたのは奇跡だと思っています。同じフロアで仲良くなった利用部門が開発要員の手助けすることで解決するというモジュールは持っていなかったので（汗。よく閃いてくれましたｗ

4.まとめ

決して頭の良い人間ではないが、それなりに決意を持って諦めずにやり続ければ合格できるんだなと感じた試験であった。大きな目標を立てて達成した経験は初めてだったので自分の可能性もまだ捨てたもんじゃないなと感じているので、今後も色々な勉強に取り組んでみようかなと思っている。

*1:ただしこの1ヵ月はどんなに調子が乗らなくても絶対に我慢して通う事。最悪行くだけでも良い

*2:記述や論文に比べれば

*3:実際今年の午後2ではH19問1の問題に記載されていた「プロジェクトの一体感を高めるためにPJメンバーを一箇所に集める」というネタを使った

*4:それでもSNSで楽しそうな人見ると殺したくなるぐらいには追い込まれていたが……

*5:勿論こんなPJに携わった経験はないｗ

*6:問題を乗り越える関係上、何らかの制約事項があるPJにするのはデフォです

*7:要望は広く聞きすぎると膨張して収集がつかなくなるというありがちな状況に一応釘は刺しています

*8:ここは少し要素を盛り込みましたが、字数的に多少肉付けしないと800字ギリギリであったため

*9:同じフロアで作業を行う、フランクなレビューで仲良くなるがここに繋がっていきます

*10:実際利用部門と仲良くなった程度で1ヵ月も縮められるとは思ってませんが、失敗プロジェクトは論文に適しませんので……