[雑記] プロジェクトマネージャ 受験

先日「プロジェクトマネージャ」という試験を受けました。結果は無事受かったのですが、誰かの役に立てばと思い(&自分への備忘録として)、1.試験対策、2.学習時の留意点、3.本番時の留意点、4.午後Ⅱ回答  をまとめます。

1. 試験対策

次のような内容を行いました。
大項目小項目内容対策時間対策時期
知識の習得基礎知識問題集の基礎知識部分を熟読5h
(PMBOKの知識体系ごとに0.5h)
2ヶ月前
PMの行動規範を捉える午後Ⅱの問題・解答例を読む5h
(1題0.3h)
2ヶ月前
午前問題対策午前Ⅱ過去問題を解く3h (3回) 数週間前〜前日
午後問題対策午後Ⅰ練習過去問題を解く10h
(1題1h、10題)
2ヶ月前〜前日
午後Ⅱ練習過去問題を解く(フル)8h
(1題2.5h、3題分)
1ヶ月前〜前日
過去問題を解く(骨子のみ)3h (1題0.5h×5題)1ヶ月前〜前日
午後Ⅱ題材準備題材となるプロジェクトの概要を作成3h (1例1h×3例)数週間前〜前日
午後Ⅰ・Ⅱ 留意点リスト作成過去を振り返り、当日の留意点をまとめる1h数週間前〜前日
38h

ちなみに参考書は、『情報処理教科書 プロジェクトマネージャ』を利用(リンクは2011年度版)。本書は、類書の中でも飛び抜けて秀逸と感じました。

  • 要点が明確
  • 最短で合格しつつ、かつプロマネとして基礎力が付くように書かれている
  • 過去8年分の問題と回答が、付録CD-ROMに入っており、十分な問題量がある。
    (PMの行動規範は、午後Ⅱ問題+解答例を読むだけで分かるため、おそらく合格後にも使える。午後Ⅰの問題を読むだけで、午後Ⅱの事例対策になる)


2. 学習時の留意点

午後Ⅰ:
  • 得意分野の場合は、時間内に答えられるようにすることを目標にする。
    不得意分野の場合は、知識を付けることを目標にする。
  • 解く問題が「文中から抜粋するタイプ」か「知識で答えるタイプ」か「答えを推測するタイプ」かを明確にしてから、答える。
  • 字数によって、まず回答文の形式を意識してから、答える。
    例えば、10〜15字→キーワードで、20字→単文(◯◯が△△)、30〜40字→(◯◯が△△で□□) と。
午後Ⅱ:
  • 決まり文句は覚えておく。例えばアについては「私はシステムインテグレータB社に属するプロジェクトマネージャである。先般私が携わったプロジェクト(以下PJ)は、○○業のA社より 依頼された、○○○○○である。本システムは、○○○○○である。○ヶ月、要員は○人、総工数は○人月、総コストは◯千万円である。私は本案件のプロジェクトマネージャとして携わった。」など。
  • 各フェーズ(以下)について、実際に要した時間を記録し、以下の目安からどれだけずれたかを計る。
    • 問題文解読+ストーリー構成:20分 (〜14:55)
    • システム概要記入:5分 (〜15:00)
    • ア (目安700字):20分 (〜15:20)
    • イ (目安1200字):40分 (〜16:00)
    • ウ (目安900字):30分 (〜16:30)
  • 時間をオーバーしてしまった場合は、その原因を必ず分析する。
    (自分の場合は以下のような原因があった)
    • ストーリー構成で想定した内容は書き終えたものの、字数が足りず、追加内容を考えた。
    • ストーリー構成の内容が多すぎて、削りながら作文したため、時間を要した。
    • 書いているうちに内容の矛盾に気づき、修正方法の検討と修正に時間を要した。
    • 書いているうちに、ストーリー構成で想定した方針からずれていることに気づき、書きなおしたため、時間を要した。
    • 事象を説明するために、予想以上に字数を要してしまい、時間(と字数)を要した。(例えばプロジェクトの体制を複雑に設定しすぎてしまった など)
  • 論文の題材は、次のものを用意すると効果的
    • 納期を守るのに苦労したプロジェクト (PMBOKのタイム)
    • 品質確保に苦労したプロジェクト (PMBOKの品質)
    • 複雑な開発体制だったプロジェクト (PMBOKの人的資源・コミュニケーション)

3. 本番時の留意点

