はじめに
本エントリは、情報処理技術者試験の「システムアーキテクト」の論文答案の書き方をまとめたものです。
H20秋の試験に合格したときに僕が実践した午後2の論文答案の書き方をまとめてみました。
「論文試験って言っても、何をどうやって書いていいのか判らない」という受験生向けの解説エントリになります。
※その他の情報処理関連のエントリは[情報処理]タグからどうぞ
サマリー
基本的な論文作成のお作法は「答案構成を作って、構成通りの答案を作る！」というものです。
答案構成というのはシナリオとか下書きとかいうイメージで、法律系の試験勉強で習った答案作成法を応用したものです。（プログラムを書くための基本設計みたいなものです）
論文作成作業項目をもう少しブレイクダウンすると、
- 設問から採点基準を漏らさず抽出する。
- 採点基準に沿って、問題文から論点を構成する。
- 論点をつなげて答案構成を作成する。
- 答案構成通りに論文答案を作成する。
となります。論点と言うのは配点ポイントのことで、要は「問いに対する答え」です。この論点を積み上げて答案を作成します。詳細は後述します。
準備
まず準備として過去問題集を買います。
問題と出題趣旨、採点講評だけならIPAのサイトからPDFでダウンロードできますが、「解答例」と「解説」と「傾向と分析」を読むために買います。
まずこの本の「傾向と分析」を先にざっと読んで試験全体の大枠を理解しておきます。ぶっちゃけ、これ以外の参考書類はいまいちですし、午後1対策にも使える良本です。
過去問解説だけでなく、勉強法、試験対策全般を網羅したオススメ参考書です。
問題の選択
本試験の午後2では3問の中から1問選んで解答するのですが、選択すべき問題は「書けるネタをたくさん持ってそうなもの」を選びます。
ネタさえ持っていれば実際に経験してなくてもいいですが、大抵「具体的に」と言われるので、経験したシステムの方が具体的に書きやすいというのは言わずもがなです。
例題
今回は、私が前回本試験で解いたH20秋のAE - 午後2 - 問2を例に説明してみたいと思います。以下、問題文全文。
問2 フレームワークの利用について
最近、システムの開発にフレームワークを利用するケースが増えている。フレームワークを効果的に利用することができれば、対象システムの品質を確保し、生産性の向上が期待できる。
ただし、フレームワークの利用においては、例えば、利用方法の習得時間の短縮、機能や性能面での制約への対応、機能の利用方法に関する開発者間のばらつきの統制、業務機能の効率の良い設計・開発などの課題に直面することがある。
アプリケーションエンジニアは、これらの課題を解決するために、利用するフレームワークの経験者や専門家の協力を得ながら、次のような対策を実施しなければならない。
- 利用方法の習得時間を短縮するために、専用の開発支援環境や利用ガイドを整備する。
- 機能や性能面での制約に対応するために、フレームワークの一部をほかのフレームワークや独自に作成したソフトウェアなどで代替する。
- 機能の利用方法に関する開発者間のばらつきを統制するために、利用規約を作成して周知徹底を図ったり、利用する機能に制限を加えたりする。
- 業務機能を効率よく設計・開発するために、フレームワークに基づいて、業務機能用のテンプレートや業務共通の機能を設計・開発し、各業務機能の設計・開発でそれらを利用する。
これらの対策を、システムの規模、要求される性能や信頼性の水準などのシステムの特性、開発要員のスキルなどを考慮して、効果的に実施しなければならない。
あなたの経験に基づいて、設問ア〜ウに従って論述せよ。
問題は、大きく、タイトル、問題文、設問の３つから構成されています。
タイトルは「フレームワークの利用について」というやつで、問題文はその下から設問の手前までの文章、設問は設問ア〜ウに書いてある文章のことです。説明の便宜上こう分けます。
１．設問から採点基準を漏らさず抽出する
設問から採点基準を漏らさず抽出します。
ここでは設問に線を引いて、どこでどんなネタを使うかを考えます。そして、解答の目次の大枠も決めますが、そんなにスッキリとは行かないので"およそ"で。
設問の流れから解答の目次を再構成すると、採点者にも採点しやすい構成になるので、なるべく設問のままで。
設問ア
- (1) あなたが開発に携わったシステムの概要について書かれている
- (2) 利用したフレームワークの概要について書かれている
設問イ
- (1) フレームワークを利用するために課題と認識したことが書かれている
- (2) 課題を解決した対策がどのような対策か書かれている
- 対策は、システムの規模を考慮したものであること
- 対策は、システムの特性を考慮したものであること
- 対策は、開発要員のスキルを考慮したものであること
- 対策は、効果的に実施した対策であること
- 対策は、重要と考えた点が中心に書かれていること
- 対策は、具体的な対策が書かれていること
設問ウ
- (1) 設問イで述べた対策について評価した点が簡潔に書かれている
- (2) 設問イで述べた対策について今後、改善したい点が簡潔に書かれている
これが採点基準の大枠です。（もちろんほんとの採点基準なんて知らないので、私の予想です。）
２．抽出した各採点基準に対して問題文から論点を構成する
前項で抽出した採点基準に則した論点を問題文から構成します。
論点というのは、採点基準を充たす問題提起、理由と結論、起承転結などで構成される配点ポイントのことです。
論点落ちすると配点されないと考えられますが、だからといって書きすぎて時間がなくなったり、記述が設問が要求するレベルに達していない（たとえば具体的じゃない、とか）と配点されないので、注意が必要です。
設問ア
(1) システムの概要
システムの概要を書きます。
システムの構成、用途、工数、期間を書いて、最後に「私はプロジェクトリーダとしてプロジェクトに参画した」と書くのがお作法です。
これは事前にある程度使い回しの効くテンプレートを用意しておきます。
(2) 利用したフレームワークの概要
利用したフレームワークの概要について書きます。設問イにつながるようなものを書いておくとラクなので、これは後から考えます。
私の場合、Webシステムであることや勤怠管理機能と人事申請機能があるフレームワークであるといった説明、マニュアルやガイドが整備されていて、サポートが充実している、お客さんの要件とマッチしているので採用した、みたいなことを書きました。
設問イ
(1) フレームワークを利用するために認識した課題
フレームワークを利用するために認識した課題について、問題文から論点とすべきものを抽出します。
と言っても実際にやるのは、問題文に線を引いて、そこから課題を考えてメモすることです。
ここでは設問に書かれている「具体的に」というのを充たすように。要は採点する人が「具体的だな」と思うかどうかですが、この設問が要求するレベルのネタ出しができるかどうかがA評価とB評価の分岐点です。(詳しくは後述)
「利用方法の習得時間の短縮」
→利用方法が煩雑で習得に時間がかかる、という課題。
「機能や性能面での制約への対応」
→既存の他システムとのシングルサインオンが利用できない、という課題。
「機能の利用方法に関する開発者間のばらつきの統制」
→プロジェクトの規模が大きいので開発者のスキルがバラバラになってしまう、という課題。
「業務機能の効率の良い設計・開発」
→工数が大きいので効率的にやらないとプロジェクトへの影響が大きい、という課題。
ここまで考えると、設問アのシステムの概要やフレームワークの概要に仕込んでおくべきネタが見えてきます。
(2) 課題を解決した対策
課題を解決した対策について、前項の論点と問題文から論点とすべきものを抽出します。
「専用の開発支援環境や」、「利用ガイドを整備する。」
- →Subversionを利用して開発現場のバージョン管理を支援する、という対策。
- →マニュアルやガイドを利用しやすいように全部印刷して見やすいところに置いておく、という対策。
「利用規約を作成して周知徹底を図ったり」、「利用する機能に制限を加えたりする」
- →コーディングガイドを作成してそれを開発前に開発者にレクチャーする、という対策
- →コーディングガイドから外れたものはコーディングチェックプログラムでチェックする、という対策
大事なのは、とにかく問題文から離れないこと。
「おらがシステムはこんなに凄かったのだー」とか書き始めて問題文から離れた時点でアウトです。
問題文は別に参考程度に書かれているわけではなく、これ書け！という出題者からの明確な意思表示です。
これを無視して、たとえば「仕様変更の頻発という課題と対策」みたいな勝手な論点を展開しても、配点されません。なぜなら採点基準を充たさないからです。
こう書くと「そんなこと言われなくても判ってる」とか「答案構成って全部問題文に書いてることのオウム返しじゃんw」と感じるかもしれませんがその通りで、この余計なことを書かずに問題文に書いてあることを漏らさずそのまま書くというのが、やってみるとなかなかできない、自分が実際にやったシステムの具体的な設計の話とかにどんどん逸れていくというのが、よくあるパターンです。
そうならないように練習するというのが論文試験の試験勉強の大半でした。
設問ウ
設問ウについては、問題文冒頭に仕込んである「品質の確保と生産性の向上」という論点を拾います。「簡潔に」という指示があるので大展開しないように。
(1) 対策について評価した点
対策について評価した点について、設問イの対策からピックアップして評価できる結果を2、3個書きます。
(2) 今後、改善したい点
今後、改善したい点について、設問イの対策からピックアップして何か問題をひとつでっち上げます。
設問ウは割とテキトーですねw。
大事なのは、設問イと対応してることです。
お客さんの偉い人に評価されたとか、テーブル設計が非効率だったので次は改善したいとか、これまでの流れをぶった切るようなものを持ってきたらアウトです。
実際にあったかどうかはどうでもいいので、採点者が「採点基準を充たしているな」と思えるネタを書きます。
と、ここまでに次の答案構成でやる内容をほとんど書いちゃってますが、実際に論点抽出でやるのは、問題文に線を引いたり、対策とかを頭で考えてメモする程度です。
本試験で私が実際にやった論点抽出という線引き・メモ作業はこんな感じでした。見にくいですが。
（写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。）
設問ア〜ウまでざっと見て、問題文から論点の抽出漏れがないか確認します。なければ答案構成の作成です。
３．答案構成をきっちり作る
論点抽出時のメモ書きを「答案構成」という形で問題用紙の[メモ用紙]というページにきっちり書き起こすというのが、この３の答案構成の作成です。
大事なのは、全体を見て分量を調整したり、流れを阻害する要素がないかを考えて論点を取捨選択することです。
要は論点抽出のまとめですが、こんな感じに箇条書きに起こします。
これがそのまま論文答案の答案構成になります。
イ．(1) フレームワークを利用するために認識した課題
(2) 課題を解決した対策
- Subversionを利用して開発現場のバージョン管理を支援する
- マニュアルやガイドを利用しやすいように全部印刷して見やすいところに置いておく
- シングルサインオンの部分について独自開発することで対応する
- コーディングガイドを作成してそれを開発前にレクチャーする
- コーディングガイドから外れたものはコーディングチェックプログラムでチェックする
- フレームワーク付属の帳票テンプレートを利用する
- 帳票テンプレートの利用を見越した設計ができるように要件定義を実施する
- フレームワーク利用経験者を推進担当として要員配置する（効果的だった）
ウ．(1) 対策について評価した点
- 効率が上がって見積工数の80%で済んだ
- バグが想定以下だった
ここまで細かく書くとたぶん時間がなくなるので、実際は自分で判るキーワードを箇条書きする程度で十分かと思います。
本試験で実際に私が作った答案構成はこんな感じでした。見にくいですが。
（写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。）
４. 何も考えずに答案構成通りに答案用紙に書ききる
答案構成が完成したら八割完成です。
時間的には逆で、ここまでで40分、残りの80分で答案構成の通りに答案を書ききります。
この時間配分については、本試験開始直後に、答案構成の隅に時間配分を書いてました。
| 問題読む | 14:30 | 〜14:40 | |
| 答案構成 | . | 〜15:10 | |
| ア． | . | 〜15:30 | 〜800文字 |
| イ−１． | . | 〜15:50 | 400文字〜 |
| イ−２． | . | 〜16:10 | 400文字〜 |
| ウ． | . | 〜16:30 | 600文字〜 |
これを書いておくのは途中で「時間がない！」ということになった場合に論点切りをしてでもウにたどり着けるようにするためです。
書いてる途中でタイムアップするとか、最低字数を満たせないというのが最悪のパターンなので、それを回避するために時計をチェックしながら、ひたすら書き続けます。
なお、答案作成中にあれ？この論点落としてね？というのに気づいても、極力止まらずに書ききります。
別のネタを思いついたり、なんか微妙に書き間違っていても、書いてる途中に答案構成を変更するのは危険です。
そのレベルの変更をするなら、答案構成時にきちんとやっておくことです。
ここまで来たら、何も考えずに機械のように書ききることです。
書き終わったら
最後まで書ききったら、受験番号とか選択した問題に○を付けてるか確認して、時間のある限り誤字脱字とかをチェックします。
ここまで来たらもう汚い字を書き直すぐらいで、答案構成を変更するようなことは無理なので諦めます。
この答案構成例について
なお、この答案構成例は優秀答案でもなんでもなく、私が前回の本試験時に作った答案構成を再現したものです。
おかしいところや甘いところ、記憶違いなところもありますが、「本試験の時間だとこれぐらいのことしか書けないのか」、「っていうかこの程度の解答でA評価なのか。。。！？」という感じで参考程度に見ていただければと思います。
問題集の答案例とか答案集の優秀答案って「こんな量、2時間で書けねーよ！」ってのも多いので。。。
普段の午後2の練習
普段、午後2の問題を練習で解くときは、答案構成のみ作って論点漏れしてないか確認する程度で十分かと思います。
ただし、最低一回は答案を最後まで作成して書く練習をしないと、時間配分ができません。2時間で3,000文字近く書く感覚を掴んでおく必要があります。
できれば勉強の一番最初にやっといて、あとは問題の量をこなすようにすると効率的です。
午前と午後1は？
なお、午前と午後1については、問題集を買ってたくさん解けば十分だと思います。
午前は、きちんとやるなら新試験の高度午前を網羅した情報処理教科書 高度試験午前Ⅰ・Ⅱ、お手軽にやるならポケットスタディ 高度試験共通 午前1・2対応がオヌヌメ。
あと、本試験で午前や午後1がメタメタだった時も、午後2を無料模試と考えて受けましょう。これ一回やると、2時間の短さが本番さながら（っていうか本番w）で経験できるのでオヌヌメです。
採点基準について
採点基準については予想するしかないですが、それを考えるヒントになるのが試験後に公表される採点講評です。
例えば、H20秋の上記問題についてIPAの採点講評.PDFから分析するに、
全問に共通して，規定字数に満たないもの，記述の乱雑なものや誤字脱字が目立つもの，論述内容が理解しづらいものがあった。
この日本語ダメレベルだと即行でD評価だろう。
課題に対する対策についての論述は不十分で，具体性に欠ける論述が多かった。また，対策をどのように効果的に実施したかを論述することを期待したが，実施した対策を列挙するだけの論述が多かった。
これはつまり、問題文をよく読んで、きちんと問いに答えてね！ってことですが、逆に言えばそれぐらい問いを無視した答案が多いわけです。
きちんと問いを分析して、論点を落とさなければA評価は普通に取れるということでしょう。
