はじめに
本エントリは、情報処理技術者試験の「プロジェクトマネージャ」の論文答案の書き方をまとめたものです。
H21春のPM試験に合格したときに僕が実践した午後2の論文答案の書き方と勉強法をまとめてみました。
※その他の情報処理関連のエントリは[情報処理]タグからどうぞ
サマリー
基本的な論文作成のお作法はSA試験編と同じで、「答案構成を作って、構成通りの答案を作る！」というやり方です。
答案構成というのはシナリオとか下書きとかいうイメージで、法律系の試験勉強で習った答案作成法を応用したものです。（プログラムを書くための基本設計みたいなものです）
論文作成作業項目をもう少しブレイクダウンすると、
- 設問から採点基準を漏らさず抽出する。
- 採点基準に沿って、問題文から論点を構成する。
- 論点をつなげて答案構成を作成する。
- 答案構成通りに論文答案を作成する。
となります。論点と言うのは配点ポイントのことで、要は「問いに対する答え」です。この論点を積み上げて答案を作成します。詳細は後述します。
準備
まず準備として過去問題集を買います。問題と出題趣旨、採点講評だけならIPAのサイトからPDFでダウンロードできますが、「解答例」と「解説」と「傾向と分析」を読むために本書を買います。
本書は「みよちゃん本」としてPM受験生から絶大な支持を得ている参考書です。
過去問解説だけでなく、勉強法、試験対策全般を網羅した良書です。まずこの本の「傾向と分析」を先にざっと読んで試験全体の大枠を理解しておきます。
論文のネタ集めについて
本試験の午後2では3問の中から1問選んで解答するのですが、選択すべき問題は「書けるネタをたくさん持ってそうなもの」を選びます。
ネタさえ持っていれば実際に経験してなくてもいいですが、大抵「具体的に」と言われるので、経験したプロジェクトの方が具体的なネタを書きやすいというのは言わずもがなです。
こういったネタは、普段の業務や論文問題集の答案、日経のIT系雑誌とかを沢山読んでコツコツ仕入れるのが王道ですが、「プロジェクトマネージャ 午後II 最速の論文対策」というネタ（本書で言う「モジュール」）の収集に特化した本があるので、時間がない場合はこれを使うという手もあります。
例題
今回は、私が前回本試験で解いたH21春のPM - 午後2 - 問3を例に説明してみたいと思います。以下、問題文全文。
問3 業務パッケージを採用した情報システム開発プロジェクトについて
近年の情報システム開発では、業務プロセスの改善、開発期間の短縮、保守性の向上などを目的として、会計システムや販売システムなどの業務用ソフトウェアパッケージ（以下、業務パッケージという）を採用することが多くなっている。このような情報システム開発では、上記の目的を達成するためには、できるだけ業務パッケージの標準機能を適用する。その上で、標準機能では満たせない機能を実現するための独自の”外付けプログラム”の開発は必要最小限に抑えることが重要である。
プロジェクトマネージャ（PM）は、例えば、次のような方針について利用部門の合意を得た上でプロジェクトを遂行しなければならない。
- 業務パッケージの標準機能を最大限適用する。
- 業務パッケージの標準機能では満たせない機能を実現する場合でも、外付けプログラムの開発は必要最小限に抑える。
外付けプログラムの開発が必要な場合には、PMは、開発が必要な理由を明確にし、開発がプロジェクトに与える影響を慎重に検討する。その上で、開発の優先順位に基づいて開発範囲を見直したり、バージョンアップの容易さなどの保守性を考慮した開発方法を選択したりするなどの工夫をしなければならない。
あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。
- 設問ア あなたが関わった情報システム開発プロジェクトの特徴を、採用した業務パッケージとその採用目的とともに、800字以内で述べよ。
- 設問イ 設問アで述べた情報システム開発プロジェクトの遂行に当たり、外付けプログラムの開発が必要となった理由、開発を必要最小限に抑えるために利用部門と合意した内容、合意に至った経緯、及び外付けプログラムの概要を、800字以上1,600字以内で具体的に述べよ。
- 設問ウ 設問イで述べた外付けプログラムの開発に当たり、業務パッケージ採用の目的を達成するためにどのような工夫をしたか。その成果、及び今後の改善点を含め、600字以上1,200字以内で具体的に述べよ。
問題は、大きく、タイトル、問題文、設問の３つから構成されています。
タイトルは「業務パッケージを採用した情報システム開発プロジェクトについて」という部分で、問題文はその下から設問の手前までの文章、設問は設問ア〜ウに書いてある文章のことです。説明の便宜上こう分けます。
１．設問から採点基準を漏らさず抽出する。
設問から採点基準を漏らさず抽出します。
これは設問に線を引いて、どこでどんなネタを使うかを考えます。
そして、解答の目次の大枠も決めますが、そんなにスッキリとは行かないので"およそ"で。
設問の流れから解答の目次を再構成すると、採点者にも採点しやすい構成になるので、なるべく設問のままで。
設問ア
- (1) あなたが携わった情報システム開発プロジェクトの特徴が書かれている
- (2) プロジェクトで採用した業務パッケージについて書かれている
- (3) プロジェクトで採用した業務パッケージの採用目的について書かれている
- (4) 上記の内容が800字以内で書かれている
設問イ
- (1) 設問アで述べた情報システム開発プロジェクトの遂行に当たり、外付けプログラムの開発が必要となった理由が具体的に書かれている
- (2) 外付けプログラムの開発を必要最小限に抑えるために利用部門と合意した内容が具体的に書かれている
- (3) 利用部門と合意に至った経緯について具体的に書かれている
- (4) 外付けプログラムの概要について具体的に書かれている
- (5) 上記の内容が800字以上1,600字以内で書かれている
設問ウ
- (1) 設問イで述べた外付けプログラムの開発に当たり、業務パッケージ採用の目的を達成するためにどのような工夫をしたか具体的に書かれている。
- (2) 業務パッケージ採用の目的を達成するためにした工夫の成果が具体的に書かれている
- (3) 業務パッケージ採用の目的を達成するためにした工夫に関する今後の改善点が具体的に書かれている
- (4) 上記の内容が600字以上1,200字以内で書かれている
これが採点基準の大枠です。（もちろんほんとの採点基準なんて知らないので、私の予想です。）
２．採点基準に沿って、問題文から論点を構成する。
前項で抽出した採点基準に則した論点を問題文から構成します。
論点というのは、採点基準を充たす問題提起、理由と結論、起承転結などで構成される配点ポイントのことです。
端的に言うと「問いに対する答え」です。
必要な論点を書き忘れる＝論点落ちすると配点されないと考えられますが、だからといって書きすぎて時間がなくなったり、記述が設問の要求するレベルに達してない場合（たとえば具体的じゃない、とか）も配点されないので、注意が必要です。
設問ア
(1) 情報システム開発プロジェクトの特徴
プロジェクトの特徴について書きます。
「業務パッケージを採用した情報システム開発プロジェクトについて」というお題なので、私の場合、「ERPパッケージを採用した製造業向け新人事システム構築プロジェクト」という設定で、後段につなげるためにプロジェクトの目的と規模を書きました。
間違ってはいけないのは、システムの特徴じゃなくてプロジェクトの特徴であるという点です。この起点が間違ってると、あとが全部だめになるので問題をよく読んで何について問われているかを確認します。
最後に「私はこのプロジェクトにPMとして参画した」と書くのがお作法です。
(2) 採用した業務パッケージについて
採用した業務パッケージについて書きます。
私の場合、採用した業務パッケージは人事システム用のERPパッケージソフトで、主な機能として給与計算と勤務管理があり、既存の会計システムと連携できるとかなんとか書きました。
他システム連携ネタはあとで優先順位の話に使うための仕込みです。
(3) 業務パッケージの採用目的
業務パッケージの採用目的について書きます。
これも後段につながるように書きたいのですが、私の場合そこまで頭がまわらず「コストが安く済む、FIT/GAPの結果が良かった、今後の拡張に耐えうるものだった」みたいなありきたりな採用理由を目的風に書いてお茶を濁しました。^^;
設問イ
(1)外付けプログラムが必要となった理由
外付けプログラムが必要となった理由について具体的に書きます。
これは問題文にある「標準機能では満たせない機能を実現するため」という理由がベースになります。これ当たり前すぎて逆に思いつかない理由ですが、これも答案にきちんと書いておきましょう。
そして、ここから具体的なネタを論点として展開します。私の場合、標準機能では満たせない機能の実現手段として、以下の２つの外付けプログラムを挙げました。
- 外付けのバッチプログラム
- UIの変更
そして、それぞれ追加開発が必要になった具体的な理由を挙げました。
- 外付けのバッチプログラム
- →外部連携に必要で、計画時からもともと追加開発を想定していたため。
- UIの変更
- →教育コストと開発コストを比較したら開発した方が安いから。
この具体的なネタを瞬時にひねり出せるかどうかが論文問題のキモですね。
本問の場合、ERPの外付けプログラム（アドオン）について知ってる人にとっては思いつきやすい話ですが、知らないと厳しいですよね。。。ネタ集めは事前にしっかり準備しておきましょう。
(2) 開発を必要最小限に抑えるために利用部門と合意した内容について
開発を必要最小限に抑えるために利用部門と合意した内容について具体的に書きます。これは問題文に書いてる「方針」をそのまま具体的にして論点として展開します。
- 「業務パッケージの標準機能を最大限適用する。」
- →業務パッケージに合わせて、業務フローを最大限見直す。
- 「業務パッケージの標準機能では満たせない機能を実現する場合でも、外付けプログラムの開発は必要最小限に抑える。」
- →外付けプログラムの開発コストが高い場合は、業務フローを見直す。
この２つです。
(3) 利用部門と合意に至った経緯:
利用部門と合意に至った経緯について具体的に書きます。
だんだん同じようなことを繰り返し書いてる気分になってめんどくさくなりますが、頭がこんがらがったら問題文に戻ります。
- 「開発が必要な理由を明確にし」
- →開発が必要な理由が明確でないものは作らず、業務フローを見直す。外付けプログラムは金がかかるから極力作らない。
- 「開発がプロジェクトに与える影響を慎重に検討する。」
- →開発がプロジェクトに与える影響を検討し、影響が少ないものは業務フローを見直す。外付けプログラムは金がかかるから極力作らない。
(4) 開発した外付けプログラムの概要
開発した外付けプログラムの概要について具体的に書きます。だんだん同じようなことを繰り（ｒｙ。
- 外付けのバッチプログラム
- →会計システムとの連携上、必要不可欠。プロジェクト計画時より織り込み済み。
- UIの変更
- →開発コストが教育コストより安くつくし、他の代替手段がないから。
設問ウ．
(1) 採用目的を達成するために工夫した点
採用目的を達成するために工夫した点について具体的に書きます。これも問題文から具体的なネタを論点として展開します。
- 「開発の優先順位に基づいて開発範囲を見直したり」
- →優先順位決めた。給与に関係するものを優先した。
- 「バージョンアップの容易さなどの保守性を考慮した開発方法を選択したりする」
- →外付けプログラムごとに開発・運用コストを明示した。優先度が同じなら安い方法を選択し、高いものは次のフェーズに後回しにした。
(2) 業務パッケージ採用の目的を達成するためにした工夫の成果
業務パッケージ採用の目的を達成するためにした工夫の成果について具体的に書きます。
これも問題文の冒頭に仕込んである「業務プロセスの改善、開発期間の短縮、保守性の向上」という採用目的から具体的なネタを論点として展開したいところですが、私の場合、考える時間がなかったので“コストと納期”という似たようなネタでお茶を濁しました。
- 当初想定した開発コストに収まった
- 予定期間内に完成した
(3) 業務パッケージ採用の目的を達成するためにした工夫に関する今後の改善点
業務パッケージ採用の目的を達成するためにした工夫に関する今後の改善点について、具体的に書きます。前項の工夫から何かひとつピックアップして問題をでっちあげます。
- 問題点
- →優先順位が低かった現場の導入サポートが結果的に不足して、問い合わせが多く発生し、想定外の運用コストがかかった
- 改善点
- →今後は問い合わせを減らす施策を実施したい
と、ここまでに次の答案構成でやる内容をほとんど書いちゃってますが、実際に論点抽出でやるのは、問題文に線を引いたり、対策とかを頭で考えてメモする程度です。
本試験で私が実際にやった論点抽出という線引き・メモ作業はこんな感じでした。見にくいですが。（写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。）
設問ア〜ウまでざっと見て、問題文から論点の抽出漏れがないか確認します。なければ答案構成の作成です
３．論点をつなげて答案構成を作成する。
論点抽出時のメモ書きを「答案構成」という形で問題用紙の[メモ用紙]というページにきっちり書き起こすというのが、この「答案構成の作成」というプロセスです。
大事なのは、全体を見て分量を調整したり、流れを阻害する要素がないかを考えて論点を取捨選択することです。
要は論点抽出のまとめですが、こんな感じに箇条書きに起こします。これがそのまま論文答案の答案構成になります。
ア．(1) 情報システム開発プロジェクトの特徴
(3) 業務パッケージの採用目的
- コストが安く済む
- FIT/GAPの結果が良かった
- 今後の拡張に耐えうるものだった
イ．(1) 外付けプログラムが必要となった理由
- 標準機能では満たせない機能を実現するため
- 標準機能では満たせない機能の実現手段と理由：
- 外付けバッチプログラム：外部連携に必要で、計画時からもともと追加開発を想定していたため。
- UIの変更：教育コストと開発コストを比較したら開発した方が安いから。
(2) 開発を必要最小限に抑えるために利用部門と合意した内容について
- 業務パッケージに合わせて、業務フローを最大限見直す。
- 外付けプログラムの開発コストが高い場合は、業務フローを見直す。
(3) 利用部門と合意に至った経緯
- 開発が必要な理由が明確でないものは作らず、業務フローを見直す。外付けプログラムは金がかかるから極力作らない。
- 開発がプロジェクトに与える影響を検討し、影響が少ないものは業務フローを見直す。外付けプログラムは金がかかるから極力作らない。
(4) 開発した外付けプログラムの概要
- 外付けバッチプログラム：会計システムとの連携上、必要不可欠。プロジェクト計画時より織り込み済み。
- UIの変更：開発コストが教育コストより安くつくし、他の代替手段がないから。
ウ．(1) 採用目的を達成するために工夫した点
- 優先順位決めた。給与に関係するものを優先した。
- 外付けプログラムごとに開発・運用コストを明示した。優先度が同じなら安い方法を選択し、高いものは次のフェーズに後回しにした。
(2) 業務パッケージ採用の目的を達成するためにした工夫の成果
- 当初想定したコストに収まった
- 予定期間内に完成した
(3) 業務パッケージ採用の目的を達成するためにした工夫に関する今後の改善点
- 問題点：優先順位が低かった現場の導入サポートが結果的に不足して、問い合わせが多く発生し、想定外の運用コストがかかった
- 改善点：今後は問い合わせを減らす施策を実施したい。
ここまで細かく書くとたぶん時間がなくなるので、実際は自分で判るキーワードを箇条書きする程度で十分かと思います。
本試験で実際に私が作った答案構成はこんな感じでした。見にくい上に字も汚いですが。（写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。）
４. 答案構成通りに論文答案を作成する。
答案構成が完成したら八割完成です。
時間的には逆で、ここまでで40分、残りの80分で答案構成の通りに答案を書ききります。
この時間配分については、本試験開始直後に、答案構成の隅に時間配分を書いてました。
| 14:30-15:10 | 下書き |
| 15:10-15:30 | ア |
| 15:30-16:10 | イ |
| 16:10-16:30 | ウ |
これを書いておくのは途中で「時間がない！」ということになった場合に論点切りをしてでもウにたどり着けるようにするためです。
書いてる途中でタイムアップするとか、最低字数を満たせないというのが最悪のパターンなので、それを回避するために時計をチェックしながら、ひたすら書き続けます。
なお、答案作成中にあれ？この論点落としてね？というのに気づいても、極力止まらずに書ききります。別のネタを思いついたり、なんか微妙に書き間違っていても、書いてる途中に答案構成を変更するのは危険です。
そのレベルの変更をするなら、答案構成時にきちんとやっておくことです。ここまで来たら、何も考えずに機械のように書ききることが大事です。
書き終わったら
最後まで書ききったら、受験番号とか選択した問題に○を付けてるか確認して、時間のある限り誤字脱字とかをチェックします。
ここまで来たらもう汚い字を書き直すぐらいで、答案構成を変更するようなことは無理なので諦めます。
この答案構成例について
なお、この答案構成例は優秀答案でもなんでもなく、私が前回の本試験時に作った答案構成を再現したものです。
おかしいところや甘いところ、記憶違いなところもありますが、「本試験の時間だとこれぐらいのことしか書けないのか」、「っていうかこの程度の解答でA評価なのか。。。！？」という感じで参考程度に見ていただければと思います。
問題集の答案例とか答案集の優秀答案って「こんな量、2時間で書けねーよ！」ってのも多いので。。。
普段の午後2の練習
普段、午後2の問題を練習で解くときは、答案構成のみ作って論点漏れしてないか確認する程度で十分かと思います。
ただし、最低一回は答案を最後まで作成して書く練習をしないと、時間配分ができません。2時間で3,000文字近く書く感覚を掴んでおく必要があります。
できれば勉強の一番最初にやっといて、あとは問題の量をこなすようにすると、2時間で書ける量しか答案構成しないように訓練できるので効率的です。
午前と午後1は？
なお、午前と午後1については、問題集を買ってたくさん解けば十分だと思います。
午前は、高度午前を網羅した情報処理教科書 [春期] 高度試験午前 I・IIがオヌヌメ。
あと、本試験で午前や午後1がメタメタだった時も、午後2を無料模試と考えて受けましょう。
これ一回やると、2時間の短さが本番さながら（っていうか本番w）で経験できるのでオヌヌメです。
採点基準について
採点基準については予想するしかないですが、それを考えるヒントになるのが試験後に公表される採点講評です。
例えば、H21春の上記問題についてIPAの採点講評.PDFから分析すると、
本年度は，"論述の対象とするプロジェクトの概要"の記述内容の不備が目立った。解答を理解するための重要な情報であり，またプロジェクトマネージャとしての経験が表現されるので，的確に記述してほしい。
（太字は私の加筆。以下同じ）
プロジェクトの概要の書き方については、ある程度自分の中でテンプレ作っておくといいですね。
本年度の試験から，設問ウでは論述内容をより具体的に表現するような問い方をした。中には設問イと設問ウの論述の重複や，設問ウに論述すべき内容を設問イに論述しているような解答も見られた。
どこに何を書くかについてはきちんと答案構成作って書く内容を事前に整理すれば解決できるはず。
また，答案用紙の解答欄が設問ごとに指定されていたが，これに従わずに，設問イの論述に続けて設問ウの解答を論述したり，解答字数の指定を守らなかったりした論述も見られた。問題冊子の注意事項，設問の要求内容をよく理解して解答してほしい。
「字数が足りなくても合格するか」はいつも議論になりますが、採点講評が「解答字数の指定を守らなかった」らアウト（減点）と言ってるわけですから、そんなことで足下掬われないようにしましょう^^;
各問に共通した点として，設問アではプロジェクトの特徴に対して，システムの特徴を記述する論述が多かった。また，問2，3においては，設問イ，ウでは開発者の視点からの論述が見られた。求められているのは，プロジェクトに関するプロジェクトマネージャの視点からの論述であることをしっかり認識してほしい。
プロジェクトじゃなくてシステムのお話を書いてしまうというのは、PMの論文で絶対やってはいけないミスです。
問3（業務パッケージを採用した情報システム開発プロジェクトについて）では，業務パッケージの標準機能をできるだけ適用し，外付けプログラムの開発を必要最小限に抑えた経験がうかがえる論述が多かった。しかし，設問で求めている，開発を必要最小限に抑えるために利用部門と合意した内容や合意に至った経緯については論述されず，開発した外付けプログラムとその必要性の説明に終始した論述も見られた。また，外付けプログラムを開発する際の工夫点について論述されていないものも見られた。
「開発した外付けプログラムとその必要性の説明に終始した論述」も、どうしてもシステム屋さん的な視点になっちゃうからですね。
また「利用部門と合意した内容や合意に至った経緯」や「工夫点」といった設問で問われている論点を落とすというのは致命的なのできちんと書けってことですね。
問3に限らず講評全般から分析するに、そもそも問いにきちんと答えられてない受験生が多いわけですから、そこをきちんとフォローするだけで合格答案になるということだお。
