論文添削で合格レベルに達しました ― システム開発未経験からのプロジェクトマネージャ試験【記録7】

4月 12, 2020プロジェクトマネージャ試験

先日、中止が発表されたプロジェクトマネージャ試験。受験予定日のほぼ1カ月前の3月19日に、TACの論文添削の２回目を実施しましたので、その結果についてまとめたいと思います。

ちなみに、論文添削は合格点を超えていましたので、「合格論文例」としても参考にしていただければ幸いです。

この記事では、プロジェクトマネジメントはもちろん、システム開発・保守・運用なども未経験の、純粋なネットワークエンジニア（主な仕事はネットワークの監視・保守・運用）が、無理やりプロジェクトマネージャ試験に挑む過程を記載します。

冒頭の解説の通り、本記事は未合格者かつプロジェクトマネジメント未経験者が執筆しております。多くの教材や学習のハウツー本にも書かれておりますが、合格していない人の「これをやると効果的！」という内容はあまり信憑性がありませんので、ご注意ください。

論文添削（ツーウェイ添削）の結果

模擬試験の翌日、3月19日に論文添削（正確には「ツーウェイ添削」）の2回目を実施しました。そして、その結果はこちら。

実は、前日の模擬試験に続いてやってはいけない凡ミスがありましたが、今度こそ合格点を突破しました！

残念ながら、設問イは相変わらずの6割未満ですが、設問アと設問ウが7割到達。全体としては65点という結果です。

頂いたコメントとしては「文章がやや冗長なので、時間によっては削っていい」とのこと。この点については、意図的であり、また戦略的に状況に応じて削る予定だったので、下手な手戻りを発生させなければ問題はないかと思っています（それにしても冗長すぎるかな？と、書きながら思ってましたが）。

合格レベルの「論述の対象とするプロジェクトの概要」

念のため合格レベルに達した時の論述の対象とするプロジェクトの概要を掲載します。（質問票・テンプレートなどとも呼ばれる）。

勘違いしないで欲しいところは「この内容なら合格できるのではなく、論文との整合性として合格レベル」というところ。あくまで重要なのは論文との整合性なのでその点は注意してください。

ちなみに、私が書く内容は、毎回ほぼ同じです。勉強の過程でちょっとだけ修正しましたが、たぶん、図の例が完成版になるかと思います。

設問ア：全体的に問題なし

実際に記述した内容は以下のとおりです。

「1.1 プロジェクトの特徴」については、何度も書いていればほとんどテンプレート的に対応できます。油断せずに設問の内容を読み取れば、ほぼ問題は発生しません。

問題になりやすいのは「1.2」の部分（提出した論文では間違えて「2.1」になってる…）。

多くの午後IIの設問アで「1.2」の部分で、今回のプロジェクトマネジメントでの課題が問われます。この部分は、設問と問題文の影響を大きく受けるため、変動が大きい。

今回提出した内容での指摘は「EVMを利用した」というところは「PMとして工夫したところなので、設問イに回してもいい」というところ。減点ではありませんが、戦略的に位置を変えることも検討した方が良さそうです。

工夫点（EVM）を設問アに入れた理由

「EVMを設問アに入れるか？」については、書きながら少し悩みました。

それでも設問アに入れてしまったのは

解答例の論文で、EVMを設問アの後半に入れてたものを見たことがある（それをパクった）
設問アの文字数に過不足が出そうだった（代わりの文章がすぐに思いつかない）

という理由です。

実はこの「設問アの2.1でEVMを登場させる」というのは、過去に見たスケジュールマネジメント関連の解答サンプルを思い出して利用しました。ただし、これだけで終わると「課題がない」と思われてしまう可能性があるため、最後の一言で別の課題について「この点が、本プロジェクトの課題であった」と意図的に付け足しています。

また、設問アの文字数は、私が毎回悩まされるところです。設問アでは文字数の下限は明確に設定されていませんが、無難にやり過ごすなら600字程度は書いておきたいところ。一方で、長い文章を入れてしまうと、文字数オーバーの恐れもありますので、600字程度の文章のゴールが見えたのであれば、私の場合そのまま書き上げるようにしています。

設問イ：冗長とわかりながら書く冗長な文章

設問イは以下のとおりです。

6割は超えていませんが、大きな減点はありませんでした。設問アに続き、焦りのためか章番号の振り間違いがあり、このあたりの減点を防ぐことができたら、もしかしたら6割を超えていたかもしれません（というか、章の番号間違っても合格レベルになるのか…）。

もっとプロジェクトマネージャとしての知識や経験に基づくような内容を盛り込めていれば、点数を稼げていたかと思いますが、私の場合プロジェクトマネージャとしての経験がないため、ボロを出さず具体的に感じられる内容で字数を満たすことに集中して書いています。

ちなみに、知識がなく具体例も限られている私の場合、あっさり書いてしまうとだいたい文字数が800字に届くか危うくなります。

そこで利用したのが「繰り返し説明する冗長な文章」です。

この方法のメリットとしては

文字数を簡単に稼ぐことができる
誤解を招く表現を防ぐことができる

この2点です。

「誤解を防ぐために、私はあえて主語や時期、文章の意図について繰り返し記載しています」という程度の冗長性であれば、採点側も減点は難しいはずです。

ただし、日本語として明らかに間違っていたり、読みにくいレベルで冗長であった場合は、減点の対象になるでしょうし、文字数も少なめに評価される可能性は否定できません。あくまでも「ちょっと冗長な感じ」程度に抑えた方がいいでしょう。

設問イの最後はコンティンジェンシープランがおすすめ

私は設問イの最後に「工夫が上手くいかなかった場合のコンティンジェンシープラン」を書くようにしています（設問や問題文でコンティンジェンシープランが問われている場合は調整しますが）。

この方が、より万全な対策を行っていたことになり、知識もアピールできます（実際、添削でも「いい記述」となっていました）。

この内容はかなりあっさり目で問題ないです。文字数が多すぎる・時間がないというときは、全く書かないという戦略も使えます。

もしも、時間が不足している場合は、先に設問ウを書いてから、戻って付け足す形でも全く問題ありません。時間の余裕を見ながら、より点数を稼げるように利用していくといいでしょう。

設問ウ：戦略的に文字を削るのもアリ

設問ウの内容は以下のとおりです。

「3.1」の「以下のような工夫を行った」で始まる箇条書きは、解答例や使えるフレーズとして参考書でみかけたものを思い出して書きました。具体的な内容ですし、解答サンプルや参考書で見かける内容というだけあって「OKです」との評価。

「3.2」では、前回の論文添削と同じく「インフルエンザの流行」を取り入れました。といっても、直近では返却を受けたあとの見直しでしか確認していないため、全面改訂に近いものです。ここも評価は悪くないですが、具体例部分は「時間によってはカットしてもいい」とのこと。確かに具体例部分が「変更管理とその対処」ではなく「変更管理の原因に対する対処」になってました。