ラベル 文章作成 の投稿を表示しています。 すべての投稿を表示
ラベル 文章作成 の投稿を表示しています。 すべての投稿を表示

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

先日「プロジェクトマネージャ」という試験を受けました。結果は無事受かったのですが、誰かの役に立てばと思い(&自分への備忘録として)、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として重要な仕事。

[雑記] 2010年の目標

明けましておめでとうございます/寒中お見舞い申し上げます。
皆様が、幸せな1年、そして素晴らしい new decade を過ごせますように。

***
新しい1年の始まりとして目標設定をします。この目標は、年末に旧年を振り返りつつマインドマップに描いたものです。今日は気の置けない友人にちょっとだけ話したのですが、まぁせっかく書いたのだからブログに公開しても良いかと思ったので、載せることにしました。ただし量が多いので抜粋。そして要望があればマインドマップもお見せします。

目標の重点項目としては、
・無駄な時間を作らないようにする。
・常に人のことを意識する。
・文章力を鍛える。→日記を書く、ブログを適度に更新する。
・キャリアについては常に考える。

これらを設定するに至ったきっかけはたくさんありますが、一言で表せば、自分に足りていなくて、かつ今身につけたいもの。


続いて、専門分野(IT)では、
・システムアーキテクトとプロジェクトマネージャを取得する。
・システム設計やプログラミング技術を、定期的に学習する。
・Webサービスを作成する。
そして語学(英語)では、
・単語と親しくなる。
・Time, New York Times, TechCrunchを読み続ける。
・英会話レッスンを受ける。
・会を開く。
また非専門分野では、
・言語学、感性、集合知、言語処理、経営、会計 について少しずつ学習

といったところ。

設定後に見返したときの反省点として、マインドマップにはもう少し具体的に描かれてはいるものの、抽象的というか、アクションが不明瞭だったり達成成果が見えづらいものがほとんどということです。次にレビューするのは4月の予定で、その時にはそれを意識するようにします。

***
さて、別の視点、というかより上位の視点から目標を立てるとすれば、自分を認識することだと思います。具体的には、上でやったような自己分析をして自分を観察しつつ、また外からの情報も取り入れて、自分をより認識することだと思っています。

自分のことはまだまだ把握できていないように感じます。上のように目標を書いてみたものの、自分としては、本当に望んでいるものと比べて抜けやズレがたくさんあるように感じます。自分自身で納得できる目標が書けてないということは、自分のビジョンが不完全だったり、自己のことを十分に理解していないということだと思います (まぁ自分が納得できるレベルが高いせいも若干はあるかもしれませんが)。

また、自分を把握するには、こうやって自己分析をするだけではなく、人に会ったり本を読んだりと外の空気に触れて自分のことを相対的に把握することも大事だと思います。

ということで、目標である「自己を把握すること」が達成できたならば、2011年の元旦に自分らしい目標設定ができていると言えると思うので、こちらも頑張りたいと思います。

***
最後に、今年も、どうぞ宜しくお願い致します。

[雑記] システムアーキテクト受験

システムアーキテクトを受験しました。
この試験は、IPA(情報処理推進機構)が行っている国家試験で、システム要求を分析からシステム構築までを問う試験。主にSEのための試験です。

このたぐいの国家試験はたくさんある(10種くらい?)のですが、その中で、システムアーキテクトはいわゆる「論文試験」と言われているもの。試験科目が全部で4科目でそのうちの1つが論文、といったもの。あるテーマについて「実際にどんな工夫をしたか」を、経験に基づいて、2,000〜3,000字にまとめるというものです。

論文といっても、どういった内容を書けば良いかやどういうストーリーにするかは問題文中に提示されているので、事例さえあれば、実のところそんなに難しくはない。
けれど、やはり2時間で2,000〜3,000字というのは、ふだん「文章」を書くことのない私にとってはしんどいです。(しかも手書きだし)


さて、試験を受けてみて感じたこととして、
私に足りない力は大きく2つ。
・書きたいことを明確化するのに時間がかかる。
・表現に乏しい。

1つめは、要点を捉えるのが苦手というか...
書き始めるときには、段落構成をしっかり捉えているのですが、
いざ書き始めていると、そのうちに、「この段落では何を書いているんだっけ」とか「全体の構成はどんなんだっけ?」と思えてきてしまうのです。

2つめは、言葉が出てこなかったり、概念をうまく表現できないことが多いということ。
言葉が出てこない例としては、「課題を設定」と書きたいときに、「課題を... なんだろう、調査?分析?探索?発見?評価?」などとあれこれ考えてしまうということ。(←ちなみにこの例は、説明のために簡単にしたのですが...)
概念を上手く表現できない例としては、「スケジュールを立てて作業を進めた」と書けばいいものを、「やるべきことをリスト化して完了日時を決めてそれに従って作業を進めた」のように書いてしまうのです。(こちらの例も説明のため簡単にしました...)

まとめると、文章を書くのが本当に苦手ということですかね。
試験を受けて、文章が書けないことを痛感しました。

しかし、社会人としては文章表現力は非常に重要。
資格に関してはなんとか逃げられるかもしれませんが、社会人としては文章力は大事ですよね。

そこで物を書くことを定期的に続けたいと思います。

今の時代なら「ブログを書く」でも良いのですが、「ハンドライティング」も大事。
手で書くとすると、後から段落構成を変えられなくなるから、力になりそうな感じがします。