論文試験に楽々合格サイトの掲示板

重点対策　2012

ITECさんより発売されるようです。
ITECさんのサイトでは5月15日。店頭やamazonではもう少し先のようです。

[582]　管理者　(2012/05/12 Sat 03:28)

システム監査　H23　問2

お世話になります。yh0807です。
度々の投稿失礼いたします。

前回ご指摘頂いた点を参考に、２時間の時間を区切って別の論文に挑戦してみました。
試験まで残りわずかですが、何かご指摘等頂ければ幸いです。

自分で書いてみて思ったのですが、「〜の仕組みがある」という監査は書きやすいのですが、「〜の仕組みが整備されていない」という論文は書きづらいかなと感じました。
以下の論文では、規程が整備されていない、規程外で運用している実態も無いことが監査手続で判明したとしましたがこの点が自信が有りません。
本番では、「〜の仕組みがある」の方で書いてみようと思います。

------------------------------------------------------
１、組織の概要とベンダマネジメント
１−１、組織の概要
　私はシステム開発業のＡ社の内部間さ質に在籍している。Ａ社では、金融業・飲食業・販売業など、顧客とする業種別に事業本部が有り、事業本部の中で、さらに細かい顧客の種別により３〜５の部が有る。ひとつの部には20〜50人程の社員が在籍しており、受注した案件の規模に応じた人数をアサインしてプロジェクトが発足する。プロジェクトが大規模になる際は、派遣会社とプログラムの派遣契約を結び、百人以上の規模でプロジェクトを行うことも有る。
　また、開発を行う事業本部の他に、総務、経理、購買部門を含むスタッフ本部も存在する。
１−２、ベンダマネジメントの状況
　Ａ社では、プロジェクト内の情報共有を目的として、ＡＳＰやＳａａＳを利用したスケジュール共有ポータルや、ファイル共有、アプリケーションの利用を行っている。
　これらのサービスの利用は、各事業本部で自由に行っており、特定の部門が管理を行ってはいない。
　利用の流れとしては、プロジェクトでサービスの利用が必要になると、プロジェクトマネージャ（以下ＰＭという）が、ネット検索やダイレクトメールから利用したいベンダを自由に選定する。ベンダ選定後は、ベンダ名、利用サービス内容、予算を記載した申請書をＰＭが事業本部長に申請する。申請が承認されると、事業本部長を責任者として、ベンダと契約を締結する。
　Ａ社の経営会議では、ＩＴ統制の観点からベンダサービスの利用を、組織横断的に管理する必要が有ると考え、監査するよう指示した。内部監査室内にベンダマネジメントに関する監査チームが発足し、私がそのリーダーに任命された。

２、ベンダマネジメントの問題点とリスク
２−１、ベンダマネジメントの問題点
　Ａ社のベンダ利用においては、コスト削減の意識から安価なサービスが多く選定される傾向にある。一方、サービスの質についてはあまり重視されていない傾向がある。
　具体的に、以下の様な点が十分に検討されないという問題点が存在する。
(1) 情報漏えいに対するセキュリティ水準が検討されない
　Ａ社のプロジェクトで多く利用しているファイル共有などのサービスでは、ソースコードや、顧客の社内情報など、高い機密性が必要となるデータが多い。これらのアップロード時の通信が暗号化されているか、ブルートフォース攻撃による成りすましを防ぐためのアカウントロックなどの機能は有るか、サービスを提供しているサーバは物理的に隔離されているか、などが本来検討されるべきであるが、現状では十分に考慮されていない。
(2) サービスの稼働率に対する信頼性
　ベンダサービスが利用できなくなると、プロジェクト全体の作業に影響する。そのためベンダが保障しているサービスの稼働率や、過去の実績を検討する必要がある。
２−２、問題点から生じるリスク
　全章で述べたＡ社の問題点により、次の様なリスクが生じる可能性が高いと私は考える。
(1) 自社および顧客の機密情報の漏洩
　セキュリティ水準の低いベンダを利用した場合、サーバ設置場所への侵入者や、通信の盗聴が行われる可能性が高まる。その結果、ファイル共有のファイルや、スケジューラの記載内容から、Ａ社だけではなく顧客の機密情報が流出してしまう場合が想定される。
(2) サービスの停止による作業の大幅な遅延
　ＳａａＳによるアプリケーションを開発に利用している場合、サービスが停止すると、同一プロジェクト内の大部分のメンバーが開発業務を行えなくなる。また、ファイル共有を利用している場合も、作業に必要なファイルを取得することが出来なくなってしまう。その結果、プロジェクトの作業が大幅に遅延してしまうリスクが想定される。

３、組織横断的なベンダマネジメントの監査
３−１、監査の観点
　私は組織横断的なベンダマネジメントが実践されているか確認するにあたり、以下の観点を用いることにした。
(1) ベンダ選定時の評価基準が整備されているか
　利用しているベンダサービスが原因で前章で述べたリスクが顕在化しないようにするためには、Ａ社の規定しているセキュリティ水準やシステムの稼働率と、整合性の取れたベンダサービスを選定する必要が有る。そのためには、選定基準を各ＰＭや事業本部長の判断に任せるのではなく、社内で標準化された評価基準が存在している必要があり、これの整備状況を確認する必要が有ると私は考えた。
(2) ベンダの導入後の評価を情報共有する仕組みがあるか
　ベンダサービスの対応の品質については、例えばダイレクトメールでは24時間のサポートを宣伝していても、トラブル発生時に連絡すると、連絡を受理は24時間受付けても対応完了まで時間がかかるなど、実際に使用してみないと分からない部分も多い。その様な実際に利用した社員の意見を蓄積することで、使用してみないと分からないメリット・デメリットを検討時に参考に出来、会社全体として有効なベンダサービスの選定・利用が行える。そのため、ベンダ導入後に評価を行って社内で情報共有出来る仕組みが必要であると考えた。
３−２、監査手続
　３−１で述べた観点を確認する監査手続きとして、私は以下を実施した。
(1) ベンダサービス利用に関する社内規程の確認
　私はベンダサービス利用を含む外部との契約について記した契約規程と関連する細則を監査証拠として精査し、ベンダサービス選定時の評価基準が整備されているかと、ベンダ評価の情報を共有する仕組みが定められているかを確認した。しかし契約規程、細則ともに、申請から契約締結、契約終了までの手続きに関しては記されていたが、選定基準やベンダの評価などは定められていなかった。
(2) ベンダ評価に関するＰＭ・事業本部長へのインタビュー
　私は、規程に定められていなくても、ノウハウとしてベンダの評価を情報共有する仕組みがあるかについて、ＰＭ経験者と事業本部長の中からランダムに20人を選出し、以下の２点についてインタビューを行った。
・ベンダサービス利用前に、他プロジェクトでベンダを評価した情報を参考にしたか
・ベンダサービス利用中または利用後に、ベンダの評価を行ったか
　上記についての回答は、いずれも行ったことは無いという回答が多数であった。

　上記の監査手続きの結果を踏まえ、Ａ社ではベンダマネジメントが会社全体で組織的に行われていないことが明確となった。私はそれらを指摘事項として監査報告書をまとめ、経営会議に提出した。
　　　　　　　　　　　　　　　　　　　　以上

[577]　yh0807　(2012/04/13 Fri 19:42)

---

Re: システム監査　H23　問2

yh0807さん

精力的な勉強お疲れ様です。
前回に比べて格段によい論文だと思います。
時間もないですので、簡単にだけコメントします。

■見直し
明らかな誤字脱字があります。本試験でも2時間という制約がありますが、見直しの時間を5分でもいいからとりましょう。

■監査は経験豊富な方が受験
監査は他の論文に比べ、受験者の年齢層が高くベテランの方が受験されます。つまり、みなさんレベルが高いです。なので、監査でなければ合格論文かな？と思いますが、監査であればどうかな？というのが感想

■監査手続き
監査の試験なので、今回は設問ウの監査手続きが答案の肝になります。
が、実際の監査手続きの記述はかなり少ないです。監査の観点や監査の結果などを除く、本当の監査手続き部分に関してはとても少ないなと感じました。監査経験があれば、もっと詳しく書けるだろうと思われないかなと。

全体的には読みやすいですが、ウの監査手続きの内容が薄いかなと思います。

たいしたコメントができずにすいません。

[578]　管理者　(2012/04/14 Sat 09:45)

---

Re^2: システム監査　H23　問2

管理人様

ご指摘ありがとうございます。
自身でも１、２についてはあまり悩まずに書けたのですが、３は詳細なイメージが持てずに書くのに悩みました。
残り時間も少ないですが、教本などの参考論文を読んで、どの程度の詳細さで、どんな監査手続きを書けばいいかを再度確認して明日に臨みたいと思います。
２度も査読して頂きありがとうございました。

[579]　yh0807　(2012/04/14 Sat 19:28)

システム監査　H22　問１

お世話になります。yh0807と申します。
昨年こちらで添削頂いたのに不合格だったため、今年再挑戦です。

昨年受験時には、「海外拠点に対する情報セキュリティ」や、「ベンダマネジメント」など、テーマにばかり着目してそちらを詳細に書こうとし、経験が無くて慌ててしまったのが一番大きな敗因かと思います。

今年の論文記載時に気をつけた点は以下です。
・「私は〜考えた」と自分の考えであることを明示すること
・監査をする際に、「〜いるか(例：規程が整備されているかなど)」という視点・注意点と、それを確認する監査手続きを「監査手続きとして〜〜した」と、はっきり明記すること

以下の論文を読んで何かお気づきの点などご指摘頂ければありがたいです。よろしくお願いいたします。

-------------------------------------------------------
メールシステムのシステムテストの正当性に対する監査

１、情報システムの概要と業務への影響
１−１、情報システムの概要
　私はシステム開発業のＡ社の内部監査室に在籍している。
　Ａ社では、メールシステムを本社内のサーバルームに所有している。メールシステムは、メールの送受信を行うメールサーバと、メールデータを保存するディスク装置で構成されている。メールサーバとディスク装置はそれぞれ本番機とホットスタンバイの予備機がある。各メールサーバ上では監視プログラムが稼動し、以下２点の自動的な切替を可能にしている。
・ディスク装置本番機の障害の検知と、予備機への切替
・メールサーバ本番機の障害発生を予備機が検知し、予備機自身を本番機として切替
　なお、ディスク装置の本番機と予備機はデータのミラーリングを行っており、切替によるデータの欠落は発生しない。
１−２、業務に及ぼす影響
　Ａ社では主に以下の目的でメールシステムを利用している。
・顧客システムの開発に関する連絡や質問対応
・社外との受発注業務
・顧客システムからの定時レポートや障害アラートの受信
　そのため、メールシステムが使用できないと、受発注業務が滞ったり、顧客システムの障害を把握できないなど、社内だけではなく顧客にも大きな影響を与えてしまう。
　私はメールシステムの監査チームのリーダーに任命され、メールシステムの障害検知・切替機能について行われたシステムテストの内容を監査することとなった。

２、行われたシステムテスト
２−１、システムテストの体制
　Ａ社のメールシステムは、Ａ社のシステム開発部門内に開発チームを発足させて構築・開発作業を行った。
　メールシステムのシステムテストは、この開発チームの他に、運用・保守部門代表として情報システム部長と部員２名が参加した。
　Ａ社の開発規定に則って作成したシステムテスト計画で以下の手順が定められた。
(1) 開発チームと情報システム部で協議し、テスト項目一覧を作成する。また、開発チームリーダーと情報システム部長はテスト項目一覧を確認し、承認の署名を行う。
(2) 開発チームメンバーは、情報システム部員立会いの下でシステムテストを行い、テスト結果と担当者名をテスト項目一覧に記載する。
(3) 開発チームリーダーと情報システム部長はテスト項目一覧に記載された結果を確認し
証人と署名を行う。
　なお、システムテスト計画ではテストでバグが発見された場合は、問題点の対応後、�A〜�Bの手順を繰り返すことと定められた。
２−２、システムテストの留意点
　Ａ社のメールシステムの特徴は、構成要素のメールサーバやディスク装置に障害が発生した際、自動で予備機に切替えて、システムの停止が発生しない様に設計されている点である。この特徴については、特に入念なテストが必要であり、以下２点について留意することがシステムテスト計画に明記された。
・システムに障害が発生したことを正しく検知できること
・システムの障害を検知した際に正しく切替動作が行われ、システムが停止しないこと
　私はこの留意点がシステムテストの適切性を確かめる上で重要になると考え、これらを考慮した監査方法を立案することにした。

３、システムテストに対する監査手続き
３−１、システムテストの網羅性
　前章で挙げた留意点に対するシステムテストの適切性を監査するためには、システムテストは想定されるあらゆるケースを網羅しているかを確認する必要が有ると私は考えた。
　例えば障害の検知については、メールサーバがＯＳごと停止した場合、ＯＳは正常稼動しているがメールサーバのプログラムのみが停止している場合、接続ケーブルの断線などによりメールサーバとディスク装置で通信が行えないなど、複数の障害が考えられる。
　切替動作についても、切替後にメールサーバとディスク装置のどちらかのみ予備機になる場合と、どちらも予備機を使用する組合せが考えられる。
　システムを停止させないためには、これらのケースの全てが正常に動作する必要がある。これらを確認する監査手続きとして、私はテスト項目一覧を閲覧し、記載されているテスト項目が想定される全てのケースを網羅していることを確認した。
３−２、テスト結果の正当性　
　次に、テスト項目一覧に記載されている結果の正当性について監査を行った。
　一点目の確認事項は、テスト項目に該当する部分を設計・開発した開発チームメンバーがテストを行わず、他のメンバーが客観的にテストを行っているか、である。これについての監査手続きとして、設計書と開発時の作業管理表を、システムテスト項目一覧と突合せ、設計・開発の担当者欄に対応するテスト項目の実施者の氏名が記載されていないことを確認した。
　また、二点目の確認事項は記載されたテスト結果が情報システム部員も立ち会った正当なものであるか、である。その監査手続きとして、システムテストに参加した情報システム部員にヒアリングを行い、自身が立ち会ったテスト項目を全て回答してもらい、全てのテストが情報システム部員の立会いのもとで行われたことを確認した。
　これらの監査手続きにより、Ａ社のメールシステムは適切にシステムテストが行われたことが保証された。

[573]　yh0807　(2012/04/07 Sat 18:02)

---

Re: システム監査　H22　問１

yh0807さん

もうすぐ試験ですね。
添削しようとがんばったのですが、問題文の読み込みから入るとかなり時間がかかってしまいました。一日ひとりの添削が精いっぱいかなというのが感想です。

さてさて、私は監査に奇跡で受かったので正直言って、適切なコメントができているかはわかりません。参考程度とお考えください。
また、あえて辛口のコメントをしています。ご了承ください。

■１．採点基準１　項目の充足度
問われている項目に対する回答の充足度が薄いと感じました。

�@例えば、設問アでは、「業務・社会に及ぼす影響」をこたえるべきですが、「業務」への影響しかありません。メールシステムがあまり好ましくないかもしれません。問題文では「生産システム」や「受発注システム」などの基幹系のシステムになっており、メールなどの情報系のシステムは、重要度は落ちるかもしれません。
まあ、メールシステムで論述しても十分合格はできると思いますが。

�A設問イも同じです。
　問われているのはテストの内容です。なのに、体制や留意点をこたえています。

�B設問ウも同じです。
求められているのは、監査手続きです。ですが、監査手続きは最後の方でしか出てきません。実際には、ちりばめて書かれているかもしれませんが、わかりにくいです。
例えば、以下のようにすっきり書いてはどうでしょう。

-----ここから

　私は、必要な監査手続きとして、以下の2つを実施した。
(1)設計書と開発時の作業管理表を、システムテスト項目一覧と突合せ
　・・・
　理由、実施手順、監査のポイント、監査証拠などを記載する。
　※採点講評にこの点の指摘あり
(2)　システムテストに参加した情報システム部員にヒアリング
　・・・・
　(1)と同様
　
----ここまで

　
■２．採点基準２　具体性
　上記にも絡みますが、設問で問われていること以外の記述が多く、それで文字数を稼いでいる気がします。問われていることのみに限定すると、文字数が大幅に減るでのはないでしょうか。
　そうすると、具体的に書かないと文字数は増えませんし、採点基準や採点講評にあるような具体的で説得力のある論文になりません。
　例えば、設問イであれば、採点講評にあるような「単体テスト、結合テストなどを含めたテスト工程全体や、テストの実施手順」を書くのもよいでしょう。また、メールのテストであれば、障害試験だけでなく、「遅延時間」「ピーク時の処理性能」「障害時の切り替え時間」「SPAM検知率」「メール誤送信の確認や添付ファイルの暗号化などのセキュリティテスト」などなど、ほかにもたくさんあると思います。具体的に書かないと、「この人はわかっていないな」と思われてしまうことでしょう。
　
以上

勝手なことを書きましたが、気を悪くされないようにお願いします。
もう2回ほど書いていただければ、合格論文になるかと思います。

よろしくお願いします。

[574]　管理者　(2012/04/09 Mon 21:39)

---

Re^2: システム監査　H22　問１

お疲れさまです。すぎエモンです。
僭越ながら査読させて頂きました。

【良いと感じた点】
・「私の立場」が明快で分かりやすかったです。

・関わった部署や、作業担当が明確に記述されており、「誰が何を行ったか」
　がわかりやすかったですね。

・システムを簡素化して記述しており、分かりやすく説明しようという意思が
　読み取れました。

・難解な用語や、読みにくい文章が無く、すっきりと読みやすい文章であると感じました。

【気になった点】
・「なお、ディスク装置の本番機と予備機はデータのミラーリングを行っており、
　切替によるデータの欠落は発生しない。」という記述が冗長ではないでしょうか。

・「テストでバグが発見された場合」→「バグ」という言葉では範囲が狭く
　ならないでしょうか？この場合は「不具合」という書き方が無難なのでは
　ないかと感じました。

・採点講評で「監査証拠」が必要だと明記されています。なので、監査証拠は何か、
　どのような手順で監査を行ったのか、監査ポイントは何か、誰に対して監査結果を
　報告したのかなどが明確に記載されていると合格率が高くなると思います。

・採点講評によると「単体テスト」「結合テスト」などを含めたテスト全体工程や
　テストの実施手順についてなど、システムテストの位置づけや具体的な内容を
　説明する必要があったようです。この点をしっかりと記述すると合格に近づくのでは
　ないかと感じました。

【査読のポイント】
☆文字数は適切か？
　○設問ア〜ウまで問題ありませんでした。

☆設問で問われた事に忠実に答えているか？
　●設問アで要求されている「社会に及ぼす影響について」が記述されていません。
　●設問イでは「システムテストの内容」を中心に記述する必要がありますが
　　体制や留意点などを中心に記載しています。

☆問題文に書かれている内容に準拠しているか？
　●問題文は「生産システム、受発注システムなどの基幹系情報システム」や
　　「組み込みシステム」を想定しているため「メールシステム」では、
　　問題文への準拠性が低下するのではないでしょうか。

☆「私の考え」がしっかりと記述されているか？
　○「私はこう考えた」という記述がしっかりとされていました。

☆システム監査技術者の視点を守っているか？
　○「私がシステムテストを行った」などという初歩的な勘違いが無く
　　システム監査者の視点を守っていました。

[575]　すぎエモン　(2012/04/11 Wed 17:06)

---

Re^3: システム監査　H22　問１

管理者様、すぎエモン様

返信が遅くなり申し訳ありません。
査読頂き、ありがとうございます。

読み直してみて、ご指摘の様に監査手続きなどで、先に理由を羅列しすぎて何を言いたいのかが分かりにくくなっていたと感じました。

１−１についてシステムの概要の削りどころが理解できていない、論述した以外の指摘事項が存在してはいけないと思ってシステムの概要を詳細に書きすぎる傾向があり、残り文字数が少なくなった結果、１−２について十分な記述が出来ていないと思います。

そして、お二人とも２についてご指摘いただいていますが、お察しの通り、システムテスト未経験者です。
そのため、あえてこの問題に手を付けてみたのですが、お二人に指摘頂いている「内容」について、全く手が出ないという状態でした。
　そして、やっぱりメールシステムでは弱いですか…。業務でで関わっているのはメール・社内ポータルの運用で、辛うじて社内の営業支援システムの構築をしたぐらいで、生産システムや受発注システムに関する経験が全く無く、イメージできるもので書いたというのが現状です。

　とりあえず、残り僅かですが、せっかくご指摘頂いた内容を活かせるよう、本番までに教本を読むなどして未経験のシステム・業務にも対応出来る様準備を行います。

[576]　yh0807　(2012/04/11 Wed 23:05)

テスト前

がんばりましょう

[522]　です　(2011/10/13 Thu 08:04)

---

Re^3: テスト前

SPAM対策です。ごりかい願います

[572]　管理者　(2012/03/09 Fri 22:01)

試験結果アンケート2011

合格発表がありましたが、いかがでしたでしょうか。
試験結果に関するアンケートにご協力をお願いします。

※合否は問いません。

以下をコピーいただき、それぞれ回答をお願いします。
よろしくお願いします。

[試験結果アンケート]
◆１．スコアを教えてください。
◆２．何回目の受験ですか？
◆３．受験の動機は何ですか？
◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど
◆５．過去問は何年分を各何回実施しましたか？
◆６．最新技術の勉強はどれくらい行いましたか？
◆７．模試は受けましたか？また、受けた方が良いですか？
◆８．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？
◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
◆１２．合格に最も大切なのはズバリなんでしょう。
◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）

◆１４．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
◆１５．書籍などへの転載可否
　ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否
◆１６．最後に一言お願いします。

[556]　管理者　(2011/12/16 Fri 22:37)

---

Re: 試験結果アンケート2011

[試験結果アンケート]
◆１．スコアを教えてください。
午前�T得点 ***.**点 （免除でした）
午前�U得点 80.00点
午後�T得点 76点
午後�U評価ランク A

◆２．何回目の受験ですか？
1回目

◆３．受験の動機は何ですか？
スキルアップのため

◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど
ITEC社のITサービスマネージャ「専門知識+午後問題」の重点対策

◆５．過去問は何年分を各何回実施しましたか？
午前のみ2年分を3回

◆６．最新技術の勉強はどれくらい行いましたか？
全くしていません。

◆７．模試は受けましたか？また、受けた方が良いですか？
受けてません。

◆８．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？

午後１：問1と問3
　　　　問題をざっと読み、直感で解けそうな問題を選択
午後２：問3
　　　　ＩＴサービスの改善活動についての問題で、具体的に書きやすそうだと直感で選択

◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
合格できた理由は最後まであきらめなかった事です。
来年合格する事が目標だったので、今回受かろうとは思わず次につながる試験にしたい、
自分のベストをつくそうと思った事です。

◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
論文が難関だと思いますが、サンプル論文をみてあきらめない事だと思います。

◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
参考書にある論文が素晴らしい内容なのは、プロが何時間もかけて書いたものだから。
自分が書く論文とは違ってあたりまえだと、何度も自分に言い聞かせました。

◆１２．合格に最も大切なのはズバリなんでしょう。
継続は力なり。コツコツ自分の課題をクリアして行く事だと思います。

◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
私にとっては自信です。
論述が公に認められたという事は、自信につながります。

◆１４．あなた様について教えてください。
職種や主な保有資格、可能であれば年代など
職種：システムエンジニア
主な保有資格：情報セキュリティアドミニストレータ、情報セキュリティスペシャリスト、第１種情報処理技術者

◆１５．書籍などへの転載可否
ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否
転載可能

◆１６．最後に一言お願いします。
今回の試験は、”ITサービスマネージャ「専門知識+午後問題」の重点対策”に
めぐりあえた事で、効率的に勉強できました。
勉強時間は正味20日間でしたが、論文が全く書けない状態から合格できたのは、
この本のおかげです。ありがとうございました。

[557]　ケリー　(2011/12/17 Sat 01:31)

---

Re^2: 試験結果アンケート2011

こちらのサイトの内容も大変参考にさせていただきましたので、協力いたします。

[試験結果アンケート]
◆１．スコアを教えてください。
午前�T得点 ***.**点（免除です）
午前�U得点 72.00点
午後�T得点 91点
午後�U評価ランク A

◆２．何回目の受験ですか？
２回目

◆３．受験の動機は何ですか？
自分自身のスキルアップ。論文系取得の１つ目として。
午前１免除の間にいろいろ受けようと思っていた。

◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど
a.東京電機大学出版局の「ITサービスマネージャ試験午前 精選予想500題試験問題集」
b.ITEC社の「徹底解説ITサービスマネージャ本試験問題」
c.翔泳社の「情報処理教科書 ITサービスマネージャ」
d.ITEC社の「ITサービスマネージャ「専門知識+午後問題」の重点対策」
e.ここのサイト

◆５．過去問は何年分を各何回実施しましたか？
午前は、５年分を３回以上（上記aの問題は数知れず）
午後は、上記c,dで採用されている問題を２回。

◆６．最新技術の勉強はどれくらい行いましたか？
特別なことはやっていない。

◆７．模試は受けましたか？また、受けた方が良いですか？
受けていない。
自分で過去問から習得できるなら不用。
ただ、午後IIは受けると参考にはなるのかも（模試というより添削）。本番までずっと不安でしたから。

◆８．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？
午後１：問２と問３
セキュリティは取る予定だったので、迷わず問３
計算問題ができそうだったので問２。設問数が少なく、間違った時のリスクも大きいかとも考えましたが、他よりも行けそうだったので。

午後２：問３
ITサービスの改善活動なら、どんな論文ネタでも対応できそうな印象だったので。

◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
・問題のポイントを見つけ出すスピード。前回落ちた時は、午後１を解くのに時間いっぱいかかり５８点で不合格でした。
・春（特別試験）は情報セキュリティスペシャリストを目指したこと
・論文の書き方の情報を収集しておいたこと。

◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
やり方ということはないですが、前回不合格だったのは、午前２と午後１の対策不足

◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
午後１通過して論文の評価（B〜Dでも)を付けてもらいたいと思う事。

◆１２．合格に最も大切なのはズバリなんでしょう。
少しずつでも時間を取ることでしょうか。
私は３０分ぐらい取れれば午後１の問題を１つ解く。
３０分も取れない時は午前２の問題を覚える。
という感じでした。

◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
単純に嬉しいですね。

◆１４．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
職種：専門学校教員
資格：第２種情報処理技術者、応用情報技術者、情報セキュリティスペシャリスト、MCP、Java認定プログラマ
年代：第２種は名前の通り相当古く、学生時代の20年ぐらい前に取得。他はここ５年ぐらいで取っています。

◆１５．書籍などへの転載可否
　ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否
転載可能

◆１６．最後に一言お願いします。
合格してみてわかったことは、
この程度の論文でも合格できるんだ
ということ。このサイトにも書いてますよね。

[558]　ひっきぃ　(2011/12/17 Sat 10:20)

---

Re^3: 試験結果アンケート2011

◆１．
午前�T　…　免除
午前�U　…　76点
午後�T　…　68点
午後�U　…　A
◆２．3回目,システム管理込みでは5回目
◆３．自分のスキルアップ
◆４．ITECの午後対策、ITIL教科書
◆５．3年分を1回
◆６．特になし
◆７．模試は受けていないが、論文は、見てもらうほうが良い。
◆８．午後１：問１と問２、午後２：問３
午後�Tは、DBからみは、絶対選ぶ、午後�Uは、インシデント
系を選択する。
◆９．今までの貯金が活きたと思う。
◆１０．午前に力を入れすぎること！
◆１１．他人の合格シーンを見て、奮い立たせた！
　　　　子供たちを見ると、奮い立つ！
◆１２．合格しようという気持ち
◆１３．お金はもちろんだが、いざというとき、身を守る。
　　　　DB保持していたから、希望の職種へ異動できた。
◆１４．あなた様について教えてください。
　職種：SE、管理人さんの会社の関連システムを10年以上
　資格：一種、二種、DB　国家は以上、その他いくつか
　年齢：アラフィフ
◆１５．転載可能
◆１６．運用周りを馬鹿にする人物が多いが、
　　　　運用無くては、意味がない。

[560]　DUKE　(2011/12/18 Sun 20:00)

---

Re^4: 試験結果アンケート2011

本サイトでお世話になり、昨年度、ＳＭに合格しました。
今年はＳＡ（システムアーキテクト）を受験し合格しましたが、
こちらにアンケートを書かせていただきます。

[試験結果アンケート]
◆１．スコアを教えてください。
午前�T得点 ***.**点 （免除でした）
午前�U得点 68.00点
午後�T得点 66点
午後�U評価 ランク A

◆２．何回目の受験ですか？
１回目

◆３．受験の動機は何ですか？
・スキルアップのため
・合格すれば会社からの奨励金（一時金）がもらえるため

◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど
午前・午後�T： ITEC社の過去問　２冊（５年分必要だったため）

◆５．過去問は何年分を各何回実施しましたか？
５年分を２回

◆６．最新技術の勉強はどれくらい行いましたか？
全く勉強していない。過去問のみで対応

◆７．模試は受けましたか？また、受けた方が良いですか？
受けていません。情報処理技術者試験に受けなれていない方は、
受験したほうがよいかもしれません。

◆８．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？
午後１：問３と問４
ざっと問題文に目を通し「何となく分かりそう」
というものを直感で選んだ。
午後２：問２
用意していたテーマだったので、問２を選択した

◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
あきらめずに最後まで試験に取り組んだこと。
ちょっとずつでも、継続して勉強を続けてきたこと。

◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
・過去問を中心としない勉強。やっぱり過去問が一番です。論文ネタも午後�Tの問題がヒントになります。
・論文を手書きしないこと。必ず２〜３回は制定でも手書きする必要があると思う。４回目以降はＰＣでも良いと思う。

◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
奨励金でなにを買おうか、考えること

◆１２．合格に最も大切なのはズバリなんでしょう。
あきらめないこと
勉強を継続して行うこと（ほんのちょっとでもよい。）やる事が大切だし、少しでも参考書や問題集を開くことが大事

◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
喜び

◆１４．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
職種：　営業
保有資格：
・テクニカルエンジニア（ネットワーク）：　平成２０年 秋
・ＩＴサービスマネージャ：　平成２２年 秋
・基本情報：　平成２３年 特別
・プロジェクトマネージャ：　平成２３年 特別
・システムアーキテクト：　平成２３年 秋

◆１５．書籍などへの転載可否
　ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否
転載可能

◆１６．最後に一言お願いします。
継続は力なり

[561]　ショウ　(2011/12/19 Mon 03:05)

---

Re^5: 試験結果アンケート2011

◆１．スコアを教えてください。
午前�T得点 ***.**点 免除
午前�U得点 64.00点
午後�T得点 71点
午後�U評価ランク A

◆２．何回目の受験ですか？
1回目

◆３．受験の動機は何ですか？
・会社からの指示
・自分自信のスキルアップ

◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど

・重点対策(itec)
・予想問題集(itec)
・過去問(itec)
・論文集

◆５．過去問は何年分を各何回実施しましたか？
3年分

◆６．最新技術の勉強はどれくらい行いましたか？
してません

◆７．模試は受けましたか？また、受けた方が良いですか？
ITECの模擬試験を試験会場で受けました。
試験の雰囲気が感じられるのと、論文を採点してくれるのでよいと思います。

◆８．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？

午後１：問２と問４
　　　　セキュリティが不得意だったので問３は除外し、
　　　　問１を途中までやってつまったので消去法で２，４となった。

午後２：問１
　　　　キャパシティ管理は未経験だったのと、３も問題に沿って論述できそうになかったので消去法で１にした。

◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）

・そもそも勉強のために時間を割いて、机に向かったこと
・勉強は紙に書いて実施したこと
　午後問題は４５分間で問題を１問実施する。
　(出来る出来ないは問わない。)
・論文を第３者に添削してもらったこと
　(私は会社にいる合格者に見てもらった)

◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方

・電車の中で問題を頭の中で読んで、答えを見る方法
　(回答は紙に書いたほうがよい)
・勉強を長時間やり続けない
　(飽きてしまうから)
・勉強するときは近くにテレビ、PC、携帯電話はおかない

◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？

・１時間(２時間でも可)勉強したら、１時間好きなことをやる
　(長時間だらだら勉強しないでメリハリつける)
・ご褒美を設定する
　(自分のほしいものを設定する。お酒、食べ物等)

◆１２．合格に最も大切なのはズバリなんでしょう。
・基礎を身につけること
・勉強を継続すること

◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）

自分自身の知識の向上

◆１４．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
職種：SE
保有資格：
・国家　基本情報
・ベンダ　MSCE2000、OracleGold9i、VCP4　　　　　

◆１５．書籍などへの転載可否
　ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否

転載可能(たいしたことかいてませんが)

◆１６．最後に一言お願いします。
このサイトは大変参考になりました。
次回はPMを受けようと思います。

[562]　初回受験者です　(2011/12/19 Mon 10:28)

