ITサービスマネージャ試験の合格論文答案の書き方

はじめに

2013年の情報処理技術者試験の「ITサービスマネージャ試験」に合格しました。

本エントリでは、私が2013年の本試験で作成した合格答案(A評価)の書き方について説明します。

また、次のエントリで、2012年の試験で作成した不合格答案(B評価)の分析をします。

その他の試験区分の論文エントリは[情報処理]タグからどうぞ

論文答案の書き方

まず最初に標準的な午後2の論文答案の作り方について説明します。

基本的な論文作成のお作法は他の論文系試験と同じで、一言で言うと「答案構成を作って、構成通りの答案を作る!」という方法です。

答案構成というのは、問題提起と理由、結論をまとめた論文答案の骨子です。章題を並べたいわゆる「目次」とは違います。

論文の書き方をもう少しブレイクダウンすると、次のようになります。

  1. 設問から採点基準を漏らさず抽出する。
  2. 採点基準に沿って、問題文から論点を構成する。
  3. 論点をつなげて答案構成を作成する。
  4. 答案構成通りに論文答案を作成する。

論点と言うのは配点ポイントのことで、要は「問いに対する答え」です。

この論点を積み上げて答案を作成します。詳細は後述します。

参考書

まず準備として過去問題集を買います。

私は翔泳社の情報処理教科書を使いました。この本の解説にある「論文構成」というのは「答案構成」とほぼ同じなので、上記の解き方を実践して答え合わせするのにぴったりです。

この本は過去問解説だけでなく、勉強法、試験対策全般を網羅したオススメ参考書です。

出題の傾向

2012までは、資源管理かインシデント管理のどちらかに決め打ちして対策していれば良かったのですが、2013年は複合的な問題が出題されるようになりました。

ただ、この2つの分野が重要なのは変わりませんので、特に資源管理をメインにやっておけば、あとはプラスアルファの知識で論文試験は乗り切れます。というか乗り切れました。
(詳しくは情報処理教科書の出題傾向参照。)

問題の選択

実際の本試験の午後2では、2問の中から1問選んで解答するのですが、選択すべき問題は「書けるネタをたくさん持ってそうなもの」を選びます。

ネタさえ持っていれば実際に経験してなくてもいいですが、大抵「具体的に」と言われるので、経験したシステム・サービスの方が具体的なネタを書きやすいというのは言わずもがなです。

例題

今回は、私が前回本試験で解いた2013(H25) - SM - 午後2 - 問1を例に説明してみたいと思います。

以下、問題文全文。

問1 サービスレベルが未達となる兆候について

  サービスレベルについて顧客と合意し、合意したサービスレベルを遵守することは、ITサービスマネージャの重要な業務である。サービスレベルを遵守していくためには、サービスレベルが未達となる兆候に対して適切な対応を図ること(以下、兆候の管理という)が重要となる。

 兆候の管理に当たっては、まず、監視システムやサービスデスクなどを通じて、システム資源の使用状況や性能の状況、利用者からの問合せ状況などの情報を幅広く収集する。

 次に、それらの状況の変化や傾向などを分析するとともに、過去の事例も参考にしながら、サービスレベルが未達となる兆候であると認識した場合には、原因を究明して適切な対策を講じる。

 また、兆候の管理を効果的に行うためには、関連部門と連携することによって、さまざまな情報を多面的に分析するなどの工夫が重要である。さらに、兆候の管理を行う仕組みを継続的に改善していくことも必要である。。

 あなたの経験を考えに基づいて、設問ア~ウに従って論述せよ。

  • 設問ア あなたが携わったITサービスの概要と、兆候の管理の概要について、800字以内で述べよ。
  • 設問イ 設問アで述べた兆候の管理において、サービスレベルが未達となる兆候及びそのように認識した理由と、サービスレベルを順守するために実施した地策及びその結果について、800字以上1,600字以内で具体的に述べよ。
  • 設問ウ 設問アで述べた兆候の管理を効果的に行うための工夫と、仕組みの改善について、600字以上1,200字以内で具体的に述べよ。

問題は、大きく、タイトル、問題文、設問の3つから構成されています。

タイトルは「サービスレベルが未達となる兆候について」という部分で、問題文はその下から設問の手前までの文章、設問は設問ア~ウに書いてある文章のことです。

説明の便宜上こう分けます。

1.設問から採点基準を漏らさず抽出する。

