PM

 このwikiは携帯版の表示に対応していないため、画面右上のパソコンのアイコンクリックでPC版用の表示からご覧ください。スマホを横にすると見やすいです。




プロジェクトマネージャ試験の勉強法まとめ
はじめに
 ITストラテジスト試験に合格するための勉強方法、お勧め参考書、お勧め論文事例集、勉強テクニック、解答のコツなどを紹介。
目次
プロジェクトマネージャ試験とは
概要
 プロジェクトマネージャ試験は、高度IT人材として確立した専門分野をもち、システム開発プロジェクトの責任者として、プロジェクト計画を立案し、必要となる要員や資源を確保し、計画した予算、納期、品質の達成について責任をもってプロジェクトを管理・運営する者を対象にした試験で、難易度は情報処理系の試験のなかで最高難度レベルとなっている。
必要な知識や能力
 プロジェクトマネージャ試験では、以下の知識や能力が必要とされる。
 実際に開発に関わっている人は、何らかの形でプロジェクトに参加したことがあるので、プロジェクトマネージャがどのような仕事を行っているか理解できると思うが、基本的にはプロジェクトを円滑に進めるための知識や能力などが必要になる。
  • 組織運営及びシステム全般に関する基本的な事項を理解している。
  • 個別システム化構想・計画及びプロジェクトへの期待を正しく認識し、実行可能なプロジェクト計画を立案できる。
  • 前提・制約条件の中で、プロジェクトの目標を確実に達成できる。
  • 要員・資源・予算・工程・品質などを管理し、プロジェクトの全体意識を統一して、プロジェクトを運営できる。
  • プロジェクトの進捗状況や将来見込まれるリスクを早期に把握し、適切に対応できる。
  • プロジェクトの計画・実績を適切に分析・評価できる。また、その結果をその後のプロジェクトの運営に活用できるとともに、ほかのプロジェクトの参考に資することができる。
難易度
 プロジェクトマネージャ試験はITストラテジスト試験に続いて難しい試験とされている。理系の試験の中でも難易度が高く合格するのは難しいと言われている。この試験には論文があり、その論文で合格レベルの論文を記述することが非常に難しいので、論文を中心に学習していくようにしよう。
お勧め参考書
参考書の種類
 プロジェクトマネージャ試験(PM試験)の参考書をみてみると、以下の4種類に分かれることがわかる。
 一つは学習用の参考書で、これは試験に必要な知識が記述されている割合の多いいわゆる教科書的な参考書だ。
 もう一つはテクニック用の参考書で、勉強や解答で知っていると役立つテクニックが記述されている割合が多い参考書だ。
 最後は、論文対策に特化した論文事例や論文記述テクニックを多く掲載している論文事例集である。
 このほかにも、試験の過去問とその解説だけに特化した過去問題集というものもある。
 このように様々な参考書があるが、どれを選択すればいいのか、以下で説明していこう。
参考書の選び方
 このように様々な種類の参考書があるが、実際に学習をしてみると、プロジェクトマネージャ試験では専門用語や専門知識について新たに学習する内容は少なく暗記量も少なくて済む。そして多くが応用情報技術者試験で学んだ知識で理解できると考えられる内容だ。
 従って応用情報試験に合格しているのであれば、学習用の参考書は不要でテクニック用の参考書や論文事例集を購入することで対応できるだろう。
お勧め参考書
 では、テクニック用参考書でおすすめの参考書はどれか。プロジェクトマネージャ試験のテクニック用参考書として鉄板なのは、通称「みよちゃん本」と呼ばれる情報処理教科書プロジェクトマネージャだ。
 この本をおすすめする理由はいくつかあるのだが、一番優れている部分はとにかくボリュームが非常に大きいことだ。一部はネットからのPDFダウンロードという形になっているが、非常に多くが掲載されている。
 まずは基本的知識としてこの試験で重要となるキーワードの解説や暗記すべきキーワードが収録されている。簡易的な説明ではあるが冗長でないので気軽に知識を得られるし、わからないキーワードを調べるために辞書的にも利用できる。このため学習用の参考書を購入する必要がない。
 この本はテクニック本なので、午後1や午後2の解答テクニックや学習方法が詳細に記載されている。また勉強スケジュールの立案方法なども記載されているので、効率よく学習することができる。
 そして、この本の最も優秀なところだが、過去15年分の過去問と、その解説がすべて収録されていることだ。午後2の解説では、参考となる論文事例集もすべての問題で掲載されている。もちろん午後2の論文の書き方のテクニックや論文作成方法なども記載されている。このため本書があれば論文事例集を購入する必要がない。
 このように、この一冊あれば、辞書代わりにも利用できるし、テクニックも得られるし、過去問解説集としても利用できるため非常におすすめの一冊だ。プロジェクトマネージャ試験を受験する人は絶対に購入するようにしよう。
勉強方法
お勧めの勉強方法
 基本的には情報処理教科書プロジェクトマネージャの通りに学習を進めればいいだろう。ここではおすすめの勉強方法について記述していく。
 おすすめの勉強方法は「知識を得る→午前2演習→午後1演習→午後2演習」というように順番に過去問を解いていく方法だ。基本的にプロジェクトマネージャ試験(PM試験)は過去問演習での学習になる。ただし実際にプロジェクトマネジメントを仕事としている人もいるだろう。その人はSTEP2から学習していこう。
  • STEP1 基本的な知識の学習
  • STEP2 プロジェクトマネジメントの必勝法の学習
  • STEP3 午前2演習
  • STEP4 午後1演習
  • STEP5 午後2論文演習
STEP1 基本的な知識の学習 午前2対策
 まずは情報処理教科書プロジェクトマネージャの巻末の重要キーワードを読むのがSTEP1だ。これで基本的な知識を再確認しておこう。わからないキーワードがあったらしっかり読んで理解しておくこと。もっと詳しい解説が欲しいなと思ったらネットで検索して調べるのもいいだろう。プロジェクトマネージャ試験は暗記すべき項目は少ないので、苦労することはないと思う。
 ある程度の基本的な知識を得られたと感じたらSTEP2へ進もう。
 すでにプロマネの仕事をしており知識がある人STEP1をスルーしてSTEP2に進もう。
STEP2 プロジェクトマネジメントの必勝法の学習
 情報処理教科書プロジェクトマネージャの「試験直前チェックリスト」を理解し、暗記するのがSTEP2だ。チェックリストにはプロジェクトマネージャ試験の午後問題でよく出題されるキーワード、出来事、考え方などが羅列されており、これを理解すると様々に利用できるので非常に便利だ。
 プロジェクトマネージャ試験では、発生した問題に対して対応すべき「必勝法」みたいなものが存在する。具体的にはこんなものが必勝法となる。
  • 各種ツール → 各種分析手法、統計手法など
  • 顕在化の兆候 → 問題が顕在化する前にあらわれがちな現象
  • 兆候の早期発見方法 → 顕在化した問題を早期発見する方法
  • 事前対策 → 問題発生が予見できるとき、問題が発生しないように事前に仕込んでおく手段
  • 事後対策 → 問題が発生したあとに対応する方法
 これらは午後1問題での頻出ワードになり、さらに午後2の論文にも活用できる。
 例えば、タイムマネジメントの「必勝法」はこんな感じだ。
  • 各種ツール
    • ガントチャート、マイルストーン、アーンドバリューマネジメントシステム、クリティカルパス法など
  • 顕在化の兆候
    • 残業時間、特定要員の負荷、生産性の低下、設計レビューの指摘件数の増加など
  • 兆候の早期発見方法
    • 現場の様子や要員との対話、生産性の実績と予定の差異など
  • 事前対策
    • 経験豊富な要員のサポート、慣れた技術を利用する、進捗確認をマメに実施するなど
  • 事後対策
    • 部分稼働、スペックダウン、要員追加など
 これをPMBOKの各知識エリアに対してを暗記して答えられるようにしておくことが望ましい。暗記すれば「納期遅延の原因はだいたいこんなことが理由かな?」とか、「コスト超過が発生してしまった。どうすればいい?みたいな問題なら、だいたいこんな解答になるのかな?」みたいに想像できる。
 必勝法を知らずに問題を解いてもあまり意味がない。せっかくの過去問題なんだから、最大限に使う方向に使用したほうが効率が良いと思うので、まずは「必勝法」を暗記して、それを利用して問題を解く練習をしたほうが効率がいい。
