読者です 読者をやめる 読者になる 読者になる

『ギブス』で学ぶITサービスマネージャ試験

秋期情報処理試験、ITサービスマネージャに合格しました。
論文式試験って敬遠されがちですが、意外とイケるよって話をします。

1.論文の合格率は低くない

SMer自体の合格率は10%代ですが、内訳を見ると
午前2・午後1・午後2(論文)それぞれで約50%、0.5の3乗で0.125になってるイメージです。
そして、午前2・午後1に関しては、完全に過去問通りのパターンが大半です。
(このへんの通過率が低いのは、実務経験が豊富な論文に自信ニキが、油断して「過去問解答暗記」「形式への慣れ」を怠っているためだと思います。)
IPAのサイトに全年の問題・解答・講評が載っているのでこれを確認すればまず6割は行きます。
※参考書は不要*1ITILの専門知識ももちろん不要*2です。

2.論述は書き上げるのが難関

周りの話を聞いていると、やっぱり文字数が多い人ほど受かっています。
3000字超えると落ちたという話はあまり聞きません。

それでも、2時間で「問題を読み込んで、3000字の論文を手書きで仕上げる」というのは至難です。
それはきっと、論文の内容で客観的に甲乙をつけるのなんて難しいから、
「半分くらいの人しか書き上げることができない」レベルの文字数・時間設定を施して、
そこで合否の差を付けようとしているのだと思います。
逆に言えば、とりあえず3000字書き上げちゃえば合格ラインに乗るわけです。
簡単ですね。

3.論述は「400字レベルの定型パターン」を丸暗記して、5〜6個組み合わせて作る。

「書き上げればよい」とは言っても、やっぱりキツいです。
問題文の読み込みに30分・3000字を書く物理的な時間で30分掛かるとすると、
3000字分の内容をたった1時間で考えなきゃいけない訳です。厳しい!
そうなると、「どんなケースでも対応できる、数百字の定型パターン」を10個くらい覚えておいて
積み木スタイルでくっつけていくのが一番妥当になります。

定型パターンの素材としては、

ITサービスマネージャ 合格論文事例集 第4版 (論文事例集シリーズ)

ITサービスマネージャ 合格論文事例集 第4版 (論文事例集シリーズ)

これ1冊で完璧です。

あとは基本の雛形は、椎名林檎の『ギブス』に合わせていきます。
具体的に見ていきましょう。

あなたはすぐに写真を撮りたがる

主体を明示しながら、課題を(主観・判断を交えず)事実だけで伝えます。
サービスマネージャ風に書くなら、
「インシデント対応やサービスデスク業務を担うA社オペレーションチームは、ユーザ側との折衝の手間を敬遠し、独自の基準でインシデント対応を行っていた」くらいになります。

あたしは何時も其れを厭がるの

サービスマネージャとしてその事象を課題と捉えていることを明示します。
「A社サービスマネージャである私は、その状況を好ましくないと判断した」くらいになります。

だって写真になっちゃえば あたしが古くなるじゃない

課題を設定した根拠を明示します。
「その理由としては、オペレーションの属人化を招き重大なインシデントが発生した際にサービスレベルが未達となるリスクが高いと考えたためである」くらいになります。

あなたはすぐに絶対などと云う

課題を解決しようとした際、ボトルネックとなる事象を、主体を明示して明確にします。
「オペレーションチームは、ITリテラシーの高くないA社情報システム部がオペレーション内容にまで指示をすることは、コミュニケーションロスの増大を招くと主張した」くらいになります。

あたしは何時も其れを厭がるの

サービスマネージャとしてその事象を課題と捉えていることを、再び明示します。
「そうした状況はインシデント発生時のリアクティブな対応の円滑化を妨げるだけでなく、インシデントを未然に防ぐプロアクティブな対応を創出しえない環境であると判断した」くらいになります。

だって冷めてしまっちゃえば 其れすら嘘になるじゃない

「判断」の後にはかならず根拠を明示します。
「その理由としては、プロアクティブな対応を提案するにあたっては複眼的な考察が不可欠であり、オペレーションチームからだけの視点では不十分であると判断したためである」くらいになります。

don't U θ ink?  i 罠 B wi θ U 此処に居て

どのような対応を取ってほしいか明示します。
「そこで私は、オペレーションチームとA社情報システム部の間で月次の業務改善会議を開催することを提起した」くらいになります。

ずっと ずっと ずっと

期間も明示します。
「次期クライアントリプレイスが予定されている2年後の3月まで」くらいになります。

明日のことは判らない

一般論・理想論にも軽く触れます。
「システムを取り巻く環境は刻々と進化しており、今日動いたシステムが明日稼働する保証はない。問題がないからといってこれまでの方法で終始するのではなく、新たな手法を積極的に取得するよう心掛けるべきである」くらいになります。

だからぎゅっとしていてね ぎゅっとしていてね

取るべき対応を、換言してもう一度強調します。
「ユーザと運用側が意思共有を行い、アイディアを出し合う土壌が必要である」くらいになります。

ダーリン

対策を取るべき主体を明示します。
「オペレーションチームのリーダであるB氏に」くらいになります。

こんな感じで枠組みだけを覚えておけば、サッと書けると思います。

結論:論文だからと敬遠するのは損かも。
   +論文の書き方相談、いつでも乗ります。

*1:何冊か立ち読みしましたが、本当にどれも大したこと書いてねーです

*2:ITILにベッタリしすぎると、「わざわざ税金使ってやってる国家資格なのに、ベンダ資格と変わんねーじゃねーか」となって、存在意義が失われる事情があるそうです