設問から採点基準を漏らさず抽出します。

これは設問に線を引いて、どこでどんなネタを使うかを考えます。そして、解答の目次の大枠も決めますが、そんなにスッキリとは行かないので"およそ"で。

設問の流れから解答の目次を再構成すると、採点者にも採点しやすい構成になるので、なるべく設問のままで。

設問ア
  • あなたが携わったITサービスの概要が書かれている
  • そのサービスの兆候の管理の概要について書かれている
  • 上記の内容が800字以内で書かれている
設問イ
  • 設問アで述べた兆候の管理においてサービスレベルが未達となる兆候及びそのように認識した理由が書かれている
  • サービスレベルを遵守するために実施した対策及びその結果が書かれている
  • 上記の内容が800字以上1,600字以内で具体的に書かれている
設問ウ
  • 設問アで述べた兆候の管理を効果的に行うための工夫が書かれている
  • 仕組みの改善について書かれている
  • 上記の内容が600字以上1,200字以内で具体的に書かれている

これが採点基準の大枠です。(もちろんほんとの採点基準なんて知らないので、私の予想です。)

2.採点基準に沿って、問題文から論点を構成する。

前項で抽出した採点基準に則した論点を問題文から構成します。

論点というのは、採点基準を充たす問題提起、理由と結論、起承転結などで構成される配点ポイントのことです。

端的に言うと「問いに対する答え」です。必要な論点を書き忘れる=論点落ちすると配点されないと考えられますが、だからといって書きすぎて時間がなくなったり、記述が設問の要求するレベルに達してない場合(たとえば具体的じゃない、とか)も配点されないので、注意が必要です。

設問ア
(1) ITサービスの概要

ITサービスの概要を書きます。

情報システムの機能について書くのではなく、ITサービスについて記述します。

私の場合、主に以下のサービス概要を記述しました。

  • 商社向けの販売システムの運用・保守サービスを提供していること
  • 一定のサービスレベルで顧客と合意してること
  • 販売システムは会社の経営を左右する大事なシステムであること
(2) 兆候の管理の概要

兆候の管理の概要について書きます。

問題文にある「監視システムやサービスデスクなどを通じてシステム資源の使用状況や性能の状況、利用者からの問い合わせ状況」というキーワードを軸に、兆候の管理の概要について説明します。

私の場合、以下の2点で管理していると書きました。

  • ①監視システム:ディスクやメモリの使用状況やバッチの実行時間がしきい値を超えたらアラートを発した場合
  • ②サービスデスク:ユーザからパフォーマンスに関する問い合わせが来た場合

あくまで「概要」なので、大展開しないこと。

設問イ
(1) サービスレベルが未達となる兆候その理由

サービスレベルが未達となる兆候とその理由について書きます。

設問ア(2)で書いた管理項目から兆候を発見したという流れで書きます。

私の場合、以下の兆候を書きました。

  • 年度末にバッチの実行時間が長くなってしきい値を超えてアラートが発生したため
(2) サービスレベルを遵守するために実施した対策及びその結果

サービスレベルを遵守するために実施した対策及びその結果について書きます。

問題文にある「それらの状況の変化や傾向などを分析するとともに、過去の事例も参考にし」というキーワードを軸に、原因と対策、結果を説明します。

私の場合、傾向の分析は特に思いつかなかったので、状況の変化・過去の事例をもとに原因・対策を立てたと書きました。

  • 過去の事例:前年の事例を参考にするため、前年の業務報告を参照した
  • 原因:データの急激な増大
  • 対策:ディスク、メモリの増設、インデックスの再設計
  • 結果:バッチのパフォーマンスが向上し、実行時間が短くなり、アラートがなくなった

ありきたりで当たり前なストーリーですが、「きちんと兆候の管理をしたことで、兆候を発見することができたから、事前に対策を打つことができた。その結果、合意したサービスレベルを遵守できたという流れ」が大事なので、兆候自体はありきたりなもので全然構わないというか、無理に派手なストーリーを展開すると自爆します。

設問ウ
(1) 兆候の管理を効果的に行うための工夫

設問アで述べた兆候の管理を効果的に行うための工夫について書きます。

問題文にある「関連部門と連携することによって、様々な情報を多面的に分析するなどの工夫」というキーワードを軸に、工夫を説明します。