午後I (論述問題):
  • 試験開始前: 解答用紙が配られたときに解答欄を眺めて、どの大問でどのような解答が求められているかを眺め、解きやすそうな大問を見つける。例えば、用語を答える問題 が多いか、40字程度の記述が多いか...など。(私は、できるだけ用語を答える小問が多い大問を選ぶようにした)
  • 試験開始直後: その解きやすそうな大問を読み、問題の概要を把握する。
    まずはパラグラフのタイトル([]で書かれた部分) だけを読む(※1)。問題なさそうなら、その後、小問を読み始めて解いていく。
  • 解く問題が「文中から抜粋するタイプ」か「知識で答えるタイプ」か「答えを推測するタイプ」かを明確にしてから、答える。
  • 字数によって、まず回答文の形式を意識してから、答える。
    (例えば、10〜15字→キーワードで、20字→単文(◯◯が△△)、30〜40字→(◯◯が△△で□□) と)。次に、字数の過不足は、冗長な表現があれば削ったり言い換えたりする、修飾語を挿入/削除する、文末を調整する。
  • 解答欄は、できるだけ全て埋める。
※1 例えば、[計画策定]→[スケジュール管理計画]→[計画変更] という章立てになっていることを意識すれば、前半ではスケジュール策定に関する設問、後半ではスケジュール変更に関する設問があることがすぐに分かります。

午後II (論文):
  • ストーリー構成を行うときは、あまり詰め込み過ぎないようにする。
    「問題文中に現れるキーワードの2〜3点の具体化」と、もしあれば「文中にないが類推されるキーワード1点の具体化」の程度でよい。
    また、その他のストーリーを書いても、それが問題文に関係ない話なら全く意味がない。
  • 文章構成は、まず設問に対する答えを明確に一文で回答し、その後理由や具体例を書くようにする。
  • 具体性を持ったキーワードを意図的に盛り込む。
  • 可能なかぎり定量的に書く。
  • 書いてみた結果字数が足りていなかったら、主張を繰り返して字数を稼ぐ。
  • 数行書くごとに、問題の趣旨に逸脱していないか確認する。(上述の「書いているうちに、ストーリー構成で想定した方針からずれていることに気づき...」への対策)
  • 主張を明確にするため、原因・方式・対策などの項目を列挙する場合、必ず順位付けをする。これをしておくと、「トレードオフのある複数の項目からひとつを選ぶ」という場合にも説明しやすいと思う。
  • 使えるフレーズ
    • 「○○という状況であった。」
    • 「○○と判明した。」
    • 「本来ならば○○が理想であった。」
    • 「○○という制約があった。」
  • 「このような状況では一般的には◯◯をすべきだが、△△なので、□□とした」と書くと、状況が明確になる。(あとプロマネとして正しい知識を持っていることも示せる)
  • プロジェクトマネージャの本務ではない業務(すなわちPMBOKの9つの知識体系に直結しない業務)は絶対に書かない。書くと減点されるだけでなく、以後の論点がずれるという問題がある。(設計はシステムアーキテクトや他のスペシャリストと相談する/例え主題が移行やテストであったとしても、視点はQ,C,Dとリスクににする)
  • 解答用紙を汚さないため、問題冊子を切り離し、使わない1枚を下敷き替わりにする。(見開きの2ページについて、解答がそれぞれの解答用紙に写ってしまい非常に読みにくくなるのを防ぐため)