---

Re^6: 試験結果アンケート2011

2008年春にテクニカルエンジア（システム管理）を取得しました。
新資格になったため今回再チャレンジしました。

◆１．スコアを教えてください。
午前�T得点 ***.**点
午前�U得点 68.00点
午後�T得点 69点
午後�U評価ランク A
◆２．何回目の受験ですか？
1回目です。
◆３．受験の動機は何ですか？
新資格になったため今回再チャレンジ
◆４．役に立った勉強教材を教えてください。
・本サイト
・ＴＡＣ通信添削
＊システム管理の時で今回は使ってません。
◆５．過去問は何年分を各何回実施しましたか？
3年分を1回ずつ
＊システム管理の時で今回は未実施。
◆６．最新技術の勉強はどれくらい行いましたか？
特にしてません。
◆７．模試は受けましたか？また、受けた方が良いですか？
ＴＡＣの午後添削と模試。
自分の弱点がわかるので効果的です。
特に、論文は書いてみると時間が足りないことがわかる。
時間内に合格ラインまでまとめあげることを本番前に
体感できるのは効果が大きいと思います。
＊システム管理の時で今回は未実施。
◆８．本試験では、どの問題を選びましたか？
午後１：問１、問４
午後２：問２
自分の不得意な分野を消去法で消して
その中から得意な分野を選択してます。
以下に早く、回答する問題を選択するかも
合格への近道だと思います。
◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
とにかく、本サイトの殿のおっしゃる「素直になる」を心がけました。
また、最後まであきらめないこと。
よくあるのが「午前ダメだったな」と思ってもそこであきらめない。
「絶対通っている」と切り替えて最後まで心折れることなく論文まで書ききること。
意外と午前パス出来てます。
◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
思い込みをなくす。
不正解には必ず自分の思い込みがあります。
◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
合格証書を手にした姿をイメージし続けること。
◆１２．合格に最も大切なのはズバリなんでしょう。
前日までの学習の継続も大切ですが、
一番大切なのは、当日の「集中力」。
当日120%の力を出せるように頑張ってます。
◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
普段の業務の成果の証明と
本音はお金ですかね。
◆１４．あなた様について教えてください。
SE、36歳
ITストラテジスト、プロジェクトマネージャ
システムアーキテクト、ITサービスマネージャ
テクニカルエンジニア（システム管理）、MCSE
◆１５．書籍などへの転載可否
転載可能
◆１６．最後に一言お願いします。
テクニカルエンジア（システム管理）受験の際も書かせていただきましたが、本サイトに出会ったことが、合格に繋がったと思います。
おかげさまで論文系の資格を多数取得することが出来ました。
ありがとうございました。

[563]　zaki　(2011/12/19 Mon 14:08)

---

Re^7: 試験結果アンケート2011

昨年はネットワークスペシャリスト試験で大変お世話になりました。
今回も報告させていただきます。

[試験結果アンケート]
◆１．スコアを教えてください。
午前I 得点 ***.**点
午前II得点 68.00点
午後I 得点 74点
午後II評価ランク A

◆２．何回目の受験ですか？
1回目です。

◆３．受験の動機は何ですか？
運用業務にかかわっているため、客観的に知識を評価してもらう目的で受験しました。
それと、会社からの報奨金(お決まりです)。

◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど
・管理者様の著書　ITサービスマネージャ「専門知識+午後問題」の重点対策
　->ITサービスマネージャを受験するなら、必須でしょう。
・ITサービスマネージャ試験に楽々合格サイト
　->特に午後2対策と掲示板の情報は役立ちました。みなさまの生の論文を拝見させて
　いただき、とても参考になりました。
・情報処理技術勉強会

◆５．過去問は何年分を各何回実施しましたか？
午前2・・新制度になってから(2年分)を2回程度です。8割以上の学習時間を午後に注
　　　　 力しました。しかし、これでは足りなかったと思います。冷や汗ものでした。
午後1・・3年分を3回程度。
午後2・・3年分を1回。論文は初めての受験でしたので、6本ほど書きました。(B〜D
　　　　 レベル)

◆６．最新技術の勉強はどれくらい行いましたか？
まったくしていません。

◆７．模試は受けましたか？また、受けた方が良いですか？
受けていません。ITサービスマネージャ試験では、基本的には不要と思います。
ただ論文を独学でされている方は、第三者の評価を受けるために、受験したほうがよい
と思います。

◆８．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？
午後１：問1,3
　　　　問1:オーソドックスな問題で、問題文を丁寧に読めば解答できる内容でした。
　　　　問3:セキュリティ管理の問題で、SCと比較すると簡単でした。
　選択しなかった理由は・・
　　　　問2:解答用紙を配られたときに、解答のマスが極端に少なかったので、一問あ
　　　　たりの得点が大きく、リスキーと思いましたので避けました。
　　　　問4:オペレータ云々の問題は昨年も出ていたと思いますが、苦手なので避けま
　　　　した。
午後２：問3:用意した論文に近く、書けそうと思ったので。ただあとで見直して
　　　　問題文の「事象」の解釈を誤ったと思い、不合格を覚悟していました。

◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
ITサービスマネージャの立場を常に意識することを心がけたことと、午後2の論文作成に
おいて、おおよその時間配分(問の選択、あらすじの作成、設問ごとの取り組み)をあら
かじめ決めておいたことで、落ち着いて受験できたからだと思います。
論文に関しては、第三者の評価が必要と思います。自分で書いた文章の癖は、
わかりにくいものです。それと、さぁ論文を書こうと思っても、最初のうちは消しゴムで
消した山ばかりができて、なかなか進みませんでした。その後、6時間以上かけてやっと
書いた論文の問題点をたくさん指摘されると、それはそれはへこみました。でもあきらめずに
数本書いていけば、必ず実力がついてくると思います。

◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
ネットワークスペシャリスト試験と重複しますが、過去問を無視していては、絶対
合格しないと思います。

◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
試験合格時の喜びをイメージすることと、気楽に試験勉強に取り組むことです。
勉強を詰め込みすぎて、試験前に燃え尽きてしまうことは、とてももったいないと
思います。

◆１２．合格に最も大切なのはズバリなんでしょう。
最後まであきらめないことですね。

◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
実力を国に認めてもらえたという満足感です。

◆１４．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
40代・サーバ構築および運用
・第二種情報処理(平成元年)
・初級システムアドミニストレータ(平成12年)
・情報セキュリティスペシャリスト(平成21年)
・ネットワークスペシャリスト(平成22年)など
※ベンダー系資格は持っていません。

◆１５．書籍などへの転載可否
　ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否
こんな文章でよければ、転載してください。
※ネットワークスペシャリスト試験に楽々合格で、私のアンケートを採用していただき
　ありがとうございます。

◆１６．最後に一言お願いします。
ITサービスマネージャ試験においても、こちらのサイトと管理者様の著書のアドバイスは
大変参考になりました。本当にありがとうございました。
ITサービスマネージャ試験に合格したら、情報処理技術者試験は引退しようと思っていま
したが、他区分にも興味がでてきました。次は何を受験しようか迷うところです。

[564]　トート　(2011/12/22 Thu 12:58)

---

Re^8: 試験結果アンケート2011

[試験結果アンケート]
◆１．スコアを教えてください。
午前�T得点 ***.**点 （免除）
午前�U得点 88.00点
午後�T得点 86点
午後�U評価ランク A
◆２．何回目の受験ですか？
1回目
◆３．受験の動機は何ですか？
秋の情報処理試験の未取得区分の中で比較的現在の業務と類似していたため。
◆４．役に立った勉強教材を教えてください。
iTEC ITサービスマネージャ合格論文の書き方・事例集　第2版
◆５．過去問は何年分を各何回実施しましたか？
2年分を1回。
◆６．最新技術の勉強はどれくらい行いましたか？
特に行いませんでした。
◆７．模試は受けましたか？また、受けた方が良いですか？
受けていません。
◆８．本試験では、どの問題を選びましたか？
午後１：問１と問３　得意分野を選択
午後２：問２　実経験が生かせそうだったから
◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
PM(まだ評価B止まりで合格していませんが)の論文の勉強が役に立ったと思います。
◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
過去問をおろそかにすると合格への道は遠のくと思います。
◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
目標は高く、「高度区分制覇」と無謀にも掲げること。
◆１２．合格に最も大切なのはズバリなんでしょう。
シンプルな解答と論文力。
◆１３．資格を取って一番得るものは何？
達成感。
◆１４．あなた様について教えてください。
30代　プログラマー
情報処理系　1種,DB,NW,SC
ベンダー系 OracleMaster11gSilver
◆１５．書籍などへの転載可否
転載可能
◆１６．最後に一言お願いします。
正直論文はあまり自信がありませんでしたが、初めて評価されて今後の励みになると思います。

[565]　chataro　(2011/12/22 Thu 18:03)

---

Re^9: 試験結果アンケート2011

◆１．スコアを教えてください。
午前�T得点 ***.**点
午前�U得点 68.00点
午後�T得点 80点
午後�U評価ランク A
◆２．何回目の受験ですか？
１回目
◆３．受験の動機は何ですか？
毎回何かしら受けている事と、会社のITIL推進
◆４．役に立った勉強教材を教えてください。
ITサービスマネージャ「専門知識+午後問題」の重点対策
システム監査技術者　合格論文の書き方
◆５．過去問は何年分を各何回実施しましたか？
3年分1回（午前）
2年分全問（午後）
◆６．最新技術の勉強はどれくらい行いましたか？
実務上の範囲（仮想化等）
◆７．模試は受けましたか？また、受けた方が良いですか？
受けていない。（NW等のときは受けてました。）
◆８．本試験では、どの問題を選びましたか？
午後1・問1/3
点数が分散するように回答問数の多い物を選んだ
午後2・問2（キャパシティ管理）
日常業務から書きやすそうだったので…
◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
今回始めての受験でしたが、論文を他の試験でも書いていた為組み立てが早く、余裕を持って書けたのが良かったと感じる。
◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
論文のPC打ち。
日頃から実際に記述する練習をしておくと驚くほどスピードが早くなります。
◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
毎回何かしらの区分を受けるようにしている。
◆１２．合格に最も大切なのはズバリなんでしょう。
何があっても諦めない心と最後まで食らいつく意地。
◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
モチベーションと確かな自信
◆１４．あなた様について教えてください。
IT関係
保有資格　SC・NW、他ベンダ資格（MCP等）
30代
◆１５．書籍などへの転載可否
転載可能
◆１６．最後に一言お願いします。
諦めなければいつかは合格できます。皆さんも頑張ってください。

[566]　犬　(2011/12/27 Tue 14:04)

---

Re^10: 試験結果アンケート2011

[試験結果アンケート]

試験区分は、【システムアーキテクト試験】です。

◆１．スコアを教えてください。
午前�T得点 免除
午前�U得点 88.00点
午後�T得点 75点
午後�U評価ランク A

◆２．何回目の受験ですか？
1回目

◆３．受験の動機は何ですか？
自己啓発

◆４．役に立った勉強教材を教えてください。
ITサービスマネージ試験に楽々合格
システムアーキテクト試験に楽々合格
アイテックの過去問、論文事例集

◆５．過去問は何年分を各何回実施しましたか？
午前�U：過去7年分を何回も
午後�T：過去7年分を何回も

◆６．最新技術の勉強はどれくらい行いましたか？
全くしていません。

◆７．模試は受けましたか？また、受けた方が良いですか？
TACの模試を自宅受験で。
模試そのものが目的でなく、実力テストの論文のツーウェイ添削を受ける為。

◆８．本試験では、どの問題を選びましたか？
午後１：問2と問3
業務系を選択するとはじめから決めていました。
午後２：問2
問1の複数システムは絶対でない…と思い、準備していなかった為。

◆９．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
絶対、あきらめない。

◆１０．（不合格時との比較も含めて）これはやってはいけない勉強のやり方
論文を書いても、誰にも見せない。
→自分の書いた論文を見てもらうのは、はじめは少しはずかしいが、見てもらわないと、どこが、悪いのか、どう直せばよいのかが分からない。

◆１１．モチベーションを上げたり維持するために工夫したことは何ですか？
受かった瞬間、合格証書をゲットした瞬間を妄想（いや想像）する。

◆１２．合格に最も大切なのはズバリなんでしょう。
絶対、あきらめない。

◆１３．資格を取って一番得るものは何？（喜び、モチベーション、お金、実力、資格の肩書きなど）
喜び。受かると、さらに勉強しようという気になる。

◆１４．あなた様について教えてください。
職種や主な保有資格、可能であれば年代など
職種：汎用機（ホスト）のオペレータ…
年代：30代
主な保有資格：
NW,DB,SC,SM,AP,SW,FE,1種,2種,初級シス
Oracle,MCP,CCNA（失効）,ITIL ,日商簿記2級

◆１５．書籍などへの転載可否
転載可能

◆１６．最後に一言お願いします。
昨年は、SMの午後�Tが61点とぎりぎり。
論文も大事ですが、それにとらわれて午後�Tをおろそかにしないことも大事だと思います。
論文の基礎は、ITサービスマネージ試験に楽々合格を熟読して勉強。
論文事例集は、論文の完成度が高すぎるので、参考程度に。
事例集から、「使えそうなフレーズ」を、たくさんピックアップして、
まとめておき、本番で使えそうなら、使う…という方法で勉強しました。

[570]　こどらん　(2012/01/07 Sat 13:58)

SA合格しました

昨年、こちらのサイトで論文の基礎を勉強し、
管理者様に添削して頂き、ITサービスマネージャ試験に
合格した者です。

おかげさまで、平成23年度 秋期の
システムアーキテクト試験に合格しました。

こちらのサイトでの論文対策の基礎をベースに、
姉妹サイト「システムアーキテクト試験に楽々合格」にて、
システムアーキテクト特有の部分について勉強しました。

午前�T得点：免除
午前�U得点：88点
午後�T得点：75点
午後�U評価ランク：A

こちらのサイト、及び姉妹サイト（SA楽々）には、大変
お世話になりました。
ありがとうございました。

[567]　こどらん　(2011/12/30 Fri 20:30)

---

Re: SA合格しました

皆さま、合格おめでとうございます。
貴重な合格体験ありがとうございます。

このサイトですが、ITサービスマネージャの掲示板としてではなく、論文試験の掲示板に変えさせていただきました。

ITサービスマネージャ以外の合格アンケートも、是非とも記載願います。

よろしくお願いします。

[568]　管理者　(2011/12/31 Sat 07:54)

H23年　秋期　SM試験結果

お世話になります。タムタムです。

H２３年度の秋期SM試験ですが、不合格でした。
午前�U、午後�Tは通過しましたが、やはり午後�Uがダメ
でした（評価B）。

こちらで何度も添削いただいたのに良い結果を出せずに
すみません。。。

結構手応えがあっただけに、ちょっとショック！

まぁ悔やんでも仕方ないので、次のPM試験に向けて更に
論文作成力を向上させたいと思っています。

またこちらに論文を投稿させてもらおうと思いますので、
その際は添削・評価、ご指導をいただければと思います。

[559]　タムタム　(2011/12/17 Sat 15:44)

H23-PM2-2

はじめまして。
ITサービスマネージャは昨年取得済みですが、情報処理技術者試験は良問が多いことから、毎回試験後には各試験の問題に目を通しています。
今回も、とても参考になる問題ばかりでした。

ただ、午後�Uの「問２　キャパシティ管理について」に対しては、回答イメージがつかめなかったので、投稿しました。

設問アで求めている「監視作業を通して、発見したキャパシティに関する問題」の監視作業とは「サービス監視を通じてか」それとも「キャパシティ監視を通じて」なのか迷うところです。

【例えば】
キャパシティを監視していて「メモリ使用量のしきい値（基準値）を超えた」
↓
ＩＴサービスへ影響「レスポンス悪化、販売機会損失」
↓
キャパシティに関する問題を発見「基準値を超えると極端にレスポンスが悪化するためITサービスへ影響する（対応が遅れる）」
↓
キャパシティ管理方法の見直し「基準値の他に警告値を設定することで問題が発生する前に是正措置を講じる」

こんな流れでいいのでしょうか？

[540]　みつ　(2011/10/25 Tue 09:58)

---

Re: H23-PM2-2

>こんな流れでいいのでしょうか？

流れが設問とマッチしてないのでは？
設問通りに組み直されてはどうでしょう。
良しあしを答えにくいご質問です。

>設問アで求めている「監視作業を通して、発見した
>キャパシティに関する問題」の監視作業とは
>「サービス監視を通じてか」それとも「キャパシティ監視を
>通じて」なのか迷うところです。

あまり気にしなくていいのではないでしょうか。日常的にはサービス監視ですが、同時にキャパシティ監視目的でもあったりします。
どちらかを明言する必要ありましたっけ？

>ＩＴサービスへ影響「レスポンス悪化、販売機会損失」

販売機会損失は、ＩＴサービスではなくて業務への影響かと思います。

>キャパシティ管理方法の見直し「基準値の他に警告値を設定することで問題が発生する前に是正措置を講じる」

なんとなく策が平凡すぎる気がします。
「メモリ使用率と実際の応答性能の関連性を検証し、適正な警告値を設定するとともに、複数の値でより精度の高い管理を・・」など。

適当な回答ですいません。

[541]　管理者　(2011/10/28 Fri 00:02)

最後まであきらめずにやりました。

何とか試験終わりました。
自己採点の結果は以下のとおりになります。

(午前1は免除)
午前2　16/25
午後1　itecの模範解答によれば7割くらいは取れている感じです。(問2、4を選択)

合否は論文の結果次第になりそうです。

論文は問の選択に時間をかけすぎた結果、
論文作成がぎりぎりで3分くらいしか見直す時間がありませんでした。

論文は　「問1　ITサービスに関する顧客への報告」を選択しました。

有益な報告内容を顧客の上層部の今後の営業戦略に役立てるための報告にする
という考え方で論旨を展開しました。
ITサービスマネージャらしいことがかけたかどうかがいまいち自信がないですが
スラムダンクの安西先生のお言葉どおりに最後まであきらめずに書くことが出来ました。

ぜひ受かりたいです。

[536]　初回受験者です　(2011/10/20 Thu 19:01)

---

Re: 最後まであきらめずにやりました。

お疲れ様です、書き込みありがとうございます。

論文は時間がないですよね。
考えているとあっという間に時間が経ってしまいます。

難関試験なので簡単ではありませんが、合格されることをお祈りしております。

合格されましたら、合格体験などをお知らせ願います。

[537]　管理者　(2011/10/22 Sat 09:45)

---

Re^2: 最後まであきらめずにやりました。

ありがとうございます。

ITサービスマネージャ試験対策では、本サイト及び管理人様の著書である重点対策にも大変お世話になりました。

試験合格の際には合格体験を投稿させていただきます。

[538]　初回受験者です　(2011/10/22 Sat 23:16)

無事に試験終了しました

お世話になっております。
以前、こちらに論文を載せさせて頂いた者です。
本当にこちらのサイトにお世話になり、最後までなんとかやりきれました。
本当にありがとうございます！

午前中の2つの試験は無事に突破してました。
残すは午後�Tと論文です。

帰ってから気づきましたがテンプレートの初めに記載する「システム名称」に論文のタイトルを間違えて書いてしまってました…。

論文も内容も正直、自信がなく、合格は非常に厳しいかと思います…、次回またチャレンジしようと思います！

本当にありがとうございました！

[532]　初回受験挑戦者　(2011/10/17 Mon 12:59)

---

Re: 無事に試験終了しました

試験お疲れさまでした

試験はさぞかし疲れたかと思います。
しばらくゆっくりお休みいただき、吉報を待ちましょう。
論文はボロボロの人でも結構受かってます。
いい結果が出ましたら、スコアや合格体験を記載いただけると幸いです。

ありがとうございました。

[534]　管理者　(2011/10/19 Wed 22:52)

---

Re^2: 無事に試験終了しました

ありがとうございます。
重点対策を読んでITサービスマネージャを受けてみようと思わせて頂きましたし、論文まで見て頂いたりお世話になりっぱなしで本当にありがとうございます。

結果判りましたらこちらに投稿させて下さい。

[535]　初回受験挑戦者　(2011/10/20 Thu 14:08)

H23-PM1-1_3

問１
設問１
（１）業務特異日のインシデント発生時の対応を行っていない。
（２）根本原因：T社からキャンペーン日の連絡がY氏にしか共有されていない。
　　再発防止策：T社と業務特異日に関する連絡方法を合意する。
（３）暫定対策の適用をすぐ判断できないのにエスカレーションしなかった。

設問２
（１）T社によるサービスの回復確認なしにインシデントを解決とした。
（２）インシデントの対応状況を解決までS社からT社に適切なタイミングで行う。

設問３
（１）各インシデントの根本的な対策とその対応状況を追加する。
（２）今回と同様の事象発生時の対応をT社に共有する。

問３
設問１
（１）利用者IDの削除うは利用者ID削除申請書受領後にすぐに実施する。
（２）ID一覧表に利用者IDが不要となった社員のものがないか確認させる。
（３）システム部全員で一つの特権IDを共用しているから。

設問２
a.発信元IPアドレス
b.宛先ポート番号

設問３
（１）情報漏えいなどの問題発生時に調査を行えるようにするため。
（２）全てのサーバのアクセスログをディスク容量を考慮して1年間保存するため。
（３）インターネットから保存したアクセスログの改ざんや削除が行われる可能性がある。

設問４
LAN2
インターネットからの利用でFWで許可されたものだけを解析できること。

[533]　gon　(2011/10/17 Mon 22:27)

論文の設問アについて

いまさらですが、
論文の設問アで、ITサービスの概要を求められますが、ここでいうITサービスってなに？
論文事例とかみると、情報システムに対する運用面のサービスや、ITIL的なシステム管理・運用
のことを説明しているものがあるけど、問題によってはITサービス＝情報システム
という観点で記述しないと、話がおかしくなる問題もあると思うのですが．．．
「ITサービス＝(情室が)提供しているITサービス」とすると、問題によっては
本来論述すべき対象がズレるという感じがするのですが。
いまさらですが、この部分がいつも腑に落ちないのです。

[529]　釣り好き　(2011/10/15 Sat 14:26)

---

Re: 論文の設問アについて

いよいよ明日ですね。
がんばってください。

重点対策にもこの点はある程度書きましたが、情報システムとITサービスは分けて考えましょう。
ITサービスの内容は、釣り好きさんがおっしゃっている内容で問題ありません。

また、おっしゃるように、論文を書くなかで、情報システムの記述をせずにITサービスを書くと不自然になります。なので、情報システムを内容を書くのですが、情報システムとITサービスの割合が4:1程度になる場合もあります。たとえそうなったとしても、問われているのはあくまでも「ITサービス」ですから、ITサービスを書かなくてはいけません。

採点者の趣旨は、「あなたはまず、どんな運用管理をしているのですか？」と聞いているんです。
・問い合わせ対応をしているのか、それともメーカに直接聞くようにアナウンスしているのか。
・故障時には予備機交換だけをしているのか、原因追究して現地対応含めて行っているのか。
・予防保全活動やキャパシティ設計なども行っているのか。

どんな運用をして、どういうITサービスを利用者に提供しているのかを述べてもらわないと、そこで起こる問題点や課題が理解できませんよね。

結論を再度述べると、求められているのはITサービスです。ITサービスの割合がかなり少なくなったとしても、ITサービスの内容を必ず書きましょう。

[530]　管理者　(2011/10/15 Sat 14:51)

---

Re^2: 論文の設問アについて

ありがとうございます。
情報システムとITサービスを上手くまとめて両方記述します。

[531]　釣り好き　(2011/10/15 Sat 15:17)

H22 午後�U設問1

初めまして。こちらのサイトを拝見し、SM受験をしてみようと決意した者です。

経験や知識が浅く、試験まで近付いて来て非常にドキドキしながら過ごしております。
初めて論文を書いてみましたので、大変恐縮ですが一度、読んで頂いてアドバイスを頂けたら嬉しいです。
宜しくお願い致します。

-----------------------------------------------------

-----　ITサービスにおける情報管理について(H22設問1)　-----
1．私が携わったITサービスの概要と情報管理において発生した問題点
1-1　私が携わったITサービスの概要
　私が勤務するA社は東京に本社と全国の主要都市に事務所を持つ運送会社であり、私はA社で情報システム部門に勤務している。情報システム部門には企画・開発グループ、ネットワーク管理グループ、システムの障害受付および運用管理を行うサービスデスクがあり、私はサービスデスクで国内の顧客管理システムを担当するチームのチームリーダとして勤務している。
　サービスデスクでは顧客管理システムのインシデント管理、問題管理、リリース管理、変更管理、構成管理を行っている。また問い合わせに対して一次対応を実施し、解決しない場合は専門の部署へエスカレーションしている。また機器の交換が必要と判断された場合は関連会社にオンサイト対応を依頼している。
サービスデスクでは設置されている全ての機器の情報を管理する構成管理データベースが(CMDB)が運用されている。新規にシステム端末が設置された場合は関連会社からの情報を元にCMDBへの登録作業を実施している。
1-2　情報管理における問題点
　ある地域の事務所が移転するということで、移転準備の為に設置されている全ての端末の情報が欲しいとユーザーから問い合わせを受けた。CMDBより該当の事務所の端末情報を抽出して情報を提示したところ、実際に設置されている端末台数や製造番号とサービスデスクから提示した情報とでは違っていた。現場で設置されている端末の情報を全て再確認する必要があり、移転作業が予定日より2日遅れる事態が発生した。

2．CMDBの利用における問題に対する改善と工夫した点
2-1　改善策
　設置されているシステム端末の構成品目に関する情報を一元管理する構成管理データベース(CMDB)を活用することは、サービスデスクでのユーザー対応、障害回復、設備の増設、変更などITサービスにおける様々なプロセスを効率よく的確に行う上で極めて重要である。しかし、必要な情報がCMDBに登録・更新されていないなどが原因でサービスの停止や作業の遅延が発生する場合がある。ITサービスマネージャには様々な取組みによって、CMDBの内容、運用方法、及び利便性を改善する事が求められている。今回判明した情報管理の問題はサービスデスクでも重大な問題として話し合われ、チームへのヒアリングの結果、下記2つが原因と判断された。
�@　特定の端末チェックリストは存在せず、関連会社作業者よりメール本文に記載する形で作業完了報告がされていた。
�A　提供された情報をサービスデスク内で精査する事なくCMDBへの登録作業を実施していた。
上記の原因を踏まえ、2つの改善案が提案された。
�@　端末設置後の端末チェックリストを作成する。
�A　サービスデスク内でCMDBへの登録チェック方法を確立する。
チーム内では上記2つの改善案が有効と判断され、上長の承認を得て実施する事にした。
2-2　工夫した点
　改善案�@を実施するにあたって関連会社作業者に対し、端末情報管理の重要さについて教育するのみでは完璧とはいえない。そこで端末設置後の端末チェックリストを作成することにした。このチェックリストは全ての項目を記述式にすることで実際に確認しないと記入できない書式とした。また、チェックリストの提出において、チェック箇所を撮影した写真も一緒に提出する事を義務付け、記入間違いがあってもDBへ登録する前に確認する事ができる手順とした。
　改善案�Aに関してはCMDB登録管理責任者を配置する事により、登録された情報に間違いがないかを二重チェックできる体制を取ることにした。またCMDB登録管理責任者によるチェックを隔週金曜日に実施する事として、新規登録および更新のチェック頻度を上げた。

3．　改善の具体的な効果・評価とCMDBの更なる活用に向けた課題
3-1　改善の具体的な効果と評価
　改善案�@に関しては端末設置後のチェックリストと写真との二重チェックが可能となり、作業者から提示される端末情報の精度が向上したと評価できた。改善案�@を作業者に指示するにあたり、当初は作業の手間が増えると反発の声もあったが、続けることにより作業にも慣れ、更に作業者全体に情報管理の重要性に関する意識の向上が見られるようになり、非常に効果が高かったと考えている。
　改善案�AでもCMDB登録管理責任者を配置することでCMDBの情報精度が向上したと評価出来た。仮に登録担当者が登録ミスした場合でも登録の差し戻しをすることで登録担当者への再確認を促す事が出来るようになった。これにより登録担当者の情報管理に対する意識向上につながる効果がみられた。また差し戻し回数が多かった登録担当者に対しては個別に指導することが可能となった。
3-2　CMDBの更なる活用に向けた課題
　私は情報システム部門において情報管理こそが最も重要であると考えている。今回の問題が発覚して現場での再調査により現在はデータ精度が向上している。今後、端末の新規設置や移設が発生する中でこのデータ精度を維持し続ける事が最も重要な課題である。
　一度、対策を実施してしまうと情報管理の重要さに対する意識が薄れがちである。そこで半期に一度設置されている端末の情報を現場に行き、確認する事にした。実際に設置状況を確認することでデータ精度の維持が可能になると共に情報管理の重要性を再確認させる事ができ、情報管理の重要さに関する意識を維持・向上させることが出来ると考えた。
　今後は他のシステムを担当しているチームとも情報を共有し、情報システム部全てのデータ精度を向上させて行きたいと思う。
-----　以上　-----

[516]　初回受験挑戦者　(2011/10/05 Wed 16:05)

---

Re^2: H22 午後�U設問1

丁寧に添削・ご指導いただきありがとうございました。

論文は苦手ではあるのですが、重点対策の本とこちらのサイトを参考にして試験までに少しでもレベルアップ出来るように頑張りたいと思います！

こちらで頂いたアドバイスを踏まえ、論文の練習をしたいと思います！

ありがとうございました！

[518]　初回受験挑戦者　(2011/10/07 Fri 07:05)

---

Re^2: H22 午後�U設問1

お疲れさまです。すぎエモンです。
査読結果が途中で切れてしまっていたようです。
再度投稿します。

【良いと感じた点】
・始めにしては良く書けている論文です。最初の記述では自分の主張を独りよがりに
　書いてしまうことが多いのですが。しっかりと書くべき事を冷静に見据え、問題文
　に準拠するような主張を記述できている部分は高評価でした。

・「チェックリストと写真との二重チェック」という工夫は現場的でいいですね。
　分かりやすく、運用の視点ならではの工夫です。

・「3-2　CMDBの更なる活用に向けた課題」の部分は、巧みな書き方だと思います。
　特に以下のような部分ではITサービスマネージャとしてとてもよい記述だと思いました。
　　●一度、対策を実施してしまうと情報管理の重要さに対する意識が薄れがちである
　　●他のシステムを担当しているチームとも情報を共有し、情報システム部全ての
　　　データ精度を向上させて行きたい
　欲を言うなら、「3-2」の部分で「CMDBの活用に対する」目標という書き方が
　出来ていればより、設問に忠実になると思います。

・おそらく本職の運用管理部門の方であろうとという事を伺わせるような論文内容
　でした。この為、内容にリアリティがあります。

【気になった点】
・問題点対する「原因」の記述が設問イではなく設問アで書いた方が良かった
　のではないかという印象を受けました。さらに記述した原因が問題文に準拠
　する書き方をすると合格に近づくと思います。

・発生した問題とそれに対する対策については、独自性のある記述がされています。
　これは現実的な記述でよいのですが、問題文に書かれている「問題点」や「対策」
　をそのまま流用した方が「問題文に忠実に準拠している」というアピールになるの
　ではないかと思います。この内容で不合格になる事はないのですが、少しでも
　合格率を上げる工夫になると思います。

・「�@端末チェックリスト」の部分が、今回の主題である「CMDB」と関係のない記述
　なのではないかと感じました。この問題の主題は「CMDB」なのに、CMDBが主役に
　なりきれていません。もっとCMDBを前面に出した内容でも良かったのではないで
　しょうか。他にも問題文に記述されている「CMDBの構成品目」などに対する言及が
　少なかった点も気になりました。

【査読ポイント】
☆文字数が規定内に収まっているか？
　→○：設問ア〜ウ全てが規定文字数内に収まっています。
　　　　設問アは欲を言うなら、もう少し文字数が多い方がいいかも知れません。

☆誤字脱字がないか？
　→△：以下の誤字を発見しました。
　　　　「構成管理データベースが(CMDB)が」→「構成管理データベース(CMDB)が」

☆所属する組織を明確に記述しているか。
　→○：以下の記述により所属する組織を明記しています。
　　　　●私はA社で情報システム部門に勤務している。情報システム部門には
　　　　　企画・開発グループ、ネットワーク管理グループ、システムの
　　　　　障害受付および運用管理を行うサービスデスクがある。

☆自分の立場を明確に記述しているか。
　→○：サービスデスクのリーダーであることが明記されています。
　　　　●私はサービスデスクで国内の顧客管理システムを担当するチーム
　　　　　のチームリーダとして勤務している。

☆関連する組織を明確に記述しているか。
　→○：以下の記述により関連する組織を明記しています。
　　　　●関連会社について言及されています。
　　　　●解決しない場合は専門の部署へエスカレーションと記述されています。