STEP3 午前2演習
 次に午前2の過去問題を解くのがSTEP3だ。実際に問題を解いていき、これまでの学習結果を確認してみよう。
 午前2は基本的には過去問の丸暗記でもクリアできてしまうが、知識を得るために間違った問題についてはしっかり参考書などを利用して知識を再確認しておこう。間違った問題には、必ず間違った数だけ正の字などでチェックをしておくこと。後から見直すと間違った回数の多い分野が苦手であるとわかるので、その分野については再確認しておくようにしよう。
 過去問を概ね80%以上正答できるようになったら、ほぼ大丈夫と考えられるのでSTEP3に進もう。
STEP3 午後1演習
 次はいよいよ午後1の対策。論文を先に学習するという方法もあると思うが、どちらを先にやるかは都合に合わせ、時間が少ない時は午後1を演習し、時間があるときは論文対策などをしてもいいかもしれない。ただ、午後1の問題文そのものが論文に活用できる「事例集」でもあるので、あくまでお勧めは午後1演習→論文演習というほうをお勧めしたいと思う。
 午後1は過去問を解いて慣れるしかない。上記の知識があれば、ほとんど国語力の問題だと思われるような問題もあるので、解いていこう。
 解いていくと「あ、これは怪しいな?」とか「これは定番の問題だな」とか理解できるようになるので、そうなればしめたもの。このあたりはみよちゃん本に詳しいので、勉強法やテクニックを参考にするといいと思う。
 実際に解くときは、本番のようにやるのが望ましい。ちゃんと問題と解答用紙を印刷し、机に座り、よーいスタートで開始し、本番同様に問題文にマーキングして解答しよう。じゃないと本番で時間が無くなって焦ってしまう。ちゃんと体に時間を叩き込むのも練習の一つ。
 ただ、新試験になってから時間や出題数が変化しているので、その辺は考慮して、なるべく新試験の環境にあわせて練習したほうがいいと思う。1問ずつ解く場合は、新試験が4問中2問選択で90分なので、問題を選択する時間や、最後にチェックする時間も考慮して、30分~35分程度で解答するのが望ましいと思う。そうすれば2問で70分なので、問題選択のためにすべての問題を流し読みする時間や、見直し時間に20分を割り当てることができる。
 午後1の解法と特効薬として、午後1問題の頻出問題を集めた問題集「システム開発現場のプロジェクトマネジメント教科書 -情報処理技術者試験 プロジェクトマネージャ 試験範囲全網羅テキスト」があるので、これを利用するのもお勧め。この本は巻末に午後1の頻出問題例が一覧で記載されている。これも「必勝法」の一部で午後1の勉強には役立つと思う。
 これらの午後1に関する解答テクニックや学習テクニックは後の章で詳しく記述しているので参考にして欲しい。
STEP4 午後2論文演習
 実際に論文を記述するためのストーリーを考えたり、骨子作る練習をしたり、実際に論文を記述して演習するのがSTEP4だ。
 いきなり論文を書くのは恐らく不可能だと思う。論文事例などを読んだりして、自分なりのストーリーを作っていくことから始めることになる。
 具体的には、章立て演習→オリジナルストーリーの作成→骨子作成演習→エディタ論文演習→手書き論文演習という流れで進んでいくとやりやすいだろう。
 論文演習は最初から手書きでやると手が疲れてしまい勉強する気力を失ってしまう。そのため、最後の最後までエディタで演習し、とにかく数をこなしていくようにしよう。そして試験の数週間前から手書きの演習を初めて、手書きになれるような勉強をしたほうが長続きしやすい。
 このあたりについての勉強法の詳細については後の項目で詳しく記述してあるので読んでみてほしい。
プロジェクトマネージャ試験の勉強法まとめ 午後1対策
勉強テクニック 午後1
チェックリストの暗記方法
 まずは、プロマネとしての必勝パターンを暗記することが合格のコツと書いたが、その暗記方法について。覚えられればどんな暗記法でもいいが、こんな方法もあるので検討してみてほしい。
 例えば進捗遅れの事後対策の場合。
  • 進捗遅れの事後対策(7種類)
    • 本番稼働開始時期の見直し
    • 部分稼働
    • スペックダウン
    • スケジュールの見直し
    • 追加要員の投入
    • 進捗確認の強化
    • 作業環境改善
 これを暗記するわけだけど、これを丸暗記するのは大変だ。そのために問題用紙を自分で作成すると覚えやすい。
 例えば、以下のように問題を作る。
  • 進捗遅れの事後対策(7種類)
  • 進捗管理の主要ツール(3種類)
  • 進捗管理指標(8種類)
 これをみて上から順番に種類の数だけ解答をつぶやけるかチェックするというものだ。こうするとヒントがあるので比較的に観点に覚えられるので試してみてほしい。
時間を計測する
 午後1問題演習時には必ず時間を計測して演習することにしよう。このとき問題を選択するところから初めて、実際に解答し終わるまで90分以内で行うことが望ましい。こうすることで体に試験時間の感覚を覚えさせることができる。
 しかし時間のない人もいると思うので、そういう人は90分で2問出題のケースならば、1問35分を目安に解答できるようにしておこう。90分で3問のケースでは1問25分を目安に解答するようにしよう。
問題は印刷する
 問題や解答用紙はできるかぎり印刷して解答するようにしよう。試験中には問題文を行き来して確認するためPDF上だとみにくいし解答に時間がかかってしまう。これでは時間を計測して演習する意味がなくなってしまう。また問題用紙に実際に書き込みができないので、印刷することをおすすめしたい。
 解答用紙も印刷しておくと、実際の解答文字数をマス目に当てはめて検討できるし、まれにわかりにくい設問があって、解答用紙をみて初めて解答方法がわかったりする場合もあるので、問題と解答は必ず印刷して解答しよう。
間違った問題の復習方法
 間違ってしまったケースは、以下の3つのケースが考えられる。
  • 間違ってしまった3パターンのケース
    • 知識がなかった
    • 問題文のヒントに気がつけなかった
    • 問題文のヒントを間違った
 「知識が無い」というのは穴埋め問題のように直接的に知識を問われていたのだが、その知識がなく答えられなかったケースだ。これは覚えていなかったので仕方が無い。もう一度それらの技術などについて再確認するようにしておこう。
 「ヒントに気がつけなかった」というのは問題文にヒントがあるのだが、なぜかそれに気がつけなかったパターンだ。主に流し読みしてしまった場合に起こりやすい。そのヒントの部分にアンダーラインを引いて、なぜ自分はそのヒントに気がつけなかったのか再確認をしておこう。
 「ヒントを間違った」というのは、ヒントには気がついていたが、間違って違うヒントを選択してしまったパターンだ。様々な条件から正解となるヒントを選択するのだが、その条件を総合的に判断できず誤ったヒントを選択してしまうことが多い。そのため、正解の手がかりとなる問題文のヒントと、自分が正解だと思った問題文のヒントの両方にアンダーラインを引いて、なぜ自分が間違ったヒントを選択してしまったのかを考えるようにしよう。
 午後1の解答のポイントは、自分がプロマネになったと過程し、問題文に記述されているプロジェクトの優先的に考えなければならないことは何で、何が問題で、それを修正するために何をすべきで、そして解決方法としてどのようなことが考えられるのか、まるでアドバイザーにでもなった気分で問題を読み、質問に対して答えていくようなイメージで解いていくといいと思う。
