昨年 情報処理技術者試験 プロジェクトマネージャ に合格し、備忘的、および今後の試験対策に勉強方法をメモしておこうと思っているうちに一年過ぎてしまった。そろそろ次の勉強に入ろうかという気持ちが出てきたので、忘れないうちに総括しておく。表題はSEO対策(?)なので、軽く受け流してください。
また、今年から試験の体系が変わっているので、その辺も留意して読まれる方は参考になればしてください。
1.午前対策 - ひたすら過去問
一に過去問、二に過去問、三四も過去問、五も過去問。はちと言い過ぎか?ただ、設問から選択肢までまったく同一の問題が、感覚的には 3 ~ 4 割出題されていたかと思う。午前試験は、足きりのためにあると考えれられるので、ここで落とすわけにはいかない。過去問はしっかりやるべき。
2.午後Ⅰ対策 - 時間がない!反射で解答
テクニカルエンジニア(データベース) の時もそうだったが、午後Ⅰの試験はまったく時間がない。はっきり言って考えている時間はない。ある程度、問題点について反射で解答できるようになっておく必要がある。じっくり考えれば解ける問題も多いはずだが、なんせ1時間30分で、おおよそ2,000 ~ 3,000 字程度の問題文を読んで、設問に 4 ~ 7 程度解答しなければいけない問題を、3 問 解かなければいけない。
2.1 問題解決は PMBOK を利用
午後Ⅱにもいえるが、基本的に PMBOK を知識の幹として、そこに情報をマッピングして覚えていくのがよいと思う。当時は第3版だったが、現在4版(日本語訳はまだかな)まで出ている。

安い本ではないが、下手に PMBOK の解説書を購入するより、この本自体を購入したほうがよい。これ自体が読み物になっており、解説書がなければ読めないような類の本ではない。
2.2 問題文にマーキングをしながら読む
先ほども言ったように、午後Ⅰはとにかく時間がない。設問に答えるときに問題文を読み直したり、該当箇所を問題文から探し直したりしている時間はない。 まず設問を読んで、問題文を読むときに、適宜マーキングすることをお勧めする。単に下線等を引くだけでは読み返すときに混乱すること必至。
自分は、たとえば、問題文に以下のようなマーキングを行った。これにより、必要な情報にすばやくアクセスすることができるようになり、最短の時間で問題文の読み直しが可能となる。
2.3 問題文を構造化する
問題文を読みながら、関係を問題用紙の余白に図示していくのは必須。こうしておかないと、上記同様また設問で必要な場合に問題文を読み直して、関係を再構築する必要が出てくる。 以下のような図を適宜描いていく。
会社間や、人物間の関係などは、上記のような図をつかって明確にあらわすことができるが、主観が入る構造や、文章自体の構造は、簡易マインドマップ風に余白に書いていくと、これも後で読み返すときに論理構造を再構築する時間を短縮できる。
もちろんこんな風にきれいに書いていたら時間がもったいないので、あくまでもマインドマップテイストで書くくらいでよいと思う。そうすると、箇条書きなどすることなく、必要最小限のメモで、キーワード間の構造が再度把握できるようになる。

2.3 時間感覚をつかむ
ボクサーは 3 分 を体に覚えこませたりするとかしないとか言うけれど、何度も言うけれど本当に時間がタイトなので、過去問を解くときに、一問 20 分くらいに時間を制限して解くとよい。自分の場合、通勤電車の乗り換えまでの時間がちょうどそれくらいなので、過去問をコピーして、電車で立ちながらそのコピーに上記のようにマーキングして通勤していた。
3. 午後Ⅱ - 論文っつってもビビる必要はない。
3.1 合格論文集を読む
論文試験といっても、たかだか数時間内で書き上げるもので、お題もその場でだされるので、すべて自分の経験から書き上げるのは無理な話。しかもPMを目指す人も受ける試験なんで、そもそもPMの経験自体がない場合も多いはず(自分もそう)。
なので、基本的には、自分の参画したプロジェクトなりをイメージし、自分がPMだったらならば、あの時起きた問題にこう対処したのに!とか、あの火を噴いたプロジェクト、自分がPMなら、こう進捗管理して、ああ軟着陸させたのに!とかの思いをぶつければよい。と思う。(自分もそう)
なので、まずは、どんなパターンで論文を書き上げるのかの参考に、その手の書籍も出ているので読んでおいて損はない。

3.2 自分のかかわったプロジェクトで題材になりそうなものの仕様を定量化しておく
問題に応じてさまざまな経験プロジェクトの属性が瞬時に思い出せるならよいが、そうでないなら、モデルプロジェクトを想定しておいて、問題選択時にそのプロジェクトに当てはまりそうな問題を選択すればよいと思う。午後Ⅱで 3 問 くらいから選択できるはずなので、1 問は当てはまる問題があるはず。逆に言えば、過去の出題状況を見ながら無難なプロジェクトを想定しておく。
大属性 | 中属性 | 具体的な状況 |
自分の会社 | 業種 | 情報処理サービス企業 |
本社所在地 | A 県 | |
従業員数 | 1,500 人 | |
役職 | 主任 | |
経験年数 | 10 年 | |
プロジェクト | 名称 | 調達システム |
概要 | 調達システムの開発 | |
技術的側面 | Javaを利用した既存システムのリプレース、ホストの既存システムの陳腐化 | |
総工数 | 63 人月、40画面、6バッチ | |
開発期間 | 12 ヶ月(2007年 6月1日 ~ 2008年 5月20日) 稼働日 253日 | |
開発費用 | 5,357 万円 (要員費用のみ) | |
要員 | 2 ~ 7人 | |
自分が担当したフェーズと役割 | プロジェクトマネージャとして、すべてのフェーズ |
てな感じでフィクションでもかまわないので、 論述するプロジェクトを具体的に把握しておく。
また、スケジュールを自分で組み立てたりする立場になければ、MS Project などのツールを使うなりして、スケジュール管理、工数管理、進捗管理をシミュレートしておくとよい。
例えば、フェーズごとの期間や工数の目安などは、COCOMOの計算式をつかったりすれば、それなりの数字が出てくるので参考に。
3.3 論文の骨格
先ほど、プロジェクトを想定しておけば、問題の 3 問のうち、1 つはあたるはず。のようなことを書いたけど、正しくは、想定したプロジェクトについて、PMBOK の 9 つの知識エリア それぞれについて、自分が論文の題材とするプロジェクトに対して、以下の項目についての想定をしておけば、想定がまったく当てはまらない状況は考えられない(と個人的には思う)。想定するのは、
9 つの知識エリア
それぞれに対して、
論文の骨格
- どのような前提のプロジェクトか?
- どのような問題(および問題の兆候)があるのか?
- どのような原因があると考え、どのような対策をとったのか?
- どのようなツール(PMBOKでいうところのツールと技法)を使ったのか?
- とった対応をどう評価しているのか?
- 反省点は何か?
想定しておけばよい。
ツールと技法について、具体的には、このような感じ。
まずは、過去の問題に対する論文、上記にあげた論文集や、参考書の模範解答などを上記に従い、構造化してみることをお勧めする。
これによって、自分が書くべき論文の組み立て方が明確になるはず。
自分は、上記イメージで、模範論文を解析して作成した。
Excelファイルをここにおいておく。
最終的には、自分が想定するプロジェクトに対して、最低 9つの知識エリアに対して1つずつ、模擬論文を書いておくなり、上記骨格のみでも想定しておくなりしておけば、当日の実際の問題にもその変形で対応できるはず。
んー結構がんばって書いた。参考になれば幸いです。