☆対象システムを明確に記述しているか。
　→○：社員スキル管理システムであると明記されています。

☆ITサービスマネージャの視点を守っているか？
　→◎：運用管理の視点に終始しています。ITサービスマネージャの視点にブレは
　　　　ありませんでした。この論文のストロングポイントだと思います。

☆自分の考えを主張しており、これが問題文に準拠しているか？
　→◎：問題文を上手く利用して主張を書けているポイントがありました。
　　　　　●構成管理データベース(CMDB)を活用することは（途中略）重要である。
　　　　その他の部分でも、随所で「私の考え」が記述されており良いポイントだと
　　　　思います。

☆数字を盛り込むことで具体的な記述を行っているか。
　→△：具体的数字を盛り込んだ記述は少ないです。「移転作業が予定日より2日遅れる」
　　　　という部分ぐらいでしょうか。もう少し、数字を盛り込む事を意識しても
　　　　よいのではないでしょうか？例えば、「3-1　改善の具体的な効果と評価」で
　　　　数字を交えて評価出来ていれば、より論文に対する説得力も増すと思います。

『設問に忠実に答えたか』
☆設問アの「携わったITサービスの概要」を記述したか。
　→○：ITサービスの概要がしっかりと記述されている様です。

☆設問アの「CMDBの利用において発生した問題及びその原因」を記述したか。
　→×：原因を記述する場所が「1-2」ではなく「2-1」になっています。
　　　　できれば「1-3　発生した問題の原因」という項目を追加した方が
　　　　設問に忠実になるかと思います。ここで、「CMDBの情報が更新されていない
　　　　事が原因だった」と明記すれば、問題文への準拠性も増します。
　　　　また、「1-2　情報管理における問題点」は、設問に忠実に応えるために
　　　　「1-2　CMDBの利用において発生した問題」という記述にした方がよいの
　　　　ではないでしょうか？

☆設問イの「問題に対してどのような改善を行ったか」を記述したか。
　→○：「2-1　改善策」の部分で記述されています。

☆設問イの「工夫した点を中心に」という記述がされているか。
　→○：「2-2　工夫した点」の部分で記述されています。

☆設問ウの「改善の効果及びその評価」を記述したか。
　→○：「3-1　改善の具体的な効果と評価」で記述されています。

☆設問ウの「CMDBの更なる活用に向けた課題」を記述したか。
　→○：「3-2　CMDBの更なる活用に向けた課題」で記述されています。

『問題文にに忠実に答えたか』

☆ITサービスやCMDBの構成品目を言及しているか？
　→×：ITサービスやCMDBについて、どのような構成品目があるのかが
　　　　言及されていません。

☆構成管理データベース（CMDB）の重要性を記述しているか？
　→◎：キチンと問題文を引用しながら（CMDB）の重要性を記述しています。
　　　　重要性の意図が問題文の内容と一致しているので、高ポイントだと思います。

☆CMDBの運用での具体的な問題点を記述しているか？問題点が題意に沿っているか。
　→○：実際に設置されている端末台数や製造番号とサービスデスクから提示した
　　　　情報とでは違っていた。という問題点は分かりやすくていいと思います。
　　　　しかし、以下のような問題文そのままの問題点にした方が問題文への準拠性は
　　　　増すのではないかと思います。
　　　　　→連絡先がわからなくてサービス停止が長引いてしまった
　　　　　→ライセンスの有効期限切れでサービスが突然停止してしまった

☆ITサービスマネージャとしてCMDBの問題に対して求められている事を記述したか。
　→◎：以下の記述により、明記されています。内容も問題文に準拠しています。
　　　　　●ITサービスマネージャには様々な取組みによって〜
　　　　問題文の表記をうまく取り込んでおり、良い点だと思います。

☆構成品目とそれらの関係をCMDBに追加するという対策を具体例を挙げて述べたか。
　→△：対策として構成品目とそれらの関係をCMDBに追加するという事は挙げられていま
　　　　せん。必須ではないですが、以下のような対策が記述されていれば「問題文に準拠
　　　　している」というプラスの評価がなされると思います。
　　　　　�@サービスデスクで顧客からの問い合わせに答える場合
　　　　　　→顧客、提供サービス、IT機器及びそれらの関係
　　　　　�A障害などに対処する場合
　　　　　　→ソフトウェアのバージョン、IT機器の型番
　　　　　�B電力設備の工事の準備の場合
　　　　　→設備、収容されるIT機器及びそれらの関係
　
☆CMDBの運用ルールを徹底するという対策を具体例を挙げて述べたか。
　→○：対策としてストレートに「CMDBの運用ルールを徹底する」という対策は挙げられ
　　　　ていません。しかし、「CMDB登録管理責任者を配置する」という記述は、
　　　　問題文に書かれている「�A責任者を定めて運用ルールの遵守状況をチェックする」
　　　　という記述に準拠しており、良い点だと思われます。

☆利用目的に応じて、ツールなどの導入を図るという対策を具体例を挙げて述べたか。
　→△：対策としてツールなどの導入を図る事は挙げられていません。
　　　　必須ではないですが、以下のような対策が記述されていれば「問題文に準拠してい
　　　　る」というプラスの評価がなされると思います。
　　　　　�@構成品目の情報を自動で収集するツールを導入する
　　　　　�A保守契約の満了やディジタル証明書の有効期限を自動通知する仕組みを
　　　　　　導入する

[519]　すぎエモン　(2011/10/07 Fri 08:36)

Ｈ１９ 午後２　問２

お世話になります。今回も論文を書いてみました。毎度同じシステムで芸がないのですが、ご意見をいただけると助かります。今回も3000文字を越えてしまったのですが、なかなか削る部分が見つからなかったので、この内容で投稿させてもらいます。

-----------------------------------------------------------

第１章　ITサービスの概要と暫定対策と本対策
１．１　ITサービスの概要
　A社は、従業員規模が２０００人程度のソフトウエア
開発企業である。ソフトウエア開発及びA社の技術者を
派遣する技術者派遣サービスを主な事業の柱である。
A社では、技術者派遣サービスが好調であり、昨年より
本サービスを支援する目的で社員スキル管理システムを
構築し運用している。A社にはその他多くの社内システ
ムが稼働しており、その開発と運用を情報システム部が
担当している。私は情報システム部に所属し、社員スキ
ル管理システムの運用チームのリーダーである。私の運
用チームでは、本システムのサービスデスクなどのサー
ビスサポート、キャパシティ管理などのサービスデリバ
リが主なサービスである。顧客は人事部であり、ユーザ
は全社員である。A社では、４月と１０月に全社員が本
システムを使用し、自身のスキルを登録・更新する。人
事部は、顧客企業から技術者派遣の要望を受け、本シス
テムを使用して検索し、回答している。

１．２　暫定対策と本対策が必要となった課題と理由
　本システムをリリースしてから、１年が経過して、人
事部より検索処理のレスポンスが悪化しているとのクレ
ームがあった。調査・確認したところ、全社員が自身の
スキルを登録・更新する４月と１０月、とりわけ登録・更新
期限の３日前に設定時に想定していた以上のアクセスが
発生した。そのため、負荷が高まり、レスポンスが悪化
していた。この報告を受けたのが、４月のスキル登録・
更新期限の３日前であり、現在レスポンスタイムは通常
の２倍近くになっていた。パフォーマンスを向上させる
ためにはシステムの大幅な改修が必要である。しかし、
この時期は顧客企業からの要望が多数寄せられるため、
早急にこの事態を解消する必要がある。そこで私は素早
く講じることが出来る暫定対策を考えることになった。

第２章　暫定対策と本対策の検討経緯と内容
２．１　暫定対策の検討経緯と内容
　今回、１．２で述べたように時間をかけて本対策を行
うことが出来ないため、早期に実施できる暫定対策を実
施することになった。暫定対策を行うにあたっては、実
施の容易さを重視し、それに伴う制限事項やルールを明
らかにすることにした。
　暫定対策の内容としては、今回のレスポンス悪化の原
因はアクセス過多である。そこでアクセスを制限するこ
とでシステムへの負荷を下げる方針で私は対策を考えた。
私は社内の部署毎に本システムにアクセス出来る時間帯
を指定し、アクセスの集中を避けることを考えた。人事
部にこの提案を行い、社内通達により、時間帯ごとに本
システムにアクセス可能な部署一覧を展開してもらう依頼
をし、了承得ることが出来た。しかし、私はこれではシ
ステム上の制約を設けていないため、社員の中にはこの
一覧に従わずに本システムにアクセスするものが出てて
くると考えた。私はネットワークが部署毎に分割されて
ることに着目した。本システムのＷｅｂサーバにはＩＰ
アドレスによりアクセスを制限する機能があるため、こ
の機能を用いて、部署毎にアクセス制限を行うことにし
た。こうすることで、確実にアクセス制限を実施出来る
ため、レスポンスが悪化する事態を避けることが出来る
と私は考えた。暫定対策は、１．２よりスキル登録更新
期限まですることを人事部と合意した。

２．２　本対策の検討経緯と内容
　暫定対策を実施することになったが、根本的な対策に
はなっていない。なぜなら、現在の暫定対策では、パフ
ォーマンスの改善を行っていないため、時間帯ごとに利
用出来る部署が限られる。結果的に、サービスレベルが
低下するため、根本的な原因を解決し、中長期的な安定
運用のための抜本的な対応が必要である。
　根本的な原因を調査するため、パフォーマンス監視ツ
ールの測定結果を確認したところ、ＤＢのアクセス権限
テーブルへのアクセスに時間がかかっていることが判明
した。本システムでは画面遷移や何らかの処理が行われ
る場合、都度アクセス権限テーブルへのアクセスが行わ
れるため、アクセス権限テーブルへのアクセスが集中し
ていたことが、パフォーマンス悪化の原因であると私は
判断した。そこで、アクセス権限情報の取得をＤＢから
取得するのではなく、メモリに同情報を展開し、そこか
ら取得する設計を考えた。メモリから取得することで、
ＤＢアクセスに比べて処理の負荷が低くなり、パフォー
マンスの向上に繋がると私は考えた。
　次に、私はこの対策の実行可能性、作業期間、コスト
、効果を評価することにした。各処理におけるアクセス
権限取得処理は共通化されているため、その共通処理を
変更するだけで対応は可能であることがわかった。修正
範囲が少ないため、作業期間も短く、コストも抑えるこ
とが出来た。また効果については、事前にパイロットテ
スト行ったところ、５０％以上のパフォーマンスの改善
を確認出来たため、問題ないことがわかった。
　私は以上の結果を基に人事部と協議し、本対策の実施
時期を、次回のスキル登録更新期限である10月から１
ヶ月前の９月と明確にし、人事部の了承を得ることが出
来た。

第３章　暫定対策及び本対策の実施結果と課題
３．１　暫定対策及び本対策の評価
　私が実施した暫定対策についての実施結果を述べるこ
とにする。暫定対策では、運用チームにてＷｅｂサーバ
の設定を変更しＩＰアドレスによるアクセス制限を実施
した。この作業を短時間で行う必要が求められたが、
部署毎のネットワークアドレスの情報収集などに手間取
り、時間がかかってしまった。また設定変更そのものも
経験者がいなかっため、スムーズに作業が出来なかった。
結果的に、2時間程度の作業時間を予定していたが、
4時間ほど費やしてしまった。設定変更後は、アクセス
の集中を避けることが出来たため、実施効果に関しては
評価出来ると私は考えている。
　次に本対策では、スケジュール通り、設計・開発・テ
ストを実施することが出来、問題なくリリースすること
が出来た。レスポンスも大幅に改善され、アクセスが集
中した際にもレスポンスが劇的に低下することはなくな
った。以上より私は、実施した本対策は効果があったと
評価している。

３．２　課題
　３．１で述べたように、暫定対策においてスピードが
求められる場面において、早期に対策を実施出来なかっ
たことは課題と認識している。ネットワークアドレスの
情報収集に時間がかかってしまったのは、どの部署で、
ネットワークアドレスを管理しているかを、私の運用チ
ームで把握出来ていなかったためである。今後は、どの
部署、どのチームでどういった情報を管理しているかを
整理し、ドキュメントにして情報システム部内、さらに
は社内全体に展開したいと考えている。
　またＷｅｂサーバの設定変更をスムーズに実施出来な
った点については、今回実施した手順をマニュアル化や、
Ｗｅｂサーバのスキル向上勉強会などをチーム内で開き、
運用スキルの向上に努めたいと考えている。
-----------------------------------------------------------

[513]　タムタム　(2011/09/27 Tue 18:11)

---

Re: Ｈ１９ 午後２　問２

すぎエモンです。僭越ながら査読させて頂きました。

いつもとは違う視点でコメントさせてもらいます。
私がＩＰＡの査読者ならどのような視点で評価するかという
ポイントに絞ってチェックしてみました。
なお、ITサービスマネージャではなく、テクニカルエンジニア（システム管理）
の論文という前提で査読しています。

【論文問題の常識から問われること】
☆文字数が規定内に収まっているか？
　→×：設問アがオーバーしています。わずか２文字のオーバーですが、
　　　　合否に関わる部分なので、文字数の調整はしっかりと行った方がいいでしょう、

☆誤字脱字がないか？
　→△：以下の誤字脱字があるようです。
　　　　「了承得ることが出来た。」
　　　　→「了承を得ることが出来た。」

☆所属する組織を明確に記述しているか。
　→○：情報システム部の運用チームに所属と明記されています。

☆自分の立場を明確に記述しているか。
　→○：運用チームのリーダーであることが明記されています。

☆関連する組織を明確に記述しているか。
　→○：顧客である人事部との関わりがしっかりと書かれています。

☆対象システムを明確に記述しているか。
　→○：社員スキル管理システムであると明記されています。

☆ITサービスマネージャの視点を守っているか？
　→○：運用部門の視点に終始しており、ITサービスマネージャの視点で
　　　　記述されていると感じました。

☆自分の考えを主張しており、これが問題文に準拠しているか？
　→◎：自分の考えがしっかり主張されています。また以下の記述により
　　　　問題文に準拠していると言えます。
　　　　　●暫定対策を行うにあたっては、実施の容易さを重視し
　　　　　●中長期的な安定運用のための抜本的な対応が必要である。
　　　　　●私はこの対策の実行可能性、作業期間、コスト、効果を評価することにした
　　　　上手く問題文を引用できており、合格率の向上に繋がったと感じます。

☆数字を盛り込むことで具体的な記述を行っているか。
　→◎：具体的数字がキッチリと記載されています。タムタムさんの数字に対する
　　　　こだわりの記述を感じました。

【設問から問われること】

☆第１章で携わった情報システムの概要を述べたか？
　→△：「情報システムの概要」を聞かれたのに「ITサービスの概要」を
　　　　答えてしまっています。

☆第１章で暫定対策及び本対策が必要となった課題を述べたか？
　→△：「１．２で述べたように時間をかけて本対策を行うことが出来ないため」と
　　　　書かれているのに実際には１．２では「本対策」という言葉が全く登場していません。
　　　　１．２で「暫定対策と本対策に分けざるを得なかった」と明言した方が題意に
　　　　沿うのではないでしょうか？

☆第１章で対策を分けた理由を述べたか？
　→△：「課題」と「理由」を同じ項目で書いてしまっています。
　　　　できれば分けたほうがよいです。

☆第２章で暫定対策の検討経緯・内容を述べたか？
　→○：暫定対策の検討経緯・内容が２．１で述べられています。

☆第２章で本対策の検討経緯・内容を述べたか？
　→○：本対策の検討経緯・内容が２．２で述べられています。

☆第２章で工夫した点を中心に具体的に述べているか
　→○：私が工夫した点を随所で読み取る事ができます。

☆第３章で暫定対策及び本対策の実施結果についての評価を述べたか？
　→◎：３．１で「暫定対策」と「本対策」とにしっかりと書き分けられています。
　　　　自身の分析も根拠を伴って述べられていて評価できる点ですね。

☆第３章で今後の課題は何かを述べたか？
　→◎：運用の視点での課題とその対応案がしっかりと述べられています。
　　　　３．１で書いた布石を上手く利用している点が高ポイントです。

【問題文から問われること】
☆暫定対策と本対策を分けて検討したか？
　→○：暫定対策と本対策を分けて検討しています。

☆暫定対策は実施の容易さを重視したか？
　→○：「暫定対策を行うにあたっては、実施の容易さを重視した」と明言されています。

☆暫定対策は効果の限界などを明らかにしたか？
　→◎：以下のようにしっかりと効果の限界が記述されています。
　　　　　●根本的な対策にはなっていない。なぜなら、現在の暫定対策では、パフォーマンス
　　　　　の改善を行っていないため、時間帯ごとに利用出来る部署が限られる
　　　　問題文に書かれている記述をしっかりと拾っており、高評価となる部分です。

☆根本原因を追及したか？
　→◎：「根本的な原因を解決し」と明記し、以下のようにしっかりと根本原因を記述しています。
　　　　　●ＤＢのアクセス権限テーブルへのアクセスに時間がかかっている
　　　　ここでも問題文に書かれている記述をしっかりと拾っていますね。お見事です。

☆本対策は中長期的な安定運用のための抜本的な対応か？
　→◎：「中長期的な安定運用のための抜本的な対応が必要である」と明記されています。
　　　　「このように中長期的な安定運用のための抜本的な対応を行った」というような
　　　　記述があるとさらに良かったのですが。今回の記述で十分だと思います。

☆実施方法や実施時期を明確にしたか？
　→◎：実施方法は「メモリに同情報を展開し、そこから取得する設計を考えた」
　　　　と明記されています。
　　　　実施時期は、「次回のスキル登録更新期限である10月から１ヶ月前の９月」
　　　　と明記されています。
　　　　書き忘れやすい「実施方法」と「実施時期」をしっかりと見落とすことなく書いていて
　　　　隙のない作り込みを感じました。

☆実行可能性、作業期間、コスト、効果などを明らかにしたか？
　→◎：実行可能性、作業期間、コスト、効果に対する記述がしっかりなされています。
　　　　この４つの項目に全て言及できている点は素晴らしいと思いました。
　　　　通常の受験者は書き漏らしやすい場所です。

☆必要以上に暫定対策を継続しなかったか？
　→○：暫定対策は、１．２よりスキル登録更新期限まですることを人事部と合意しており
　　　　必要以上に暫定対策を継続しなかった事が確認できます。

【総評】
従来の論文と比べて、とても良く書けていると思いました。メキメキとレベルアップしている
という迫力を感じます。特に問題文に対して「忠実に応えるぞ！」という気迫がありますね。
具体的数字を明記する点も良い個性だと思います。

△と×を付けたポイントに対する改善がなされれば、更によい論文になると思います。

[514]　すぎエモン　(2011/09/30 Fri 19:47) mail

---

Re^2: Ｈ１９ 午後２　問２

お世話になります。

今回も丁寧に添削・ご指導いただきありがとうございました。

今回から今までは違う視点でコメントを頂けているのですが、私個人の感想としては、非常に良い方法だと思いました。

実際の採点のポイントと論文の該当箇所をセットにしてコメントしてもらっているので、問題点がよりはっきりとわかるようになりました。

悪い箇所だけでなく、良い箇所も理由を付けてコメントして下さっているので非常に参考になります。

サービスにもよると思うのですが、私が前回利用した有料の添削サービスよりも丁寧に添削してもらっていると思うので、すごく助かっています。

毎回ありがとうございます。

☆第１章で対策を分けた理由を述べたか？
確かに「課題」と「理由」は分けた方が読みやすいですね。

誤字脱字は今後も気を付けます。

[515]　タムタム　(2011/10/05 Wed 14:03)

Ｈ２２ 午後２　問２

お世話になります。

また一つ論文を書きました。今回の問題は正直、自信がなく題意から外れている可能性があります。

「人的リソースの確保」で論述を行うと思ったのですが、いい題材が浮かばず、自分としては「運用機能の改善」でまとめたつもりです。ただこの「運用機能の改善」に対して誤った認識をしている気がしました。

お時間がある時で結構ですので、ご意見をお聞かせいただければと思います。

あと文字数に関しても空白文字を考慮するようにしてみました。

第１章　ＩＴサービスの概要とリリースの検証と受入

１．１　ＩＴサービスの概要
　Ａ社は従業員が１０００人程度のソフトウエア開発企
業であり、システム開発と人材派遣サービスを中心に事
業を展開している。Ａ社には人材派遣サービスの効率化
を目的としたシステムである社員スキル管理システム、
その他、プロジェクト管理システムなど多くの社内シス
テムが稼働している。私が所属する情報システム部では、
各社内システムの開発・運用を担当しており、システム
ごとに開発チームと運用チームが存在する。私は社員ス
キル管理システムの運用チームのリーダーである。私の
チームのＩＴサービスの内容は、本システムのヘルプデ
スク、変更管理、インシデント管理、性能管理である。
顧客は人事部であり、以下のＳＬＡを締結している。
・年間稼働率　９７％（非営業日はシステムは稼働しな
いため除く）
・社員検索処理のレスポンスタイム　５秒以内
・障害発生時の復旧許容時間　１時間

１．２　リリースの検証と受入
　私が担当したリリースは、アクセス権限データをサー
バ起動時にメモリに展開する機能強化のリリースである。
画面遷移の度に、DBよりアクセス権限レコードを取得す
るのではなく、メモリから取得することでレスポンスの
向上を図るものである。
　リリースの検証と受入のため、私はテスト環境を構築
した。次に開発チームにて、変更を実装した後、リリー
スの検証・受入を実施する。まず運用チームで作成した
運用テスト計画と本番切り替え手順を開発チームが検証
する。問題がなければ、顧客である人事部による最終検
証が実施される。その後、運用チーム立ち会いの下、開
発チームによる本番環境へのリリースが実施される。

第２章　リリースの検証及び受入で発生した問題と問題に
対して人事部と協議した内容

２．１　リリースの検証及び受入において発生した問題

　開発チームによる実装が終わり、運用チームが作成し
た運用テスト計画によるテストが実施された。次に、人
事部によるユーザテストが実施された。その人事部のユ
ーザテストにおいて問題が発生した。その問題とは、本
システムのアクセス権限変更画面よりアクセス権限を変
更しても、その変更が反映されないというものであった。
人事部より障害票が起票され、その内容を元に調査した
ところ次のような原因が判明した。アクセス権限データ
のメモリ展開はサーバ起動時のみに実施されている。そ
のため、アクセス権限変更画面よりDBのアクセス権限デ
ータを変更してもメモリに反映されない。そのため、DB
のレコードを更新するだけでメモリに変更後のデータを
反映しないアクセス権限変更画面の更新処理では、すぐ
にシステムに反映されないという事態が発生していたこ
とが、私の運用チームの調査により判明した。

２．２　人事部と協議した内容

　私は今回発生した障害に対して、次の２つの対策を検
討した。
（１）DBのアクセス権限データが変更されるとメモリ上
のアクセス権限データにも反映する。
　利用する人事部からするとこの方法が最もよいと考え
られる。パフォーマンスが向上し、今回の障害も解消さ
れる。しかし当然、開発・運用チームによる実装の修正
が必要となる。またテストもやり直しとなるため、リリ
ースを延期する必要が出てくるという問題が発生する。
（２）ユーザ運用による対応
　今回の変更は、サーバ起動時にアクセス権限データを
メモリに展開するものであるが、本システムのサーバは
毎朝６時に再起動を行っている。そのため、その日にア
クセス権限変更画面より変更した内容は、次の日の朝に
はメモリに展開されており、システムに反映されている
ということになる。つまり、ユーザにアクセス権限の変
更は即時に反映されず、次の日の朝から反映される仕様
でも業務の運用に問題がなければ私はこの方法が最も良
いと考えた。なぜなら、再度システムの改修を行う必要
がないため、追加の改修コストを抑制することが出来、
予定通りリリースすることが出来るからである。
　私は、上記の２つの対策を人事部と協議することにな
った。協議した結果、人事部としてはアクセス権限デー
タは頻繁に変更されるものではなく、緊急を要するアク
セス権限の変更は運用上発生しないということであった。
私は人事部と今後の本システムの運用マニュアルにつ
いても協議し、アクセス権限の変更については翌日に
反映されるという運用の変更で合意することが出来た。

第３章　問題の根本原因と再発防止に向けた対策

３．１　問題の根本原因

　今回、人事部との協議の結果、無事リリースをするこ
とが出来たが、人事部より指摘のあった件は運用チーム
の運用テスト計画の品質に問題があったことを厳しく追
求された。そこで私は、今後こういったインシデントが
発生しないように今回の根本原因を究明することにした。
今回の変更管理プロセスからリリース管理プロセスにか
けて分析を行った。

　分析の結果、根本原因は変更管理プロセスで作成され
る運用テスト計画が本システム初回リリース時のものが
使い回されていることであった。本システムの初回リリ
ース時にはアクセス権限を変更する機能はなく、その後
追加された機能である。本来であれば、この機能追加の
変更管理プロセスの中で運用テスト計画にこの追加機能
が反映されるべきであったが、その反映が漏れていた。
そして今回のアクセス権限機能の変更においても、当初
の運用テスト計画がそのまま使われていたため、テスト
が漏れてしまっていた。

３．２　再発防止に向けて講じた対策

　以上より、再発防止に向けて、講じなければいけない
対策は明白であり、それは機能の追加・変更・削除など
システムに変更があった場合、その変更を反映した運用
テスト計画を作ることである。そのためには、今後はそ
のように変更管理プロセスを実施すればよいことになる
が、私はこの作業が漏れないように運用管理ツールを次
のような変更を加えることにした。同ツールの変更管理
機能の中で、運用テスト計画の見直しプロセスをワーク
フローに加えることにした。もし運用テスト計画に変更
を加える必要がなければその理由を入力させるようにも
した。このようにシステム化することで、運用テスト計
画の見直しをプロセスとしてチーム内に定着させること
が出来ると考えた。

　　　　　　　　　　　　　　　　　　　　　　ー以上

[510]　タムタム　(2011/09/18 Sun 09:43)

---

Re: Ｈ２２ 午後２　問２

すぎエモンです。僭越ながら査読させて頂きました。

【良いと感じた点】

・論文が規定の文字数に全て収まったようです。
　前回まではぎっしり書き込んでいて、本番での時間不足を心配しましたが。
　今回はしっかりと理想的な文字数にまとめてきていることを感じました。
　この量の記述なら、後で見直しをする時間も確保できるのではないかと
　思います。

・設問アについては前半のＩＴサービスの概要も簡潔で分かりやすく、
　後半のリリースの検証と受入の概要も短い文章で分かりやすくまとめており、
　良い点であると感じました。

・私の立場が「運用チームのリーダー」となり、ITサービスマネージャに
　より相応しいスタンスになっていると感じました。また、意識して
　「私はこのように行動した」という記述をなさっているという努力が
　文章に表れていました。

・設問イの問題点と解決策が「わかりやすい問題点」「わかりやすい解決策」
　であり、読みやすく、理解しやすかったです。問題点や対策が難解な記述に陥って
　しまう人も多いので、いいポイントではないでしょうか。

・「人事部より障害票が起票され、その内容を元に調査した」という記述は、いいですね。
　運用の現場がしっかりとルールに従って運営されている事を臭わせる記述です。

・「運用チーム」「開発チーム」「人事課」という３者をそれぞれのスタンスでしっかりと
　書き分ける事ができている点がこの論文のストロングポイントではないかと感じました。
　全般的に「Who＝どの部門が」「What＝なにをした」というのが常に明確ですよね。

・Ｑ：リリースの検証の時、どのような準備をしたか？
　→Ａ：受け入れテスト環境の構築を行った。
　Ｑ：発生した問題は何か？
　→Ａ：受け入れテストの結果、運用機能の改善が必要であると判明した。
　という記述になっており、しっかりと問題文の例にならって、題意に答え
　ようとしている意図が感じられます。
　題意から外れているという印象は受けませんでした。

【気になった点】

・設問アで、年間稼働率97%とありますが、これはメンテ作業を含まない
　システムの非ダウンタイムの事を想定していますかね？
　だとするとちょっと気になる部分があります。
　例えば2011年度は以下のような見積もりになります。
　　平日日数：243日　、一日の運転時間：12時間
　　見込稼働時間：2916時間　、　年間稼働率＝97%とすると、
　　システムのダウン時間は90時間まで許容される事になります。
　こんなにダウン時間基準が緩くて大丈夫でしょうか？
　社内システムだからちょっと緩くていいのかも知れませんが
　障害発生時の復旧許容時間＝１時間と厳しいのでチグハグな感じがします。
　年間稼働率＝99%以上の書き方の方が無難なのかも知れません。
　ただし、ミッションクリティカルな業務ならさらに厳しくする必要がありますが。

・設問アで、人事部との間にＳＬＡを締結していますね。ＳＬＡを明記する事は
　ITサービスマネージャ論文としては悪くないのですが、今回のケースでは
　その後に続いていく論文内容に対して関係の無い記述になってしまっています。
　査読者はＳＬＡを「重要な布石だろう」と注目しているのに、肩すかしを
　くらうような感じになります。なので、論文の後半部分でうまくＳＬＡを
　絡めて記述するか、それとも今回に限ってはＳＬＡの記述自体を削除して
　しまった方がいいかも知れません。
　削除する場合、空いたスペースに、今回の主題（≒根本原因）となる「運用
　テスト計画の現状」をそれとなく布石として記述しておけば、論文として
　一貫性が保たれ、合格率を高められるのではないでしょうか。

・設問イは以下のような構成になっていますね。
　　「２．１　リリースの検証及び受入において発生した問題」
　　「２．２　人事部と協議した内容」
　しかし設問イを読むと以下の小項目を付け加えた方が良さそうです。
　　「２．３　実施した対策」
　この論文では、「２．２　人事部と協議した内容」の部分で実施した対策の
　ことを記述しているのですが、設問イで問われている事に忠実に答えるという
　視点から考えると、項目をキッチリ分けて、別々に記述した方が、題意に沿う
　のではないかと考えました。

・設問イ（２）ユーザ運用による対応の部分では、”具体的対策”をもう少し早い段階で
　分かりやすく記述した方がよいのではないかと考えました。
　対策については設問イの最後で「アクセス権限の変更については翌日に反映される」
　と記述されているのですが、最後に書かれてしまうと読んでいる途中で、「肝心な
　部分が抜けているのでは」といった感覚になります。
　「ユーザ運用による対応」→「リリース内容の翌日反映の許容」とすぐに結びつく
　書き方の方が分かりやすいのではないかと感じました。

・設問ウで述べている「３．２　再発防止に向けて講じた対策」は
　「３．２　再発防止に向けて講じた施策」という書き方にした方が
　設問に忠実になるのではないでしょうか。もしかしたら出題者は
　設問イでは”対策”、設問ウでは”施策”と言葉を使い分けたいのかも
　知れません。
　よって、３．２の部分は用語も全て「対策→施策」と書き換えた方が
　無難ではないかと考えます。

・全般的に「私はこのように考えた」という記述がもう少し欲しいです。
　5W1Hの「Why＝なぜそうしたのか」という部分ですね。
　今回のケースでは、問題文を引用し、以下のような記述を追加するとよりよい
　論文になると考えます。
　→リリース管理については、リリースの内容を把握した上で、適切な実装計画を立案
　　し、確実に実施するためのマネジメントを行う事がが重要であると私は考えた。
　→私は、再発防止に向けて、発生した問題の根本原因を究明し、適切な施策を講じな
　　ければならないと考えた。
　　なお、根本原因の究明に当たっては、リリースの検証及び受け入れ、又はリリース
　　管理の視点に留まらず、他の管理プロセス（変更管理・構成管理など）、更には稼
　　働環境、運用基準なども含めた、分析を行う事が重要であると考えの元、広範な視点
　　から再発防止に取り組む事にした。

[511]　すぎエモン　(2011/09/20 Tue 23:23) mail

---

Re^2: Ｈ２２ 午後２　問２

いつもありがとうございます。

そうですね、年間稼働率97%は緩すぎるかもしれませんね。メンテ時間は考慮していませんでした。非営業日にシステムを停止する前提でいましたので。

年間90時間もシステムの停止を許容するのはおかしいと思うので、99.5%にしたいと思います。

なるほど、確かにSLAの部分は読み手には肩透かしな感じになるかもしれませんね。やっぱり後の内容と連動しないと気持ちが悪いと思うので、修正したいと思います。

読み返してみると、「２．２」は題意にはない内容が盛り込まれていますね。気付きませんでした。これも新たに小項目を設けたいと思います。

「アクセス権限の反映が明日」というのは、確かに前で記述しておくべきでしたね。後から後からでは、確かになんというか真実味が欠けるというか。

今回は、「自分はこう考えた」みたいなところを強調したつもりだったんですが、改めて読み直してみると、なぜそう考えたか薄い印象は確かにありますね。