私の場合、インフラ部門と連携して、他のシステムの状況を分析したという話を展開しました。

  • インフラ部門と連携
  • 他のシステムのハードやソフト、業務、データ量などを比較・検討して多面的に分析
(2) 仕組みの改善

兆候を管理するための仕組みの改善について書きます。

問題文にある「兆候の管理を行う仕組みを継続的に改善していく」というキーワードを軸に、改善内容について説明します。

私の場合、継続的というと定期連絡会を開いて情報交換するぐらいしか思いつかなかったので、そう書きました。

  • インフラ部門と定期的に連絡会を設ける
  • パフォーマンス異常の兆候を定期的に確認する

と、ここまでに次の答案構成でやる内容をほとんど書いちゃってますが、実際に論点抽出でやるのは、問題文に線を引いたり、対策とかを頭で考えてメモする程度です。

本試験で私が実際にやった論点抽出という線引き・メモ作業はこんな感じでした。見にくいですが。(写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。)



設問ア~ウまでざっと見て、問題文から論点の抽出漏れがないか確認します。なければ答案構成の作成です

3.論点をつなげて答案構成を作成する。

論点抽出時のメモ書きを「答案構成」という形で問題用紙の[メモ用紙]というページにきっちり書き起こすというのが、この「答案構成の作成」というプロセスです。

大事なのは、全体を見て分量を調整したり、流れを阻害する要素がないかを考えて論点を取捨選択することです。

要は論点抽出のまとめですが、こんな感じに箇条書きに起こします。これがそのまま論文答案の答案構成になります。

設問ア
(1) ITサービスの概要
  • 商社向けの販売システムの運用・保守サービスを提供していること
  • 一定のサービスレベルで合意してること
  • 販売システムは会社の経営を左右する大事なシステムであること
(2) 兆候の管理の概要
  • ①監視システム:ディスクやメモリの使用状況やバッチの実行時間がしきい値を超えたらアラートを発した場合
  • ②サービスデスク:ユーザからパフォーマンスに関する問い合わせが来た場合
設問イ
(1) サービスレベルが未達となる兆候その理由
  • 年度末にバッチの実行時間が長くなってしきい値を超えてアラートが発生したため
(2) サービスレベルを遵守するために実施した対策及びその結果
  • 過去の事例:前年の事例を参考にするため、業務報告を参照
  • 原因:データの急激な増大
  • 対策:ディスク、メモリの増設、インデックスの再設計
  • 結果:バッチのパフォーマンスが向上し、実行時間が短くなり、アラートがなくなった
設問ウ
(1) 兆候の管理を効果的に行うための工夫
  • インフラ部門と連携
  • 他のシステムのハードやソフト、業務、データ量などを比較・検討して多面的に分析
(2) コントロールの妥当性のチェック
  • インフラ部門と定期的に連絡会を設ける
  • パフォーマンス異常の兆候を定期的に確認する

細かく書くとたぶん時間がなくなるので、実際は自分で判るキーワードを箇条書きする程度で十分かと思います。

本試験で実際に私が作った答案構成はこんな感じでした。見にくい上に字も汚いですが。(写真をクリックして「オリジナルサイズで表示」をクリックすると拡大して表示できます。)

4. 答案構成通りに論文答案を作成する。

答案構成が完成したら8割完成です。

時間的には逆で、ここまでで40分、残りの80分で答案構成の通りに答案を書ききります。

この時間配分については、本試験開始直後に、答案構成の隅に時間配分を書いてました。

14:30-15:10 答案構成
15:10-15:30 ~800文字
15:30-16:00 800文字~
16:00-16:30 600文字~

これを書いておくのは途中で「時間がない!」ということになった場合に論点切りをしてでもウにたどり着けるようにするためです。

書いてる途中でタイムアップするとか、最低字数を満たせないというのが最悪のパターンなので、それを回避するために時計をチェックしながら、ひたすら書き続けます。

なお、答案作成中にあれ?この論点落としてね?というのに気づいても、極力止まらずに書ききります。別のネタを思いついたり、なんか微妙に書き間違っていても、書いてる途中に答案構成を変更するのは危険です。

そのレベルの変更をするなら、答案構成時にきちんとやっておくことです。

ここまで来たら、何も考えずに機械のように書ききることが大事です。

書き終わったら

最後まで書ききったら、受験番号とか選択した問題に○を付けてるか確認して、時間のある限り誤字脱字とかをチェックします。

