プロジェクトマネージャ試験の勉強法まとめ論文事例

プロジェクトマネージャ試験の勉強法まとめ 論文の書き方具体例
具体的な午後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-06-01 20:22:34

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

認証パスワード