次はもっとその辺りを意識して論述したいと思います。

毎回、非常に参考になります。
ありがとうございました。

[512]　タムタム　(2011/09/21 Wed 11:16)

Ｈ２１ 午後２　問１

いつもお世話になります。以前指摘いただいたように、別の題材で論文を書いてみました。毎回お手数おかけして申し訳ないのですが、まだまだ的外れなことを書いている可能性があるので、よろしければご意見をお聞かせ下さい。

問題：
http://www.jitec.jp/1_04hanni_sukiru/mondai_kaitou_2009h21_2/2009h21a_sm_pm2_qs.pdf
問１

論文：
第１章　私が携わったITサービスと変更管理プロセス

１．１　私が携わったITサービスの概要
　A社は社員数が１０００人ほどのソフトウエア開発企
業であり、システム開発及び人材サービスを主な事業
としている。A社には、社員スキル管理システムやプロ
ジェクトタスク管理システムなどの多数の社内システ
ムが存在している。A社には、これらの社内システムの
開発・運用・管理を担う情報システム部が存在してお
り、各システム毎に開発担当・運用担当チームが存在
している。私は員スキル管理システムの運用チームに
所属しており、顧客は人事部、ユーザーは全社員であ
る。ITサービスの内容は、ユーザーからの問い合わせ
対応、障害対応、変更要求対応や可容性及び性能管理
である。

１．２　変更管理プロセス
　社員スキル管理システムの運用における変更管理プロ
セスは以下のとおりである。なお、変更要求は運用管理
ツールの変更要求プロセス管理機能を用いており、変更
要求の内容は、CMDBにて管理されている。
�@変更要求の受付、評価・分析
　変更要求は全て人事部より起票される。起票された
変更要求を運用チームで評価・分析を行い、優先順位
と分類を行う。
�A影響分析
　基本的に運用チームにて影響分析を行い、内容によ
っては開発チームに依頼し、その結果を運用チームが
確認する。
�B承認・否決
　人事部の担当者と情報システム部のマネージャー、
運用チームのリーダーが�@�Aの結果をもとに、変更
要求の承認・否決を行う。
�C実施
　変更要求の実装方法、テストとスケジュールを検討し、
チーム内レビューを行う。その後、リリース管理にて
実装を実施する。開発チームでのテスト実施、または
人事部の受入テストにて問題がないことを確認し、リ
リースを行う。
�D変更実施後のレビュー
　実施作業の正常作業を確認し、CMDBを更新する。
その後、実装された変更要求の評価を行う。

第２章　変更管理プロセスで発生した事象
２．１　発生した変更要求の事象とその原因
　A社では、毎年４月と１０月の２週目までに、社員ス
キル管理システムを使用して自分の業務経歴と保有ス
キルを更新することになっている。しかし、中にはそ
の期限内に業務経歴・スキルを更新しない社員も多数
存在していた。社員スキル管理システムの顧客である
人事部は、この自体を問題として捉え、システムに次
の機能の追加実装の変更要求が発生した。その機能と
は、４月と１０月の２週目の月曜日の時点で、社員ス
キル管理システムの自身の業務経歴・スキルが未更新
である社員を抽出し、更新督促メールを一括送信する
機能であった。
　情報システム部の同システムの運用担当チームでは、
この変更要求の受付を行い、１．２の変更管理プロセ
スを経て、追加機能の実装を行うことにした。開発チ
ームによる実装・テストもスケジュール通りに完了し、
人事部による受入テストを実施することになった。こ
こで問題が発生した。テスト環境にて、更新督促メー
ル対象社員の数が１０名を超えた時、メール送信がエ
ラーとなってしまった。エラーログから原因を調査し
たところ、A社のメールサーバでは、１０名を超える宛
先を設定すると送信エラーとなる仕様であることが判
明した。これは、A社のメールサーバなどネットワーク
全般を管理しているネットワークグループ部にヒアリ
ングしたことで判明した。

２．２　原因となった変更管理プロセスの問題点
　原因が発覚した時点で、ネットワークグループ部に
更新督促メールを送信するアカウントに対してのみメ
ールの宛先数の制限を解除してもらうように依頼し、
無事１０名を超える場合でも更新督促メールを送信す
ることが出来、リリースすることが出来た。しかし、
情報システム部では今回のようにA社のネットワークの
制限により変更管理プロセスを経てリリースした機能
でインシデントが過去にも発生していた。そこで情報シ
ステム部マネージャー、及び各システムの運用と開発
担当チームのリーダーが今回の問題の原因と対策につ
いて話しあうことになった。その結果、問題の原因は
以下のように整理された。それは、変更管理プロセス
における影響範囲の調査において、今回のようなメー
ルサーバなどの社内ネットワークが関連する変更であ
っても、ネットワークグループに確認するというプロ
セスが存在していなかった。今回のようにネットワー
クグループしか把握していない制約が存在することが
わかったため、私もこれが根本原因であると確信した。

２．３　変更管理プロセスの問題点に対する改善策
　２．２の変更管理プロセスの問題を改善するための
対策を講じることになった。基本的な対策としては、
社内ネットワークが関連する変更要求に関しては、ネ
ットワークグループ部に実装方法に問題がないことを
確認すればよいことになる。しかし、これではネット
ワークグループ部に確認を依頼する基準が曖昧である
ため、影響分析の結果、社内ネットワークに影響がな
い変更要求であっても、実は影響しているといった結
果になりかねない。そこで私は、ネットワークグルー
プ部の上位職に相談して、全ての変更要求に対する影
響調査結果をレビューしてもらえるように依頼するこ
とにした。当然、レビューを依頼するため、ネットワ
ークグループ部に作業負荷がかかることになるが、レ
ビューは社内ネットワークに関係する部分だけでよい
という条件を提示し、承諾してもらえることになった。
これにより、社内ネットワークの制約による変更要求
に対する影響調査の精度を高めることが出来、変更管
理プロセスの確実な実施につながると考えた。

３．１　変更管理プロセスの定期的な確認方法
　私は、今回の改善策を含め、変更管理プロセスが確
実に実施されていることを定期的に確認する必要があ
ると考えた。なぜなら、定期的にプロセスの実施状況
を確認することで、事前に変更管理プロセスで発生す
る可能性のある障害や変更ミスを防止出来るからである。
私は、以下のように内部監査を実施することを提案し
た。
（１）ユーザ受入テストにおいて、影響調査が不
十分であったことが原因による差戻しの割合
今回のように変更管理プロセスにおける影響調査が不
十分であったことから問題が発生するケースが存在す
る。今回はなかったが、これが原因で他のシステムや
社内ネットワークに影響を与え、重大なインシデント
になる可能性が否めない。そこで私は受入テストにお
いて、影響範囲の調査が不十分であったことから差戻
しになった割合を定期的に確認することにした。具体
的には変更要求１０件に１件以上の割合で差戻しにな
っている場合は、今回と同様の原因と対策について
会議を行うことをルール化した。
（２）ネットワークグループ部のレビュー実施状況
　今回の改善策で、ネットワークグループ部に変更要
求の影響調査結果のレビューを依頼することになった
が、それが確実に実施されているかを確認する必要が
ある。そこで私は、変更要求１０件の内レビュー指摘
が２件以下の場合、ネットワークグループ部にレビュ
ーの実施状況をヒアリングし、レビューが確実に実施
されていることを確認することにした。これにより、
レビュー実施の形骸化を防止することが出来ると考えた。

３．２　今後の課題
　今回の改善策で、ネットワークグループ部に影響調
査結果のレビューを依頼することになっているが、や
はり全ての変更要求に対して依頼するのは問題である。
なぜなら、場合によって人事部からの変更要求が集中
することがあり、ネットワークグループ部のレビュー
がボトルネックになる可能性があるからである。そこ
で今後は、全ての変更要求の影響調査結果をレビュー
してもらうのではなく、運用チームでも社内ネットワ
ークに対するスキルとノウハウを蓄積し、またネットワ
ークグループ部との情報共有を行い、チーム内で影響
調査作業を完了出来る範囲を増やしていくことを予定
している。

　　　　　　　　　　　　　　　　　　　　　ー以上

[505]　タムタム　(2011/09/11 Sun 20:06)

---

Re: Ｈ２１ 午後２　問１

すぎエモンです。僭越ながら査読させて頂きました。

【良いと感じた点】
・設問アの冒頭部分で、会社の説明、システムの説明、私の説明、ITサービス
　の説明をそれぞれ区別してしっかりと説明出来ている点は素晴らしいと思います。
　論文の本題に関係の無いシステムに関する説明は冗長な記述になるので
　書かない方がいいのですが、ここでの記述ではさほど冗長とは感じませんでした。

・設問ウで「私は、今回の改善策を含め、変更管理プロセスが確実に実施されて
　いることを定期的に確認する必要があると考えた」という表記は自分の考えを
　装いつつ問題文表記を上手に取り入れているというテクニックですね。
　「私の考えを述べる」ことと「問題文に準拠する」という両方の課題を
　同時に実現する巧みなテクニックだと思います。
　さらに、「なぜなら〜」という書き方でITサービスマネージャの視点での
　理由まで説明できていて、「定期的にプロセスの実施状況を確認することで、
　事前に変更管理プロセスで発生する可能性のある障害や変更ミスを防止出来る
　からである」とまとめられている部分は非常に好印象でした。

・設問ウの「変更要求１０件に１件以上」「変更要求１０件の内レビュー指摘
　が２件以下」といった具体的な数値を交えた記述についてはいつもながら
　説得力があります。「レビュー実施の形骸化を防止」という記述もいいですね。
　どこの現場にもありがちな「レビューの形骸化」という点に意識を向けたと
　いうのは好印象でした。

・論文全般的に言えることですが、時期や人数、件数などとにかく具体的数値の
　記述が徹底されており、こだわりを感じました。これにより、論文記述内容の
　「ぼんやりとした表現」が排除され、具体性と説得力の向上に寄与していると
　思います。

・設問ウの「今後の課題」については、理想として掲げた対策とそれに対する現実
　とのギャップという事を記述しており、分かりやすく、かつリアリティがありました。

【気になった点】
・設問アは、大幅に文字数をオーバしているようです。
　私が数えた限りは、25文字×35行＝975文字でした。
　行末の空白文字が文字数に含まれていることにご注意下さい。

・設問アの変更要求プロセスは、箇条書きで詳細に記載されており、
　とても分かりやすいのですが、その分文字数が多くなりすぎている
　ようです。もう少しなにかを削って短くする必要がありそうです。

・「第１章　私が携わったITサービスと変更管理プロセス」
　「第２章　変更管理プロセスで発生した事象」
　という流れになっているのに
　「第３章　変更管理プロセスの確認方法と今後の課題」
　という記述が見あたりませんでした。

・設問イで「私はこのように考えた」「私はこのように工夫した」
　という記述が少ない印象を受けました。
　設問ウで問題文表記を上手に取り入れているので、設問イでも以下のよう
　に付け加えると更に合格率が高まるのではないでしょうか。
　　「私は、このような場合には、その原因となる変更管理プロセスの
　　　問題を特定し、その改善策を立案・実施することによって、
　　　再発を防止しなければならないと考えた。」
　
・変更管理プロセスの問題点は「ネットワークグループに
　確認するというプロセスが存在していなかった」という点ですが
　以下の２点が気になりました。
　　�@ポイントになる部分なのに、目立たない。
　　　もう少し、カッコで括るとか箇条書きにするとかで
　　　目につきやすくすると査読者にも「何が問題なのか」が
　　　分かりやすくなると思います。
　　�A問題点見極める段階での記述者の関わりが薄い
　　　もっとも重要なポイントとなる問題点を見定める際に「私」が
　　　当事者になりきれていません。このケースなら
　　　　私＝「情報システム部マネージャー」 or 「運用部門リーダ」
　　という立場にして、「自分が中心となってこの問題を発見した」ぐらい
　　言い切った方が、論文としては説得力が増すのではないでしょうか？

・文字数が多すぎませんでしょうか？私が数えた限り
　設問ア：975文字、設問イ：1575文字、設問ウ：1000文字
　となっています。本番では手書きの上、以下の部分で時間が余計に
　必要になります。
　　�@アンケートに答える時間
　　�A問題文を選択する時間
　　�B構想を練る時間
　　�C書き終わった後見直す時間
　　�D誤りを修正したり、忘れた漢字を思い出す時間
　これらの為の時間消費を考えると、文字数が多いと時間オーバーで
　最後まで記述できないというリスクがあります。
　よって、どちらかというと、文字数は最低文字に近い方が
　合格率が高くなるのではないかと考えています。

[506]　すぎエモン　(2011/09/12 Mon 20:49) mail

---

Re^2: Ｈ２１ 午後２　問１

どうも添削していただきありがとうございます。

字数は気をつけて計算したつもりなんですが、またオーバーしていましたね。申し訳ないです。いつもExcelで論文を書いて計算しているのですが、計算式を見直します。

どうしても第三者にわかりやすく書こうと思うと、詳細に書かないと疑問に思われると思ってしまい、字数が増えてしまうと自分でも感じていました。もう少し削れる部分を検討してみたいと思います。

確かに問題イ、ウを書いてる途中から「自分が」という論述になっていないですね。事実をただ羅列してる感じは、確かに説得力に欠けるものになってるのは、ご指摘通りだと思います。

・文字数を意識し、削れる部分を意識する。
・もっと当事者視点で論述し、自分の行動として強調する。

以上のことに気をつけて、次の論文を書きたいと想います。

図々しいお願いですが、また添削していただけると助かります。
いつもながら頂いたご指摘は非常に参考になります。

ありがとうございました。

[509]　タムタム　(2011/09/17 Sat 08:20)

V3　or　V2

今回、はじめてITSMを受験予定のみちろうといいます。
こちらのサイトで色々と勉強させていただいています。
ありがとうございます。

ところでITSMはITILベースとのお話もあったと思うのですが、この場合、V3を学習した方が良いのでしょうか？
それともV2で良いのでしょうか？

こちらの記事を読む限りでは「V3ではITSMとの関連が薄れた」様に思えます。

ITILは以前V2を少し勉強した程度なので、ITSMの前に学習しようと考えていたのですが、V3にするべきか迷っています。

アドバイスをいただけると嬉しいです。

[507]　みちろう　(2011/09/16 Fri 20:17)

---

Re: V3　or　V2

ご質問に対する見解については、重点対策P57あたりから述べております。もしお持ちでしたらその内容もご確認ください。

基本的にはV2で十分です。
V3の内容は補完的でよいでしょう。

また、ITサービスマネージャはITILに沿っていますが、ITILの試験ではありません。よって、ITILを理解するのは大事ですが、ITILを覚えたから合格できる試験ではありませんし、逆に最低限の理解で合格されていらっしゃる方も多数います。

[508]　管理者　(2011/09/16 Fri 20:36)

Ｈ２２ 午後２　問１

ITサービスマネージャーの試験勉強を始めて、１週間になります。
「専門知識+午後問題」の重点対策を一通り読み、一度論文を書いてみました。はっきり言って、これまで運用・保守を経験したことがなく、恥ずかしながらCMDBや運用管理ツールの存在を知りませんでした。なので、大分的外れなことを書いているかもしれないのですが、よろしければ添削していただけると幸いです。

１．私が携わったITサービスとCMDBの利用において発生した問題

１．１　私が携わったITサービスの概要
　A社は社員数が１０００人ほどのソフトウエア開発企業であり、システム開発及び人材サービス
を主な事業としている。A社には、社員管理システムやプロジェクトタスク管理システムなどの
多数の社内システムが存在している。A社には、これらの社内システムの運用・管理を担う情報
システム部が存在しており、各システム毎に担当チームが存在している。私が担当している
ITサービス、すなわち担当しているシステムは社員管理システムであり、顧客は人事部、
ユーザーは全社員である。ITサービスの内容は、ユーザーからの問い合わせ対応、障害対応、
変更要求対応や可容性及び性能管理である。

１．２　CMDBの利用において発生した問題
　情報システム部では、社内システムの運用・管理を効率的に行う目的で運用管理ツールを導入
しており、そのツールにはCMDBによる構成管理機能が備わっている。そのCMDBを用いて、
各システムの担当チームでは、問い合わせ履歴、ハードとソフトの管理、インシデント・問題管理、
別システムとのデータ連携の管理、を行っていた。
　ある日の朝、社員管理システムのサービス起動障害が発生した。私はサービスが起動してい
ないことを確認した後、CMDBより社員管理システムの社員データに依存している社内システム
がないか確認を行い、依存している社内システムに至急連絡をした。これにより、サービスの一時
停止を早い段階で社内に通知することが出来た。しかしその後、研修管理システムでエラーが発生
し、社員管理システムの社員データを参照出来ない事が原因であった。研修管理システムは
CMDB上社員管理システムのデータを参照していなかったが、それは研修管理システム担当者
のCMDBの更新漏れであることが判明した。

２．問題に対する改善策と工夫点

２．１　改善策
　私たち情報システム部では、今回のインシデントを受けて、改善策を考えることにした。元々の原因
はCMDBの更新漏れである。１ヶ月前に、研修管理システムでは独自に保有していた社員データを
参照するのではなく、社員管理システムが社内システムのみに公開している社員データを参照する
変更をリリースした。その時に、運用管理ツール上よりCMDBの更新を行っていたが、その更新に
原因があると仮説を立てた。そこで、研修管理システムの運用・管理担当チームのリーダーにヒアリング
を行った。その結果、CMDBへの更新そのものは自分の部下に指示を出して行わせていること、また
部下が更新した内容をリーダーが確認をしていないということが判明した。さらに現在の運用管理
ツールの入力画面では、他システムのデータに依存するどうかは、依存する・しないのラジオ
ボタンを選択し、何システムの何データに依存しているかについては、フリーフォーマットでテキスト
エリアに入力する方法であった。そのため、入力する人により、システムの名前、データの名称が
微妙に異なるといったことが発生しており、それが今回の社員管理システムに依存しているシステム
の検索の完全性を低下させている可能性が高いという結論に至った。
　そこで今回の結果より、以下の２つの改善策を提案した。
�@CMDBに対する登録・更新の承認体制の確立
これまで部下がCMDBに対して行う登録・更新に対し、チームのリーダーによるレビュー・確認が徹底
されていなかった。そこでレビュー・確認を徹底させるため、運用管理ツールに元々備わっていた、
ワークフロー機能を活用することにした。メンバーが入力した内容は、自動的にチームのリーダー、
運用部のマネージャーに承認依頼が届くようになる。さらに、この承認の決済が下りない限り、実装
してはいけないという運用ルールを設けた。以上の策を講じることで、CMDBに対する誤った更新や
入力漏れを排除することが出来るため、CMDBのデータの正確性が確保されると考えた。
�A「他システムのデータに依存する」入力項目のシステム名・データ名のプルダウン化
依存しているシステムやデータの名称が人により、微妙な差異があることに対する対策である。
こういった属人性を排除するために、テキストエリアに入力する方式ではなく、システム及びデータを
プルダウンから選択する方式にカスタマイズすることにした。プルダウンの内容はCMDBでマスタ
管理されているシステム名やデータ名を表示する。こうすることで、テキスト入力であったような、
人による表現の微妙な差異、入力ミスを排除することが出来ると考えた。

２．２　工夫した点
　�@のような承認体制を確立を確立することで、部下の入力ミスや漏れを見地出来るようにはな
った。しかし今回のインシデントを振り返った時に、社員管理システムに依存しているシステムを
検索した時に、研修管理システムが検索結果に表示されなかったことに対して少しでも疑問を
持つことが出来れば、未然に防ぐことが出来たのではないかと考えた。そこで私は、「他システム
のデータに依存する」入力項目で選択されたシステムのリーダーを承認者に追加するという
運用ルールを設定した。こうすることで、自担当のシステムのデータが他システムから参照されて
いるかをリーダーが認識することが出来る。結果、今回のようなインシデントを未然に防ぐことが
出来る確率が高まると考えた。
　また、上記の承認者の追加という運用が徹底されているかを定期的にチェックする仕組みを
設けた。具体的には、CMDBより、「他システムのデータに依存している」入力項目にチェックが
あるにも関わらず、承認者フィールドに他システムの承認者が設定されていないデータを検索
することで実現することが出来ると考えた。

３　改善策の効果と評価及び今後の課題

３．１　改善策の効果と評価
　�@の改善策の効果を測定することにした。測定方法は、リーダーの承認結果が差し戻しとなった
件数を図ることとした。一回の承認依頼あたり、平均２．５回の差し戻しが発生していることがわ
かった。簡単な入力ミスや表現が適切出ないなどが差し戻しの理由の大半を占めていたが、中
には他システムのデータに依存する変更リリースを行うにも関わらず、チェックボックスにチェック
を付けないといった重大なミスも発見されていた。承認体制をシステム化したことで、CMDBの
データの正確性を向上させることが出来たと言える。また各リーダーからは、自担当のシステム
のデータが他システムからどれだけ参照されているかを承認依頼が届くたび確認することが
出来るため、自担当のシステムの重要性を認識することが出来ると好評価であった。
　�@�Aの対策による効果を測定するため、一度マネージャーとリーダーを招集し、実際にその場
で、あるシステムがどのシステムのデータに依存しているかを検索し、検索結果を全員でレビュー
することになった。各システムで検索を実行し、それらの検索結果をリーダーが確認し、問題が
ないことを確認出来た。�@�Aの改善策は、有効であった評価している。

３．２　CMDBの更なる活用に向けた課題
　今回、運用管理ツールにおける承認体制を採用したのは、変更リリースにおけるCMDBの更新
時の場合だけであった。今後は、インシデント管理、問題管理などCMDBの更新を伴う入力に
関しては承認体制を適用したいと考えている。しかしここで一つの課題が存在する。それは、承認者
の確認・レビューによる作業負担が増加することである。現在、承認者は情報システム部の運用部門
のマネージャーと、各チームのリーダーのみである。今後は各チームのサブリーダーにも、承認作業
を担ってもらうことで、承認作業の負荷分散の体制を整えることが、承認体制適用の第一歩であると
考えている。

[498]　タムタム　(2011/08/29 Mon 20:33)

---

Re: Ｈ２２ 午後２　問１

タムタムさん。はじめまして、すぎエモンです。
僭越ながら査読させて頂きました。

【良いと感じた点】
・「１．１　私が携わったITサービスの概要」の文章は読みやすく理解しやすかった
　ですね。もしかして、過去問題の午後１の文章を参考にしたのでしょうか
　そうならば、とてもよい工夫だと思います。

・承認を徹底させる工夫ににワークフロー機能を使って利便性を挙げるという工夫は、
　わかりやすく現実的な工夫ですね。時代のトレンドをうまく取り入れている事も
　好ポイントだと思います。

・属人性を排除するという考え方で対策を取るという記述は、ITサービスマネージャ
　の視点としてとてもいいですね。その為に「テキスト入力」を「プルダウンから
　選択する方式」にするという対策は初心者でもわかるほど明快な対策で理解
　しやすいです。

・改善策の効果で、「平均２．５回の差し戻し」と、曖昧さを排除してキチンと
　定量的に評価している点は素晴らしいと思います。また、この結果を踏まえて
　客観的に分析を加えた上、「CMDBのデータの正確性を向上させることが出来た
　と言える」と評価を断定できている事も論文として説得力が増す書き方になって
　いますね。

・最後の「３．２　CMDBの更なる活用に向けた課題」の部分で、「各チームのサブ
　リーダーにも、承認作業を担ってもらうことで、承認作業の負荷分散の体制を整える」
　という記述がとてもわかりやすく納得できる記述でした。承認の義務づけには常に
　承認者の不在という問題がついてまわります。私も論文を読んでいてそこを危惧して
　いたのですが、最後でその点を記述者が問題提起してくれたので、スッキリした印象を
　うけました。うまく論文をまとめたなという感じですね。

・全体として論文の基本を抑え、ITサービスマネージャの視点を外れる事無く記述できて
　いるという点がよかったと感じます。特に後半の設問ウの書き方が巧みですね。

【気になった点】
・設問アの「私が携わったITサービスの概要」については、どちらかというと
　A社の説明が中心になっています。ITサービスの概要を中心に書かないと
　題意からやや外れていると見なされる可能性があります。よって、A社の説明は
　簡潔にして、ITサービスの概要についての文章を記述した方が合格率が高まる
　のではないでしょうか。

・「１．２　CMDBの利用において発生した問題」の部分がわかりにくかったです。
　「研修管理システムでエラーが発生」という問題の原因が、「研修管理システ
　　ム担当者のCMDBの更新漏れ」となっているのですが、この２つの原因−結果
　のつながりが上手く理解出来ませんでした。
　読み手のことを考えると、いっそのこと、
　　「研修管理システムのサービスで問題が発生した」
　　→「必要な社員の情報がCMDBに登録されていない事が原因だった」
　というシンプルな書き方にした方が理解しやすいかもしれません。

・設問イが1,600字をオーバーしていませんでしょうか？私が数えた限りは
　３行ほどオーバしているようです。

・「２．２　工夫した点」で同一文章で「〜時に、〜時に、」という重複記述が
　みられます。この様な場合は文章を２つに分割するなどしたほうが読みやすい
　のではないでしょうか。

・現場で発生した事例を記述しているようなので現実的で評価できるのですが、
　「システム間のデータの依存関係のあるなし問題」というテーマはやや
　わかりにくい印象を受けました。「問題文に忠実に準拠しているテーマか」
　という面でも徹底に欠けます。より合格率を上げるなら、問題文に記述
　されている事例を使った方がいいです。
　例えば、以下の様な論文構成にするなどです。

　　「１．２　CMDBの利用において発生した問題」
　　　→ライセンスの有効期限切れでサービスが突然停止した。
　　　→ライセンスの有効期限情報がCMDBに登録されていなかった。
　　「２．１　改善策」
　　　→ライセンスの有効期限情報をCMDBに追加した。
　　　→CMDB運用ルールでライセンスの有効期限を定期チェックさせた。
　　「２．２　工夫した点」
　　　→CMDBの管理責任者を定めて運用ルールの遵守状況をチェックさせた。

　現場の経験からはかけ離れてしまうかも知れませんが、査読者に「問題文に
　可能な限り準拠させたよ」というアピールになり、合格率が向上に繋がると
　思います。

[499]　すぎエモン　(2011/08/30 Tue 11:20) mail

---

Re^2: Ｈ２２ 午後２　問１

すぎエモンさん、添削して頂いてありがとうございます。

自分が意識・注意して、書いた部分を評価してもらってすごく嬉しいです。少し自信が出てきました。

あと指摘いただいたところは、やっぱり自分では気付かない的確な指摘だなぁと思いました。添削してもらわないとわからないですね。

「ITサービスの概要」に関しては、確かに自分でも未だに困惑しながら書いてます。ＩＴサービスなので、○○システムってわけじゃなくて、いろんなシステムの集まり？？（社員管理システムや、勤怠管理システムなどの社内イントラネットシステムなど）なのかなぁと思ったり。今でもはっきりとわかっていない状態です。

すみません、設問イは文字数超えてますね。
修正します。

「問題文に忠実に準拠しているテーマか」
については、確かにすごく悩みました。問題文にあったような想定が自分では中々イメージできず、自分の言葉で論述する自信がなかったので、あえて違うアプローチを取ってみました。

でもやっぱり問題文に忠実にした方が、合格率はあがりますよね。
これまで論文試験を３回受けて一度だけ受かっているのですが、ちゃんとした評価基準はあると思うのですが、人間が評価する以上少しは採点者の好き嫌いはあるんだろうなぁと思っています。

一度、問題文に準拠した形でまだ論文を作成するので、添削していただけると幸いです。

今回はどうもありがとうございました。

[500]　タムタム　(2011/08/31 Wed 19:11)

---

Re^3: Ｈ２２ 午後２　問１

お世話になります。先日は私の論文に対する指摘、ありがとうございました。図々しとは思ったのですが、ご指摘いただいたすぎエモンさんに再度、添削してもらえると嬉しいなぁと思って再度投稿させていただきました。
いつでも構わないので、感想をいただければ幸いです。

１．私が携わったITサービスとCMDBの利用において発生した問題

１．１　私が携わったITサービスの概要
A社は、社員数が１０００人程のソフトウエア開発企業であり、ソフトウエア開発及び人材提供サービスを
主な事業としている。人材提供サービスは、社外より要望のあったA社の技術者を提供するサービスである。
そして、社外より要望のあった技術者を迅速に抽出するために、社員スキル管理システムを導入している。
社員スキル管理システムでは、社員の業務経歴とスキルを管理しており、本システムは情報システム部が
開発し、運用も行っている。私は本システムの運用チームにおけるリーダーである。

１．２　CMDBの利用において発生した問題
社員スキル管理システムでは、社員のマスタデータに関しては社員管理システムより毎月１日にデータの
連携を受けている。この社員マスタデータ連携処理は、深夜に実行されるバッチ処理である。バッチ処理には
商用のバッチ実行ツールにて、実行・管理を行っている。
　ある月の１日に、この社員マスタデータ連携処理が正常に実行されていないことが、バッチ実行ツールから
の異常終了メールにて検知した。早速、実行ログを確認したところ、その月の１日にバッチ実行ツールの
ライセンスの有効期限が切れており、それが原因でバッチ処理が実行されていないということが判明した。
CMDBにはバッチ実行ツールのソフトウエアバージョン情報や、適用されているパッチ、このバッチ処理
システムを利用している社内システムなどは登録されていたが、ライセンス情報を構成品目として登録してい
なかった。サーバやDBなどのソフトウエアはライセンス情報を構成管理ツールに登録しており、ライセンスの
有効期限が近づくと管理者にメールが届く仕組みである。しかし、最近導入されたバッチ実行ツールはライセ
ンス情報が登録されていなかったことが今回の原因であると判明した。

２．問題に対する改善策と工夫点

２．１　問題の原因
　A社情報システム部では、情報システムのマネジャー及び各社内システムのリーダー
が集まって、今回のインシデントに対する原因と改善策について打ち合わせを行った。今回の直接の原因は、
CMDBにバッチ実行ツールのライセンス情報の登録漏れが原因であった。CMDBに対しては運用管理ツール
を通じて操作しているため、運用管理ツールに対する運用に問題があるとう仮説を立て、議論を進めた。
バッチ実行ツールを導入し、CMDBにソフトウエア情報を登録したのは、各社内システムの基板設計を担当して
いる基盤チームであった。そこで基盤チームのリーダーにCMDBに対する登録方法についてヒアリングしたところ
次のことが明らかになった。
・CMDBへの更新はリーダーが指示を出し、部下のB君に実施させた。
・部下のB君が登録したCMDBに対する確認はリーダーは行っていなかった。
これを元に、CMDBへの登録を行ったそのメンバーにもヒアリングを行ったところ、ライセンス情報を登録しなけれ
ばいけないというルールを把握していなかったこともわかった。
　私は以上のヒアリング結果から今回のインシデントの原因を以下のようにまとめた、
・CMDBへの更新に対してリーダーの承認体制が確立されていない。
　情報システム部は、部署の特性上、リーダー以外は経験の少ない若手で構成されている。その部下の作業
内容に関しては、やはりリーダーのレビュー・確認作業が重要であると考えたからである。また経験の有無を
問わず、人はミスをすることがあるため、そういった属人性を排除する意味でも承認体制は必須である。
・運用管理ツール・CMDBに対する運用ルールが明確にドキュメント化されておらず、周知徹底されていない。
　今回、運用管理ツールを操作してCMDBを更新したB君は、運用ルールを把握していなかった。その時点で
運用ルールは明確にドキュメント化されておらず、それを知るすべは先輩やリーダーから教えてもらうしかない
状況が問題であると考えたからである。部署の特性上、異動も多いため、新しく配属されてきたメンバーが
運用ルールを正確に引き継ぐことが出来ていないとうことも容易に想像することが出来た。

２．２　改善策と工夫した点
　私はこの問題に対する改善策を次のように考えた。
・ソフトウエア情報のCMDBへの更新に対する承認体制の確立
　現在導入している運用管理ツールには、各種データの更新を承認により確定することが出来るワークフロー機能
を有している。これまで活用していなかったが、この機能を用いて部下やリーダーが実施したCMDBの更新を
上位職の方が確認し、承認する仕組みを整えた。こうすることで、メンバーによる誤った更新や漏れを検知出来る
と考えた。
・運用ルールの整備
　承認体制を確立はしたため、部下のミスや漏れを防止することが出来るが、それはあくまでもメンバーがCMDBへの
正しい更新ルールを把握していることが前提である。そうでないと、上位職と部下の間で差し戻しと再承認依頼を
繰り返すことになり、効率が悪くなるためである。そのためには運用ルールをドキュメント化し、誰もがいつでも参照
出来るようにする仕組みが必要であるため、この改善策を考えた。
　この改善策に対して工夫した点がある。それは、運用管理ツールのCMDBへの更新画面にこの運用ルールの
ドキュメントに対するリンクを設けている点である。ファイルサーバのある場所に格納しておくよりも、本当に必要と
なる操作をしている画面の近くにあった方が参照しやすいと考えたからである。

