高度情報処理試験の論文試験対策

2017年9月27日情報処理技術者試験,資格・検定

皆様こんにちは。ソリューション開発部の中川01です。

秋期の情報処理試験も近づいてきました。やはりIT技術者の公的な資格としては、有力で価値あるものなのではないでしょうか。いろんな技術者の方と面接させていただくことも多いのですが、やはり高度情報処理試験の資格を持っていると、注目度もあがります。

当社では高度情報処理試験合格した場合に、報奨金として15万円支給されます。このように、情報処理試験で手当てが支給される会社も多いと思います。とはいっても、高度情報処理試験の大部分で午後Ⅱは論述式、いわゆる論文式の試験、2時間で2,000字以上書くことが求められます。

私は昨年、情報処理試験のITサービスマネージャの試験を受験して合格しました。その試験で、たいしたこと書いてないなと思って試験を終えましたが、でもポイントはおさえているだろうと思い、合格できるという感触はありました。結果は合格で、3回連続で高度情報処理試験の論文式試験を突破したことになり、コツはわかった気がします。それほど立派な論文でなくても合格できるということを確信し、それを伝えたいと思ってこの記事を書きました。書き方について悩んでいる人たちにとって何かのヒントになれば幸いです。

ITサービスマネージャを中心に書きますが、システムアーキテクト、ITストラテジスト、ならびにプロジェクトマネージャなどの試験にも共通することを書きたいと思います。

難しくない

論文?2時間で2000字?そんなん無理?いいえ、しっかり対策すれば、それほど難しくはありません。

どこかで発表するような立派な内容でなくていい

高度情報処理試験の論述試験は論文といわれてますが、どこかで講演したり寄稿したりするものではないので、斬新であったり感嘆させたりする立派な内容である必要はありません。あくまで午前からの試験の延長です。教科書通りの当たり前のことを書いて、基本がわかっていることを伝えることができればよいのです。

形式は決まっている

設問の形式とそれにあわせた論述の形式は決まっています。設問アで対象のプロジェクトやシステムの説明、設問イで実施した施策について記述し、設問ウは振り返りです。このパターンにあわせて書くことを考えておけばよいのです。

出題テーマはある程度決まっている

どんな内容が問題として出るかはもちろん試験までわかりませんが、細かな違いこそあれ出てくるテーマはおよそ決まっています。プロジェクトマネージャなら、品質管理、進捗管理、外注管理といったテーマがよく出ています。こういったテーマが何年かローテーションで出題されているのです。

問題文をある程度引用すればいい

最低でも2時間の間に約2,000字以上を書くことになります。そんなに書けるのでしょうか?過去問の問題文を読んでください。いいこと書かれてます。論述を書くときは、ここから多くを引用して書けばよいです。まず、一般論として問題文の内容をほぼそのまま書き、その次に具体的な内容を続けて書くことで字数を稼ぎます。

60点とれば合格

合格ラインは60点です。2時間の間に完璧なものを書けるわけありません。でも合格すればいいのです。そんなにキレイな文章でないといけないとか、絶対的に日本語がおかしいところがないとか、そこまで完全でなくても大丈夫です。40点までマイナスされても合格できるのです。

対策方法

そんなに難しくないとはいえ、書くことは事前に考えておく必要があります。

過去問に沿って書くことを考えてみるのがいいと思います。いきなり頭から全部書くのは難しいので、少しずつ考えるとよいと思います。

まず、対象のプロジェクトを考えましょう。基本的には経験されたプロジェクトのことがいいですね。

書き方は決まりきっていますので、書き方をふまえつつネタを準備する方法を書いてみたいと思います。

設問ア

設問アでは必ず、対象システムやプロジェクトの説明です。ここでは、

  • 立場を意識する
  • 数字を想定する

ということが大事と思っています。

プロジェクトの内容を書いたら、あなたがどう関わったかも書かなくてはなりません。