解答テクニック 午後1
問題文へのマーキングの方法
 みよちゃん本では、プロジェクトにとってプラスの文章にはアンダーラインを引いた上で欄外に○+(○の中に+のマーク)、マイナスの文章には○-、プロジェクトマネージャには○PMマークなどをつけるように推奨されていたけど、自分はそれをもう一歩進めたマーキングをお勧めしたいと思う。
 具体的なマーキングはこんな感じ。
  • 主人公となるプロジェクトマネージャの名前にアンダーラインをひいて○PM(○の中にPMの文字)のマーク
  • 前提条件となる文章に○前のマーク
  • 怪しい文章に○怪のマーク
  • 意味がよくわからない文章に○?のマーク
  • プロジェクトにとって明らかにプラスとなる文章に○+のマーク
  • プロジェクトにとって明らかにマイナスとなる文章に○-のマーク
 さらに、マークは以下の方針に従ってマーキングする。
  • プロジェクトにマイナスとなる文章には、右側の欄外に記述する 例:○-マーク
  • プロジェクトにプラスとなる文章には、左側の欄外に記述する 例:○+マーク
 どういうところにマーキングすればいいかは、午後1の問題を解いてみるとなんとなくわかってくる。で、怪しいと思ったらマーキングをする。具体的にはこんな感じ。
  • 主人公となるプロジェクトマネージャの名前にアンダーラインをひいて○PM(○の中にPMの文字)のマーク
    • これはプロジェクトマネージャは○○氏みたいにかいてあるから確実にマークする→文章の左側欄外
  • 前提条件となる文章に○前のマーク
    • 納期、コスト、仕様に関する前提条件。例えば顧客の都合で納期は絶対とか、レスポンス時間は1秒以内とかの前提条件→文章の右側欄外
  • 怪しい文章に○怪のマーク
    • 顧客企業の上位管理者が顔見知りでよろしくと言っているとか、担当者が繁忙とか、先に開発環境を構築とかいかにもなところ→文章の左側欄外
  • 意味がよくわからない文章に○?のマーク
    • ユーザからの指摘を受けていきなり変更してしまったとか、通常だったらあり得ない対応をしているところ→文章の右側欄外
  • プロジェクトにとって明らかにプラスとなる文章に○+のマーク
    • 経験豊富な要員を配置したとか、事情がかわったら再見積できる契約とかプロジェクトにとってプラスのところ→文章の左側欄外
  • プロジェクトにとって明らかにマイナスとなる文章に○-のマーク
    • 経験の少ない要員とか、新しい技術を採用したとかマイナスになる部分→文章の右側欄外
 という感じでマーキングをする。
 で、もしプロジェクトにとってプラスになる理由を探している場合には、左欄外のマークを探せばいい。マイナスになる理由を探している場合は右欄外のマークを探せばいい。これが右側と左側に別々に○マークをする理由。あまりにたくさんマーキングすると紛らわしいけど、プロジェクトにプラスになるアンダーラインへのマーキングへは左側、マイナスになるマーキングは右側にすることによって探しやすくなる。
設問へもマーキングしよう
 忘れがちなのが設問へのマーキング。
 問題文も大事だけど設問も大事。設問に記述されている条件は問答無用に適用され、問題文からの選択範囲を大幅に削減できるからだ。
 例えば問題文に、「▼▼という施策を実施したとき、○○において、どんな問題が発生すると想像されるか」とあったとする。このとき▼▼という施策の実施で様々な問題が発生するけども、特に「○○において」はどんなことがあるか?と聞いていることになる。
 これは「▼▼を実施すると複数の問題が発生することが考えられるけど、その中で○○に限定したら答えは限られますよ?」ということを意味している事が多い。この「○○において」を見落としてしまうと解答を絞りきれなくなって誤答してしまうことになる。
 従って問題文にも積極にマーキングして見落としがないようにしておこう。

プロジェクトマネージャ試験の勉強法まとめ 午後2対策
勉強テクニック 午後2
解答知識エリアの絞り込み
 仕事の合間に学習することを考えると、すべての知識エリアで論文を用意するのは難しいと思う。なので過去問の出題傾向と自分の好みに合わせてエリアを決めて学習するのが望ましい(出題傾向はみよちゃん本に記載あり)。
 お勧めの知識エリアは、タイム、コスト、品質、人的資源の4つ。ここから非常に多く出題されている。次に重要なのはリスクと統合マネジメントだ。しかし、リスクマネジメントは、どんなリスクか明示されていなければタイムでもコストでもいいので前者の4つの知識エリアを流用できるので学習しなくてもいい。統合マネジメント(主に変更管理)は、それぞれの知識エリアで論文を記述する際にも関わってくる内容なのでこれも自然に学習ができる項目だと思う。
 というわけで、特に自分の好みがないりであれば、この6つ(正確にはタイム、コスト、品質、人的資源の4つに注力しつつリスクと統合マネジメントを意識しながら学習する)に的を絞って勉強しよう。
事前にプロジェクトを3つ用意しよう
 論文を記述するのに想定するプロジェクトは、問題に対して矛盾なく適用するために3つぐらい用意しておくのが望ましい。
 例えば、「1次開発と2次開発をわけて」とか「納期が間に合わなそうだから部分稼働を選択する」というような回答を求められる問題だと、組み込み系の製品開発プロジェクトのストーリーは適用するのが難しい。24時間の可用性が求められるという論文を記述したい場合は24時間だれかがアクセスする可能性のあるWeb系などがわかりやすいし、夜間のバッチジョブを想定した論文なら、クラサバ型の業務システムという感じで考えたほうが話が通りやすい。
 ちなみに、自分が用意したプロジェクトはこんな感じ。
  • Webアプリを利用した業務システムの構築
  • Webアプリを利用した会員向け購買サイトの構築
  • クライアント-サーバ型のWindowsアプリケーションを利用した業務システムの構築
 プロジェクトの規模は固定させたほうが矛盾ない論文が書きやすいようだ。例えば開発期間:○○ヶ月、開発工数:○○人月、ピーク時の要員:○○人、チーム数:○○チーム体制、予算:○○万円という具合に固定し、チーム編成は自分がプロジェクトマネージャでチーム数は2ぐらいがわかりやすいと思う。予算、期間、工数、要員数が想像できないようであれば、そこを知ることから学習しよう。
エディタの利用
 論文問題に必要な技術は、問題の解答力(構成力)と、手書き能力だ。しかし解答力と手書き能力は一致しない。最初から手書きで練習し疲れてしまうと飽きて面倒になってしまう。だから、ある程度できるようになるまで、エディタを使って構成力を養うほうがいい。それで慣れたら手書きで記述して長文を時間無いで書く練習をするのが効率がいいだろう。
 使用するのはワープロでもエディタでもいいが、論文では文字数を気にする必要があるので、等倍フォントが利用でき行数が表示されるエディタがいいと思う。
 例えば秀丸エディタのようなものがお勧め。1行を25文字で記述すれば、4行で100文字。8行で200文字というように計算がしやすい。
勉強の流れ
 いきなり骨子やストーリーを作るのは苦労すると思うので、まずは過去問に対して「章立て」と「設問からの抽出」を作成してみよう。問題文に沿った章立てと問題文からの抽出を作るのが最初は少し難しいが慣れると簡単にできるようになる。これらができるようになったら骨子を作成し、次に実際に論文を記述するという流れになる。
  • 論文の勉強の流れ
    • SETP1 章立て
      • 設問から抜き出して章立てを作る演習
    • SETP2 問題文からの抽出
      • 作成した章に対して、それぞれ記述するべきことを問題文から抽出する
    • SETP3 骨子作成とプロジェクトの事前準備
      • 記述する論文の骨子を入れていく
    • SETP4 エディタでの論文の記述
      • エディタで実際に論文を記述する
    • SETP5 手書きでの論文の記述
      • 手書きで実際に論文を記述する
STEP1 章立て
 設問の文章から章立てをする練習を行うのがSTEP1。これは簡単なので何回かやれば簡単に章を作ることができるだろう。このあたりはエディタで短時間で済ませてしまおう。
 できるようになったらSTEP2へ進もう。
 このあたりの詳細な章立ての方法は後の解答テクニックに記述されているので参考にして欲しい。
STEP2 問題文からの抽出
 作成した章に対し、どのような記述をすればいいか、問題文から抜き出して記述していくのがSTEP2の問題文からの抽出だ。このあたりもエディタで簡単にできるようになる。
 このときに自分だったらどのような話にするか考えながら行うと、骨子が作りやすくなる。
 問題文からの抽出ができるようになったらSTEP3に進む。
 このあたりの詳細な設問からの抽出方法は後の解答テクニックに記述されているので参考にして欲しい。