３　改善策の効果と評価及び今後の課題

３．１　改善策の効果と評価
　以上のように改善策を講じた。ITサービスマネージャーとしては、講じた対策に対しては継続的かつ定量的に
その効果を評価し、必要であれば更なる改善が必要である。私は講じた２つの対策に対する効果と評価を行う
こととした。
　１つ目の承認体制の確率については、部下のCMDBに対する更新に対してリーダーやマネージャーが差し戻し
を行った回数を計測した。結果、一回の更新あたり２．５回の差し戻しが行われていた。またその差し戻しの内容を
確認したところ、誤字・脱字がほとんどであったが、中にはライセンスの有効期限の入力ミスなどクリティカルな
ミスも存在した。この結果を受けて、私は承認体制は有効に働いていると評価した。
　２つ目の運用ルールの整備に関しては、運用管理ツールのCMDBの更新を各画面に設けられている運用ルール
のドキュメントリンクの参照回数を計測した。１０回のCMDB更新あたり５回、運用ルールのドキュメントリンクが
参照されていることが分かった。CMDBへの更新を実施したメンバーにアンケートをとったところ、CMDB更新の各
画面にリンクが設けられているため、少ない操作で運用ルールを参照出来ると評判は良かった。

３．２　CMDBの更なる活用と今後の課題
　今回、運用管理ツールにおける承認体制を採用したのは、主にソフトウエア情報におけるCMDBの更新に限定
していた。今後は、インシデント管理、問題管理などCMDBの更新を伴う入力に関しては承認体制を適用したいと
考えている。しかしここで一つの課題が存在する。それは、承認者の確認・レビューによる作業負担が増加するこ
とである。現在、承認者は情報システム部の運用部門のマネージャーと、各チームのリーダーのみである。今後
は各チームのサブリーダーにも、承認作業を担ってもらうことで、承認作業の負荷分散の体制を整えることが、承
認体制適用の第一歩であると考えている。

　　　　　　　　　　　　　　　　　　　　　　　　　　−以上

[501]　タムタム　(2011/09/02 Fri 12:13)

---

Re^4: Ｈ２２ 午後２　問１

お疲れさまです。すぎエモンです。
僭越ながらご指名なので査読をさせて頂きました。

【良いと感じた点】
・一度指摘された事を吸収し、すぐに対応をとる姿勢には頭が下がります。
　このようなモチベーションの高さを維持することが合格を勝ち取ることに
　繋がるのではないかと考えます。

・「１．１　私が携わったITサービスの概要」については、相変わらず
　理想的な書き出しですね。必要な事項を最低限の文字数で書き出しており
　しかも分かりやすいです。論文の手本になりそうだと感じました。

・設問アは記述内容もより問題文に準拠した内容になり、読む側に分かり
　やすい問題になっています。記述者の実体験には基づいていないのかも
　知れませんが、現実感がないといった違和感は感じませんでした。

・工夫した点で記述している「運用管理ツールのCMDBへの更新画面にこの
　運用ルールのドキュメントに対するリンクを設けている点」という
　内容は非常にわかりやすくて、納得できる工夫ですね。

・「講じた対策に対しては継続的かつ定量的にその効果を評価し、
　必要であれば更なる改善が必要である」という表記はいいですね。
　ITサービスマネージャーとして相応しいとアピールするような文章です。

・運用ルールの整備について、「ドキュメントリンクの参照回数」から
　定量的に評価するという点は「その手があったか」と思ってしまいました。
　定量的な評価が難しい部分をうまく数値で評価できたという点でポイントが
　高くなると思います。

・設問ウの内容はいつもながら巧みです。特に評価のアプローチと今後の課題
　の問題提起が実にウマいと思います。

【気になった点】
・設問アが、８００字をオーバーしているようです。
　設問イも、１６００字をオーバーしているようです。
　可能であれば、ワープロソフトの横書き原稿用紙テンプレートを用意して
　これに論文書く練習をすると、文字数の確認が楽になります。
　また、本番の原稿用紙は２５文字×３２行＝８００字なので
　これと同じ構成の原稿用紙ならば、本番さながらの環境で訓練できます。

・最初の査読で「バッチ実行ツール」というものがよく分からないまま
　消化不良になってしまいました。
　　→バッチ実行ツールがライセンスを情報を登録しているのか？
　　→バッチ実行ツールのライセンス情報の入力が漏れていたのか？
　　→そもそもバッチ実行ツールとは何をしていて、バッチ実行ツールの
　　　何が問題になったのか？
　と言った疑問が湧いてしまい、１回の査読では理解できませんでした。
　主題が構成管理データベース（CMDB）なので、バッチ実行ツールを
　前面に出すよりも、「CMDBの必要な構成品目の不足→追加」という事を
　主題にした方が読み手は理解しやすいのではないかと思います。

・「承認体制を確立はしたため」という記述は
　「承認体制を確立することで」という書き方にした方が
　わかりやすくなるのではないかと考えました。

・設問ウにおいて、
　「CMDBの更新を伴う入力に関しては承認体制を適用したい」の部分は
　「CMDBの更新を伴う入力に関しては同様の承認体制を適用したい」
　という書き方の方がわかりやすくなるのではないかと考えました。

・設問アで「ライセンス情報を構成品目として登録していなかった」
　という記述があるのに、その直後には「サーバやDBなどのソフト
　ウエアはライセンス情報を構成管理ツールに登録しており」という
　書き方がされており、矛盾を感じました。
　　�@ライセンス情報の構成品目そのものが存在しないのか？
　　�Aライセンス情報の構成品目はあるもののデータの入力を
　　　行っていなかったのか？
　この２つのどっちなんだろう、という疑問ですね。
　設問イ以降を読むと、�Aの前提で書いているようです。
　なので、�Aの書き方で統一した方がいいですね。
　ただし、試験の問題文を読むとどちらかというと�@をテーマ
　として扱ってもらいたいようです。よって、
　　「ライセンス情報を構成品目として登録していなかった」
　　「だから、ライセンス情報を構成品目として登録した」
　という流れの方が読み手にわかりやすく、問題文にも忠実に
　準拠するのではないだろうかと考えました。

・今後、論文の練習をお続けになるなら、次は別の過去問題に
　チャレンジされる方がよいかと思います。同じ論文問題を
　何度も書き換えるという練習方法は、本番とかけ離れた
　やり方になるので、実践的でない可能性があります。

[502]　すぎエモン　(2011/09/05 Mon 08:53) mail

---

Re^5: Ｈ２２ 午後２　問１

お世話になります。

すみません、字数ですがもう一度確認します。
Excelで数えた時は収まってたと思っていたのですが。

確かに

　　「ライセンス情報を構成品目として登録していなかった」
　　「だから、ライセンス情報を構成品目として登録した」

という流れの方が、問題にも忠実で読み手にはわかりやすいですね。
修正します。
バッチ実行ツールの説明は確かに漏れていますね。もっと読み手を意識しないといけないですね。精進します。

なるほど、確かにあまり同じ題材ばかりで論文の練習をするのはよくないですね。おっしゃる通り次は違う問題を解くようにします。

効果的な学習方法までアドバイスしてもらいありがとうございます。
毎回、経験に基づいた的確な指摘をいただけるので非常に勉強になります。
今後ともよろしくお願いします。

[503]　タムタム　(2011/09/06 Tue 17:48)

---

Re^6: Ｈ２２ 午後２　問１

お疲れさまです。すぎエモンです。

参考までに言いますと、行末の空白は文字数に含まれます。
なので、以下のような文字数の数え方になります。

『記述例』
・CMDBへの更新はリーダーが指示を出し、部下のB君に
実施させた。
・部下のB君が登録したCMDBに対する確認はリーダーは
行っていなかった。

『文字数の数え方例』
×→文字数を全部カウントして６９文字
○→４行×２５文字なので１００文字

[504]　すぎエモン　(2011/09/09 Fri 14:02) mail

Ｈ２２ 午後２　問２

今年の秋季試験でITサービスマネージャを受験しようと早速申し込みました。参考書や当サイトのアドバイスを参考に時間をかけて何回かＨ22、Ｈ23の午後２の論文問題をトライしていますが、合格レベルに対して自分がどのレベルにいるのかよくわかりません。一度、皆様に見ていただけたらと思い投稿いたします。どうぞよろしくお願いします。

設問ア
１．私が携わったITサービスの概要
S社は、日本全国に１３２の支店を持つ総合証券会社であり、個人や法人の顧客より、株式や債券、投資信託などの金融商品の注文を受け付け証券取引所や投資信託の運用会社へ注文を取り次ぎ、約定を確認した後に商品の引き渡しと売買代金の決済を行う証券取引オンラインシステムを稼働させている。
　私は、この証券取引オンラインシステムの運用を担当している運用管理室に所属しているサブリーダである。S社では、この証券取引オンラインシステムの端末として、パソコンを１人1台配備し、計５千台を稼働させている。一方、データセンタでは、UNIX系やWindows系のサーバを60台程度、稼働させており、広域LANサービスを利用した全国ネットワークで支店や本社とデータセンタを相互に接続している。今回、この証券取引オンラインシステムの内、サブシステムとして構築された顧客情報システムのリリース管理について、述べる。
２．リリースの検証及び受入れの概要
　新たなシステムや変更されるシステムに円滑に実装されるためのリリース管理は、ITサービスマネージャの役割であり、リリース内容を確認した上で適切な実装計画を立案し、推進していくマネジメントが重要である。
２．１リリース内容
顧客情報システムは、新規サブシステムであり、専用サーバの運用監視システムへの登録やバッチシステムに関する運用管理システムヘのジョブやジョブネットの登録、また、データベースやシステムテーブルの構成変更時のコマンドオペレーションなどのリリース項目があった。
２．２リリース計画
　開発部門からのリリース内容説明、運用環境への組込み、運用手順の精査、運用テスト、リリースリハーサルなどを計画した。
設問イ
１．リリースの検証及び受入れ時の問題点
　リリースの検証及び受入れは、リリース管理における重要なプロセスである。しかし、リリースの検証及び受入れの過程でスケジュールや体制上の問題点や運用機能との不整合の問題点などが発生することがある。
１． １コンソールオペレーションの煩雑性
データベースやシステムテーブルの構成変更のオペレーションは、サーバに対するリモートコンソールよりコマンドを投入するオペレーションであったが、コマンド数が多く、しかも、文字数も多く複雑なため、このまま受け入れると運用ミスや作業遅延につながる可能性があると感じられた。オペレータはシフト体制を組んでおり、様々な担当オペレータが作業をするため、オペレーションは極力、シンプルでわかりやすいものにしておく必要があると考えていた。今回のコマンド投入は、２０ヶ所もあり、このまま、受け入れると運用品質の低下が懸念された。
１． ２監視メッセージの大量発生
　サーバ監視システムへの登録後、本番リリースに先行して、運用監視業務を開始し、問題点の洗い出しを図ることにした。その結果、サーバオペレーションであるデータベースやシステムテーブルの構成変更時や定期的に行うリブートやテープ交換オペレーション時に監視システム上に多数のメッセージがあがり、監視業務の中で障害として扱われ運用負荷を増大させる要因になっていた。
２．運用解決に向けた取り組み
２．１問題解決に向けた取り組み
　リリースの検証及び運用受入れの過程において、発生した問題点を一覧にまとめ解決に至るまで管理することにした。問題の内容により、関連部門と協議し、解決策をさぐったり問題の対策検討のタスクを担ってもらうことを依頼した。
２． ２実施した対策
　上記、１．１項のコンソールオペレーションの煩雑さの問題については、開発部門に対すし、問題点を提示しどのような解決策があるか共に協議し、対策を進めた。具体的な対策としては、コマンドのバッチ化やシェル化への変更であった。これが実現すれば、オペレーションは簡略化されシンプルなものとなり、安定した運用が維持できると考えた。しかし、バッチ化やシェル化を行うためには約1カ月程度の期間が必要であり、リリース時期を延期しなければならない見込みとなった。これに対し、利用者に対し開発部門と共に状況を説明し理解を求めた。利用者側では必要最低限の機能に絞ってシステムを利用したい旨、調整案が提示されリリース計画を見直すことになった。
　また、上記１．１項の監視メッセージの大量発生については、リリース先行期間中に発生したメッセージを記録し、開発部門に提示し、解決策の検討を求めた。その結果、対応不要なメッセージについては、業務サーバ側で抑止する対策や監視システム側で無視する対策をとった。また、メッセージの発生条件などで双方の対策がとれない場合は、運用マニュアルを作成し、発生条件と対処方法を明記し運用手順に組み込んだ。
設問ウ
１．設問イで述べた問題の根本原因
　今回、設問イで述べた問題の再発防止のため、幅広い広範囲な視点から分析を行い根本原因を突き止め対策する必要がある。
　私は、今回設問イで述べた問題が発生した要因には、リリース後本番運用への移行を考慮した設計やテストがなされていない事が原因にあるのではないかと考えた。このため、本番運用に移行するためのポイントや考慮点を開発担当者に意識させ、設計時点から考慮に入れるよう導くための対策を実践することにした。
２．再発防止に向けて講じた施策
２． １開発段階からの運用設計
　まず、短期的施策として、開発設計工程上で行われる設計会議、リリース会議に運用部門からも出席し、開発計画、リリース計画について把握するとともにリリースの検証や運用受入れの観点で早めに準備しておくべきこと、確認しておくべきことを指摘し、開発部門に対し計画させることにした。このようにして、早めに本番運用として受け入れるための運用としての規定路線に乗せることが重要である。
２．２運用設計ガイドの策定
　リリースの検証や運用受入れに必要な規定集やチェックリストを作成し、広く開発部門に公開し活用してもらうよう報知した。また、適用状況を確認するため、設計会議やリリース会議で上記チェックリストを活用してもらい、早めに軌道修正してもらうよう定期的にチェック結果と対策について、確認する運用を始めた。
以上

[495]　まつ　(2011/07/31 Sun 12:23)

---

Re: Ｈ２２ 午後２　問２

まつさん。はじめまして、すぎエモンです。
僭越ながら査読させて頂きました。

【良いと感じた点】
・このサイトで説明されている基本をしっかりと抑えて書かれています。
　よって、まつさんの論文は合格を目指せるレベルにあるのではないかと感じました。

・「メッセージの発生条件などで双方の対策がとれない場合は、運用マニュアル
　を作成し、発生条件と対処方法を明記し運用手順に組み込んだ。」という
　フォローの仕方は良かったです。開発側が立てた１つの対策に依存せず、
　運用の立場で２重の回避策を講じておくというのは、運用管理者ならではの
　工夫ですね。

・「問題が発生した要因には、リリース後本番運用への移行を考慮した設計やテ
　ストがなされていない事が原因にあるのではないかと考えた」という記述は
　ＩＴサービスマネージャの視点として、とても良い表記ではないかと思います。
　私もグッと来ました。この部分だけで、査読者の好感度がアップするのでは
　ないでしょうか。

・上記で述べた部分も含めて、設問ウの書き方がとても上手です。「開発設計工
　程上で行われる設計会議、リリース会議に運用部門からも出席」「リリースの
　検証や運用受入れに必要な規定集やチェックリストを作成し、広く開発部門に
　公開し活用してもらう」などなどＩＴサービスマネージャの視点をしっかりと
　理解していることを十分にアピールできる内容になっていると感じました。

【気になった点】

『誤字脱字』
・開発部門に対すし
　→開発部門に対し

・些細な話ですが、設問アの部分を厳密に原稿用紙に記述すると
　わずかながら８００字をオーバーするようです。本番の原稿用紙上では
　このような事は起こりにくいですが。

・冒頭の部分でS社と対象システムの説明を１つの文で説明しようとしているの
　で、文が長くなりややわかりにくくなっています。S社の説明と対象システム
　の説明については２つの文に分けた方が分かりやすいのではないでしょうか。

・設問ア後半では「リリースの検証」と「受入れの概要」を記述する
　必要があるのですが、「リリース内容」「リリース計画」を中心に
　記述してしまっています。なるべく題意に沿うためにも
　　２．１　リリースの検証
　　２．２　受入れの概要
　という書き方にした方がいいかも知れません。

・設問アでは問題文からの引用をされていますね。
　　「新たなシステムや変更されるシステムに円滑に実装されるためのリリース
　　　管理は、ITサービスマネージャの役割であり、リリース内容を確認した上
　　　で適切な実装計画を立案し、推進していくマネジメントが重要である」
　という部分ですね。しかし、この記述のせいで設問アの「リリースの検証」と
　「受入れの概要」の説明が少なくなってしまっている印象があります。
　ITサービスマネージャとしての「考え」を記述するのは設問アよりも設問イの
　方がよいと思いますので、この引用は設問イに記述して、設問アでは
　システムの概要と「リリースの検証」と「受入れの概要」にしっかり答える
　事に文面を割いた方がいいかも知れません。

・設問アで「リリースの検証及び受け入れの説明」を記述する必要があります。
　ここでは以下のような準備をしたという記述が欲しいです。
　　・受け入れテスト環境の構築
　　・実装手順及び不測の事態に備えた切り戻し手順の作成
　　・人的リソースの確保
　さらに、設問イでこの時に「発生した問題点」の説明を記述する必要があります。
　よって、以下のような記述が欲しいです。
　　・緊急の受入れ要請があり、受け入れテストに十分な時間を確保できない。
　　・受け入れテストの結果、運用機能の改善が必要であると判明した
　　・実装に当たり、当初想定した以上の作業要員が必要であると判明した。
　記述が欲しい理由はどちらも「問題文に書かれているから」なのですが
　この論文ではストレートにこの記述をしている部分が見あたりません。
　これで不合格になるという事はないのですが、問題文に可能な限り準拠させる
　という意味で、「忠実に」問題文の表記を取り入れていった方が合格率が
　高まるのではないかと考えました。客観的に読む立場としては今の書き方が
　オリジナリティがあって読んでいて楽しいのですが、合格を取る為の書き方に
　するなら、できる限り問題文に準拠した方がいいです。

・設問ウはせっかくなので、根本原因の記述の前に、以下の様な文章を追記する
　とより合格率が向上するのではないかと考えます。
　　「私は、根本原因の究明に当たっては、リリースの検証及び受け入れ、又は
　　　リリース管理の視点に留まらず、変更管理や構成管理などの他の管理プロ
　　　セス、更には稼働環境、運用基準も含めた広範な視点から分析を行うこと
　　　にした。」

[496]　すぎエモン　(2011/08/01 Mon 16:40) mail

---

Re^2: Ｈ２２ 午後２　問２

すぎエモンさん

査読ありがとうございます。
なかなか自分では気がつかないのですが、指摘されてみれば、なるほどと思うようなことばかりでした。確かに、設問アでは、システムの概要と「リリースの検証」と「受入れの概要」もバランス悪く後半、詰まってしまった感があります。
設問イの部分についても合格を取る為の書き方という点で勉強になりました。
また、よいところも指摘頂き、これから１０月の試験までの励みになりそうです。
まだ、現在は時間は気にせず十分時間をかけて、ここ２年間の過去論文から選んで論文を書く練習を繰り返していますが、試験では２時間という制限の中で書き上げなければなりませんので、時間不足で失敗しないためにも、これからは、時間配分を気にして論文を書き上げる練習を始めたいと思っています。

ご指摘ありがとうございました。また、機会があればよろしくお願いします。

[497]　まつ　(2011/08/05 Fri 09:01)

ITサービスマネージャ

はじめまして。
先日、ITパスポートの試験を受けました。
次は、販売士１級を取得しようと思っていましたが、（小売系の業務アプリケーションのサポートデスクに勤務しているため）ITサービスマネージャの方が興味があったので、今から学習し、１０月の
試験を受験しようか？迷っています。といいつつも、2011ITサービスマネージャ「専門知識＋午後問題」をすでに購入しましたが・・。問題を見ていると、午後の問題は割と今の実務と合っており、ITILなどは理解しているのですが、午前�Tの試験の方が私にとっては、超難関です。
サポートデスク内の運用面は強いのですが、（といっても論文は学習が必須ですが）テクノロジ系、ストラテジ系の問題はさっぱりで、今から勉強しても間に合うのか？心配です。勉強に割ける時間は１日１時間〜２時間程度なのですが、
そんなんで、合格できるものなのでしょうか？
非常に幼稚な質問ですみません。
なかなか、情報がなく、一番詳しいHPを見つけることができたので
質問してみました。どうか、よろしくお願いします。

[492]　カバ　(2011/07/17 Sun 00:40)

---

Re: ITサービスマネージャ

午前１はなかなか難関です。
範囲が広いので、勉強には結構時間がかかります。

今から間に合うか？と言われますと、人によると思います。ITパスポートの勉強でかなりしっかりと勉強された方であれば、突破は不可能ではないと思います。
ただ、コツがいります。
やみくもに勉強してはいけません。午前は出題パターンが決まっており、全く同じ問題や同じ系統の問題が出題されます。なので、過去問を中心にそのパターンを見つけるようにしながら勉強するとよいでしょう。
午前１の範囲をすべて理解しようとすると、３年かかっても無理でしょう。でも、合格される方は、コツを探しながら短期間で合格されます。
問題は暗記系と考える系に分かれます。言葉を知っていないと解けない問題と、基本的な理屈は理解したうえで計算などをして考える問題です。短期間で合格するのであれば、後者を得意にすべきです。
コツはどうやって見つけるか。それは過去問を何年分も解くことです。そうすれば、出題傾向が見えてくると思います。

また、今回基本情報を受験され、来年春に応用情報、来年秋にITサービスマネージャを受験されるのも選択肢かと思います。

[493]　管理者　(2011/07/20 Wed 02:28)

---

Re^2: ITサービスマネージャ

ありがとうございます。
私も、あれから午前問題を勉強していましたが、なんとなく受かる気がしませんでした。。。この時点でかなり弱気ですが。

基本技術の方もわからないのに、いきなり応用は難しいと思い始めており、やっぱり最初に基本技術を取得するとしっくりくるのかと思っていました。管理人さんと同じ思いでしたね。

現在、自分の仕事を進める上で存在意義がわからなくなってきて
私は、技術的な事がわからないので、自分の専門である運用支援の勉強をしたいと思い始めました。ですが、やっぱり基本的な事が解っていないと、例えまぐれで合格したとしても、説得力がないんだなと考えたり、色々と悩むばかりで・・・。

でも、アドバイスをいただいて、近道ばかり考えないで、地道に努力をする決心がつきました。
まずは、基本技術情報の勉強から始めてみたいと思います。

今まで、難易度の低い資格ですが、１発合格で進めてきたので
これからもこのポリシーだけは曲げないように進めていきたいと
思います。

子育て、仕事、勉強と山積みの日々ですが、充実した生活が送れるように、努力したいと思います。
また、くじけたら愚痴らせてください。
ありがとうございました。

[494]　カバ　(2011/07/20 Wed 22:11)

H22PM1-2

お世話になります。
ITサービスマネージャの勉強を始めました。

H22PM1-2の設問３の答えについて、
疑問点がございますので、質問させてください。

(1)の模範解答
APサーバ1とAPサーバ2は昼間帯にサービスを停止させずに1台ずつパッチを適用する。

設問では「夜間作業での作業リスクを減らし・・・」とありますが、
なぜ夜間作業だと作業リスクがあるのでしょうか？

むしろ、夜間のほうが利用者が少ないため、
作業リスクは低いのではないかと思いました。

もし、ご存知でしたら、ご教示いただけませんか。

以上、よろしくお願い致します。

[489]　エス　(2011/07/01 Fri 07:27)

---

Re: H22PM1-2

すぎエモンです。僭越ながら私見を書き込ませて頂きます。

この場合の「夜間作業のリスク」は「夜間の方が危険だよね」という意味ではな
いみたいです。この場合の「夜間作業」とは「夜にシステムを停止して行う緊急
パッチ作業」という意味と捉えていいでしょう。

　「夜間＝危険」ではなく　→　「夜間作業→システム停止→可用性低下のリスク」
　ですね。

よって、設問の意図は
「緊急パッチ作業って夜間に実施するとは言え、システムを止めないとダメな作
　業なので可用性が低下しちゃってイヤな感じだよね。少しでもこの作業のリスク
　を減らす方法ってないのかな？」
という事を問うているようです。

解答を見ると以下のような考えが正解になるようです。

「緊急パッチ作業では、ＡＰサーバ３台とＤＢサーバ１台を止めて４台同時に作
　業しないといけないから大変だよね。作業者が少ないとミスも起きそうで怖いよ。
　あれっ？そういえばＡＰサーバ１とＡＰサーバ２はロードバランサの設定を変
　えれば、昼間でも片方ずつ切り離してメンテ作業ができるんじゃね？
　ＡＰサーバはメンテ前の事前バックアップも不要だし、イケるかも知れないぞ。
　ＡＰサーバ１とＡＰサーバ２の２台のパッチ適用を昼間にできれば、夜間作業で
　緊急パッチ作業をするサーバの台数が２台に減らせるぞ。これならミスも起こ
　りにくい。おお、俺って頭良いじゃん！」

という考え方ですね。

[490]　すぎエモン　(2011/07/01 Fri 12:33) mail

---

Re^2: H22PM1-2

ご回答を参考に納得することができました。
ありがとうございます。

すぎエモンさんからの回答にもございますように、
夜間に複数台に対して同時に作業することが
設問における作業リスクと言っていると考えることが
自然な気がしました。

それを回避するという意味で、
昼間でなくても夕方や夜間作業の数時間前でも良いのでしょうが、
例として昼間に作業していると明記しているのですね。

納得いたしました。

[491]　エス　(2011/07/02 Sat 22:57)

システム監査技術者Ｈ２１問３

こんばんは。yh0807と申します。
ＩＴサービスマネージャに受かったので、春期はシステム監査を受験しようと思っています。…が、同じ論文試験でもＩＴサービスマネージャといくらか勝手が違うようで戸惑っています。

■戸惑っている点
・問題で「あなたが関係した情報システムの〜」となっているが、構築や運用保守で関わったのか、監査する立場として関わったのか書くのに迷う。

参考書やサイトによっても、まちまちのようで…。

とりあえず、運用・保守で関わったという設定で論文を書きました。何かご指摘等頂ければありがたいです。

-----------------------------------------------------------------
１．情報システムの概要と求められる信頼性
１−１．情報システムの概要
　私はシステム開発業のＡ社のシステム管理部で社内のシステム全般の運用・保守チームのリーダーを担当している。Ａ社にはメールシステムがあり、社員間や社外とのメールの送受信に利用されている。Ａ社には本社ビル内に300人、社外の顧客事業所等に600人ほどの社員がおり、社員は会社から貸与されたＰＣで、社内ＬＡＮやＶＰＮを介してールシステムを利用する。
　メールシステムは負荷分散装置１台、メールサーバ２台、ディスク装置１台で構成されている。負荷分散装置は２台のメールサーバのうち、正常に稼動していてセッション数の少ない方にアクセスを振り分ける。社員は負荷分散装置を通じてメールサーバにアクセスし、認証を行ってメールの送受信を行う。2台のメールサーバはディスク装置に接続しており、メールサーバは社外とのメールの送受信を行って受信したメールをディスク装置上の各社員のメールディレクトリに配信する。

１−２．求められる信頼性
　メールシステムの利用目的のうち、社外との送受信の利用目的は以下である。
・社外との受発注業務
・請負っている顧客システムの開発に関する連絡
・顧客システムからの定時レポートや障害アラートの受信
　これによりほとんどの社員が業務上メールの利用が不可欠である。そのため、常にメールシステムが安定して利用できなければならず、システム管理部とユーザ部門の間で、メールサーバの可用性について以下を定めたＳＬＡを締結している。
・システムの停止は年２回以下
・システム停止時間は１回につき３時間以下

２．リスクと対応策及び影響度
２−１．想定したリスクと対応策
　メールシステムに求められる信頼性を確保するにあたり、私が想定したリスクとその対応策は以下の通りである。
(1)メールサーバの故障の対策
　メールサーバ1台の構成では、ハードウェア障害によりメールの受信や、社員のメールディレクトリへのアクセスの処理が停止してしまう。そのため、以下の二通りの方法を検討した。
ａ．本番機と同じ設定を行った予備機によるコールドスタンバイ
ｂ．同時に稼動している２台のサーバと負荷分散装置によるロードバランシング
　その結果、ｂ案を採用した。その理由としては、１台のサーバに障害が発生してももう１台が稼動しているために、予備機への切替と動作確認を行う時間が必要なくサービスの停止が発生しないことと、平常運転時も１台のメールサーバにかかる負荷が小さく処理の遅延がおこりにくいことの２つが挙げられる。
(2)ディスク装置障害の対策
　社員のメールディレクトリのあるディスク装置の故障によるサービス停止のリスクについては、以下の二つの対策を行った。
　ディスクのデータについては、ディスク装置のＲＡＩＤ設定でミラーリングを行い、１本のディスクが故障しても、もう一方のディスクを使用してサービス提供を続けられるようにした。
　ディスク装置の筐体の故障については以下の２つの案を検討した。
ｃ．障害発生時に同型の予備機にディスクを差替えるコールドスタンバイ
ｄ．予備機も稼動させて常にデータを本番機から同期するホットスタンバイ
　以上の案ではｃ案の見込み作業時間が１時間でありＳＬＡに定められた時間内で行えることと、ｄ案では書き込み処理をメールサーバで制御するため負荷がかかりメールの送受信の処理に遅延が発生する可能性があることから、ｃ案を採用した。

２−２．関連する業務やサービス提供の影響
　前章で述べた対応策を決定するにあたって考慮した業務やサービス提供への影響は以下である。
　メールシステムが停止すると、受発注業務や顧客との連絡が行えなくなる。それにより、自社の業務に遅滞が生じるだけでなく、他社の業務も円滑に行えない可能性が高くなる。
　また、顧客システムからのアラートメールを受信できず、顧客システムの障害を感知できずに対応が遅れ、顧客企業の業務に重大な損害を与えてしまう恐れがある。
　こういった事態を避けるために、メールシステムの信頼性の確保が重要になっている。

３．リスクの対応策の監査の留意点
３−１．監査時の留意点
　このメールシステムのリスク対応策を監査する際に留意する点は以下の２つである。
(1)障害を検知する仕組みがあるか
　障害の発見が遅れると対応も遅れてしまい、結果としてＳＬＡに定められた時間を超過してしまう可能性がある。
　また、メールサーバで障害が発生した場合は、負荷分散装置によってもう一方のメールサーバに振り分けられてメールシステムを問題なく使用できるため、障害が発生したことが発覚しにくいという特徴がある。これにより、一方のメールサーバに負荷がかかり処理に遅延が発生する状態が続いたり、残ったメールサーバにも障害が発生した際にサービスが停止してしまうという事態が懸念される。そういった事態を避けるために、迅速に障害を検知することが重要である。そのため、定期的にメールサーバの死活監視を行う監視ツールの使用や、保守担当メンバーによる定時メンテナンスなどの、障害を検知する仕組みがあるか確認する必要がある。
(2)障害発生時の対応手順が確立されているか
　障害発生時は、迅速に復旧させることが必要であるため、復旧手順が確立され関係するメンバーに羞恥されている必要がある。
　特に、ディスク装置の筐体の故障ではサービスが停止してしまうが、ＳＬＡに定められた３時間という短い時間で予備機へのディスクの入替え、起動、動作確認等の作業を行わねばならない。
　こういった自体に対応するための手順書の存在や、訓練実施の有無を確認したり、実際に復旧作業を行うメンバーにインタビューを行い復旧手順を正しく理解しているか確認することが重要である。

[485]　yh0807　(2011/06/10 Fri 00:02)

---

Re: システム監査技術者Ｈ２１問３

お疲れさまです。すぎエモンです。

僭越ながら、またまた査読させて頂きました。
ＩＴサービスマネージャのサイトでシステム監査の論文査読を行うのは
管理人さんに対して少々心苦しいのですが。

【良いと感じた点】
・さすが論文合格者の論文です。非常に高いレベルでまとめられており
　高度な査読内容の指摘をすることができます。

・ずばりこの問３の問題はぱっと見で解きやすい印象を持ちますが
　色々とワナがあり記述しにくい設問になっています。
　　�@yh0807さんが「●戸惑っている点」で記述した問題がある
　　�A「企画・開発段階」と時期を限定しているので、システムが稼働
　　　した後の状況を書いてしまうとアウト
　　�Bテーマが障害や不具合の「未然防止」なので実際に障害が起きて
　　　しまった事を書いてしまうとアウト
　この�Aや�Bのワナに引っ掛からず、きちんと企画・開発段階の監査である
　ことや、未然防止の対策を講じている点での線引きが出来ている点は
　素晴らしいと思います。論文突破者ならではの上級テクニックですね。

