はじめまして。
とりあえず春に情報セキュリティは取れたので、
秋にITサービスマネージャを受験しようと考えております。
NWとどちらを受けるか迷ったのですが、
私は保守・運用の仕事が多いので、ITサービスを受ける事にしました。
論文試験は全く自信がありませんが、このサイトを参考にしながら
頑張りたいと思います。
今後もちょくちょ覗かせていただきますので、
よろしくお願いいたします。
[264] もとちゃん (2009/07/04 Sat 15:52)
お久しぶりです。
システム管理、プロジェクトマネージャに続き、システム監査も合格する事ができました。
このサイトで学んだ論文の基礎がベースとなって連続合格が可能になったと考えます。
本当にありがとうございました。
～～～～～～～～～～～～～～～～～～～～～
平成２１年度 春期 システム監査技術者試験 成績照会
受験番号 AU921-???? の方は， 合格 です
午前Ⅰ得点
***.**点
午前Ⅱ得点
84.00点
午後Ⅰ得点
61点
午後Ⅱ評価ランク
A
～～～～～～～～～～～～～～～～～～～～～
午後Ⅰが非常にギリギリでしたね、運が良かったです。
[260] すぎエモン (2009/07/01 Wed 11:11) mail
すぎエモンさん
システム監査の合格おめでとうございます。
相当努力されたんだと思います。
情報処理試験の中で、監査が一番難しいと感じております。監査に合格したということは自信を持たれて良いでしょう。
過去の掲示板での添削では、勝手なコメントを書いて申し訳ございませんでした。嫌なお気持ちになられたでしょう。
すぎエモンさんは、私のレベルを十分に超えられてます。今後は、この掲示板に質問される受験生へのアドバイスや悩みにお答えいただけると助かります。
私ごとですが、情報セキュリティに合格しておりました。
合格はいいですね。
ご報告ありがとうございました。
[263] 管理者 (2009/07/01 Wed 21:57)
先日プロマネ試験を受験したと書き込みした某氏です。
今日、春試験(高度)の合格発表があったのですが
無事合格していました！
これもシステム管理受験の際に色々と論文指導していただいた
管理人様のおかげと思います。
ありがとうございました。
（ちなみに午後Ⅰが60点であしきりのところ、68点だったので
ちょっと危なかったです。。）
秋は初開催のITストラテジストを受けようかと考え中です。
[259] 某氏 (2009/06/30 Tue 23:43)
某氏さん
合格おめでとうございます。
すごいですね。連戦連勝ですね。
>これもシステム管理受験の際に色々と論文指導していただいた
>管理人様のおかげと思います。
私は何もしておりません。某氏さんの実力でしょう。
秋はストラテジストですか、、、
合格したら、コツを教えてください。
時間があれば、論文テクニックを含めた合格体験談を書き込み願います。
[262] 管理者 (2009/07/01 Wed 21:41)
ショウです。サンプル問題の論文を投稿します。
よろしくお願いします。
------------------------------------------------------
１． 私が携わったＩＴサービス概要とエスカレーショ
ンしたインシデントの概要
１．１ 私が携わったＩＴサービス概要
私は旅行会社Ａ社に勤務し、情報システム部に所属し
ている。主にＩＴサービスマネージャとしてＡ社のシス
テムの運用監視業務に従事している。今回、論述するＩ
ＴサービスはＡ社の旅行販売業務システムである。
旅行販売業務システムは、業務サーバとＤＢサーバが
配置された大阪データセンタと全国に150 の販売代理店
の業務端末とを専用線で接続したシステム構成となって
いる。販売代理店の窓口業務時間は10時から19時で窓口
業務時間内のサービス中断は窓口業務遂行の妨げになる
ため、各サーバは冗長化構成になっている。また大阪デ
ータセンタ内に運用保守・監視・販売代理店からの問い
合せ対応を行うサポートデスクを設置している。サポー
トデスクと販売代理店との間で、問題解決対応時間48時
間がＳＬＡとして規定されており安定的なＩＴサービス
の提供に努め日々の運用保守業務を遂行している。
１．２ エスカレーションしたインシデントの概要
ＩＴサービスマネージャは日々のインシデントへの対
応状況を監視しＳＬＡを遵守するため主体的に行動する
事が重要であり、インシデントの内容によってはエスカ
レーションを指示し対応と解決を行う事が重要であると
私は考える。
今回、エスカレーションしたインシデントは販売代理
店Ｂ店からの申告によるインシデントである。内容は、
「予約キャンセルを受けたが、キャンセル処理ができな
い」ということである。20分後には、他の販売代理店か
らも同様にキャンセル処理ができない申告がありＢ店に
特化したインシデントではなかった。他の販売代理店へ
も発生し拡大しはじめているという状況であった。
２． インシデント検知から終了までのプロセスと、エ
スカレーション実施を判断した理由について
２．１ インシデントの検知について
検知するインシデントとしては、システム監視ツール
のアラーム通知における検知、各販売代理店のユーザか
らのサポートデスクへの問い合せにおける検知がある。
どちらからの検知であっても、発生したインシデントは
インシデント管理ＤＢシステムにおいて、記録し管理す
るルールとなっている。
検知したインシデントは以下の項目を記録する。
①インシデント管理番号
②インシデント発生日時
③インシデントタイトル（30文字以内で簡潔に書く）
④インシデント詳細内容
⑤サポートデスク対応担当者
⑥インシデント検知者（システム監視ツールまたは、
販売店の問い合せユーザ名を書く）
２．２ 初期サポートの実施とエスカレーション
Ａ社の全てのシステムには発生したインシデントを迅
速にかつ正確な対応と対処を行うため、障害対応マニュ
アルが配備されている。インシデント管理ＤＢシステム
に記録した後は、障害対応マニュアルの作業手順に従っ
てインシデント解決を行う。多くのインシデントは既に
原因と対処が明確なエラーであり、障害対応マニュアル
に記載された作業手順に従って対処する事でサポートデ
スクでの解決が可能である。また、インシデント管理Ｄ
Ｂシステムに記録された過去の類似インシデントを検索
し対処に役立てることを行っている。しかし、障害対応
マニュアルが無く、過去に類似したインシデントもない
未知のエラーが発生したと考えられる場合は、エスカレ
ーションを指示する必要がある。１．２で記載した販売
代理店Ｂからの申告は、まさに未知のエラーが発生した
と考えられる状況であり、私は開発部門へのエスカレー
ションを指示した。なお、Ｂ店へは原因不明であり解決
には時間を要する事を説明するとともに、予約者へキャ
ンセル料が発生してしまうなど、早急にキャンセル処理
が必要な予約データは、キャンセル料が発生しないよう、
社内手続きを実施した。ＤＢのデータを消去しなかった
のは、開発部門にてインシデントの原因究明が出来なく
なる可能性を回避する工夫をしたためである。
ＳＬＡ遵守のための働きかけも重要なことであり、開
発部門へのインシデントの内容の詳細を伝達するだけで
なく、必要なログの取得や調査協力をした。また、開発
部門に逐次、調査状況の報告を求めるようにした。
２．３ インシデント解決と終了について
発生から18時間後、原因が判明した。原因は３日前に
リリースした業務プログラムにバグであったためである。
復旧を優先するため旧プログラムに一時的に戻し確認テ
ストを実施して回復していることを確認した。
後日の修正プログラムリリース時においてもリリース後、
確認テストを実施し問題がないことを確認した。
私はインシデント管理ＤＢシステムに以下の項目を記
録することを指示しインシデントを終了させた。
⑥原因および対処内容
⑦対応終了日時
３． インシデント管理プロセスの定期的な評価と改善
について
ＳＬＡで取り交わした合意内容の達成を目指すために
は、インシデントの検知から終了までのインシデント管
理プロセスを定期的に評価し、良い点はさらに良くなる
工夫を検討し、悪い点については改善案をいくつか検討
し改善していくことが重要であると私は考える。
サポートデスクでは２週間に１回、発生したインシデ
ントについて、発生件数、対応内容、未解決インシデン
トの確認を行うミーティングがある。単に報告や情報共
有という位置付けのミーティングであったが、インシデ
ント検知から解決・終了までのプロセスの評価も一緒に
行うこととした。
サポートデスク要員のスキル不足が原因で対処に時間
がかかったプロセスがあったものは、「要員スキル向上
のための訓練の実施」「メンバ交代」「スキル不足要員
のベテラン要員のサポート」などの案を検討し改善をは
かることとした。
今回のインシデントを評価すると、プロセスとしては
早急に対応できたため、問題ないプロセスであったと評
価に値すると考える。ただし、エスカレーションの判断
基準を明確に設けられていれば、なお良かったのではな
いかと考える。今回のエスカレーション実施は私の業務
経験から判断した面が強く、曖昧で明確な基準があった
わけではない。明確な判断基準があれば私の不在時にお
いても的確にエスカレーションできると考える。サポー
トデスク要員が、インシデント対応時にエスカレーショ
ンが必要なインシデントであることをいち早く察知しで
きるため、ＳＬＡ遵守につながる改善であると考える。
後日、エスカレーションにおける判断チェックシート
を作成し仮運用することとした。サポートデスク要員か
らはエスカレーションの必要性が早くに察知できるとい
う声もあり、狙い通りの効果が得られた。改善において
も評価と同様に定期的に実施することとし、今後も安定
的なＩＴサービスの提供に努めたいと考える。
以上
[258] ショウ (2009/06/29 Mon 04:14)
ショウさん
勉強お疲れ様です。
簡単にコメントします。
>問題解決対応時間48時
>間がＳＬＡとして規定されており安定的なＩＴサービス
>の提供に努め日々の運用保守業務を遂行している。
こんなSLAってあるんですか？
なぜ48時間なのか、分からないです。48時間もかかっては
急ぎの処理ができないのでは？
私の本の中で、第2部にSLAを解説してます。
同時に、代表的なSLAをいくつか載せているので、その中からSLAを選んでもらった方がよいでしょう。
一般的なSLAでない場合、採点官の立場に立つと、読むのが大変です。
このままでは評価ポイントである「論述の妥当性」に”？”がつきます。
ショウさんの内容の場合、SLAを「障害・不具合の復旧時間を12時間」としてはいかがですか？
そのほうが違和感は減ります。
>未知のエラーが発生したと考えられる場合は、
>エスカレーションを指示する必要がある。
なぜですか？
SLAが48時間であれば、48時間以内に対応できるのであればエスカレーションする必要性はありませんよね。
2.2と2.3の内容が薄いですね。
ちょっと残念
3もいまいちですね。
総合評価ですが、私の評価はCです。
ですが、色々と最近調査した結果、合格率が大幅に上がっていることもあり、この内容でも合格する可能性が多いにあります。題意に沿ってよくかけていますからね。
ただ、私の評価でAを目指してください。
合格ラインぎりぎりだと、不合格の可能性もありますから。
SLAを変えて書きなおしてほしいです。
応援してます。
[261] 管理者 (2009/07/01 Wed 21:37)
ＳＭの試験について、何本くらい、準備すればいいでしょうかね？
ＡＵでは、翔泳社の教科書より９本と書いてあったんですけどね。
ちなみに、春にＡＵ受けたときは、５本くらい準備して、本番
では、適当に混ぜて、アレンジして２７００字くらい書きました。
アイテックの昨年版の午後対策と、今年の翔泳社持っているけど、
具体的な本数がないんで、困っています。
一応、３本程度準備しようと考えています。ＡＵに比べて、
はずれは少ないと思うんですけどね。いかがでしょうか？
[251] ＤＵＫＥ (2009/05/25 Mon 09:22)
昨年ＳＭ試験に合格した者です。
準備論文ですが、私の場合は３本位用意しました。
ただ、出題者の要求に外れるとＮＧなので、今までの経験等を
書く設問ア以外は準備論文の内容を無理に書こうとはせず、
問題文の内容に合わせるようにしました。
[255] 某氏 (2009/06/07 Sun 13:47)
AUの場合は範囲が広いので、準備論文の本数が増えるでしょう。
ITサービスマネージャの場合は、インシデント（障害）系を1本しっかり作っておけば、最低限戦えるでしょう。3問ありますので、1問はインシデント（障害）系での論文がかけるはずです。
ただ、某氏が言われていたように、ア以外は準備できる可能性は低いと思います。出題された内容に即して書くしかないでしょう。
参考になりましたでしょうか。
[256] 管理者 (2009/06/09 Tue 04:47) web
各位
ありがとうございます。３本程度書こうと考えています。
監査の時は、結局、適当にアレンジして、書きました。
春の監査はあきらめています。
午後Ⅰは一番難しい問題（問２）を選択してしまったようです。
ＩＴＥＣとＴＡＣとも、割れていますからね。
問３は簡単だったけど、考えすぎてしまった。
失点が多く、駄目ですね。
今回から、素点ですから、偏差とかでの調整はないと
みています。５０点もとれていないだろうな。
論文は、ここにさらすことはできません。
やはり、顧客の秘密に関することですからね。
設問ウが今回から長いことが最大の注意事項だと思います。
[257] ＤＵＫＥ (2009/06/17 Wed 00:06)
ちょっとだけ宣伝させてください。
ITECさんからITサービスマネージャに関する本が発売されました。
2009 ITサービスマネージャ 「専門知識+午後問題」の重点対策
http://www.itec.jp/shop/products/detail.php?product_id=338
ITILの内容や、午後Ⅱのテクニックなどに加え、合格復元論文を3本載せています。これが特に受験生の皆様の役に立つと思っております。
よろしくお願いします。
[254] 管理者 (2009/05/30 Sat 14:36) web
こんばんは、ショウです。
「ネットワークスペシャリスト試験に楽々合格」の掲示板では、
ちょくちょく書込みさせていただいていますが、
こちらへの書込みは初めてです。
秋はＩＴサービスマネージャを受験しようと考えており、
新試験のサンプル問題を使って論文を書いてみました。
こちらで合格された方々より、
あまり出来はよくないと思われますが、
添削していただけたらと思います。
------------ ITサービスマネージャ試験 午後２ サンプル問題 ------------
問１８ インシデント管理におけるインシデントの段階的取扱いについて
ＩＴサービス提供中のインシデント発生時には、ＳＬＡで規定された時間内で迅速に
サービスを回復させることが求められている。ＩＴサービスマネージャは、インシデントへ
の対応状況を監視し、ＳＬＡを遵守するように、主体的に行動する必要がある。
インシデントによっては段階的取扱い（以下、エスカレーションという）が重要と
なる。ＩＴサービスマネージャは、インシデントの検知から終了まで、エスカレーショ
ンを含めて、次のようなプロセスを遂行しなければならない。
（１）インシデントの検知と記録
システム監視ツールからの情報やユーザからの問合せなどによって
検知したインシデントを記録する。
（２）初期サポートの実施とエスカレーション
一次対応者にインシデントの解決に向けた対応を指示する。インシデントへの対
応状況によっては、二次対応者へのエスカレーションを指示する。インシデントへの対応状況を把握し、ＳＬＡが遵守されるように働きかける。
（３）インシデントの解決と終了
インシデントが解決されていること、及びサービスが回復していることを確認し、インシデントを終了する。
また、エスカレーションを含めたインシデント管理プロセスについて定期的に評価
し、改善を行うことによって、ＳＬＡで取り交わした合意内容の達成を目指すことも重
要である。
あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。
設問ア
あなたの携わったＩＴサービスの概要とエスカレーションしたインシデントの概要を、
８００字以内で述べよ。
設問イ
設問アで述べたインシデントの検知から終了までのプロセスを、エスカレーションの
実施を判断した理由及び工夫した点も含め、８００字以上１６００字以内で、具体的に
述べよ。
設問ウ
ＳＬＡで取り交わした合意内容の達成を目指した、インシデント管理プロセスの定量
的な評価と改善について、６００字以上１２００字以内で、具体的に述べよ。
------------------------------------------------------------------------
＝＝＝＝＝＝ ここから論文です ＝＝＝＝＝＝＝＝
１． 私が携わったＩＴサービス概要とエスカレーショ
ンしたインシデントの概要について
１．１ 私が携わったＩＴサービス概要について
私は通信会社Ａ社に勤務している。情報システム部に
所属しており、主にＩＴサービスマネージャとして自社
システムの運用監視業務に従事している。今回、論述す
るＩＴサービスはＡ社の顧客管理システムである。
Ａ社の顧客管理システムは東京のセンタにサーバ群と
ＤＢが配備されたネットワークが構築され、各販売店の
クライアント端末と専用線で接続されている。営業時間
の10時から20時の間、運用稼動しておりＳＬＡとして、
以下の項目が定められている。
1)営業時間帯におけるシステム稼働率が99％である事
2)１処理要求にたいする応答時間が５秒以内である事
3)運用稼動開始時刻が遅れる場合は30分前までに各販
売店に対して電子メールおよびＦＡＸで周知する事
１．２ エスカレーションしたインシデントの概要につ
いて
東京のセンタでは、システム監視ツールにおける監視
をサポートデスクを設置して対応している。各販売店か
らの問い合せについての対応もサポートデスクにて対応
している。日々のインシデントへの対応状況を私が監視
しＳＬＡを遵守するため主体的に行動する事が重要であ
ると考え対応している。
インシデントの内容によってはサポートデスクでの解
決が困難なインシデントがあり、このようなインシデン
トはエスカレーションを指示し対応と解決を行う事が重
要であると私は考える。今回、エスカレーションしたイ
ンシデントはシステム監視ツールにて検知した、ＤＢサ
ーバのハードディスク使用率95％のしきい値超え検知に
おけるインシデントである。
２． インシデント検知から終了までのプロセスと、エ
スカレーション実施を判断した理由について
２．１ インシデントの検知について
検知するインシデントとしては、システム監視ツール
のアラーム通知における検知、各販売店のユーザからの
サポートデスクへの問い合せにおける検知がある。どち
らからの検知であっても、発生したインシデントはイン
シデント管理ＤＢシステムにおいて、記録し終了するま
で管理するルールとしている。
検知時における記録内容は、①発生日時、②インシデ
ント内容（30文字以内で簡潔に書く）、③インシデント
詳細内容、④対応者、⑤検知者（システム監視ツールま
たは、販売店の問い合せユーザ名）、である。
２．２ 初期サポートの実施とエスカレーションの実施
について
センタにはインシデント発生時において、速やかにか
つ正確な対応と対処、解決を行うためのマニュアルが配
備されている。システム監視ツールのアラームは障害ナ
ンバーが付与されており、障害ナンバーから障害対応マ
ニュアルを検索し、サポートデスク担当者はＩＴサービ
スマネージャの指示のもと障害対応マニュアルに記載さ
れている作業を実施しインシデントの解決を行う。
今回のインシデントにおいても私の指示のもと、障害
対応マニュアルの対処作業を行い解決する事となった。
具体的には、不要なデータを削除する事でハードディス
クの使用率を下げる対処が、マニュアルに記載されてい
るため、取引が終了し定められた保存期間（18ヶ月間）
を経過した不要データを削除する対処を指示した。ただ
し、今回のインシデントについてはマニュアルに記載さ
れた対処だけでは問題がありエスカレーションの必要が
あると考えた。なぜならば取引データは日々、追加・変
更されており、削除となるのは年１回のメンテナンス時
に行われるデータベース再編成のタイミングしかないた
めである。今回の対処だけでは一時的な解決にしかなら
ず、近々同様のアラームが発生するとも限らない。そう
なってはＳＬＡで定められた、稼働率99％や応答時間５
秒以内が守れなくなると私は考えた。
以上の事からエスカレーションが必要と判断し開発部
へのエスカレーションを指示し、一時的な対処でのイン
シデント解決、終了はは行わず、根本的な解決がなされ
るまで終了を保留する事にした。
根本的な対処が早急に必要である事を開発部門に認識
させる必要があると考えた私は、サポートデスク担当リ
ーダのＡ氏に過去のログから取引データの増加率を調査
させ、再び同様なインシデントが発生する可能性がある
という報告書を作成した。調査の結果、現状の状況では
２ヶ月後に再び発生する可能性がある。エスカレーショ
ンにおけるインシデントの内容を伝える工夫として作成
した報告書であるが、対応スケジュールを計画する事に
も利用できると私は考えて実施した。
２．３ インシデント解決と終了について
報告書にて早期対処の重要性を十分に認識させる事が
開発部門にできたため、早急な根本的対処を実施する事
となった。増加率から算出し現状の２倍の容量になるよ
う増設を行う事が対処の内容である。
増設後は45％に使用率が下がりインシデントが根本的
対処により解決されたと判断した。また、サポートデス
クにてサービス回復確認テストを実施し、問題がない事
とＳＬＡが遵守できている事を確認した。
私はＡ氏にインシデント管理ＤＢに、⑥対応内容、⑦
対応終了日時、を記録する事を指示しインシデントを終
了させる事にした。
３． インシデント管理プロセスの定期的な評価と改善
について
以上
[227] ショウ (2009/05/06 Wed 21:58) mail
投稿した論文が途中で切れてしまっていましたので、
再度、投稿することにいたします。
==================================================
１． 私が携わったＩＴサービス概要とエスカレーショ
ンしたインシデントの概要について
１．１ 私が携わったＩＴサービス概要について
私は通信会社Ａ社に勤務している。情報システム部に
所属しており、主にＩＴサービスマネージャとして自社
システムの運用監視業務に従事している。今回、論述す
るＩＴサービスはＡ社の顧客管理システムである。
Ａ社の顧客管理システムは東京のセンタにサーバ群と
ＤＢが配備されたネットワークが構築され、各販売店の
クライアント端末と専用線で接続されている。営業時間
の10時から20時の間、運用稼動しておりＳＬＡとして、
以下の項目が定められている。
1)営業時間帯におけるシステム稼働率が99％である事
2)１処理要求にたいする応答時間が５秒以内である事
3)運用稼動開始時刻が遅れる場合は30分前までに各販
売店に対して電子メールおよびＦＡＸで周知する事
１．２ エスカレーションしたインシデントの概要につ
いて
東京のセンタでは、システム監視ツールにおける監視
をサポートデスクを設置して対応している。各販売店か
らの問い合せについての対応もサポートデスクにて対応
している。日々のインシデントへの対応状況を私が監視
しＳＬＡを遵守するため主体的に行動する事が重要であ
ると考え対応している。
インシデントの内容によってはサポートデスクでの解
決が困難なインシデントがあり、このようなインシデン
トはエスカレーションを指示し対応と解決を行う事が重
要であると私は考える。今回、エスカレーションしたイ
ンシデントはシステム監視ツールにて検知した、ＤＢサ
ーバのハードディスク使用率95％のしきい値超え検知に
おけるインシデントである。
２． インシデント検知から終了までのプロセスと、エ
スカレーション実施を判断した理由について
２．１ インシデントの検知について
検知するインシデントとしては、システム監視ツール
のアラーム通知における検知、各販売店のユーザからの
サポートデスクへの問い合せにおける検知がある。どち
らからの検知であっても、発生したインシデントはイン
シデント管理ＤＢシステムにおいて、記録し終了するま
で管理するルールとしている。
検知時における記録内容は、①発生日時、②インシデ
ント内容（30文字以内で簡潔に書く）、③インシデント
詳細内容、④対応者、⑤検知者（システム監視ツールま
たは、販売店の問い合せユーザ名）、である。
２．２ 初期サポートの実施とエスカレーションの実施
について
センタにはインシデント発生時において、速やかにか
つ正確な対応と対処、解決を行うためのマニュアルが配
備されている。システム監視ツールのアラームは障害ナ
ンバーが付与されており、障害ナンバーから障害対応マ
ニュアルを検索し、サポートデスク担当者はＩＴサービ
スマネージャの指示のもと障害対応マニュアルに記載さ
れている作業を実施しインシデントの解決を行う。
今回のインシデントにおいても私の指示のもと、障害
対応マニュアルの対処作業を行い解決する事となった。
具体的には、不要なデータを削除する事でハードディス
クの使用率を下げる対処が、マニュアルに記載されてい
るため、取引が終了し定められた保存期間（18ヶ月間）
を経過した不要データを削除する対処を指示した。ただ
し、今回のインシデントについてはマニュアルに記載さ
れた対処だけでは問題がありエスカレーションの必要が
あると考えた。なぜならば取引データは日々、追加・変
更されており、削除となるのは年１回のメンテナンス時
に行われるデータベース再編成のタイミングしかないた
めである。今回の対処だけでは一時的な解決にしかなら
ず、近々同様のアラームが発生するとも限らない。そう
なってはＳＬＡで定められた、稼働率99％や応答時間５
秒以内が守れなくなると私は考えた。
以上の事からエスカレーションが必要と判断し開発部
へのエスカレーションを指示し、一時的な対処でのイン
シデント解決、終了はは行わず、根本的な解決がなされ
るまで終了を保留する事にした。
根本的な対処が早急に必要である事を開発部門に認識
させる必要があると考えた私は、サポートデスク担当リ
ーダのＡ氏に過去のログから取引データの増加率を調査
させ、再び同様なインシデントが発生する可能性がある
という報告書を作成した。調査の結果、現状の状況では
２ヶ月後に再び発生する可能性がある。エスカレーショ
ンにおけるインシデントの内容を伝える工夫として作成
した報告書であるが、対応スケジュールを計画する事に
も利用できると私は考えて実施した。
２．３ インシデント解決と終了について
報告書にて早期対処の重要性を十分に認識させる事が
開発部門にできたため、早急な根本的対処を実施する事
となった。増加率から算出し現状の２倍の容量になるよ
う増設を行う事が対処の内容である。
増設後は45％に使用率が下がりインシデントが根本的
対処により解決されたと判断した。また、サポートデス
クにてサービス回復確認テストを実施し、問題がない事
とＳＬＡが遵守できている事を確認した。
私はＡ氏にインシデント管理ＤＢに、⑥対応内容、⑦
対応終了日時、を記録する事を指示しインシデントを終
了させる事にした。
３． インシデント管理プロセスの定期的な評価と改善
について
３．１ インシデント管理プロセスの定期的な評価につ
いて
ＳＬＡを遵守するためには、インシデント管理プロセ
スを定期的にかつ客観的に評価する事が重要だと私は考
える。今回のインシデント管理プロセスにおいては、Ｓ
ＬＡを遵守できている事から十分に評価できると考える。
ただし、現状でよいかの判断と評価を行うため、半年に
一回、サポートデスク、開発部門間で評価会議を行う事
と、ユーザヒアリングを実施して定期的な評価と改善を
図る事とした。
３．２ 改善について
今回のインシデント発生で、プロセスを改善すべきと
考える点があった。ＳＬＡを遵守できていたのは増加率
が定量的な伸びであり、急なデータ増のリスクは考慮し
ていなかった事である。また、本インシデントの検知の
２週間前からのインシデント管理ＤＢを確認すると、５
秒以内ではあるが、応答が以前に比べ遅くなったという
問い合せがあり、今回のインシデントの兆候であったと
考える。管理プロセスにおいて終了していないインシデ
ント解決を重視して対処するのは当たり前であるが、終
了しているインシデントに対しても見直し、兆候を把握
し早急な対処に努めるプロセスが必要であると考えた。
私は週１回、終了インシデントから別のインシデント
となる兆候を把握するための確認プロセスを入れる改善
を行った。同時に、兆候の判断基準を明確にしておく必
要があると考えて、開発部門に協力を依頼し兆候一覧表
を作成した。一覧表のメンテナンスも必要であると考え
られる。一覧表のメンテナンスについては評価会議で確
認しメンテナンスを行う事とした。
以上の事をインシデント管理プロセスの改善とした。
以上
==================================================
[228] ショウ (2009/05/06 Wed 22:25)
悪くなんじゃないですか
時間があるときにじっくり見ます。
取り急ぎ、、、
最初にＳＬＡが3つ出てきますが、3つ使ってますか？
[229] 管理者 (2009/05/07 Thu 21:19)
こんばんは。ショウです。
> 悪くなんじゃないですか
> 時間があるときにじっくり見ます。
本当ですか？
そう言っていただけると、ちょっと自信が持てます。
じっくりと、ご確認＋厳しくコメントをよろしくお願いします。
> 取り急ぎ、、、
> 最初にＳＬＡが3つ出てきますが、3つ使ってますか？
３つは使っていません。
設問イには２つしか書いていません。。。。
なぜ、２つしか書かなかった（書けなかった）かというと、
実はこういう理由です。。。。
設問アで、いろいろなＳＬＡを考えてみたのですが、
いいのが思い浮かばず、ふと思いついたのが、
去年の午後１に「開始時間が遅れる場合は事前連絡する」
というようなＳＬＡが書いてあったなぁと思ったので、
１．１のパートが、ちょうど４００文字程度になると思ったので、
記入しました。
でも、設問イを書いていて、エスカレーションしたインシデントで、
「連絡が遅れてしまう」という事に、どうしてもつなげるのが出来ず、
２つのみを書いて先に進んでしまいました。
やっぱり、３つ書いたら３つとも考慮していることを論述しないと、
減点対象でしょうか？
[230] ショウ (2009/05/07 Thu 23:24)
減点ではないでしょう。
ですが、書かない方が良いと思います。
理由は、採点官が混乱しないためと、それを書くなら他に大事なことを書いた方がいいから、です。
5月末に本を出しますので、そこに詳しく書いてます。
添削には少々時間がかかりますので、しばらくお待ちください。
[232] 管理者 (2009/05/08 Fri 22:43)
こんばんは、ショウです。
コメントありがとうございます。
詳しくは本で確認させていただこうと考えていますが、
少し質問させてください。
問題文の始めの部分ですが、
===================================================================================
ＩＴサービス提供中のインシデント発生時には、ＳＬＡで規定された時間内で迅速に
サービスを回復させることが求められている。ＩＴサービスマネージャは、インシデントへ
の対応状況を監視し、ＳＬＡを遵守するように、主体的に行動する必要がある。
===================================================================================
という書き出しで始まっていたのと、
問題文の中盤あたりに、
===================================================================================
（２）初期サポートの実施とエスカレーション
一次対応者にインシデントの解決に向けた対応を指示する。インシデントへの対
応状況によっては、二次対応者へのエスカレーションを指示する。インシデントへ
の対応状況を把握し、ＳＬＡが遵守されるように働きかける。
===================================================================================
それから、設問ウでは
===================================================================================
ＳＬＡで取り交わした合意内容の達成を目指した、インシデント管理プロセスの定量
的な評価と改善について
===================================================================================
となっていましたので、
「ＳＬＡの具体的な定義と、そのＳＬＡ遵守についての働きかけ」
について書く必要があると考えたのですが？
考えすぎでしょうか？
[233] ショウ (2009/05/08 Fri 23:39)
＞シュウ様
横から失礼します。
SLAの件ですが、
===================================================================================
ＩＴサービス提供中のインシデント発生時には、ＳＬＡで規定された時間内で迅速にサービスを回復させることが求められている。
===================================================================================
とあることから、単純に、『障害によりサービスが停止した場合、検知から○分以内に回復すること』をSLAとすることで良いのではないでしょうか？
その方が、ア～ウの設問に対する答えも素直につながると思います。
＞管理者様
5月末に出される本とは、「ITサービスマネージャ対策本」ですか？
それとも「論文対策本」でしょうか？
いずれにしても、非常に興味があります。
立ち読みしたところ、情報処理教科書がイマイチだったので、期待しています。
最後に
今までサンプル問題を見たことがなかったのですが、かなりITILを意識した問題になっていますね。ITIL的に言えば、「インシデントをデータベースで管理する」、「既知のエラーに対するワークアラウンドを提供する」などの答えが書ければ採点者にアピールできるような気がします。
[235] ss2004 (2009/05/09 Sat 09:37) web
ss2004様へ
どうも。ショウです。
コメントありがとうございました。
> 単純に、『障害によりサービスが停止した場合、検知から○分以内に回復すること』を
> SLAとすることで良いのではないでしょうか？
> その方が、ア～ウの設問に対する答えも素直につながると思います。
たしかに、稼働率がどう、レスポンスがどう、というＳＬＡを書くよりは、検知から解決までのプロセスについて問う問題なので、
「インシデント検知から○分以内にサービス回復させること」
という、ＳＬＡの方がスマートですし、論述もしやすいですね。
勉強になりました、ありがとうございます。
[236] ショウ (2009/05/09 Sat 15:50) mail
ショウさん
お待たせしました。厳しい採点を書きます。
厳しい採点は愛情であることを理解して読んでいただけると幸いです。
■総合評価
C
※私の評価です。今後もそうですが、私の評価は本試験より厳しめです。ギリギリAを目指していただくのではなく、余裕のあるA評価を目指してもらうためです。
■総論
良い点は、
・論文としての体裁が整っています。
・比較的読みやすいです。
悪い点
・論述の具体性と妥当性です。
これが欠けていては、何回受けても受かりません。今は、論文を何度も書くよりは、納得のいく論文を1本仕上げることが大事です。
設問イが最も重要なので、この点に関して妥当性のコメントをします。私または採点者が感じる疑問があります。
>「ＤＢサーバのハードディスク使用率95％のしきい値超え検知に
>おけるインシデントである。」
・これって普通にあることでしょ。ショウさんの書き方だと95%を超えるとすぐに稼働率99%のSLAに影響がでるような書き方ですね。もしそうであれば、ハードディスクの使用率の閾値をもっと低い値に設定すべきでしょう。
・作業を一つひとつ指示されているようですが、ITサービスマネージャという管理者またはプロマネ的な人がすべての作業を指示するんでしょうか？
・サーバのデータ削除手順がマニュアル化されていなかったりツール化されていないって、ちょっと「え？」と思います。
・・・他にもたくさん
■各論というか枝葉の指摘
この部分だけを直しても意味がありません。総論で述べた本質部分の改善をしてください。
>主にＩＴサービスマネージャとして自社
>システムの運用監視業務に従事している。今回、論述す
>るＩＴサービスはＡ社の顧客管理システムである。
自社システムを運用しているのに、なぜ今回はA社のシステムの内容を書くの？
>東京のセンタでは
東京のセンタって何？
データセンタのこと？後半を読むとサービスデスクのセンタのようにも思える。
>運用稼動しておりＳＬＡとして、
>以下の項目が定められている。
> 1)営業時間帯におけるシステム稼働率が99％である事
> 2)１処理要求にたいする応答時間が５秒以内である事
> 3)運用稼動開始時刻が遅れる場合は30分前までに各販
前回言ったように、SLAが3つある意義が不明
サービス概要が薄いです。
無駄な記述が多いからでしょう。今回論述することに絞って具体的な記述を増やしましょう。
どんな内容を書くかは、ズバリ、後半で記載する内容に関連することを書きます。意味もなく台数や運用方法を具体的に書いても駄目です。
>１．２ エスカレーションしたインシデントの概要につ
> いて
ショウさんがタイトルとして「インシデントの概要」としています
しかし、インシデントの概要を書いているのは、最後のわずか３行のみです。
・・・・
きりがないのでこれくらいに
もう一度書き直されてはいかがでしょう。
[246] 管理者 (2009/05/17 Sun 07:57)
管理者様
とても厳しいコメントありがとうございました。
まあ、そんなもんだろうとは思っていたので、特に気にしていません。
２時間程度で書くという事は考えないで、
じっくり考えて、別のネタにして書きたいと思います。
> これって普通にあることでしょ。ショウさんの書き方だと95%を超えるとすぐに稼働率99%のSLAに影響がでるような書き方ですね。もしそうであれば、ハードディスクの使用率の閾値をもっと低い値に設定すべきでしょう。
やっぱり、ネタに無理がありますよね。
パッと思いついたエラーをエスカレーションが必要であるかのように、
書いてしまった感じがしています。
> 作業を一つひとつ指示されているようですが、ITサービスマネージャという管理者またはプロマネ的な人がすべての作業を指示するんでしょうか？
作業の一つひとつを指示するようなことは無いであろうと考えます。
解決方法が分かっているものは、すぐに担当者が対処してして、
終了したことの報告を受けるとか、
何か別の問題があれば状況についての報告を求めるのが、
ＩＴサービスマネージャではないかと思っています。
ただ、「一次対応者にインシデントの解決に向けた対応を指示する」と問題文に書かれていたので、
単純に、「へぇ～、解決プロセスで、解決に対する指示を出さないといけないんだ。大変だし面倒だなぁ」
と思って、そのまま論文に書いてしまいました。
逆に私が無知なので質問したいのですが、
管理者さんが考えるＩＴサービスマネージャとは、
どいう人物像だと考えますでしょうか？
> サーバのデータ削除手順がマニュアル化されていなかったりツール化されていないって、ちょっと「え？」と思います。
削除手順がマニュアル化していないと伝わりましたか？
「具体的には、不要なデータを削除する事でハードディス
クの使用率を下げる対処が、マニュアルに記載されてい
るため、取引が終了し定められた保存期間（18ヶ月間）
を経過した不要データを削除する対処を指示した。」
そうですね。。。ここは「対処」ではなく「削除作業手順」
という文言にしたほうが良かったですかね。
> ■各論というか枝葉の指摘
> この部分だけを直しても意味がありません。総論で述べた本質部分の改善をしてください。
わかりました。
全体的に別のネタを考えて、書き直してみます。
> 自社システムを運用しているのに、なぜ今回はA社のシステムの内容を書くの？
通信会社Ａ社に勤務しているから、自社であるＡ社と書いたのですが、
自社と書いたりＡ社と書いたり混乱しますから、
表現はどちらかに統一したいと思います。
>東京のセンタって何？
>データセンタのこと？後半を読むとサービスデスクのセンタのようにも思える。
両方保持しているという意味なんですが、
そうだという事を明記したいと思います。
>前回言ったように、SLAが3つある意義が不明
意義があるものだけにしたいと思います。
>サービス概要が薄いです。
>無駄な記述が多いからでしょう。今回論述することに絞って具体的な記述を増やしましょう。
>どんな内容を書くかは、ズバリ、後半で記載する内容に関連することを書きます。意味もなく台数や運用方法を具体的に書いても駄目です。
ちなみに、SLAの記載以外に無駄だと、考えられるところをご指摘いただけると、
修正時にも注意して考えることができるのですが。
>しかし、インシデントの概要を書いているのは、最後のわずか３行のみです。
書くネタが思い浮かばす、ここは問題文から半分以上を、
パクって書いてしまおうと考えて書いてしまいました。
やっぱりダメですか（笑汗
[247] ショウ (2009/05/17 Sun 17:26)
非常におおざっぱな話になりますが、ハードディスクの閾値程度の話ならマニュアル化又は自動化されていないのがおかしいという話ではないでしょうか？
エスカレーションの文脈で言えば、真に想定外のインシデントが起こった場合には、ITサービスマネージャの出番となるでしょうから、そのようなインシデントについて記述すれば概ね設問の趣旨からはずれずに論述できると思います。
[248] ss2004 (2009/05/17 Sun 20:52) web
こんばんは。ショウです。
ss2004さん。コメントありがとうございます。
エスカレーションのネタとしては、かなり無理がありました。
ss2004さんの言うとおり、今回は「真に想定外のインシデントが起こった場合」を意識して書いたつもりです。
管理者さん。読んでコメントするのが、
うんざりするかもしれませんが、よろしくお願いします。
ss2004さんからもコメントしていただけるとありがたいです。
ただ、私も他の人の論文を読んで、勉強したいと考えています。
お忙しいようでしたら、無理にとはいいませんが、
ss2004さんも、同じテーマで書いてみてはもらえませんか？
===========================================================
１． 私が携わったＩＴサービス概要とエスカレーショ
ンしたインシデントの概要
１．１ 私が携わったＩＴサービス概要
私は通信会社Ａ社に勤務している。情報システム部に
所属しており、主にＩＴサービスマネージャとして自社
システムの運用監視業務に従事している。今回、論述す
るＩＴサービスは自社の顧客管理システムである。
顧客管理システムは、サーバとＤＢを配置したネット
ワークがあるデータセンタと、各販売店の端末と専用線
にて接続されている。データセンタは東京に存在し、同
拠点にサポートデスクも設置されている。
各販売店の営業時間である10時から20時の間、運用稼
動している。営業時間内でのサービス中断は、各販売店
の業務遂行に大きな影響を与えてしまうため避けなけれ
ばならない。各サーバやネットワーク機器は全て冗長構
成になっているが、万が一、サービス中断が発生した場
合には迅速にかつ確実にサービス復旧を行う必要がある。
１．２ エスカレーションしたインシデントの概要
ＩＴサービスマネージャは日々のインシデントへの対
応状況を監視しＳＬＡを遵守するため主体的に行動する
事が重要であると私は考える。インシデントの内容によ
ってはサポートデスクでの解決が困難なインシデントが
あり、このようなインシデントはエスカレーションを指
示し対応と解決を行う事が重要である。
今回、エスカレーションしたインシデントは販売店の
Ｂ店から申告によるインシデントである。内容は「商品
在庫検索をするとエラー表示がされる」ということであ
り、他に同様な申告は最近受けてはいない。
サポートデスクに対するＳＬＡとして、問題解決時間
48時間以内である事と規定されており、未知の問題が発
生したと考えられる場合は、エスカレーションを行い早
急に解決する必要があると考える。
２． インシデント検知から終了までのプロセスと、エ
スカレーション実施を判断した理由について
２．１ インシデントの検知について
検知するインシデントとしては、システム監視ツール
のアラーム通知における検知、各販売店のユーザからの
サポートデスクへの問い合せにおける検知がある。どち
らからの検知であっても、発生したインシデントはイン
シデント管理ＤＢシステムにおいて、記録し終了するま
で管理するルールとしている。
検知時における記録内容は、①発生日時、②インシデ
ント内容（30文字以内で簡潔に書く）、③インシデント
詳細内容、④対応者、⑤検知者（システム監視ツールま
たは、販売店の問い合せユーザ名）である。
２．２ 初期サポートの実施とエスカレーションの実施
について
サポートデスクにはインシデント発生時において、速
やかにかつ正確な対応と対処を行うため、障害対応マニ
ュアルが配備されている。
各インシデントの解決は障害対応マニュアルに記載さ
れた対応や処置、作業手順に沿って対処する事でインシ
デント解決を行っている。多くのインシデントは既に原
因と対処が分かるエラーについてであり、障害対応マニ
ュアルに記載された対処作業手順に沿って対処する事で、
サポートデスクでの一次対応にて解決可能であるが、対
応状況によってはエスカレーションを指示する必要があ
る。
Ｂ店からのインシデントに対して、対応したサポート
デスクのメンバはＹ氏であり、通常通り障害対応マニュ
アルから対応を試みた。再起動をユーザに指示するなど
の一通り作業を実施し解決したかに思えたが、数分後、
再び同じ問題が発生したと、問い合わせがあり解決でき
ていないことが明らかになった。
以上の状況から、障害対応マニュアルの記載された対
処、作業手順では解決が困難であると判断し、開発部門
へのエスカレーションをＹ氏に指示する事にした。なお
Ｂ店へは原因不明であり解決には時間を要する事を説明
するとともに、業務遂行の妨げにならないよう必要デー
タの送付やサポートデスク側での代行処理などを行うよ
う、ユーザサポート面での対処について工夫をした。
また、ＳＬＡである問題解決時間48時間を遵守できるよ
う、開発部門とアクション会議を早急に開催するする事
とし、早期解決に向けた原因調査、アクションプランを
計画する工夫を行った。
２．３ インシデント解決と終了について
原因調査の結果、特定の検索文字と特定の権限を持つ
ユーザのみにエラー表示がされる、レアケースのバグで
ある事が判明した。発生から22時間が経っておりバグ改
修と改修のリリースは、さらに24時間後となりそうであ
った。原因が分かっており、24時間後には対処できる事
をＢ店に説明した上で、暫定的対処としてユーザの権限
を一時的に変更し業務に支障が生じないように対処した。
最終的にはバグを改修する事でインシデントを解決し、
バグ改修後、サポートデスクにて改修されていること
運用テストにて確認し、また、Ｂ店にも原因の報告とと
もにエラー表示がされない事を確認してもらった。
私はＹ氏にインシデント管理ＤＢに、⑥対応内容、⑦
対応終了日時、を記録する事を指示しインシデントを終
了させる事にした。
３． インシデント管理プロセスの定期的な評価と改善
について
３．１ インシデント管理プロセスの定期的な評価につ
いて
ＳＬＡを遵守するためには、インシデント管理プロセ
スを定期的にかつ客観的に評価する事が重要だと私は考
える。今回のインシデント管理プロセスにおいては、問
題解決時間が46時間であり、ＳＬＡを遵守できている事
から十分に評価できると考える。ただし、現状のプロセ
スで問題がないかの判断と評価を行うため、半年に一回、
サポートデスク、開発部門間で評価会議を行う事に加え
て、ユーザヒアリングを実施して定期的な評価を行う事
とした。
３．２ 改善について
今回のインシデント発生に際して、インシデント管理
プロセスの改善すべきと点としては、エスカレーション
の判断基準を設けることだと考える。
今回のエスカレーションについては、私の業務経験に
よる独自の判断基準でエスカレーションを実施したが、
明確な判断基準を設ける事で、的確なエスカレーション
の実施ができると私は考える。また、的確な判断基準を
設けることでサポートデスクのメンバにおいても、エス
カレーションの必要性のあるインシデントである事を、
いち早く察知し早期なインシデント解決に結びつける事
ができると私は考える。
過去にエスカレーションを実施したインシデントにつ
いて、インシデント管理ＤＢにて確認、分析しエスカレ
ーション判断基準を設け、サポートデスクメンバ全員に
展開する事を今回のインシデント管理プロセスの改善と
した。
以上
===========================================================
[249] ショウ (2009/05/18 Mon 00:08)
すみません、なかなか自分の論文を書くほどの余裕がありませんので、雑ぱくな感想だけでお許しください。
一点だけ、インシデントの内容がそれほど深刻なものと思えないのですが？
ということを、疑問に感じました。私なら、もう少し深刻なインシデントを想定すると思います（この例なら、在庫検索が一切できないとか）。
そこを除けば、全体の書き方は良いと思います。特に、問題文からの引用の仕方は優れていると思います。
[250] ss2004 (2009/05/20 Wed 23:18) web
ss2004さんへ
> すみません、なかなか自分の論文を書くほどの余裕がありませんので、雑ぱくな感想だけでお許しください。
そうですか。残念ですが仕方ないです。
> 一点だけ、インシデントの内容がそれほど深刻なものと思えないのですが？
> ということを、疑問に感じました。私なら、もう少し深刻なインシデントを想定すると思います（この例なら、在庫検索が一切できないとか）。
>
> そこを除けば、全体の書き方は良いと思います。特に、問題文からの引用の仕方は優れていると思います。
どうも、コメントありがとうございました。
参考にさせていただきます。
[252] ショウ (2009/05/29 Fri 23:13)
ショウさん
インシデント管理ではインパクトと緊急度に応じた優先度をつけます。（詳しくは書籍のP61)
ショウさんのインシデントは、インパクトと緊急度が高いことが伝わってきません。在庫検索によるインパクトと緊急度が高いことを明示するか、全システムがダウンするなど、明らかにインパクトが大きいインシデントを記述するのがよいでしょう。
今は悩まれている状態かもしれませんが、それほど心配しなくていいです。1つ得意な事例（この場合はインシデント）を作れば、その一つを色々な問題で応用できます。これはITサービスマネージャ試験ならではの特徴です。（PMでは無理でしょう。）
書き直しされる場合は、新しい記事を立ててください。
よろしくお願いします。
[253] 管理者 (2009/05/30 Sat 14:31) web
本日、ITILファンデーション試験を受けてきました。
試験問題は結構悩ましく、残り2つまでは絞れるんですけど、どっちなのかが分かりません。そんな問題が多かったです。
65点で合格のところを92点（40問中37問正解。）でした。よかったです。
試験については以下に書きましたので、参考にしてください。
http://sm.xn--n9q36mh1hnxuksz7wt.net/archives/65219417.html
[222] 管理者 (2009/02/11 Wed 17:25)
ショウです。
私はITILというものは、全く分かりません。
「インシデント」という言葉が分からず、
インシデントという言葉を調べてから、
論文を投稿したぐらいです。
今度、管理者さん著書の本には、
ITIL論文対策も含まれているということなので、
その本で勉強しようと思っていますが、
全くド素人なので、ITIL関連を勉強する上で、
この本はよいと考えるものがあれば、
お聞かせねがえませんでしょうか？
[243] ショウ (2009/05/12 Tue 12:56)
>全くド素人なので、ITIL関連を勉強する上で、
>この本はよいと考えるものがあれば、
>お聞かせねがえませんでしょうか？
難しい質問ですね。
ITILの本はたくさんの良書がでています。その内容は私が書いた内容とは比べ物にならないくらい良い本です。それは間違いありません。
ただ、ITILの勉強とITサービスマネージャの勉強はイコールではありません。ITILは今やv3になり、IPAが求めている試験範囲とはズレがあると考えております。v2の内容がマッチしているでしょう。
また、ITILを本格的に勉強するのはとても時間がかかります。
その点も含めて、私の本では、IPAが発表する応用情報のシラバスをもとにキーワードを抽出し、IPAから試験情報以外にもたくさんの情報が提供されている情報を大切にしています。分厚い本を出すのではなく、試験に必要な内容をピンポイントで提供したいという思いを込めて書き上げました。
ですが、どこまで読者の方々のためになるかは未知数です。
手前味噌で恐縮ですが、とりあえず私の本を読んでいただき、不十分と思われたら、他の本を買われてはいかがでしょうか。
[244] 管理者 (2009/05/12 Tue 19:51)
>ただ、ITILの勉強とITサービスマネージャの勉強はイコールではありません。
>ITILは今やv3になり、IPAが求めている試験範囲とはズレがあると考えております。
>v2の内容がマッチしているでしょう。
>また、ITILを本格的に勉強するのはとても時間がかかります。
>手前味噌で恐縮ですが、とりあえず私の本を読んでいただき、
>不十分と思われたら、他の本を買われてはいかがでしょうか。
ご回答ありがとうございます。
今度、発売予定の書籍で勉強を進めていき、
不十分だと感じたら（おそらく感じることはないかと思いますが[笑汗]）
別の本を購入して勉強をしたいと思います。
[245] ショウ (2009/05/13 Wed 13:06)
テクニカルエンジニア（システム管理）の
平成20年 午後1 問2 設問2(1)の問題について、
よく分からないので質問させてください。
設問2(1)
「Webページの改ざん以外で、公開用Webサーバに関する
F社のシステム構成上のリスクを20文字以内で述べよ」
試験センターの解答例は
「Ｗｅｂアクセスログが削除される」
という事ですが、この解答内容が、いまいち引っかかってなりません。
設問の内容が、
「Webページの改ざん以外に発生する可能性のあるリスクを述べよ」
となっていれば、
DMZ上にあって公開されているのだから、
Webアクセスログが改ざんされたり、削除されたりするリスクがある。
というので、納得できるのですが、
設問の文言は「システム構成上のリスク」と書かれているので、
ＤＭＺ上に大事なものを置いていることいけない
という内容の事を解答しないといけないのではないかと
私は考えてしまいます。。。
素直に読み取っていないという事なのでしょうが、
どうしても、素直に読み取れない問題でした。
どなたか、納得できるような解説をしていただけませんでしょうか？
よろしくお願いいたします。
[234] ショウ (2009/05/09 Sat 00:09)
昨年この問題を解いて合格しました私が解説いたします。（えっへん！）
設問2(1)
「Webページの改ざん以外で、公開用Webサーバに関する
F社のシステム構成上のリスクを20文字以内で述べよ」
ショウさんは問題の読み方でひっかかっているようですね。
この設問は、あくまで公開用Webサーバに関するリスクが問われているようです。
F社のシステム構成上のリスクについて一般的に広く問われているわけではありません。
どっちともとれそうであまり良い文章じゃないですが、
こうゆう変なのはたまにあるので要注意です。
(ワザと変な文章にしてるようにも思えます)
公開用Webサーバのリスクとシステム構成上のリスクを両方考えつつ、
他の設問との整合性をみて解答するしかないですね。
あとはご存知の通り「F社のシステム構成上」とは
ＤＭＺに配置し外部公開されるシステム構成としていることを指しています。
公開用WebサーバのリスクでWebページの改ざん以外となると、
踏み台にされないかとかも考えられますが、
ここは問題に色々記述のあるログのうちのＷｅｂアクセスログで、
それの改ざん・削除を解答するのが素直ですよね。
しかし、早くも秋期試験の勉強開始ですか。
頑張って下さい～。
[240] かんそく (2009/05/10 Sun 22:57) mail
かんそくさん
コメントありがとうございます。
> この設問は、あくまで公開用Webサーバに関するリスクが問われているようです。
> F社のシステム構成上のリスクについて一般的に広く問われているわけではありません。
> 公開用Webサーバのリスクとシステム構成上のリスクを両方考えつつ、
> 他の設問との整合性をみて解答するしかないですね。
確かに設問では「・・・公開用Webサーバに関する・・・・」
となっていますね。
微妙な文書の書き方ですけど、ここは
「公開用Webサーバに関するリスクを問われている」
と認識しないといけないわけですね。
ややこしい問題ですね。。。。
ありがとうございます。
これからの勉強に役立てたいと思います。
> しかし、早くも秋期試験の勉強開始ですか。
> 頑張って下さい～。
いやぁ～。
新試験になりますし、ちょっとづつでもやっていかないと、
さすがに合格できないとだろうと感じていまして。。。。
論文もサンプル問題を見る限り、
設問ウは準備できそうになくなりましたからね。
プロマネもそうでしたから。。。。。
頑張って一発合格を目指します。
[242] ショウ (2009/05/11 Mon 13:06)
本日、合格証が届きました。
合格はうれしいものです。
スコアは以下です。
受験番号 AU604 - XXX の方は，合格です。
午前試験のスコアは，680 点です。
午後I試験のスコアは，615 点です。
午後II試験の評価ランクは，A です。
午後Ⅰはぎりぎりでしたし、午後Ⅱもぎりぎりだと思います。ラッキーでした。
今後も学習を続けていきたいと思います。
[211] 管理者 (2008/06/20 Fri 16:59)
私もこの春にＡＵ受験しましたが、全然駄目です。
午後Ⅰは、考えすぎたかな？って感じで、答えを外しています。
第一感を、大事にすべきでした。
ＴＡＣ配点では、３０点くらい損しています。
そんな簡単（あんちょこ？）な答えでいいんかい？ってな
気分です。
まあ、午前Ⅰについては、アドバンテージ（２年分免除）を
確保できる見込みなので、来年春に、合格できるよう、
秋のＳＭ受験後に、準備に着手するつもりです。
今回から、午前は、制度としては、楽になりました。
ただ、午後Ⅰは一律６０点ゆえ、正直厳しいですね。
また、短い時間に慣れていたせいか、じっくり、考えることが、
案外むずかしいですね。さらに、一問あたりのウエイトも、
従来より重くなったわけですから、午後Ⅰについては、厳しく
なったように、感じられました。
春のＡＵの試験より、しょうもない質問です。
「データ」の定義として、アクセスログっていうのは、
含まれないんでしょうかね？
午後Ⅰ問３の設問２で、ＡＰサーバのアクセスログのほうに食いついたのですが、やっぱり、注文履歴らしいのです。
ログのほうが、時刻とか、明確なので、飛びついたんですけど、
考えすぎでしたかね？
ログが、定義上「データ」でなければ、完璧に外れですけど、
いかがでしょうか？
国語の問題と割り切るべきでしたかね？
[231] DUKE (2009/05/07 Thu 23:45)
DUKEさん
こんにちは
監査ですか、、、
監査は難しかったです。
>「データ」の定義として、アクセスログっていうのは、
>含まれないんでしょうかね？
含まれると思います。
ですが、（よく読んでいないので間違っていたらすいません。）
アクセスログから特別注文が判断できますか？特別注文の判断には注文限度額が必要ですが、「ログ機能」の問題文を読む限り、アクセスログからは取得できないと思います。
[237] 管理者 (2009/05/10 Sun 06:22)
受付のボタンをクリックするところなどが記録されるんで、
判断しました。
私は、当時、逆に履歴では、特別注文と判断できないと
判断していました。
いまいち、理解に苦しむ問題でした。
課長の押印前に、受付しても、履歴では判断できるか
不明でしたからね。
課長の指示がＯＫなら、結果的に問題ないけど、
ＯＫの指示前はまずいとか、考えすぎましたかね？
まあ、これが実力なんでしょう。
[241] DUKE (2009/05/11 Mon 00:33)
ss2004さんの記事が、別の内容であったのでこちらに回答します。
>>管理者様
>5月末に出される本とは、「ITサービスマネージャ対策本」ですか？
>それとも「論文対策本」でしょうか？
>いずれにしても、非常に興味があります。
>立ち読みしたところ、情報処理教科書がイマイチだったので、期待
>しています。
ありがとうございます。かなり力を入れて書きました。
ITサービスマネージャ対策の総合版です。ITIL,論文対策も充実させてます。たぶんご存じだと思う大手出版社から出ます。ただ、新試験ですのでIPAがどう出題してくるかは分かりません。
もう少したら正確に公表し、5月末には書店に並ぶと思います。
それとss2004さんのHPを見させていただきました。情報処理試験の合格率はすごいですね。短時間で合格できるコツや勉強方法を教えていただけませんか？特にエンベデットは、他の試験と分野が全く異なるから難しいと聞いていたんですが。どうやって勉強されました？
[238] 管理者 (2009/05/10 Sun 06:44)
>管理者 様
さっそく御返事ありがとうございます。
ITサービスマネージャの教科書ですが、単なる「テクニカルエンジニア（システム管理）の焼き直し」というものが結構見受けられました。新試験でどのような出題がされるかは不明ですが、せめて、公式発表位はフォローアップして欲しいと思いました（TACのテキストはその点研究していると思います）。
私の試験対策ですが、とにかく、過去問重視で行っています。エンベデッドも同様で、過去3年間の過去問を解いたのが試験対策のすべてです。
なお、論文については、「テクニカルエンジニア（システム管理）に楽々合格」を、かなり参考にさせていただきました。
[239] ss2004 (2009/05/10 Sun 20:41) web
昨年おかげ様でシステム管理に合格できた某氏です。
今日の情報処理はプロジェクトマネージャを受けてきました。
午後Ⅱの論文が合計2,200字以上が最低文字数になったので去年までよりは少し楽だったです。
ただ、9:30～16:30の長い試験時間は何度受けてもしんどいですね。
結果はまたご報告したいと思います。
[226] 某氏 (2009/04/19 Sun 22:44)
テストです。
ああ
わかり
[223] 管理者 (2009/02/14 Sat 23:06)
てすと中
[224] 管理者 (2009/02/14 Sat 23:11)
fadasにほんご
[225] 管理者 (2009/02/14 Sat 23:16)
管理人さん、こんばんは。
掲示板へのカキコ、ありがとうございます。さっそくリンクを張らせていただきました。
他愛もないページですが、私のホームページへもリンクを張っていただければ幸いです。
http://www10.plala.or.jp/sozo/tec/index.html
春はシステム監査技術者を受験予定ですが、今年から試験内容が大きく変わるみたいですね。
午後Ⅰの試験時間の見直しが入ったのがよかったです。（これまで何回か、時間不足で泣かされましたので。。。）
今後ともよろしくお願いします。
[221] そぞ (2009/01/14 Wed 02:52) web
すごく、読みやすくためになりました。
ぼくも論文がある上級シスアドを２度ほど受けたことがあるのですが、いつも論文で落ちていました。
すごく良いヒントがあったので、今年の試験に活用してみたいと思います。ありがとうございました。
[220] ケンハ (2009/01/13 Tue 23:47) web
お久しぶりです。
システム管理に続き、プロジェクトマネージャも合格する事ができました。
このサイトで学んだ論文の基礎が生かされたと考えております。
皆様との交流があってこその結果だと思います、本当にありがとうございました。
～～～～～～～～～～～～～～～～～～～～～
平成20年度 秋期
情報処理技術者試験 成績照会
プロジェクトマネージャ試験
受験番号 PM921 - 0xxx の方は，合格です。
午前試験のスコアは，695 点です。
午後I試験のスコアは，680 点です。
午後II試験の評価ランクは，A です。
～～～～～～～～～～～～～～～～～～～～～
[218] すぎエモン (2008/12/16 Tue 15:43)
すぎエモンさん
ご無沙汰しております。
合格おめでとうございます。PMはSMとは各段に難しい試験です。IT資格の最高峰といっても過言ではないでしょう。
すぎエモンさんの日頃の努力の賜物でしょう。
ご報告ありがとうございました。
今後ともこのサイトをよろしくお願いします。
[219] 管理者 (2008/12/17 Wed 00:44)
21年度秋に向けて、内容を充実させていきます。
一人でも多くの方が合格していただけるようにがんばります。
サイトへのご要望があれば、どんどん書き込みしてください。皆さまの”声”を大事にしていきます。
[217] 管理者 (2008/11/03 Mon 11:18)
管理人様、はじめまして。
こちらのサイトは会社の昼休みなどによく拝見させて頂きました。当初、論文試験は初めての受験ということもあり、敷居が高いと感じていました。しかし管理人様のシステム管理に対する考えを読んでいるうち、私でもいけるのではと大変勇気づけられました。
試験結果ですが合格でした。
午前 700
午後Ⅰ 600
午後Ⅱ A
受かりはしたものの、午後Ⅰはぎりぎりでした。午後Ⅱは３を選択したのですが、題意から少しずれた感じがしたので恐らくぎりぎりだと思います。管理人様のアドバイスにあった、頻出分野のネタをいくつかまとめておいたのが効いたと思います。そうでなければ2時間ではとても書ききれませんでした。
今後も本サイトの運営で一人でも多くの合格者がでることを祈っております。
ありがとうございました。
[212] non (2008/06/20 Fri 23:20)
管理人様
はじめまして。
無事、合格することが出来ました。
今回、初めてシステム管理を受けるにあたり、本サイトに出会ったことが、合格に繋がったと思います。
----------------------------------------
午前試験のスコアは，640 点です。
午後I試験のスコアは，645 点です。
午後II試験の評価ランクは，A です。
----------------------------------------
情報処理試験自体、10年ぶりでしたのでとにかく
午前中の過去問を解きまくりました。
本サイトの午前のページも参考にさせていただきました。
午後Ⅰ午後Ⅱは、どの参考書を読むより先に本サイトの「コツ」を熟読し、T○Cの論文添削＆模試で、弱点を克服していきました。
模試では午前がB判定で、かなりあせりましたが。。。
とにかく、殿のおっしゃる「素直になる」を心がけました。
秋はプロジェクトマネージャ合格を目指したいと思います。
ありがとうございました。
[210] zaki (2008/06/18 Wed 08:57)
昨年システム監査合格体験記を書かせていただいた某氏です。
システム管理ですが、何とか合格しておりました。
午前、午後Ⅰともギリギリのラインだったのですが、管理人さんの「システム管理者を意識する」というアドバイスや採点のおかげで午後Ⅱ突破できたと思います。
ありがとうございました！
-----------------------------------
午前試験のスコアは，645 点です。
午後I試験のスコアは，625 点です。
午後II試験の評価ランクは，A です。
-----------------------------------
次は秋は飛ばして来春に新制度のプロマネを受験しようかと思ってます。
その際はまたよろしくお願い致します。
[209] 某氏 (2008/06/17 Tue 23:21)
ハチです。お疲れ様です。
Ｈ２０春 不合格でした。
（成績）
午前： ６９０点
午後１：６３５点
午後２：Ｂ
やっぱり論文でダメでした・・・
何度も添削して頂いたのに、結果を出せずにすいません。
今回の勉強を通じてこの資格が、
まったく手の届かないモノではないと、感じることが出来ました。
次の試験で再チャレンジしようと思います。
ありがとうございました。
[200] ハチ (2008/06/16 Mon 11:19)
ヤマポンです。
私も、論文でダメでした。
午前 695点、午後1 625点、午後2 B でした。
論文の敗因は、システム管理者になり切れなかった点
だと考えています。
それと、題意に正直に答えられていなかった点も
マイナス要素と考えています。
管理人さんには、ご多忙中、何回も添削いただいたのに
申し訳ありませんでした。
次の試験で、リベンジしたいと思います。
[202] ヤマポン (2008/06/16 Mon 15:50)
まさやんです。
私も不合格でした。
精一杯やったので、悔いはありません。実力どおりといった感じです。
午前： ７４５点
午後１：５４０点
午後２：採点されず。
午前は、比較的とれたので、後は
午後１を解ける実力をつけることが課題です。
私も次の試験でリベンジします。
またよろしくお願いします。
[203] まさやん (2008/06/16 Mon 16:46)
午前試験のスコアは，685 点です。
午後I試験のスコアは，640 点です。
午後II試験の評価ランクは，B です。
午後１単純なミスが多かったので、論文採点
されてないつもりでした（汗
論文は字数足らずでしたので惜しいなぁと
今頃悔しく思います。
ギリギリのお忙しい中で色々評価していただいて
管理人さんには本当にお世話になりました。
次の２００９年秋のITサービスマネージャ試験で
リベンジしたいと思います。
またよろしくお願いいたします。
[208] aki (2008/06/16 Mon 22:56)
初めて投稿させて頂きます。
しんと言います。
こちらのサイトをいつも見させて頂いておりました。
論文に自信が無く、玉砕覚悟だったのですが
何とか合格することが出来ました。
---
午前試験のスコアは，650 点です。
午後I試験のスコアは，620 点です。
午後II試験の評価ランクは，A です。
---
午前は自己採点で39/55くらい。
午後Ⅰは80%くらい出来たつもりだったんですが、
ぎりぎりでした。
論文はとにかく手で書く練習が必要ですよね^^;
慣れていないと試験中に手が痛くて痛くて、、、
内容としてはみなさんがこちらで添削されている
ものに比べたらとても薄っぺらいものだと思って
いるのですが、(決して謙遜ではありません。)
システム管理の立場として書けたのが良かった
みたいです。
管理人さんどうもありがとうございました。
[207] しん (2008/06/16 Mon 22:30)
かんそくです。
合格でした～。
午前 695点
午後I 660点
午後II A
論文に無理があったような気がしましたが、
なんとかなってたようです。
管理人さんのご指導のおかげです。
ありがとうございました。
次はネットワーク頑張ります～。
[206] かんそく (2008/06/16 Mon 21:12)
皆様こんばんは
試験結果のご報告ありがとうございます。
合格の方もいれば、不合格の方もいらっしゃるので、私の気持ちは複雑です。
HPを通じて添削させていただきましたが、私の添削が適切ではなかったかもしれません。皆様の貴重なご意見は、しっかりと受け止めていきたいと思います。
試験は一発勝負ですから、厳しいですよね。たまたま体長がわるかったり、単純なミスをしてしまったり、といことがあります。多くの著書を書かれている先生方も、不合格は何度も経験されています。（勝率5割以上の先生は少ないと思います）
次の試験はちょっと先になりますが、良いご報告をいただけることを楽しみにしております。
[204] 管理者 (2008/06/16 Mon 19:49)
午後Ⅰは簡単なようですが、実は、無茶ボーダが高い気がします。自分自身２回目でしたが、これで、６２０程度？って、疑いたくなります。６５％から７０％はいかないと、６００乗らないんじゃないですかね？
[205] ＤＵＫＥ (2008/06/16 Mon 20:58)
平成20年度 テクニカルエンジニア（システム管理）試験
合格する事ができました。
自分の論文のレベルが低く、
途中で断念したつもりでしたが、
せっかく努力したんだから
胸を張って不合格になろうと考えていました。
～～～～～～～～～～～～～～～～～～
受験番号 SM921 - ???? の方は，合格です。
午前試験のスコアは，720 点です。
午後I試験のスコアは，615 点です。
午後II試験の評価ランクは，A です。
～～～～～～～～～～～～～～～～～～
ひとえにこのサイトで交流を深めた
皆様方のお陰だと思っております。
ありがとうございました
[201] すぎエモン (2008/06/16 Mon 11:32)
試験が終わって、徐々に解答速報が出てきましたね。
itecの午後２の講評を見ていてやられたと思いました。
（１）を選んだのですが、性能関連についての
SLA項目にフォーカスをあて、もろに性能対策に
尽力したことを書いてしまいました。
論文問題は「SLA遵守のためのプロセスで発生する問題」
および「問題の対処」を問われているので、
だめですね。。。
性能対策自体が、ここでいうプロセスであって
性能劣化が問題ではなく、性能対策中に何か
困ったことが発生した場合のそれが問題点という
ことですかね…
がっかりです。
[186] トゲ (2008/04/24 Thu 20:59)
合格しました。
パスワードなくしたので点数はわかりませんが…。
自己採点で午前は３８問正解でした。
たぶん、すれすれだったと思います。
午後１は自己採点では７割５分程度、
論文はNo.186で記載したとおりです。
[199] トゲ (2008/06/16 Mon 11:14)
私は２回目でした。
午前が、４１／５５なので、滑り込みかなと感じています。
午後Ⅰは、問１，３，４選択で、アイテック、ＴＡＣの解答より、約６０％～７０％位かなってところです。
去年は、６５％ぐらいかなって思ったら、５００前半だったので、選択の○をミスったか？キーワードが漏れているか？だと思います。
午後Ⅱは論文、外しました。問３でしたけど長期化より、障害対策に重点置いてしまった。午後Ⅰまで通過できれば御の字ですが、来年は秋か？って憂鬱な気持ちです。
[187] ＤＵＫＥ (2008/04/26 Sat 23:02)
こんにちは
試験お疲れ様でした。長丁場なので、本当に疲れますよね。
さて、ボーダなのですが、なんとも答えにくいですね。
情報処理試験に長く携わっている経験から申しますと、”書き方”と”難易度”でスコアが大きく変わります。
①書き方
正解だと思っていても、点数が悪いことがあります。私が生徒さんの添削をさせていただいた時の感想です。「この人、わかっているのに・・・でも必要なポイントが記載されていないから0点だなあ」
http://sm.xn--n9q36mh1hnxuksz7wt.net/archives/52440673.html
②難易度
簡単な問題の場合、スコアが伸びません。IRT的な評価をしているのかも。午後Ⅰが全くできなかったという人のスコアが、案外600を超えていたケースはたくさんあります。
システム管理は逆で、思ったよりスコアが悪いという方が多いです。
参考にならない意見かもしれませんが、コメントさせていただきました。
[188] 管理者 (2008/04/27 Sun 09:05)
昨年、酷いチョンボだったのかと、悲しかったのですが、とりあえず落ち着きました。ありがとうございます。
[189] ＤＵＫＥ (2008/04/27 Sun 15:55)
アイテックより、ＳＭについて、午前はＤＢの難度が高かったので、難易度が上がったとのことでした。
テクニカルＤＢ保持しているんで、一応、全部正解でした。ＤＢの問題が多かったので、助けられたと
いう認識のほうが強いです。ただ、ＩＲＴだと、やさしい問題が高得点だから、４１／５５でも６００点前半
程度と見ています。ＤＢなんか、４４／５４（一問チョンボがあった年）でも６００後半でしたからね。
午後Ⅰは、確かに、国語の試験ですね。じっくり読めれば解けるけど、時間がないから、見落としている
というイメージが強いです。
問１は甘めで、９０％近く取れているようですが、間違ったのは、設１（２）です。ＩＴＡＣ同様、
プログラムの世代戻しに食いついてしまった。
他は、線引いたところから、引用したレベルです。
リリース台帳云々とか、水曜日が一時間短いとか、どうにかヒットしました。
しかし、ここで、３０分使っちまったので、以降が慌てた。問３は、設問１（１）から、間違っちまったし、
設問２は、一つは「Ｓｏｒｒｙサーバのメッセージ出力回数」などと、書いちまった
（言いたいことは、業者の模範解答と同じイメージですけどね。）
し、もう一つは、全然はずれで、未だに答えが思い出せません。
問４は、ＤＢ保持者が、慌てちまって、設１（３）や設２は、アホなこと書いてしまった。
全体として、最低７０％は行けているようですが、システム管理は、広くて浅いというイメージが
強く、ボーダも高い気がしています。
管理人さんがおっしゃるように、論文の合格率が半分というのも、正解でしょう。
よほどのことがない限り、準備していれば、最低でもＣランクの相当上位には行くはずだと
思うからです。
午後Ⅰについては、毎度思いますが、２問を解く時間に３問やらされているような状況です。
知人に、小児マヒの男性がいるが、１種までは取れたけど、高度は受けていないそうです。
想像ですが、午後Ⅰが間に合わないのだろう。
（ＩＰＡによると、時間のハンデをつけることも可能らしいけど・・・）
もう少し、障害者の立場も考えてやるべきじゃないのかなとも思っている。
[191] ＤＵＫＥ (2008/04/28 Mon 23:30)
論文については、私も、長期化の原因より、障害対策を書いてしまったので、
よくても、Ｃランクかな？って気がしています。
午後Ⅰは、昨年５２０で、想像より、かなり低かったので、キーワードを
漏らしていたんでしょうかね。
今年も、業者の模範解答と同義のように見えるんですが、案外駄目かもしれません。
ＴＡＣさんの配点については、毎回、各種目とも、論述のウェイトがイマイチ
軽いような気がします。（今までの調査に基づいているとは思いますけどね）
「論文まで行ってくれ！論文を評価してくれ！」が今の気持ちです。
（合格させてくれ！が本音だけど、こんなに外したんだからと、とっくにあきらめています。）
Ｂ以下だとしても、論文の評価を見て、今後の対策を検討したいと思います。
秋の準備については、既に始めましたが、種目は、もう７回目くらいのＮＷです。
今度こそ、合格したいと思います。
ＤＢを保持しているんで、ＮＷ取れたら、両手に花です。
（両方保持している方は、仲間うちでも、かなり評価が高いですからね。）
今年合格しないと、来年秋は、今のＮＷ相当か、システム管理相当のバッティングですからね。
（システム管理に行き着きそうですが・・・）
春は、何受けようかしらん？セキュリティが有力ですが、この際、監査に
挑戦するのもいいかも・・・
[194] ＤＵＫＥ (2008/05/08 Thu 23:43)
ＤＵＫＥさん
こんばんは
書き込みありがとうございます。
いくつかコメントします。
・合格発表までは、複雑な心境ですよね。「あー、あそこを間違えなければ」とか「ああ書いていれば」とか、色々思います。
・この試験は秋に移動するため、次は１年半後ですね。これって長いですよね。
・NWとDBをダブルで持っている人は、少ないです。評価が高いと思いますよ。私も、NW受かって４年後にDBを受かりましたが、「資格はこれで十分」と思いました。
・来年の春ですが、、、私も受けるものがあまりありません。受かりそうな試験もほとんど皆無です。秋は、NWをもう一回受けたり、SMをもう一回受けたりしたいと思ってます。
また、遊びに来てください。
[195] 管理者 (2008/05/09 Fri 21:23)
模範解答出ましたけど、何となく、素直じゃないなぁって、気がします。毎度のことですけどね。
＜問１＞
設問１（１）①なんか、確かにそのとおりだけど、原因究明が遅れたからじゃないの？
理由の解釈が、非常に曖昧だと思います。
「２回も、同じチェックやったから遅れた。」みたいな旨、書いたので、多分ペケ。
原因究明のやり方のほうに、問題があるとしか、思えなかったですけどね。
＜問３＞
設問１（２）なんか、業者同様、「毎月再編成に変更する」旨書いたが、模範解答は、
「サイクル短くする」って、そのとおりだけど、なんか具体性がない。
問題文の前提条件が、曖昧だから、毎月と特定できないと判断したのだろうか？
（半年とか、数ヶ月おきとか、書いたのがいるのだろうか？）
テクニカルＤＢ保持者の私としては、「毎月やったほうがいい」に決まっている。
何のため、毎月メンテやってんの？
＜問４＞
設問３（２）「使用されていない」って、いうより、そもそも、新規ＤＢは「接続されていない」から、
「使用できない」んじゃないの？
「現行ＤＢが接続されていて、新規ＤＢは、切り離されているため。」なんじゃないの？
本設問の模範解答が、一番、理解不能だ。
全般、キーワード（「単位時間あたり」等）の漏れがあったので、
午後Ⅰ通過は、厳しくなりました。解釈誤ったところとか、キーワードの漏れとかは、
反省要だけど、だいたい、時間に追われるから、多少はやむをえない気もしている。
（高度の午後Ⅰは、だいたい、そういう傾向がある。）
通過したところで、論文チャチだし、１年半後にリベンジだな。
来年春は、システム監査に挑戦しようかな？
[196] ＤＵＫＥ (2008/06/04 Wed 22:43)
問１については、設問１（１）②もおかしい。「８時までに」って、明示しなければ、ＳＬＡは守れないはず。今ごろ、模範解答出すのに、なぜブラッシュアップしないのか、不思議。
[197] ＤＵＫＥ (2008/06/06 Fri 23:27)
不合格です。
午前試験のスコアは，660 点です。
午後I試験のスコアは，620 点です。
午後II試験の評価ランクは，B です。
ううむ、あの論文ではやはり駄目だった。
秋は、ＳＭの後ガマを受けることにします。
惜しいような、却って最悪なような気がします。
午後Ⅰのボーダが非常に高いですね。６００点
前半なんて、思いもしなかった。午後Ⅰから、しっかり
やらないと駄目ですね。
[198] ＤＵＫＥ (2008/06/16 Mon 11:10)
こんにちわ。初投稿です！
午前 45/55
午後１ 65%～75% (1,2,3)
午後２ ↓です。
障害の長期化対策というより、障害対策的な論文になってしまった感があります。
強引に連絡（＝障害検知）・連携（＝ベンダーへの情報提供効率化・ユーザへの広報）・
想定外に事態代替策（＝部品の冗長化）で逃げましたつもりですが、なんか…変。
さらに言うと、２－１は原因視点と原因を分けずに記述した点はまずったなぁ・・・
ここで、障害対策的な論文へと進みだしたような気がします。
まとめ3章で2日の長期停止に対して、今は停止してませんってかいたら、長期化を短期化に
出来たって言えてない気がするが。
【問題】
問３ システム障害の長時間化の防止策について
システム障害が想定を超えて長時間化した場合、それによる損失は甚大なものとなる
ことがある。このことから、システム管理エンジニアは、できる限り短い時間でシステ
ム障害から復旧できるように、長時間化の防止策を講じる必要がある。
例えば、システム障害が長時間化した場合は、対応の経過を整理した上で、次のよう
な視点から長時間化した原因を究明し、防止策を立案・実施する。
（１）連絡は適切な時間内に実施できたか
例えば、障害検知の遅れや、連絡不備による初動の遅れはなかったか。
（２）情報は適切に収集できたか
例えば、スキル不足や手順・体制の不備で情報が混乱することはなかったか。
（３）手順は適切であったか
例えば、並行して実施できる作業はなかったか。
（４）想定外の事態に適切に対応できたか
例えば、修理部品の到着の遅れに対し、代替策はとれなかったか。
（５）部門間の連携は適切であったか
例えば、開発部門との間で、復旧方法の確認に手間取ることはなかったか。
原因の究明や防止策の立案に当たっては、運用部門だけでなく、開発部門や利用部門
などの有識者を交えたレビューも有効である。
あなたの経験に基づいて、設問ア～ウに従って論述せよ。
設問ア あなたが携わった情報システムの概要と、長時間化したシステム障害の内容及
び業務への影響について、８００字以内で述べよ。
設問イ 設問アで述べたシステム障害について、長時間化した原因をどのような視点か
ら究明したか。また、長時間化した原因は何であったか。それぞれ具体的に述べ
よ。さらに、立案・実施した防止策について、工夫した点を中心に具体的に述べ
よ。
設問ウ 設問イで述べた防止策について、どのように評価しているか。今後の課題は何
か。それぞれ簡潔に述べよ。
第一章 私が携わった情報システムの概要と長期化したシステム障害の内容と業務への影響
１－１ 私が携わった情報システムの概要
現在、私は製造業を営むA社にてOAシステムの運用管理に携わっている。
当システムは、ネットワーク上のユーザ情報やコンピュータ・ファイル情報を一元管理できるものである。
当システムに登録されたユーザは認証処理を経て、ファイル情報などにアクセス可能となる。
ユーザは、当システムを主に業務で使用するファイルの共有する場として活用している。
ユーザ数・コンピュータ数はともに5000程度である。
当システムを搭載したサーバは拠点10箇所に分散配置されている。拠点によって24時間稼動であることから
システムにおいても、原則24時間常時稼動の体制で運用を行っている。
私は、当システムの情報の登録や削除また、機器管理などの運用管理を行っている。担当者は3名で
必要があれば、拠点サーバへは遠隔操作で保守作業をおこなう。
１－２ 長期化したシステム障害の内容と業務への影響
当システムは、業務で使用するファイルを保存している為、システムが停止した場合は多大な損害が発生する。
製造業の当社では、物流において配送の停止・販売において販売の停止が発生し、致命的な問題となる。
また、人事データなども扱えなくなることから、本社機能も停止することになる。
障害について、当システムは大容量のHDDを搭載してはいるが、大容量の業務ファイルを保存していることによって、
HDDの枯渇が発生した。枯渇により、新規データの保存や更新不可の問題が発生した。
また、同時期、HDDの障害は発生してシステムダウンとなり、サービス停止となり全体の復旧に2日の間費やすことになった。
我々、運用担当者は、このような障害を未然に防ぎ、また障害発生時は極力停止時間を短縮するように
取り組まなければいけない。
（780文字くらいだった気がする。）
第二章 システム障害の長時間化した原因究明の視点と解決策について
２－１ システム障害の長時間化した原因究明の視点について
当システムの問題は２つに分けて考える必要がある。
（１）HDD枯渇の問題について
HDD枯渇の問題は、ユーザに対して自由に使用を許可して枯渇状態となっってしまった。
HDDの枯渇状態となってから増設の対応をしてしまった為、2日の停止となってしまった。
そこで、デスクの使用率を監視していれば、枯渇となる前に検知して対策を行うことが出来た。
また、使用状況をユーザへ広報する場があれば、不要ファイルの削除やデータの圧縮を行ってもらうことも可能であった。
（２）HDDの障害の問題について
（**** このから記憶があまりない ****）
原因については
・パーツの故障
・CEの連絡が遅くなった
視点については、
・障害がおきた時、検知できるようすれば、早急に対応可能
・障害がおきることを前提にした冗長構成を採用していれば、障害時もサービス維持してその間に保守可能。
（活性保守可能）
的なことを書いた。
（**** ここまで ****）
２－２ 障害長期化の解決策
（１）HDD枯渇の問題の解決策
当問題については、ツールを導入して、1時間の間隔でHDD使用率を取得するようにした。
取得した情報は、管理コンソール上に一元管理され、拠点・使用率を一画面上に表示できる。
使用率90％を超える拠点は、赤文字で目立たせる仕様である。また、異常時はメール通知を管理者へ発信する。
さらに、取得した情報はイントラへ掲載することで、ユーザが使用率の閲覧可能となった、
この事で、枯渇となる前に、ユーザ自身は不要ファイルの削除や圧縮を行い、
管理者はデスクの増設なども余裕をもって行うことが出来る。
なお、当ツールは当社で導入実績のあるものであり、導入時に時間を費やさずに導入できた。
（２）HDDの障害の問題の解決策
当問題について、パーツの故障は回避できない。特に当システムは読み書きが多いため、HDDの劣化に注意しなくてはいけない。
そこで、冗長構成を採用した、メモリ・CPI・電源などには冗長構成を採用して、特に気にしなくてはいけないHDDについては、
RAID５＋ホットスペア1本の二重の冗長化を行った。また、ツールを導入した。
当ツールは、障害時には情報を管理コンソールへ届ける。管理コンソール上では、異常時には赤文字で目立たせる仕様である。
また、当ツールにおいてもメール機能を持ち、異常時はメールは担当者へ配信する。また、ベンダーサポートへ情報を届ける。
このことで、障害を早急に検知するとともに、障害時は冗長化によりシステムの停止を回避出来る。
また、ベンダーサポートへ連絡も効率的に行え、早急にCEの手配を行える。そして、部品交換は活性保守で行える。
なお、当ツールはすべての機器で同一ベンダーだったこともあり、無償で導入することができ初期投資を抑えることが出来た。
（第二章は、1300文字強だった気がする）
第三章 防止策の評価と今後の課題
（～簡略～）
３－１ 防止策の評価
HDD枯渇の問題の解決策については、対策前は2日の間停止してしまったことがあったが、
対策後、枯渇前に対策を行えてる。ユーザは不要ファイルを削除してくれている。
だから、停止は起きていない。
検知の早急化やユーザが削除してくれて、管理の軽減化が出来ている。
HDDの障害の問題の解決策は、2日停止していた事があったが、障害時も冗長化のおかげで
停止していない。また、CEを早急に手配可能。活性保守で停止しないで回復可能。
検知の早急化と情報連携の効率化。
全体的に検知の早急化と運用負荷の軽減化を行えている。自分も評価できる。
３－２ 今後の課題
今後は、現在の担当者が移動などに備え、対策を行ったところなどについてマニュアル作成を行う。
注意しなくてはいけないところは、スキルレベルよって、判断を必要とするようなマニュアルではないものを
にして、復旧手順や、今回の変更点などを洗い出し作成する。
（第3章は750文字くらいだった）
[193] なんだかなぁ (2008/05/05 Mon 14:34)
こんにちは。
試験が終わって、風邪を引いてしまいました。
６月１６日の合格発表までの間、皆さんはどうやってすごしていますか。というのも、試験が終わって、ちょっと気が抜けた生活になっています。個人的にはOracleMasterでも６月までに受験しようかと。その後、秋に別の情報処理技術者試験を受けようかなどど考えていますが。ただ、まだ気合が入りませんが。。。差し支えなければ、みなさんの今後の目標など教えてください。
[190] まさやん (2008/04/28 Mon 16:59)
こんにちは
試験が終わると気が緩んでしまいました。ネットサーフィンばかりしています。まさやんさんの記事を読んで、共感しました。秋試験を今からやる気はしません。がんばれない。
今の期間の使い方として、試験勉強期間にはできない勉強をしたいと思います。私はサーバの構築経験が少ないので、メールサーバやWWWサーバなどを構築し、基礎を勉強したいです。それが実務や試験対策につながると思います。
他の皆さんはどうですか。教えてください。
[192] みんと (2008/04/29 Tue 07:51)
はじめまして。ずっとこのサイトでみんさんのがんばっている姿に励まされ、こつこつ勉強してシステム管理を受けました。管理人様や、がんばられた皆さんに感謝したいと思います。
昨日の感想を少々。
午前の試験ですが、私が受験した会場では、みな早々に解答を書き上げて、試験が終了する前にほとんどが出て行ってしまいました。焦りましたが、私は自信がなかったので、最後まで残りました。
結果は、４９問正解することができました。
しかし、午後１は時間がない中で苦しい解答になってしまい、まるっきりだめでした。
みなさんは時間がない中で、どうやってあの難問を解いていらしゃるのでしょうか？問題を読むだけでも、１０分以上かかってしまいます。そこから設問を解く際にも、何度も設問を読み返すので、とても３０分以内では終わりません。
普段の仕事の中で、文章を早く読み、まとめあげる力を養うのが基本だとは思うのですが、問題を解く上でなにかアドバイスがありましたら聞かせていただけないでしょうか。よろしくお願いします。
[176] まさやん (2008/04/21 Mon 17:29)
あくまで私個人の午後I攻略法ですが「設問から先に読む」です。
文章は読む必要の無い内容が多いので、設問に回答するために必要そうな部分だけ読むようにしています。
もちろんデメリットもありますが・・・。
今回の試験だと問１の水曜日と土曜日がどうこうと言ったくだりを見落としそうになりました。
ですがそれ以上に時間が節約できるというメリットは大きいと私は思います。
別のテクニカルエンジニア試験ですが、この方法で挑んだところ2連続で失敗していた午後Iの試験が700点オーバーで合格できました。
万人にお勧めできるものではありませんが参考程度に。。。
[178] こま (2008/04/21 Mon 22:44)
まさやんさん こんにちは
試験お疲れ様でした
>問題を読むだけでも、１０分以上かかってしまい
>ます。そこから設問を解く際にも、何度も設問を
>読み返すので、とても３０分以内では終わりません。
難しい問題の場合、まさやんさんだけでなく皆さん時間がたりません。それほどご心配される必要はないと思いますが。
一つアドバイスです。私は監査を受け、問１がメチャクチャ難しくて、答えが分かりませんでした。あせればあせるほど設問と問題を中途半端に何往復もする状態に陥っていました。
こんなときに有効なのは、図に落とすことです。問題文を読みながら、各システムを図示し、運用をフロー化していきます。すると、頭の中が整理されるので、問題点やポイントがはっきりしてきます。
「時間が無いのに、図に落としていたら余計に時間がかかる」と思われたら、それは逆です。時間がないからこそ頭の中をきちんと整理する、それが時間短縮につながります。
一度お試しください。
また、問題文を読むときにポイントをマークしておくことも有効です。マークするのは、違和感があるところ（この文章が無くても成り立つ）、運用がどう見てもおかしいところ、など。マークしたところをそのまま引用すれば答えになることが多々あります。
[179] 管理者 (2008/04/22 Tue 04:01)
やまぽんです。
個人的な意見ですが、システム管理の午後１自体は
他の高度試験に比較すると問題自体は容易と思います。
その反面、パスするには高得点が必要と思います。
私の午後１の攻略方ですが、問題文を何回も読むと時間が不足するので、設問と関連付けて読んでいます。
具体的には、問題の最初の前提部分を読み、ポイント思われる部分にアンダーラインを引きます。
その後、問題を読み進み、途中で設問１を見ます。
設問１の解答後、設問２の部分に取り掛かります。
問題文の段落と設問は、多くの場合、順序が合っていますので、この方法で、切り抜けています。
問題文の段落がどの設問にも関連していない場合は
間違っている可能性があると思い、見直しをしています。
問題文の最初の前提部分をポイントを上手く抑えることが、重要で短時間で解答するコツと思います。
ご参考までに・・・
[180] やまぽん (2008/04/22 Tue 06:33)
ハチです。
他の方々も書かれているように、みなさん時間は足らないのです。
結果的にまさやんさんは、すべての回答を埋めることができたのでしょうか？
自分は時間が足らなくなったら、カンでも良いからすべて埋めること を目標にしてました。
割り切りも大切だと思います。
[181] ハチ (2008/04/22 Tue 07:31)
私も今回の試験は、やや時間が足りず、全ての問題を解くことができませんでした。いろいろテクニックはあると思いますが、今回の試験は過去問を解かないと無理だなと思いました。午後１の問題は、いろんな解がある場合があり、いろいろ検討しないと答えが出ないので、時間が足りなくなるのが当たり前です。この時間で解くには、どうしても充分な量を過去問を繰り返し解き、答えがすぐに思い浮かぶようにしておく必要があると思います。または、実務経験を積むことだと思います。
[182] 流星パピー (2008/04/22 Tue 09:28)
こまさん、管理人さん、やまぽんさん、ハチさん、流星パピーさん
ご回答ありがとうございます。こんなに多くの方にアドバイスいただいて、感動です。
今までも、疑問があったら書き込みをしておけばよかったと、今更ながら後悔しています。
こまさん、ありがとうございます。
「設問から先に読む」「設問に関係しそうなところ、部分だけを読む」
別のテクニカルエンジニア試験で、７００点オーバーはすごいです。
重要な点を読み飛ばす可能性があるが、時間短縮のメリットがあるということですね。
了解しました。
管理人さん、ありがとうございます。
「各システムを図示し、運用をフロー化する」
「違和感があるところをマークする」
とても参考になります。図示とフロー化。一度やってみます。
これができるようになると、確かに頭が整理されますよね。
今年私の中で、最も難しかったのは、午後１の問４です。頭の中で整理が出来ていませんでした。
自分なりに図示とフロー化してみます。
やまぽんさん、ありがとうございます。
「問題文の最初の前提部分のポイントを上手く抑える」
「問題文を設問と関連付けて読む」
問題の読み進め方も具体的で、たいへん参考になりました。。
ハチさん、ありがとうございます。
とにかく、すべて回答はうめてきました。合っている自信は全くありませんが。
とにかくうめて、部分点だけでも貰えればと思ってうめました。
時間がないのは、みなさんいっしょなのですね。
その中で、割り切ったり、工夫した読み方をされたりしているのですね。
流星パピーさん、ありがとうございます。
「過去門を多く解く。」「実務経験を積む。」
やはり、基本ですね。日ごろからの努力で力を養うということですね。
みなさん、アドバイスありがとうございました。
私は高度情報処理を受けたのは、これが初めてでした。
春の試験は終わりましたが、今からが始まりです。秋にも別の試験を受けたいと思います。
また、皆さんのがんばっている姿を励みに、私もがんばりたいと思います。
[183] まさやん (2008/04/22 Tue 18:27)
はじめまして、かんそくです。
システム管理試験お疲れ様でした。
午後Ⅰは問２、３、４を選択しましたが１０分ほど時間が余りました。
途中いい加減に書いた設問もあったので、もっとじっくり時間を使えばよかったです。
でも問１を選択から外したのは良かったのかな。
システム管理は初受験ですが、午後Ⅰについてアドバイスを～。
午後Ⅰの問題構成は次のようになってます。
・本文(始めから設問の前まで)は時間経過に沿って記述されている
・設問は見出しの段落と対応して出題される
各設問には文中の中括弧で囲われた見出しと対応させて、
「〔ID管理とID登録申請プロセス〕について(1)(2)に答えよ」
みたいに記載されてます。
そしてこれが大事だと思いますが、
設問は、始めの概要からその見出しまでの記述で解けるようになってます。
例えば今回平成２０年の問２設問１なら、
・最初の概要
・〔注文システムの利用方法〕
・〔ID管理とID登録申請プロセス〕
の範囲で解答できます。
ですので、
①本文を概要から設問１の見出しまで読んで解答。
②また本文続きを設問２の見出しまで読んで解答。
の繰り返しで効率良く読解ができると思います。
あと、まれに設問の見出しの順番が入れ替わってるときがありますが、
本文の順に設問を飛ばしてやるのが良いです。
以上、参考になりましたでしょうか。
[184] かんそく (2008/04/22 Tue 21:58)
かんぞくさん、ありがとうございます。
＞設問は、始めの概要からその見出しまでの記述で解けるようになってます。
＞①本文を概要から設問１の見出しまで読んで解答。
＞②また本文続きを設問２の見出しまで読んで解答。
＞の繰り返しで効率良く読解ができると思います。
なるほど。
具体的でたいへん参考になります。
ほんとに、もっと早い段階で質問を書き込めばよかったと、後悔するばかりです。
[185] まさやん (2008/04/23 Wed 11:05)