（情報処理技術者試験）プロジェクトマネージャ試験

来週から、春の情報処理技術者試験の申し込みが開始となります。
春は、当ブログにも関連の深い、「プロジェクトマネージャ試験」が実施されます。
私も、2014年の春に受験し、無事合格しました。
今回は少し趣向を変え、プロジェクトマネージャ試験の受験記、および学習方法などを紹介したいと思います。

【受験理由】

当時の出向先で、プロジェクトマネジメントの知識を使って、成果を出している管理者と出会いました。

成果を出すコツが、プロジェクトマネジメントにあるのでは？と考え、学習を始めました。
（これが、プロジェクトマネジメントとの出会いでもあります。）
そして、せっかく学習するなら何か目標を、ということで、受験することとなりました。

 【学習期間】

決意してから受験するまで、結局1年半を費やしました。
試験が年1回なので、1回見送った結果、この期間となりました。
期間中、仕事も忙しかったですが、地道にコツコツ学習を進めていました。

【学習方法】

○参考書
学習の指針となるテキストは、「情報処理教科書 プロジェクトマネージャ」を選択しました。

情報処理教科書 プロジェクトマネージャ 2018年版

 

午前・午後の両方を網羅していること、
テクニックや解説も豊富であることなどが選定理由です。
後で知ったのですが、ネット上でも一押しのテキストとして紹介されています。
自分も使用してみて、とても良書だと思いました。

また、回答を導き出すのに、PMBOKの知識も必要になってくるため、
以前買った、「プロジェクトマネジメント標準 PMBOK入門」を引っ張りだして読み込みました。

プロジェクトマネジメント標準 PMBOK入門 PMBOK第5版対応版

あとは、先輩からPMP試験のテキストを借りて読んでました。
これらの読み込み→過去問→再度、不足しているところを読み込み、
というように、学習を進めました。

○午前1（50分・選択式・30問出題）

前提知識として、これまで何回か受けていた高度試験の積み重ねがあり、
それに加え、過去問6回分を3週実施しました。
午前1は範囲も広いですので、過去問を中心に学習を進めます。
各回、8～9割正答できるようになるまで、暗記する勢いで学習しました。
空き時間30分でも1回分できるので、寝る前に1回分、という感じで実施してもよいと思います。

試験本番のペース配分としては、「1問当たり1～1.5分」となります。
1問に10分とかかけてしまい、後半の問題ができなかった、などが無いようにしましょう。
難しい問題は後回し。

○午前2（40分・選択式・25問出題）

ここから、プロジェクトマネージャ試験独自の学習が必要となります。
参考書の紹介のところの通り、テキストの読み込みをベースとして、
あとは過去問を中心に進めました。
こちらも、過去問6回分を3週実施。
進め方は午前1と同じです。

試験本番のペース配分は、こちらも「1問当たり1～1.5分」です。

○午後1（90分・記述式・3問中2問選択）

午後問題は、知識だけでなく慣れやテクニックも必要となってきます。
過去問を実施しながら、回答のコツを掴んでいくようにしましょう。
過去問6回分を、2週実施しました。
解答とPMBOKを照らし合わせて、このようにPMBOKを使う、ということを確認しながら学習しました。
ここに一番時間をかけたような気がします。

形式としては、数ページの問題文を読んで、その内容について、文章で回答する、というものとなります。
国語の試験です。
ですので、問われていることを回答する、というのが基本になります。

具体的には、
・EVMを採用することで、問題を解決できると判断した理由は何か。
　→進捗の進み・遅れを、数値で判断できるから。
・早い段階で利用部門に参加してもらうようにした目的は何か。
　→プロジェクトへの参加意識を高めるため。
・M課長がチームに出した指示は何か。
　→遅れを回復するためのリカバリプランを策定すること。
・M課長は、作業時間管理の仕組みをどのように変更したか。
　→タスク別に時間を管理するように変更した。
というように、問われていることが記載すべき回答となります。
「理由は何か」に対して、「～するように変更した」は、回答になり得ません。