STEP3 骨子作成とプロジェクトの事前準備
 ここでは作成した章立てと設問からの抽出に対して、記述する論文の骨子を作成していくのと、それと平行してプロジェクトの事前準備やストーリーを作成していくのがSTEP3だ。
 ここでは作成した章に対して、自分が記述する論文の骨子を入れていく。そのためにはプロジェクトをあらかじめ準備しておかないといけないし、おおまかな開発ストーリーも用意しておかなければ、実際に骨子を作ることができないので、骨子を作るのと平行してプロジェクトの事前準備の作業を行う。
 ここもエディタで骨子を作るようにすることで数をこなすことを優先しよう。
 過去の問題に対して簡単に骨子が作れるようになったらSTEP4に進もう。
 このあたりの詳細な骨子作成の方法は後の解答テクニックに記述されているので参考にして欲しい。
STEP4 エディタでの論文の記述
 いよいよ実際に論文を記述するのがSTEP4だ。
 こちらもエディタで、STEP3で作成した骨子を実際の文章に置き換えていくように記述していく。エディタを利用して記述する本数を優先していこう。
 試験の1週間前まではエディタでの演習で十分だ。最低でも5年分ぐらいの論文は記述しておきたい。
STEP5 手書きでの論文の記述
 いよいよ手書きで記述する練習をするのがSTEP5だ。最初は疲れるが、次第に慣れてくるので、試験前の1週間前ぐらいから、1日1本、実際に記述していこう。試験前日は手を休めるようにすること。
想定するプロジェクトの用意
 前述した事前に準備するプロジェクト、ストーリーは骨子の作成段階で用意していくのがいいだろう。
 実際には章立てと設問からの抽出をしながら、自分だったらこういう物語にするなと考えながら演習していくと、自分なりのストーリーが思いつきやすくなる。最終的にSTEP3の実際に論文を記述する前に、少しずつストーリーをブラッシュアップしていき完成させよう。
骨子作成中に手が止まったら
 骨子を作ろうとすると、プロジェクトマネジメントにおける知識において「こういう場合はどうなるんだっけ?」とか「もっと具体的な知識がないと解答できない」という部分が結構でてくるので、そうなったらネット等で知識を調べ、実例を参考にしながら骨子を積み上げていくといいと思う。
 例えば、よくあるパターンが品質に関する問題。ソフトウェアの品質を問う問題で「ソフトウェアの品質を保つには品質を作り込むためのプロセスと品質を確認するためのプロセスが重要である。品質を保つために、あなたはどのようなプロセスを組み込みましたか?」みたいなことが、さらっと書いてある。ここで重要となるのが「品質を作り込むためのプロセス」「品質を確認するプロセス」って何?ってこと。これは参考書等には記述されていないので、自分で学習するしかない。疑問に思った点がでてきたら、その都度調べて学習していこう。
 ちなみに「品質を確認するプロセス」は、機能性や使用性についてならレビュー、信頼性や効率性ならテストの実施などが該当する。
 それが理解できると、次に「じゃあレビューはどうやる?」「テストはどうやるの?」というように具体的なレビュー法、テスト法が知りたくなると思う。それらは応用情報等でも勉強するように、ウォークスルーとか、ラウンドロビンとか、インスペクションとか、ブレーンストーミングとか、ブラックボックステストとか、そんな知識と結びついていく。
  • 論文問題の学習の流れ
    • 「ソフトウェアの品質を保つには品質を作り込むためのプロセスと品質を確認するためのプロセスが重要である。あなたが関わったプロジェクトにおいて品質を保つためにどのような試作を取り入れましたか?」みたいな設問がある
    • 私は品質を保つために品質を作り込むプロセスを、こうこうこういうように工夫したみたいな話にしたい
    • 私は品質を保つために品質を確認するプロセスを、こうこうこういうように工夫したみたいな話にしたい
    • じゃあ、品質を作り込むプロセスと確認するプロセスの具体例を知らないと解答できないな・・・
    • 品質を保つソフトウェアの開発手法や確認する手法について学習しよう・・・
 このように論文の骨子を作ろうとするごとに「あ、この知識がないと書けないな」ということがわかってくるので、その部分をネットや参考書を利用して探す。これが重要。これが結構大変なのだが、過去問で一通り勉強すると新傾向の設問でない限り、ほとんど応用できるので合格率を確かなものにするためにはいいと思う。
骨子を用意して自分の黄金パターンを見つけるのが重要
 論文の骨子を考えていくと、自分の用意したプロジェクトパターンに合う骨子が貯まっていくと思う。
 骨子を作成していると自分の得意な黄金パターンがあることがわかってくると思う。そのパターンが理解できるようになると、論文の解答が楽になる。
 骨子を作るのは難しく、「明らかに自分たちに落ち度がある失敗で問題が発生した」という内容は自分たちのミスで発生したことなので骨子として採用しにくい。逆に、相手の都合により問題が発生したことにしたとしても、そのリスクをあらかじめ考慮してなかったの?という話になってしまい、これも骨子として採用するのはためらわれる。
 そうなると「予見することが不可能だが、しかし問題が発生してしまった」「事前にリスクを想定し事前対策を検討したけど実際に顕在化してしまった」という話にならざるを得ないと思う。骨子を作っていくと、たまたま失敗してしまったパターンみたいなものが見えてくるので、そういうパターンを見つけていくのが重要だ。
 例えばよくあるパターンだと思われるのがこのようなリスクだ。
  • ユーザ企業のキーマンが多忙、理解力不足で要件定義が進まない
    • 対処法:専任の担当者を任命することを要求したり、設計レビューにユーザ企業の人間を参加させたりとか
    • 用意するべきプロジェクト:理解力不足とかの設定ならWebアプリ形式に決定したがWebアプリについて詳しくないとかの設定に
  • ユーザ企業の経営方針変更で仕様変更が発生した
    • 対処法:上位管理者に相談したりとか、部分稼働するとか、別途予算を要求するとか
    • 用意するべきプロジェクト:部分稼働とかだとオープンを告知してしまったWebサイトの設定とか
  • 協力企業の要員の能力不足
    • 対処法:要員交代等
    • 用意するべきプロジェクト:基本的には何でもよさげだけど、クラサバ型のシステムが無難?
 このようなストーリーであれば骨子として比較的採用しやすいだろう。
原稿用紙を用意する
 手書きで練習する際には実際に原稿用紙を用意して記述するようにしよう。レポート用紙などに手書きで記述していると、どうしても文字サイズが異なるので本番時に違和感を感じてしまうからだ。
 本番の解答用紙は手に入れることができないが、サイズはA4でそこに400字を記述するような解答用紙なので、市販のA4サイズの400字詰め原稿用紙を購入して実際にそれで手書き練習をするのがおすすめ。実際にマス目の大きさにも違和感なかったし、本番に近い環境で練習できるのはきっとメリットがあると思う。
書けなかった漢字はメモる
 PCに慣れていると、手書きで漢字がなかなか書けなくなってしまっていることに気がつくと思う。
 論文の演習中にPCを使って文字を調べるのは良いとしても、それだけだとまた忘れて書けなくなる事が多い。なので、書けなかった漢字は、どこかにまとめてメモしておいたほうがいいと思う。で、あとから見直して漢字を勉強する。まったく書けなくなっているのなら、本格的に勉強する必要があるけれども、ちょっとど忘れしている程度ならば、あとから見直せば思い出せるはずなので、メモしておいて、本格的な学習に利用したり、試験前日に見直して記憶を呼び覚ましておくようにしたほうがいいと思う。
解答テクニック 午後2
論文の書き方
章立て
 論文は最初に問題を読んで、それから設問を理解して解答しようとすると、解答する内容がブレてしまうことが多い。そこで、最初は問題を読まず、どんな解答を求められているか設問から章立てをすることがぶれない解答をする近道だ。
 例えば、平成19年の問1だとこんなかんじ。問題文を読まずに設問だけで章立てするとこんな感じになる。過去問はIPAのサイトからダウンロードできる。
1 私が携わったプロジェクトについて
1.1 私が携わったプロジェクトの概要
1.2 関係者との交渉が必要になった問題と背景
2 問題解決の手順と合意に至った解決策について
2.1 問題を解決するための手順
2.2 交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
3 施策の評価と今後の改善について
3.1 手順と解決策についての評価
3.2 今後どのように改善したいと考えているか
 これが求められている内容をすべて網羅した章立て=論文の流れとなる。場合によっては問題文を読むことで多少は変化してくることもあるが、90%ぐらいはこのままの構成が利用できる。こうすることで問われている内容から大きく乖離することなく解答できるし論文を構成することができる。