ここまで来たらもう汚い字を書き直すぐらいで、答案構成を変更するようなことは無理なので諦めます。

この答案構成例について

なお、この答案構成例は優秀答案でもなんでもなく、私が前回の本試験時に作った答案構成を再現したものです。

おかしいところや甘いところ、記憶違いなところもありますが、「本試験の時間だとこれぐらいのことしか書けないのか」、「っていうかこの程度の解答でA評価なのか。。。!?」という感じで参考程度に見ていただければと思います。

問題集の答案例とか答案集の優秀答案って「こんな量、2時間で書けねーよ!」ってのも多いので。。。

普段の午後2の練習

普段、午後2の問題を練習で解くときは、答案構成のみ作って論点漏れしてないか確認する程度で十分かと思います。

ただし、最低一回は答案を最後まで作成して書く練習をしないと、時間配分ができません。

2時間で3,000文字近く書く感覚を掴んでおく必要があります。

できれば勉強の一番最初にやっといて、あとは問題の量をこなすようにすると、2時間で書ける量しか答案構成しないように訓練できるので効率的です。

午前と午後1は?

なお、午前と午後1については、問題集を買ってたくさん解けば十分だと思います。

午前は、きちんとやるなら新試験の高度午前を網羅した情報処理教科書 高度試験午前Ⅰ・Ⅱオヌヌメ

あと、本試験で午前や午後1がメタメタだった時も、午後2を無料模試と考えて受けましょう。これ一回やると、2時間の短さが本番さながら(っていうか本番w)で経験できるのでオヌヌメです。

採点基準について

採点基準については予想するしかないですが、それを考えるヒントになるのが試験後に公表される採点講評です。例えば、H25秋のIPAの採点講評.PDFは以下の通り。

 昨年度は設問で要求していない事項についての論述が多いと指摘したが,本年度は設問で要求している事項に答えていないものが少なからず見受けられた。設問をよく読み,何について解答することが求められているかしっかり把握した上で,論述に取り組むよう改めて注意を促したい。
(太字は私の加筆。以下同じ)

問題文を読んで、問題に答えましょうということですね。論文試験と言えども試験問題なので、設問と関係ない話を書いても一点にもならない、ということです。気をつけましょう。

 また,設問アの“あなたが携わったITサービスの概要”で,システム構成,アプリケーション機能,顧客ビジネスなどの説明に終始するものが相変わらず見受けられた。ITサービスについて記述する必要があることを再度注意しておきたい。

ITサービスマネージャ試験特有の話として、システムやプロジェクトの話ではなく、ITサービスの話を書かないといけません。この起点が失敗するとたぶんあとは全部ダメになります。ITサービスとは何か、を書けるようにしておきましょう。

 問1(サービスレベルが未達となる兆候への対応について)では,顧客と合意したサービスレベルが未達となる兆候について,認識した兆候とサービスレベルを遵守するために実施した対策,管理を効果的に行う工夫と仕組みの改善などについて論述することを求めた。

問題文で問われていることを答えないといけません。

試験問題ですから当たり前ですが、論述試験ではつい自分の経験を書きすぎてしまい、問題文から外れてしまうことが多いので、気をつけましょう。

サービスレベルの維持活動は受験者にとってなじみのあるテーマのようで,不断の情報収集と的確な分析によって兆候を認識したことが伺える良質な論述が見受けられた。しかし,兆候と認識した理由が不明なものや,単なるインシデント対応についての論述が少なからず見受けられ,兆候の管理を確実に実施している受験者は多くはないと推測される。

論述のネタを選ぶときは、「問題文から離れてないか」をしつこく検討しないと、インシデント対応みたいな関係ない話を書いてしまいます。

また,効果的に管理する工夫では問題文の例を引用しただけで,実経験に基づいているのか疑わしいものも見受けられた。これは,ITサービスマネージャとして効果的な管理に注力した経験がないことに起因するものと推察される。兆候の管理は,サービスレベルを遵守するための有効な方策の一つである。管理プロセスの確立と継続的な改善に積極的に取り組むことを期待したい。

問題文に沿って論述することと、問題文のコピペは紙一重なので、題意の範囲内でなるべく具体的に書く訓練をしましょう。


以上、前編の合格答案作成編でした。後編ではB評価の不合格答案の検討・分析をしてみたいと思います。