また、回答すべき内容は、本文中に書かれていることが多いです。
自分で解決策を導き出すのではなく、本文に記載されている問題点を見つけ出し、
それを回答する、という感じになります。
これが、知識だけではなく、テクニックが必要、という所以となります。
※そうでないと、採点できないからでしょうね…。
※まれに、知識を問う問題もありますが、数は少ないです。

・過去のPJでは、しばしば遅れが発生していた。
　→なので、EVMを採用して、解決しようとした。
・ユーザ部門の参加意識が低く、後工程での仕様変更が頻発したことがあった。
　→なので、早い段階から参画してもらうようにした。
・BチームのSPIが「0.8」であった
　→なので、リカバリプランを立てる必要があった
という感じです。

以上より、問題点を見つけることが重要であり、
ここにPMBOKの知識が重要となってきます。
まずは設問を読み、対応する本文の箇所の周辺で、問題となりそうな点を抽出する、
というのが回答テクニックとなります。

試験本番のペース配分は、
問題選択に5分、
1問目に40分（その中でさらに配分する。設問1～3なら13分・13分・13分。）、
2問目に40分、
最後の5分で見直しを行う、という風に進めるとよいと思います。

○午後2（120分・論述式・2問中1問選択）

※午後２の論文の例を書きました。参考になればと思います。 

ksk-2g.hatenablog.jp

午後2試験は、短い設問に対して、経験と知識に基づいた、2,400文字～3,200文字の論文を作成する形式となります。
2時間で、手書きで原稿用紙6～8枚を埋めるという、大変な試験です。
しっかり対策しないと、さっぱり書けずに終わってしまいます。
私がやった学習としては、
論文の概要（問題文を読み、章立てと骨子、および記載ポイントを書いたもの）を15問分作成、
概要を読みながら、規定文字数に膨らませるのを3本分、
実際に時間を測って、手書きで論文を3本作成しました。

まずは、問題文から概要を作成し、章立て、および設問に対する論述ができるように練習を行いました。
概要の作成は、得意な分野だけではなく、色々な分野を作成するようにしましょう。
自分が参加したPJ、見聞きした問題点をフル活用し、論文に使えるケースを準備します。
（となりの部でこんな問題が起こっていた、というのも活用できます。）

論述する際は、まず不都合な状況（制約・問題点）を書いてから、
それを解決するために実施したこと（これは、問題文にいくつか例示されている）を書くとよいです。

具体的には、
・不都合：過去のPJでは、実コストが見積もりを大きく超過し、赤字PJとなることがあった。
　　そのため、経営者より、見積もりの制度を上げることが強く求められていた。
・実施したこと：過去の赤字PJでは、予定した生産性が出ていないことが散見された。
　　以上より、見積もりの精度を向上する必要があり、生産性をプロジェクトの特徴を踏まえ、修正することとした。
　　　※ここは、問題文に記載されている例をそのまま利用する
　　具体的には、過去のPJを分析して、作業に応じた適切な生産性を求めることとした。
　　その結果、難易度の高い、システム間連携に関する改修は、標準の生産性に「0.5掛け」、
　　改修の経験が豊富である、業務プログラムの改修は、標準の生産性に「1.2掛け」を行うこととした。
という感じになります。

さらに、論文をレベルアップさせるためには、「知識・キーワードを入れる」とよいと思います。
例えば、「ファストトラッキングを実施した」だけではなく、
・追加コストが発生しないため、優先的に採用することとした
・後戻りのない機能を厳選した上で、実施した
といった知識を入れると、合格レベルの知識があることを、採点者にアピールできます。

こういった観点で、概要を作成します。
いくつか作成できたら、400文字・600文字といった、必要な文字数に膨らませる練習を行います。
どうしても文字数に満たない場合は、もう一つ観点や実施したことを追加するなどが必要となります。
これができたら、概要なしの状態から、時間を測って手書きをしてみましょう。

試験本番のペース配分は、
問題選択に5分、
章立て、骨子作成に30分（ここが土台となります。しっかり時間をかけ、頭の中で論文を完成させます。）、
設問アに20分、設問イに45分、設問ウに20分（ここはとにかく書きまくるだけ！）、
最後の5分で見直しを行う、という風に進めるとよいと思います。

実際に書いてみると意外に書けないのが、設問アの「プロジェクトの概要・特徴」です。
ここに時間を食うのはとてももったいないです。
すらすらと書けるよう、しっかり対策しておきましょう。