問題文からの抽出
 章立てをすることでどのような論文の流れになるか道筋が見えたと思う。次は具体的に何を記述すればいいかをまとめる必要がある。
 みよちゃん本にも書かれているように、このような午後2では「あなたはプロジェクトマネージャですよね?なら、実際にこういう経験していますよね?そういうときこんなことをしていますよね?そのときどう考えてどう行動したんですか?」のように聞かれている。これらの具体例は、実は問題文の中に記述されている。なので、それを問題文からピックアップして構成した章立ての中に記述していく。
 具体的にはこのような感じだ。同じく平成19年の問1。
1 私が携わったプロジェクトについて
1.1 私が携わったプロジェクトの概要
1.2 関係者との交渉が必要になった問題と背景
 ※利用部門や協力会社に関わるような関係者との問題が発生
 ※開発範囲の認識が異なる、リスク顕在化で納期遅延が発生
2 問題解決の手順と合意に至った解決策について
2.1 問題を解決するための手順
 ※関係者と状況の認識を合わせる
 ※問題の本質を理解して、選択肢を複数立案して、優先順位を付け、最善方法をみつける
2.2 交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
 ※相手との要望が異なり、互いに妥協する過程
3 施策の評価と今後の改善について
3.1 手順と解決策についての評価
 ※もちろん顧客が満足で終了
3.2 今後どのように改善したいと考えているか
 ※さらにこうすればよかったという記述
 このように問題文から抜粋して各章に割り振ることで、具体的にどんなことを記述すればいいのかが見えてくるので、あとはこの具体例に合わせて骨子を作るだけだ。
骨子の作成
 次に作成した章立てに従ってストーリーを考える。最初からいきなりかくと後から整合性がとれなくなることがあるので、骨子を考えてから書き始めるのがお勧めだ。具体的には、問題選択に5分、章立てや骨子の作成に15分、残りの90分で書き上げて、残りの10分をチェックに使用する感じがベストだと思う。90分で書き上げるのは手書き能力で、15分で骨子を作るのは構成力だ。。
 では、実際にどんな感じでストーリーを作るのか。具体的にはこのような感じで作成していく。同じく平成19年の問1。ここまでくると問題文をみなくても章立てを見るだけで論文が作れる。実際の試験では、これを記述すると時間がかかるので、問題文にアンダーラインを引いたり、章番号を書いたりすることで対応しよう。
1 私が携わったプロジェクトについて
1.1 私が携わったプロジェクトの概要
 ▼基幹業務システムの開発 保守契約切れに併せて再構築のため遅延許されない
1.2 関係者との交渉が必要になった問題と背景
 ※利用部門や協力会社に関わるような関係者との問題が発生
 ※開発範囲の認識が異なる、リスク顕在化で納期遅延が発生
 ▼ユーザ企業から口頭で伝えたという仕様変更の要求がありリスク顕在化
2 問題解決の手順と合意に至った解決策について
2.1 問題を解決するための手順
 ※関係者と状況の認識を合わせる
 ▼伝えていたつもりが、自社では把握せず、どちらの責任にもならないという結論に
 ▼変更しないと業務に使えないが、それを変更すると時間がないという認識は一致
 ※問題の本質を理解して、選択肢を複数立案して、優先順位を付け、最善方法をみつける
 ▼複数立案したが、弊社としては納期を遅延してもらうしかないという結論
2.2 交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
 ※相手との要望が異なり、互いに妥協する過程
 ▼顧客はとりあえず納期だけはなんとかして欲しいという要求
 ▼幸い、仕様変更部分は月集計に関する部分なので、最初の1ヶ月では必要の無い機能。部分稼働はどうか?
 ▼顧客も同意し、まずは日次機能を稼働させ1ヶ月以内に月集計機能を実装で合意
3 施策の評価と今後の改善について
3.1 手順と解決策についての評価
 ※もちろん顧客が満足で終了
 ▼無事うまくいきますた
3.2 今後どのように改善したいと考えているか
 ※さらにこうすればよかったという記述
 ▼そもそも口頭うんぬんが問題なのでそれを解決できればよかった
論文の流れの必勝パターン
 プロジェクトマネージャ試験の論文を読んでいくと「だいたいこんな流れの解答を期待しているんだろうな?」というのがわかってくる。そのあたりが理解できるとしめたもので、難なく解答ができるようになると思う。
 それが、この論文のおおまかな流れの必勝パターンだ。具体的には、こんな感じの流れになっている。
  • あるプロジェクトがある
  • そのプロジェクトのはある特徴がある
  • その特徴のためプロジェクトにはリスクが内包している
  • リスクが顕在化しないように事前対策を複数検討し選択する
  • でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった
  • さらに対策を検討する
  • でもリスクが顕在化してしまった
  • そのために事後対策を複数考えて選択する
  • リスク回避できたが予定と違うことをしたので、別リスク発生の可能性
  • その予防策も考える
  • うまく収まってめでたしめでたし。でもこうすればもっとよかったかも
 骨子を作ったら、そこから話を膨らませていくわけだが、基本的にはその骨子の結論やストーリーの道筋をたどるために、字数や設問に合わせて、上記の黄金パターンからいくつかを選択して解答するようにする。こうすると、簡単に肉付けができるし、PMとして考えた理由も記述することができる。
 しかし、論文中では、これらすべての解答が求められているとは限らない。例えば、「絶対に納期が許されない状況。なぜか納期遅延の可能性がでてきた。どうしましたか?」みたいな論文を求められているとする。この場合では事前対策や兆候の発見までは問われていない。いきなり納期遅延リスクの顕在化であり、その顕在化したリスクに対する対応策だけを回答として求められている。すると、こういうパターンを選択することになる。
  • ○あるプロジェクトがある ←これは設問アとして絶対に存在する
  • ○そのプロジェクトのはある特徴がある ←これは設問アとして絶対に存在する
  • ×その特徴のためプロジェクトにはリスクが内包している ←いきなりリスク顕在化なので問われず
  • ×リスクが顕在化しないように事前対策を複数検討し選択する ←いきなりリスク顕在化なので問われず
  • ×でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった ←いきなりリスク顕在化なので問われず
  • ×さらに事前対策を検討する ←いきなりリスク顕在化なので問われず
  • ○でもリスクが顕在化してしまった  ←問われている内容
  • ○そのために事後対策を複数考えて検討する  ←問われている内容
  • ▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性 ←あるとなお良い
  • ▲その予防策も考える ←あるとなお良い
  • ○うまく収まってめでたしめでたし。でもこうすればもっとよかったかも ←これは設問ウとして問われる可能性アリ
 ○は必須に解答すべきこと。最初の二つの○は問アに該当する部分。
 ▲は記述するとなお良いけど、場合によっては字数がたりなくなるので必要に応じて追加する部分。
 ×は合否に関係しないからスルーする部分。
 このようにパターンを選択したら、選択したパターンに対して論文に記述する骨子を埋め込んでいく。すると、このような感じになる。
  • ○そのプロジェクトのはある特徴がある
    • Webアプリを利用した基幹システム。かつ納期遅延が許されない
  • ○リスクが顕在化してしまった
    • Webアプリに詳しくなく操作性に関する要件定義が進まなくなって遅延しそう
  • ○そのために事後対策を複数考える
    • 案1 要件定義を円滑に進ませるために要件定義の責任者の設置を顧客に求める
    • 案2 プロトタイプ手法を採用
  • ○プロジェクトの特徴を考慮して、その複数の案から最善案を選択する
    • ユーザにとってもっともわかりやすいと思われるからプロトタイプを選択
  • ▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性
    • プロトタイプ手法の採用でかえって作り込みが増え遅れないか?
  • ▲その予防策も考える
    • あくまで操作性に限定したプロトタイプにするよう両社で合意
  • ○うまく収まってめでたしめでたし
 このような必勝パターンの考え方に従って、問題発生の理由、プロジェクトの特徴、その解決法をうまく組み合わせると、旨い具合に論文が肉付けできると思う。