例えばプロジェクトマネージャ試験で、あなたがどういう立場で関わったか?それはやはりプロジェクトマネージャと書きたいです。実際の経験ではサブリーダであった場合は、傍にいたプロジェクトマネージャになったつもりで、プロジェクトマネージャとしてこのプロジェクトに従事したと書いてください。こう書くことで、気持ちも引き締まった感じがして、以降も自らがプロジェクトマネージャだったらどう動くかと考えながら論述できるのではと思います。

ITサービスマネージャの試験ならITサービスマネージャとして、システムアーキテクトの試験なら、アーキテクトです。変な遠慮で中途半端な役割とか書かなくていいです。ITベンダーに勤めているならば、開発プロジェクトや運用をお客様から請け負っていることが多いと思いますので、それはそのように書けばいいです。

論文試験において、具体的な数字を出すと説得力も高まります。いわゆる本論の設問イのところでも数字を出すととてもよいのですが、それは後述するとして設問アでも対象のシステムやプロジェクトの説明に数字を書いておくのがよいので、準備の段階で具体的な数字を想定しておきましょう。あまりに小さな規模のものや、品質の悪さが出てしまう数字になってしまう場合は少し盛ってもいいと思いますが、後の話しの整合性があるようにしっかりと考えてください。

準備する数字は受験する試験に合わせたシステム、プロジェクトの説明をするのに合ったものが必要です。例えば、ITサービスマネージャの試験で、テーブル数がいくつとか、何人月であるとか、利用している開発フレームワークとか説明しても意味ないです。運用を意識しているのですから、SLAをどのように交わしているのか等が重要です。

試験別のシステム・プロジェクトを説明時に使うといい数字は以下です。

ITサービスマネージャ運用サービスを提供するうえで重要となる数字SLA(稼働率、対応までの時間)
システムアーキテクト システムの構成、設計に関する数字システムの規模
(画面数、テーブル数、STEP数、サーバ数など)
プロジェクトマネージャ 開発などのプロジェクトの数字プロジェクトの人月
総コスト・利益
期間
ITストラテジスト 事業やシステム、計画や構想の数字システムや事業の売上・利益
取り扱い商品数
拠点数
利用者数
その現状と目標の数字

ITサービスマネージャの場合、設問アにおいては、是非とも書いたほうがいいという決め文句的なものがあります。平成26年度秋期試験ITサービスネージャの午後Ⅱ講評を見てください。

ここに『”ITサービスの概要”について、十分な内容を記述していないものが相変わらず見受けられた。』とあります。ITサービスの概要についての十分な内容って何でしょう?提供している機能?サービスを提供しているインフラ構成?いいえ、違います。ITサービスマネージャの試験においては、こう書けばよいです。

『…が提供しているITサービスは、インシデント管理、問題管理、変更管理、リリース管理、構成管理である。』

つまり、ITILの運用管理プロセスを列挙し、それをITサービスの概要として書いてください。

設問イ

設問イでは具体的な対策などの本論を書きます。

このために、論述するプロジェクトについて出題されそうなテーマにあわせて振り返り、準備しておく必要があります。経験したプロジェクトが論文に書けるほど、成功したといえないかもしれません。その場合は、もしココがこうなっていたらもっとよかったのになあとか、あれをやらなかったら失敗だったなあという反省を元に、実際の結果より少しいい結果に「盛る」のもありだと思います。

どのようなテーマが出題されるかはわかりませんが、前述したとおり試験毎にテーマはだいたい決まっています。過去問題を見るとわかりますが、プロジェクトマネージャなら進捗管理、外注管理、品質管理などです。論述できるプロジェクトが複数用意できればいいかもしれませんが、一つのプロジェクトで複数テーマを書けるように準備するのがいいでしょう。

そして、課題への対策のための行動やエピソードを部品的にネタとしていくつか用意しておきます。その部品の組み合わせ方で様々な出題テーマに対応もできると思います。

主題に対して、まずは一般論を記述するとよいでしょう。問題文にはそういった一般論がが記載されているので、その一部を写して記述すればよいのです。そこに教科書的な常識をさらに書き加えてもよいでしょう。

