お久しぶりです、こんばんは。秋の準備を始めようと、約２年ちょっとぶりにやってきたくろすです。
まだ全部拝見していませんがサイトVerUPしてますね～
と、さて間違っていたらごめんなさい…(と先に謝っておいて～)(^^;)
○TOPページの左にある推奨本の「ITサービスマネージャ 専門知識＋午後問題の重点対策(赤っぽい本)」のリンク先が2009年版に行っちゃいます…
2010年版が出ているとの事なので、2010に行けた方がうれしいかなと…
○同じく推奨本の「ITサービスマネージャ合格論文の書き方・事例集(周りが紫の本)」の本の方をクリックするとエラーになっっちゃいます…
ただし、下の文字の方をクリックすると行けるので、そういう造りなのかなとも思いつつ…
もし、お時間のある時に、さくっと本紹介のページに飛べるとうれしいな♪と思いました。
お勉強して、また来ますね。
ご活躍 頑張ってください。
[389] くろす (2010/07/22 Thu 00:46)
くろすさん
ご丁寧な指摘ありがとうございます。
こういうご指摘はとてもありがたいです。
これからも遠慮なく言ってください。
リンク切れを直しました。
実は、さぼっていただけです。
>お勉強して、また来ますね。
>ご活躍 頑張ってください。
温かいお言葉ありがとうございます。
くろすさんこそ、ご活躍をお祈り申し上げます。
ありがとうございました。
[390] 管理者 (2010/07/24 Sat 21:57)
昨年、属人性の排除とか、標準化の遅れとかをネタに
書いたんですが、こういうのって、根本的に、
外していますかね？
あちこちのサンプル見ていると、そういうネタは少ないですね。
ＩＴＰＲＯとかでは、ミス防止とかの記事とかに
使われているんですけどね。
可視化とかも、駄目なんですかね？
メインフレームだから、レガシーだし、そういうネタしか、
書きにくいのも事実ですけどね。
[387] ＤＵＫＥ (2010/07/11 Sun 03:00)
試験官からすると、「外している」と思われているかもしれません。
現場の泥臭い仕事と、論文は多少異なります。※多少ではない場合もあります。
合格に徹するとするならば、過去問で書かれていない内容で書くことはお勧めしません。過去問で述べられている「複数人によるチェック」「ツールを活用した効率化」などを活用するほうが無難でしょう。私もそうします。
試験センターの論述は理想論かもしれませんが、それはそれで間違っていません。よりよいITサービスのためには、理想系を論述するというのはおかしくありません。試験センターの思いとリンクした内容を書くことをお勧めします。
[388] 管理者 (2010/07/15 Thu 20:52)
こちらでは、はじめまして。
Noahです。
これまでは、ネットワークスペシャリストの方でお世話になりました。非常に時間を要しましたが、楽々合格サイトを参考にさせて頂き漸くネットワークスペシャリストを09年に取得。
また10年春に情報セキュリティスペシャリストも取得する事が出来ました。
色々と迷いましたが、秋にITサービスマネージャを受験する事にしましたので、今度は、こちらでお世話になります。
宜しく御願いします。
重点対策は、ネットワーク、情報セキュリティとこれまで必ず購入してきましたので、当然、今回も購入済みです！
まずは、翔泳社の参考書(といっても問題が多い)を一通りやりつつ重点対策にも取り掛かりたいと思います。
また管理人さんが執筆されているというのを、こちらのサイトにて初めて知り、驚いている次第です。
自身の資格取得もさることながら、教育という観点にも興味があるので本サイトを参考にさせて頂ければと思っております。
初の小論文となりますが、頑張りたいと思います。
ちょくちょく寄らせて頂きますので、宜しくお願いいたします。
[385] Noah (2010/07/08 Thu 12:15) mail
Noahさん
いつもありがとうございます。
ネットワーク、セキュリティのダブルスペシャリスト合格おめでとうございます。きっと実力があって努力されたんでしょうね。
合格するって本当にうれしいですよね。
重点対策もお買い上げいただいたようで、ありがとうございます。論文対策は絶対的な自信がありますので、何度も読んでください。
今後も遊びに来てください。
[386] 管理者 (2010/07/09 Fri 01:54)
ITサービスマネージャの『専門知識+午後問題』の重点対策を
使って勉強しております。
内容が非常に充実しており、これを十分活用して
秋試験のITサービスマネージャに挑むつもりです。
そこで、著者である管理者様におききしたいのですが、
この本と同じような感じで、他区分の論文試験（システムアーキテクトやシステム監査）の本を出版される予定などは
ないのでしょうか？
[381] こどらん (2010/06/27 Sun 17:07)
こどらんさん
お返事が遅くなりました。
重点対策のお買い上げありがとうございます。
今後の改善点があれば、忌憚のないご意見をお待ちしております。次の改訂にて改善していきます。
他区分の論文試験は今のところありません。今はネットワークを書いています。
他の論文試験に関しても、テクニック的な内容は書けるのですが、本質まで踏み込んだ内容になると、まだまだ実力不足というのが正直なところです。今後は分かりませんが、今のところはそんな状況です。
ITサービスマネージャ、是非合格してください。
そして貴重な合格体験をお聞かせください。
[383] 管理者 (2010/07/01 Thu 08:05)
回答ありがとうございました。
頑張ります。
[384] こどらん (2010/07/01 Thu 19:56)
こんばんは。
管理者様にご質問があります。
ＩＴサービスマネージャの２つの参考書（2010年度版 「『専門知識+午後問題』の重点対策」と2010年度版「ITサービスマネージャ本試験問題」）をお勧めしていますが、素人がこれから挑戦するにあたってどちらの参考書がお勧めまたは理解できる内容になっていますか？専門書なので２冊買うのは金銭的につらいのと同じような内容なら１冊でもいいのかと思うので・・・
今年ＩＴサービスマネージャを挑戦しようと思っている為、詳しく教えて頂けたら有難いです。
[379] nanasi (2010/06/25 Fri 23:51)
nanasiさん
書き込みありがとうございます。
「『専門知識+午後問題』の重点対策」をお買い求めください。ITサービスマネージャ本試験問題」は参考書ではなく、過去問解説になります。
「『専門知識+午後問題』の重点対策」にて基礎をしっかり学んでいただき、合格を勝ち取ってください。合格するためにノウハウをしっかりと詰め込んだつもりです。また、午後Ⅱの論文対策は手前味噌で恐縮ですが、どこよりも的を射た内容だと自負しております。
また、何人もの方に高い評価をいただいておりますが、ITILに関する解説を充実させております。ITサービスマネージャではITILの内容が必須になっており、試験で必要なITILの知識をポイントを絞って解説しております。
また何かご不明な点がありましたら、何なりとご質問ください。
よろしくお願いします。
[380] 管理者 (2010/06/27 Sun 15:20)
管理者様
ご返信ありがとうございます。
『専門知識+午後問題』の重点対策を購入し基礎から身につけ、管理者様のＨＰに記載してある各ポイントと過去問を勉強し、がんばります。
管理者様はどういう風な勉強法をしてきたのですか？参考になれば実践したいです。
ご教授願います。
[382] nanasi (2010/06/28 Mon 01:20)
平成２１年度 午後１ 問３ 設問１
必要最小限の人数にしている、現在の運用オペレータ総人数を求める問題について、教えてください。
どのように計算すれば試験センターのような「１２人」と出てくるのかが全く分かりません。
計算問題が、とても不得意なのです。
もしかして、計算では求められなかったりしますでしょうか？
もうしわけございませんが、どなたか解説お願いいたします。
[376] ショウ (2010/06/01 Tue 01:21) mail
ショウさん、お疲れさまです。すぎエモンです。
僭越ながらコメントさせて頂きます。
平成２１年度 午後１ 問３ 設問１
必要最小限の人数にしている、現在の運用オペレータ総人数を求める問題について
ですが…
一日に必要なオペレータの人数はシステムの観点から考えると、
・朝シフトチーム ２名
・昼シフトチーム ２名
・夜シフトチーム １名
で合計５名必要になります。
しかし、ここで問題文より以下の条件が追加されます。
「常に１チームあたり１人分の余裕が必要な体制にする」
これにより体制は以下のようになります。
・朝シフトチーム ３名 （１人分の余裕を追加）
・昼シフトチーム ３名 （１人分の余裕を追加）
・夜シフトチーム ２名 （１人分の余裕を追加）
で合計８名必要になります。
さらに問題文より以下の条件が追加されます。
「各チームの人数は同一とする」
これにより体制は以下のようになります。
・朝シフトチーム ３名
・昼シフトチーム ３名
・夜シフトチーム ３名 （１人追加しチームの人数をそろえる）
で合計９名必要になります。
それでは１年間に必要とされるオペレータの延べ人数はどれほど
になるでしょうか？
９人 × ３５６日 ＝ ３２８５名
さらに、オペレータ１人の１年間の勤務日数はどうなるでしょうか？
３５６日 ÷ ７日 ≒ ５２週の勤務がある
１週間の勤務日数は非番の１日を除き６日なので
５２週 × ６日 ≒ ３１２日の勤務が可能
よって、３２８５名 ÷ ３１２日 ≒ １０．５人
これによりオペレータ人数は１１名が必要です。
（私も解答が公表されるまでは答えは１１名だと思っていました）
しかし、ここでもう一度問題の前提に立ち返らないといけないようです。
問題文には以下の条件が記載されています。
「各チームの人数は同一とする」
これにより各チームの体制の人数を揃えるためにはオペレータの
必要人数は”３で割り切れる数”にする必要があります。
よって、”１１人以上でかつ、３チームの人数を同一にできる最小の人数”
構成を考えると。
・チーム１ ４名
・チーム２ ４名
・チーム３ ４名
ということになり合計１２名必要になります。
ここで注意したい点は、問題が
「休暇」≠「非番」と扱っていることでしょうか。
「休暇」は、オペレータが自分の意思で取得する
有給休暇や突発的な病休を意味しているようです。
休暇については「１チームあたり１人分の余裕」
を確保しているのでこれで対応します。
「休暇」だけを考慮した場合、オペレータは９名でＯＫです。
「非番」については、通常の会社員にとっての日曜日
のように、必ず休みとして与えられる休日の様です。
これは「１チームあたり１人分の余裕」で対応するではなく
別途さらに人を追加確保してオペレータの非番に対応することに
なっているようです。
よって、「休暇」と「非番」に両方対応する体制にする場合は
オペレータは１２名必要になるということになりそうです。
って、この計算方法でいいかどうかは不明ですが
自分なりに納得した解答方法です。
[377] すぎエモン (2010/06/02 Wed 09:58) mail
すぎエモンさん
ご解説ありがとうございます。
なるほど、とても分かりやすい解説だと思いました。
でも解説を読んで理解しましたが、
前提条件がいくつも重なっているため、
この計算問題は、ちょっと難しいですね。。。。
去年の「２点足らず・・・・」という状況にならないためにも、
去年の問題はしっかりと全て理解をしておきたいと
考えております。
また、論文も時間ができたら投稿してみたいと考えておりますので、
コメントいただけたらと思います。
[378] ショウ (2010/06/03 Thu 00:58) mail
おはようございます。
今年秋にＩＴサービスマネージャを受験予定の者です。
過去問を解いていて疑問に思われる部分がありましたので質問させていただきます。
設問3の(1)で穴埋めの解答がそれぞれ順不同で
イ IDがX氏の利用者ID
ウ アクセス日時が紛失日時以降
エ アクセスファイルが顧客ファイル
となってます。イ、ウはそれぞれ表から項目としてID、アクセス日時となり 保持するデータ項目 であるため抽出条件として適用できると思うのですが、エは項目がアクセスファイルとなり 保持しないデータ項目 となり抽出の条件としては適用できないと思われます。
保持しないデータ項目であるにもかかわらずなぜ抽出条件にアクセスファイルが項目として選ばれているのかわかりません。
何か見落としているのか。理解ができないでいます。
以上、よろしくお願い申し上げます。
[374] ｒｉｒｉ (2010/05/31 Mon 06:28)
自己解決しました。
翔泳社の書籍では 項目 アクセスファイル は保持しないデータとなってますがＩＰＡのＰＤＦファイルで確認しましたが保持するデータとなっており、どうやら翔泳社の書籍の誤植だったようです。
お騒がせしました。
[375] riri (2010/05/31 Mon 12:26)
TOPページにも書きましたが、2010年度版が発売されました。
私も一部でお手伝いさせていただきましたが、ITECの先生方のノウハウ・知識量に正直驚きました。
特に午後1は、昨年のITサービスマネージャはかなり難しかったようですが、正解以外の解答についても論理的に踏み込んで非常に詳しく解説してあります。この解説の深さに驚かれるのではないでしょうか。
また、昨年は予想問題にて午後1問3にかなり類似した問題を予想されていました。予想問題を解かれた方は簡単に解けたのではないのでしょうか。
立ち読みででも構いませんので、感想をお聞かせください。
参考書として活用いただける重点対策の2010年度版は、4月下旬から5月上旬に発売予定です。こちらもご期待ください。
[370] 管理者 (2010/04/28 Wed 07:31) web
管理者様 こんにちは
田植えの準備等で忙しくすごしてます。
天候が不順で苦労します。
先日、翔泳社の今年度のＩＴサービスマネージャの参考書を買って午後一を７問くらいやったのですが、若干、ネットワークや情報セキュリティと赴きが違いますが慣れると解きやすい問題が多いかもと思いました。
こちらでご紹介いただいた本もいずれは（６月？）購入しようと思います。なんか１０月の試験に向けて皮算用をしだした私です。論文という強敵もありますのでじっくり研究します。楽しみ楽しみ。
[371] riri (2010/04/30 Fri 18:50)
ririさん
いつもありがとうございます。
>楽しみ楽しみ。
この姿勢がすばらしい！
私も見習わせてもらいます。私は本を書いてはいますが、他の試験を受けるときは常に挑戦者です。正直言って、楽しむ余裕はあまりありません。
もし本を購入いただけるようでしたら、忌憚の無い意見をお待ちしております。よろしくお願いします。
また遊びに来てください。
よろしくお願いします。
[372] 管理者 (2010/05/01 Sat 15:22)
かしこまりました。読んでみます。
[373] GOKAKUSURUZO (2010/05/03 Mon 00:21) mail
あけましておめでとうございます。
昨年はＰＭもＳＭも、午後１で落とされる。
ＳＭにいたっては２点に泣く、
散々な結果となってしまったことが残念です。
今年は、子供がうまれてくるので、
まとまった勉強時間をとることが、
困難になってくるだろうと考えています。
同じ境遇の経験をされて、なおかつ合格された方。
「こんな勉強方法はいかがでしょう？（合格体験記）」
お願いします。（笑）
さて、散々なＳＭの試験だったのですが、
試験当日、酒を飲みに気分を一新して家に帰る
というのが、通常でしたが、
昨年は妊娠中の妻もいたため、酒も飲まず家にすぐに帰りました。
そして、「復元論文」を作っていました。。。。（笑汗
採点者には読まれず、評価されなかった論文なので、
全く価値はありませんが、今年の春のＰＭと秋のＳＭに再挑戦するため、
私の論文を、いろいろと評価していただこうかと考えました。
正月早々に気分を一新して、今年はいい一年だったと
笑いたいので、みなさんよろしくお願いいたします。
====================================================
平成２１年度 問３ 事前予防的な問題管理について
１． 私が携わったＩＴサービスの概要と、分析して判
明したインシデントの発生の傾向や頻度について
１．１ 私が携わったＩＴサービスの概要について
私は旅行会社Ａ社に勤務している。情報システム部の
システム運用担当に所属し、自社システムの保守運用業
務に従事してきた。今回、論述するＩＴサービスは旅行
予約販売システムについてである。
Ａ社は大阪に本社があり、全国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
ショウさん
おはようございます。
情報セキュリティ受けてきましたよ
今回はリベンジできそうな予感がします。午後がⅠ、Ⅱとも簡単でしたよ。これで不合格なら笑うしかありません。
試験後、書店でITサービスマネージャの書籍を探しましたが翔泳社だけでしたね 少なくて唖然 まずは肩慣らしに ITIL の本でも読んでみようかな
文章は書くの好きなんですが論文は初めてで皆目検討がつきません。
半年に一度の試験は刺激になっていいです。みんな頑張っている姿見るだけでも自分も成長できた気がします。秋に向けて頑張ります。
[368] riri (2010/04/19 Mon 09:19)
試験勉強、論文対策で使用した参考資料を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)