以上、私が受験したときの学習方法と、学んだ解法テクニックとなります。
これから受験する方にとって、役に立てばと思います。

スケジュールの遅れ（対策例）

先ほどの記事のおまけです。

スケジュールの遅れに対して、原因を判別した結果、
どんな対策が考えられるかをいくつか紹介します。

＜ケース１＞
・原因：質問が頻発して時間が取れず、予定の作業が消化できない。
　　　　例えば、部下を多く抱えるリーダーが、絶え間なく来る部下からの質問責めで、回っていない状態　など。
・対策：リーダーへの質問を分散できるよう、追加人員や体制の見直しを検討する。
　　　　有識者をレビューアとしてアサインする、
　　　　比較的経験の多い人をサブリーダーに任命し、簡単な質問を対応させるなど。
　　　　リーダーの作業を、どれだけ別の人に移せるかを考えないといけない。

＜ケース２＞
・原因：スキルに対して難易度が高く、予定通り終わらない。
　　　　例えば、言語やフレームワークのスキルが低く、製造が終わらない　など。
・対策：スキルのある作業者に、担当をチェンジする。
　　　　つまづきそうな箇所をリストアップし、作業者のスキルの向上を図る。
　　　　困ったときに相談できるような人をアサインする。

＜ケース３＞
・原因：前工程の作業品質が悪く、予定通り進めることができなかった。
　　　　例えば、設計書の品質が悪く、確認や仕様変更が頻発し、製造が進まない　など。
・対策：設計書の見直しが必須。このまま進んでも、品質の悪いプログラムが出来上がるだけ。
　　　　どんな問題が多く発生しているかを検討し、その観点で再チェックさせる。
　　　　製造作業を1週間止めるなどして、再度計画を立て直す。

スケジュールの遅れ

プロジェクトの実行中、しばしば発生する「スケジュール遅れ」。

スケジュール表上で、完了日と現在の日付を比較して、
完了日を過ぎているのに、完了となっていないと出る、「遅れ」の文字。

管理者がそれを見つけて、
「遅れているじゃないか、何をやってるんだ！」
「早く挽回しろ！」とのハッパ。

それでもうまく行かないと、
「新しく作業者を3人入れるから、これで何とか納期までに終わらせろ」
という対策が取られ、
作業者にうまく作業が振れず、現場は大混乱。
結局、納期までに終わらず…

こんなマネジメントを、よく見かけないでしょうか。

＊
スケジュールに遅れの兆候が見られた場合、
最初にすべきことは「原因の判別」です。

なぜ、遅れているのか？
「時間が取れず、予定の作業がこなせなかった」
といった、遅れの原因を判別します。

次に、上記の遅れの原因が、今後も発生するかを検討します。
時間がとれなかったのが、1回きりの突発対応のためであれば、
今後、挽回の見込みがあります。
PJ作業に加え、上司が次々と作業を出してくるような状況であれば、
今後も発生する可能性があります。
このままでは、挽回は難しいかもしれません。

今後も発生するようであれば、その原因を取り除かなくてはいけません。
上司から振られる作業が多いようであれば、それを止めさせ、
その上で、遅れている作業を挽回するように、
人を投入する、残業体制を敷くなどの対応を行う必要があります。

遅れに対して、遅れ分の工数をあてがうだけでは不十分です。
（「3人入れるから大丈夫だろう」、という感じ）
遅れの根本原因を取り除かないと、繰り返し遅れが発生してしまいます。
原因を取り除いた上で、確実に終わるような計画を立てる必要があります。

また、要員の追加などの対策が取られると、
遅れを作った張本人が安心し、作業の手を緩めることもあります。
遅れを出している作業者は、遅れていることを自覚し、
早く遅れを挽回するよう、意識づけをすることも重要です。

作業者としては、とにかく予定通りに進めることが重要です。
終わらない場合、その原因をしっかり上位者に報告してください。

管理者としては、遅れを発見したとき、どういう対策をとるかで、
プロジェクトの成否が大きく変わってきます。
まずは上例の通り、原因の判別を実施してください。
もしかすると、真の原因が自分にあるかもしれません。