次に、それにあったあなたのプロジェクトでの行動を記述します。準備してきたネタを中心に書きます。できればプロジェクト固有の特色を書き、それにあわせて前述の一般論の中で特に重視した点などをかけるとよいでしょう。

対策を打ったら、それにより逆に高まるリスクに対する手を打っておくことも忘れずに書くと、引き締まった感じになります。そして、記述する時には ”~した。” と過去形を連発するより、時々敢えて ”~する。” といった現在形を混ぜると躍動感が出てよいと思います。

では、そういったネタを準備するヒントをいくつか書きます。

午前の用語を使う

午後の論文試験を受けるからには、その試験の午前の対策もしているはずです。そこで勉強して覚えた用語は論文の中でも使いましょう。同じ意味でも学習した用語を使うほうがスマートですし、知識があるというアピールにもなります。

例えばスケジュールの遅延に対して、要員を追加したりすることはクラッシング、先行タスクが完了する前に後続タスクを進める方法はファスト・トラッキングといいますが、そういった用語を記述の中で使いましょう。レビューもウォークスルーとかインスペクションといった表現を使ったほうがよいです。

重要な用語を覚えたら、その用語を使って論文のネタとして書くことができないか考えるのがいいでしょう。SWOTという用語を勉強したら、自分の会社、顧客、プロジェクトでSWOT分析をやってみましょう。そして、その結果を論文の本文中に入れてるとよいでしょう。

ただし、午前の試験にもまだ出題されないような新しい用語は使う必要ありません。基本用語を使ってください。

午後Ⅰの問題から持ってくる

今度は午後Ⅰです。その対策も行ってると思いますが、過去問題と解答をヒントに論文の事例にすることもできます。午後Ⅰの問題では担当者が設計や計画したことについて、上司がある指摘を行ったがその内容は何?というパターンの問題がよくあります。まさしくその問題の解答の行動を論文のネタに持ってくればよいのです。

午後Ⅰの過去問の解答だけでも見てください。平成28年度 秋期 ITサービスマネージャ試験の解答例では、

  • 『SLA違反となる前に対策がとれるよう、しきい値を目標値より下に設定する』
  • 『将来のサービスに対する需要とサービス利用者の見通しを営業部門から入手する』

と、解答だけ見ても行動的にヒントになりそうな語句があります。

午後Ⅰの過去問などを解いたら、そのケースや行動が自分のプロジェクトでの事例に近くないかを考えてみて、論文のネタとして考えてみましょう。

マネージャ視点の行動にする

ITサービスマネージャやプロジェクトマネージャはもちろん、これらの高度情報処理技術者での論文ではマネージャ視点での行動ができているか問われます。マネージャの視点って何でしょう?大げさに考えること必要はありません。説明、交渉、指示、調整などです。

関係部署や上層部などに説得したり交渉したり、調整をお願いしたり、などを含めるだけでもいいです。

難局を乗り越えるために、実力のある自分が自ら手を動かしたというより、チームのメンバーにやってもらえるように指示したり、指導したり、ルールを作ったりしたと記述したほうが評価されます。

プロジェクトでのKPIを取得しておく

前の項でもでも述べましたが、数字を書くことは重要です。設問イの中では実施した対策について効果があることを示すために数字を出すことが説得力あり、有効です。利用する数字は斬新なものである必要なく、教科書でKPIとして取得するべきというものでよいです。

  • ITサービマネージャなら各ITILプロセスの中での各指標。サービスデスクの応答時間や変更管理の緊急の変更発生件数など
  • システムアーキテクトならバグの発生率や検出率、プロジェクトマネージャなら進捗率など
  • ITストラテジストなら在庫回転率とか○○当たりの売上高など、経営に結びつく数字

