まとめwiki

論文の書き方の具体例

最終更新:

matowiki

- view
管理者のみ編集可
プロジェクトマネージャ試験の勉強法まとめは移転しました
 情報処理試験まとめは、まとめwikiより情報処理試験関連情報だけ独立して情報を一新し別サイトに移転しました。
 今後ともまとめwikiをよろしくお願いいたします。
 移転先の情報処理技術者試験まとめwikiのトップページはこちら
Top > 情報処理試験まとめ > プロジェクトマネージャ試験の勉強法まとめ > 論文の書き方の具体例
プロジェクトマネージャ試験の勉強法まとめ 論文の書き方具体例

目次

関連ページ

初めに

 モバイル版のページが表示される方は見やすいPC版からどうぞ。画面下部の「PC版はこちら」をクリック

具体的な午後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 骨子を考える

 ここが最も重要な作業になると思う。ここで矛盾無い骨子を作ることが合格論文の第一歩となるからで、知識をちりばめるのは1文ごと書きながら考えることはできるんだけど、2000字以上の論文になると、話の流れを一つ間違えてしまうとまったく台無しになってしまうことも考えられ、しかも手書きであるために明らかに間違ったと思いつつも修正が不可能で致命的になる可能性も考えられるからだ。
 幸い、どんなことを記入すればいいか、記入例を問題文が提示してくれており、すでにそれをまとめているので、それを眺めつつ矛盾無いようなまとめ方をすればいいわけで、これまでの骨子を考える構成力を養った力がここで発揮されることになる。
 ここで特に注意するのは、設問アに記述すべき前提条件や定量的表現を創造しておくこと。すでに記述しているので省くが対策がいくつも考えられる中で、これを選択したという根拠になる記述=プロジェクトの特徴を記述することは必須となる。
 さて、今回の問題文の必勝パターンはこんな感じ。必勝パターンは必勝パターンのテンプレートに従って作成するわけだが、この必勝パターンのテンプレートについてやテンプレートの使い方は情報処理試験まとめ/プロジェクトマネージャ試験の勉強法まとめ/午後2対策で説明しているので、まずはこちらを読んでから読み進んでみてほしい。
  • ○あるプロジェクトがある → 設問ア プロジェクトの概要
  • ○そのプロジェクトにはある特徴がある → 設問ア 特定の開発ソフトの使用、要員がそのソフトの使用経験が無い
  • ○その特徴のためプロジェクトにはリスクが内包している → 設問イ 要員のスキルが低く品質低下、納期遅延のリスク
  • ○リスクが顕在化しないように事前対策を複数検討し選択する → 設問イ 要員の教育、作業標準の設定や選考開発
  • ○でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった → 設問イ 要員の生産性の監視
  • ○さらに対策を検討する → 設問イ 要員の再教育、作業方法の周知、仕組みの見直し
  • ×でもリスクが顕在化してしまった → 本問ではここは求められていない
  • ×そのために事後対策を複数考えて選択する → 本問ではここは求められていない
  • ▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性 → 設問イかウ 余裕があれば
  • ▲その予防策も考える → 設問イかウ 余裕があれば
  • ○うまく収まってめでたしめでたし。でもこうすればもっとよかったかも → 設問ウの内容
 で実際に作成した論文の骨子例はこんな感じ。
論文例
------------------------- 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
 ただ流れは理解してもらえると思う。基本的にはプロジェクトにはリスクが潜在としてあって、それをどう顕在化させないようにコントロールしたかという話になるということ。そして、なぜそういう行動をしたのかという行動の理由を説明していること。で行動した結果なマイナスの側面も説明していること。行動の理由の説明が知識の散りばめにもなるし、プロマネとしての知識の披露や、行動指針を知る術になるという感じになると思われる。
 いちおう自分が合格した論文でも上記の流れを汲んでいるので、決して的外れではないと思う。

関連ページ

参考書など

参考書など

参考書の選び方
 結論としては、通称「みよちゃん本」と呼ばれる情報処理教科書 プロジェクトマネージャをお勧めしたいと思う。この参考書は非常に優秀でお得。理由は以下の通り。
  • PMBOKなどの知識、実践に関する知識が簡潔ではあるが箇条書きでまとめられている
  • プロジェクトマネジメントに関係する知識について重要なもは巻末に説明がある
  • 平成14年以降の午後1の問題、解説、解答例が網羅されている。午後1解答テクニックも詳しい。
  • 平成14年以降の午後2の問題、解説、論文例が網羅されている。論文テクニックも詳しい。
 このように過去問の解説や基本最低限の知識などが網羅されている。基本的にはこの本に記述されている内容+ネットで調べられる内容で合格できるし、論文例が網羅されてるから別途、論文対策の参考書も必要無い。
 ただしデメリットもある。
  • プロジェクトマネジメントに関する知識の詳細な解説が無い(概略的なものはある)
  • 実際の業務におけるケーススタディ集や、事後対策等の記述もほとんど無し
 なので午前2レベルの知識を深く学習したかったり、PMBOKの細かい説明が欲しい人は、それらを解説しているような参考書が別途必要になると思う。もし深いところを知りたいと思った場合には「PMBOKをどうやって実際の仕事に活かすのか」といったことを解説している事例集を購入したほうがいいと思う。これらは実際のプロジェクトにならって紹介されているので、論文対策にも利用できる。
 逆にPMBOKの入門本とかは、PMBOKの概略を示しただけでテスト対策として有用とは思えなかった。
2018年おすすめの参考書一覧
過去問の入手方法
 平成16年(2004年)以降の過去問と論文以外の解答は午前、午後ともIPAのサイトからダウンロードできる。従って、特に問題集等は買わなくてもいい。
 また、みよちゃん本情報処理教科書 プロジェクトマネージャを購入すると、翔泳社のサイトから平成14年以降の全論文問題、参考論文例、論文解説、午後1問題の解答解説が手に入る。そのためみよちゃん本を購入すれば、特に専用の論文実例集や午後1問題解説集などは購入しなくてもいい。

コメントを残す

  • テストの投稿 -- 名前 (2011-08-15 18:20:55)
名前:
コメント:

2017年12月24日 (日) 13時04分32秒
&trackback()
記事メニュー
目安箱バナー