あけましておめでとうございます。
昨年はＰＭもＳＭも、午後１で落とされる。
ＳＭにいたっては２点に泣く、
散々な結果となってしまったことが残念です。
今年は、子供がうまれてくるので、
まとまった勉強時間をとることが、
困難になってくるだろうと考えています。
同じ境遇の経験をされて、なおかつ合格された方。
「こんな勉強方法はいかがでしょう？（合格体験記）」
お願いします。（笑）
さて、散々なＳＭの試験だったのですが、
試験当日、酒を飲みに気分を一新して家に帰る
というのが、通常でしたが、
昨年は妊娠中の妻もいたため、酒も飲まず家にすぐに帰りました。
そして、「復元論文」を作っていました。。。。（笑汗
採点者には読まれず、評価されなかった論文なので、
全く価値はありませんが、今年の春のＰＭと秋のＳＭに再挑戦するため、
私の論文を、いろいろと評価していただこうかと考えました。
正月早々に気分を一新して、今年はいい一年だったと
笑いたいので、みなさんよろしくお願いいたします。
====================================================
平成２１年度 問３ 事前予防的な問題管理について
１． 私が携わったＩＴサービスの概要と、分析して判
明したインシデントの発生の傾向や頻度について
１．１ 私が携わったＩＴサービスの概要について
私は旅行会社Ａ社に勤務している。情報システム部の
システム運用担当に所属し、自社システムの保守運用業
務に従事してきた。今回、論述するＩＴサービスは旅行
予約販売システムについてである。
Ａ社は大阪に本社があり、全国50店舗の営業店がある。
本社にはセンタがあり旅行予約販売システムの業務サー
バとＤＢサーバが設置されている。営業店は毎日9時か
ら20時まで営業しており、来店される顧客に対して、専
用業務ＰＣを用いて旅行の予約販売業務を遂行している。
センタと営業店は広域イーサ網で接続されている。ま
た、センタには本システムを監視するための監視システ
ムと、営業店からの問い合わせに対応するためのヘルプ
デスクが設けられている。
１．２ 分析して判明したインシデントの発生の傾向や
頻度について
提供サービスに潜在する問題の発見と対策を行う事前
予防的な問題管理は重要であると私は考える。
ある日、ヘルプデスクに対して営業店ユーザから、予
約処理に時間がかかりすぎ、顧客対応において業務に支
障が出てきている。という申告を受けた。申告は１店舗
だけでなく複数の店舗からも受けるようになってきた。
詳細には日曜日14時から16時に発生しているようであり、
監視システムにおいて、業務サーバのＣＰＵ使用率のし
きい値超えが申告時間帯に多く発生していた。
今まではサーバのＣＰＵしきい値超えについては、あ
る程度時間が経てば治まる傾向にあった。そのため経過
を見ることにしていたが、明らかに発生件数が多く今ま
での２倍近い件数が発生していた。私は早急に適切な対
応を行うことが必要であると考えた。
２． インシデントの発生の傾向や頻度に対する考察お
よび潜在する問題の発見と、発見した問題を解決す
るために実施した対策について
２．１ インシデントの発生の傾向や頻度に対する考察
および潜在する問題の発見について
私は業務サーバのＣＰＵ使用率のしきい値超えのイン
シデントがなぜ増加したのかについて、以下のような仮
説を立てて検証することにした。
●業務サーバのＣＰＵ使用率が増加するような、リリー
スの実施がされており、そのリリースが影響を与えて
いないかどうか。
Ａ社では定期的に新しい旅行商品を企画し、それに対
応するように業務サーバおよびＤＢサーバへのリリース
が実施されている。リリースの頻度としては月に１回程
度である。
これらのリリースが影響を与えるようなことが無かっ
たか検証するにあたり、リリース台帳においてリリース
内容の確認、各サーバのログの確認、監視システムのア
ラーム状況の確認を実施した。結果、オリンピックにち
なんだ旅行商品を企画しリリースした直後に発生してい
ることが分かった。日曜日に発生していたのも営業店へ
の来客数が急増していることが起因していた。
私は、なぜリリース直後にＣＰＵ使用率が増加し、営
業店での予約処理業務へのレスポンスが悪化するような
ことになってしまったのか、次のような仮説をさらに立
てて検証することにした。
●予想していたトラヒックが、今までのリリース時にお
けるトラヒック増であると予想してサーバ処理能力の
検討してしまったからではないか。
リリース時におけるトラヒック増は予想していたもの
の、現時点での業務サーバの処理能力を超えるようなト
ラヒックにならないであろうと、過去の実績トラヒック
から算出していたことが検証の結果分かった。
２．１ 発見した問題を解決するために実施した対策に
ついて
私は国際的なイベントがからんだ旅行商品や、特別な
キャンペーンを企画した旅行商品については、今までの
実績トラヒックよりも多く発生することがあると認識す
るとともに、今回においては高トラヒックを予想した特
別な対応が必要であろうと考えた。
リリース内容を把握し高トラヒックが予想されるリリ
ース内容については、業務サーバの処理能力に問題が無
いか検討する事が重要であると考えた。今回においては、
予備機を用いて業務サーバ２台を増設する対応を行い対
策を実施した。
３． 事前予防的な問題を定着させるために行った取り
組みと、今後改善すべき点について
仮説と検証を繰り返すことにより考察を深め、提供す
るサービスに潜在する問題を発見し、適切な対策を実施
する事は重要であると私は考える。また、事前予防的な
問題管理を定着するさせることも、ＩＴサービスマネー
ジャとして重要な営みであると私は考える。
私は事前予防的な問題管理を定着させるため、インシ
デントの件数が基準値を超えた場合に分析を義務付ける
こととした。今回のインシデントを一例を書くと、15分
内に業務サーバのＣＰＵの使用率が３回、監視システム
にてアラーム検知をした際に分析を行うこととした。こ
の15分内に３回という基準値において、今回のインシデ
ントの実績をベースに基準値を設定した。
分析においては、基本的に情報システム部のシステム
運用担当者にて実施することとしているが、分析を行う
過程には商品企画部門や開発部門、営業店などの関係者
の協力が必要であると私は考えた。関係者に今回のイン
シデント内容を踏まえ、事前予防的な問題管理の実施が
いかに重要な行動であるかを十分に説明し、関係者から
理解と協力を得る約束をすることができた。
今後改善すべき点としては、分析し発見した問題に対
して適切な対策が実施できているかについての検証を行
っていくことであると私は考える。分析、仮説立てと検
証、問題の発見、対策の実施、対策の検証のプロセスを
サイクルさせ、よりよい分析と対策の実施を行っていく
ことが重要である。
また、優れた分析、対策の実施者については表彰する
取り組みを行い、システム運用担当者のモチベーション
を上げて実施していくことも重要であると考える。
以上
[351] ショウ (2010/01/02 Sat 17:59)
はじめまして。
私も午後IIは問3を選択しましたので、コメントさせて頂きます。
自分の論文の突っ込み以外に添削などした事はありませんので、気になった点のみ書かせて頂きます。
【1.1】
「こんなシステムをこういうSLAで運用・提供している」と記述して初めて「ITサービスの概要」に
なると考えます。少なくとも論述するインシデントについてのSLAは具体的に記載すべきです。
後述しますが、インシデントの定義が曖昧だと採点に弊害が生じます。
【1.2】
業務に影響を与えるインシデントに対し、経過を見る、という対応は現実的とは思えません。
CPU使用率の閾値超え自体はインシデントではないとも取れますが、SLAの記載がないため判断できません。
今までは経過を見ていたのに頻度が2倍になったら早急に対応しなければならない理由も不明です。
この節ではインシデントの発生傾向が分かれば良いので最後の1文は不要です。
明らかに対応しなければならない問題となると、事前予防ではなく事後対応となり題意から外れます。
【2.1】
要は「プログラムの性能が半分になった」という仮説ですが、これを一発で当てるのは少々不自然です。
今までもCPU使用率の閾値超えは発生していたのですから、頻度が2倍になったのであれば「顧客が急増した」
という仮説が挙がる方が自然です。「オリンピック」というイベントも顧客急増を示唆するものですし。
仮説は複数立てた方が題意に沿う形になりますので、上記も踏まえ、仮説は「プログラム不備」と
「顧客急増」、「その他」の3つを挙げ、前者2つが正しかった、という内容が良いと思います。
または、顧客は急増したが、顧客増加量より予想される頻度よりも多く閾値超えが発生し、調査したところ
プログラムの不備が判明した、という流れも良いと思います。後者はより題意に沿っている内容になります。
【2.2】
予備機というと、通常本番機がダウンした場合等に使用するものと考えます。データ同期の方法なども
ありため本番機の負荷が高くなったからといって簡単に稼動できるものではないはずです。
逆にそれを想定しての予備機なら、CPU使用率の閾値を超えた時点で稼動することが運用手順によって定め
られているはずですので、不自然 or 記述不足な感じを受けます。
【全体】
直近のリリースによって発生した問題に（事後）対応した、という印象を受けますので、少々題意から
外れているように思います。「潜在的な問題」を強く意識した構成と流れにすれば、A評価になると思います。
[352] hok (2010/01/03 Sun 02:00)
hokさん
コメントありがとうございます。
今後の勉強に生かしたいと思います。
[353] ショウ (2010/01/03 Sun 23:49)
どうも、かんそくです。
前半は良いのですが、
「２．２ 発見した問題を解決するために実施した対策について」
以降に問題があります。
私の評価ではＢです。
１．トラヒックでなくトランザクション
ネットワークに限定した障害でなくサーバ処理も関係するので、
問題にある通りトランザクションが適切でしょう。
これはキーワードなので外すとマイナスです。
２．今回発生した障害の原因と対策、および事前予防策
障害の原因
「２．２」の記述ではわかりにくいです。
まず「業務サーバの処理能力が不足していた。」
障害の原因の具体的な記述が必要です。
それからこの原因から、大きく論旨展開として、
「原因→対策→事前予防策」となるべきです。
対策
・業務サーバを２台増設
唐突にサーバを増設しているように読めました。
なぜサーバ増設したのか、検討案も併記するとよいのでは。
（プログラム改修も検討したが工数が大となるため止めた等）
事前予防策
・業務サーバの処理能力についての事前予防策
ここは設問ウに記述して下さい。
新商品が来ても同じテツは踏みませんよというのが大事ですね。
（あらかじめ企画部より人気商品販売に関する情報を受け、
システム運用部にてスケーラビリティを判断し、
サーバ増設を実施するような体制を取りまとめた等 ）
以上、コメント＆添削です。
試験はまた次回頑張りましょう！
[354] かんそく (2010/01/04 Mon 15:11)
すぎエモンです。僭越ですがコメントさせて頂きます。
【良いと感じた点】
・「１．１ 私が携わったＩＴサービスの概要について」
については、記述が簡潔で明快であり、分かりやすい印象を受けました。
短い文章で担当システムの説明が上手になされていると思います。
・挙げられている問題がＣＰＵのしきい値越えの事例であり、問題文の
例と一致しています。これは問題文への準拠性を高める工夫であると
思われ、上手いやり方です。
・自分の考えを自分勝手な主観でなく、問題文から抜き出した点が良いと
感じます。これにより問題文への準拠性が高くなっています。
・文章を２度３度と読み直すポイントが殆どありませんでした。
飲み込みやすい文章であり、素晴らしいと思います。
・「オリンピックにちなんだ旅行商品」というのは面白いですね。
独自性を感じます。
【気になった点】
・今回の論文の主旨は、「事前予防的な問題管理」であるため、
「問題が顕在化する前に対策を行った」事が必要であると
出題者が認識している可能性があります。
この場合、「営業店ユーザからの指摘で問題点に気付いた」という
記述は危険です。論旨から外れていると見なされる可能性があります。
ここは、問題文に従い、運用部門がＣＰＵしきい値越えのインシデントが
増えたことを問題点のトリガーとして、顧客には障害が発見されていない
設定とした方が無難だと思います。
・ＣＰＵのしきい値は、重要なＳＬＡになるので、前半部分で数値を明記
しておいた方がよいのではないでしょうか？
・以下の２点の仮説は、完全に問題に準拠させるため、いっそのこと
完全に問題文と同じ記述にした方が問題準拠性が増すのではないでしょうか？
（原文）
●業務サーバのＣＰＵ使用率が増加するような、リリー
スの実施がされており、そのリリースが影響を与えて
いないかどうか。
●予想していたトラヒックが、今までのリリース時にお
けるトラヒック増であると予想してサーバ処理能力の
検討してしまったからではないか。
（問題文に合わせて変更）
●トランザクションの変化はないか、特定のトランザクションは増えていないか
●プログラムの変更は無かったか、そのプログラムがＣＰＵを占有していないか
・「３．事前予防的な問題を定着させるために行った取り組みと、今後改善すべ
き点について」の部分については、以下のように項目分けして、
丁寧に設問に答えた方が合格率が向上するのではないかと考えます。
３．問題管理定着の取り組みと改善すべき点
３．１事前予防的な問題を定着させるために行った取り組み
３．２今後改善すべき点
【私の評価】
Ａではありませんが、高く評価しています。
Ａでないポイントは、問題が顕在化した後に対策を行っている点が
題意から外れている可能性があるからです。
全体的な論文記述が、読みやすく秀逸です。論文が論旨に沿ってさえ
いれば、容易に評価Ａを獲得できそうな論文作成技術であると感じました。
[355] すぎエモン (2010/01/04 Mon 17:51) mail
かんそくさん、すぎエモンさん
コメントありがとうございました。
問題に気付いた点をユーザからの指摘にしたところは、
確かに題意から外れていると見なされる内容ですね。。。。
hokさんからもコメントがありましたが、
「事後対応」になっているという部分がまずいですね。
勉強になります。
ちなみにですが、今回のＳＭにしても、昨年のＰＭにしても
私の場合は、１．１の「システム概要（ＳＭ時）」「 プロジェクト概要（ＰＭ時）」は、
どのような問題がきても、全く同じ４００文字を書いてしまうのですが、
特に問題ありませんでしょうか？
[358] ショウ (2010/01/07 Thu 01:10) mail
お疲れさまです。すぎエモンです。
「システム概要（ＳＭ時）」と「 プロジェクト概要（ＰＭ時）」は別に書くべきだと
私は考えております。…といいますか、私はＳＭとＰＭの合格時論文では別物として
記述しました。
①ＳＭでのシステム概要
運用の観点でのシステム概要を記述するという事になると思います。
つまり、運用しているシステムの概要であり、システム開発に関しての
情報は不要だと思います。
記述する情報の一例を挙げると
・運用時間帯
・機器構成
・運用要員構成
・運用における記述者の立場
などが挙げられると思います。
②ＰＭでのプロジェクト概要
対象となるシステムの概要はあくまで補助的な説明に留め、
対象プロジェクトの説明を中心にすべきだと思います。
記述する情報の一例を挙げると
・プロジェクトの開発工数
・開発期間
・顧客や外注との契約形態
・開発要員構成
・プロジェクトにおける記述者の立場
などが挙げられると思います。
ＳＭとＰＭの1.1の記述を統一してしまうと
査読者に求められている試験区分の立場を「理解していない」あるいは
「混同している」と見なされてしまう可能性があり
合格率が低下する危険性があります。
[359] すぎエモン (2010/01/07 Thu 17:41) mail
すぎエモンさん
こんばんは。ショウです。
すいません。質問の仕方がまずかったですね。
立場に応じた論文を書く必要があると考えておりますので、
ＳＭとＰＭでは、異なる観点で書かないといけない
というのは理解しております。
私が質問したかった内容は、論文を作成する際にあたり、
ＳＭの場合は、インシデント関係だろうが、
サービスデスク関係だろうが、移行手順関係だろうが、
どんな問題がきても、１．１で書く「ＩＴサービス概要」を決めて書いています。
ちなみに、「旅行予約販売システム」です。
かたや、ＰＭの場合も同様に、品質だろうが、要員管理だろうが、1.1のプロジェクト概要は、「営業支援システム」で書いています。
以下のように、、、
========================
１．私が携わったシステム開発プロジェクトの特徴と、
○○○○○○○○○について
１．１ 私が携わったシステム開発プロジェクトの特徴
私はソフトウェア開発会社Ａ社に勤務し、主に通信会
社のシステム開発案件にプロジェクトマネージャとして
従事してきた。今回、論述するシステム開発プロジェク
トは、通信会社Ｂ社の営業支援システム開発である。
Ｂ社は年々売上高が減少しており、営業力の強化を重
要課題として掲げていた。現在、利用している営業支援
システムは老朽化しており、使い勝手も悪いとの評判が
あった。加えて、2007年３月末をもって保守契約も切れ
ることから、経営会議にて2008年４月に稼働開始するこ
とを条件に開発の承認がされ、Ａ社が営業支援システム
開発プロジェクトを受託し開発することとなった。私は
プロジェクトマネージャとして参画することとなり、20
06年５月からプロジェクトを開始した。
=============================
毎回、違うネタで論文を作成される
大変器用な方がいらっしゃって関心していたのですが、
私は不器用なので、
ＳＭ用の１．１のＩＴサービス概要
ＰＭ用の１．１のプロジェクト概要
を作ってしまっています。。。。。
これって、あまりよくないことか、それともいいことなのか？
というのを質問したかったんですが。
[361] ショウ (2010/01/09 Sat 22:28) mail
すぎエモンです。
１．１で書く「概要」を常に固定化した文章を
使用して問題ないかという質問でしたか。
これはしたり！題意を読み違えました（苦笑）
大筋では問題ないかと思います。
私も、ＳＭ受験時は1.1を固定文章にしていたと
記憶しています。論文全体として、1.1の部分がいびつに
なっていなければ、不合格の原因になることもないでしょう。
固定文章の方が序盤の文章記述をスピードアップさせる事が
出来ますので、時間的な余裕が生まれるメリットがあります。
ただし、この場合、論文作成前に記述するアンケートと
1.1のプロジェクト概要の整合性がとれて矛盾点がないことが
重要かと思います。
[362] すぎエモン (2010/01/12 Tue 10:02) mail
こんばんは。ショウです。
> すぎエモンです。
> １．１で書く「概要」を常に固定化した文章を
> 使用して問題ないかという質問でしたか。
> これはしたり！題意を読み違えました（苦笑）
すいません。質問内容が悪かったです。
意図としては、おっしゃるとおりで、
１．１で書く「概要」を常に固定化した文章を
試験区分にあわせて用意し使用するということです。
> 大筋では問題ないかと思います。
> 私も、ＳＭ受験時は1.1を固定文章にしていたと
> 記憶しています。論文全体として、1.1の部分がいびつに
> なっていなければ、不合格の原因になることもないでしょう。
なるほど、わかりました。ありがとうございます。
> 固定文章の方が序盤の文章記述をスピードアップさせる事が
> 出来ますので、時間的な余裕が生まれるメリットがあります。
この時間的な余裕が生まれるというメリットは、
実際の試験時にはかなり大きなメリットであると、
私は考えております。
> ただし、この場合、論文作成前に記述するアンケートと
> 1.1のプロジェクト概要の整合性がとれて矛盾点がないことが
> 重要かと思います。
ですよね。。。。
試験担当者はテンプレート（アンケート）の読み込みから、
どのようなシステムの話なのかを確認するという事が、
どこかの本で書いてあったのを記憶しています。
もしかしたら、管理者さんのＩＴサービスマネージャの
本だったかもしれません。。。
ただ、このテンプレートもある程度決まっているようでしたので、
実は、これも合わせて用意するようにしています。
たとえば、開発期間であったり、開発規模(人月)であったり、
費用はハードウェアを除いて、開発規模(人月)×100万円とか
[363] ショウ (2010/01/12 Tue 22:47) mail
ショウさんご無沙汰しております。
ネスペやっと受かりました。
今度の春は情報セキュリティスペシャリストに挑戦します。
昨春はなぜか午前Ⅰのみ採点されてあとが ＊＊＊ でしたから必ずリベンジしますよ
情セキュはそんなに受かりたい気持ちもなくネスペのための踏み台程度に考えていたのですがネスペに合格してみると・・・ 急に情セキュに合格したいと思うようになりました。ペネスペと情セキュは二つとってほんとの意味でのネスペのような気がしてます。
今度の春に情セキュ受かったら私もITサービスマネージャを秋に受けたいと考えています。ITILは結構興味あります。
４月に試験が終わったら・・・論文の勉強もしたいです。そのときはショウさんにいろいろ質問ますよ。
[365] riri (2010/02/16 Tue 23:08)
ririさん、ご無沙汰です。
> ネスペやっと受かりました。
> 今度の春は情報セキュリティスペシャリストに挑戦します。
よかったですね。
姉妹サイトの「ネットワークスペシャリスト試験に楽々合格 掲示板」でririさんの合格は拝見いたしましたよ。
（^^）
> 情セキュはそんなに受かりたい気持ちもなく
> ネスペのための踏み台程度に考えていたのですが
> ネスペに合格してみると・・・
> 急に情セキュに合格したいと思うようになりました。
> ネスペと情セキュは二つとってほんとの意味でのネスペのような気がしてます。
たしかに、ネットワークスペシャリスト合格者であれば、
情報セキュリティスペシャリスト試験は、
とっつきやすい試験かもしれませんね。
> 今度の春に情セキュ受かったら
> 私もITサービスマネージャを秋に受けたいと考えています。
> ITILは結構興味あります。
今度の春は、プロジェクトマネージャを受験して、
秋はITサービスマネージャを受験しようと考えています。
ただ私の場合、どちらも「午後Ⅰ」が鬼門のようで、
まずは、ちゃんと「午後Ⅰ」を突破できる基礎を身につけたいと考えています。
ITサービスマネージャも午後Ⅰ過去問を何度も
繰り返し解いて準備していたのですけどね。。。。。（--;
> ４月に試験が終わったら・・・論文の勉強もしたいです。
> そのときはショウさんにいろいろ質問ますよ。
論文試験を合格したことがないので、
ちゃんとコメントできるかどうか分かりませんが、
お互いにコメントし合えればいいと考えますし、
このサイトで、論文を投稿すれば、
管理者さんをはじめ、いろいろな方がコメントしてくれると思いますよ。
[367] ショウ (2010/02/19 Fri 13:06) mail
試験勉強、論文対策で使用した参考資料を2点ご紹介します。
■ITサービスマネジメント入門(第6版)
www.nec.co.jp/itil/index.html
第II部の1章から3章まで。ITILの基礎や、ITILとISO/IEC 20000の
違いを理解するのに役立ちます。
■重要インフラ情報システム信頼性研究会報告書
sec.ipa.go.jp/reports/20090409.html
Part3「システム障害事例の分析と対策指針」57ページより掲載の
障害分析表はシステム障害事例の宝庫です。
論文ネタを考える際の助けになります。
■
これは試験が終わってから思ったことですが……
試験対策本でITILを学習していると、各プロセスでやることが
ただ書かれているせいか、「これが起きたらこうする」的な
事後対応視点での理解になりがちです。
でも、システムを正常稼動（＝サービスを提供）し続けるための
問題の予防こそがITILの本質です。場当たり的な運用では発生して
しまう問題があり、それを予防するために各プロセスが存在します。
それぞれのプロセスがどんな問題を予防しているか、という視点で
学習・理解していくと、自ずと論文ネタは思い浮かぶ気がします。
今秋受験される方の参考になれば。
※URLが2個あると書き込めないようなので、先頭を消してあります。
[366] hok (2010/02/19 Fri 13:00)
昨年の秋期にITマネージャー受けました。
結果は、論文で不合格でした。
午後Ⅰまで通過していたので、今年は、論文をメインに勉強していきます。
2009 ITサービスマネージャ 「専門知識+午後問題」の重点対策は、すごく試験勉強に役立ちました。
ありがとうございました＾。＾
[364] ケンハ (2010/01/24 Sun 14:48)
あけましておめでとうございます。
今年もよろしくお願いします。
早速ですが、またまた
ご相談させていただきたいことがあり
投稿させていただきました。
ＩＴＳＭのサイトでプロジェクトマネージャのことを
記述してすいません。
今回の春の試験を何とか突破できないものか
思案中なのですが、以下の方法のうち
①合格ゼミが最短コースかどうか
管理者様が思いつくことを
教えていただきたいと思います。
①ＩＴＥＣ合格ゼミ(大阪)
３日間コース、講師の直接指導
②ＩＴＥＣ通信教育(午前免除)
③独学＋模試
①と③では格段の差があるでしょうか？
当然、私の努力が大前提ですが、
[356] ＧＯＫＡＫＵＳＵＲＵＺＯ (2010/01/05 Tue 08:03) mail
ＧＯＫＡＫＵＳＵＲＵＺＯさん
あけましておめでとうございます。
本年もよろしくお願いします。
掲示板の規程をしっかり作っていなかった私に問題があるかもしれませんが、この掲示板は皆様のコミュニティ目的としているため、私への問いかけには応じかねます。
今後は、このような記事は無視するか、削除することになります。
ただ、最初に述べましたように、私に落ち度があって、ＧＯＫＡＫＵＳＵＲＵＺＯさんに悪気はなかったと思います。
なので、少しだけ回答させてもらいます。
私は③だけは選びません。午後１までは独学で対応可能ですが、論文は第三者に見てもらったほうがいいです。第三者に見てもらわないと、論文の良しあしがわからないからです。
[357] 管理者 (2010/01/06 Wed 06:20)
すぎエモンです。
横槍を入れて申し訳ないのですが。
私は、独学のみでした。
模試や通信教育、セミナーは受けませんでした。
最低コストを目指したのもありますが、人見知りなので…
論文についてはここのサイトで評価してもらっただけです。
合格率は低くなりますが、そういう選択肢もありうる…
ということで…
[360] すぎエモン (2010/01/07 Thu 17:50) mail
ITサービスマネージャ試験に合格しましたので、勉強法などを書きます。
【使用教材など】
・ITサービスマネージャ 「専門知識+午後問題」の重点対策〈2009〉（以下、「重点対策」と表記）
・アイテック公開模試
【午前1対策】
・免除
【午前2対策】
・「重点対策」の素読（ITIL部分を重点的に）
・過去問3年分
【午後1対策】
・「重点対策」の問題を解く
・「重点対策」に載っていない過去問を解く
※ JITECでダウンロードできる問題はすべて解いた
【午後2対策】
・「重点対策」の素読
・公開模試
※ 論文を実際に書いたのは、模試と本番の2本
【感想】
・ITILの問題が思っていたよりも多く出た。
・論文は、「対象者像を理解していることを示す」、「題意をはずさずに書く」、「高度な内容を書こうと頑張らない」を念頭に置いたところ、危なげなく書けた。
[350] ss2004 (2009/12/30 Wed 08:50) web
あまり参考にならないとは思いますが、受験記を投稿させて頂きます。
■取得済 ：2種、NW、SC
■運用経験：なし、開発側
■論文経験：なし、初挑戦
■勉強開始：2009/07上旬（H21春期合否発表直後）
■参考書 ：管理者殿著 ITEC「重点対策」のみ
■勉強方法：
◎通勤時間
・参考書を読む（片道15分×往復、試験直前までに3周以上読んだ）
H21春のSCを受けていたので、セキュリティ部分は流し読み程度
◎仕事の合間、業後（合計20時間くらい）
・職場のSLA、ITIL関連、障害記録、等のドキュメントを集める
・システム障害事例を検索（みずほ、ANA、失敗知識データベース、etc）
・上記の障害事例と、開発者視点の発想からインシデントと対応方法等の
具体例を考え、ITILの11プロセス毎に分類し、Excelでまとめる
※開発者なので最終的には、インシデント管理、問題管理、リリース管理、
キャパシティ管理等の想像できる分野以外は捨てることにした
・「ITサービスの概要」を考案。携わったシステムのエッセンスを抽出して
単純化したり業界を変えたりして、特定されないよう工夫した。
◎試験直前（金曜日に有休を取得）
・「シス管でなくITIL系の問題を」という事で、ITSMのサンプル問題を使い
2時間で1本目の論文を書いた（字数ギリギリ、内容はC評価レベル）
・参考書のリリース管理の章を参考に、試験で出されそうな問題※を考えつつ
2時間で2本目の論文を書いた（字数ギリギリ、内容はC評価レベル）
※リリース管理プロセスでのあるべき姿、問題が発生した場合の対処法が
問題文で例示され、リリース管理で発生したインシデントの概要と、
問題発見プロセスと対処法を工夫した点を中心に論述せよ、という問題
設問ウは「定期的な評価と改善」を想定
・上記論文のブラッシュアップはせず、論文ネタの深堀を行った
■試験当日：
◎午前I、免除。移動時間は参考書を読みつつ論文ネタの考案
◎午前II、余った時間で論文ネタを考え、午前IIの余白に書き込み
◎午後I、時間ギリギリのため午後IIの準備できず
◎午後II
・問題選択、問１変更管理、問２サービスデスクとも捨てていた分野のため
必然的に問３を選択
・構想、予防活動はネタがなかったので急遽構想を練る。「予防できた問題」
を思いつき、開始13分くらいで設問イまで書ける程度に逆説的に論理を構築
・テンプレート、開始15分くらいで記述終了
・設問ア、開始35分くらいで記述終了、予定より5分遅れ
・設問イ、開始95分くらいで記述終了、予定より5分遅れ
・設問ウ、再び構想開始。参考書にあった予防活動のためのマニュアルを配布
したことにして記述開始。しかし遅れた5分分の思考時間が足りなかったため
2行字数が足らず、問題文の表彰について書き、時間も字数もギリギリで終了
■アドバイス（反省の裏返し）
◎論文練習時、準備していたネタを使って2時間で論文が書けても安心しない。
本番での論理構築は思いのほか時間が掛かる。私は2時間の中で問題文も含め
て考えるという謎の手を使ったが、模試を受けたり、予め「○年度の問○」と
決めておいた問題や、有識者に考えて貰った問題を練習する時に初めて見る、
などの手を使って感覚を磨くと良い。
◎新制度1発目なので、参考書やWebのサンプル論文、復元論文はどうしても
「システム概要」になっている。「ITサービス概要」を書く意識を強く持つ。
この点では論文練習は今年の問題を中心に行う方が良い。
◎ITILのどこかのプロセスで問題が発生し、その対応を問われる問題は毎年必ず
出されるはず。論文ネタとして用意する事例については、予防対応、事後対応、
原因、影響など深く掘り下げて定量的に表現できるようにしておくと、問題の
内容にも設問ウにも応用が利く。
[347] hok (2009/12/27 Sun 08:56)
hokさん
合格記ありがとうございます。
また、合格おめでとうございます。
>あまり参考にならないとは思いますが、
そんなことはありません。とっても役に立ちます。
hokさんの努力の跡がうかがえます。こういう合格体験談って、天才のコメントは参考になりません。天才は簡単に受かるからです。わたくしを含め、皆さんが苦労して合格した体験というのは、とても貴重です。
これからも、このHPをよろしくお願いします。
そして、また遊びに来てください。
[348] 管理者 (2009/12/28 Mon 19:55)
hok様
合格体験記、ありがとうございます。
管理者様と同様、努力の跡がかなり伺えます。
私が不合格になったのは当たり前だと思いました。
うわべだけの勉強しかやっていなかったと思います。
[349] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/12/28 Mon 23:47)
やまぽんです。
昨年、管理人さんの丁寧な添削にも拘わらず、論文で論旨を外してしまい、不合格となりました。
1年遅れましたが、今年なんとかリベンジでき、合格しました。
受験番号SM634-1450の方は， 合格 です。
午前I試験の得点は，***.**点です。
午前II試験の得点は， 72.00点です。
午後I試験の得点は， 69点です。
午後II試験の評価ランクは，Aです。
[337] やまぽん (2009/12/21 Mon 14:41)
お久しぶりです。かんそくです。
昨年の塾ではお世話になりました。
ＩＴサービスマネージャ合格おめでとうございます。
ちなみに私もネットワークスペシャリストに合格できました。
[338] かんそく (2009/12/21 Mon 22:33)
やまぽんさん、ＩＴサービスマネージャ合格おめでとうございます。
かんそくさんもネットワークスペシャリスト合格おめでとうございます。
お二人とも、大変な努力の成果ではないかと思います。
このサイトもＩＴサービスマネージャ挑戦者の聖地になりつつありますね。
もしかしたら、ＩＰＡ出題者の人も注目しているかも知れません。
[343] すぎエモン (2009/12/22 Tue 08:25)
やまぽんさん
合格おめでとうございます。
さすがですね。もともと私より経験も実力も御有りなので、受かるべくして合格された気がします。
ちょっとお願いがありますので、私のメールに連絡いただけないですか？よろしくお願いします。
[344] 管理者 (2009/12/22 Tue 23:20)
みなさんありがとうございます。
まとめレスで申し訳ありません。
今回の合格は、小生の実力向上より、合格基準の緩和と認識しています。
合格率も大幅に上がっている様子なので・・・
本当に、合格基準が緩和されたのなら、
残りの新区分（改名）にも挑戦したいと考えています。
・ITストラテジスト
・システムアーキテクト
[346] やまぽん (2009/12/23 Wed 12:00)
平成２１年度 秋期 ＩＴサービスマネージャ試験 成績照会
受験番号 SM821-**** の方は， 不合格 です
午前Ⅰ得点 68.00点
午前Ⅱ得点 80.00点
午後Ⅰ得点 51点
午後Ⅱ評価ランク -
残念な結果となりましたが、
ここまで点数が取れたのも
このサイトのおかげです。
私の独学だけでは午前Ⅰの
突破も不可能だったと思います。
来年がんばります。
管理者様、すぎエモン様
ありがとうございます。
[345] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/12/23 Wed 02:45)
解答速報をみて、試験直後落ち込んでいましたが合格できました。
管理者様、すぎエモン様、掲示板でのご指導ありがとうございました。
重点対策の参考書と、このサイトが大変合格に役立ちました。
また、次の試験に向けて頑張ります。
[339] だっく (2009/12/21 Mon 22:38)
だっくさん
合格おめでとうございます。
大変な努力をなされたのだと察します。
私もITサービスマネージャは未取得なので、
ITILを勉強して、いつかは挑戦したいですね。
[342] すぎエモン (2009/12/22 Tue 08:21) mail
ＩＴストラテジスト合格できました
すぎエモンです。
プロマネ、システム監査に続き、ＩＴストラテジストも合格する事ができました。
このサイトで学んだ論文の基礎が活かされて連続合格が可能になったと考えます。
本当にありがとうございました。
～～～～～～～～～～～～～～～～～～～～～
平成２１年度 秋期 ＩＴストラテジスト試験 成績照会
受験番号 ST921-xxxx の方は， 合格 です
午前Ⅰ得点
***.**点
午前Ⅱ得点
64.00点
午後Ⅰ得点
78点
午後Ⅱ評価ランク
A
～～～～～～～～～～～～～～～～～～～～～
午後Ⅰと午後Ⅱが素直な問題構成で
午前Ⅱだけがやたらと難しいと思っていましたが
それがダイレクトに点数に出ていますね、今回も運が良かったです。
[341] すぎエモン (2009/12/22 Tue 08:07) mail
合格された皆様
本当におめでとうございます。
皆様の合格の声を聞けるのは本当にうれしいです。
このサイトを運営していて良かったです。
もしお時間があるようでしたら、勉強方法など、合格体験談を記載願います。
来年受験される方への最高のアドバイスになります。
よろしくお願いします。
※新規記事で作成願います。
[340] 管理者 (2009/12/22 Tue 06:53)
今日、１２月２１日は合格発表の日です。。。
早速、正午になった瞬間、試験センターのページにアクセスし確認してみましたが。。。。。
結果は。。。。不合格でした。。。。
午後Ⅰが「５８点」
ショック！！！。あと２点って。。。。。
なんか、いやな予感はしていたんですけどね。。。。
午後Ⅰの出来がいまいちのような気がして。。。。
論文を読んでもらえなかったのが、一番辛いですね。。。。
[336] ショウ (2009/12/21 Mon 12:32)
とりあえず、試験が終わりほっとしているところです。
約３ヶ月前「楽々合格」の文字に引かれ、勉強を開始して以来
このサイトと過去問の勉強だけで今までにない手ごたえを感じる
ことが出来ました。
管理者様、すぎエモン様ありがとうございました。
大変感謝しております。
午前は突破できましたが、
論文で論点がずれていると思います。
また来年がんばります。
2010年春ですが、通常ならばプロジェクトマネージャ
なのですが、情報セキュリティにしようか悩んでいます。
セキュリティ午後Ⅱの問題を見てみましたが
今の私の知識ではちんぷんかんぷんです。
過去問の訓練で解けるようになるのでしょうか？？？
論文ではなく、解答の決まっている情報セキュリティのほうが
結果として合格しやすいのでないか？と考えた次第です。
[325] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/19 Mon 21:27)
お疲れさまでした。
私もＩＴストラテジストを受験してきました。
ＧＯＫＡＫＵＳＵＲＵＺＯさんのご意見ですが
私としては同意と反対が半分半分です。
【プロジェクトマネージャの方が良い理由】
①論文系は「次に繋がりやすい」というメリットがあります。
一度どれかの論文系の区分に合格してしまえば、論文のコツを
つかんで、別の論文系でも連続合格を獲得しやすくなります。
②プロジェクトマネージャは市場価値が高いです。
http://itpro.nikkeibp.co.jp/article/COLUMN/20081204/320690/?ST=solution
合格時のインパクトや経営層からの評価が違います。セキュスペよりも
プロマネ合格者の方が数段上の扱いを受けるのですね。
【セキュリティスペシャリストの方が良い理由】
①高度区分の中で唯一春秋両方試験が行われます。
よって、１年に２度チャンスがあるので、何度もチャレンジするには
最適です。過去問も豊富に存在するハズです。
②ネットワークスペシャリストとの親和性が高いです。
通常、高度の非論文系は、他の区分との違いが大きく。
別の区分に連続で合格する事は困難ですが、セキュリティスペシャリストと
ネットワークスペシャリストは方向性が近く、培った知識がそのまま活かせま
す。
【プロジェクトマネージャのデメリット】
①評価が高い分、合格すると仕事で重い責任を負うこともあるので
その点は注意です。
②難易度が高いです。特に運用現場の人は、自分より数段上の管理者としての
視点と開発側サイドでの視点も身につける必要があります。
【セキュリティスペシャリストのデメリット】
①最新技術の導入が多いので、他の区分のような「しっかりとした基礎知識」
だけでは合格が難しいです。過去問研究だけでは突破できない可能性がありま
す。
②合格者に向けられる目が、他の区分よりも冷ややかな時があります。
セキュリティは金にならない副次的な技術という考えが根強く
「スゴイねえ、…で何の役に立つの？」という感じですかね。
ＧＯＫＡＫＵＳＵＲＵＺＯさんの場合は、論文作成がある程度のレベルにまで
達していますので、このまま論文系で絞ってもよいかも知れません。
後はひたすら練習論文の数をこなすと、論文のレベルも上がって来るでしょう。
第三者に論文を評価してもらうと更によいですね。
セキュスペを目指す場合は、何度かの不合格も視野に入れてネスペの合格まで
見据えた長期的なプランで勝負されるといいかも知れません。
[326] すぎエモン (2009/10/20 Tue 09:10) mail
すぎエモン様
いつも大変お世話になっております。
やはり練習不足だと思います。
ある程度、練習して引き出しを持っていないと
「工夫した点」が書けません。
次回はプロジェクトマネージャにします。
秋にはＩＴＳＭもあるわけですから、
「プロジェクトマネージャ試験楽々合格」ってできないですか、
で、少し書いてみました。
－－－－＋－－－－＋－－－－＋－－－－＋－－－－＋
プロジェクトマネージャ平成２１年春午後Ⅱ問３
－－－－＋－－－－＋－－－－＋－－－－＋－－－－＋
１．プロジェクトの特徴と採用した業務パッケージと採
用目的
１．１情報システム開発プロジェクトの特徴
私はソフトウェア会社の情報システム開発部門に勤務
している。今般、書店Ｈ社のＡ社長から基幹システムで
ある会計システムの開発を依頼された。私はその開発の
プロジェクトマネージャを担当した。
Ｈ社は愛媛県に本店があり、中四国を中心に７０店舗
をもつ中堅の書店である。現行の会計システムは１０数
年前に他社が構築したもので、ソフトウェアはＨ社用に
オリジナル開発されたものであった。ハードウェアの老
朽化、ソフトウェアの陳腐化等の事情により、新システ
ムへのリプレイスが急務となっていた。Ａ社長からは会
計システムの構築にあたり、次のような要望があった。
①次の４月から本稼動を開始したい。
(開発期間：10ヶ月間)
②現行システムにはとらわれず、一般的に使用されてい
る会計システムにしてほしい。そのために現行の業務プ
ロセスに改善が必要な場合は対応したい。
③開発費用は出来るだけ安くしてほしい。
④現行システムは紙の帳票出力が大量にあるので、新シ
ステムでは経費削減のため、紙の帳票出力は少なくして
ほしい。
１．２採用した業務パッケージとその採用目的
私はＡ社長の要望に答えるためには、業務プロセスの
改善、開発期間の短縮、開発費用の縮小等が必要なこと
から、弊社での導入実績があり、開発経験者が豊富であ
る会計パッケージを採用することにした。また、できる
だけ業務パッケージの標準機能を適用するが、どうして
も標準機能では満たせない機能があった場合は必要最小
限「外付けプログラム」で対応することにした。
２．外付けプログラムが必要になった理由と利用部門と
合意した内容・経緯、開発した外付けシステムの概要
私は次のような方針について利用部門の合意を得た上
でプロジェクトを遂行しなければならなかった。
①業務パッケージの標準機能を最大限適用する。
②業務パッケージの標準機能では満たせない機能を実現
する場合でも、外付けプログラムの開発は必要最低限に
抑える。
外付けプログラムの開発が必要な場合は、開発が必要
な理由を明確にして、開発がプロジェクトに与える影響
を慎重に検討する。その上で、開発の優先順位を見直し
たり、バージョンアップの容易さなどの保守性を考慮し
た開発方法を選択したりするなどの工夫をしなければな
らなかった。
２．１外付けプログラムの開発が必要となった理由
まず、要件定義を実施した。Ｈ社からは担当取締役の
Ｙ氏、会計担当Ｎ氏が参加し、会計システムのサーベイ
シートを元に現行システムとのフィットギャップ分析を
実施した。標準機能でほとんどの機能を満足していたが
次の機能だけが不足していた。
①経営日報：毎日、営業終了後、各店舗からその日の売
り上げ等の経営情報をパソコンに入力し、そのデータを
本社へ転送する。
②ランキング表：毎月、月末時点の各店舗における売り
上げ、経費、利益等を集計し、各計数毎にランキングを
あらわす表である。
２．２利用部門と合意した内容、経緯、概要
①経営日報の作成については、現行システムですでに
稼働中であり、毎日、７０店舗から送られてきた経営日
報を手作業で会計システムに入力することは量、時間的
にも不可能である。外付けプログラムで対応することと
した。
②ランキング表の作成については、会計パッケージで
は各店舗毎の計数は表示できる。全店分についても表示
できるが、ランキングの機能はなかった。この表につい
ては経営判断のため必須であるため、外付けプログラム
で開発することにした。
３．工夫した点とその成果及び今後の課題
３．１工夫した点
外付けプログラムの開発にあたり、会計パッケージ採
用の目的達成のため次の工夫を実施した。
①経営日報の作成について、各店舗でのデータ作成、デ
ータ転送については、新会計システム用にプログラムを
変更しなければいけないが、他社が開発したシステムで
もあり、開発期間の短縮、開発費用の縮小という観点か
ら、現行システムをそのまま使用し、受信したデータと
新会計システムのデータ項目が相違するところは変換用
テーブルを使用し、新規開発を最小限にした。
②ランキング表の作成については、通常ならば、現行シ
ステムと同様に全種類のランキング表のプログラムを個
別に作成するが、これも開発期間の短縮、開発費用の縮
小という観点から、大福帳データとして、パソコンにダ
ウンロードするプログラムのみ作成し、あとは表計算ソ
フトを使用して、ユーザーが並べ替えの機能を利用して
自由にランキング表を作成することにした。
また、パソコンのソフトウエアであるため、バージョ
ンアップは簡単でユーザーでも可能であり、安価である。
３．２成果
その後、順調に外部設計、内部設計、プログラム開発、
テスト、移行、本稼動とスケジュール通りに進捗させる
ことが出来た。
Ａ社長から安くていいものを提供してもらって喜んで
いるとの好評をいただいた。私も非常に満足している。
３．３今後の改善点
今回のプロジェクトについて、紙の削減については着
手できなかった。昨今のパソコンの普及、ユーザーのレ
ベルアップ、またエコを考えれば、紙での出力の前に、
帳票を表計算ソフト用にダウンロードする機能が必要で
あると感じた。この機能を業務パッケージの標準機能と
して弊社パッケージとして提供したい。
－以上－
[327] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/20 Tue 21:54)
お疲れさまです。すぎエモンです。
ITサービスマネージャのサイトでプロジェクトマネージャの論文を
査読してもいいのやらが気になりますが…
【良いと感じた点】
・いつもながら設問アの書き方は巧みですね。最初に読む人間を論文の世界に引
き込みやすい書き方だと思います。
・論文の内容がシンプルで読みやすいという点が評価できます。「読むのも疲れ
る論文」が意外と多いので、簡潔で読みやすい論文はポイントが高いです。
・この論文をアップしているのが、情報処理試験日の２日後というのはすごいで
すね。普通は「終わった～」といって合否がでるまで勉強をお休みする人も多
いのですが。非常に高いモチベーションを感じます。私の経験上、こういう高
いやる気を持つ人が、複数の高度区分に合格していく事が多いです。
【気になった点】
・「利用部門との合意した内容」については記述されていますが、
「利用部門との合意に至った経緯」の説明が弱くないでしょうか。
・「２．３開発した外付けプログラムの概要」を追加した方がいいかもしれませ
ん。「２．２利用部門と合意した内容、経緯、概要」で答えようとしています
が、「利用部門と合意した概要について答えている」と誤解されないためにも
もっと明確に項目分けして「設問に忠実に答えている」ことをアピールした方
が合格率が上がると思います。
・上記２点を踏まえると設問イについては
「２．１外付けプログラムの開発が必要となった理由」
「２．２利用部門との合意した内容」
「２．３合意に至った経緯」
「２．４開発したプログラムの概要」
と詳細に項目分けして、１つ１つ丁寧に答えた方が、設問で問われている事に
忠実に答える事になり、合格率が向上すると思います。
・「帳票を表計算ソフト用にダウンロードする機能」というのはちょっと意味不
明ですね。「帳票を表計算ソフト用にコンバートする機能」の方が良くないで
しょうか？
・「この機能を業務パッケージの標準機能として弊社パッケージとして提供した
い」という部分ですが、最後の最後で「ん？」と思ってしまいました。他社パッ
ケージを自社パッケージとして売り出すに当たって業務パッケージ開発元の著
作権を侵害しないだろうか？という心配ですね。この様な余計な疑問を持たれ
る記述は避けた方が賢明でしょう。「会計パッケージを自社製品で作成したい」
という記述の方がよいと考えます。
・全体的に論文の視点がややシステムアーキテクト寄りの書き方ですね。欲を言
うならプロジェクトマネージャとしてもう少し高い視点で記述できるともっと
説得力のある論文になるのではないでしょうか？例えば「３．１工夫した点」
については、プログラム上の工夫ではなく、問題文に書かれているように「開
発の優先順位に基づいて開発範囲を見直す」「バージョンアップの容易さなど
の保守性を考慮した開発方法を行う」などのプロジェクトマネージャとしての
工夫を見せつける事で、さらに合格率が向上すると思います。
【総括】
・やや、設問イなどで不足している点がありますが、論文能力が着実に向上して
いる事を加味すると、十分合格をねらえる実力があるのではないかと感じまし
た。あとは論文と午後１の数をこなしてレベルアップしていけば、次回のプロ
ジェクトマネージャでも良い結果が出せるのではないかと考えます。
[328] すぎエモン (2009/10/21 Wed 13:03) mail
すぎエモン様
早速、読んでいただいてありがとうございます。
ご指摘どおり、システムアーキテクト寄りの回答になっています。
プロジェクトマネージャなら・・・・・とした。
という・・・・・のところで詰まってしまいます。
思いつかないのです。
午後Ⅰを解いていけば、午後Ⅱへつながっていくでしょうか？
なにか参考になる対策本はないでしょうか？
三好康之氏の「プロジェクトマネージャ」がいいでしょうか？
いつも教えていただくばかりですいません。
[329] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/21 Wed 22:32)
>午後Ⅰを解いていけば、午後Ⅱへつながっていくでしょうか？
そうですね、「IPAが求めるプロジェクトマネージャとしての視点」を培うには
午後Ⅰが最適であると思います。
>なにか参考になる対策本はないでしょうか？
私は「プロジェクトマネージャ完全教本：日本経済新聞出版社」を購入しました
が、殆ど参考にしませんでした。理由は、参考書の論文集が完璧すぎるからです
膨大な時間をかけ、何度も推敲や第3者チェックを重ねる。という本番受験時に
はあり得ない行程を経て作成された「模範論文」は受験会場で書かれる論文の実
情とはほど遠く、不慣れな受験者が読むと「こんなに高いレベルの論文なんて自
分には書けない」と思ってしまいます。
プロジェクトマネージャとしての視点での論述が出来ないのは、現時点では仕方
の無いことだと考えます。よって、「午後Ⅰ問題」でプロジェクトマネージャと
しての視点を磨き、それを「午後Ⅱ問題」に反映させるというサイクルを繰り返
す事で、少しずつ書き方も見い出す事が出来るのではなでしょうか。参考書に頼
りきって、人の言葉を借りるよりも、自分の中で熟成させて獲得した言葉を使う
方が説得力のある内容になると愚考します
なお、「プロジェクトマネージャとしての工夫」を記述する際は「自分の経験」
や「参考書」から思い出して記述するのは大変だと思います。目の前にある「試
験問題」の問題文に具体的な工夫例が書いている場合があることが多いのでそれ
をそのまま使った方が楽だと思います。
例えば、問題文に「開発の優先順位に基づいて開発範囲を見直す」と書いてある
なら。
３．１工夫した点
私は、パッケージの外付けプログラムの開発にあたり、開発の優先順位に基
づいて開発範囲を見直す工夫を行った。開発範囲を絞り込む事で以下のメリッ
トが生まれると考えた。
①工程の遅れを防ぐことができる
②品質の確保が容易になる
③コストを削減できる
のように書くこともできます。結果的には題意に沿いつつ、まるで自分で考えた
工夫の様に見せる事ができます。
[330] すぎエモン (2009/10/22 Thu 12:29) mail
すぎエモン様
午後Ⅰ、Ⅱの繰り返しでがんばります。
ありがとうございます。
[331] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/22 Thu 22:43)
◆すぎエモンさん
いつも書き込みありがとうございます。本当に感謝しております。私がITサービスマネージャの試験に関して時間をほとんど割けてません。掲示板にて、連戦連勝のすぎエモンさんから書き込みをいただき、喜ばれている受験生さんは多いと思います。
◆ＧＯＫＡＫＵＳＵＲＵＺＯさん
>三好康之氏の「プロジェクトマネージャ」がいいでしょうか？
これはお薦めです。
執筆協力者として巻末に私の名前を掲載していただいておりますので、ひいき目があると思われるかもしれませんが、レベルの高い本です。
情報処理試験の本はたくさんありますが、この本が最もレベルが高いと思います。私が別の本を執筆する際には「三好さんの本を参考にするとよいよ」とアドバイスをもらいました。
>「プロジェクトマネージャ試験楽々合格」ってできないですか、
これ、実は前からやりたいと思っていたんです。
私が受験生のときにまとめたテクニックがノートにぎっしり記録してあります。そのノウハウを是非読んでいただきたいと考えております。
ただ、私の稼働や諸事情があって、延期させてもらってます。
[332] 管理者 (2009/10/24 Sat 22:30)
管理者様
やはり、三好先生の本はいいと思いました。
チェックリストの暗記、あるべき姿の記述がありましたので、
私はまず午後Ⅰを勉強して、午後Ⅱがある程度できたところで
もう一回読もうと思っていました。
ちなみに、執筆協力されたのは2010年からでしょうか？
付属のＣＤには午前Ⅱの問題がわかるようになっていると
聞いて、ますます、優れものと思いました。
[333] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/26 Mon 18:57)
どうもショウです。
ＧＯＫＡＫＵＳＵＲＵＺＯさんは、スゴイですね。
試験終了後の２日後に、プロマネの論文を書くとは・・・。
今年のＩＴサービスマネージャ試験を受けて、
「はぁ～、やれやれ」
「春まで時間はあるし、少しのんびりするかぁ～」
という気分の僕とは、えらいちがいですね。
ハンドルネームにもあるように、
「合格するぞ！！」という意欲には、感心いたします。
僕も見習いたいと思います。
ちなみに、僕は去年「プロマネ」に挑戦しました。
なお論文試験も、はじめてでした。。。。
結果は午後Ⅰで５０点という
なんとも、さぶい結果になりました。。。。
初めての論文試験ということもあり、
結構、論文書いて練習したのに、読んでもらえなかったのが、
とても残念でした。。。。
なので今年は、論文練習以上に、午後１対策をしっかりと
やっておきたいと考えております。
ちなみに、三好さんの本は良本だと思います。
僕もいろいろな方に、どの参考書がいいか聞きましたが、
周りの合格された全員が「三好さんの本がいい」というのです。
正直、半信半疑でしたが・・・・。
本屋で立ち読みした感想は・・・・・。
「これ、分かりやすいかも」だったので、その場で買いました。
ただ、午後Ⅰ対策をおろそかにした結果。
午後ⅠでＯＵＴ！！！。 （笑ってしまいますね）
今日からでも、少しずつ勉強をする時間を作って、
来年のプロマネに挑戦することにします。
ＧＯＫＡＫＵＳＵＲＵＺＯさん。頑張りましょうね。
管理者さん、すぎエモンさん、また、色々とお教えください。
と言いいつつ、この掲示版で「プロマネ」について、
やり取りをしてもいいのかどうか、ちょっと気にしております。
大丈夫でしょうか？？？
大丈夫じゃない気もしますが・・・。 （＾＾；
[335] ショウ (2009/11/03 Tue 18:13)
初めまして。管理者様の対策本を読んで受験して参りました。同じ教室中に同じ対策本を使ってる方を散見しました。
肝心の論文の出来は……自分の評価でＢランクです。採点が甘いことを期待するしかありません。
同じく受験された方々、お疲れ様でした。
※余談ですが、対策本P100のイの解説が「構成管理」となっていますが、「キャパシティ管理」ではないでしょうか。
[323] hok (2009/10/18 Sun 19:31)
私も管理人殿の「重点対策」本を持って受験しておりましたよ(^_^)v
前回投稿したのは、３年前です。つまり、今回は３回目の受験です。
今までは、２回とも午後Ⅰで落ちていましたが、今回の午後Ⅰはいけるのではと感じています。
そこで、論文ですが、すべてＩＴＩＬっぽかったのでとてもあせりました。そこで、しかたなく「問１の変更管理プロセスの確実な実施について」を選択しました。
内容は移行プロセスに問題が発生し、移行リハーサルを対策案として書きました。しかしながら、移行はリリース管理の範疇のようににも思います。広義では変更管理のような気もします。ご意見ください。
みなさんは、論文いかがでしたか？
[324] スイマー (2009/10/18 Sun 20:53) web
どうもです。ショウです。
ずいぶん前に論文を投稿して以来の書込みです。
家の引越しに、弟と友人の立て続けにあった結婚式。
さらには、かみさんの妊娠と、
試験前に多くのイベントがありましたが、
とりあえず、ＩＴサービスマネージャ試験は受けてきました。
手ごたえは。。。。
うーん。どうでしょうね。。。
微妙ですね。こればっかりは分かりませんね。。。。。
午後Ⅰも、なかなか手ごわかったような気がしますし、
午後Ⅱの論文は、もっと手ごわかったです。。。
問１、問２、問３
どれを選んでも難しそうでしたが、
結局、僕は問３の「事前予防的な問題管理について」を選択しました。
正直、どの問題も単純な感じはしなかったですね。
どの問題も「ひとひねり」ありそうな問題でした。。。
問３だと、仮説→検証→さらに仮説→検証 みたいに、
仮説と検証を繰り返し考察を深め、問題を発見する。
というプロセスが絶対必要だと考えますしね。。。。
ああ、厄介だぁ～。
今後の勉強のために、一応、復元してはいますけど、、、、
なんとか合格したいものです。。。。
[334] ショウ (2009/11/03 Tue 01:10)
この時期、いつものことでありますが、
絶対合格と思いながらも、
試験当日、問題を見た瞬間、
わからない問題が多く、、、、不合格。
また、半年間、勉強しなければならない。つらい。
特に、今回、問題傾向が変わり、
出来なかったらどうしよう、、、とか
そんな不安に陥るのは私だけでしょうか？
[316] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/06 Tue 22:20)
はじめまして。
私も不安になります。
ひとつご質問なんですが、試験の前の日をどのように過ごされていますか。
勉強はあまりせずに早く寝ようとしますが、寝られません。どちらかというと寝不足気味です。
なにかいいアドバイスを教えていただけないでしょうか。
[318] Trust (2009/10/11 Sun 22:14)
私は試験の前日（土曜日）に早起きをします（私は５時ぐらい）。
すると夜は自然と早寝になります。早く寝れば試験日も早く起きれて余裕を持って準備できます。
[321] pyunta (2009/10/16 Fri 19:52)
私は、試験の前日は、「持ち物と試験会場までの行き方を確認」する以外は普通に過ごしています。
普通にということは、普段のペースで過去問を解くということです。私の経験では、一夜漬けも良くないですし、早く寝ようとするのも却ってダメです。
[322] ss2004 (2009/10/16 Fri 20:55) web
－－－－＋－－－－＋－－－－＋－－－－＋－－－－＋
１．運用の概要と運用効率向上に着手した理由
１．１情報システムと運用の概要
私が勤務する会社は愛媛県に本店があり中四国を中心
に１５０店舗の支店をもつ地方銀行である。私はその地
方銀行の情報システム部門のＩＴサービスマネージャと
して勤務している。
銀行の基幹システムはホストシステムであり、勘定系
、情報系、開発系のサブシステムから構成されている。
しかし、最近、パソコンソフトの充実、サーバーシステ
ムの充実に伴い、融資支援システム、ＣＲＭシステム、
グループウェアシステム等のサーバーシステムの導入が
当たり前になってきた。その結果、情報システムが大規
模化、複雑化する傾向にある。その大規模化、複雑化す
したシステムを運用するためには、より多くのハードウ
ェア、ソフトウェア、施設、要員などの運用資源が必要
となっている。
現在の運用要員は２０人である。そして、２４時間オ
ンラインサービスを運用するために、１日８時間の３交
代制で運用している。通常勤務は８時３０分から１７時
３０分までの８人、遅出勤務は１６時から２５時までの
４人、深夜勤務として２４時から９時までの４人、残り
４人は休日である。
１．２運用効率の向上に着手した理由
現状での運用体制の中で大規模化・複雑化するシステ
ムを運用するためには、外注要員の増員が手っ取り早く
簡単な方法であるが、銀行という社会的信用を重視する
企業にとっては個人情報漏えい等のセキュリティの観点
からふさわしくないとされた。また、他部署からの異動
による増員も考えたが、近年の人件費削減のためリスト
ラを推進中であることからありえない方策であった。
結局、現状での運用効率向上から要員を搾り出すしか
なかったのである。
２．運用資源の稼動分析と施策の実施
２．１運用資源の稼動状況の分析
まず、私は運用効率向上のため、改善プロセスを、シ
ステム開発部門と協力しながら、以下のように進めた。
①運用資源の稼動状況を定量的に分析し、改善点を明確
にする。
現行システムの運用に、だれが、いつ、何の処理を、
どれくらいの時間かかっているか、「システム別運用工
数表」を作成するようにメンバー全員に依頼した。
その結果、日次、週次、月次、期次について、磁気テ
ープへのデーターバックアップに一番多くの時間を費や
していることがわかった。テープ管理者のテープの入出
庫作業時間、オペーレーターのテープ装填時間を何とか
短縮出来ないかを考えた。
②運用資源の低減または活用目標を定め、施策を立案す
る。
この施策の検討をし始めたころ、弊社のホストコンピ
ュータを担当するＩ社からＶＴＳ(バーチャル・テープ
・サーバー)の導入提案があった。ＶＴＳとは１本あた
り現在のテープの約８０倍の容量があるテープを２００
本装填し、テープの入出庫はロボットアームで自動装填
し、今までは１ファイルに対して１本の物理テープを割
り当てていたが、ＶＴＳはユーザーが意識することなく
ディスク装置のイメージでファイルを管理できるもので
あった。
私は現状から以下の目標値を設定し、ＶＴＳ導入を実
施した。
Ａ．テープオペレーションの削減
１日１１００回から１０回程度に削減
Ｂ．テープの削減
約２６０００本から約４００本に削減
Ｃ．テープ保管スペースの削減
約３００００本の削減
２．２施策の実施
私はＶＴＳの導入を次のスケジュールで実施した。
①４月 ：ＶＴＳの導入
②５月から７月：システム整備とテスト
③８月から１１月：日次、月次、期次のテープ移行と本
稼動
④１２月から：保存データのテープ移行と本稼動
移行についてはデータセット名をわかりやすくするた
め、たとえば、普通預金元帳の場合、ＢＴ１．ＦＵＴＵ
．ＭＯＴＯＣＨＯをＶＴＳにした場合、頭文字だけをＢ
からＶに変更し、ＶＴ１．ＦＵＴＵ．ＭＯＴＯＣＨＯと
した。これによって、ＪＣＬ等の変更作業を簡単にわか
りやすくした。
導入後、半年が経過したが、ＡからＣの目標値をほぼ
クリアすることが出来た。
３．評価と今後の改善
３．１評価
今回のＶＴＳ導入については以下のように高い評価を
得ている。
Ａ．テープ装填作業軽減により、オペレーターが２人削
減できた。
Ｂ．テープ入庫・出庫作業の軽減により、テープ管理者
を２人削減できた。
Ｃ．情報システム部が毎月実施していたテープの現物検
査について、３人３日から２名１日に削減できた。
Ｄ．テープ装填ミスによるシステム障害が皆無となった。
Ｅ．開発時のテストについて、今までは磁気テープ貸出
簿貸を提出し、翌営業日にテープ出庫を確認しテストを
実施していたが、ＶＴＳ導入後はデータ使用申請書を提
出すれば即時にテストを実施できるようになった。また、
テスト時間も転送速度が４倍となったため、かなり短く
なった。
また、今回のＶＴＳ導入に伴う費用については約１億
円かかったが、削減工数が高かったため、約５年で償却
できることになった。
手間が減って、運用効率も向上し、安全性も確保でき
た今回の投資はかなり有効であったと考えられる。
３．２今後の改善
今回の施策については、ホストシステム、サーバーシ
ステムともにテープ作業という、運用の一部を効率化し
たに過ぎない。サーバーシステムの増大、オペレーショ
ンの複雑化等に対する根本的な施策ではない。
今後は複数のサーバーシステムを一箇所に集中し、簡
単な操作で運用できるよう、開発の初期段階からプロジ
ェクトに参加し、システム運用面も重視したシステム構
築が必要であると考える。
以上
[319] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/13 Tue 21:19)
すぎエモンです。僭越ですがコメントさせて頂きます。
【良いと感じた点】
・設問アでの問題点がわかりやすかったですね、
運用が何に困っているかが分かりやすく、
運用効率向上に着手する理由が明快でした。
・設問アの記述量をピッタリ１枚目の行末で揃えて
いますね。記述量の調節が巧みだと思いました。
・特に「１．１情報システムと運用の概要」の部分は
記述が巧みだと感じました。短い文書量で
情報システムと運用の概要と現状の問題点を巧みに
書き出していると思います。
一度の査読で状況が頭に描けました。
・ある程度論文を書いてくると当たり前の事になりますが
問題に対して忠実に答えようとする事は最重要課題になります。
この論文については忠実に答えようとする意図が現れていますね。
・ＶＴＳ導入に伴う費用を明記し、更に「約５年で償却」
と償却期間まで記述出来ているのはポイントが高いですね。
記述者の視野の広さをアピールできるポイントに
なるかと思います。
【気になった点】
・文面から察するに「２４時間オンラインサービス」に加えて
「３６５日無停止運転」を行っているような感じを受けます。
それなら、その旨明言した方が良くないでしょうか？
そうでなければ「残り４人は休日である」という記述に「何でだろう？」
という疑問を持ちます。
・「結局、現状での運用効率向上から要員を搾り出すしか
なかったのである。」という記述がありますが、実際には
本文を読み進めると「要員を搾りだした」のではなく
工数を削減して人員削減を行う対策を行ったようですね。
査読者によっては矛盾を感じるかもしれません。
・目標値の削減率がものすごい数値になっていますね、
事実に基づいた数値なのかも知れませんが、
「じゃあ今までのオペレータの仕事って大半が機械で
置き換え可能で無駄だったのか？」という感想を持ってしまいます。
・運用面での現場の工夫が少ないと思いました。
ハード導入で大半の問題が解決してしまっています。
査読者は、「Ｉ社の提案で大半が解決した事」ではなく
「記述者（あなた）の工夫で問題を解決した事」を求めているのでは
ないかと考えます。ＶＴＳ導入を決断した事を工夫とするのではなく
ＶＴＳ導入の中で発生した問題を記述者の工夫で解決したという
シナリオの方が合格率が高いと思われます。
この論文の場合、記述者の具体的な工夫は
データセット名のネーミングの頭文字の件になるでしょうが、
やや説得力に欠け、問題文の「工夫した点を中心に具体的に述べよ」
という要求には答えきれていないと思います。
・些細な事ですが「データセット名」とはＩＢＭ、日立、富士通の
汎用機の世界で通じる用語ですが。ＮＥＣの汎用機では通じません。
そもそも汎用機を知らない人にとっては不明な用語になるかも知れません。
念を押して「ファイル名」という記述にした方が無難かも知れませんね。
・この改善に開発部隊がどのように係わったかが不明です。
問題文にが「関連部門と協力しながら」と記述があり、
記述論文にも「システム開発部門と協力しながら」と記述
されているのに実際はほとんど「関連部門との協力」が
記載されていないようです。
・最後に「開発の初期段階からプロジェクトに参加し」という
記述がありますが、サーバーシステムの構築と開発は関連性が
ない場合があります。「サーバ構築とシステム開発を混同している」
という取られ方を防ぐためにも書き方を変えた方がいいかも知れないですね。
[320] すぎエモン (2009/10/14 Wed 17:01)
平成１８年午後Ⅰ問２を午後Ⅱとして書いてみました。
確かに勉強になります。
－－－－＋－－－－＋－－－－＋－－－－＋－－－－＋
１．情報システムの概要とインシデントの概要
１．１私が携わった情報システムの概要
私が勤務する会社は健康食品の販売会社であり、イン
ターネットを利用した販売を行っている。弊社では、Ｗ
ＥＢサーバやメールサーバなどのインターネット向けの
システム及び販売管理システムを構築している。私はそ
の情報システム部のＩＴサービスマネージャとして勤務
している。
弊社のシステム構成はバリアセグメントにＤＮＳサー
バ、ＷＥＢサーバ、社外メールサーバ、ＳＹＳＬＯＧサ
ーバがあり、ファイヤーウォールを中継し、社内ＬＡＮ
内に社内メールサーバ、販売管理サーバを設置している。
各サーバは同一のＯＳを使用しており、ＯＳのバージ
ョン及びセキュリティパッチのレベルは統一している。
また、各サーバまバックアップは、毎日３時からバッ
クアップ媒体に自動収集し、媒体は３世代分を保管して
いる。
サーバーのセキュリティパッチが公開された場合、ま
ず開発環境でテストを行った後、週末の夜間に全サーバ
を更新している。
また、全サーバについて、テスト環境として本番環境
と同じ機能をもつ開発環境がある。
１．２発生したセキュリティインシデントの概要
ある日、私は部下から前日分のＷＥＢサーバのログか
らの、２１時から２２時にかけて不正アクセスがあり、
侵入された可能性があるとの報告を受けた。
・
・
・
・
・
・
２．インシデントの検知から終了までのプロセス
２．１インシデントの検知から終了までのプロセス
報告を受けた私は、弊社の対応手順に基づいて、以下
の状況調査と処置を指示した。
①セキュリティ侵害の確認
バリアセグメント上及び社内ＬＡＮ上の全サーバとフ
ァイヤウォールに関するログを調査し、不正アクセスの
内容を確認する。
②関連部門へ連絡する。
③全サーバとファイヤーウォールについて、利用者のロ
グイン状況、インターネット接続状況及びプロセス稼動
状況を記録する。
この時、原因分析を確実に行えるよう、ハードディス
クのコピーをとることと、アクセスログなどを印刷する。
④不正アクセスの再発を防止するため、インターネット
の接続を遮断する。
その結果、以下のような報告があった。
①ログ調査の結果、不正アクセスの経路が判明し、ＷＥ
Ｂサーバだけが不正アクセスされていることが判明した。
②ＯＳメーカーのホームページでセキュリティ情報を調
査した結果、今回の不正アクセスはＯＳのセキュティホ
ールを利用したものであることが判明した。そこで、セ
キュリティパッチが適用されているか確認したところ、
開発環境ではテストを完了していたが本番用サーバには
まだ適用していなかった。
③ＷＥＢサーバの被害状況については、ＷＥＢサーバ上
に隠しディレクトリが作られており、その中に不審なフ
ァイルの存在が確認された。
２．２復旧作業
以下の手順で復帰作業を指示した。
①ＷＥＢサーバ上に発見された不審なファイル意外にも
被害を受けている可能性があると判断し、一世代前のバ
ックアップ媒体を用いてＷＥＢサーバを復旧する。
②不正アクセスを受けたＷＥＢサーバとほかの全サーバ
に対してセキュリティパッチを適用する。
③①、②の作業が完了しだい関連部署に連絡し、インタ
ーネットを再開する。
３．評価と今後の改善
３．１評価
今回のインシデントについて、私に報告があったのが
結果的に、不正アクセスの翌日の１０時あった。また、
その原因分析から対応終了まで約○○時間を要した。
これはＳＬＡで取り交わした合意内容を満足するもの
であるが、システムの安全性から考慮すると、必ずしも
安全ではないと考えられる。今回の被害はＷＥＢサーバ
のみであったが、その他のサーバに被害が及び可能性が
ないわけではない。
３．２今後の改善
今後の改善として以下が考えられる。
①ＳＹＳＬＯＧサーバの移設
ＳＹＳＬＯＧサーバについてはバリアセグメントに設
置しているため、今回のＷＥＢサーバのように侵入や改
ざんが考えられる。ファイヤーウォールの内側に設置し
セキュリティを確保したい。
②侵入探知システム
侵入探知システムを追加することにより、不正アクセ
スの発見時間の短縮が望ましい。
③待機系サーバの追加
全サーバについて、不正アクセスや改ざんがあった場
合、サービスの停止時間を短縮するために、全サーバに
ついて待機系を構築し、切り替えてサービスを再開でき
るような構成を作り上げたい。
[317] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/10 Sat 01:04)
すぎエモン様
添削ありがとうございます。
ご指摘の点、修正してみましたので
読んでみてください。
ありがとうございます。
それにしても、論文は難しいです。
私の場合、いつも感じるのですが
設問アはパターンどおりに書きます。
設問イ、問題文にそって書き進めますが
途中で何を主張したいのか、だんだん
わからなくなってしまいます。
また、用意している論文とぴったりとは
あわないので、無理やり合わそうとする
ところから、頭の中がぐちゃぐちゃになって
しまいます。とほほーーーー
平成２０年午後Ⅱ問３
－－－－－－－－－＋－－－－－－－－－＋－－－－＋
１．情報システムと障害について
１．１ 私が携わった情報システム
私が勤務する会社は愛媛に本店があり中四国を中心に
１５０店舗をもつ地方銀行である。私はその銀行の情報
システム部門でシステム管理エンジニアとして勤務して
いる。
私が携わっている情報システムはホストシステムであ
り、勘定系、情報系、開発系、ナイトオンラインの４種
類のサブシステムが稼動している。稼働時間は毎日６：
００から２４：００の間は勘定系、情報系、開発系が稼
動し、２４：００から翌朝６：００までの間は勘定系の
機能を限定し、性能を縮小させたナイトオンラインを稼
動させ、２４時間のオンラインサービスを提供している。
１．２ 障害の内容と業務の影響
毎日２４：００から勘定系システムからナイトオンラ
インシステムへの切り替え処理を実施しているが、曜日
によって切り替え前処理が異なっている。金曜日以外は
データーベースの更新処理をしてから切り替え、金曜日
についてはデーターベースの更新処理をしないで切り替
える。ただし、月末には曜日にかかわらず、データーベ
ースの更新処理をしてから切り替える手順であった。
今回、月末の金曜日に障害が発生した。通常、金曜日
はデーターベースの更新処理をしないで切り替える手順
であったが、月末であったためデーターベースの更新処
理後、切り替える手順であったが、２４：００を過ぎて
も更新処理が終了せず、１時間後の２５：００に更新処
理が終了し、切り替え処理を完了した。２４：００から
２５：００の１時間オンラインサービスが停止し、イン
ターネットバンキング、コンビニＡＴＭのサービスが約
１５０件不能となった。
２．障害の原因究明と対策立案と実施
２．１ 障害の原因追求
システム障害が想定を超えて長時間化した場合、それ
による損失は甚大なものとなるため、次のような視点か
ら長時間化した原因を究明した。以下にその分析結果を
列挙する。
①連絡は適切な時間内に実施できたか
この日２１：３０からのデータベース更新処理につい
て、オペレーターから早い時点で、正常処理はしている
ものの処理速度がいつもより少し遅いような気がする。
異常ではないかとの連絡が開発担当者と運用担当者に連
絡が入っていた。連絡については初動の遅れはないと判
断した。
②情報は適切に収集できたか
開発部門及び運用部門について、関係する社員にはす
べて連絡済であり、全員出社していた。処理状況につい
てオペレーターが全員に報告し、処理を監視していた。
情報は適切に収集できたと考えた。
③手順は適切であったか
今回の障害の原因はデーターベースの更新処理のプロ
グラムであった。スケジュール、更新処理に問題はなか
ったため、更新処理を強制終了させることなく、終了す
るのを待ってから切り替えを実施した。オンラインサー
ビスを停止させることになってしまったが、データーベ
ースの更新処理は必須であったため、手順は適切であっ
たと判断した。
④想定外の事態に適切に対応できたか
今回の障害では想定外の事態はなかった。
⑤部門間の連携は適切であったか
数年前から会社の方針として、セキュリティ等の問題
から開発と運用を分離する体制づくりが進められてきた。
その結果、部門間の連携がうまくいかず、開発部門は運
用部門のことをあまり考慮しないで開発を進めるように
なり、運用部門に引継いだ時に始めて運用できないこと
に気づき、急遽プログラムを修正をしなければならない
ような不具合が度々おこるようになってきた。
今回の障害の直接の原因はプログラム変更であったが、
開発担当者から運用担当者に事前にプログラムを変更し
たことの連絡をしておけば、今回の障害は避けることが
出来たと考える。
２．２ 対策立案と実施
(１)特に重要と考えた対策
開発部門と運用部門間のレビューの実施と相互確認
(２)その理由
障害発生時の連絡の実施等は電話連絡網を作成し、定
期的に訓練を実施しているため、問題ないと判断した。
情報収集についても、定期的に障害訓練を実施してい
るため、問題ないと判断した。想定外については、障害
対策としては優先順位が低いと考えた。
やはり、開発部門と運用部門のレビューの実施と相互
確認については、とても有効な対策と考えた。開発担当
者は正しいと思っていても運用側のスケジュールでは不
具合があったり、運用側では正しい思っていてもプログ
ラムがスケジュールにあっていなかったりすると今回の
ような障害が発生する。
レビューには「システム運用定例会」と「障害対策会
議」の２つを実施するようにした。
「システム運用定例会」は月１回開催を原則とし、開
発部門と運用部門の当月の実績と翌月以降の予定を報告
・連絡・相談する会議である。また、この会議をきっか
けに担当者レベルの設計等の打ち合わせも出来るように
なった。
「障害対策会議」も同様に月１回開催を原則とし、障
害の状況、原因、対策、今後の課題を報告・連絡・相談
する会議である。
この対策について、レビュー実施の作業コストが増加
するが、障害を事前に予防できたことと、障害発生によ
る損害と比較すれば、十分な費用対効果があると判断し
た。
また、レビューを実施することにより、開発部門と運
用部門のコミュニケーションが活発に取れるようになり、
プログラム作成時に運用を考慮したシステム作りができ
るようになると考えた。
３．対策の評価と今後の課題
３．１ 対策の評価
私が実施したレビュー実施の対策はとても高く評価さ
れる内容であった。なぜなら、対策を実施して約６ヶ月
間が経過するが、相互確認漏れによる障害は発生してい
ない。また、開発部門からは運用部門に対する不平・不
満が以前よりは減ったとの評価をもらっている。
３．２ 今後の課題
レビュー実施による相互確認は効果的であったが、こ
の対策も時間がたつにつれて慣れが発生し、思い込み等
による障害を引き起こす可能性があると考えた。
そのためには、レビュー実施後、実施内容を文書にま
とめ第三者的な立場である社員に判断してもらうような
仕組みづくりに取り組んでいきたい。
以上
[286] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/08/18 Tue 20:06)
前回の論文よりもぐっと良くなりました。
『良くなった点』
・ナイトオンラインの説明が素晴らしいですね、短い文章で適切に
説明されており、査読者の興味をぐっと引き込む書き方になっています。
・「その結果、部門間の連携がうまくいかず、開発部門は運
用部門のことをあまり考慮しない」の部分は、読む人に
「あるある」と思わせる内容ですね。ありがちな問題点
というのは査読者にも理解しやすくポイントが高いです。
・結果的に論文のレベルがあがっていると思います。
前回の論文よりもかなり合格に近づいた内容に
改善できたのではないかと考えます。
『気をつける点』
・今回は既存の論文に手を加えて改善をされたようですが、実際の
論文は手書きの一発勝負です。よって、ワープロの様に
文章を追加したり削除したりというのも困難です。
よって、論文記述に慣れてきたら、一度書いた論文の修正は
行わず、常に一発勝負でゼロから２時間以内に書き上げる訓練が
必要になってくると思います。
・私は事前に雛形論文は用意しない様にしていました。これは可能な限り
問題文に問われている事に内容を一致させるための工夫です。
雛形論文を用意すると、「問題文で問われている事に内容を沿わせる」事と
「雛形論文にすり合わせる」という二重の命題を抱えてしまい
論文作成が困難になってしまいます。「雛形論文は用意しなくとも
問題文が雛形になるからいいや」と考えていましたね。
[287] すぎエモン (2009/08/19 Wed 08:46)
すぎエモン様
確かに雛形論文にすり合わせようとして
わからなくなったような気がします。
ゼロから２時間以内に書き上げる訓練を
してみます。
ありがとうございます。
[288] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/08/19 Wed 20:37)
ウの字数を満足しています？何か短すぎるように感じるんですけど。
[312] ＤＵＫＥ (2009/10/02 Fri 22:25)
ウの字数については、ＩＴサービスマネージャ試験の場合は満足していません。しかし、この問題はテクニカルエンジニア（システム管理）試験問題であるため、設問ウの文字数は問われません。設問イ、ウの文字数を合わせて１６００字以上にする必要はありますが。その条件は満たしているようです。
ＤＵＫＥさんのおっしゃるとおりもう少し設問ウの部分にも文字数があった方が良いとは思いますが、テクニカルエンジニア（システム管理）の場合は。それが不合格に直接繋がる要因にはならないと考えます。
[313] すぎエモン (2009/10/03 Sat 00:30)
補足すると、ＩＴサービスマネージャ試験の場合は、設問ア、イ、ウの全てで文字数が決められており、そこがテクニカルエンジニア（システム管理）と大きく異なる点です。論文記述時は注意する必要がありますね。
[314] すぎエモン (2009/10/03 Sat 00:38)
設問ア：８００字以内
設問イ：８００字以上１６００字以内
設問ウ：６００字以上１２００字以内
ですよね。
８００＋８００＋６００＝２２００字で合格でしょうか？
春のプロジェクトマネージャの問題を見ると
出題傾向がかわり、ア、イ、ウとも
記述内容をかなり絞り込んでくるように思われます。
[315] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/10/06 Tue 20:15)
重点対策のP424に合格者の方の貴重な体験談がある。是非読んでいただきたい。
きっと、皆さまの自信になるでしょうし、残された時間での効率的な学習方法のヒントが分かるでしょう。
一つお詫び。誤植があります。
「ネタ集めの方法として、（中略）、過去問の午後Ⅱ試験を参考にしました」とありますが、午後Ⅱではなく、午後Ⅰです。以下、2か所に同じミスがあります。
申し訳ございません。
[311] 管理者 (2009/09/30 Wed 10:34)
はじめまして。
管理者様の書籍を購入して勉強していますが、以前から気になっていることがあります。
P33の午後Ⅰの出題傾向分析の表で、「分野」欄の数字は何に対応するのでしょうか。
欄外に以下の注釈があります。
「分野については、この後で説明する演習問題の番号を参照のこと」
表の「演習問題」欄の数字が、第3部 午後Ⅰ対策の演習問題の番号に対応しているようなのですが、「分野」についてはどう理解すればよいでしょうか、、、
お忙しいところ恐れ入りますが、管理者様、もしくは同書籍で学習している皆さま、コメントいただけると幸いです。
[306] とんがらし (2009/09/23 Wed 23:47)
とんがらしさん
ご指摘ありがとうございます。
完全な誤植です。申し訳ございません。
出版に際し、複数人でのチェックを実施しておりますが、不十分だったようです。
今後はこのようなことが無いように気をつけます。
大変失礼いたしました。
[307] 管理者 (2009/09/24 Thu 07:42)
管理者様
早速のご回答、ありがとうございます！
なるほど、記載の誤りだったのですね。
ちなみに、「分野」について本書のどこかに説明がございましたら、ご教示いただけるとありがたいです。
そもそも、この表で使用されている「分野」を、自身の学習計画の作成や弱点分野の判断の目安にしたいと思っていたのです。
[308] とんがらし (2009/09/25 Fri 01:03)
削除すべきところを削除しなかった誤植になります。
2008年度版の残骸でした。
旧試験と新試験で、分野がITILベースに大きく変わりました。なので、過去問との対応付けができない状態であります。
申し訳ございません。
こちらの誤りでありながら、温かくご対応いただきましてありがとうございました。
[309] 管理者 (2009/09/25 Fri 07:32)
管理人様
ご丁寧にありがとうございました。
了解です！
分野わけ、難しいですね、、、
[310] とんがらし (2009/09/26 Sat 16:45)
初めて投稿します。
私は開発ベンダーに所属していて、顧客のシステムを運用しているのですが、
今回午後Ⅱ試験の設問アでどのような立場を記載するのがいいのか迷っています。
ベンダーとして立場を詳しく書くのがいいでしょうか。
社内の情報システムについて記載するのであれば、分かりいいのですが・・・。
（ITILだと、顧客（決裁者）とSLAを結ぶのは顧客内のプロバイダ（情報システム部門）というのもあり、サプライヤーとしてのベンダーとしての立場は伝えにくそう。考えすぎですか。）
[297] だっく (2009/09/04 Fri 07:30)
だっくさん初めまして、すぎエモンと申します。
『ベンダの立場』『顧客の立場』のどっちで
書くべきかでお悩みかと察します。
個人的な見解は、『どちらでも構わない』と思います。
大事なのは『どちらが査読者に分かりやすく伝わるか』だと
思います。
開発ベンダーに所属する立場の場合、ベンダ技術者と
しての立場と情報システム運用部門の立場が別になるので
２つの視点から論述せざるを得ない場合があります。
よって、論文内容の簡潔性や一貫性に欠ける場合があります。
ただし、現実性には優れることが多いですね。
顧客の情報システム部門に所属する立場の場合、
情報システムを運用管理する立場にブレが起きにくいので
論文内容の簡潔性や一貫性に優れます。
しかし、論述者の立場を偽る事になるケースが
多いので、論述者が上手く『顧客側の立場』を
演じきれないなら、正直にベンダ技術者の立場で
論述した方がよいのではないでしょうか？
ちなみに私は現実はベンダ側の技術者ですが、
論文記述の際は『顧客側の立場』で、『情報システム部門
に所属するシステム管理エンジニアである』と言い切りました。
この方が、論文を簡潔に記述できると判断したためです。
ちなみにITサービスマネージャ試験は、ITILの理解度を問う
事が目的ではありませんので、あまりITILを意識しすぎる
必要はないのではないかと考えます。あくまでも参考程度に。
現実のシステム運用管理の現場で、ITILをバイブルとして
運用を行っていることって、あんまり見かけませんからね。
[298] すぎエモン (2009/09/04 Fri 08:43)
ご意見、ご指摘ありがとうございます。
まずは、簡潔にベンダーとしての立場で記載する訓練をした上で
試験に挑みます。
どうしても分かりやすく書けない、一貫性が保てない時には、
『情報システム部門に所属するシステム管理エンジニアである』
としますが、最終手段にいたします。
『ITILも参考程度に』、ということで気が楽になりました。
ありがとうございました。
[299] だっく (2009/09/04 Fri 17:14)
すぎえもんさんの見解で良いと思います。
補足します。
やらないほうがいいのは、利用者、顧客である情報システム部、ベンダ（だっくさん）の３者が常に存在する論述です。
例えば、利用者からの問合せに対し、ベンダの立場である私は、契約上の顧客であるA社の情報システム部門のBさんと相談した。
書いている立場からすると、事実に基づいて書いているだけと思いますが、読んでいる（採点者）の立場からすると、わかりにくいだけです。
採点者が採点する本質論は、「ITサービスマネージャとしてどう考えて、どう対応したか？」です。本質論ではない記述は、省略できるなら省略しましょう。
私もSIer（ベンダ）ですが、論文ではベンダの立場ではなく、社内の情報システム部として書きました。
[300] 管理者 (2009/09/06 Sun 07:21)
管理者様、ありがとうございました。
気になった点としては、アンケート（質問書）に、所属する企業・機関を記入する点です。
論文には、社内の情報システム部として書くが、
アンケートには情報処理サービス企業と書く分には問題ないと
考えてよろしいでしょうか。
（所属は情報処理サービス企業だが）
顧客の情報システム部門のITサービスマネージャとして勤務している
イメージで考えています。
[303] だっく (2009/09/20 Sun 13:47)
管理者です。
久々に書き込みの時間がとれたので、簡単にコメントします。
>論文には、社内の情報システム部として書くが、
>アンケートには情報処理サービス企業と書く分には問題ないと
>考えてよろしいでしょうか。
ご自分はどう思われますか？
冷たい言い方と思わないでください。
ご自分で納得できる理由も含めて結論を出すことが大切です。ここでも論理的思考が大切です。
[304] 管理者 (2009/09/22 Tue 20:48)
もう一度、考え直したのですが
論文に自社システムの運用をしていると記載している場合は、
「12.あなたが所属する企業・機関など」に、
ユーザ企業を選択するのが無難だと思いました。
ソフトウェア企業を選択すると、論文内容との不整合により
減点されるかもしれないからです。
論文の記載内容に素直に従うようにいたします。
[305] だっく (2009/09/23 Wed 21:52)
初めての投稿になります。
まさおと申します。
本サイトは非常に参考になっており、
試験に向けて、非常に助かっております。ありがとうございます。
さて、試験のシラバスが公開されていたので、
拝見致しました。
ITILバージョン2が基本とされているようですが、
バージョン3の範囲・用語は本テスト範囲外と認識して
よいのでしょうか。
正直、バージョン2と3が混在すると非常にややこしくなるので、
助かります。
が、明示的に『バージョン2』を範囲とするとも
記載されておらず、もやもやした気持ちです。
もし、皆様がご存知のことがあれば、
お教えいただきたい次第であります。
宜しくお願い致します。
[295] まさお (2009/09/02 Wed 16:29)
久々の投稿です。
いつもはすぎえもんさんに助けてもらっています。
ありがとうございます。
ご質問に関しては、TOPページに記載してます。
ご質問とは無関係にたまたま書いた記事ですので、問いかけに対応しているかはわかりませんが。
よろしくお願いします。
[296] 管理者 (2009/09/03 Thu 22:08) web
ご回答、ありがとうございます。
迷いが吹っ切れました。
TOPページを見落とし、申し訳ありませんでした。
[302] まさお (2009/09/08 Tue 12:37)
TOPページに記事を日々更新してます。
http://sm.xn--n9q36mh1hnxuksz7wt.net/
以前は、TOPページの表示件数が4件だったため、古い記事がすぐに消えてしまいました。
ITILv2とv3の記事も消えてしまいました。
今はTOPページの表示件数を10件にしました。
また、もっと古い記事を見たい場合は、WebボタンのURLにて確認できます。
今後とも、当サイトをよろしくお願いします。
[301] 管理者 (2009/09/06 Sun 07:35) web
始めまして、りんと申します。
今秋の試験を目指して学習を始めるにあたって、ホームページを拝見させて頂きました。
内容が分かりやすくまとまっていて、非常に勉強になりました。
ありがとうございました。
現在は「論文のコツ」でご指摘されている内容に重点に注意して（いるつもりで）、過去問題を解いています。しかし自分が書いた内容なので、自分自身で採点するのが難しいです。
恐れ入りますが、可能であれば添削お願い出来ますでしょうか。
感想、コメントでも構いませんので、よろしくお願い致します。
H16 午後Ⅱ春期 問３
■■■■■■■■■■■■■■■■■■■■
「障害の切り分け」について
■■■■■■■■■■■■■■■■■■■■
設問ア
１．私が携わった情報システムの概要
（１）Ａ社の業務内容
Ａ社は資産運用会社である。従業員数はおよそ100名。本社は東京にあり、支社や店舗はない。Ａ社は資産の70％ほどを複数の金融機関に運用の委託をしている。また複数の金融サービス会社から、株式や債券の銘柄情報、格付け情報を取得している。業務で使用するシステムはＢ社が開発したものである。
（２）自分の立場
私はＢ社のシステムエンジニアである。Ｂ社は信託銀行の子会社のシステム会社である。Ａ社とＢ社は保守・運用支援の契約を結んでおり、現在Ｂ社の社員８名がＡ社に出向している。またＢ社の本社に障害対応と開発要員が１０名待機している。私はＡ社に出向する一人である。
（３）システム概要
Ａ社のシステムはＢ社の単独運用指定金銭信託に関するシステムをベースに開発されたものである。本システムの機能は主に次の２つである。
１つ目は、金融機関がＣＤに記録した毎月の資産運用結果である取引情報や残高情報をデータベース化すること。
２つ目は、Ａ社が保有する全ての株式・債券の銘柄情報・格付け情報を金融サービス会社からダウンロード（購入）し、データベース化すること。
（４）機器
Ａ社の社員は全員に２台の端末を与えられている。端末はそれぞれ用途が異なる。1台目は主にインターネットやメールを使用するために使われる。２台目はＢ社のデータベースにアクセスし、資産運用業務に必要な情報を取得するための端末である。サーバは全部で３台ある。１台は既述した、データベースを格納するためのサーバである。他の２台は社内ネットワーク上のファイルを保存するファイルサーバである。全てのサーバの内容は、外部に接続された磁気テープ装置に、毎日にバックアップされている。
２．切り分けができなかった障害
ある日、データベースを格納しているサーバのディスプレイにエラーが表示された。内容は「サーバに接続されている機器を認識出来ない」というものだった。
設問イ
１．作業の統括
（１）エラー内容調査
最初に、Ｂ社の作業員がサーバのディスプレイに表示されているエラーの内容を調査した。エラーの内容は「サーバに接続される機器が確認できない」というものだった。
（２）ログ調査
２番目に、サーバのコンソールに出力されているログを調べた。しかしログの内容もエラーのメッセージと同じ内容であったため、障害の原因が、サーバにあるのか、磁気テープ装置にあるのか、機器間を結ぶ接続コードにあるのか原因の切り分けができない状況だった。そのため本環境のサーバ機器のメーカであるＣ社のヘルプデスクに連絡した。
（３）Ｃ社ヘルプデスクに連絡
Ｃ社のヘルプデスクは、エラーとログの内容からは原因の内容を限定できないため、作業者による現地調査を提案した。また磁気テープ装置が原因である場合に備え、交換用の磁気ディスク装置と接続コードを用意した。
（４）Ｃ社による実地調査
Ｂ社作業員は最初にＣ社作業員による磁気テープ装置の調査を依頼した。その結果、原因は磁気テープ装置にあることが判明した。根本的な原因は次の３つが考えられた。
①磁気テープ装置の接続部の破損
②磁気テープ装置の外部接続機の故障
③磁気テープ装置のＣＰＵの故障が考えられた。
（５）対応作業による影響
①と②の場合、接続機器周辺の交換作業が発生する。作業には磁気テープ装置の電源を切る必要があるが、他の機器への影響はない。
③の場合、磁気テープ装置そのものを交換する作業が発生する。作業にはサーバの電源を切る必要がある。そのため、Ａ社の業務に影響をもたらす。
（６）統括
可能な限りＡ社の業務に与える影響が少ない方針を検討し、影響の少ない箇所から作業を行うことで対応とした。
２．切り分けの方法
（１）障害事象と機器構成との関連性
今回の障害の切り分けで最も工夫したのが機器構成の関連性である。上述の理由から可能な限りサーバは停止しないよう、機器の原因を調査し対応する必要があった。
主に工夫した点は、最初に磁気テープ装置から調査を始めたことである。これは、磁気テープ装置は深夜のバックアップ処理が開始されるまでは取り外してもＡ社の業務に影響がないことを考慮したためである。
更に磁気テープ装置を調査したところ、接続機器に原因があることが判明した。しかし接続部のどこに原因があるか特定するためには、実際に原因があると思われる箇所を交換する必要があった。そのため、Ａ社の業務にもたらす影響が少ない箇所から危機の交換を行い、障害事象が解決した時点で、原因の切り分けとすることにした。
（２）ソフトウェア構成との関連性
ソフトウェア構成の関連も調査した。表示されたエラーメッセージとログの内容からは、上述の情報を入手し、Ｃ社のヘルプデスクに連絡し、事前調査を依頼した。
（３）障害事象の整理・関係性調査
ヘルプデスクに連絡する際、ログが出力されている時間から、障害の発見までの事象を時系列に整理し、Ｃ社のヘルプデスクに報告した。ログが出力されていたのは先日の深夜３時頃で、その時間帯は昨日のバックアップ処理中であった。
（４）発生した障害事象と類似する過去の障害事象の調査
Ｂ社の障害発見者は、Ｃ社のヘルプデスクと並行して、Ｂ社本社に連絡し、過去に同様の障害が発生していないか調査を依頼した。
設問ウ
１．評価
今回の対応の評価は低くはないものだった。障害の切り分けができないケースはこれまで少なかったため、障害を悪化させず復旧させたことについては評価された。しかし調査方法が試行錯誤で行ったため、別の障害を引き起こしていた可能性もあると指摘された。
２．今後の改善点
（１）ログの詳細出力設定
サーバにログの内容を詳細に出力するよう設定を変更する。しかし、それによって全ての障害の原因を切り分けができるようになるわけではないことは留意事項として指摘された。
（２）Ｃ社ヘルプデスク、作業者との連携強化
詳細なログを出力することでＣ社のヘルプデスクにより厳密な情報を提供する。また、現場に到着した作業者が作業を開始する前に、事前にＢ社の見解とＣ社の見解を話し合い、事象を再確認するようにする。
[292] りん (2009/08/31 Mon 23:37)
はじめまして、すぎエモンと申します。
僭越ながらコメントさせて頂きます。
【良いと感じた点】
・小見出しの付け方は、設問に準じており、
忠実に問題に答えようとする意志が感じられました。
・問題文に書かれている事も、「論文に盛り込むべき事」
と認識して、丁寧に拾っている努力を感じました。
・現実的な記述が、各箇所に見受けられ、実際の経験を元に
論文を構築されている事を強く感じました。
【気になった点】
・設問アについてですが、制限文字数の８００字を
オーバしていませんでしょうか？制限文字数には
空白や改行も含まれますのでご注意下さい。
・「交換用の磁気ディスク装置」とありますが、
磁気テープ装置の障害なのに、何故磁気ディスク装置が
必要になるのかという疑問を感じました。
・「主に工夫した点は、最初に磁気テープ装置から調査を
始めたことである」という記述がありますが、理由が
弱いような気がします。査読者が、「原因がよく分からない
から調べやすいところから適当に当たりを付けて調べていった
のかな？」という感想をもってしまう可能性があります。
その場合、システム管理者として行き当たりばったりすぎる
という評価をされてしまうかも知れません。
・（２）ソフトウェア構成との関連性は、問題文に書かれている
事から記述したと推測しますが、前後の展開との関連性が無く
無理矢理記述したような感覚があります。問題文に書かれている
とはいえ、本文にうまく組み込め無かったら、記述しなくても
よいと思います。
・主題である「切り分け」については詳細に記述されているようですが、
今回の障害が「何が根本原因」で「どうやって解決したのか」が
十分に説明されていないようです。これがハッキリしないと
切り分けが正しかったかどうかの「評価」が困難になりますので
しっかりとした記述が必要になるかと考えます。
・全般的に現実の事象の詳細を説明しようとし過ぎて、分かりにくくなって
いたり冗長な記述が多いのではないかと考えました。あまり実際の
出来事に忠実にしようと考えず。読み手に伝わりやすいように、
システム状況や障害内容をシンプル化して簡潔に記述しても
よいのではないでしょうか？
例えば、問題文に「関係者を招集して」とあるので、関係者を
招集して皆で障害事象を分析した事にすると、問題への忠実性も
向上します。更に本文にあるヘルプディスクとの複数回に渡る
やりとりも必要なくなり、全体をスッキリと短く記述できます。
【誤字脱字】
・危機の交換
→機器の交換
[293] すぎエモン (2009/09/01 Tue 12:58)
すぎエモン様
適切で分かりやすいアドバイスをありがとうございます。
特に、事象の詳細の説明について書き過ぎていないか、丁度悩んでいたところでした。ご指摘いただくことが出来ましたので、とても勉強になりました。
ご指摘頂いた点を改善して、残りの期間学習したいと思います。
お忙しい所ありがとうございました。
りん
[294] りん (2009/09/01 Tue 22:04)
はじめて書き込みします。ロナと申します。
今秋、旧システム管理も含め初めて
ITサービスマネージャ試験に挑戦します。
論文試験も初挑戦です。
非常に読みやすいサイトですね。
特に論文対策の部分を参考にしたのですが
実際に自分で論文を書いてみると大変難しいことが
わかりました。
少し古い過去の問題ですが、論文を投稿いたします。
お時間があるときで構いません。
コメントいただけると幸いです。
--------------------------------------------------
【情報システムにおけるサービスレベルについて】
--------------------------------------------------
１.サービス概要とサービスレベル
１－１．私が携わったサービス概要
私は情報システム会社に勤務しておりシステム管理者
として従事している。今回述べるシステムはＺ社の受発
注業務のデータ交換システムである。Ｚ社は小売業であ
り、取引先３社からの受注、メーカー・卸５社への発注
などのデータ交換を行うシステムを自社のＡＳＰサービ
スにて運用している。システムでは、データの送受信及
びフォーマット変換処理を行っており１日あたりのデー
タ送受信回数は合計５０回である。
システムを運用する上で合意しているサービスレベル
は以下の通りである。
・障害及びエラー通知時間は１５分以内とする。
・障害回復時間は３時間以内とする。
・システム稼働時間と稼働率は利用するＡＳＰサービス
の標準に従い２４時間３６５日、９９．９％とする。
１－２．重要と考えた項目の設定理由と基準値
「障害及びエラー発生時は１５分以内に状況連絡をす
る」が重要と考えた。理由は、受発注業務を中心とした
データ交換サービスであるためシステムの停止がＺ社の
業務停止を引き起こす原因となるからである。本来であ
れば迅速なシステムの障害回復が望ましいが重度の障害
の場合、回復まで時間がかかることが予想される。その
ため障害回復中にも代替手段にて業務が継続できるよう
Ｚ社にシステムの状況を迅速に伝えることが重要だと考
えた。連絡を受けた後、Ｚ社ではシステム障害時の緊急
対応としてＦＡＸや電話業務に切り替えるなど損失拡大
を防ぐ対応を取ることができる。
システムは冗長化構成となっておりサービス継続困難
な場合には１０分程度で自動的に待機系に切り替わる。
１５分と設定した理由は、障害の状況から回復までの見
通しを最低限判断するために必要な時間を考慮した。
２．サービスレベルの維持と具体的な方策
システム管理エンジニアとしては、あらゆる場面を想
定して合意したサービスレベルを維持するよう運用体制
を整えておくことが重要である。
２－１．現行システムの障害検知方法
障害及びエラー検知についてはサーバのハードウエア
、基幹アプリケーション、Ｚ社個別のアプリケーション
、ネットワーク状況について実施している。検知方法は
サービスを運用しているシステムとは別のシステムより
ツールを用いてログの内容を監視している。ネットワー
クは一定間隔の死活監視を行っている。
障害及びエラーが発生した場合は、ヘルプデスクの監
視端末にログの内容を表示し合わせて音によるアラート
鳴動とパトライトの点灯によって監視者が検知する。監
視者は表示されたログ内容に基づき運用マニュアルに従
い対応する。具体的には、サービス利用者へのエラー内
容の連絡、自社内の関係各部署への連絡、エラー対応コ
マンドの実行などである。
２－２．サービスレベルの基準値と実測値
Ｚ社サービス導入後、ある特定の取引先からのデータ
に不備がありＡ社個別のフォーマット変換プログラムが
エラー終了することが数日間続いた。ヘルプデスクでは
運用マニュアルに従いＺ社へデータ変換エラー発生を伝
えＺ社を通じて取引先へ修正したデータの再送信を依頼
していた。しかし毎回同内容のエラーであり、発生時間
もＺ社の営業時間を過ぎた時間であったためＺ社の障害
連絡先に電話がなかなかつながらないことがあった。そ
のためエスカレーションによって第２連絡先であるＺ社
システム担当者個人への携帯電話へ連絡する回数が増え
ており１５分以内の連絡が危ういこともあった。また自
社ヘルプデスク側では本来の業務に支障をきたす恐れが
あるとエラーに対する不満が出ていた。
後日、エラー元の取引先より「システムの不具合があ
りフォーマット変換エラーが続いているがすぐには対応
できない。Ｚ社にも迷惑をかけたくないためアラートを
無視することができないか」との依頼があった。
２－３．Ｚ社とのフォーマット変換エラーに関する協議
現状では第２連絡先へのエスカレーションにより、合
意したサービスレベルは維持できているものの連絡がつ
かないリスクを抱えているためＺ社と打ち合わせを行っ
た。また同時間帯に重度の障害が発生した場合、ヘルプ
デスクの対応人数不足が原因で他のＡＰＳサービス利用
者にも悪影響が生じるリスクを説明した。Ｚ社でも担当
者個人への負担が続いていたためリスクの認識は一致し
ていた。
エラー対応に関するヒアリングを行ったところ、取引
先からの受注データであるためＺ社としてはエラーであ
っても受信したい。取引先のデータ不備は軽微な内容で
あるためＺ社側でも修正は可能であり深夜の受注締め時
間までに間に合えばよいとのことであった。
２－４．サービスレベルの改善
ヒアリングの内容を踏まえ私は以下のようなエラー発
生時の対応内容の変更を提案した。
（１）取引先のシステム不具合が解決するまでエラーが
発生したデータをＺ社が受信できるような設定を追加し、
受信後、Ｚ社にてデータを修正し取り込みをおこなう。
（２）このエラー発生時の連絡は、電話連絡に加えメー
ル連絡を行う。電話がつながらない場合にはメール送信
にてエラー連絡完了とする。その他の障害などの場合は
通常通り電話連絡とする。
加えて、現状では第２連絡先までエスカレーションす
ることも多く今後連絡がつかないリスクも考えられるた
め新たに第３連絡先を新設してもらうことにした。
Ｚ社も提案内容に合意し、翌日より運用することにな
った。自社ヘルプデスクへはエラー時の対応変更に伴い
新たに対応マニュアルを作成し混乱が起きないように説
明会を実施した。
３．方策の評価と今後の課題
３－１．方策の評価
提案したエラー発生時の変更によりサービスレベルが
維持できないリスクは以下の点において軽減できたと評
価している。
（１）ヘルプデスクでのエラー対応作業が簡略化し、電
話での連絡がつながらないという不安が解消できた。
（２）作業の簡略化により本来のヘルプデスク業務に注
力することが可能になった。
Ｚ社においてもエラーデータの修正による多少の手間
はかかるものの受注機会を逃すことはなかった。また取
引先のシステム不具合にも関わらず、データの取り込み
を行い受注処理を継続したことでＺ社と取引先間の信頼
を深めるきっかけとなった。
３－２．今後の課題
一時的なエラー対応の変更によってサービスレベルは
維持することができたが、あらかじめ想定可能なエラー
であったのではないかと考えている。導入前に業務内容
をヒアリングし、サービス継続困難な障害連絡とＡ社個
別のアプリケーションエラーを分けてサービスレベルを
設定すれば、このような一時的な変更も実施しなくても
済んだのではないかと考えている。
この経験を生かし、今後業務内容や状況に合わせたサ
ービスレベルの設定について考慮していきたいと考えて
いる。
＜以上＞
[275] ロナ (2009/07/18 Sat 00:52)
ちょっと眠いので、コメントがずれているかもしれませんが、、、
■１－１
・サービス概要を述べてください。
SLAは１－２で書きましょう。
・問われていることに忠実に答えることが大事です。
■１－２
・「重要と考えた項目の設定理由」を端的に言うと何ですか？
・問題文にもあるように、SLAは「ユーザと合意の上で設定する」
のです。しかし、今回の記述を読む限り、合意があったように
感じません。「これらの結果をユーザと合意して設定した」という
記述があると良いでしょう。
・
> システムは冗長化構成となっておりサービス継続困難
>な場合には１０分程度で自動的に待機系に切り替わる。
>１５分と設定した理由は、障害の状況から回復までの見
>通しを最低限判断するために必要な時間を考慮した。
この意味が良く分からないです。
自動的に切り替わるなら通知する必要性は薄いですよね。
問われているのは「重要と考えた項目」。自動で切り替わるなら、
業務に支障がでないですから。
ということは、ロナさんは自動的に切り替わらなかった場合が
「重要」と想定しているのでしょうか？そうであれば、15分の
根拠がわかりません。
■２
読むのが辛い、、、
エラーを通知するだけでしょ。エラーと分かっているのであれば
すぐ通知すれば良いのでは？なぜ15分を超えるんでしょうか？
・・・
とりあえず、ダウンです。
頭が冴えているときにもう一度読ませてもらいます。
今の状態での私の評価
C
採点官に読みやすい論文にしてください。
[276] 管理者 (2009/07/19 Sun 23:26)
こんばんわ。ロナです。
コメントいただきありがとうございました。
お疲れのところに加え、読みにくい文章で失礼しました。
今一度、問題文と参考書を読み直し、
忠実にまた読み手にわかりやすい論文を
心がけて書き直します。
その際には、また投稿させてください。
[277] ロナ (2009/07/21 Tue 23:19)
私はロナさんのシステムを理解しているわけではありませんが、
アの部分だけですが、骨子を私で考えてみました。一例として参考にしてください。
1.1
・立場：システム管理者
・システム：受発注システム
障害対策のため、システムを二重化している。
１．２ 重要なSLA
・重要なSLA:システム障害の15分以内の通知
・理由：受発注業務は顧客との接点であり、売上に直結する重要な業務。
一瞬たりとも停止したくないシステムだから
・基準：15分
その理由：ユーザからは即時にほしいとの要望。
われわれは、適切な状況判断をする時間が必要であるので、最低限の事実確認
時間である15分以内を要望。合意に至った。
簡単ですが、骨子はこれくらいシンプルでも構いません。
具体的なシステムの説明や数値を入れると、800字はあっというまです。イとウも、このように骨子をシンプルに考えてみてください。
よろしくお願いします。
[279] 管理者 (2009/07/30 Thu 09:43)
初めまして。すぎエモンと申します。
僭越ながら時間が取れたので、コメントさせて頂きます。
（良いと感じた点）
・論文の項目分けが設問に忠実であり、基本条件を満たしています。
・エラー検知後のリアクション「パトライトの点灯」って面白いですね。
未経験者の論文には産まれにくい発想で、現実味ある記述を感じます。
私はそんな工夫があることを初めて知りました。
・どうも本当に経験している事を記述しているようですね。
論文の各所に現実味を帯びた記述が散見されます。
（気になった点）
・システムを運用する上で合意しているサービスレベルは
１－２で記述した方がよいでしょう。
・ＳＬＡでは３つの項目を挙げていらっしゃいますが、
３つ内、何故「障害及びエラー通知時間は１５分以内とする。」
の項目を挙げたのでしょうか？
１－２では、「１５分」という時間に対する理由よりも、
３つの項目からなぜ、この項目を選んだのかを説明する必要があるのでは
ないでしょうか？
・「２－２．サービスレベルの基準値と実測値」とありますが、
２－２ではサービスレベルの基準値と実測値を中心に記述しているでしょうか？
「システムに発生した問題点」について記述しているような感想を持ちました。
・「２－４．サービスレベルの改善」は、サービスレベル自身の見直しではなく
サービスレベル維持の為の業務改善ではないでしょうか？
この論文では、サービスレベルの基準値と実測値のかい離は発生していない
ようですが、問題の趣旨を考えるとあえて、サービスレベルの基準値と
実測値にかい離が発生して、その対策を講じたというシナリオの方が
合格に近いと考えます。
・実際の経験を記述なさっているようであり、
論文内容に現実味がある点については、良いポイントだと思います。
しかし、その分、実際の出来事内容を詳細に書こうとし過ぎて
分かりにくい表記になっているのではないのでしょうか。
読み手は、ロナさんの担当システムについては素人ですので、ある程度
端折ったり、ありがちなシステムにデフォルメしたりして、
読みやすくしてあげる工夫が必要ではないかなと感じました。
細かい説明を省いた分、書けることが増えるので、そこにあなたの
考えた事や、行った工夫を書いていくと論文の質が上がると思います。
問題文に「工夫した点を中心に具体的に述べよ」とありますので
「工夫した点」に文章を集中させた方がよいかと思います。
[283] すぎエモン (2009/08/10 Mon 11:40)
管理者様
すぎエモン様
こんばんわ。ロナです。
コメントいただきありがとうございました。
初回の投稿から１ヶ月も経過してしまいました。
いただいたアドバイスを元に論文を見直しました。
お時間があるときでかまいませんので
コメントいただけると幸いです。
---------------------------------------------------
【情報システムにおけるサービスレベルについて
---------------------------------------------------
１.サービス概要とサービスレベル
１－１．私が携わったサービス概要
私は情報システム会社に勤務しておりシステム管理者
として従事している。私が携わっているシステムは小売
業Ｚ社の受発注業務のデータ交換システムである。この
システムではデータ交換における通信ゲートウエイの役
割を担っている。通信相手先は取引先３社とメーカー・
卸５社である。１日あたりのデータ送受信回数は合計５
０回である。また、Ｚ社の在庫管理、注文管理などの業
務システムとも連携しており送受信されるデータ種によ
って振分・マージ処理、データフォーマット変換処理、
通信プロトコル変換処理を同システム内で行っている。
このシステムを導入するにあたりコスト面の都合から
自社のＡＳＰサービスを利用することになった。このＡ
ＳＰサービスは障害対策のため冗長化構成となっており
サービス継続困難な場合には１０分程度で自動的に待機
系に切り替わる。サービス提供時間は２４時間３６５日
であり、同時間帯のヘルプデスクも開設している。すで
に５０社程度の業務が同ＡＳＰにて稼働している。
１－２．重要と考えた項目の設定理由と基準値
（１）重要と考えたサービスレベル項目
・障害及びエラー発生時は１５分以内に状況連絡する。
（２）理由
・受発注業務は顧客との接点であり、売上に直結する重
要な業務だからである。システムダウンなどの障害で強
制切替えが発生した場合、処理中断や回線断の業務影響
が発生する。Ｚ社側で実施するリカバリ作業を速やかに
実行できるよう状況を正確に伝える必要がある為である。
（３）基準値
・当初Ｚ社から「即時としてほしい」と要望があった。
しかしサービス提供事業者として正確な影響度を把握す
るため最低限の１５分以内を要望し、合意に至った。
２．サービスレベルの維持と具体的な方策
システム管理者は合意したサービスレベルを維持する
責任がある。実施した具体的な方策を述べる。
２－１．サービスレベルの監視
システムで発生した障害及びエラーの検知はヘルプデ
スクにておこなう。専用の運用監視端末と運用ツールを
用いてアラート鳴動と警告灯（パトライト）の点灯によ
って検知する仕組みを構築している。監視者は運用マニ
ュアルに沿ってサービス利用者や自社内の関係各部署へ
エラー内容を連絡する。必要に応じてマニュアルに記載
されたエラー対応コマンドの実行を実施することもある。
またインシデント管理を合わせて実施し、発生時刻、
発生内容、連絡時刻、暫定対応内容、ステータス、業務
影響度などを記録し管理している。
記録されたインシデントは週次の定例ミーティングに
て関係者に通知され、エラー解決状況や締結したサービ
スレベルの乖離が発生していないかどうか確認している。
２－２．基準値と実測値の乖離
Ｚ社サービス導入後、ある特定の取引先からのデータ
に不備がありフォーマット変換時に頻繁にエラーが発生
するようになった。ミーティングにてヘルプデスクの対
応状況を確認すると日中の発生時には５分以内に連絡が
完了していたが、夜間時間帯の発生時には１０分を超え
ることが度々あり、ぎりぎりサービスレベルを守れてい
るような状況であった。
２－３．状況の分析
私は、日中時間帯と夜間時間帯の対応状況について各
々担当者にヒアリングを実施し比較を行った。すると以
下のような問題点があった。
（１）マニュアルに記載のあるＺ社の第一連絡先が担当
部署の代表電話連絡先となっており、夜間時間帯に連絡
がつくことがない。明らかに担当者不在であることが容
易に推測できる。その後、第二連絡先であるＺ社担当者
の携帯電話へ連絡しているため時間がかかっている。
（２）夜間時間帯の担当者が日中に比べて手薄である。
担当者は複数のシステムについて監視を担当しているた
め、同じ時間で複数の障害が発生してしまうと対応に時
間がかかる恐れがある。また運用マニュアルのにはエラ
ーメッセージから障害状況を利用者に伝える運用になっ
ていた。日中時間帯は上位者の判断も仰ぎやすいが、夜
間時間帯は経験の浅い若手の技術者が担当することが多
く、過去事例の検索に時間がかかっていた。
２－４．対策の立案と実施
状況の分析の結果、以下の対策を立案し実施した。
（１）対策の立案
運用マニュアルの整備と自社内の情報連携強化
（２）実施内容
分析結果より日中時間帯と夜間時間帯では自社の体制、
Ｚ社の体制ともに異なることが判明した。対応レベルに
ついては統一する必要があり、運用マニュアルの整備を
行う際には、容易な文章を用い、過去事例の検索のキー
ワードとなるようエラー分類別のレイアウトとした。
また、日中担当者と夜間担当者との引き継ぎミーティン
グを毎日開催することにした。頻度の多いエラーの傾向
や実際の対応内容をあらかじめ把握しておくことで対応
時間の短縮につながるのではと考えた。
２－５．ユーザへの報告と評価
Ｚ社には、夜間時間帯の対応に時間がかかっている現状
を説明し、なるべく１度で連絡がつく夜間時間帯の連絡
先を設けてもらうことにした。Ｚ社からは日中と夜間の
連絡先を別にすることは、双方にとっても有効であると
いう認識で一致した。
３．方策の評価と今後の課題
３－１．方策の評価
今回実施した方策は概ね以下の点において適切であっ
たと評価している。
（１）夜間時間帯にＺ社へ連絡する際、第一連絡先の連
絡がとれないという事象が減り、１０分以内に連絡完了
する比率が多くなった。
（２）運用マニュアルの整備により、障害状況確認まで
の時間が短縮された。特に過去事例の検索においては引
き継ぎミーティングを実施することで事前に対応方法を
確認することができ、若手の担当者でも不安なく対応す
ることができた。
３－２．今後の課題
ヘルプデスクの担当者間で対応レベルを統一させてい
くことが今後の課題である。特に新規業務や慣れていな
いエラー対応については担当者各人の経験に左右される
ことがある。そのため効果的であった引き継ぎミーティ
ングは今後も継続して実施していきたい。また定期的な
マニュアルの見直し、最新の連絡先確認を実施し属人的
な運用とならないような体制をつくっていきたい。
[289] ロナ (2009/08/19 Wed 22:00)
【良いと感じた点】
・全体的に論文のレベルが向上しました。良い改善が
出来ていると思います。
・「日中担当者と夜間担当者との引き継ぎミーティン
グを毎日開催することにした」という対策は分かりやすくて
いいですね。運用サービスでありがちな工夫であり、
査読者にも伝わりやすいです。
・（１）重要と考えたサービスレベル項目
（２）理由
（３）基準値
の流れは非常にいいですね。読み手にとても伝わりやすい
書き方だと思います。
・３．方策の評価と今後の課題は３－１、３－２どちらとも
すっきりとシンプルに書かれており理解しやすかったですね
この部分はかなりポイント高いと思います。
【気になった点】
・１－１のシステム概要説明がまだ少し分かりにくいですね。
事実が書かれているのでしょうが、初めて読む人にとっては
頭の中にシステム概要がパッと浮かびにくいです。
冒頭の記述で読む人を論文の中に引き込む事ができると
合格率が高くなりますので、今後の工夫のポイントだと
思います。
・問題文には「サービスの基準値と基準値と実績値がかい離
している場合には状況を分析の上対策を立案し実施しなけ
ればならない」とあります。しかし、この論文のケースでは
「ぎりぎりサービスレベルを守れている」と記述しているので、
SLAは守れていますね。かい離は発生しそうなだけで、
実は発生していません。これは厳しい見方をすると
題意に沿っていないと取られる可能性があります。
ここはウソでもいいのでSLAの15分を守れない事例が発生
した（つまりかい離が発生した）事にした方がよかったの
ではないでしょうか？ここから、かい離した状況の原因を
分析する。そして対策を立案し実施するというシナリオ
にした方が題意にキチンと即した書き方にになっていた
のではないかと思います。
【その他】
・この論文はこの形で良いと思います。次からは別の問題文
を元に新規の論文を書かれることをオススメします。
本番で必要になるのは「２時間でゼロから論文を書き上げる」
能力なので、「何度も同じ論文を修正する」という訓練方式は
有効な勉強法にならない可能性があります。
[290] すぎエモン (2009/08/20 Thu 09:29)
すぎエモンさま
こんにちわ。ロナです。
コメントありがとうございました。
本番を想定して、２時間以内でかけるよう
新しい問題にて再度チャレンジしたいと思います。
[291] ロナ (2009/08/23 Sun 08:38)
１．情報システムと障害について
１．１ 私が携わった情報システム
私が勤務する会社は愛媛に本店があり中四国を中心に
１５０店舗をもつ地方銀行である。私はその銀行の情報
システム部門でシステム管理エンジニアとして勤務して
いる。
私が携わっている情報システムはホストシステムであ
り、勘定系、情報系、開発系、ナイトオンラインの４種
類のサブシステムが稼動している。稼働時間は毎日６：
００から２４：００まで、勘定系、情報系、開発系が稼
動し、２４：００から翌朝６：００まで勘定系の代わり
にナイトオンラインが稼動し、２４時間のオンラインサ
ービスを提供している。
１．２ 障害の内容と業務の影響
毎日２４：００から勘定系システムからナイトオンラ
インシステムへの切り替え処理を実施しているが、曜日
によって切り替え前処理が異なっている。金曜日以外は
データーベースの更新処理を実施してから切り替える。
金曜日についてはデーターベースの更新処理をしないで
いきなり切り替える。ただし、月末時には曜日にかかわ
らず、データーベースの更新処理をしてから切り替える
手順であった。
今回、月末の金曜日に障害が発生した。通常、金曜日
には、データーベースの更新処理をしないで切り替えて
いたが、月末であったため、データーベースの更新処理
語、切り替える予定であったが、２４：００を過ぎても
更新処理が終了せず、１時間後の２５：００に更新処理
が終了し、切り替え処理を完了した。２４：００から２
５：００の１時間オンラインサービスが停止し、インタ
ーネットバンキング、コンビニＡＴＭのサービスが約１
５０件不能となった。
２．障害の原因究明と対策立案と実施
２．１ 障害の原因追求
システム障害が想定を超えて長時間化した場合、それ
による損失は甚大なものとなるため、次のような支店か
ら長時間化した原因を究明した。以下にその分析結果を
列挙する。
①連絡は適切な時間内に実施できたか
この日２１：３０からのデータベース更新処理につい
て、オペレーターから早い時点で、正常処理はしている
ものの処理速度がいつもより少し遅いような気がする。
異常ではないかとの連絡がシステム開発担当者と運用担
当者に連絡が入っていた。連絡については初動の遅れは
ないと判断した。
②情報は適切に収集できたか
システム開発部門及び運用部門について、関係する社
員にはすべて連絡済であり、全員出社していた。処理状
況についてオペレーターが社員に報告し、処理を監視し
ていた。情報は適切に収集できたと考えた。
③手順は適切であったか
今回の障害の原因はデーターベースの更新処理のプロ
グラムであった。スケジュール、更新処理に問題はなか
ったため、更新処理を強制終了させることなく、終了す
るのを待ってから切り替えを実施した。オンラインサー
ビスを停止させることになってしまったが、データーベ
ースの更新処理は必須であったため、手順は適切であっ
たと判断した。
④想定外の事態に適切に対応できたか
今回の障害では想定外の事態はなかった。
⑤部門間の連携は適切であったか
今回の障害の原因はプログラム変更であった。システ
ム開発担当者はデーターベース更新処理のプログラムを
変更したが、スケジュール等の運用を変更したわけでは
なかった為、運用部門に連絡しなくてよいと判断した。
この連絡漏れが今回の障害を招いたといえる。
２．２ 対策立案と実施
(１)特に重要と考えた対策
開発部門と運用部門間のレビューの実施と相互確認
(２)その理由
障害発生時の連絡の実施等は電話連絡網を作成し、定
期的に訓練を実施しているため、問題ないと判断した。
情報収集についても、定期的に障害訓練を実施してい
るため、問題ないと判断した。想定外については、障害
対策としては優先順位が低いと考えた。
やはり、開発部門と運用部門のレビューの実施と相互
確認については、とても有効な対策と考えた。開発担当
者は正しいと思っていても運用側のスケジュールでは不
具合があったり、運用側では正しい思っていてもプログ
ラムがスケジュールにあっていなかったりすると今回の
ような障害が発生する。
この対策について、レビュー実施の作業コストが増加
するが、障害を事前に予防できたことと、障害発生によ
る損害と比較すれば、十分な費用対効果があると判断し
た。
また、レビューを実施することにより、開発部門と運
用部門のコミュニケーションが活発に取れるようになり、
プログラム作成時に運用を考慮したシステム作りができ
るようになると考えた。
３．対策の評価と今後の課題
３．１ 対策の評価
私が実施したレビュー実施の対策はとても高く評価さ
れる内容であった。なぜなら、対策を実施して約６ヶ月
間が経過するが、相互確認漏れによる障害は発生してい
ない。また、開発部門からは運用部門に対する不平・不
満が以前よりは減ったとの費用かをもらっている。
３．２ 今後の課題
レビュー実施による相互確認は効果的であったが、こ
の対策も時間がたつにつれて慣れが発生し、思い込み等
による障害を引き起こす可能性があると考えた。
そのためには、レビュー実施後、実施内容を文書にま
とめ第三者的な立場である社員に判断してもらうような
仕組みづくりに取り組んでいきたい。
以上
[284] ＧＯＫＡＫＵＳＵＲＵＺＯ (2009/08/13 Thu 21:09)
はじめまして、すぎエモンと申します。
僭越ながらコメントさせて頂きます。
Ｈ２０午後Ⅱ問３は、私が合格を取得した際に選択した
論文なので感慨深いですね。問題文①～⑤の部分をいかに論文に取り込むかで
苦労した記憶があります。
「良いと感じた点」
・設問に対して忠実に答えようという文章構成になっており、
合格の基本条件を満たしています。
・「インターネットバンキング、コンビニＡＴＭのサービスが約１
５０件不能となった」という表記は数字で具体性が示されていて
いいですね。システム停止時間を記述する人は多いですが、もう一歩
踏み込んで影響を書けていることはポイントが高いです。
・設問アの文字数をキッチリと８００字に近づけている事、
全体の文字数が２４００字をやや上回る文字数であり
バランスがよい記述量であると感じました。
「気になった点」
・論文の前半部分で、システムが抱える問題点について触れていないので、
論文の中盤で「この連絡漏れが今回の障害を招いたといえる」と唐突に断言されると
「どうしてそう断言できるのだろう？」という疑問がわきます。
・特に重要と考えた対策が「開発部門と運用部門間のレビューの実施」とありますが
その考えに至った経緯が事前に示されておらず、やはり唐突さを感じます。
・論文の展開が、「問題なかった」部分が中心となっており、「問題点」と「解決策」
が話の中心になっていないように感じます。また、問題文には「工夫した点を中心に
述べよ」と書いているのに、工夫した点が中心になっていないような気がします。
・「ナイトオンライン」というのは面白いですね、独自性を感じます。折角なのでどのような
どんなオンラインか説明があってもいいのではないかと思いました。
「誤字・脱字」
・減ったとの費用かをもらっている
→減ったとの評価をもらっている
[285] すぎエモン (2009/08/18 Tue 09:16)
自分の本を宣伝するようですいません。
合格論文集が発売されております。
この本は、買っていただいて損はないと思います。
論文対策には、論文ネタを準備することがとても重要です。
以下にもたくさん書きました。
http://sm.xn--n9q36mh1hnxuksz7wt.net/archives/cat_50067923.html
「専門知識+午後問題」の本も自分ではお勧めしているのですが、ライバル他社さんの本もあるので、どれを買うかは読者の好みになると思います。
ですが、論文集らしき本はこの本以外に見受けられません。よって、この本でしか論文ネタを集めるのが難しいと思います。
特にインシデント管理（障害管理）に関するしっかりとした論文ネタが必要です。この本の中で、自分にピタリとあう論文ネタを準備してください。
[280] 管理者 (2009/08/02 Sun 23:35) web
わくわくスタディワールドの社長の美月先生が、良い本と言っていたので、即購入しました。この本の事例を読んでいるだけで勉強になりました。
ありがとうございます！
あとは、この本の事例に当てはめて、自分の経験を入れて論文を２個ぐらい作成しようと思います。
[282] ないとー (2009/08/03 Mon 15:41)
午前対策として基礎固めのため、お勧めの本がありましたら、具体的な本名を教えていただけませんでしょうか？よろしくお願いします。
[278] Ｍａｔｓｕｍｏｔｏ (2009/07/28 Tue 19:35) mail
基礎固めとしてじっくり勉強されるほどの時間は無いかもしれませんね。時間的なことを考えると過去問中心の勉強が良いと思います。
お薦めは難しいですが、強いてあげるなら松原さんの「情報処理教科書 [秋期]高度試験午前対策 2009年度版 」は悪くないのでは？
めちゃくちゃお勧めという訳ではなく、他社に比べて解説は詳しいと思います。他にももっと良い本があるかもしれません。
[281] 管理者 (2009/08/02 Sun 23:40) web
今は仕事がかなり忙しいので、妄想レベルですが、、、
時間と皆様からのニーズがあれば、ITサービスマネージャの直前対策をやりたいと思ってます。
趣旨は、
「ITサービスマネージャに合格していただく」
これに尽きます。
時期は10月の10日前後を予定してます。場所はまったく未定ですが、東京か横浜でやりたいです。
基本的には重点対策の内容になりますが、ポイントは以下です。
①重要なポイントを生で伝える。
②皆様との意見交換の場を設ける
③本には書けなかった（書きにくかった）テクニックを伝える。
④皆様の論文を添削する（時間の制約があるので、数人しかできないと思いますが）
私の場合も、色々な先生方の直接授業を受けて大躍進しました。皆さまの合格へのお手伝いができれば幸いです。
皆様のご意見を聞きながら、考えていきたいと思います。
懇親会をするのも良いかもしれません。
[268] 管理者 (2009/07/11 Sat 23:07)
管理者さん、こんにちは。
重点対策は、良い本ですね。自分がやっている実務にこの本の
内容を当てはめると、ああ、ちゃんと本に書いてあることやって
るんだああ、感動してしまっております。
是非、東京か横浜で対策ゼミを開催して欲しいです。
私は今回初めて受けようと思っているのですが、論文の頭脳は、
管理者さんは普段どうやって鍛えていらっしゃるのでしょうか？
[269] 浪人 (2009/07/13 Mon 15:13)
是非、参加したいと思います。
でも、仕事もお忙しいようですから、くれぐれも無理はなさらないように。
[271] ss2004 (2009/07/13 Mon 23:37) web
浪人さん、ss2004さん
早速の書き込みありがとうございます。
皆さんのご要望を聞きながら開催を前向きに検討していきたいです。
>私は今回初めて受けようと思っているのですが、論文の頭脳は、
>管理者さんは普段どうやって鍛えていらっしゃるのでしょうか？
私は国語が大の苦手でした。だから理系に進みました。
ですが、この試験の論文は国語力がそれほど重視されていません。
重点対策のP376に書いたように、難易度もそれほど高いとは言えませんし、P388からの論文の書き方を信用していただき、素直になっていただければ合格できます。
日頃から鍛える方法は、業務です。
メールでも提案書でも誰かに説明するときでも、常に「なぜか」という理由を考えます。例えば、「ここで設計書を作る理由はなぜか」。すると、すると設計書の中で必要な部分と不要な部分が見えたりします。メールでも、自分で読みなおして分かりにくいところは理由をつけます。
このなぜかを考える癖により、論理の妥当性が増します。
さらに、ITサービスマネージャ試験の具体性を増すためには、P384で書いた、業務経験を補うことが重要です。
これらのことをすることで、試験に受かるだけでなく、業務においても一目おかれるようになると思います。
[272] 管理者 (2009/07/14 Tue 08:05)
管理者さん
ご回答どうもありがとうございます。
これからは、業務の中で「なぜかを考える癖」をつけたいと思います。そういえば、管理者さんに言われるまで、業務に内容に関しては常に「そう言うものだから」としか考えていませんでした。
これじゃあ、進歩しませんね。(^^;)
[273] 浪人 (2009/07/14 Tue 08:55)
管理者様
はじめまして。lotusといいます。
日頃より本HPを活用させていただいております。
ITサービスマネージャの直前対策勉強会にも
ぜひ参加させていただきたく。
今後ともよろしくお願いいたします。
lotus
[274] lotus (2009/07/15 Wed 08:32)
はじめまして。
とりあえず春に情報セキュリティは取れたので、
秋にITサービスマネージャを受験しようと考えております。
NWとどちらを受けるか迷ったのですが、
私は保守・運用の仕事が多いので、ITサービスを受ける事にしました。
論文試験は全く自信がありませんが、このサイトを参考にしながら
頑張りたいと思います。
今後もちょくちょ覗かせていただきますので、
よろしくお願いいたします。
[264] もとちゃん (2009/07/04 Sat 15:52)
はじめまして
もとちゃんさんと同じく初めてこの試験を受けます。
私は製造業の情報システム部門が分社してできた会社に勤務しています。親会社の情報システムの保守・運用を担当していて、ま・さ・に、ITサービスマネージャの試験そのものです。
この試験を受験される皆さんは保守運用部門の人が多いと思います。会社からきちんと評価されていますか。
営業と違って売り上げが無いからどれだけがんばっても認めれもらえないのが不満です。
この資格を取得して会社からの評価をあげたいと思います。
それから、今の会社の運用が本当に正しい姿なのかを確かめたいです。もっと良い方法は間違いなくあります。でも、正しい姿がなにかわからないし、私が言ってもどうせ聞いてもらえません。
このサイトでモチベーションを保ってがんばります。
よろしくおねがいします。
[270] kakura (2009/07/13 Mon 18:24)