生産性

「スケジュールの作成方法」にて、スケジュールの作成に、生産性を用いることを紹介しました。
生産性とは、「単位時間当たりにできる作業量」のことです。

…簡単にこう言ってしまっていますが、自分のやっている作業について、
生産性がどれくらいか、把握しているでしょうか？
そもそも、プロジェクトは新規性があるものであり、
メンバの経験や求められる品質なども、プロジェクトごとに差異があります。
ですので、一律、これでいい、という値は存在しないことになります。
とは言え、何も計画無しで進めるわけにも行かないので、
類似プロジェクトの結果を参考にしたり、プロジェクトの特性から補正したりして、
目標値を定めていることが多いです。

でも、参考にするものが無い場合は、どうしたら良いのでしょうか？
その場合はズバリ、「測定してみる」のが良いです。
実測値ですから、信ぴょう性もかなり高いです。

例えば…10ページの設計書を元にコーディングを行ったら、
5時間かけて、300ラインのコードが作成した、という値を測定しておきます。
この場合は、300÷5＝60（ライン／時）という生産性が得られます。
さらに、10÷5＝2（ページ／時）という生産性も得られます。

この値を持っておくと、次に30ページの設計書をもらったとき、
およそ900ラインのコードができ、およそ15時間かかる、ということが推測できます。

これ以外にも、テスト100項目消化するのに10時間かかった、など、
成果と時間をセットにして測定することで、生産性は簡単に求めることができます。

難易度や状況につき、ばらつきはつきものですが、
複数回、継続して収集していくと、精度の高いものができてきます。

さらに…まだ経験の浅い後輩に作業を振るときは、
持っている生産性に0.8かけて算出する、などにも使えます。

目標のない状態で作業すると、時間が増大しがちです。
とにかく、まずは基準となる値を持つことが、非常に重要です。

生産性は、プロジェクトという大きなくくりでなくても、
もっと身近な、日々の作業で使えるものです。
ぜひ意識して、測定し、活用して欲しいと思います。

チーム・ビルディングのゴールと成果

人を集めただけでは、チームとしてうまく機能しない、というのは想像がつきやすいし、経験のある人も多いでしょう。
１＋１が「１」とか「１．２」とかになっている場合です。コストは2人分かかっているのですが…

メンバーをチームとして機能させるためには、チーム・ビルディングを行うことが必要です。
チームビルディングのゴール、および成果としては、以下のようなものがあげられます。

・メンバーが、相互補完関係にある。
　→同じタイプばかりで固めず、それぞれが得意な領域を持ち、補い合う状態。
・プロジェクトのゴールや目標が共有されている。
　→メンバーが、プロジェクトの成功に向かって作業している状態。
・メンバーは、協力して働くことを理解している。
　→他のメンバーが困っていたら、自主的に助けることが根付いている状態。
・適度なレベルの競争と、利害対立がある。
　→基本的には協力の姿勢であるが、ただの仲良し集団ではダメ。高いパフォーマンスを出すために、時には厳しいことも言えるような状態。

プロジェクトを開始してから、なるべく早くこういう状態を作り上げることが、プロジェクトリーダには求められます。

個人の成果・進捗ばかりを重視してばかりいると、チームとしての結びつきは弱くなっていきます。
自分の仕事だけ終わればよいと考え（もしくは、自分のだけで精いっぱい）、遅れているメンバーを気にしなくなってしまいます。
こうならないようにするには…「協力しなさい」というだけでは不足です。
ずばり、「フォロー用の工数を与えておく」というのが有効です。
1日のうちの数時間を、フォローするために使いなさい、と決めてしまうのです。
この時間で、遅れているメンバーを助けたり、他のチームの課題を解決したりするのです。
こういう活動を通じ、協力する姿勢や、プロジェクトの成功に向けて一丸となることを根付かせていくのです。
また、フォロー活動は、できればプロジェクトリーダではなく、メンバーが担う方が効果的です。
その方が、チームとしての推進力があがり、一体感を生むからです。

どんなチームができあがるかで、プロジェクトの成功は大きく変わってきます。
チームビルディングを重要な要素として、プロジェクト計画に組み込んでいきましょう。