・ＳＬＡは監査の場合、無理に入れる必要はないのに…と思ったのですが
　今回のテーマが「信頼性」であるためこれを表現する手段として
　ＳＬＡの概念を上手く利用できていると思います。

・設問ウについて、留意点が簡潔で分かりやすいです。更に、具体的に監査する
　ポイントまでしっかり記述出来ている点も素晴らしいです。
　ここでは問題文で「ＩＴ環境の特徴などを踏まえて」という難しい課題を突き
　つけられているのですが、ここをＳＬＡを使ってうまく答えていますね。

【気になった点】
・「戸惑っている点」でご自分でも記載していますが、「自分が構築したシステムを自
　　分で監査する」構成になっているので危険ですね。問題の出し方から「自前監査」
　　でも問題ないのかも知れないですが、う〜ん…どうなんでしょうね。私ならリスク
　　が高いので避けると思います。
　　よって、「設問イでは他人が考案したリスクの対応策をヒアリングする」
　　「設問ウでは自身で監査を実施する」という書き方にすると思います。
　　私がＨ２１に受験した際は、この問３はどっちつかずな設定であり、ハイリスク問題
　　であると判断して排除し、問２を選択した記憶があります。

・設問アですが、私の立場がシステムの構築者側という点もシステム監査試験
　という観点から見てどうでしょうかね…う〜ん、問題文を読む限りは問題ないような
　気もしますもありますが。システム監査のセオリーでは、「システムを作った側」の
　立場からは独立していた方が、監査の独立性という意味で合格率が高い傾向にあるよ
　うですからね。

・「羞恥されている」という記述ですが、いや〜ん、はずかし〜ってその羞恥ではない
　　ですよね（笑）。「周知」の間違いだと思います。

・設問では要求されていないですが、どういう理由で監査が必要になっているのか、
　どのような立場で監査を行う予定なのか。誰に対して監査結果を報告するのか。
　などが明確なら、更に具体性が高まり監査論文として良い内容になるのではないか
　と思います。

[486]　すぎエモン　(2011/06/10 Fri 14:47) mail

---

Re^2: システム監査技術者Ｈ２１問３

すぎエモン様

またまたお世話になります。色々ご指摘頂きありがとうございました。
まさかこの時期に、即レス頂けるとは思っていなくて返事が遅くなり申し訳ありません。
1つ目と2つ目の指摘点は、完全にITサービスマネージャの論文を引きずっていたというか、違いを理解しきれずに書いていたための問題点ですね。
ご指摘頂いた内容を読んで、論文を書く時の視点の違いが少しは分かった気がします。
4つ目に関しては、自分の立場を内部監査室の人間と設定した上で、会社の経営層に対して「社内のメールシステムが業務に及ぼす影響を最小限に抑えるように運用・管理されているか」について調査して報告するという形にすればよかったのかな、と思います。

何はともあれ、あと1週間を切ったのでご指摘頂いた内容を活かせるようにがんばります。

[488]　yh0807　(2011/06/21 Tue 12:38)

重点対策2011の発売開始

発売が開始されました。
詳しくはTOPページを参照してください。

[487]　管理者　(2011/06/18 Sat 13:10)

ITストラテジスト受かってました

以前、プロマネ受かってましたと書き込みした某氏です。

去年の秋試験で、ITストラテジストの合格発表があったのですが
無事合格していました！
ITストラテジストは一昨年の秋に一度落ちていたので余計にうれしいです。

少し前とはなりますが。システム管理受験の際に管理人様に色々と論文指導していただいたのも大きいと思います。
ありがとうございました。

ちなみに成績照会はこんな感じでした。

午前�T得点 ***.**点 （免除）
午前�U得点 88.00点
午後�T得点 86点
午後�U評価ランク A

では本年もよろしくお願いします。

[482]　某氏　(2011/01/06 Thu 23:24)

---

Re: ITストラテジスト受かってました

合格おめでとございます

監査、システム管理、診断士、プロマネ、ストラテジストですか。
すごい！

是非とも、合格のコツを教えてください。
論文テクニックがあればご指導ねがいます。

[483]　管理者　(2011/01/28 Fri 06:37)

---

Re^2: ITストラテジスト受かってました

20年度にこのサイトでお世話になって
システム管理に合格出来たものです。

私も22年度秋ITストラテジスト合格することが出来ました。

ここ3年の戦績です。

20年春　システム管理　　　　　合格
20年秋　プロマネ　　　　　　　不合格
21年春　プロマネ　　　　　　　不合格
21年秋　システムアーキテクト　合格
22年春　プロマネ　　　　　　　合格
22年秋　ITストラテジスト　　　合格

プロマネには苦労しましたが、昨年なんとか合格出来ました。

ITストラテジストに合格したら
情報処理はしばらく休もうと思いながら
3年間受験し続けたのですが
論文系試験制覇の欲が出てきて
この春、システム監査を申し込みました。

23年度春季試験は延期になりましたが
「システム監査技術者に楽々合格」の力を借りて
試験に備えます。

今後ともよろしくお願いします。

[484]　zaki　(2011/03/24 Thu 11:21) mail

試験結果アンケート2010

合格発表が近づいてきました。
発表がありましたら、試験結果に関するアンケートにご協力をお願いします。

※合否は問いません。

以下をコピーいただき、それぞれ回答をお願いします。
よろしくお願いします。

[試験結果アンケート]
◆１．スコアを教えてください。
◆２．何回目の受験ですか？
◆３．受験の動機は何ですか？
◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど
◆５．過去問は何年分を各何回実施しましたか？
◆６．模試は受けましたか？また、受けた方が良いですか？
◆７．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？
◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
◆１０．合格に最も大切なのはズバリなんでしょう。
◆１１．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
◆１２．書籍などへの転載可否
　ここに書いていただいた貴重な合格体験を、私の書籍に転載させていただくことは可能でしょうか？皆様の貴重なご意見を多くの方に読んでいただき、勉強の参考にしていただくためです。
　（例）転載可能　or　転載否
◆１３．最後に一言お願いします。

[469]　管理者　(2010/12/17 Fri 05:20)

---

Re: 試験結果アンケート2010

※名前間違っていたので修正しました。
こんにちは、yh0807と申します。合格しました！！
以下、アンケートへの回答になります。

◆１．スコアを教えてください。
　午前�T得点 ***.**点
　午前�U得点 92.00点
　午後�T得点 82点
　午後�U評価ランク A

◆２．何回目の受験ですか？
　1回目

◆３．受験の動機は何ですか？
　1.日常やっている運用の業務を保証する資格がほしかった
　2.資格奨励金(15万円)がほしかった

◆４．役に立った勉強教材を教えてください。
　「ITサービスマネージャ 「専門知識+午後問題」の重点対策」(管理人様の著書)

◆５．過去問は何年分を各何回実施しましたか？
　午前2：最近4年分を1回ずつ
　　　　(ただし、ITILv3の勉強はしておいたほうが良かったかも…)
　午後1：最近5年分を2回ずつ
　　　　→1回やって、解説を読んで間違ったところを確認した後、時間を置いてもう一回。
　午後2：論文を書いた問題→4問
　　　　 あらすじだけ書いたもの→8問
　　　　 →最近4年分をやりました。同じ事象を元に、いくつかの
論文に展開させて、本番に対応できるようにしました。

◆６．模試は受けましたか？また、受けた方が良いですか？
　受けてないので、必要ないかと。
　ただし、論文は誰かに目を通してもらいアドバイスを受ける必要が有ると思います。

◆７．本試験では、どの問題を選びましたか？
　午後1：問２と問４
　午後2：問３
　また、どのように問題選択をしましたか？
問題を1番から斜め読みしていき、分からなさそうな言葉が出てきたり、苦手なジャンルであればやめる。どの意見も大体毎回この方法です。

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
　午後1、午後2では、ひたすら基本・原則論に忠実に考える。
　自分の考えである部分をはっきり強調する。
　それ以外の部分で自己主張しない(ネットワークや開発技術を詳細に書いて誇示しない)

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
　難しい問題が出来なかった後は、出来る問題をやって自身を取り戻す。
　資格奨励金の使い方を考える。

　
◆１０．合格に最も大切なのはズバリなんでしょう。
　人の意見・本の記載内容を素直に理解すること。
　こつこつ努力すること。

◆１１．あなた様について教えてください。
　文系出身・26才・女
　業種：システム開発業
　部門：社内情報システム担当(4年間)
　保有資格：
　ITILファウンデーション
　MCP/MCA/MCDST
　LPIC1
　基本情報/応用情報/旧セキュリティーアドミニストレーター/
　セキュリティスペシャリスト/ネットワークスペシャリスト

◆１２．書籍などへの転載可否
　可

◆１３．最後に一言お願いします。
　書籍やこのサイトを通じて勉強させていただいた管理人様、ここの掲示板で論文のアドバイスを下さった皆様、ありがとうございました。
　資格を取得しただけで満足せず、実務でも活かせる様に頑張ります。

[470]　yh0807　(2010/12/20 Mon 12:27)

---

Re^2: 試験結果アンケート2010

ご無沙汰しております。うーちゃかです。
合格していました。やっぱり嬉しいです。

◆１．スコアを教えてください。

　午前�T　71.40点
　午前�U 84.00点
　午後�T 76点
　午後�U A
　
　合格してほっと一安心ですが、論文の採点は
　かなり甘かったんじゃないだろうかと思います。

◆２．何回目の受験ですか？

　1回目。

◆３．受験の動機は何ですか？

　同じ職場の同期が去年合格して、興味を持ちました。
　また、正直、資格報奨金が欲しかったです。

◆４．役に立った勉強教材を教えてください。
　
　iTEC　徹底解説　本試験問題（2009）
　　※上記の同期のお古なので、ちょっと古いです。　
　　　2009年の問題はIPAからダウンロードし、わからない
　　　ところは、ネットで解答を参考にしました。

◆５．過去問は何年分を各何回実施しましたか？

　2006、07、08年のを2〜3回。
　ただし、論文については過去のは読んで傾向をつかんだだけ。
　実際に書いたのは、インシデント管理、問題管理、変更管理を
　テーマにした3本。
　（この3つのうち一つは必ず出ると予想した）

◆６．模試は受けましたか？また、受けた方が良いですか？

　新宿で iTECの模試を受けました。
　ちなみに、9月に受けて、E判定でした。
　模試について「難易度に信憑性が無い」という方もいますが、
　刺激を受けるという意味では受ける価値は多いにあると
　私は思います。
　（やっと、そこからやる気に火がついた、ともいえる）

◆７．本試験では、どの問題を選びましたか？

　午後１：　問3と問4
　午後２：　問3（インシデント管理）

　午後1は、ヘルプデスクとセキュリティという、実務で
　やっていることに近い内容の問題だったので、この2つに
　しました。
　最初は問1にしようかとも思ったのですが、「ない場合は、
　なし、と書きなさい」というのが妙にひっかかってやめました。　

◆８．合格の場合、合格できた理由は何だと思いますか？

　理由になってないかもしれませんが、
　試験は1回で受かる、と決めて勉強すること。
　（ただし、1回で受からなかった試験はもちろんあります）

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？

　資格報奨金を使ってる自分とか、キャリアアップした自分
　という「楽しい未来にいる自分」を思い浮かべてました。

◆１０．合格に最も大切なのはズバリなんでしょう。

　この業界の社会人であれば、日々の業務をITサービス
　マネージャ試験と絡めて考え、対応すること。だと思います。
　運用に携わっている人であれば、仕事と試験勉強を一緒に
　できる、おいしい試験だと思います。
　（NW、DBだと、業務＝仕事、とも言えないと思うので）
　
◆１１．あなた様について教えてください。
　
　文系出身　30歳　
　基本情報処理
　ネットワークスペシャリスト
　CCNA、CCNP（どちらも失効）
　ITILファウンデーション（v2）
　
◆１２．書籍などへの転載可否
　
　転載可能

◆１３．最後に一言お願いします。

　テキストに向かって勉強したくないなー、というときは
　よくこちらのHPにお世話になってました（笑）。
　管理人様、掲示板で意見を交わさせて頂いた方、どうも
　有難うございました。
　そして、今度はシステム監査のほうでお世話になります。

[471]　うーちゃか　(2010/12/20 Mon 19:23)

---

Re^3: 試験結果アンケート2010

たぬきです。はじめましてです。

◆１．スコアを教えてください。
午前１：免除
午前２：88
午後１：68（危ねぇ・・・）
午後２：A

◆２．何回目の受験ですか？
SMとしては2回目です。昨年午後2がB判定でした。

◆３．受験の動機は何ですか？
去年落ちたので、リターンマッチです。
プロマネとかアーキテクトはまだ早かったり自分の仕事と
ちょっと縁遠いので。

◆４．役に立った勉強教材を教えてください。
ITECの重点対策2010です。一番役に立ちました。
あと、同じくITECの本試験問題集と、合格論文の書き方・
事例集 第2版も買いました。

◆５．過去問は何年分を各何回実施しましたか？
3年分をそれぞれ１〜２回です。

◆６．模試は受けましたか？また、受けた方が良いですか？
受けてません。過去問で十分だと思います。

◆７．本試験では、どの問題を選びましたか？
午後１：問２と問４
自分のわかりそうなキーワードが多い問題を選びました。
聞いたことのないキーワードが多い問題を外しました。

午後２：問３（インシデント管理）
3問の中では、サービスデスク業務が一番理解できていたので。

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
論文の練習をきっちりしたことです。本番はダメダメでしたが、
合格できてました。練習で作った論文は管理人さんにも見てい
ただきました。ありがとうございました。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
合格しなきゃというプレッシャーを持ち続けるようにしました。（でも苦しい…）

◆１０．合格に最も大切なのはズバリなんでしょう。
自分を追い込むこと。

◆１１．あなた様について教えてください。
30代中盤です。仕事はサーバ構築が多いです。
テクニカルエンジニア（ネットワーク）、セキュスペ

◆１２．書籍などへの転載可否
転載可能

◆１３．最後に一言お願いします。
合格したときの快感があるから、試験はおもしろい！

[472]　ぽんぽこタヌキ　(2010/12/20 Mon 22:40)

---

Re^3: 試験結果アンケート2010

こどらんと申します。
お陰様で合格することができました。

◆１．スコアを教えてください。
　午前�T得点 ***.**点
　午前�U得点 76.00点
　午後�T得点 61点
　午後�U評価ランク A

◆２．何回目の受験ですか？
　1回目

◆３．受験の動機は何ですか？
　1.スキル向上
　2.資格奨励金がほしかった

◆４．役に立った勉強教材を教えてください。
　「ITサービスマネージャ 「専門知識+午後問題」の重点対策」
　「iTEC　徹底解説　本試験問題」
　「ITサービスマネージャ 合格論文の書き方・事例集第2版」

◆５．過去問は何年分を各何回実施しましたか？
午後�T：直近6年分を2回
午後�U：障害管理、性能管理に関するテーマを
　　　　　かなり昔まで遡って1〜2回づつ書き、他のテーマは
　　　　　読むだけ。

◆６．模試は受けましたか？また、受けた方が良いですか？
　受けていません。模試の問題の質は本試験のそれに
　遠く及ばないので。但し、論文の添削をこのサイト管理者様に
　して頂きました。

◆７．本試験では、どの問題を選びましたか？
　午後�T：問3と問4
　午後�U：問3
　また、どのように問題選択をしましたか？
　午後�Tは、2問解答なので、時間的に少し余裕があると思い、じっくり吟味しました。
　午後�Uは、インシデント管理が出たら選択すると受ける前から決めていました。

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
諦めないこと。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
　「合格した瞬間」や「合格を会社に報告する時の手続き」をリアルに想像する。

◆１０．合格に最も大切なのはズバリなんでしょう。
　諦めないこと。

◆１１．あなた様について教えてください。
　職種：今年の1月からホスト（汎用機）のオペレータ…
　年代：30代
　保有資格：2種、1種、FE、SW、NW、DB、SC、
　　　　　　　旧制度のOracle Master 9i Plutinum
　　　　　　　CCNA（現在は失効）
　　　　　　　日商簿記2級

◆１２．書籍などへの転載可否
　転載可能

◆１３．最後に一言お願いします。
　一言じゃないですが…、
　論文を書く際に意識したのは…
　(1)数値を入れる。（具体性が増す）
　(2)「〜だからである。」「理由は〜」を意識して入れる。（根拠を述べる展開にもっていく）
　(3)「私は〜」を意識して入れる。（自分の行動を示す）
　(4)テーマをわかりやすいものにする。（採点者をつかれさせない。）但し、あたりまえになりすぎないようにする。
　(5)問題文の中に「〜も重要である」といった記述があれば利用する。

このサイトの管理者様に論文を添削して頂いた際、テーマ選定に問題がある旨、指摘されました。「身近なわかりやすいものをテーマにした方がよい」とアドバイスを受けました。それを忠実に守ったことが今回の合格につながったように思います。
　ありがとうございました。

[473]　こどらん　(2010/12/20 Mon 22:42)

---

Re^5: 試験結果アンケート2010

この掲示板で論文を添削していただいた、かずかずです。
いろいろと教えていただいたことが大変参考になりました。
おかげで合格することができました。

◆１．スコアを教えてください。
午前�T：78.20点
午前�U：84.00点
午後�T：65点
午後�U：Ａ

◆２．何回目の受験ですか？
SMとしては、旧システム管理の頃も含めて全く初めてでした。

◆３．受験の動機は何ですか？
自分自身は直接携わっていないのですが、ITサービスに携わっている方と接する
仕事をしており、業務上ITサービスマネジメントを理解する必要がありました。
また、他の方と同様に資格報奨金が欲しかったです。（私の会社は５万円）

◆４．役に立った勉強教材を教えてください。
用途別に色々と参考書や問題集を用意しました。特に無駄な買い物はしなかった
と思っていますが、特に役立ったのは以下の３冊です。
（ITECの方が読んだら泣いて喜びそうな組み合わせです。）

(1) ITEC 高度専門 ITサービスマネジメント
　　　教科書的な本ですが、午前�U以降の対策に先立って、この本で
　　　基本的な知識の習得に努めました。
　　　また、試験直前の午後�Tと午後�U対策でも、各プロセスの整理
　　　に活用しました。

(2) ITEC ITサービスマネージャ 「専門知識＋午後問題」の重点対策
　　　実際の試験問題の接し方は、この本で学びました。
　　　特に午後�T対策は、「まず自分で解いてみて、解き終わったら
　　　解説を読み込む」ということを愚直に実践しました。

(3) ITEC ITサービスマネージャ 合格論文の書き方・事例集
　　　論文作成に必要な記述レベルを知るのに役立ちました。
　　　もちろん、重点対策も役立ちましたが、いろいろな実例をもとに
　　　ネタ作りをしました。
　　　また、ストーリーをまとめるのに論文設計ワークシートが役立ちました。

◆５．過去問は何年分を各何回実施しましたか？
上記で色々と購入した割には、年度別の問題を午前�Tから午後�Uまで
時間を図って解く、ということをやっていません。

◆６．模試は受けましたか？また、受けた方が良いですか？
ITECの模試を新宿で受けました。（結果はＤ判定）
過去に出たことがない新しい問題に遭遇したときにどれだけ
対応できるかで自分の実力を知ることができるため、決して
損ではないと思います。

◆７．本試験では、どの問題を選びましたか？
午後�T：問１と問２、　午後�U：問２

邪道と言われるかもしれませんが、午後�Tと午後�Uの対策勉強を
する際、情報セキュリティ関連の問題を捨てました。
その代わり、午後�Tではサポートサービスとサポートデリバリ、
午後�Uではサポートサービスに絞り込んで対策を立てました。
（「専門知識＋午後問題」の重点対策は、ひと通り読みましたので、
　念のため。）

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
模試は散々な結果でしたが、午後�Tと午後�Uを解くにあたって、
サポートサービスとサポートデリバリの各プロセスの理解が足りない
のが原因だと考え、◆４で挙げた教材(1)で各プロセスの説明を
見直して自分自身でプロセスフローをPowerPointに書き出して読み返した
のがよかったと思います。
また、午後�Uは模試をもとに自分自身で原稿用紙を作成して、◆４(3)
の論文設計ワークシートと合わせてコピーをとり、論文設計から原稿用紙
への書き込みまで実際にやってみて、この掲示板で論文を添削していただ
いたことも役立ったと思います。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
仕事場や家庭で、試験を受けることを宣言しました。
特に家庭では、合格したら報奨金がもらえることを話したら奥さんから
プレッシャーをかけられるようになったことも一因だったと思います。
（全然、工夫じゃないですね。）

◆１０．合格に最も大切なのはズバリなんでしょう。
「自分で書いて解く」

◆１１．あなた様について教えてください。
職種：某メーカーの情報システムソリューション部門に所属
　　　（いわゆる、メーカー系ＳＥの部隊です。）
年代：40代
保有資格：1989〜1990年に、旧第二種、旧第一種を取得
　　　　　2001年に、旧ソフトウェア開発技術者を取得
　　　　　上級はこれまで未取得

◆１２．書籍などへの転載可否
転載可能

◆１３．最後に一言お願いします。
試験対策の主体は参考書・問題集でしたが、受験対策のスケジュール検討や
論文対策（添削）は、ここの掲示板が大変役に立ちました。
管理人様、添削していただいた方には大変感謝しています。

[474]　かずかず　(2010/12/21 Tue 01:37)

---

Re^6: 試験結果アンケート2010

こんばんは。ショウです。

まずは結果からですが「合格」でした。
論文試験で初合格です。本当に嬉しいです。

以下、アンケート回答です。

[試験結果アンケート]

◆１．スコアを教えてください。

午前�T： 免除
午前�U： ７２．００点
午後�T： ７０点
午後�U： Ａランク

◆２．何回目の受験ですか？

２回目

◆３．受験の動機は何ですか？

以前に保守運用関連の業務に従事しており、
とっつき易いと考えたいたのと、
去年、不合格だったので再チャレンジするため。

◆４．役に立った勉強教材を教えてください。
（例）A社の本「BCD」、E社の通信教育、会社の研修、雑誌F、HPなど

・過去問（16年〜21年）
・「ITサービスマネージャ 「専門知識+午後問題」の重点対策」(管理人様の著書)
・ある非営利活動法人の勉強会

◆５．過去問は何年分を各何回実施しましたか？

６年分を４〜５回

◆６．模試は受けましたか？また、受けた方が良いですか？

前回はＴＡＣで模試を受けましたが、
今回は受けておりません。

受けたほうがいいとは思います。
理由としては、
論文については自己採点が困難であり、
模試にて自分の論文作成能力を知っておく必要があるからです。

また、模試を受けるなら、私は「ＴＡＣ」の模試がいいと考えます。
理由としてはＴＡＣの模試は本試験に近い感じがします。

別の試験区分（ＮＷ）のときに「itec」の模試を受けましたが、
難しすぎて散々な結果になってしまいました。

それ以来、itecの模試は本試験に少し離れている印象を受け、
模試を受けるならＴＡＣを選んでいます。
最近はitecを受験したこと無いので、なんとも言えないので
いち個人の意見だと思ってください。

◆７．本試験では、どの問題を選びましたか？
（例）午後１：問○と問○、午後２：問○
　また、どのように問題選択をしましたか？

午後�T：　問１と問２
午後�U：　問３

【午後�Tの問題選択について】
１）午後�Tの問題選択については、開始前に解答用紙を眺めて、
　　なるべく解答数が多そうな問題を選ぼうと検討する。
　　計算問題が苦手なので数値を入れるだけの解答欄はパスしがち。。。
２）ざっと表題をよんで、どんなテーマなのか確認する
　　得意そうなテーマならそれだけで選ぶ場合もあるが、
　　過去に何回かそれで失敗しているので、ここでは選ばない。
３）問１から読み始める。。
　　１ページ読んで「スーッと」頭に問題の状況が
　　理解できるようならば、そのまま、その問題を解く。
　　そうじゃなく、なにか引っかかるものがあったり、
　　理解不能ならばパスして、次の問題にする。
４）３）問１、問２、問３、問４　とやっていく。
　　仮に問１、問２がスムーズに理解できるようならば、
　　問３、問４は全く見ない。
　　逆に１問もスムーズに理解できなければ、
　　なるべく分かりやすそうなものを感覚で選ぶ。

ある程度、午後�Tの過去問で訓練をしないと、
問題選択の感覚は養えないと考えています。

【午後�Tの問題選択について】
今年は正直、問１も問２も私にとっては選ぶ余地が無かった。
今年は論文を１回も書かずに望むという無謀な挑戦となったが、
昨年書き溜めた論文で唯一「インシデント関係」については、
多い方だったので、問３を選ばざる得なかった。
逆に言うと得意なテーマを作ってしまって、
それを選ぶという方法がいいと思います。

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）

今回と前回では正直あまり差はありません。
過去問を解いた数が１年増えた程度です。
正直、午後�Uについては今回の方が準備不足です。

ただし、試験当日は妙に落ち着いて受験できたことや、
試験直前までＡ評価をもらった、
去年の模試の論文を頭に入れて望んだ事が、
変に力が入りすぎずで良かったかも知れません。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？

今年は、論文を書くための２時間など、
まとまった勉強時間を全くとることができませんでした。

私が工夫したのは、隙間の時間をいかに勉強時間に割り当てるか？です。
会社のお昼休みの１時間のうち、前３０分を昼食時間とし、
後３０分を午後１の勉強時間に割り当てました。
３０分で１問を解くというペースです。

なるべく毎日、今日はできなかったら明日は必ずする。
というように継続するという習慣をつけることで、
モチベーションを維持しました。

◆１０．合格に最も大切なのはズバリなんでしょう。

「継続」です。
過去問を１日１問３０分だけでいいので、
継続して、あきらめずにやることです。

今回、私が合格できたのはそれに尽きます。

◆１１．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など

職種：通信キャリアの法人部門（ソリューション部門）に所属
年代：３０代
保有資格：　旧第二種、旧初級シスアド ※両方とも学生時代に取得　
　　　　　　テクニカルエンジニア（ネットワーク） 2008年取得
　　　　　　ＩＴサービスマネージャ　2010年取得(今回)

◆１２．書籍などへの転載可否

　転載可能

◆１３．最後に一言お願いします。

午前、午後�Tは過去問をひたすら解くことで対応できると考えます。
テクニカルエンジニア（システム管理）時代の過去問まで準備し、
自分にあった過去問題集（解説付き）で勉強することをお薦めします。

午後�Uの論文については、まず自分で書く。
そして他人に添削してもらう
という事が絶対に必要だと思います。
そして、その論文かからなずＡ評価になるまで
繰返し精度を上げる必要があると考えます。

とっかかりは、管理人様の著書の本などで、
論文の書き方をマスターすることから始めることを
お薦めします。

[475]　ショウ　(2010/12/21 Tue 03:36) mail

---

Re^7: 試験結果アンケート2010

ご無沙汰しています。すぎエモンです。
合格された皆様、本当におめでとうございます！
私も自分の事の様に嬉しいです。

[試験結果アンケート]
◆１．スコアを教えてください。

システムアーキテクトを受験しました。
スーパー惨敗でした。自分でも信じられません。
午前�T得点***.**点
午前�U得点76.00点
午後�T得点26点
午後�U評価ランク-

午後�T26点って…、にじゅうろくてんって…、
しかしよく考えると、自分の問題を解いた感触から
考えるとこれは、何かおかしい点数です。
恐らく私は、１問を選択ミスしていますね、どちらかの問題が
選択した問題番号と実際に解いた問題とが一致していなかった
ようです。実際は52点ぐらいだったんのでしょうね。
自分を戒めるための良い教訓だと思います。
皆様はこういう凡ミスをなさらないようにお気をつけ下さい。

◆２．何回目の受験ですか？
システムアーキテクトは１回目です。

◆３．受験の動機は何ですか？
システムアーキテクトが未取得だからです。

◆４．役に立った勉強教材を教えてください。
何もありません。勉強教材はナシで挑む貧乏主義なので。

◆５．過去問は何年分を各何回実施しましたか？
IPAに掲載されているものを全部、３回ずつ実施しました。

◆６．模試は受けましたか？また、受けた方が良いですか？
模試を受けたことはありません。不要だと思います。

◆７．本試験では、どの問題を選びましたか？
午後１：問１と問３、午後２：問２
問題選択は、組み込み系問題を避けて選択しました。

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
不合格できた理由は、問題文の選択をしっかりと確認しなかったから
だと思います（笑）

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
人様の論文を査読させて頂くと、論文を書くモチベーションが
不思議とあがります。

◆１０．合格に最も大切なのはズバリなんでしょう。
徹底的な努力とわずかな”運”ですかね。

◆１１．あなた様について教えてください。
世代は、３０代中盤です。
取得資格は以下の通りです。
　テクニカルエンジニア（ネットワーク）
　テクニカルエンジニア (情報セキュリティ)
　テクニカルエンジニア (システム管理)
　プロジェクトマネージャ
　システム監査技術者
　ＩＴストラテジスト
　第１種情報処理技術者
　第２種情報処理技術者
　電気通信主任技術者（伝送交換）
　工事担任者資格（AI・DD総合種）

◆１２．書籍などへの転載可否
転載可能（この惨めな内容でよければ）

◆１３．最後に一言お願いします。
９連敗→６連続合格→２連敗です。
やはり、十分な努力を行った後も結果が付いて
来ないこともありますので、ダメだった人も
運が向くまで気長に頑張ってみて下さい。
努力していればそのうち幸運が降臨することも
あるみたいです。

[476]　すぎエモン　(2010/12/21 Tue 13:07) mail

---

Re^8: 試験結果アンケート2010

はじめまして、わくわく と申します。
感謝を込めて受験結果をご報告いたします。

[試験結果アンケート]
◆１．スコアを教えてください。
　午前1得点 ***.**点
　午前2得点 92.00点
　午後1得点 81点
　午後2評価ランク A
◆２．何回目の受験ですか？
　1回目
◆３．受験の動機は何ですか？
　1.ITILv2ファンデーション取得の延長線上
　2.現在の業務に有効活用するため
　3.監視は見てるだけで楽だね..という一部の人の考え方を正すため
◆４．役に立った勉強教材を教えてください。
　ITサービスマネージャ合格論文の書き方・事例集〈第2版〉（アイテック）
　徹底解説ITサービスマネージャ本試験問題〈2010〉（アイテック）
　高度専門 ITサービスマネジメント（アイテック）
　システムはなぜダウンするのか（日経BP）
　資格取得ノウハウ提供サイト　シカク■マニア（Webサイト）
　ITサービスマネージャ試験に楽々合格（Webサイト）
　　本当は「専門知識＋午後問題」重点対策も購入したかったのですが
　　どこに行っても売り切れでとても残念でした。
◆５．過去問は何年分を各何回実施しましたか？
　午前2は2009年を1回、午後1は2007年から2009年を1回
　午後2は対策本を読んでイメージ作りやポイントのみ書いただけで
　論文は1本も書ききることが出来ませんでした。（無謀ですね）
◆６．模試は受けましたか？また、受けた方が良いですか？
　受けていません。
　論文だけでも添削してもらった方が良い結果を出せると思う。
◆７．本試験では、どの問題を選びましたか？
　午後1：問3と問4
　午後2：問3
　身近なテーマであるのとセキュリティ取得を活かして選択
◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
　論文の書き方のコツにならって書いたのが良かったと思いますが
　管理人様にはとても感謝しております。
　練習不足、準備不足のため設問ウで3、4行の文字数不足になりましたので
　絶対に不合格だと思っていました。
◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
　甘いものやおいしいランチで自分を元気づける。
　運用を軽視する人への反骨精神。
◆１０．合格に最も大切なのはズバリなんでしょう。
　最後まであきらめないこと。
◆１１．あなた様について教えてください。
　職種：ネットワークインフラの運用
　保有資格：情報処理（テクニカルネットワーク、セキュリティスペシャリスト）
　　　　　　ITILv2ファンデーション
　年代：30代中盤
◆１２．書籍などへの転載可否
　転載可能
◆１３．最後に一言お願いします。
　管理人様の掲示板で「規定文字数不足でも合格することはある」という
　一文に救われました。本当に感謝しております。
　おかげで、受験料の領収書とID／パスワードは捨てずにすみました。

[477]　わくわく　(2010/12/23 Thu 00:57)

---

Re^8: 試験結果アンケート2010

管理人殿

昨年のNWスペシャリスト取得から随分とお世話になっております。
今回は、残念ながら不合格でしたが合否問わずとありますので、
管理人さんへのお礼と自らの戒めを含めフィードバックいたします。

また合格された皆様、おめでとうございます。
事情により来年以降受験が困難なため、数年先となりますが
再チャレンジできればと思ってます。
＃あぁ午前�Tからやり直しか…(涙)

◆１．スコアを教えてください。
　午前�T得点 免除
　午前�U得点 76.00点
　午後�T得点 52点
　午後�U評価ランク -