4. 午後Ⅱ回答
 メモ+一部補完で書きます。問3(組織要員管理)を選択。
  • プロジェクトについて:
    • 概要:B社向けSaaS基盤システムの構築。本PJは自社(A社)において経営戦略上最重要PJであり、本PJを早急に発足し、システムを早急にリリースする必要が出てきた。アプリケーションは既存のものを流用、インフラは新規設計・構築。
    • チーム編成:アプリケーション(AP)グループとインフラ(IS)グループ、自分は両グループを統括する立場のプロマネ。APグループはこれまで本システムのAP開発を行ってきた。ISグループは、インフラの研究部門のメンバを異動させることにより新規結成。
  • イ:人間的側面の問題、誘発されると想定したリスク、対策
    • PJが抱える問題:
      1. ISグループ内の意欲低下。
        別部門から人事異動で結成したことにより、本PJの業務内容と担当者の希望領域との間にずれが生じていた。それに伴いグループ全体として意欲低下。(設問中の「意欲の低下による成果物の品質の低下」を意図)
        さらに、上記問題に伴い、ISグループのリーダとメンバ間で不和が起こり、生産性低下。(設問中の「要員間の対立が...」を意図)
      2. APグループのリーダーPが、家庭の問題を抱えている
        (設問中の「健康を損なうことによる進捗遅延」に類する現象を意図)
    • 誘発されると想定したリスク:
      1. インフラ概要設計の品質低下による、スケジュール遅延と、後工程での後戻りに伴うコスト増
      2. リーダー不在により、APの開発についてスケジュール遅延
    • 対策:
      1. メンバ全員と面接を実施し、担当者の希望領域をヒヤリング。結果、本システムリリース後に、本システムの改善をさせる業務を担当してもらうことで、合意を得た。またそれに向け、現時点から改善点をまとめる作業を新規に指示。
      2. APグループのサブリーダーQ(経験豊富な開発者)に、リーダーPの業務の一部を権限付きで任命。特に、次期人事異動でシステムアーキテクトに昇格させることを意図した。
        なお、リーダーPの一部業務の移管は、リーダーP自身にさせた (Pの意欲を低下させないため)。
  • ウ:対策の評価、認識した課題、今後の改善点
    (上手くまとまっていないが、概ね以下のようなことを記述)
    • 対策を施すことで、スケジュール遅延が1ヶ月生じたが、全体として取っていたバッファ内に収まっており、スケジュール内でリリースできた。
    • 要員のモチベーションを維持することは重要。今回のケースでは、労働者が基本的には高次元の要求を持っていたが、実作業とマッチしないことが原因だったため、マズローのY理論の考え方に従い要員の自主性を尊重し、対策を打った。結果、要員が自主的に働くようになった。
    • 組織要員管理の面から、要員教育は重要。PJを遂行する上で、適切に要員教育計画を立てる必要がある。
    • 外部環境の変化が激しい昨今、限られた要員でPJを遂行せざるを得ないケースが多い。その状況下で、今回のように要員自身が納得しない状況で異動を伴い、PJを遂行するケースがある。そこで、モチベーションをウォッチし、適切に業務を与えることが、PMとして重要な仕事。

『読んだら使える 日経新聞の読み方』

読んだら使える 日経新聞の読み方』(角川総一著)という本を読みました。

最近、経営戦略や事業戦略について興味を持っています。ところが、私はおそらく同年代の中では日経はあまり読まない方 (週1〜2回) で、企業活動・経済・政治についてもかなり疎い方だと思います。そこで、もう少しインプットを増やすべきと思い、日経新聞を読む頻度を増やすことを決意し、本書を手に取りました。

本書を読んで重要と感じたことを4点:
  1. 重要箇所だけを読む;基本的には見出し+リードだけを読む
  2. 新聞の構造を知り、自分にとって重要なページから順に読む
  3. 他の情報源も活用し、得た情報を再構築する
  4. アウトプットしようという意識で読む
日常的に読んでいる方から見れば当然のことですが、今一度整理のためにまとめてみます。

1. 重要箇所だけを読む;基本的には見出し+リードだけを読む
どうしても多くの記事を最後まで読んでしまいがち。しかし、最後まで読むと時間がかかるけれども、時間をかけた割に得られる効果は少ないと思います。
そこで、基本的には見出し+リードだけを読みその他は切り捨てるという意識で、緩急を付けて読む。それが効率よく情報収集するためのコツだと思います。
切り捨てた結果として得られない情報はあるけれど、毎日読むことを続ければ徐々に背景知識も増えていき、ある程度の段階になると、自然と斜め読みだけで重要な情報を得られるようになるのではと思います。

2. 新聞の構造を知り、自分にとって重要なページから順に読む
記事レベルでは、見出し+リードがもっとも重要な箇所。一方、新聞全体でみるとどんなカテゴリがあって、どのページにどの程度重要な情報があって... を意識し、自分にとって重要なページから読むことで、時間効果的に読めると思います。
本書の3章に詳しく書かれています。
(ちなみに自分は、一面→総合→企業→経済 の順に読もうと思います。)

3. 他の情報源も活用し、得た情報を再構築する
理解するには、情報を多方面から得ることが重要です(以前書いた記事:「記憶を定着させるにはテストが最も効果的。知識が再構築されるから」も近い内容かもしれません)。そのため、日経以外にも、他の全国誌や、Google Newsのキーワード配信機能、ブログなどの情報源も活用することが望ましいです。