章中の流れの必勝パターン
 もう一つのパターンが一つの章の中で記述すべきパターン。
 みよちゃん本でも記述されているようにシステムアーキテクトの論文でなく、プロジェクトマネージャの論文なので、マネジメントする立場になって論文を記述していかなければならない。そのためには、以下のようなパターンを多様するとマネジメントっぽい感じになる。
 具体的にはこんな感じ。
  • ある問題が発生した(発生しそう)
  • 原因を調査した
  • その原因に対する対策として○○を実施させた
  • なぜなら○○が○○だから○○だと考えたからである
 たったこれだけだ。具体的な論文では、このような感じになる。
  • ある問題が発生した(発生しそう)
    • 納期遅延が発生しそう
  • 原因を調査した
    • 調子したところ今回の開発で使用するテクノロジでの開発経験の無い要員が多かった
  • その問題に対する対策として○○を実施させた
    • そこで経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら○○が○○だから○○だと考えたからである
    • なぜなら勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
 こうすると、かなりプロマネっぽい論文になるがどうだろうか?
 例えばこんな感じでは後者のほうがやはりよく見える。
  • 納期遅延のリスクが顕在化しそうだった
  • そこで経験者に新人の教育を実施させた
  • その後進捗が挽回しはじめ最終的に納期が守られた
  • 納期遅延が発生しそう
  • 調査したところ今回の開発で使用するテクノロジでの開発経験の無い要員が多かった
  • そこで経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
知識を散りばめる
 これで体裁は整ったが、さらに知識をちりばめてアピールすると、より合格論文に近くなる。
 具体的には、実施した施策の根拠となるツール、理論、必勝法などを記述する。そうすると、前章の例もグッと厚みが増してくる感じにみえるのが不思議だ。
 実際に記述するとこのような感じになる。
  • 納期遅延が発生しそう
  • 各チームリーダや現場の人間から本音を聞き出すため個別にミーティングを実施し、特性要因図を利用して原因を分析した
  • その結果、今回の開発で使用するテクノロジでの開発経験の無い要員が多かったことが主な原因であることがわかった
  • これらの対処には要員交代したり、開発要員を同室で作業させるなどの改善なども考えられる
  • しかし、今回は経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら、ただちに経験豊富な要員を集められることは現実的でないからである
  • そして勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
  • また過去の類似プロジェクトの結果から要員教育の効果で成功した例が多くこの例が参考になると考えたからだ
 このような感じでどんどん加筆して知識をいれていく。すると、よりしっかりした論文に見えてくる。
 特に分析手法やツールはいろんな場面でちりばめる知識として利用できる。そのため、それらを暗記しておくことが重要になる。そしてここで「必勝パターン」がでてくることになるのだが、やはり「必勝パターン」の暗記は重要だと思う。
 論文中に使える必勝パターンは例えばこのようなものだ。
  • 発生確率・影響度マトリクス
  • インスペクション、ウォークスルー、ラウンドロビン
  • デルファイ法、過去の類似案件からの類推
  • 特性要因図、パレート図
  • ミーティング、個別面接
定量的な解答をする
 知識をちりばめるのと同様に、所々に定量的な表現を入れることも大事だと。数字が入ると説得力が増すからだ。だけど、実際の論文との内容で矛盾が生じるかもしれないので結構難しいところだと思う。
 例えば定量的な表現をいれるとこんな感じになる。
  • 納期遅延が管理上限の進捗10%以上の差違が発生しそう
  • 各チームリーダや現場の人間から本音を聞き出すため個別にミーティングを実施し、特性要因図を利用して原因を分析した
  • その結果、今回の開発で使用するテクノロジでの開発経験の無い要員が多かったことが主な原因であることがわかった
  • これらの対処には要員交代したり、開発要員を同室で作業させるなどの改善なども考えられる
  • しかし、今回は経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら、ただちに経験豊富な要員を集められることは現実的でないからである
  • そして勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
  • また過去の類似プロジェクトの結果から要員教育の効果で成功した例が多くこの例が参考になると考えたからだ
  • 実際に過去の例では勉強会の実施で一時的に5%の進捗率低下となるが、その後持ち直し、対策をしない場合より10%の納期短縮されていた
 この例は割合で記述しているが、具体的な工数や金額で答えられれば、そのほうが良い。
 以下のような言葉が、定量的な言葉として使いやすい。
  • 進捗率、工数、ステップ数
  • レビューの指摘件数、指摘密度
  • テスト数、密度、網羅率
  • 不具合の発見件数、発見密度
  • レスポンス時間、バッチの処理時間、システム停止時間、要望された機能の実装率
検討した結果を複数用意する
 これはすでに今までの中の話で取り上げているので短く説明する。
 問題発生時の対策には一般的には複数が考えられる。しかし、そのうち対策として実施するのは一つか二つのことが多いと思う。それは他に考慮すべき事柄があって、採用できない対策であることが多いからだ。
 もし字数や時間に余裕があれば、「一般的な対策は対策A、対策B、対策Cと複数の対策ある。しかし、このプロジェクトにはこのようなプロジェクト特有な特徴があるので対策Aを採用することになった」という記述にすることで、より説得力が増す論文になる。
 しかし、このような記述するためには、最初の設問アでプロジェクトの特徴としてしっかりと特有の特徴が記述されていないと説得力を失ってしまうので、そのあたりも考えて骨子を作成する練習をする必要があるだろう。
 なぜリスクが顕在化してしまい、そしてなぜ複数ある対策の中から特定の対策を選択したのか、すべてはプロジェクトに特徴があるからそういう論述になるわけで、実は設問アというのは、論文を作成する上でかなり重要だ。
変更したことに対して発生するリスクを考慮する
 これもすでに述べているのに簡単に解説する。
 顕在化しそうな問題や、発生してしまった問題に対して事後対策を行って問題を解決しようとするわけだが、そもそも「事後対策」は本来は行う予定でない対策で、本来の予定を変更して特別に実施していることになる。このように本来とは違うことを実施しているわけだ。従って、それを実施することで新たなリスクを抱えてしまう可能性が考えられる。
 そのため論文では追加して実施した施策に対し、その施策が悪影響を及ぼさないよう別の対策を考えておく必要がある。その施策を実施することで抱えるリスクに対する事前対策を論文に盛り込むことで、より説得力のある論文になるし、字数を多く記述できない人にとっては、絶好の文字数稼ぎになる。
解答用紙や文房具の評価
解答用紙への工夫
 実際の試験では、解答用紙として週刊誌や青年漫画誌のように紙が二つ折りにされ、真ん中がホチキスで留められている冊子が配られる。ちょうど、IPAの各試験の午前、午後の問題冊子のような形状である。その1ページに400字詰め原稿用紙のマス目が印字されている。つまり1ページの裏表に両方記述をすることになる。紙質は厚手の原稿用紙のような感じで、多少、つるつるした感じである。
 ここで二つの問題が発生する。
 一つは裏移りの問題である。1ページの裏表に記述するので、表を書いた後に裏を記述すると表に書いた時が裏移りしてしまうのである。下敷きが使えればいいのだけど、持ち込んでいい筆記用具に下敷きは含まれていないため利用できない。なので特に筆圧の強い人、濃い鉛筆を使うと汚くなってしまい、採点者の印象も悪くなりかねないという懸念がある。
 二つ目の問題は書き心地が変化してしまうことである。説明が難しいけど、週刊誌の表紙に文字を書こうとすると、机と表紙の間に何枚も紙があるので、当然、書き心地は柔らかい。ところが、裏表紙に文字を書こうとすると、今度は机と裏表紙の間には紙が一枚もなく、机と直接接しているので、書き心地が堅くなる。前述の通り解答用紙も週刊誌のように二つ折りにされているので、1ページずつ記述をしていくと、書いてる紙と机の間の紙の枚数が変化してしまう。この変化が以外と苦痛で、このおかげで手が痛くなったりする。そこで、完全に解答冊子を折り返してしまい、机と記述している紙の間の枚数を一定にさせるようにすると変化が無くていいと思う。よく、満員電車で新聞の読みたい面を折り返して読んでいる人が居るけど、あの要領。単語帳やスケッチブックのようにくるっと裏側に一周させるイメージ。
 ところで関係ないが、会場によっては、かなり机の状態が酷いこともあるようだ。特に古いテーブルで木目がデコボコしているようなところもあるらしい。そういうところはボール紙が配布され、それを下敷きがわりに使うように指示されるらしい。このような可能性も考えて、シャープペンの芯などは異なる硬さのものを用意するとかするといいかもしれない。