◆２．何回目の受験ですか？
　1回目

◆３．受験の動機は何ですか？
　当初は、DBスペシャリストを1年かけて勉強しようかと考えて
　ましたが、本HPでITサービスマネージャの試験内容(運用系の
　試験である)を知った事。
　また現在、データセンター系ネットワーク運用業務のマネー
　ジャに携わっているため。

　試験(名)がシステム管理のままだったら、受験はしなかった
　と思います。

◆４．役に立った勉強教材を教えてください。
　不合格でしたので、利用した教材という意味では、

　午前：翔泳社　硬度試験午前対策（09年NW受験時のもの）
　午後：翔泳社　情報処理教科書　ITサービスマネージャ
　　　　iTEC 重点対策　ITサービスマネージャ

　重点対策の方がITマネージャという視点で書かれていると
　思います。
　また情報処理教科書と重点対策は殆ど構成が一緒なので
　どちらか1冊で十分です。
　＃教科書とありますが、NWやSCなどとは構成が違います。

◆５．過去問は何年分を各何回実施しましたか？

　情報処理の教科書を1回
　重点対策にある過去問を2回
　午後�T中心に解いてました。

◆６．模試は受けましたか？また、受けた方が良いですか？
　TACの模試を受験しました。
　＃iTECは締切が過ぎてまして…。

　個人的には、受験した方が良いと思います。
　現在の理解度が可視化できますし、小論文を客観的に見て
　頂けるのは、良い事だと思います。

◆７．本試験では、どの問題を選びましたか？
　午後�T
　　問２と問４
　理由：
　　問２：現在の業務に近い問題だった為（LBを利用した構成)
　　問４：昨年、セキュスペ取得のため、勉強していた為　　　

　午後II
　　問２(リリース管理)
　理由：直近でリリース管理関連の課題が業務で有ったため。
　　　　＃インシデント管理(問３)と迷いましたが…。

◆８．合格の場合、合格できた理由は何だと思いますか
　不合格のため、省略します…。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
　・資格取得が全てではありませんが、少なくとも取得できれば
　　基礎知識を有しているという証明ができる事。

　・自身のスキルアップ

　
◆１０．合格に最も大切なのはズバリなんでしょう。
　不合格のため、省略します…。

◆１１．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など

　職種：
　　・製造業のグループ(IT)会社勤務
　　　データセンター内のNWサービスを提供してます。
　年代：
　　・30代後半
　保有資格
　　・OracleMaster Silver(今のBronze？)
　　・CCSA（CheckPoint社Firewall-1の資格）
　　・ITILv2ファンデーション
　　・ネットワークスペシャリスト
　　・情報セキュリティスペシャリスト
　　
◆１２．書籍などへの転載可否
　　・転載可能

◆１３．最後に一言お願いします。
・結果について
　　最初に合否を確認し、不合格と知りました。
　　てっきり小論文で落ちたとばかり思ってましたが、まさかの
　　午後�Tでの不合格でした。

　　得点配分はわかりませんが、問４のセキュリティの回答の書き
　　方に非常に迷った点がありました。
　　前回、情報セキュリティを受講したのを引きづり、運用と言う
　　より技術的な解答をした所があったのではないかと思います。
　　
・管理人さんへ
　　いつかは本資格は、取得したいと考えてます。
　　またお世話になると思いますが、よろしくお願いします。

[478]　Noah　(2010/12/23 Thu 01:45) mail

---

Re^10: 試験結果アンケート2010

管理人様　いつもこのページをみてやる気を出しておりました。また重点対策にも大変お世話になりありがとうございました。以下少しでもみなさんの参考になれば幸いです。

◆１．スコアを教えてください。
午前�T：68.00点
午前�U：76.00点
午後�T：75点
午後�U：Ａ

◆２．何回目の受験ですか？
1回目

◆３．受験の動機は何ですか？
書店で問題集をみてこれならできそうじゃん、それに今やってる仕事に役立つじゃんと思ったから。それと後輩に範を示す意味もありました。

◆４．役に立った勉強教材を教えてください。
特に役に立った教材に「◎印」をつけました。