4. アウトプットしようという意識で読むこと
著者曰く、「『インプットしたからアウトプットできた』のではなく、『アウトプットしたいとう意欲が先にありき』」なのだそう。
何も意識しないと、ついつい受動的に読んでしまいがちだと思います。そうすると、おそらく、頭には入って来ないでしょう。そこで、アウトプットすることを前提に読むと、「どんな情報が必要か」を自然と意識し、必要な情報を必要なだけインプットできると思います。
つい忘れがちですが... 情報をインプットすることは目的ではなく、収集した情報を何らかの形で役立てることが目的ですよね。そこを意識しながら読むことが重要と再認識しました。

-----
前回の更新から半年以上も空いてしまいました。
仕事が忙しい...という一見正しそうな(だが大きく誤解している)理由で、いつの間にか記事を更新しない状態になっていました。
しかし、文章を素早く分かりやすく書けること(本質的には、必要な情報を効果的に人に伝えられること)は重要。そこで、トレーニングも兼ねて、続けて行きたいと思っています。以前書いた記事([雑記] システムアーキテクト受験)でも以下のとおり書いていますし...。
文章を書くのが本当に苦手ということですかね。 試験を受けて、文章が書けないことを痛感しました。 しかし、社会人としては文章表現力は非常に重要。 資格に関してはなんとか逃げられるかもしれませんが、社会人としては文章力は大事ですよね。 そこで物を書くことを定期的に続けたいと思います。

記憶を定着させるにはテストが最も効果的。知識が再構築されるから。 (To Really Learn, Quit Studying and Take a Test)

The New York Timesの記事 (To Really Learn, Quit Studying and Take a Test) から。

Purdue Universityでの研究結果:文章を読んで1週間後に内容を思い出すという実験をしたところ、「文章を読んだ直後にテストを受けた」被験者は、「文章を反復した」被験者や「図を描きながら文章を読んだ」被験者に比べて、文章の内容をよく思い出すことができたという結果になった。

また、「一週間後にどれだけ覚えているか?」という質問に対しては、「文章を読んだ後にテストを受けた」グループが、3グループのうちでもっとも自信がないと答えた。

なぜテストが効果的なのかは明らかになっていないが、「テストによって、後に情報を取り出すための手がかりが作られるからだろう」とのこと。また、Marcia Linn教授(University of California)によると、「テストによって、知識と知識のずれを認識し、より整合性がとれた形で知識が再構築されるのではないか」とのこと。

***

この記事のエッセンスは「得た知識は、テストをして知識を再構築することで、定着する」ということだと思いますが、自分の経験を振り返ってみると確かに納得できます。
自分は高校時代は社会科が不得意で、物理が得意だったのですが、それも当てはまりそうな気がします。問題集や暗記カードなどで「テスト」し丸暗記した社会科は、ほとんど長期的な記憶には残らないのに対し、色々な問題や事例を当てはめることで「テスト」した物理は長期的によく覚えているような気がします。

さて、この記事を読んで、気づいたことが3点あります。
1つめは、自分は理解したつもりになっている場合が多いなということ。例えば、「ふんふん、なるほど」と読み進めた本については、知識の再構築の過程を踏んでいないため、記憶への定着は少ないということになります (しかも図で整理しても定着しないというのだから)。一方、読んで頭に知識を入れたあと、様々なの角度から叩いて「テスト」した場合は、知識の再構築ができて定着する残ることになると思います。
(巷では「本を読んだらアウトプットせよ」と云われていると思いますが、その本質は、「アウトプットする過程で、知識の再構築が行われて、知識が定着するから」かもしれません。)

2つめに、語学についても同じことが言えそうです。単純に単語帳で語彙を頭に入れただけでは、定着しないと思います (仮に暗記カードを使ってテストをしたとしても、知識の再構築には寄与しないと思うので、効果がなさそうです)。一方で、頭に入れたその語彙を、他の知識と関連付けて再構築することで、はじめて定着することになると思います。例えば、その語彙をイメージする、その利用シーンをイメージする、他の単語と併せて文章を作る、話す、その語彙を辞書で引くなどをすることで、定着するのだと思います。

3つめ。この話は、PDCAのやり方にも生かせるのではないかと思います。仮に「ある活動に対してCheckしてActすることの本質が、その活動を再構築すること」だとすると、上で紹介した記事の「テスト」という考え方が当てはまるかもしれません。漠然とCheckとActを行っても効果はさほど現れず、「目的に適っている活動か?」「効果が出る活動か?」「もっと改善できる活動ではないか?」というように「テスト」するように行うと、活動を再構築することができ、より改善されるかもしれません。
(ちょっと飛躍しすぎた感はありますが...)