紙質
 紙質は、午後1はマークシート用紙のような、わりと色が乗りやすいタイプの紙で応用情報の午後と同じような感じ。午後2はどちらかというと若干つるつるして色が乗りにくい感じだった。
 そのため、手の疲れ防止のため2Bを午後1で使うと非常に書きにくく文字が汚くなる傾向があるように感じた。しかし午後2は若干つるつるしているので、2Bでも十分に記述が可能だった。なので、手の疲れが激しい人は午後1をHB、午後2をBか2B(受験票にはHBかBを指定)などと使い分けたほうがいいと思う。
文房具
 自分はパイロットの「ドクターグリップ Gスペック」と三菱鉛筆の「ユニ アルファゲル クルトガエンジン搭載タイプ」を利用してみた。
 ドクターグリップはとても重心のバランスが良く書きやすい印象があった。ユニアルファゲルのクルトガ搭載タイプも同様、書き心地は問題ないのだが、つかれにくさではドクターグリップのほうが上に感じた。
 しかし、実際に利用してみると、特に2Bの芯では、すぐに芯が減るので、どんどん文字が太くなってしまう。その場合にはクルトガ搭載タイプのユニアルファのほうが、常に芯のとがった部分を利用できるので、書き心地が維持され非常に書きやすかった。ところが、HBなどの堅い芯で午後2の論文の解答用紙のようなツルツルした紙に記述しようとすると、逆に芯のとがった部分のみ紙に接するため、芯のひっかかりを感じて書き心地がものすごく悪くなった。
 そのため、柔らかい芯→クルトガ搭載タイプ、硬い芯→ドクターグリップなどと使い分けたほうがいいと感じた。
 しかし、このあたりは書き方によっても随分違うと思うので、実際に試してリスクを軽減するか、異なる芯やシャープペンを複数持ち込むなどのリスク回避を検討したほうがいいと思う。

プロジェクトマネージャ試験の勉強法まとめ 論文の書き方具体例
具体的な午後2問題の論文の書き方
例題
 平成15年度試験の問2を利用。みよちゃん本購入者は翔泳社のサイトからダウンロードできる。
 または、こちらのサイトでも公開されているようだ。
 この論文は比較的簡単な論文だと思う。プロマネとして実施すべきことが問題文中に網羅されているので、それに従って記入すればいいだけだから。これを差別化するためには、知識をちりばめること、整合性のある論文にすること、定量的な表現を入れることが重要になる。
その1 まずは設問から章立てする
 すべての設問に答えられる内容にするために、まず設問から章立てを作る。そして、それに併せて論文を組み立てて行く。
 具体的に章立てを記述するのは時間がかかるし、手の耐久力を消費してしまうので、可能な限り問題文にアンダーラインを引き章番号を記述するなどして済ますようにしよう。
 エディタで骨子を作成する演習段階なら、ちゃんと章立てをすべて記述して記述例として保存しておこう。あとから見直すと、もっとこんなこと書けばよかったとか、自分の成長を確認できるのと同時に論文を改善できるのでお勧めだ。
論文例
------------------------- 16行×25列 400文字
1 私が携わったプロジェクトについて
1.1 プロジェクトの概要
1.2 開発支援ソフトウェアの概要と特徴
2 ソフトを効果的に使用する工夫と見直しについて
2.1 プロジェクト立ち上げ時の工夫
2.2 プロジェクト遂行中の見直し
3 活動の評価と今後の改善点について
3.1 実施した活動をどのように評価しているか
3.2 今後どのような改善を考えているか
------------------------- 16行×25列 400文字
その2 問題文から記述すべき内容を抜粋する
 次に章ごとに問題文から抜粋して、書き込むべき内容をまとめていく。ただまとめていくだけなので、ここまでは誰でも簡単にできるようになると思う。
論文例
------------------------- 16行×25列 400文字
1 私が携わったプロジェクトについて
1.1 プロジェクトの概要
 ※特定の開発支援ソフトウェアの使用を指定された
 ※ほとんどの要員がそのソフトの使用経験がない
1.2 開発支援ソフトウェアの概要と特徴
 ※コンポーネント指向の開発環境や言語、CASEツールなど
2 ソフトを効果的に使用する工夫と見直しについて
2.1 プロジェクト立ち上げ時の工夫
 ※プロジェクト中の要員の教育
 ※キーパーソンへの教育やキーパーソンによる訓練の実施
 ※作業標準の制定や先行開発
 ※外部の過去の事例、プロジェクト中のノウハウの利用や共有
2.2 プロジェクト遂行中の見直し
 ※要員の生産性の監視
 ※必要な要員への再教育、作業方法の周知、仕組みの見直しの実施
3 活動の評価と今後の改善点について
3.1 実施した活動をどのように評価しているか
 ※大成功
3.2 今後どのような改善を考えているか
 ※改善点
------------------------- 16行×25列 400文字
その3 骨子を考える
 ここが最も重要な作業になる。ここで矛盾のない骨子を作ることが合格論文の第一歩となるからだ。2000字以上の論文になると、話の流れを一つ間違えてしまうと書き出しと最後でまったく意見の異なる論文になってしまうことがよくある。訂正しようにも、手書き論文は大幅な書き換えをすることは難しく、それが致命的になってしまう可能性が考えられる。
 どのような内容の論文を記述すればいいか、それは記述例を問題文が提示してくれており、問題文からの抽出はすでに終わっているので、それに従って骨子を作成すれば矛盾や書き漏れなく作成することができるだろう。
 ここで特に注意するのは、設問アに記述すべき前提条件や、設問イで記述したい定量的表現をどのように記述するか想定しながら骨子を作ることだ。すでに記述しているので省くが対策がいくつも考えられる中で、これを選択したという根拠になる記述=プロジェクトの特徴を記述することは必須となる。
 さて、今回の論文における必勝パターンの適用方法は以下の通りになる。
  • ○あるプロジェクトがある → 設問ア プロジェクトの概要
  • ○そのプロジェクトにはある特徴がある → 設問ア 特定の開発ソフトの使用、要員がそのソフトの使用経験が無い
  • ○その特徴のためプロジェクトにはリスクが内包している → 設問イ 要員のスキルが低く品質低下、納期遅延のリスク
  • ○リスクが顕在化しないように事前対策を複数検討し選択する → 設問イ 要員の教育、作業標準の設定や選考開発
  • ○でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった → 設問イ 要員の生産性の監視
  • ○さらに対策を検討する → 設問イ 要員の再教育、作業方法の周知、仕組みの見直し
  • ×でもリスクが顕在化してしまった → 本問ではここは求められていない
  • ×そのために事後対策を複数考えて選択する → 本問ではここは求められていない
  • ▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性 → 設問イかウ 余裕があれば
  • ▲その予防策も考える → 設問イかウ 余裕があれば
  • ○うまく収まってめでたしめでたし。でもこうすればもっとよかったかも → 設問ウの内容
 上記の必勝パターンから実際に作成した論文の骨子例を以下のように作成した。
論文例
------------------------- 16行×25列 400文字
1 私が携わったプロジェクトについて
1.1 プロジェクトの概要
 ※特定の開発支援ソフトウェアの使用を指定された
 ※ほとんどの要員がそのソフトの使用経験がない
 ▼ネットワークの構築を簡単にするためWebアプリ形式の基幹業務システム ← プロジェクトの概要
 ▼顧客もWebアプリを利用したシステムは未経験 ← プロジェクトの概要
1.2 開発支援ソフトウェアの概要と特徴
 ※コンポーネント指向の開発環境や言語、CASEツールなど
 ▼本チームは未経験の技術だが今後の受注が見込めそうと勉強を兼ね経営陣が指定 ← リスク要因
 ▼MS社が提供するコンポーネント指向の統合開発環境を利用が前提 ← プロジェクトの特徴
 ▼一部要員が他の部署で使用経験が十分あることも未経験技術を採用した理由 ← プロジェクトの特徴
 ▼生産性は1000step/人日とベンダが説明 ← ツールの特徴