◎「専門知識＋午後問題」重点対策
◎ITサービスマネージャ試験に楽々合格(Web)
・応用情報・高度に出る午前共通知識問題(ITEC)
◎ITIL実践の鉄則(技術評論社)
・ITIL V3実践の鉄則(技術評論社)
・24時間365日サーバ/インフラを支える技術(技術評論社)
・キャパシティプランニング(O'REILLY)
・ITアーキテクトのやってはいけない(日経BPムック)

◆５．過去問は何年分を各何回実施しましたか？
午前�T：「応用情報・高度に出る午前共通知識問題(ITEC)」を中心に1回
　　　　H21年度分を1回
午前�U：「専門知識＋午後問題」重点対策を中心に3回
　　　　H21年度分を1回
午後�T：H16年度からH21年度までを各1回
午後�U：H16問1、H20問3、H21問2を各1回と論文ネタの整理

◆６．模試は受けましたか？また、受けた方が良いですか？
模試は受けませんでしたが、自分の実力を客観的に把握できないようであれば受けたほうがよいと思います。

◆７．本試験では、どの問題を選びましたか？
午後�T：問1と問3
午後�U：問3
問題文をパッと見て、情景が頭に思い描けるような問題を選択しました。言い換えれば経験に近く論点をイメージしやすい問題でしょうか。あと年なので計算問題が入っているものは避けるつもりでした。

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
午前問題は試験直前の詰め込みです。（暗記で対処できる問題も多いため）
今回はこれに失敗して、午前のピークが一週間前に来てしまいました。一週間前にやったH21年度過去問の結果は午前�T�Uとも80%を超えていました。

午後問題は出題者の意図を問題文から読み取って、独りよがりや一般論の解答にならないように誠実に解答することです。特に午後�Tは特定の解答になるように設問が作成されていると肝に銘じることだと思います。
午後�Uは設問に則して章立てとあらすじを20分程度かけて作成し、丁寧な文字で主語と述語の関係が明確になるような歯切れの良い文章を心がけました。このために私は一文一文読み返しながら書くようにしています。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
夜ときどき職場の仲間と飲みに行ったり、日曜日の午後は家族サービスのために必ず空けるようにしました。また常に目の前に問題集をおいておきました。

◆１０．合格に最も大切なのはズバリなんでしょう。
自分で決めたことを「最後までやり抜く意思」でしょう。
継続をすれば結果は後からついて来ます。

◆１１．あなた様について教えてください。
ネットワーク系のシステム設定を振り出しに、システム開発、システム企画、セキュリティ管理と業務が変わり、現在はシステム運用管理を行なっています。
資格報奨金は今まで一度も出たことがありません。(涙)
しかし「その分野の共通語で議論できるようになること」「知識を体系的に整理できること」「不足するスキルを補うことができること」を目標にその時々の業務に関連する資格を取得してきました。

オンライン
プロジェクトマネージャ
アナリスト
情報セキュアド
情報セキュリティ

40代最後です、来年50になります。
計算が遅くなったので、通勤電車の中で九九を唱えたり、広告に書いてある電話番号の数字を順番に足し算したりして何とかスピードを維持しておりました。(涙涙)

◆１２．書籍などへの転載可否
転載可能

◆１３．最後に一言お願いします。
シャープペンはグリップの柔らかいものがよいよ。

[479]　７７　(2010/12/23 Thu 14:33)

---

Re^11: 試験結果アンケート2010

◆１．スコアを教えてください。
午前�T　得点***.**点　免除
午前�U　得点76.00点
午後�T　得点73点
午後�U　評価ランクA

◆２．何回目の受験ですか？
４回目（システム管理２回を含む）

◆３．受験の動機は何ですか？
自己実現のため

◆４．役に立った勉強教材を教えてください。
ITサービスマネージャ 「専門知識＋午後問題」の重点対策
IT Service Management教科書 ITIL V3 ファンデーション 第2版

◆５．過去問は何年分を各何回実施しましたか？
今回は２年間分を１回、過去の受験を含めれば６年間分くらいは
解いてます。

◆６．模試は受けましたか？また、受けた方が良いですか？
会社でＩＴＥＣの模擬テストを受験
受けないよりは受けた方がいいが、いつも低得点です。

◆７．本試験では、どの問題を選びましたか？
午後１：問２と問３
午後２：問２

◆８．合格の場合、合格できた理由は何だと思いますか？
（不合格時の比較などもあれば）
ＩＴＩＬの学習の効果が大きかったです。
おかげで、ＩＴＩＬ　Ｖ３　Ｆｏｕｎｄａｔｉｏｎにも合格
できました。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
意地です。

◆１０．合格に最も大切なのはズバリなんでしょう。
合格するまで諦めない。

◆１１．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
普通のＳＥ
情報処理技術者試験：ＡＮ、ＰＭ、ＡＥ、ＤＢ、１種、２種
ＩＴコーディネータ、ＩＴＩＬ　Ｖ３　Ｆｏｕｎｄａｔｉｏ

◆１２．書籍などへの転載可否
転載可能

◆１３．最後に一言お願いします。
管理人さん、ありがとうございました。
特に「重点対策」の論文対策は素直で分かりやすかったですよ。

次はシステム監査受けます。
「システム監査技術者に楽々合格」でもお世話になります。
私のTwitterＩＤは　takashi300403　です。

[480]　スイマー　(2011/01/01 Sat 20:40) web

---

Re^12: 試験結果アンケート2010

はじめまして。
いつもサイトは訪れていますが、ＢＢＳへは初めてです。
感謝の意を込めて書き込みます。

◆１．スコアを教えてください。
　午前�T得点　***.**点
　午前�U得点　68.00点
　午後�T得点　82点
　午後�U評価ランク　A

◆２．何回目の受験ですか？
　1回目

◆３．受験の動機は何ですか？
　1.今後運用管理業務を行う可能性があったため。
　2.「ITサービスマネージャ試験に楽々合格サイト」で見た
　　ITサービスマネージャ試験は難しい試験ではない、を鵜呑み。
　3.合格一時金（15万円）目当て。

◆４．役に立った勉強教材を教えてください。
　「ITサービスマネージャ 「専門知識+午後問題」の重点対策」(管理人様の著書)
　「ITサービスマネージャ試験に楽々合格サイト」の記事全て。
　過去の業務経験を思い出す。

◆５．過去問は何年分を各何回実施しましたか？
　午前2,午後1:1年前を1回。
　午後2:実施なし。

◆６．模試は受けましたか？また、受けた方が良いですか？
　受けていません。なので受けなくても良い、としか言えません。
　ただ、論文系のスキルを上げるには模試は良い材料になるとは思います。

◆７．本試験では、どの問題を選びましたか？
　また、どのように問題選択をしましたか？
　・午後1:問3,問4
　　　→新人時代にヘルプデスクまがいを経験したのでダメもとで(問3)
　　　→数少ない得意分野の中で、セキュリティは多少自信があった(問4)
　・午後2:問2
　　　→昔、リリース管理を行ったことがあるため

◆８．合格の場合、合格できた理由は何だと思いますか？（不合格時の比較などもあれば）
　・午前2〜午後1
　　「〜重点対策」、「〜楽々合格」の記事をくまなく読み過去問題を解く。
　　過去問題を解く際は、答えだけではなく
　　「なぜそうなるのか」「他の選択肢はどういう意味か」を意識したのが良かったかも。

　・午後2
　　1.今までの業務経験を思い出す。
　　2.業務経験から「〜重点対策」で挙げていただいた「筋書き」を頭の中で整理する。
　　3.困難に打ち勝つリーダとなるよう、脚色方法を妄想する。
　　
　　を実施して備え、うまくハマりました。
　　ギリギリでも規定文字数まで粘ったのが功を奏しました。
　　今思えば、1回でも論文の練習をしておけばもっと整理できたかな、と思います。

◆９．モチベーションを上げたり維持するために工夫したことは何ですか？
　勉強した内容から、実際の業務での利用シーンを想像する。
　合格一時金の使い道を妄想する。

◆１０．合格に最も大切なのはズバリなんでしょう。
　忙しくても毎日（30min〜）勉強する心意気。
　日曜日を潰して受験しているという気概。
　決して難しい試験ではない、という思い込み。

◆１１．あなた様について教えてください。
　職種や主な保有資格、可能であれば年代など
　人物：30歳代前半・男
　職種：システムエンジニア（ソフトウェア開発・管理、運用も多少経験）
　　　　今は品質管理が中心
　保有資格：基本情報技術者/応用情報技術者/情報セキュリティアドミニストレータ
　　　　　　SJC-P5.0/SJC-WC1.4
　　　　　　XMLマスター:ベーシックV2/XMLマスター:プロフェッショナル（アプリ開発）

◆１２．書籍などへの転載可否
　転載可能

◆１３．最後に一言お願いします。
　こちらのサイト、並びに管理人様の書籍には大変お世話になりました。
　特に「問題に対して素直になる」は目からウロコが落ちました。
　　→「そもそも論」を唱える人って多いですよね。。
　　　
　今後は運用系の業務が主体となるので、
　この勉強で得た知識を有効活用できるように整理していきたいと思います。

[481]　レオレオ　(2011/01/02 Sun 21:48)

平成22年度秋期試験、いかがでしたか

皆さん、試験おつかれさまでした。
手ごたえはいかがでしたか？

私は、今年初チャレンジのITサービスマネージャを
うけてきました。
午後�U、午後�Tは6割取れてると思うのですが、
論文で時間が足りず、設問ウの600字を超えることが
できませんでした。
内容的にはまとめに入ってましたが、あと2行ほどの
ところで試験終了時刻になってしまいました。

字数が足りないのは、採点されないのでしょうか。
せめて、減点扱いだと嬉しいのですが・・・。

[444]　うーちゃか　(2010/10/17 Sun 22:13)

---

Re: 平成22年度秋期試験、いかがでしたか

試験お疲れ様です！

管理者の私は、NWのサイト上での解答速報作成でへとへとです。
NWは難しい・・・

さて、ご質問の件ですが、採点はされます。
また、文字数不足でも合格した人は何人もいます。
大幅な減点かもしれませんが、あきらめる必要はありません。

[445]　管理者　(2010/10/17 Sun 23:16)

---

Re^2: 平成22年度秋期試験、いかがでしたか

管理人様

ご返信有難うございます。
（管理人様から返信を頂けるとは思ってなかったので
恐縮です）
また、ネットワークの回答速報作成、お疲れ様です。

採点対象になるんですね、よかった！
ただ、内容に自信があるわけでもないので大幅な減点は
恐怖ですが、でも不合格確定ではないので少し安心しました。

あと、事後報告になりますが、こちらのHP、及び
「 ITサービスマネージャ 「専門知識+午後問題」の重点対策」
には大変お世話になりました。
今回落ちたとしても、来年また受けようと思います。
（その前に、春はシステム監査を受けようと思います）
基本情報から数年たって、試験の勘をすっかり忘れてたのですが
管理人様のわかりやすいHPと著書のおかげで、なんとか
戦うことができました。

12月には、良いご報告ができるといいです。

本当に、有難うございました。

[446]　うーちゃか　(2010/10/17 Sun 23:56)

---

Re^3: 平成22年度秋期試験、いかがでしたか

２００９年度版ですが、午後の重点対策のお世話になりました。
午前IIはどうなるかと思いましたが、思ったよりも正解できて
いたのは、この本のおかげです。
午後IはITAC速報をみていると6割に届いたかなと思いますが、
合否発表の採点結果を観ないとなんとも言えないことが多いの
で、楽しみに12月を待つことにします。
午後IIは、昨年はPM論文を書いてしまったので、
サービスデスクの活動を忘れないように書きました。昨年
よりはSM寄りにかけた（８００＋１１００＋９００）と考えて
います。
できるだけのことをした、合っている合っていないは別として
昨年よりも書ききれました。ありがとうございました。

[447]　ちょし　(2010/10/18 Mon 07:29)

---

Re^4: 平成22年度秋期試験、いかがでしたか

こんにちは、

先ほど、IPAの解答より午前IIは、なんとか突破できたようです。

午後Iは、意外と微妙だったりします。
問２の可用性問題、と問４のセキュリティ問題を選択しました。
問４から開始したのですが、意外と苦戦してしまい、半分の４５
分を過ぎてしまい、問２は、問題文に前提条件が沢山ありました
が、時間が無く解答に際してすべて考慮できたかが不安です。

一応、解答欄はすべて埋めましたが…。

午後IIは、問２のリリース管理を選択しました。
時間内に記載する事は出来ましたが、不安です。

理由１：論文構成が１５分で組み立てられず、そのまま作成を
　　　　開始した。
　　　　その為、設問ウは、その場で考えて記載しました。

理由２：ポイントを外した？
　　　　リリース管理の問題点として、
　　　　　１．リプレース予定機器の新規OSのリリース遅延発覚
　　　　　２．検証範囲の不足
　　　　を挙げたのですが、その対策(設問ウ)として
　　　　　１．リスクマネジメントの徹底
　　　　　２．他チームを巻き込んだ影響分析
　　　　など、ちょっとサービスマネジメントのポイントから
　　　　外れていないか？と懸念しています。
　　　　リスクマネジメントなんか、どちらかというとPMの対策
　　　　じゃなかったか？！…と。

設問アは、準備+既存のリリースプロセスを８００字で。
設問イは、対象案件の説明と問題について１１００字程度で。
設問ウは、上記の通りで７００字程度で。

初の小論文は、やはり難しかったです。
あの短時間に構成の組み立てはやはり出来ませんでした...orz。

皆さんもお疲れ様でした。

全く話は変わりますが、受験した会場が、サービスマネージャの
区分の方だけだったので、ちょっと驚きました…。

[448]　Noah　(2010/10/18 Mon 12:35) mail

---

Re^5: 平成22年度秋期試験、いかがでしたか

ちょしさん、Noahさん

試験、おつかれさまでした。
会社でも昨日の試験の話題とか出ませんでしたか？

私は、午後�Tは、3と4を選択しました。
論文は、3を選択しました。
最初は1の構成管理にしようかと思ったのですが、構成管理をテーマに論文を書く練習をしなかったので、字数がどれだけになるか予想が立てられず、3のインシデント管理にしました。

まぁ選んだインシデント管理でも、結局は構成に20分近くかかってしまい、時間も足りない中で字を綺麗に書く余裕もなく、採点官には非常に見苦しい論文となっています。内容に自信があるわけでもなく、字数も足りない・・・。

でも、私もちょしさん同様、初めての論文試験にしてはやりきった感があり、次回もがんばろうと思っています。

> リスクマネジメント
論文を読んでいないのでなんともいえませんが、リリース管理でリスクマネジメントというのがちょっと違和感あるような気がします。リスクマネジメントというと、事業継続性管理とか経営の話のほうがfitしそうです。
おそらく、PPA（潜在的問題分析）のようなことをおっしゃってるのだと思いますが。
（偉そうですみません。字数も足りない私のほうがぼろぼろなのに）

> 全く話は変わりますが、受験した会場が、サービス
> マネージャの区分の方だけだったので、ちょっと
> 驚きました…。

私は、今回もそうでしたが、一つの区分だけの会場でしか受けたことが無いので（基本、セキュアド、NW）、複数扱う会場もあるのか〜と初めて知りました。

[449]　うーちゃか　(2010/10/18 Mon 21:27)

---

Re^6: 平成22年度秋期試験、いかがでしたか

>会社でも昨日の試験の話題とか出ませんでしたか？
>
　会社の人間には、受験のことは全く話していないので…。
　まぁ昼休みに午後一問題（もちろん重点対策）をやって
　いたので、気づいている人もいたと思いますが…。

> でも、私もちょしさん同様、初めての論文試験にしては
> やりきった感があり、次回もがんばろうと思っています。
>
　私も初めてでして(^^;;

　実は、このSM試験、当初は受験する予定がありませんでした。
　管理者さんのネットワーク楽々の方ででお世話になっており、
　昨年、合格し、今年の春は、情報セキュリティもなんとか合格
　できたので、次は、データベースかなと思っていたのですが、
　あるトピックでITサービスマネージャ試験の事を知り、運用系
　は長年やってきてので頑張ってみるか！と突然決めました。
　
　私の場合は、やりきった感というより、とりあえず書いた！
　感といった感じです　(＾＾;;;　

>> リスクマネジメント
>論文を読んでいないのでなんともいえませんが、リリース管理で
>リスクマネジメントというのがちょっと違和感あるような気がし
>ます。リスクマネジメントというと、事業継続性管理とか経営の
>話のほうがfitしそうです。
>おそらく、PPA（潜在的問題分析）のようなことをおっしゃってる
>のだと思いますが。
>（偉そうですみません。字数も足りない私のほうがぼろぼろなの
> に）
>
　いえいえ、とんでもございません。
　コメントありがとうございます。

　どちらかというと今回のリプレース作業を各フェーズ
　(計画、設計、検証、実装)と進めてきたんですが、その際の
　問題点をリスクマネジメントと置いたので、そちらの記述が
　前面に出たなと、今になって感じてます。
　
　当日は、構成が考えられず、「適用予定のOSが遅れる問題が
　あったな、よし！これを記述しよう」と場当たり的になった
　のは確かです。

　まぁくよくよ考えても仕方ないので、とりあえず結果を待ち
　ます（笑）

>私は、今回もそうでしたが、一つの区分だけの会場でしか受けた
>ことが無いので（基本、セキュアド、NW）、複数扱う会場もある
>のか〜と初めて知りました。
>
　ほぉーなるほど。
　私は、ネットワーク(何度も（汗）)、情報セキュリティを
　これまで受講しましたが、他の試験区分もあったような…。

　確かに会場が大学やコンベンションセンターみたいなところ
　が多かったので、地方によっても違うのかもしれませんね。

[450]　Noah　(2010/10/19 Tue 01:08) mail

---

Re^7: 平成22年度秋期試験、いかがでしたか

アイテックで、午後�T解答と試験講評がでましたね。

自分は、午後�Tはなんとか6割いったようです。

[452]　うーちゃか　(2010/10/19 Tue 20:26)

---

Re^8: 平成22年度秋期試験、いかがでしたか

お疲れ様でした、私の会場はトイレが少なく往生しました。
何たる奇縁か、運用関係の作業をしていた拠点のそばでした。
午前�Uからの参戦でした。
午後�Tについて、恥をさらしますね。
はっきりいって、国語の試験と、言いたくなりました！
問２は特に酷い！

問１
設問１
ＲＰＯの観点
なし

ＲＴＯの観点
移動時間が短縮・・・

設問２
（１）
障害発生日の午前３時　⇒あほ！

（２）
ａ：２
ｂ：１
（３）
日，月，火

設問３
（１）
テストデータの削除の必要性がないため

（２）
操作ログを使ってＤＢ内容のロールフォワード

（３）
本番サイトで行った設定変更等を同期を取って、
バックアップサイトに反映する。

問２：
設問１
増強方式２

将来的に増強できなくなる可能性がないため　⇒あほ！

設問２
ＬＡＮから切り離す　⇒あほ！

設問３
（１）
ＷＥＢサーバ１か２のどちらかに反映して、
障害など起きないことを確認してから、他に反映する。

（２）
ＤＢサーバのフルバックアップ取得する時間が確保できない

設問４
（１）
予約方式１のＤＢサーバの負荷が高いため

（２）
各予約処理の取り扱い比率

[453]　ＤＵＫＥ　(2010/10/20 Wed 00:33)

---

Re^9: 平成22年度秋期試験、いかがでしたか

ハルと言います。
受験された皆様お疲れ様でした。

管理人様にはこの掲示板や重点対策本でお世話になりました。
本は、9月頭に注文した物が試験の1週間前に届きましたｗ

重点対策は凄い人気ですね。
試験会場ではあまりに同じ本が並んでいて
それが少しおかしくておかげでリラックスが出来ました。

さて試験ですが、私は午前�Uからの受験でした。
午後�Tは問２と問４、午後�Uは問３を選択しました。

午前�U、午後�TはITECの解答例を見る限り問題無さそうでした。
しかし午後�Uの問３について少々気になっています。

ITECの本試験講評速報を見ると
インシデント管理がテーマのような内容に思えました。

しかし私は、
設問アはインシデント管理で、
設問イはインシデントの対策だから問題管理として解答しました。
設問ウはイの結果についての不備なので問題管理の範疇と考えました。

メインの設問イとそれに続いて設問ウが問題管理であるので、
インシデント管理というよりは問題管理の問と考えています。

具体性が足りなく字も汚いので
せめてテーマを抑えたいと考えていたので気になっております。

管理人様、皆様、よろしければお考えをお聞かせください。

[454]　hallu　(2010/10/20 Wed 01:37)

---

Re^10: 平成22年度秋期試験、いかがでしたか

ＤＵＫＥさん、halluさん

試験おつかれさまでした。

ＤＵＫＥさんは午後�Tは問１、問２を選択されたんですね。
私も最初は問１を選択しようと思ったのですが、設問１の「効果がない場合は、なし、と記述せよ」というのが妙に気になるというか、１問目から不安にさせられてしまい、他の解答をずばっと書けそうな問題に移行しました。

halluさん、私も午後�Uは問３を選択しました。
僭越ながら私の考えを述べてみます。

私もアイテックと同様、インシデント管理がテーマだと考えます。
受験時に思ったことですが、日本語の曖昧さ（"問題"という単語）を意図的に利用しているのか、と勘ぐりました。

問題文４行目「インシデント発生時に想定される問題への対策を事前に検討しておく」とありますが、ここでの「問題」とは、ITILでいう「インシデント管理プロセスで解決できなかった、問題管理へエスカレーションしたインシデントの根本原因」というよりは、「インシデント対応時のサービス提供者側の不手際」を指していると捉えました。
つまり、「予防措置について（問題管理）」ではなく、「インシデント対応プロセスの整備」を問われていたと考えます。

問題文でいうと、「主要な業務システムが稼動するサーバに障害が発生した場合を考える（６行目）」ですが、これについて問題管理だったら、「障害そのものが起きないように手を打つ（CPU使用率閾値超えのインシデントが目立つ→状況調査→CPUを占有するプログラムがあった）」という対応になると思いますが、問題文では「回復の手順に不慣れでITサービスの回復が遅れること」が"想定される問題"とあります。
つまり、対応策（回復の手順）自体は判明しているのに、もたもたしてうまく行動できなかった、ということですよね。
よって、「発生したインシデントに如何にスムーズに対応できるか、常に検討しなさい」というのが問３の題意だったと思います。

ちなみに、上記で書いた問題管理の例は、昨年の午後�U問３の問題文を参考にしました。
そう、昨年既に「事前予防的な問題管理」は出ているのです。

あとで時間があったら、私の論文構成を書きたいと思いますが、今は時間が無いのでこの辺失礼します。

[455]　うーちゃか　(2010/10/20 Wed 05:21)

---

Re^11: 平成22年度秋期試験、いかがでしたか

問２の最終設問ですが、ＩＴＡＣ、ＩＴＥＣ、ＴＡＣの三者とも、
レスポンスタイムですが、そういうものなんですか？

比率を増やしたいのに、なぜそうなのか？疑問に感じました。

[456]　ＤＵＫＥ　(2010/10/20 Wed 23:54)

---

Re^12: 平成22年度秋期試験、いかがでしたか

うーちゃかさん

レスありがとうございます。

なるほど、仰る通りのような気がします。

「インシデント発生時に想定される問題」
という文と、
「ITサービスマネージャは，インシデントを発生させないための
　予防的な対策とともに，インシデント発生時に想定される
　問題への対策を事前に検討しておくことが重要である。」
という文を読み、インシデントとは書いてあるけど問題管理だな、
と得意気に思ってしまい考えがそのことに占有されてしまいました。

しかし落ち着いて考えてみたら、
予防的な対策は当然としてインシデント管理時の問題を答えなさい
と考えることが出来ます。

試験中は頭がそのことに回りませんでした…

素直さが足りませんね。

実際の論文は問題文中のキーワードを拾う事に精一杯で、
インシデント管理だからとか問題管理だからという視点が薄いので
その結果が良いように転ぶことを祈ります…

> そう、昨年既に「事前予防的な問題管理」は出ているのです。
昨年の問題のことまで考えられていたとは。
しっかり論文を研究されていたのですね、尊敬します。
うーちゃかさんなら多少文字数が足りなくても合格されそうです！

[457]　hallu　(2010/10/21 Thu 00:41)

---

Re^13: 平成22年度秋期試験、いかがでしたか

ＤＵＫＥさん

問２の最終設問について
営業部の目的は「予約方式１の取得比率拡大」で、その目的のために特別割引キャンペーンを実施し、その結果、予約件数(サーバ処理）が増加するであろうことを見込んでいます。
おそらく、広告バナーでユーザを誘導できても、予約の増加による利便性が悪さでユーザが離れていくことを営業部は心配しているのではないでしょうか（一般ユーザ相手のWebシステムは、レスポンスが生命線といってもいいでしょう）。
なので、システム運用部では、営業部が要請してきたX秒以内のレスポンスタイムでサービスを提供できるようなシステムの構成、運用方式の見直しを行う必要があったのでしょう。

問題文の最後から2行目「利用者が"快適に"予約をおこなえるように」がヒントだと思います。

DUKEさんの、「各予約処理の取り扱い比率」は、システム部門が出すものでは無いかな、という気がします。
方式2と3は外部サービスを利用しているので、方式1も含めたそれぞれの件数をみて比率を出すのはサービスを管轄している営業部が行うのが妥当かと思います。

DUKEさんの意図と違う解答になってたらすみません。

halluさん

なんだかえらそうにすみません。
過去問の分析についてですが、どうしても論文の練習（実際に書く）という行為が苦手、というか面倒くさく、過去問の分析ばかりをしていました。
で、やっぱり本番で書き切れなかったという・・・。

キーワードが拾えていれば、大きく題意を外してはいないのではないでしょうか。
お互い12月には笑えているといいですね。

[458]　うーちゃか　(2010/10/21 Thu 05:54)

---

Re^14: 平成22年度秋期試験、いかがでしたか

なるほど、そっちを見るのですか？納得です！

問１の設問３（１）についても、間違いですね。
業者さんは、本番環境に近い・・・ですけど、これも
違うと思う。
あいまいで、具体性がないと思いますけどね。
要は、「ロールフォワードするプログラムの走行確認が
できないから」でしょうね。ＴＡＣの配点だと、
６０点を超えるかどうかで、微妙な状況です。

[459]　ＤＵＫＥ　(2010/10/22 Fri 00:34)

---

Re^15: 平成22年度秋期試験、いかがでしたか

運用周りについては、でっち上げ論文書きました。
正直、全然うまくいかないですね。
本当は、モグラたたきに、終始したイメージが強いです。
初期は、ＡＰの初期不良で、呼び出されたりで、往生して、
モグラが落ち着くと、経費削減で人員が減ります。
自動化など、夢の夢で、少ない人員での作業となります。
そして、契約の折り合いが付かなくなって、協力会社が撤退し
ます。安いカネで妥協する協力会社が来ますが、指導しても、
なかなか、品質が上がらずで、モグラを自分で作る始末です。
それでも、なんとか、落ち着いてくるんですけどね。
結局、人員削減との戦いで、自動化は一向に進まず、
最後は、経費が高い自分が、責任とらされて、ポイされます。

運用周りは、開発と違って、ミスは大事故ですから、
たいへんです。野球で言えば審判で、きちんとやって当然！
ミスれば、ボロクソです。
その点、開発は、バグ出ても、それほどうるさくはない。
テストでたたき出せば、それほどでもないし、人間ミスは
あるってんで、多量に作り込まない限りは、よい。
野球でいえば、選手で、エラーしても、ＨＲ打ったりで、
結局勝てばよい！
自動化でもしない限りは、いい評価も、もらえないし、
カネもずっと、現状維持で、つまらなかったなぁ。
この辺の評価制度を、考えないと、運用周りに、
いい人員が、根付かないと、感じています。

[460]　ＤＵＫＥ　(2010/10/25 Mon 22:36)

---

Re^16: 平成22年度秋期試験、いかがでしたか

私はネットワークの運用（たまに構築）を行う部署に配属となり、今は品質（ITSMSとかISMSとか）の管理者をやっている入社8年目のSEです。

DUKEさんのおっしゃりたいことは、よくわかります。
自分も運用を経験してきた上で、いろいろ言いたいことはあるのですが、ここの掲示板の意義、内容から発言するならば「運用を経験して良かった」と思っています。

「つまらなかったなぁ」と過去形になっているのは、DUKEさんはもう運用を離れたのでしょうか。
運用の経験が今のお仕事に生きていませんか？
最適なコストバランスや、運用（サービスイン後）を考えたシステム設計などは、私の周りでは運用を経験した人のほうが優れている場合が多いです。
また、そういう人は、顧客との折衝術、組織の在り方、自分及び部下のモチベーションなど、マネジメント面でも優秀である印象があります。
なんというか、全体を俯瞰して物事を考えられる人が多いです。
（で、こういう人がIPAが言う「ITサービスマネージャ」なのだろうと個人的には思っています。自分はまだまだですが）

昨今、景気も良くなく、また、クラウドのようなサービスが出てきて、今後は自社でシステムを構築するケースは少なくなってくるでしょう。
今後は、運用を考えられる人・管理できる人（≠運用の作業員）は重宝されると思っています。

[462]　うーちゃか　(2010/10/27 Wed 16:39)

---

Re^17: 平成22年度秋期試験、いかがでしたか

南都銀行でトラブルがあって、二重課金があったそうです。
原因は、うっかりミスで、テストデータを消し忘れたとかで、
自分の誤答が予言だったのか？とおかしな気分でした。
もちろん冗談で、私にとっては、他山の石です。
うっかりミスとは、表面的な原因で根本原因があると
思われますね。それを追求するのが、ＳＭ技術者でしょうね。
結局、属人性とかに至るような気がします。
根本原因に対処しないと、もぐらたたきですからね。

[466]　ＤＵＫＥ　(2010/11/01 Mon 22:41)

---

Re^18: 平成22年度秋期試験、いかがでしたか

本日、胴元の模範解答の発表がありましたね。
私は、午後�Tで、完全にあきらめました。
ＴＡＣ配点で５５点も行けません。
読解力が落ちていると感じます。ＬＢの設定とか、ＲＴＯの
目標とか、読めば書ける問題です。
また、突っ込むところと、素直に書くところを、
分けないといけませんね。
深読みが、ある意味、敗因でした。

[468]　DUKE　(2010/12/11 Sat 01:36)

運用という仕事

表題のテーマにて少し議論がありましたので、私の見解を書かせていただきます。

仕事の良し悪しは人によって価値観が違います。
「ビルゲイツと商店街のおじさんとどっちが幸せか」という一文を見たことがありますが、これに似ていると思います。
なので、答えはありません。
私は、自分がやっている仕事を好きになろうと考えています。

私はネットワークエンジニアが大半ですが、4年ほど運用業務も兼務でやっておりました。運用という業務は、世間的にはあまり華やかではないでしょうし、正直なところSEとしての単金も高くないのが事実だと思います。でも、楽しかったです。
それは、自分が主体的に仕事をしていたからだと思います。
たとえば、サービスデスク（当時はヘルプデスク）で問合せを受け付けるのですが、色々な人から電話があります。色々な人と話せるのはとても新鮮で、社内からの問合せの場合は、色々な人と仲良くなれました。
また、変更管理がしっかり確立されていなかったこともあり、利用者さんの要望をすぐに反映するという柔軟な対応（ITIL的には問題でしょうが）を行い、結構喜んでもらえました。
大きな部署では変更管理がしっかりしているので、FAQの改善や問合せに対する回答方法もある程度制約があるでしょうが、当時の私の部署はかなり自由にできました。
サービスデスクに電話してくる場合は、基本的に利用者の人が困って電話をしてきます。そんな皆さんのお役に立てるというとてもやりがいのある仕事でした。
また、サービスデスク以外に、ルーチンも非常に多いのが運用の仕事の特徴です。私は、日々ルーチンの改善を図り、チェックツールを作ったり、問い合わせへの返信を簡略化する仕組みをプログラム化したり、ルーチンをより効率化することを考えていました。
当然、同じ運用のメンバーにも共有すると「お、これ便利だね。使わせてもらうよ。」と、最初は一人で使っていたツールを段々とみんなが使うようになりました。これもとても楽しかったです。

今は運用から離れ、ネットワークの仕事をメインでやっていますが、ネットワークの仕事を楽しんでいます。「ネットワークは人と人とをつなぎ、人々の幸せをお手伝いする仕事」と思って仕事をしています。

[463]　管理者　(2010/10/28 Thu 21:20)

---

Re: 運用という仕事

本当は、管理人さんのおっしゃるようになりたかったものです。

ちなみに、論文ネタは、ＩＴＥＣの論文対策初版本を
利用しました。
正確には「システム管理」時代の本です。
Ｎ社のＫさんのネタを参考にしました。実際、
よく似ているシステムでしたからね。
管理人さんは、何社の何というシステムか？
もう、わかっていらっしゃると思います。

[464]　ＤＵＫＥ　(2010/10/31 Sun 23:12)

---

Re^2: 運用という仕事

上の仕事、もぐらたたきとは無関係です。
一応成果を上げたので、論文ネタにしました。

今までの他の仕事の経験でいえば、人為的なミスが許されない
のが、一番辛かったですし、単価が安かったのも、
辛かったです。

「決してミスをしていない人物は、何もしなかった人物だ。」
の格言が、ある意味、胸に響くものでした。
結局、誰も手が出せなくなるんですよね。

最近、政府は、運用費用を下げるなどという方針を
出したようですが、これにより、品質を下げないことが、
大前提ですね。
運用をきちんと考えた製品（標準化、自動化）を作って
いかないと、駄目でしょうね。

[465]　ＤＵＫＥ　(2010/11/01 Mon 01:49)

---

Re^3: 運用という仕事

こんばんは。

私は、入社以来一貫してネットワーク業務を行ってます。
現在は、マネジメントとしての立場ですが、これまで
社内ネットワーク、CTI関連ネットワーク、データセンター
ネットワークと設計、構築、運用と色々経験させてもらい
ました。

特にデータセンター業務では、B2Cシステムを収容する共用
ネットワークを運用していましたが、これまでのルータ、
スイッチに加え、ファイアウォール、負荷分散装置、DNS,
NTP,Mailなどなど色々な技術要素を覚えるので必死でした。

もう10年前の話なので、まだまだ標準化などとはほど遠い
手探り状態での運用でした。
その当時は、おそらくインフラの中でもトップクラスで忙し
かったと思います。

運用業務なのにいつも午前様で、メンテ作業がある際は、
朝から出社して次の日の夜帰宅、翌朝朝から出社など今考える
とホント酷い状況だったと思います（苦笑）

と長くなりましたが、管理人さんがおっしゃる通り、運用って
目立たないですよね。特にインフラ系の運用は、出来て当たり前
であり、トラブルとしかられるという何ともモチベーションが
上がる要素が少ない業務だと思います。

そんな中、自分がモチベーションを維持できたのは、自分が
システムを支えているんだという自負があったからだと思います。

VPNが登場してからは、キャリアさんがレイヤを上げ、専用線など
から、サービスの提供を行ってます。
また最近では、クラウドサービスなどインフラ自身がコモディティ
化され、現場を経験する環境なども少なくなってきました。

更に自動化が進みますます人手を介す機会が少なくなるでしょう。
また残った業務もオフショアなど人件費が安い国へとアウトソース
も進み、日本人が運用する機会ってホント減るんだろうなと思う
今日この頃です。

最後ですが、私も後進にネットワーク業務を通じ、ヒューマン
ネットワークを構築しろと言ってきており、管理人さんの意見
に非常に共感が持てました。

長文となり、失礼しました…。

[467]　Noah　(2010/11/02 Tue 02:24) mail

ＩＴサービスマネージャ受験してきました

どうもです。ショウです。

１７日の日曜日に情報処理技術者試験を受験しました。
区分は当然ですが、「ＩＴサービスマネージャ」です。（^^;

とりあえず、午前２で落とされていないか心配でしたので、
ＩＰＡのホームページの解答を確認し、
自己採点してみました。

１８／２５　で、午前は無難にクリアです。

午後１は去年２点差で不合格という苦い経験があるのですが、
今年は、思っているよりは、悪い手応えではなかったです。
ちなみに選択したのは、「問１」「問２」です。

で、問題は午後２です。。。。。

なお、今年は、ちょっと色々とあったものですから、
去年の試験以来、まったく論文を書かずに試験に臨むという、
とても無謀な挑戦となりました。（笑汗

とりあえずは、最初の４００文字だけは、
過去に書いた論文を引っ張り出してきて、
前日に丸暗記しておきました。

でも、実際には、なかなか書けないもんで・・・

設問ア：８００文字
設問イ：８００〜１６００文字
設問ウ：６００〜１２００文字

の文字数制限には、達することには達しましたが、
内容が何ともです。。。。

ちなみに、私が選択した問題は
「問３　インシデント発生時に想定される問題への対策について」
です。
問１は、ちょっとパス。
問２は、うーん、書けるかも。。。。
でも、受け入れ時の問題の対処か。。。。思いつかん。。。。
問３は、インシデントに対する対策かぁ。。。
留意点ってのは、めちゃくちゃ気になるが、
これしか選択のしようがないか。。。。

ということで「問３」です。　（笑汗

まあ、とりあえずは復元してみようと思って、
復元論文は書いてみました。
復元論文をあらためて読んでみて・・・
「うーん、題意を外してそうな気がする。。。。」

という感じです。
まあ、やるだけはやったので１２月の結果を
楽しみに待つことにします。

[451]　ショウ　(2010/10/19 Tue 03:52) mail

---

Re: ＩＴサービスマネージャ受験してきました

ショウさん

試験お疲れ様でした。
論文を2時間書くのは疲れますよね。

論文の復元をされたら、是非みせてください。

では、12月の吉報を心よりお祈り申しあげます。

[461]　管理者　(2010/10/27 Wed 06:27)

Ｈ２１問１

取り急ぎ、書いてみました。

Ｈ２１問１　変更管理プロセスの確実な実施について

　新製品の販売や制度変更への対応、提供機能の改善な
ど、システムに対する様々な変更要求が発生する。一方
、システムに対する変更にはリスクが存在し、事業に重
要な影響を及ぼすこともある。このため、ＩＴサービス
マネージャは、変更要求の受付からその終了に至るまで
の、変更管理するための一連の手続（以下、変更管理プ
ロセスという）を定め、確実に実施することが重要であ
る。
　変更管理プロセスに問題があると、例えば、次のよう
な事情が発生する。
・変更要求の処理に時間がかかる。
・変更の失敗が度重なる。
　このような場合には、その原因となる変更管理プロセ
スの問題を特定し、その改善策を立案・実施することに
よって、再発を防止しなければならない。
　また、変更管理プロセスが確実に実施されていること
を、定期的に確認する必要がある。このための方策とし
ては、例えば、次のようなことが考えられる。
・重要業績評価指標（ＫＰＩ）などを用いて、実施状況
をレビューする。
・内部監査などによって、遵守状況をチェックする。
あなたの経験と考えに基づいて、設問ア〜ウに従って論
述せよ。

設問ア　あなたが携わったＩＴサービスの概要と、変更
管理プロセスについて、800字以内で述べよ。

設問イ　設問アで述べた変更管理プロセスで、どのよう
な事象が発生したか。その原因となる変更管理プロセス
の問題は何であったか。また、再発を防止するためには
どのような改善策を立案・実施したか。800字以上1600
字以内で具体的に述べよ。

設問ウ　変更管理プロセスが確実に実施されていること
を、定期的に確認するために行っている方策について、
今後の課題とともに、600字以上1200字以内で具体的に
述べよ。

＋−−−＋−−−−＋−−−−＋−−−−＋−−−−＋
１．ＩＴサービスの概要と変更管理プロセス
１．１ＩＴサービスの概要
　地方銀行Ａは、中・四国を中心に約１４０店舗の本支
店をもつ中堅の地方銀行である。銀行の基幹システムは
ホストシステムで稼動しており、入金、出金などを処理
する勘定系システムと、顧客情報などを処理する情報系
システムが稼動している。また、日中はオンラインシス
テムが稼動しており、夜間はバッチシステムが稼動して
いる。私はソフトウエア会社Ｂ社に所属しており、Ａ銀
行のシステム運用を受託している。
１．２変更管理プロセス
　今般、新製品の販売や制度の変更などがあった場合、
ホストシステムのプログラムの変更や追加はもちろんの
こと、パソコンサーバを利用したサブシステムを構築し
ホストシステムと接続することによって、サービスを提
供している。また、ホストシステム、サブシステムにつ
いて、各業務ごとに担当者を割り当て、運用を実施して
いる。各担当者からは提供された機能について改善など
、システムに対する様々な変更要求が発生している。
　また、システムに対する変更にはリスクが存在し、事
業に重要な影響を及ぼすこともある。このため、変更要
求の受付からその終了に至るまでの、変更管理プロセス
を以下のように定め、確実に実施している。
A.『業務改善要望』を担当者が記入し、受託部門長がそ
の内容を承認し、開発担当であるシステム部に提出する。
B.システム部では受け付けた『業務改善要望』を担当者
に割り当て、実施可・不可、対応時期、工数、金額を回
答する。その結果をシステム部の企画部門で検討し、対
応の可否を決定する。
C.その決定した内容を受託部門長に回答する。

２．変更管理プロセスの問題と再発防止改善策の立案・
実施
２．１発生した事象
　以前より、この変更管理プロセスには問題があり、次
のような問題が発生している。
�@変更要求の処理に時間がかかる。
�A変更の失敗が度重なる。
２．２変更管理プロセスの原因
　上記のような事象が発生するには次のような原因があ
った。
�@変更要求の処理に時間がかかる。
については、受託部門からの申し入れについては、要望
を出してから、システム部の担当者に渡り、対応時期、
工数、金額の記入は１日から２日で対応している。しか
し、実際の対応については、新製品の販売や制度変更へ
の対応が最優先課題であるため、現状で稼動しているシ
ステムへの改善要望については、優先順位は低く、対応
できない状態である。
　また、変更要望が発生するシステムについては、もと
もと担当者の開発能力が低く、新規案件についての対応
も遅れ気味であり、質も悪いため、開発も遅れ、改善の
できない、悪の循環となっている。
　また、年間の開発に関する予算が新製品の販売や制度
変更には対応しているが、変更要望については明確に確
保していないため、予算が余ったらの対応しかないため
企画部門で不採用となっている。
�A変更の失敗が度重なる。
については、『業務改善要望』の内容について受託業務
部門との打ち合わせを実施せずに対応内容を決定してい
るめ、改善要望を１００％満足するのものができず、変
更の失敗が度重なっている。
２．３再発防止改善策の立案・実施
　私は上記の原因となる変更管理プロセスの問題を特定
しその改善策を立案・実施することにし、再発を防止す
ることにした。このことはシステム部との協議で決定し
た。
　まず、�@について、改善要望について、そのスケジュ
ールを以下のように決定することにした。改善要望は半
期に１回、３月と９月を締め切りとし要望をあげること
にした。その対応については翌期に対応する。
また、その工数は最大で２人月、期間は１カ月として、
それを超えるものについては、別途、協議・対応するこ
とにした。
　�Aについては、必ず改善要望を提出した担当者と打ち
合わせを実施し、その結果はシステム部の企画部門に文
書で提出し、上司の確認、システム部長の承認をいただ
くことにした。失敗した場合は、システム部の責任で対
応していただくことにした。
３．定期的確認の方策と今後の課題
３．１定期確認の方策
　また、変更プロセスが確実に実施されていることを、
定期的に確認するために、次の定期確認の方策を実施し
た。半期に１回の部内監査のときに、業務改善要望が必
ず実施されているか、チェック項目に追加していただき、
その結果を監査部に報告することにした。
３．２今後の課題
　以上のような変更管理プロセスにおける、改善策の立
案・実施、定期的な確認の方策を実施することによって
変更管理プロセスの確実な実施を遂行してきた。
　今後については、変更対応はできるものの、長期にわ
たり変更を多数加えたシステムについては、５年から７
年の単位で全体のシステム見直しをする必要があると考
える。なぜならば、ハードウェア、ソフトウエアの進歩
に伴い、当たり前の品質が変化するこの時代に、古いシ
ステムでは対応できない機能が必ず発生しているからだ。
その対応プロセスについて対策の立案・実施が今後の課
題である。
　　　　　　　　　　　　　　　　　　　　　　-以上-

[439]　ＺＥＴＡＩＧＯＫＡＫＵ　(2010/10/13 Wed 23:15)

---

Re: Ｈ２１問１

ＺＥＴＡＩＧＯＫＡＫＵさん、すぎエモンです。
僭越ながら査読させて頂きました。

【良いと感じた点】
・「B.システム部では受け付けた『業務改善要望』を担当者
　に割り当て、実施可・不可、対応時期、工数、金額を回
　答する。その結果をシステム部の企画部門で検討し、対
　応の可否を決定する。」という部分の記述は素晴らしい
　ですね。そこまでしっかりと対応するのかと感心しました。
　題意にも沿った書き方だと思います。
・設問アの文字数が絶妙ですね。800字に近づけるのは難しい
　のですが、見事だと思います。
・問題点を「�@変更要求の処理に時間がかかる。

　�A変更の失敗が度重なる。」と問題文に完全に準拠した点
　は素晴らしいと思います。受験時に問題文を取り入れて
　文章を作成するというアドリブ能力が評価できます。
・「変更要望については明確に確保していないため、
　予算が余ったらの対応しかない」という表現は面白いですね
　組織としては良くないのでしょうが、「あるある」と内心
　ニヤニヤしてしまいました。経験者にしか書きえない発想ですね。
・常に自分を運用部門の立ち位置に据え、自分たちで何でも対応する
　のではなく、他の部門との関わりをしっかり記述する点は素晴らしい
　と思います。ＩＴサービスマネージャとしてあるべき視点ですね。
・「５年から７年の単位で全体のシステム見直しをする必要がある」
　という点は「最後に自分の考えをしっかりと論じた」という
　印象を受けました。「３．２今後の課題」の部分は全般的に
　大変良い内容だと思います。

【気になった点】
・設問ウは私が数えた限りでは500文字になっているようです。
　設問ウ600字以上1200字以内なので、もう少し分量を増やした方が
　いいと思います。
・「１．１ＩＴサービスの概要」はどちからというと
　システムの概要についての記述ではないでしょうか。
　どんな運用を行っているかという”サービス概要”
　が１．２の方に書かれてしまっているので
　１．１に移動するなどした方がいいかも知れません。
・「パソコンサーバを利用したサブシステム」は
　パソコンとサーバを利用したサブシステムなのか
　パソコンをサーバにしたしたサブシステムなのか
　ちょっと曖昧に感じましたね。もう少しわかりやすい
　表現の方がよいのではないでしょうか？
・「半期に１回の部内監査」という部分ですが、問題文に
　可能な限り忠実に準拠するという意味で「半期に１回の内部監査」
　という書き方の方が合格率が高まるかもしれません。
・「変更要望が発生するシステムについては、もともと担当者の
　開発能力が低く、新規案件についての対応も遅れ気味であり、
　質も悪いため、開発も遅れ、改善のできない、悪の循環となっている。」
　という部分に違和感を覚えました。開発部門の質が悪いのか？
　特定の担当者の質が悪いのか？という疑問ですね。
　どちらにしてもいきなり問題点を突き付けられた印象で
　「どういうことだろう？」という印象になりました。
　問題点となる部分は事前に布石をうっておき、査読者に理解しやすい
　ようにする、もう少し深く掘り下げて書くなどの工夫があると
　より理解しやすくなるのではないでしょうか。
・「失敗した場合は、システム部の責任で対応していただく」という点は
　評価が分かれると思います。運用部門と開発部門の間に溝がある点を
　短い文章で見事に書き出しており、非常に現実的で現場的です。
　この様な現場は実際にたくさんあります。
　しかし、査読者によっては理想論を求め、「運用部門と開発部門の融和
　を図るような対策を取らなかったのかな？」という印象を持つかも
　しれませんね。私ならリアリティある表現なのでプラス評価しますが。

[441]　すぎエモン　(2010/10/14 Thu 07:22) mail

---

Re^2: Ｈ２１問１

すぎエモンさん、
早速の返信ありがとうございます。
午後１で落とされないように
がんばります。

[442]　ＺＥＴＡＩＧＯＫＡＫＵ　(2010/10/15 Fri 00:32)

---

Re^3: Ｈ２１問１

初めまして。コメントさせて頂きます。

全体的に問題文に沿って記述してある点は良いと思います。
ただ違和感を感じるというか、気になる点があるので、その点について述べます。

1.2 の変更管理プロセスの説明ですが、変更内容の承認までのプロセスしか書いておらず、片手落ちな感があります。採点官に変更管理プロセス自体の知識を疑われるのも損なので、設問イ以降の論述に関係ないとしても、変更作業や作業後の確認プロセスまで言及した方が良いと思います。

2.1 発生した事象ですが、問題文そのままの事象では抽象的過ぎると感じました。変更要求のどのプロセスでどれくらい時間が掛かったのか、どのような失敗がたび重なったのか、その具体例を求められていると考えます。
具体例と思しき記述が次の2.2に混ざってしまっていますので、上手く分離して書ければより良い論文になると思います。

2.2 この部分が最も違和感のある部分です。具体的には記述してある内容が、変更管理プロセスの問題ではないのでは、という点です。
まず�@について。
優先順位が低いので対応できない、は順位が低いのだから順当ではないでしょうか。「優先順位を決定するのが遅い」でしたら変更管理プロセスの問題になりえますが、決定した優先順位の高低について問題視するのは変更管理プロセスの範疇ではありません。
開発品質が低いのも変更管理プロセスとはほぼ無関係です。
予算の関係で不採用になるのも経営判断として間違いとは言えません。
総合すると「サービスデリバリ」の範疇の問題ではないかな、という印象です。

次に�Aについて。
対応内容の決定はどちらかと言えば「問題管理」の範疇と考えます。問題点に対する「解決策」の提示が問題管理の仕事で、その解決策に伴う変更を確実に実施するのが変更管理の仕事ですので、解決策自体が適切でない、というのは変更管理の問題として不適切と判断される可能性があります。

採点官の方がどの程度のレベルで採点されるのか分かりませんので、題意を外しているとしてC〜B判定になる可能性も、問題とされずA判定になる可能性もあるとは思いますが、リスクであるのは間違いないと思います。
本番は一発勝負なので余裕はないと思いますが、なるべく各管理プロセスの典型的な問題で論述した方が安全だと思います。

[443]　hok　(2010/10/15 Fri 12:57)

21年 午後�U　問1

初めまして。
今回、初めてSMの試験を受けるにあたり
午後�Uの論文を書いてみました。

あまり自信がないので、
ぜひ皆様からのご意見を頂きたく
投稿させて頂きました。

至らない点も多々あるかと思いますが、
どんな意見でもいただけましたら幸いです。

どうぞよろしくお願いします。

====================================================
■変更管理プロセスの確実な実施について

1.私が携わったITサービスと変更管理プロセス
1-1 私が携わったITサービスの概要
Aセンターはがんの研究機関であり、全国約100の系列機
関を有している。私はソフトウェア会社であるW社に所
属しており、Aセンターのシステム運用を受託している
ITサービスマネージャである。
Aセンターではがん診断の支援システムを使用している。
これはAセンターや各系列機関で診断が困難な症例を、
Webシステムによって他の系列機関の医師や研究者に調
査依頼するというものである。
利用しているするサーバは2台、システムの利用者はAセ
ンターおよび各系列機関に所属する約500名の医師・研
究者である。
私が担当しているITサービスは、がん診断の支援システ
ムにおいて、利用者からの変更要求対応、故障対応、利
用者への操作説明などが主作業となっている。

1-2 使用されている変更管理プロセス
当システムの変更管理は、以下のプロセスによって実施
されている。
�@変更要求の受付・フィルタリング
�A変更要求の評価・分析
�B変更実装の承認
�C変更実施方法・スケジュールの管理
�D変更実施後のレビュー
各プロセスの管理は、変更管理データベース上の変更表
を使用しており、変更表を編集してステータスを進める
ことでプロセスが進み、各担当者へ作業依頼メールが送
信される。
各プロセスともに開発や運用を受託している技術者が作
業を担当するが、�Bの承認プロセスにおいてはAセンター
のシステム責任者であるX医師が担当している。

2.変更プロセスによる問題発生と改善策
○2-1 変更管理プロセスで発生した事象と原因
当システムの変更管理プロセスにおいて、変更要求の受
付〜分析までが完了しているにも関わらず、承認が得ら
れないため作業が滞ってしまうという事象が頻発した。
大半の変更要求は画面内の説明文の言い回しなど、緊急
度の低い変更であったため、変更遅れによるシステムへ
の影響度は小さく、承認遅れによる対応はされていなか
った。しかし、ある日運用中のシステムに致命的なバグ
が発見された。ただちに変更要求が行われ、受付・分析
は完了したが、承認が行われなかったため、変更実装が
行えない状況になってしまった。そのため、運用中のシ
ステムは約15時間停止せざるを得ず、SLAで締結されてい
る「障害からの復旧は12時間以内」という項目を遵守す
ることができなかった。
承認の遅れは、承認を担当しているX医師が変更要求を
随時確認できる状態になかったことに起因していた。
X医師は本業である医療業務が多忙であったため、担当
システム関連のメールに目を通してないことが日常的に
みられた。離席や外出していることもしばしばであるた
め、口頭や電話でも確実に連絡を取ることができていな
かった。

○2-2 再発防止のための改善策立案と実施
前述のように、変更管理プロセスによってシステムの運
用に影響を与える場合、問題を特定し、その改善策を立
案・実施することによって、再発を防止しなければいけ
ない。今回の問題点は、X医師が変更要求を随時確認で
きない状況にいるということである。そこで、その改善
策として私は以下の案を挙げた。
�@変更承認の担当者を変更してもらう
�A変更承認権限をX医師以外にも付与してもらう
担当者を変更してもらうという�@の案は、Aセンターの
体制方針から不可能であるという回答であった。
そこで�Aの案が採用され、変更承認は緊急時に限りAセ
ンターの技術責任者であるY氏にも権限が与えられた。
Y氏は技術の専門職として勤務しているため、システム
関連業務を最優先で遂行できるという理由からである。
改善後、X医師の不在時にシステムバグによる障害が発
生したが、Y氏による変更承認が行われ、変更管理プロ
セスによる変更実施の遅延は防ぐことができた。
それ以後も、変更承認による遅れは発生せず、SLAの遵守
は保たれている。

3 変更管理プロセスの実施確認
○3−1 変更管理プロセス実施確認のための方策
変更管理プロセスは、確実に実施されていることを定期
的に確認する必要がある。
前述した改善策では変更承認権限者の追加に加え、変更
表のステータス更新時に、運用部門メンバーにもメール
が自動送付されるよう変更していただいた。以前は、ス
テータス更新時に次プロセスの担当者のみにメールが送
付されており、本人以外は変更管理データベースを自発
的に確認する以外で変更表のステータス確認を行う機会
がなかった。以後は運用担当メンバーがリアルタイムで
ステータスの更新状況を知ることができ、更新が滞って
いる担当者への状況確認などの対策を迅速に行うことが
可能となった。

○3-2 今後の課題
上記の対策により、変更実施の遅れを防ぐことは可能と
なったが、変更実施内容の確認について向上させる余地
があると考える。幸い、現在までに変更作業の実施によ
る障害は発生していない。しかし、変更作業により障害
は発生しなくて当たり前という雰囲気により、変更実施
後のレビューが形式だけのものとなっているように感じ
られる。現在のレビューでは、各変更実施担当者が独自
に用意した報告書に目を通し、特に内容に問題がなけれ
ば終了となる。これでは変更実施担当者の報告方法に依
存する点が大きく、明確なレビュー合格基準が与えられ
ていない。今後は変更実施方法・スケジュールの策定と
同時に、作業項目のチェックシートを作成し、作業実施
時には複数の担当者によるチェックを要する運用の
取り込みなどが必要と考える。
実施内容の効果的なチェックを加えることで、迅速かつ
正確な変更管理プロセスの実施を心がけたい。

-以上-
====================================================

[434]　ka2　(2010/10/13 Wed 00:31)

---

Re: 21年 午後�U　問1

ka2さん。はじめまして、すぎエモンです。
僭越ながら査読させて頂きました。

【良いと感じた点】
・設問に忠実に答えようとする構成ですね。
　もっとも基本的で重要な部分です。
・題材が「がんの研究機関」というのは斬新
　ですね。作成者にとっては単に仕事現場の説明
　なのかも知れませんが、未経験者が取り上げることのない
　題材で、査読者にとっても新鮮に映るかも知れません。
　つまり、リアリティがあるということですね。
・「1-1 私が携わったITサービスの概要」が短い文章ながら
　スッキリと分かりやすくまとめられていて読みやすいです。
　出だしで査読者の心を掴みやすいよい書き方だと思います。
　特にシステムの概要を短く簡潔に記述し、ITサービスの概要
　を中心として説明できている点は高評価ではないでしょうか。
・SLAで締結されている「障害からの復旧は12時間以内」という
　目標数値をしっかりと明言できている事、更に「運用中のシ
　ステムは約15時間停止」と実際の停止時間を記述して
　SLA違反となってしまった事が判りやすく記述していることは
　とても良いポイントだと思います。ITサービスマネージャとして
　デキる所を見せたなという印象を受けました。
・最低限の文字数で論文をまとめている事は見事だと思います。
・改善策としてあげた以下の２案はとても分かりやすいですね。
　�@変更承認の担当者を変更してもらう
　�A変更承認権限をX医師以外にも付与してもらう
　文章を見た瞬間に誰でも理解できそうな改善策です。
・「3−1 変更管理プロセス実施確認のための方策」で挙げている
　変更管理プロセスの定期的な確認方法は納得のいく内容でわかりやすい
　ポイントだと思います。
　ただし、より貪欲に合格を目指したいなら重要業績評価指標（ＫＰＩ）
　などを用いて、実施状況をレビューするという書き方にするか、
　内部監査などによって、遵守状況をチェックするやり方の方が
　より、問題文に準拠するのですが、そこまでする必要はないでしょう。
・何度も読み直しする事無くスッキリと頭に入ってきました。
　全体的に初めての挑戦にしては大変良く書けている論文だと思います。
　私が査読者ならＡ評価を付けると思います。

【気になった点】
・取り立てて「ここが悪い」という点はありませんでした。
・「変更管理プロセスによってシステムの運
　用に影響を与える場合、問題を特定し、その改善策を立
　案・実施することによって、再発を防止しなければいけない。」
　という記述は折角なので
　「私は、変更管理プロセスによってシステムの運用に影響を
　与える場合、問題を特定し、その改善策を立案・実施すること
　によって、再発を防止しなければいけないと考えた。」
　という書き方にしては如何でしょうか、
　これにより、「自分の考えであり、それが問題文に準拠する」
　ことを強くアピールするという事に繋がります。
・ka2さんは、論文作成能力は非常に高いと思われるので、
　私からアドバイスできることは少ないです。
　しかし、レベルが高い人でも選択した論文問題や査読者と
　相性が悪いとあっさりとＢ評価になってしまう事例があるようです。
　合格には運の要素もあるということですね。
　よって、本番では慎重に問題を選択する、結果が駄目でも
　運が悪かったと割り切り、次回挑戦に気持ちを切り替える
　などが重要かと思います。

[436]　すぎエモン　(2010/10/13 Wed 11:54) mail

---

Re^2: 21年 午後�U　問1

初めまして。
すぎエモンさんが丁寧に評価されているので、その他の部分を指摘させて頂きます。全体として評価の高い論文である点はすぎエモンさんと同意見です。

・段落の始めは字下げするのが正しいです。本番では１字あけて書き始めるべきでしょう。

・1-1で「受託しているITサービスマネージャ」が個人で受託しているような表現です。「私はAセンターのシステム運用を受託しているソフトウェア会社W社に所属しており、ITサービスマネジメント業務を行っている。」という感じで私は去年書きましたので参考まで。

・2-1で「変更承認が行われず障害復旧に15時間掛かった」という箇所に違和感を覚えました。
　障害復旧はインシデント管理の範疇ですから、バグが残っていようとまずは「サービスを復旧する」ことを重視するのが理想論です。バグは「ある日」発見されたのですから、バグがあってもサービスは（一部制限としても）とりあえず提供できるのでは？と感じました。
　本問は「変更管理の確実な実施」ですから、「サービス停止に繋がる致命的なバグが発見され変更管理にかけたが、承認が遅れたため適用前にバグが表面化しサービスが停止してしまった」等とした方がより適切かと思います。（これも回避策をアナウンスしてないのでマズイんですが…）

参考になれば幸いです。

[438]　hok　(2010/10/13 Wed 23:03)

---

Re^3: 21年 午後�U　問1

>すぎエモンさん、hokさん

貴重なご意見ありがとうございます。

自分の書いた論文にご意見を頂いたのは初めてなので、

大変参考になりました。

本番ではお二方に頂いたアドバイスを取り入れ、

私にできる最善の論文が書ければと思います。

今回書いた論文は、

PCで打ち込んでも

2時間以上かかってしまったので

スピードにまだ課題が残っていますが…

すぎエモンさんとhokさんに頂いたお言葉で

少なからず自信を得ることもできました。

合格発表の際は良い報告を

この場でできたらと思います。

すぎエモンさん、hokさん

ありがとうございました。

[440]　ka2　(2010/10/14 Thu 00:15)