KPIを設定してその数字を監視している時点でまずポイントアップです。さらに、それらを改善するために行動し、その数字が良くなったというストーリーだとさらに説得力あります。そのストーリーの中で使う数字を具体的な値まで書けるように、準備しましょう。KPIの取得をしていなければ、それらを測定していたらどのような数字になりそうか、想定してみましょう。教科書的なものなので、測定していなくても、想定するのはそれほど難しくはないはずです。実際の数字があまりよいものでなければ、どうすればよくなったかなということを考えつつ、”盛って”良い数字に変えてもよいと思います。

  • 『サービスデスクのエスカレーション率が、約40%と他システムに比べて高かった。調査してみるとFAQのシステムはあるが、そこにいくつか問題があり… それを解決することで10%に改善された。』
  • 『私は、システム全体の品質を設計工程での品質向上が重要と考え、設計書のウォークスルーを実施した。上流工程(設計段階)で不具合を検出するほうが、下流工程(テスト段階)で検出するより、手戻りの工数が少ない。その結果、結合テスト段階において、発生した不具合は、他のサブシステムに比べて20%ほど少なかった。』

簡単なレベルの例ですが、実施する対策も難しいことでなく教科書的なことでよいです。教科書的な対策を”実施した”と書くだけでは足らないので、その裏付けや補足として数字を書くがアピールになり、効果を具体的に表現できます。

設問ウ

設問ウは一般的に振り返りです。

プロジェクトなどが100点満点で終わることなど、それほどないでしょう。全体的には80点として、残りの20点は何だったのかを書きます。”今回とった対策は、概ね計画通りに成果を挙げることができた。しかし、以下の課題が残った… “という感じで。

残りの課題ですが、大きくなりすぎないようにしましょう。課題が大きいと、成功じゃないよと評価されてしまうかもしれません。

プロジェクトの要素は、品質、コスト、納期で、それらはトレードオフとなります。どれかがなんらかの事情で達成できなかったというように書くのがよいでしょう。しかし、その中で品質が犠牲になることは、あまり成功している感じはしません。コストもはっきりとした事情があったり、取り戻したりできていればいいのですが、マネージャでとして優秀な感じがしません。

当初の予定の一部分だけが、納期に間にあわなかった。しかもあまり重要でなかったり、運用でカバーできたり、というのがいいと思います。現在は運用でカバーしていると、残りのその部分に対して開発や改善を計画または実施中と締めれば最もよいかと思います。

おわりに

以上、大したことはかけませんでしたが、何かのヒントになると幸いです。繰り返しになりますが、情報処理試験の論文は、最初に書いたとおり、そんなに難しいことを書く必要はありあません。教科書通りのことを書いていればよく、ポイントを外さなければ、合格することができます。

次回(があれば…)は、もう少し具体的な文例をいくつか出したいと思います。

この会社に入ってから、プロジェクトマネージャ、ITストラテジスト、ITサービスマネージャと合格することができたのですが、その元ネタとなった仕事はプロジェクトの中で、それなりにいい立ち位置で働くことができたからかなとも思ってます。論文記述にあたっては前述のような方法を使って盛りましたけど、二次受けはまだしも、三次受け、四次受けといった位置でのプロジェクトへの参画では、こういうものを書くのは難しいかもしれません。当社では、論文書くためのネタも集めやすい(もちろん、そのために仕事しているわけではないですが)仕事がちゃんとありますので、一緒に仕事してみたいと思ってくれた方は新しい仲間の募集も行っておりますので、ぜひご検討ください。

論文の試験では、鉛筆と消しゴムが必要になります。鉛筆はともかく、社会人になってから消しゴムって使わないですよね。試験会場は、学校になることが多いと思います。黒板や机、掲示してある紙といった教室の雰囲気を感じ、消しゴムと鉛筆を使って試験を受ける。そうすると、若かった自分の何かを思い出せるでしょう。それもいいと思いませんか。がんばって試験会場に足を運びましょう。

  • 株式会社アークシステムの予約・来訪管理システム BRoomHubs
  • 低コスト・短納期で提供するまるごとおまかせZabbix