2 ソフトを効果的に使用する工夫と見直しについて
2.1 プロジェクト立ち上げ時の工夫
 ※プロジェクト中の要員の教育
 ※キーパーソンへの教育やキーパーソンによる訓練の実施
 ▼内部設計移行はプロトタイプ作成要員を講師とする定期的な勉強会を実施 ← 事前対策
 ※作業標準の制定や先行開発
 ▼要件定義や外部設計で先行開発を兼ねてプロトタイプ手法を利用→顧客にも自社にも有利 ← 事前対策
 ▼一部キー要員をプロトタイプ作成に当て経験を積ませる ← 事前対策
 ※外部の過去の事例、プロジェクト中のノウハウの利用や共有
 ▼質問しやすいように質問掲示板を設置する ← 事前対策
2.2 プロジェクト遂行中の見直し
 ※要員の生産性の監視
 ▼一部要員がベンダ説明の1000step/人日を下回る800step/人日 ← 兆候の発見理由
 ※必要な要員への再教育、作業方法の周知、仕組みの見直しの実施
 ▼生産性の低い要員への再勉強会の実施とキー要員による指導強化 ← さらなる対策
3 活動の評価と今後の改善点について
3.1 実施した活動をどのように評価しているか
 ※大成功
 ▼生産性は早期に1000step/人日を取り戻し大成功 ← めでたしめでたし
 ▼リスク対策として納期とコストに余裕をみた→勉強のためと経営者も許容 ← 対策することで発生するリスクの防止
3.2 今後どのような改善を考えているか
 ※改善点
 ▼事前に作業標準を作成し制定しておけばよかった ← 改善点
------------------------- 16行×25列 400文字
 今回のポイントは、なぜ未経験な技術を採用しなければならなかったのかという説得力、経験を積ませるための方法論とそれを選択することの合理的な理由だ。あとはどれだけ知識を並べられるかで、合格論文に近くなると考えられる。
 未経験な技術を採用する理由は経営側からの指示という想定だ。そして未経験な技術を採用しているため、サポート可能な要員として、他部署でこの技術を習得しているエキスパートが存在していることも想定している。 プロトタイプと兼ねた先行開発を選択した理由は、顧客企業も新技術に明るくなくプロトタイプを利用することで要件定義やレビューがスムーズに進むという一石二鳥という理由付けが特徴となっている。
 定量的な表現としては、生産性の指標としてベンダが公表する生産性(step数)を取り入れることにした。
 この場合は事前対策がメインなので、考えられる対策を記述できるだけ記述したほうがプラスになると思われる。
 今回は勉強会を実施することにしているが、勉強会を実施するとそれだけ納期とコストが超過する可能性があるが、その余裕を見た納期とコストを見積もり、さらに経営者に「勉強のため」だから認めてくださいということを記述することで、事前対策を実施することで発生する可能性のあるリスクを低減させている。
 今回は、プロトタイプ手法と先行開発を兼ねたこと。エキスパート要員のようなキーとなる要員を先行参加させ学習させたこと。そのエキスパート要員らによる他の要員の学習機会を設けたこと。質問掲示板を設置したこと。生産性指標を管理して再教育したこと。作業標準を作成して徹底させること。という手法をそれぞれちりばめた形になった。
 後は、この骨子に従って、知識をちりばめたり、なぜそう考えたのか理由付けを説明して肉付けをしていくだけで論文の完成という具合である。
その4 実際の論文例
 スペースが無いので設問イだけ。本チームは未経験のテクノロジ。顧客もそれほど詳しくない。MS製品の新テクノロジを利用することは経営陣の要望。別チームでテクノロジを経験した経験者が本チームにいる。ベンダから平均的な生産性の数値が提出されていたという前提の流れで。
論文例
------------------------- 16行×25列 400文字
2.1 プロジェクト立ち上げ時の工夫
 プロジェクトを立ち上げるにあたり、前述のように本
チームで未経験の技術を使用することは非常に大きなリ
スクになると考えた私は、これらのリスクが顕在化しな
いよう対策を取らねばならないと考えた。
 まず一つはプロトタイプ手法を利用した先行開発であ←知識のちりばめ プロトタイプ手法
る。本プロジェクトでは顧客もWeb アプリの利用経験が←事前対策 先行開発
なく、これを利用することの操作性を心配しているよう
であった。プロトタイプ手法を利用してレビューを実施
すれば実際の操作性を再現し、実際にユーザに利用して
もらうことで、よりスムーズにレビューが進むだろうと
考えることができた。
 さらにこのプロトタイプの作成を、他部署でWeb アプ
リ開発経験豊富な要員と本プロジェクトのチームリーダ←知識のちりばめ 経験豊かな要因のサポート
やキー要員などで作成することで学習を兼ねて実施しよ
うと考えた。こうすることで事前に経験者からの技術の
学習が実践を通じて効率よくOJT 形式で実施できると考←知識のちりばめ OJT
えられたからだ。
 また内部設計以降は、各要員に対して先行開発要員を
講師とした就業時間内の定期的な勉強会を開くことにし←事前対策 勉強会の実施
た。これによって先行開発要員から全てのチームメンバ←知識のちりばめ 就業時間内の勉強会
に対して技術や開発基準の学習となりスキル向上になる
と考えたからである。
 もちろん勉強会の実施により一時的に時間がとられ進←事前対策 施策することのデメリットを潰す対策
捗が遅れる懸念があったが、今回は初めて使用するテク
ノロジということである程度の余裕をみた開発スケジュ
ールを上位管理者が認めてくれたことも幸いした。
2.2 プロジェクト遂行中の見直し
 EVMSを利用し、より密に進捗の管理を行うため要員か←知識のちりばめ EVMS
ら週に一度の報告でリアルタイムに進捗を管理していた←知識のちりばめ 進捗報告を密に
ところ、一部の要員で進捗が遅れていることが明らかと
なった。
 チームリーダに指示し生産性の進捗状況を報告させた
ところ、一部の要員で生産性が低下し、ベンダ説明の生
産性である1000step/人日を下回り800 step/人日と管←定量的表現
理下限を下回っていることがわかった。
 そこで各チームリーダや開発要員から、気兼ねない意←知識のちりばめ 個別面接
見を聞くために個別に面接を行い、原因を特性要因図で←知識のちりばめ 特性要因図
調査したところ、新しいテクノロジの習得が遅れている
要員の存在が明らかとなった。
 現在はまだ進捗遅れはそれほど大きなものではないが←知識のちりばめ 技術習得の遅れは後に響く
技術習得の遅れは後々に大きな影響を落とすことが多い。
そのため私は生産性の低い要員に対し個別に再勉強会を←事後対策 個別の再勉強会
実施しスキルの向上をさせることにした。
 また何か質問がある場合に簡単に質問ができるよう、←知識のちりばめ ナレッジベースの設置
ナレッジベースを目的とした質問掲示板を設置し、要員←知識のちりばめ ノウハウの共有化
に利用してもらうこととした。質問への敷居を低くし、
またノウハウが共有化されると考えたからだ。
------------------------- 16行×25列 400文字
以上 48行×25列=1200文字(空白、改行含む)
 実際に10分程度で書き上げたもの(※一部後日加筆)なので文章の流れや「てにをは」がおかしかったりするけど、たぶん実際もこんな感じになると思う。
 大まかな流れは骨子の通り。なぜその対策をしたが。その根拠は何か。何でそれを理解したか。という知識を散りばめてこんな感じにしあがるのでは?という例ということで。たぶん内容的にはレベルAぐらいはいけてると思う。わからないけどw
 ただ流れは理解してもらえると思う。基本的にはプロジェクトにはリスクが潜在としてあって、それをどう顕在化させないようにコントロールしたかという話になるということ。そして、なぜそういう行動をしたのかという行動の理由を説明していること。で行動した結果なマイナスの側面も説明していること。行動の理由の説明が知識の散りばめにもなるし、プロマネとしての知識の披露や、行動指針を知る術になるという感じになると思われる。
 いちおう自分が合格した論文でも上記の流れを汲んでいるので、決して的外れではないと思う。
コメントを残す

コメントを投稿するには画像の文字を半角数字で入力してください。


画像認証


  • 最終更新:2017-11-17 20:40:38

このWIKIを編集するにはパスワード入力が必要です

認証パスワード