管理人様、はじめまして。
こちらのサイトは会社の昼休みなどによく拝見させて頂きました。当初、論文試験は初めての受験ということもあり、敷居が高いと感じていました。しかし管理人様のシステム管理に対する考えを読んでいるうち、私でもいけるのではと大変勇気づけられました。
試験結果ですが合格でした。
午前 700
午後Ⅰ 600
午後Ⅱ A
受かりはしたものの、午後Ⅰはぎりぎりでした。午後Ⅱは３を選択したのですが、題意から少しずれた感じがしたので恐らくぎりぎりだと思います。管理人様のアドバイスにあった、頻出分野のネタをいくつかまとめておいたのが効いたと思います。そうでなければ2時間ではとても書ききれませんでした。
今後も本サイトの運営で一人でも多くの合格者がでることを祈っております。
ありがとうございました。
[212] non (2008/06/20 Fri 23:20)
本日、合格証が届きました。
合格はうれしいものです。
スコアは以下です。
受験番号 AU604 - XXX の方は，合格です。
午前試験のスコアは，680 点です。
午後I試験のスコアは，615 点です。
午後II試験の評価ランクは，A です。
午後Ⅰはぎりぎりでしたし、午後Ⅱもぎりぎりだと思います。ラッキーでした。
今後も学習を続けていきたいと思います。
[211] 管理者 (2008/06/20 Fri 16:59)
管理人様
はじめまして。
無事、合格することが出来ました。
今回、初めてシステム管理を受けるにあたり、本サイトに出会ったことが、合格に繋がったと思います。
----------------------------------------
午前試験のスコアは，640 点です。
午後I試験のスコアは，645 点です。
午後II試験の評価ランクは，A です。
----------------------------------------
情報処理試験自体、10年ぶりでしたのでとにかく
午前中の過去問を解きまくりました。
本サイトの午前のページも参考にさせていただきました。
午後Ⅰ午後Ⅱは、どの参考書を読むより先に本サイトの「コツ」を熟読し、T○Cの論文添削＆模試で、弱点を克服していきました。
模試では午前がB判定で、かなりあせりましたが。。。
とにかく、殿のおっしゃる「素直になる」を心がけました。
秋はプロジェクトマネージャ合格を目指したいと思います。
ありがとうございました。
[210] zaki (2008/06/18 Wed 08:57)
昨年システム監査合格体験記を書かせていただいた某氏です。
システム管理ですが、何とか合格しておりました。
午前、午後Ⅰともギリギリのラインだったのですが、管理人さんの「システム管理者を意識する」というアドバイスや採点のおかげで午後Ⅱ突破できたと思います。
ありがとうございました！
-----------------------------------
午前試験のスコアは，645 点です。
午後I試験のスコアは，625 点です。
午後II試験の評価ランクは，A です。
-----------------------------------
次は秋は飛ばして来春に新制度のプロマネを受験しようかと思ってます。
その際はまたよろしくお願い致します。
[209] 某氏 (2008/06/17 Tue 23:21)
ハチです。お疲れ様です。
Ｈ２０春 不合格でした。
（成績）
午前： ６９０点
午後１：６３５点
午後２：Ｂ
やっぱり論文でダメでした・・・
何度も添削して頂いたのに、結果を出せずにすいません。
今回の勉強を通じてこの資格が、
まったく手の届かないモノではないと、感じることが出来ました。
次の試験で再チャレンジしようと思います。
ありがとうございました。
[200] ハチ (2008/06/16 Mon 11:19)
ヤマポンです。
私も、論文でダメでした。
午前 695点、午後1 625点、午後2 B でした。
論文の敗因は、システム管理者になり切れなかった点
だと考えています。
それと、題意に正直に答えられていなかった点も
マイナス要素と考えています。
管理人さんには、ご多忙中、何回も添削いただいたのに
申し訳ありませんでした。
次の試験で、リベンジしたいと思います。
[202] ヤマポン (2008/06/16 Mon 15:50)
まさやんです。
私も不合格でした。
精一杯やったので、悔いはありません。実力どおりといった感じです。
午前： ７４５点
午後１：５４０点
午後２：採点されず。
午前は、比較的とれたので、後は
午後１を解ける実力をつけることが課題です。
私も次の試験でリベンジします。
またよろしくお願いします。
[203] まさやん (2008/06/16 Mon 16:46)
午前試験のスコアは，685 点です。
午後I試験のスコアは，640 点です。
午後II試験の評価ランクは，B です。
午後１単純なミスが多かったので、論文採点
されてないつもりでした（汗
論文は字数足らずでしたので惜しいなぁと
今頃悔しく思います。
ギリギリのお忙しい中で色々評価していただいて
管理人さんには本当にお世話になりました。
次の２００９年秋のITサービスマネージャ試験で
リベンジしたいと思います。
またよろしくお願いいたします。
[208] aki (2008/06/16 Mon 22:56)
初めて投稿させて頂きます。
しんと言います。
こちらのサイトをいつも見させて頂いておりました。
論文に自信が無く、玉砕覚悟だったのですが
何とか合格することが出来ました。
---
午前試験のスコアは，650 点です。
午後I試験のスコアは，620 点です。
午後II試験の評価ランクは，A です。
---
午前は自己採点で39/55くらい。
午後Ⅰは80%くらい出来たつもりだったんですが、
ぎりぎりでした。
論文はとにかく手で書く練習が必要ですよね^^;
慣れていないと試験中に手が痛くて痛くて、、、
内容としてはみなさんがこちらで添削されている
ものに比べたらとても薄っぺらいものだと思って
いるのですが、(決して謙遜ではありません。)
システム管理の立場として書けたのが良かった
みたいです。
管理人さんどうもありがとうございました。
[207] しん (2008/06/16 Mon 22:30)
かんそくです。
合格でした～。
午前 695点
午後I 660点
午後II A
論文に無理があったような気がしましたが、
なんとかなってたようです。
管理人さんのご指導のおかげです。
ありがとうございました。
次はネットワーク頑張ります～。
[206] かんそく (2008/06/16 Mon 21:12)
皆様こんばんは
試験結果のご報告ありがとうございます。
合格の方もいれば、不合格の方もいらっしゃるので、私の気持ちは複雑です。
HPを通じて添削させていただきましたが、私の添削が適切ではなかったかもしれません。皆様の貴重なご意見は、しっかりと受け止めていきたいと思います。
試験は一発勝負ですから、厳しいですよね。たまたま体長がわるかったり、単純なミスをしてしまったり、といことがあります。多くの著書を書かれている先生方も、不合格は何度も経験されています。（勝率5割以上の先生は少ないと思います）
次の試験はちょっと先になりますが、良いご報告をいただけることを楽しみにしております。
[204] 管理者 (2008/06/16 Mon 19:49)
午後Ⅰは簡単なようですが、実は、無茶ボーダが高い気がします。自分自身２回目でしたが、これで、６２０程度？って、疑いたくなります。６５％から７０％はいかないと、６００乗らないんじゃないですかね？
[205] ＤＵＫＥ (2008/06/16 Mon 20:58)
平成20年度 テクニカルエンジニア（システム管理）試験
合格する事ができました。
自分の論文のレベルが低く、
途中で断念したつもりでしたが、
せっかく努力したんだから
胸を張って不合格になろうと考えていました。
～～～～～～～～～～～～～～～～～～
受験番号 SM921 - ???? の方は，合格です。
午前試験のスコアは，720 点です。
午後I試験のスコアは，615 点です。
午後II試験の評価ランクは，A です。
～～～～～～～～～～～～～～～～～～
ひとえにこのサイトで交流を深めた
皆様方のお陰だと思っております。
ありがとうございました
[201] すぎエモン (2008/06/16 Mon 11:32)
試験が終わって、徐々に解答速報が出てきましたね。
itecの午後２の講評を見ていてやられたと思いました。
（１）を選んだのですが、性能関連についての
SLA項目にフォーカスをあて、もろに性能対策に
尽力したことを書いてしまいました。
論文問題は「SLA遵守のためのプロセスで発生する問題」
および「問題の対処」を問われているので、
だめですね。。。
性能対策自体が、ここでいうプロセスであって
性能劣化が問題ではなく、性能対策中に何か
困ったことが発生した場合のそれが問題点という
ことですかね…
がっかりです。
[186] トゲ (2008/04/24 Thu 20:59)
合格しました。
パスワードなくしたので点数はわかりませんが…。
自己採点で午前は３８問正解でした。
たぶん、すれすれだったと思います。
午後１は自己採点では７割５分程度、
論文はNo.186で記載したとおりです。
[199] トゲ (2008/06/16 Mon 11:14)
私は２回目でした。
午前が、４１／５５なので、滑り込みかなと感じています。
午後Ⅰは、問１，３，４選択で、アイテック、ＴＡＣの解答より、約６０％～７０％位かなってところです。
去年は、６５％ぐらいかなって思ったら、５００前半だったので、選択の○をミスったか？キーワードが漏れているか？だと思います。
午後Ⅱは論文、外しました。問３でしたけど長期化より、障害対策に重点置いてしまった。午後Ⅰまで通過できれば御の字ですが、来年は秋か？って憂鬱な気持ちです。
[187] ＤＵＫＥ (2008/04/26 Sat 23:02)
こんにちは
試験お疲れ様でした。長丁場なので、本当に疲れますよね。
さて、ボーダなのですが、なんとも答えにくいですね。
情報処理試験に長く携わっている経験から申しますと、”書き方”と”難易度”でスコアが大きく変わります。
①書き方
正解だと思っていても、点数が悪いことがあります。私が生徒さんの添削をさせていただいた時の感想です。「この人、わかっているのに・・・でも必要なポイントが記載されていないから0点だなあ」
http://sm.xn--n9q36mh1hnxuksz7wt.net/archives/52440673.html
②難易度
簡単な問題の場合、スコアが伸びません。IRT的な評価をしているのかも。午後Ⅰが全くできなかったという人のスコアが、案外600を超えていたケースはたくさんあります。
システム管理は逆で、思ったよりスコアが悪いという方が多いです。
参考にならない意見かもしれませんが、コメントさせていただきました。
[188] 管理者 (2008/04/27 Sun 09:05)
昨年、酷いチョンボだったのかと、悲しかったのですが、とりあえず落ち着きました。ありがとうございます。
[189] ＤＵＫＥ (2008/04/27 Sun 15:55)
アイテックより、ＳＭについて、午前はＤＢの難度が高かったので、難易度が上がったとのことでした。
テクニカルＤＢ保持しているんで、一応、全部正解でした。ＤＢの問題が多かったので、助けられたと
いう認識のほうが強いです。ただ、ＩＲＴだと、やさしい問題が高得点だから、４１／５５でも６００点前半
程度と見ています。ＤＢなんか、４４／５４（一問チョンボがあった年）でも６００後半でしたからね。
午後Ⅰは、確かに、国語の試験ですね。じっくり読めれば解けるけど、時間がないから、見落としている
というイメージが強いです。
問１は甘めで、９０％近く取れているようですが、間違ったのは、設１（２）です。ＩＴＡＣ同様、
プログラムの世代戻しに食いついてしまった。
他は、線引いたところから、引用したレベルです。
リリース台帳云々とか、水曜日が一時間短いとか、どうにかヒットしました。
しかし、ここで、３０分使っちまったので、以降が慌てた。問３は、設問１（１）から、間違っちまったし、
設問２は、一つは「Ｓｏｒｒｙサーバのメッセージ出力回数」などと、書いちまった
（言いたいことは、業者の模範解答と同じイメージですけどね。）
し、もう一つは、全然はずれで、未だに答えが思い出せません。
問４は、ＤＢ保持者が、慌てちまって、設１（３）や設２は、アホなこと書いてしまった。
全体として、最低７０％は行けているようですが、システム管理は、広くて浅いというイメージが
強く、ボーダも高い気がしています。
管理人さんがおっしゃるように、論文の合格率が半分というのも、正解でしょう。
よほどのことがない限り、準備していれば、最低でもＣランクの相当上位には行くはずだと
思うからです。
午後Ⅰについては、毎度思いますが、２問を解く時間に３問やらされているような状況です。
知人に、小児マヒの男性がいるが、１種までは取れたけど、高度は受けていないそうです。
想像ですが、午後Ⅰが間に合わないのだろう。
（ＩＰＡによると、時間のハンデをつけることも可能らしいけど・・・）
もう少し、障害者の立場も考えてやるべきじゃないのかなとも思っている。
[191] ＤＵＫＥ (2008/04/28 Mon 23:30)
論文については、私も、長期化の原因より、障害対策を書いてしまったので、
よくても、Ｃランクかな？って気がしています。
午後Ⅰは、昨年５２０で、想像より、かなり低かったので、キーワードを
漏らしていたんでしょうかね。
今年も、業者の模範解答と同義のように見えるんですが、案外駄目かもしれません。
ＴＡＣさんの配点については、毎回、各種目とも、論述のウェイトがイマイチ
軽いような気がします。（今までの調査に基づいているとは思いますけどね）
「論文まで行ってくれ！論文を評価してくれ！」が今の気持ちです。
（合格させてくれ！が本音だけど、こんなに外したんだからと、とっくにあきらめています。）
Ｂ以下だとしても、論文の評価を見て、今後の対策を検討したいと思います。
秋の準備については、既に始めましたが、種目は、もう７回目くらいのＮＷです。
今度こそ、合格したいと思います。
ＤＢを保持しているんで、ＮＷ取れたら、両手に花です。
（両方保持している方は、仲間うちでも、かなり評価が高いですからね。）
今年合格しないと、来年秋は、今のＮＷ相当か、システム管理相当のバッティングですからね。
（システム管理に行き着きそうですが・・・）
春は、何受けようかしらん？セキュリティが有力ですが、この際、監査に
挑戦するのもいいかも・・・
[194] ＤＵＫＥ (2008/05/08 Thu 23:43)
ＤＵＫＥさん
こんばんは
書き込みありがとうございます。
いくつかコメントします。
・合格発表までは、複雑な心境ですよね。「あー、あそこを間違えなければ」とか「ああ書いていれば」とか、色々思います。
・この試験は秋に移動するため、次は１年半後ですね。これって長いですよね。
・NWとDBをダブルで持っている人は、少ないです。評価が高いと思いますよ。私も、NW受かって４年後にDBを受かりましたが、「資格はこれで十分」と思いました。
・来年の春ですが、、、私も受けるものがあまりありません。受かりそうな試験もほとんど皆無です。秋は、NWをもう一回受けたり、SMをもう一回受けたりしたいと思ってます。
また、遊びに来てください。
[195] 管理者 (2008/05/09 Fri 21:23)
模範解答出ましたけど、何となく、素直じゃないなぁって、気がします。毎度のことですけどね。
＜問１＞
設問１（１）①なんか、確かにそのとおりだけど、原因究明が遅れたからじゃないの？
理由の解釈が、非常に曖昧だと思います。
「２回も、同じチェックやったから遅れた。」みたいな旨、書いたので、多分ペケ。
原因究明のやり方のほうに、問題があるとしか、思えなかったですけどね。
＜問３＞
設問１（２）なんか、業者同様、「毎月再編成に変更する」旨書いたが、模範解答は、
「サイクル短くする」って、そのとおりだけど、なんか具体性がない。
問題文の前提条件が、曖昧だから、毎月と特定できないと判断したのだろうか？
（半年とか、数ヶ月おきとか、書いたのがいるのだろうか？）
テクニカルＤＢ保持者の私としては、「毎月やったほうがいい」に決まっている。
何のため、毎月メンテやってんの？
＜問４＞
設問３（２）「使用されていない」って、いうより、そもそも、新規ＤＢは「接続されていない」から、
「使用できない」んじゃないの？
「現行ＤＢが接続されていて、新規ＤＢは、切り離されているため。」なんじゃないの？
本設問の模範解答が、一番、理解不能だ。
全般、キーワード（「単位時間あたり」等）の漏れがあったので、
午後Ⅰ通過は、厳しくなりました。解釈誤ったところとか、キーワードの漏れとかは、
反省要だけど、だいたい、時間に追われるから、多少はやむをえない気もしている。
（高度の午後Ⅰは、だいたい、そういう傾向がある。）
通過したところで、論文チャチだし、１年半後にリベンジだな。
来年春は、システム監査に挑戦しようかな？
[196] ＤＵＫＥ (2008/06/04 Wed 22:43)
問１については、設問１（１）②もおかしい。「８時までに」って、明示しなければ、ＳＬＡは守れないはず。今ごろ、模範解答出すのに、なぜブラッシュアップしないのか、不思議。
[197] ＤＵＫＥ (2008/06/06 Fri 23:27)
不合格です。
午前試験のスコアは，660 点です。
午後I試験のスコアは，620 点です。
午後II試験の評価ランクは，B です。
ううむ、あの論文ではやはり駄目だった。
秋は、ＳＭの後ガマを受けることにします。
惜しいような、却って最悪なような気がします。
午後Ⅰのボーダが非常に高いですね。６００点
前半なんて、思いもしなかった。午後Ⅰから、しっかり
やらないと駄目ですね。
[198] ＤＵＫＥ (2008/06/16 Mon 11:10)
こんにちわ。初投稿です！
午前 45/55
午後１ 65%～75% (1,2,3)
午後２ ↓です。
障害の長期化対策というより、障害対策的な論文になってしまった感があります。
強引に連絡（＝障害検知）・連携（＝ベンダーへの情報提供効率化・ユーザへの広報）・
想定外に事態代替策（＝部品の冗長化）で逃げましたつもりですが、なんか…変。
さらに言うと、２－１は原因視点と原因を分けずに記述した点はまずったなぁ・・・
ここで、障害対策的な論文へと進みだしたような気がします。
まとめ3章で2日の長期停止に対して、今は停止してませんってかいたら、長期化を短期化に
出来たって言えてない気がするが。
【問題】
問３ システム障害の長時間化の防止策について
システム障害が想定を超えて長時間化した場合、それによる損失は甚大なものとなる
ことがある。このことから、システム管理エンジニアは、できる限り短い時間でシステ
ム障害から復旧できるように、長時間化の防止策を講じる必要がある。
例えば、システム障害が長時間化した場合は、対応の経過を整理した上で、次のよう
な視点から長時間化した原因を究明し、防止策を立案・実施する。
（１）連絡は適切な時間内に実施できたか
例えば、障害検知の遅れや、連絡不備による初動の遅れはなかったか。
（２）情報は適切に収集できたか
例えば、スキル不足や手順・体制の不備で情報が混乱することはなかったか。
（３）手順は適切であったか
例えば、並行して実施できる作業はなかったか。
（４）想定外の事態に適切に対応できたか
例えば、修理部品の到着の遅れに対し、代替策はとれなかったか。
（５）部門間の連携は適切であったか
例えば、開発部門との間で、復旧方法の確認に手間取ることはなかったか。
原因の究明や防止策の立案に当たっては、運用部門だけでなく、開発部門や利用部門
などの有識者を交えたレビューも有効である。
あなたの経験に基づいて、設問ア～ウに従って論述せよ。
設問ア あなたが携わった情報システムの概要と、長時間化したシステム障害の内容及
び業務への影響について、８００字以内で述べよ。
設問イ 設問アで述べたシステム障害について、長時間化した原因をどのような視点か
ら究明したか。また、長時間化した原因は何であったか。それぞれ具体的に述べ
よ。さらに、立案・実施した防止策について、工夫した点を中心に具体的に述べ
よ。
設問ウ 設問イで述べた防止策について、どのように評価しているか。今後の課題は何
か。それぞれ簡潔に述べよ。
第一章 私が携わった情報システムの概要と長期化したシステム障害の内容と業務への影響
１－１ 私が携わった情報システムの概要
現在、私は製造業を営むA社にてOAシステムの運用管理に携わっている。
当システムは、ネットワーク上のユーザ情報やコンピュータ・ファイル情報を一元管理できるものである。
当システムに登録されたユーザは認証処理を経て、ファイル情報などにアクセス可能となる。
ユーザは、当システムを主に業務で使用するファイルの共有する場として活用している。
ユーザ数・コンピュータ数はともに5000程度である。
当システムを搭載したサーバは拠点10箇所に分散配置されている。拠点によって24時間稼動であることから
システムにおいても、原則24時間常時稼動の体制で運用を行っている。
私は、当システムの情報の登録や削除また、機器管理などの運用管理を行っている。担当者は3名で
必要があれば、拠点サーバへは遠隔操作で保守作業をおこなう。
１－２ 長期化したシステム障害の内容と業務への影響
当システムは、業務で使用するファイルを保存している為、システムが停止した場合は多大な損害が発生する。
製造業の当社では、物流において配送の停止・販売において販売の停止が発生し、致命的な問題となる。
また、人事データなども扱えなくなることから、本社機能も停止することになる。
障害について、当システムは大容量のHDDを搭載してはいるが、大容量の業務ファイルを保存していることによって、
HDDの枯渇が発生した。枯渇により、新規データの保存や更新不可の問題が発生した。
また、同時期、HDDの障害は発生してシステムダウンとなり、サービス停止となり全体の復旧に2日の間費やすことになった。
我々、運用担当者は、このような障害を未然に防ぎ、また障害発生時は極力停止時間を短縮するように
取り組まなければいけない。
（780文字くらいだった気がする。）
第二章 システム障害の長時間化した原因究明の視点と解決策について
２－１ システム障害の長時間化した原因究明の視点について
当システムの問題は２つに分けて考える必要がある。
（１）HDD枯渇の問題について
HDD枯渇の問題は、ユーザに対して自由に使用を許可して枯渇状態となっってしまった。
HDDの枯渇状態となってから増設の対応をしてしまった為、2日の停止となってしまった。
そこで、デスクの使用率を監視していれば、枯渇となる前に検知して対策を行うことが出来た。
また、使用状況をユーザへ広報する場があれば、不要ファイルの削除やデータの圧縮を行ってもらうことも可能であった。
（２）HDDの障害の問題について
（**** このから記憶があまりない ****）
原因については
・パーツの故障
・CEの連絡が遅くなった
視点については、
・障害がおきた時、検知できるようすれば、早急に対応可能
・障害がおきることを前提にした冗長構成を採用していれば、障害時もサービス維持してその間に保守可能。
（活性保守可能）
的なことを書いた。
（**** ここまで ****）
２－２ 障害長期化の解決策
（１）HDD枯渇の問題の解決策
当問題については、ツールを導入して、1時間の間隔でHDD使用率を取得するようにした。
取得した情報は、管理コンソール上に一元管理され、拠点・使用率を一画面上に表示できる。
使用率90％を超える拠点は、赤文字で目立たせる仕様である。また、異常時はメール通知を管理者へ発信する。
さらに、取得した情報はイントラへ掲載することで、ユーザが使用率の閲覧可能となった、
この事で、枯渇となる前に、ユーザ自身は不要ファイルの削除や圧縮を行い、
管理者はデスクの増設なども余裕をもって行うことが出来る。
なお、当ツールは当社で導入実績のあるものであり、導入時に時間を費やさずに導入できた。
（２）HDDの障害の問題の解決策
当問題について、パーツの故障は回避できない。特に当システムは読み書きが多いため、HDDの劣化に注意しなくてはいけない。
そこで、冗長構成を採用した、メモリ・CPI・電源などには冗長構成を採用して、特に気にしなくてはいけないHDDについては、
RAID５＋ホットスペア1本の二重の冗長化を行った。また、ツールを導入した。
当ツールは、障害時には情報を管理コンソールへ届ける。管理コンソール上では、異常時には赤文字で目立たせる仕様である。
また、当ツールにおいてもメール機能を持ち、異常時はメールは担当者へ配信する。また、ベンダーサポートへ情報を届ける。
このことで、障害を早急に検知するとともに、障害時は冗長化によりシステムの停止を回避出来る。
また、ベンダーサポートへ連絡も効率的に行え、早急にCEの手配を行える。そして、部品交換は活性保守で行える。
なお、当ツールはすべての機器で同一ベンダーだったこともあり、無償で導入することができ初期投資を抑えることが出来た。
（第二章は、1300文字強だった気がする）
第三章 防止策の評価と今後の課題
（～簡略～）
３－１ 防止策の評価
HDD枯渇の問題の解決策については、対策前は2日の間停止してしまったことがあったが、
対策後、枯渇前に対策を行えてる。ユーザは不要ファイルを削除してくれている。
だから、停止は起きていない。
検知の早急化やユーザが削除してくれて、管理の軽減化が出来ている。
HDDの障害の問題の解決策は、2日停止していた事があったが、障害時も冗長化のおかげで
停止していない。また、CEを早急に手配可能。活性保守で停止しないで回復可能。
検知の早急化と情報連携の効率化。
全体的に検知の早急化と運用負荷の軽減化を行えている。自分も評価できる。
３－２ 今後の課題
今後は、現在の担当者が移動などに備え、対策を行ったところなどについてマニュアル作成を行う。
注意しなくてはいけないところは、スキルレベルよって、判断を必要とするようなマニュアルではないものを
にして、復旧手順や、今回の変更点などを洗い出し作成する。
（第3章は750文字くらいだった）
[193] なんだかなぁ (2008/05/05 Mon 14:34)
こんにちは。
試験が終わって、風邪を引いてしまいました。
６月１６日の合格発表までの間、皆さんはどうやってすごしていますか。というのも、試験が終わって、ちょっと気が抜けた生活になっています。個人的にはOracleMasterでも６月までに受験しようかと。その後、秋に別の情報処理技術者試験を受けようかなどど考えていますが。ただ、まだ気合が入りませんが。。。差し支えなければ、みなさんの今後の目標など教えてください。
[190] まさやん (2008/04/28 Mon 16:59)
こんにちは
試験が終わると気が緩んでしまいました。ネットサーフィンばかりしています。まさやんさんの記事を読んで、共感しました。秋試験を今からやる気はしません。がんばれない。
今の期間の使い方として、試験勉強期間にはできない勉強をしたいと思います。私はサーバの構築経験が少ないので、メールサーバやWWWサーバなどを構築し、基礎を勉強したいです。それが実務や試験対策につながると思います。
他の皆さんはどうですか。教えてください。
[192] みんと (2008/04/29 Tue 07:51)
はじめまして。ずっとこのサイトでみんさんのがんばっている姿に励まされ、こつこつ勉強してシステム管理を受けました。管理人様や、がんばられた皆さんに感謝したいと思います。
昨日の感想を少々。
午前の試験ですが、私が受験した会場では、みな早々に解答を書き上げて、試験が終了する前にほとんどが出て行ってしまいました。焦りましたが、私は自信がなかったので、最後まで残りました。
結果は、４９問正解することができました。
しかし、午後１は時間がない中で苦しい解答になってしまい、まるっきりだめでした。
みなさんは時間がない中で、どうやってあの難問を解いていらしゃるのでしょうか？問題を読むだけでも、１０分以上かかってしまいます。そこから設問を解く際にも、何度も設問を読み返すので、とても３０分以内では終わりません。
普段の仕事の中で、文章を早く読み、まとめあげる力を養うのが基本だとは思うのですが、問題を解く上でなにかアドバイスがありましたら聞かせていただけないでしょうか。よろしくお願いします。
[176] まさやん (2008/04/21 Mon 17:29)
あくまで私個人の午後I攻略法ですが「設問から先に読む」です。
文章は読む必要の無い内容が多いので、設問に回答するために必要そうな部分だけ読むようにしています。
もちろんデメリットもありますが・・・。
今回の試験だと問１の水曜日と土曜日がどうこうと言ったくだりを見落としそうになりました。
ですがそれ以上に時間が節約できるというメリットは大きいと私は思います。
別のテクニカルエンジニア試験ですが、この方法で挑んだところ2連続で失敗していた午後Iの試験が700点オーバーで合格できました。
万人にお勧めできるものではありませんが参考程度に。。。
[178] こま (2008/04/21 Mon 22:44)
まさやんさん こんにちは
試験お疲れ様でした
>問題を読むだけでも、１０分以上かかってしまい
>ます。そこから設問を解く際にも、何度も設問を
>読み返すので、とても３０分以内では終わりません。
難しい問題の場合、まさやんさんだけでなく皆さん時間がたりません。それほどご心配される必要はないと思いますが。
一つアドバイスです。私は監査を受け、問１がメチャクチャ難しくて、答えが分かりませんでした。あせればあせるほど設問と問題を中途半端に何往復もする状態に陥っていました。
こんなときに有効なのは、図に落とすことです。問題文を読みながら、各システムを図示し、運用をフロー化していきます。すると、頭の中が整理されるので、問題点やポイントがはっきりしてきます。
「時間が無いのに、図に落としていたら余計に時間がかかる」と思われたら、それは逆です。時間がないからこそ頭の中をきちんと整理する、それが時間短縮につながります。
一度お試しください。
また、問題文を読むときにポイントをマークしておくことも有効です。マークするのは、違和感があるところ（この文章が無くても成り立つ）、運用がどう見てもおかしいところ、など。マークしたところをそのまま引用すれば答えになることが多々あります。
[179] 管理者 (2008/04/22 Tue 04:01)
やまぽんです。
個人的な意見ですが、システム管理の午後１自体は
他の高度試験に比較すると問題自体は容易と思います。
その反面、パスするには高得点が必要と思います。
私の午後１の攻略方ですが、問題文を何回も読むと時間が不足するので、設問と関連付けて読んでいます。
具体的には、問題の最初の前提部分を読み、ポイント思われる部分にアンダーラインを引きます。
その後、問題を読み進み、途中で設問１を見ます。
設問１の解答後、設問２の部分に取り掛かります。
問題文の段落と設問は、多くの場合、順序が合っていますので、この方法で、切り抜けています。
問題文の段落がどの設問にも関連していない場合は
間違っている可能性があると思い、見直しをしています。
問題文の最初の前提部分をポイントを上手く抑えることが、重要で短時間で解答するコツと思います。
ご参考までに・・・
[180] やまぽん (2008/04/22 Tue 06:33)
ハチです。
他の方々も書かれているように、みなさん時間は足らないのです。
結果的にまさやんさんは、すべての回答を埋めることができたのでしょうか？
自分は時間が足らなくなったら、カンでも良いからすべて埋めること を目標にしてました。
割り切りも大切だと思います。
[181] ハチ (2008/04/22 Tue 07:31)
私も今回の試験は、やや時間が足りず、全ての問題を解くことができませんでした。いろいろテクニックはあると思いますが、今回の試験は過去問を解かないと無理だなと思いました。午後１の問題は、いろんな解がある場合があり、いろいろ検討しないと答えが出ないので、時間が足りなくなるのが当たり前です。この時間で解くには、どうしても充分な量を過去問を繰り返し解き、答えがすぐに思い浮かぶようにしておく必要があると思います。または、実務経験を積むことだと思います。
[182] 流星パピー (2008/04/22 Tue 09:28)
こまさん、管理人さん、やまぽんさん、ハチさん、流星パピーさん
ご回答ありがとうございます。こんなに多くの方にアドバイスいただいて、感動です。
今までも、疑問があったら書き込みをしておけばよかったと、今更ながら後悔しています。
こまさん、ありがとうございます。
「設問から先に読む」「設問に関係しそうなところ、部分だけを読む」
別のテクニカルエンジニア試験で、７００点オーバーはすごいです。
重要な点を読み飛ばす可能性があるが、時間短縮のメリットがあるということですね。
了解しました。
管理人さん、ありがとうございます。
「各システムを図示し、運用をフロー化する」
「違和感があるところをマークする」
とても参考になります。図示とフロー化。一度やってみます。
これができるようになると、確かに頭が整理されますよね。
今年私の中で、最も難しかったのは、午後１の問４です。頭の中で整理が出来ていませんでした。
自分なりに図示とフロー化してみます。
やまぽんさん、ありがとうございます。
「問題文の最初の前提部分のポイントを上手く抑える」
「問題文を設問と関連付けて読む」
問題の読み進め方も具体的で、たいへん参考になりました。。
ハチさん、ありがとうございます。
とにかく、すべて回答はうめてきました。合っている自信は全くありませんが。
とにかくうめて、部分点だけでも貰えればと思ってうめました。
時間がないのは、みなさんいっしょなのですね。
その中で、割り切ったり、工夫した読み方をされたりしているのですね。
流星パピーさん、ありがとうございます。
「過去門を多く解く。」「実務経験を積む。」
やはり、基本ですね。日ごろからの努力で力を養うということですね。
みなさん、アドバイスありがとうございました。
私は高度情報処理を受けたのは、これが初めてでした。
春の試験は終わりましたが、今からが始まりです。秋にも別の試験を受けたいと思います。
また、皆さんのがんばっている姿を励みに、私もがんばりたいと思います。
[183] まさやん (2008/04/22 Tue 18:27)
はじめまして、かんそくです。
システム管理試験お疲れ様でした。
午後Ⅰは問２、３、４を選択しましたが１０分ほど時間が余りました。
途中いい加減に書いた設問もあったので、もっとじっくり時間を使えばよかったです。
でも問１を選択から外したのは良かったのかな。
システム管理は初受験ですが、午後Ⅰについてアドバイスを～。
午後Ⅰの問題構成は次のようになってます。
・本文(始めから設問の前まで)は時間経過に沿って記述されている
・設問は見出しの段落と対応して出題される
各設問には文中の中括弧で囲われた見出しと対応させて、
「〔ID管理とID登録申請プロセス〕について(1)(2)に答えよ」
みたいに記載されてます。
そしてこれが大事だと思いますが、
設問は、始めの概要からその見出しまでの記述で解けるようになってます。
例えば今回平成２０年の問２設問１なら、
・最初の概要
・〔注文システムの利用方法〕
・〔ID管理とID登録申請プロセス〕
の範囲で解答できます。
ですので、
①本文を概要から設問１の見出しまで読んで解答。
②また本文続きを設問２の見出しまで読んで解答。
の繰り返しで効率良く読解ができると思います。
あと、まれに設問の見出しの順番が入れ替わってるときがありますが、
本文の順に設問を飛ばしてやるのが良いです。
以上、参考になりましたでしょうか。
[184] かんそく (2008/04/22 Tue 21:58)
かんぞくさん、ありがとうございます。
＞設問は、始めの概要からその見出しまでの記述で解けるようになってます。
＞①本文を概要から設問１の見出しまで読んで解答。
＞②また本文続きを設問２の見出しまで読んで解答。
＞の繰り返しで効率良く読解ができると思います。
なるほど。
具体的でたいへん参考になります。
ほんとに、もっと早い段階で質問を書き込めばよかったと、後悔するばかりです。
[185] まさやん (2008/04/23 Wed 11:05)
ハチです。
みなさん、お疲れ様でした。
初めての情報処理を受験しての感想は、
「時間が足りない」ということでした。
午前：
時間的にも余裕があり、２度ほど見直しをする時間がありました。
ヒッカケ問題にみごとにひっかかっている箇所が、何箇所もありました。
次回も、時間制限ギリギリまで見直しをしようと感じました。
ですが、見直した結果で間違った問題もありました・・
４３問正解 この時点であぶないです・・
午後１：
問１、２、４を選択
とにかく時間が足りませんでした。
終盤では時間に追われて、問題文をほとんど読まずに回答を書いてました。
問１に時間を使いすぎたのが敗因です・・・
午後１で不合格の可能性が高いです。
午後２：
問１を選択
文字数はなんとかクリアしましたが、
文章構成が上手くいかず、支離滅裂になってしまいました。
せっかく、論文の添削を頂いたのに、申し訳ありません。
総評：
時間制限を設けての「訓練」が足りなかったと感じました。
特に「読む」、「書く」の速度を上げないと
自分は合格できなさそうです。
次回は、この点に注意して再チャレンジしたいと思います。
ありがとうございました。
ＰＳ.
やまぽんさんと、まったく同じ選択ですね。
自分の回答も思い出してみます。
[170] ハチ (2008/04/21 Mon 09:06)
やまぽんです。
私も、午後１の設問１でペースを崩してしまいました。
SLA項目は簡単と思いますが、要因に、何を書くべきか
必要以上の時間をロスしました。
今考えると、それぞれの要因は、こうかな?
(1)早い時点で開発担当者に対処案を確認すべきであった。
(2)バッチ業務の再実行可能時刻を超過した時点で通知すべきであった
初めの問題で、特に簡単に見える問題に手こづると
後に響きます。
問４の設問２は、問題の主旨がつかめず、時間もなく、適当な解答を書きました。
午後１は、ボーダーラインかな?
[171] やまぽん (2008/04/21 Mon 09:49)
ハチです。
なんだか共に戦った「戦友」のような気持ちになりますね（笑）
要因のところはＳＬＡなので、数字を入れたほうが良いかと考えました。
（そんなこと考えてるから時間が足りなかったんですが・・）
午後１問１
設問１
（１）
サービス開始時刻
8:00のオンラインサービス開始時刻を意識せず、２度調査を行った。
運用変更通知
サービス開始が遅れることを利用部門へ６０分前までに通知しなかった。
（２）
端末属性管理テーブルの設定を戻す
（これはテンパってましたのでよくわかりません）
（３）
最近のリリースの状況をリリース管理台帳で確認する。
(もう少しなにか書きましたが、忘れました）
設問２
（１）
運用案Ａ：１２０分
運用案Ｂ：１７５分（７０分を足し忘れ）
（２）
ｂ.通常バックアップ後の増分バックアップ全て
ｃ.通常バックアップ後の最新の差分バックアップ
設問３
運用案Ａ
水曜日にも通常バックアップを行う
午後１問２
設問１
（１）
利用者ＩＤとＶＰＮＩＤの無効化申請書
（２）
ログファイルから云々・・・（間違ってます）
設問２
（１）Ｗｅｂアクセスログの漏えい
（改ざんが正しいと思います）
（２）ＦＷの内側にＷｅｂアクセスログを保存する
（微妙な表現ですね・・）
設問３
（１）
イ.ＩＤがＸ氏のＶＰＮＩＤ
ウ.アクセス日時が紛失日時以降
エ.アクセスファイルが顧客ファイル
オ.アクセス日時
（２）
各機器の時刻を同期させる為、ＮＴＰサーバを設置する
午後１問４
設問１
（１）Ａ系統の注文が現行ＤＢに書き込まれる為
（２）？憶えてません・・
（３）移行作業中の障害が発生した場合を考慮する必要がある
(チラっとＤＢのミラーリングが云々が見えたのでカンで書きました）
設問２
あまり憶えてません。
設問３
（１）
ａ．新規ＤＢサーバ切り離し
ｂ．現行ＤＢサーバ接続
ｃ．確認テスト
（２）
現行のシステムを維持するための構成は変更していないため
[172] ハチ (2008/04/21 Mon 11:37)
akiです、皆さんおつかれさまでした。
以下、長々と駄文失礼致します。
テクニカルエンジニアは初回の情報セキュリティで
惨敗して以来、1年半ぶりの受験でした。
過去に類を見ないほど頑張って勉強はしていたのです
が・・・、惨敗ですね（＝＝；
■午前 ４１/５５ でした。
５１～５５を全て外すという・・・。
そこまで快調だったんですけどね。
二択で勇気を持って全て外したおかげでぎりぎり
になってしまいました。
■午後１ 選択問１、問２、問３
ペースとしてはよかったのですが、本番で問題が解けた
嬉しさに調子に乗って上手く解こうとした問２が結果
的に時間を使いすぎ、次の問３で通常の時間になってしまったので、
最終的に問１に20分しかかけられず、単純な掛け算すら
間違えるという始末。冷静に読み直すと簡単なんです
けど、試験の雰囲気負けですかね。。
解答速報を見る限り、問１の結果が散々だったので
おそらくここでアウトです。
■午後２ 問２
これは対策不足がハッキリでてしまいました。
文字数も超えられず、途中から話が全く繋がっていない
というひどい論文になってしまいました。
開始30分かけて題材とネタを決めたのですが、アを書き終えた
時点で残り1時間を切っていました。
イを書き終えて残り15分、しかも、600文字も足りませんでした。
ウを書いて残り6行ほど。そして残り時間2分・・・。
最終日に色々と教えてもらっていたので管理者さんに申し訳ないです。。
来年は新しい内容になり、マネジメントとか経営の問題
も増えるそうで。ITILレベルが２にも満たない私には
実力不足すぎて受けられない試験になるんでしょうかねぇ。
[177] aki (2008/04/21 Mon 22:17)
再現論文：問１ SLAに基づく情報システムの運用について
論文構成メモから、覚えている範囲で作成してみました。
直近に経験した（笑）午後１の問4をヒントに、論文を捏造しました。
今日は、出張の移動日で、モバイル環境でアップしています。
------------------ ここから ------------------
１.情報システムの概要と合意したＳＬＡについて
１.１.情報システムの概要
私は自動車部品製造会社の情報システム部門に所属し
ており、システム管理エンジニアとして、製造工場の生産
実績収集・出荷指示システムの運用管理を担当している。
当社は、国内５箇所の生産工場で自動車部品を生産し、
顧客である自動車メーカに納入している。実績収集・出荷
指示システムは、本社に設置された６台のサーバと５箇所
の工場に設置される端末ＰＣから構成されるクライアント
サーバシステムで運用されている。当社の生産管理の特徴
は、顧客である自動車メーカの短納期での搬入指示に対応
することである。自動車メーカの生産ラインに同期して、
必要な自動車部品を生産し供給することである。また、自
動車メーカに納入時には、各自動車メーカしての専用納入
伝票の添付が義務付けられている。
従って、当実績収集・出荷指示システムにおいて、高い
可用性が要請される。
１．２．合意したＳＬＡについて
私は、当実績収集・出荷指示システムに関係する各部門
本社の生産管理部、各工場の工務部、出荷部と重視せべき
ＳＬＡ項目についての検討会を開催した。検討会での席上
では、いろいろな意見がでたが、当面の優先順位などを考
慮し、以下の３項目に決定した。
（１）サービス開始時刻の遵守
（２）専用納入伝票の出力に要する時間
（３）システムの稼働率
当実績収集・出荷指示システムは、本稼働後、１年が経
過し、システム的には安定期になってきた。システムの安
定化に伴い、当システムを適用する生産工程が増加してい
る。稼働当初より、システムの処理量が増大傾向にある。
システムの負荷も増大し、レスポンスの劣化や夜間バッチ
の遅延が問題となってきた。
２.ＳＬＡ遵守のプロセスと発生した問題とその解決法
２.１.ＳＬＡ遵守のため実施したプロセス
我々、システム管理エンジニアは、ＳＬＡを遵守したサ
ービスを提供する義務があり、そのためにＳＬＡ遵守のた
めのプロセスを確実に実行する必要がある。
私は、合意したＳＬＡを遵守するには、実績収集・出荷
指示システムの可用性と信頼性の向上が最優先課題と考え
た。現在のシステムを運用状況を正しく把握するために、
インフラ管理部門の協力を得て、システムを構成する６台
のサーバのシステム資源の利用状況をモニタリングした。
具体的には、ＣＰＵ使用率、メモリ使用率、ディスク使用
率である。その結果、一部のサーバは、システム能力が不
足していることが判明した。
可用性を向上するには、サーバ増強が最も有効なのは、
明白であるが、サーバの増強は、我々、システム運用部門
だけの判断では実施できない。また、信頼性の向上には、
全てのサーバを冗長構成にすれば、可能であるが、設備投
資の費用対効果を考慮すると簡単に実施できない。
そこで、私は、既設の６台の負荷バランスを考慮し、各
サーバの役割分担を変更することで、可用性と信頼性を向
上を図ることにした。現在、稼働中のシステムの構成変更
であるので、一斉に実施するのは、困難と考え、大きく３
分割して構成変更する作業計画案を作成した。
私は、作成したサーバ構成変更計画案を、システム開発
部門、インフラ管理部門に確認を依頼し、一部修正があっ
たが、原案通り、進めることの了解を得た。また、本稼働
中のシステムを停止しないで、構成変更するため、業務部
門の理解と協力を得るために、毎月開催される工場連絡会
で、サーバ構成変更案の概要を説明し、承認を得た。
２.２.発生した問題
私は、３分割して既存サーバの構成変更に着手した。
第１回目の構成変更の前準備は順調に完了して、事前調査
で業務処理量が最小の金曜日の午前中に構成変更を実施し
た。ここで、問題が発生した。広島工場からの出荷指示に
おいて、顧客の専用納品書の出力が大幅に遅れ、顧客への
出荷便に間に合わない事態が発生した。
幸いにも、広島工場の出荷責任者の迅速な対処で、出荷
担当者の残業対応と赤帽トラックを利用した特別便で出荷
することで、顧客への納入責任は果たすことができた。
私は、現在でもぎりぎりの処理能力で稼働しているシス
テムを、システム構成変更のためといえ、一時的に縮小す
るリスクの大きさを痛感し、反省した。
２．３．解決策
私は、既設６台のサーバの稼働させながら構成変更する
計画に関して、根本的な見直しが必要であると考えた。シ
ステム稼働状況で、構成変更するには、稼働中のシステム
を２重化し、１系統づつ切り替えるしかないと判断した。
我々、システム運用部門では、システム保守向上のため
当実績計上・出荷指示システムに負荷分散装置の導入を検
討していた。今回のサーバ構成変更に、負荷分散装置の利
用の検討に着手した。調査の結果、負荷分散装も、以前に
比較し安価な製品も販売されていることがわかった。
私は、サーバ構成変更のために、負荷分散装置の導入利
用を、上長に申請した。負荷分散装置の低廉化により、シ
ステム運用部門の予算内で、導入可能なので、導入が承認
された。
私は、インフラ管理部門と共同で、サーバ構成変更計画
を、負荷分散装置を利用した計画に変更した。負荷分散装
置の利用にて、サーバの切り離しおよび接続が動的に実施
可能となり、サーバ構成の変更は大きな問題なく完了した。
既設サーバの役割分担の変更により、合意したＳＬＡの維
持・改善が可能になった。
３.私の評価と今後の課題
３.１.私の評価
私が、今回実施した解決策は、有効であったと評価して
いる。以下に、評価するポイントを記す。
（１）システム構成変更中のサービスレベル低下を極小化
（２）負荷分散装置導入による可用性と信頼性の向上
（３）サーバ増設などの大きなシステム投資の抑制
３.２.今後の課題
現在のシステム構成では、負荷分散装置により、サーバ
処理は２系統で運用されているが、負荷分散装置は、１台
しか導入されていない。負荷分散装置自体が、ハード障害
で停止すると、サービスの継続ができない。
今後、負荷分散装置を追加導入し冗長構成とし、システ
ム全体の信頼性の更なる向上を推進して行くつもりである。
[175] やまぽん (2008/04/21 Mon 15:33)
ハチです。お疲れ様です。
Ｈ２０春の試験で書いた論文を、
骨子と記憶を元に復元しました。
改めて書いてみると「もっと、こうすれば良かった」と
思うところが多々あります。
この問は、「ＳＬＡの遵守のプロセス」の問題点と評価を問われているので、
評価で「ＳＬＡが改善した」と書いたらＯＵＴかな、と思いながら書きました。
それが正しかったのかもわかりませんが・・・
ここから-----
Ｈ２０問１
ＳＬＡに基づく情報システムの運用管理について
１．情報システムの概要と合意されたＳＬＡ
１－１．情報システムの概要
私は、全国に２０の拠点を持つクレジットカード会社に勤務するシステム管理エンジニアである。私は東京本社の運用監視チームのチームリーダである。私が携わった情報システムは顧客管理システムである。各拠点によせられる利用者からの問い合わせに対して、利用者登録状況やクレジットカードの利用状況を照会するシステムである。稼働時間は８：００～２０：００となっている。２０：００以降に時間には、夜間バッチ処理により、売上データの集計や、データバックアップが行われている。システム構成はＵＮＩＸサーバ２０台が本社に設置されており、各拠点に約３０台づつのクライアントがある。クライアントのＷｅｂブラウザから顧客情報システムを利用する仕組みとなっている。
１－２．合意されたＳＬＡ
ＩＴを利用したサービスを提供する場合、情報システムの運用を顧客や利用部門との間で合意されたＳＬＡに基づいて行うことが多くなってきた。
顧客管理システムにおいても、利用部門との間で社内ＳＬＡを合意している。合意しているＳＬＡは「オンライン稼働時間の遵守」である。顧客管理システムが停止した場合は、各拠点で照会業務が行えなくなる。代替手段としては、本社に設置されたメインフレームでの照会があるが、端末は本社にしか設置されていない。顧客管理システムが基幹インフラとなっている為、メインフレーム用端末の各拠点への配備は今後も計画されていない。この為、オンライン稼働時間８：００～２０：００は重要なＳＬＡとなっている。
２．ＳＬＡ遵守のためのプロセスと問題解決策
２－１．ＳＬＡ遵守のためのプロセスと問題点
ＳＬＡを遵守したサービスを提供することはシステム管理エンジニアの重要な職務であり、その為には次のようなＳＬＡ遵守のためのプロセスを確実の実行する必要がある。
（１）サービスレベルの継続したモニタリング
（２）サービスレベルの傾向分析
（３）サービスレベルが悪化した場合の原因究明と対策
（４）顧客や利用部門への状況の定期報告
しかし、ＳＬＡ遵守のためのプロセスを実施する際には、次のような問題が発生することがある。
・モニタリングの方法によってはサービスに影響が出る
・サービスレベルの悪化の原因を特定するための情報が不足している
・対策を実施するときにサービス停止が必要となる。
顧客管理システムにおいても、サービスレベルを悪化させる事態が発生していた。夜間バッチがデータ量の増加に伴い、長くなってきていた。現在は８：００のサービス開始時刻には間に合っているが、残り時間が４５分程度となってしまっていた。私は、夜間バッチ処理の改善が必要であると考えた。私は夜間バッチ処理の改善を行うにあたり、現状の把握しようとしたが、ここで問題が発生した。開発部門より提供されている設計書と現在のシステム構成に差異があり、夜間バッチ処理の問題点の究明に時間がかかってしまった。その後、サーバの設定を確認することで夜間バッチ処理の改善は行うことができた。しかし、私は開発部門との情報共有に不足があると実感した。
２－３．問題点の解決策
私は、開発部門との情報共有不足を解消するため、対策の検討を行った。私が所属する運用管理チームのＳＬＡは「サービス提供時間８：００～２０：００の遵守」である。このＳＬＡを阻害する要因としては、夜間バッチ処理の遅れがある。障害発生時の対応も要因となりうるが障害訓練も行っており、現在のところ問題は発生していない。また、障害対応自体は別チームにて担当しているため、運用監視チームの目的は、正確な情報を早く通報することにある。ここでも設計書の最新化は有効であると考えた。
具体的な解決策としては、設計書の内容を１つ１つサーバの設定と差異がないか確認していった。差異が発見されれば、該当のリリースの内容まで遡っての調査を行った。開発部門へは、全てのリリースの内容が設計書に正しく反映されているか確認を依頼した。運用監視チームはサーバ側から、開発部門はリリースからと逆の手順を行うことダブルチェックを行った。
幸い、顧客管理システムは、２００７年１０月より稼働開始と稼働より日が浅く、リリース回数も１３回であった。このためすべてのチェックをおえるのに、のべ工数８日で完了することができた。このことで設計書の内容は最新化され情報共有は強化された。
情報共有不足の解決策としては、運用監視チームと開発部門とのジョブローテーションなども考えられるが、開発効率の悪化を考え、今回の実施は見送った。
３．解決策の評価と今後の課題
３－１．解決策の評価
今回実施した解決策は、社内にて高く評価された。評価された点は下記となる。
・設計書が最新化され、情報の精度が向上したこと
設計書が最新化されたことで運用改善への取り組みが行いやすくなったことを評価された。
・障害発生時の通報の情報精度が向上したこと
運用監視チームからの通報の情報精度が向上し、対応の品質が上がったことを評価された。
３－２. 今後の課題
今回の再チェックにより、設計書は最新化され対応の品質は向上した。しかし、今後のリリースにおいても同様の問題が発生する可能性がある。リリース管理の改善と今後の継続した取り組みが今後の課題である。
[174] ハチ (2008/04/21 Mon 13:46)
試験お疲れ様でした。
■午前
7割できていればまず間違いなく合格ですので、
38問あっていればいいでしょう。それ以下受かった人もたくさんいます。
■午後Ⅰ
午後Ⅰは時間がないので、皆苦しい状況です。条件は同じなので、案外高得点かもしれませんよ。
■itacさんの解答速報
以下に掲載されていますので、参考にしてください。
http://www.arkweb.co.jp/~haru2008/kaitourei/sm.html
[173] 管理者 (2008/04/21 Mon 12:30)
やまぽんです。
システム管理試験を初めて受験しました。
感想と自分の解答を投稿させていただきます。
【午前】
試験センターの解答例と照合したところ、４６問正解でした。
【午後１】
問１、問２、問４を選択しました。
初めの問１に時間を取られ、問４は15分での解答になりました。
自分の解答を記憶している範囲で記載します。（間違いもそのままです）
自分の感覚では、問１（50%)、問２（80%)、問４（70%)で、全体（65%）で
600点、ギリギリでクリアを期待しております。
問１
設問１
(1)SLA項目 サービス開始時刻
要因 トラブルの原因究明に行き詰まり、サービス開始時刻が遅れた。
SLA項目 運用変更通知
要因 トラブルの原因究明と復旧に始終し、利用部門への連絡を怠った。
(2)バックアップからマスタファイルを復旧する
(3)修正したプログラムのリリースに関して情報をシステム運用担当者に
連絡しておく
設問２
(1)運用案Ａ 120分、運用案Ｂ 245分
(2)b 全ての増分バックアップファイル
c 直近の差分バックアップファイル
設問３
運用案Ｂ（×：正解は運用案Ａ? 70分＋10分X2=90分から）
対策：水曜日にも通常バックアップを実施する
問２
設問１
(1)利用者ID無効化申請書とVPN ID無効化申請書
(2)ID管理システムからのユーザ一覧表と販売課の営業員との
定期的な整合性確認を依頼する
設問２
(1)Webアクセスログも改ざんされるリスクがある
(2)Webアクセスログを社内LAN側に配置変更する
設問３
(1)イ IDがX氏の利用者ID
ウ アクセスに値は紛失日時以降
エ アクセスファイルが注文ファイル
オ アクセス日時
(2)各期機のシステム時刻を同期するシステムの導入が必要である
問４
設問１
(1)販売サイトを停止せず、販売システムを運用中にシステム移行を
実施するため
(2)顧客マスタ、注文マスタ
(3) ⑧
データ反映の更新処理実施中は、販売サイトの停止を検討する
設問２（問題の主旨が判らないがとりあえず記入しました）
(1)商品マスタ
月末夜間に販売担当者がオンライン更新するから
(2)注文記録マスタ
月末日に月次バッチ処理で一括更新されるから
設問３
(1) a 新規DBサーバ切り離し
b 現行DBサーバ接続
c 確認テスト
(2)フォーマット変換作業は、新規DBサーバを利用して実行されるから
【午後2】
問１を選択しました。
再現論文は、別途、投稿させていただく予定です。
[169] やまぽん (2008/04/21 Mon 08:34)
みなさん、試験お疲れ様でした。
感想も投稿いただきありがとうございます。
試験は一発勝負、時間は短い、緊張する、苦しい戦いですね。私もシステム監査を受けたのですが、（試験の出来はおいておいて）最後まで戦い抜いた自分を褒めてやりたいです。
特に、”手”が疲れました。”頭”以上に疲れてます。
※記事は分けていただいた方が、皆さん見やすいと思います。よろしくお願いします。
[168] 管理者 (2008/04/21 Mon 05:55)
５時間以上の長丁場お疲れ様でした。
論文は疲れますよね。
出来はいかがでしたでしょうか？
本日の感想、復元答案があれば、ぜひアップしてください。
今日は本当にお疲れ様でした。
[164] 管理者 (2008/04/20 Sun 18:39)
はじめて書き込みさせていただきます。
やってしまいましたｗ
午後１でだめだろうなーと思いつつ午後２を受けたら問題選択に付けずに３番の論文書いて提出しちゃいました。
まぐれでも論文のだめさ加減の評価をみたかった(T_T)
[165] むむ (2008/04/20 Sun 23:09)
はじめまして。はじめと申します。
初めて投稿します。
これまでずっとこのサイトをＲＯＭってきましたが
とうとう今日試験本番を戦いました。
たぶん午後一だめなんだろうな…
と落ち気味のところですが。。
論文は慣れてる障害系の問３を選びました。
文章の中身は、本当にこないだ起きた障害で
一切脚色のないリアルの話でございます。
※大げさな話や、脚色した部分も一切なしです。
多分落ちてるんだろうと思いますが
一応午後二の問題文と論文を投稿してみます。
よろしくお願いします。
【問題】
問３ システム障害の長時間化の防止策について
システム障害が想定を超えて長時間化した場合、それによる損失は甚大なものとなる
ことがある。このことから、システム管理エンジニアは、できる限り短い時間でシステ
ム障害から復旧できるように、長時間化の防止策を講じる必要がある。
例えば、システム障害が長時間化した場合は、対応の経過を整理した上で、次のよう
な視点から長時間化した原因を究明し、防止策を立案・実施する。
（１）連絡は適切な時間内に実施できたか
例えば、障害検知の遅れや、連絡不備による初動の遅れはなかったか。
（２）情報は適切に収集できたか
例えば、スキル不足や手順・体制の不備で情報が混乱することはなかったか。
（３）手順は適切であったか
例えば、並行して実施できる作業はなかったか。
（４）想定外の事態に適切に対応できたか
例えば、修理部品の到着の遅れに対し、代替策はとれなかったか。
（５）部門間の連携は適切であったか
例えば、開発部門との間で、復旧方法の確認に手間取ることはなかったか。
原因の究明や防止策の立案に当たっては、運用部門だけでなく、開発部門や利用部門
などの有識者を交えたレビューも有効である。
あなたの経験に基づいて、設問ア～ウに従って論述せよ。
設問ア あなたが携わった情報システムの概要と、長時間化したシステム障害の内容及
び業務への影響について、８００字以内で述べよ。
設問イ 設問アで述べたシステム障害について、長時間化した原因をどのような視点か
ら究明したか。また、長時間化した原因は何であったか。それぞれ具体的に述べ
よ。さらに、立案・実施した防止策について、工夫した点を中心に具体的に述べ
よ。
設問ウ 設問イで述べた防止策について、どのように評価しているか。今後の課題は何
か。それぞれ簡潔に述べよ。
【論文】
１．情報システムの概要と長時間化した障害について
１－１ 情報システムの概要
私は、東京にあるシステムインテグレータにて社内
業務用グループウェアを運用する、システム管理エン
ジニアである。（社内システム担当所属）
当グループウェアは、電子メール・ワークフロー・
スケジュール管理・規定類管理・勤怠管理・掲示板な
ど、社員の日常業務においてなくてはならないツール
となっている。
当グループウェアは、グループウェアサーバ・ＤＮ
Ｓサーバ・メールサーバ・メールゲートウェイサーバ
の４台にて構成される。利用者は全社員の６５０人で
ある。
１－２ 長時間化した障害の内容及び業務への影響
今年３月、メールサービスが１５時間程度と大幅に
遅延した性能障害が発生した。
上記にも示したように、当グループウェアは当社社
員の日常業務ではなくてはならないツールであるが、
障害対応の手際が悪いため、復旧に丸２日もかかって
しまった。これにより、業務効率が大幅に低下し、各
所で開発作業の遅延が発生した。費用にすると数百万
円規模の損失が出たと見込まれる。
２．長時間化した原因とその究明について
２－１ 原因の究明
障害が長期化した原因の究明については、適切な連
絡・適切な情報収集・適切な手順など様々の角度から
のアプローチが可能である。
２－２ 連絡について
そもそも、当社の社内システム担当は、障害が発生
しても社員からの問い合わせを受けて始めて動くよう
に、障害対応に関する意識が低い。このため、障害検
知のしくみもないことから、ミッションクリティカル
な障害に対しても対応の初動に遅れが発生した。
２－３ 情報の収集について
通常運用時の運用手順書は豊富にあるが、障害発生
時に情報を取得する手順は存在しない。また、社内シ
ステム担当は運用部門であるため、社員のスキルも低
い。したがって、障害発生当初は何もできずに途方に
暮れてしまい、早期に適切な情報を収集できなかった。
２－４ 部門間の連携について
社内システム担当は、本社の経営企画部の一部門に
属している。このため、担当部長は社内でも大きな権
限を有していることから、部長の鶴の一声で初期構築
時のメンバを招集することができた。なお、召集した
初期メンバは、業務とは異なる部分で付き合いが多い
ため、作業の連携はスムーズにいった。
２－５ 想定外の事態について
初期構築時の有識者へ各種の解析作業の指示を出し
た。ボトルネックとなる候補として、サーバ・ネット
ワーク・回線・ルータを挙げ、これらの性能情報の中
で、通常の動きとは異なる挙動を見せるデータを探し
解析するよう作業指示を出した。
しかし、解析の結果、特に問題となるデータは存在
しないことが判明した。結果的に、原因はハードウェ
アの老朽化に伴う性能劣化であることがわかったが、
解析作業時には、原因としてソフトウェアの可能性に
強く固執してしまっていたために、想定の外にあった
ハードウェアが起因であったことから原因究明が長時
間化してしまった。
２－６ 原因と実施した防止策
上記の究明より、実施した防止策と共に、原因を下記
に挙げる。
①障害検知の仕組みがない
障害監視用ミドルウェアを導入するのはコストがかか
ることから、有識者と共に障害監視スクリプトを作成
し、障害の予兆が発生した場合、直ちに社内システム
担当者へメールが届くような仕組みを導入した。
②障害解析用データ収集手順がない
有識者と共に障害解析用データ収集手順書を作成し、
運用ルールを策定することで、障害時の解析作業に必
要となるデータを収集可能とした。
③ハードウェア障害に関するノウハウがない
日頃から開発部署で協働しているハードウェアベンダ
との勉強会を開催し、ハードウェア起因の障害切り分
けノウハウを社内に蓄積する。
３．防止策の評価と今後の課題
３－１ 防止策の評価
もともと社内システム担当では、障害が発生した場
合には放置気味であったが、今では障害検知メールが
届くと早急に解析用データを収集するよう動けるよう
になった。これは、障害の長時間化を防ぐという意味
では大きく進歩したといえ、高く評価できる。
３－２ 今後の課題
障害の長時間化を防ぐという観点から、可用性確保
の視点で見てみると、今回の防止策はＭＴＴＲを短縮
する対策であった。今後は、機器の二重化など、ＭＴ
ＢＦを長時間化する対策を実施していきたい。
以上
[166] はじめ (2008/04/20 Sun 23:38)
おはようございます。以前 論文を見て頂いたくろすです。
添削大変ありがとうございました。独学だったのでアドバイスはとても参考になりました！
その後、ＰＣの故障などで論文アップまでに至らず、試験当日を迎えてしまいましたが、ぜひお礼が言いたくてやってきました。
＞本日の感想、復元答案があれば、ぜひアップしてください。
感想は、「時間が無い…」この一言です。
「時間が無いよ」と聞いていたので、午後１，２共に時間を計ってやっていたんですが、今ひとつピンと来ていませんでした。
今回初めて受験し「これか…」と言う感じです。
午後２を最後まで書けなかったので玉砕決定とは思うものの、どういう採点になるのか知りたかったです。
あまりにがっかりしていて、午前の答え合わせすらが終わっていませんが、どうせ玉砕決定なら次の勉強を始めなくては…と思いますので(^^;)、近いうちに復元答案のアップまで行きつけるようにしたいと思います。
なお、その場合、別にスレを立てた方がよいのでしょうか？
乱文ですが、まずはお礼まで…
[167] くろす (2008/04/21 Mon 03:14)
akiと申します。
以前メールで連絡させて頂いた者です。
以下は初めて書いた論文です。
皆さんよりとてもレベルが低く、採点に値しない
などひどい内容かもしれませんが、考え方、書き方
などいくつかご指摘頂ければと思います。
お忙しいところ恐縮ですが、よろしくお願いいたします。
---------------[以下本文]----------------
１．携わった情報システムの概要と作業ミスによる障害
１．１ 携わった情報システム
私はお客様先として、クレジットカードの取り扱いに
関する業務を行っているＴ社の情報システム課に常駐して
いるエンジニアである。ユーザー数は約３００人、端末
３００台、サーバー約２０台がネットワークに参加している。
そのサーバーのうち、ユーザー管理サーバー（以下、ＡＤサーバー）
は、社内のすべての端末でログインの操作で必ず必要となっており、
このサーバーがダウンすると社内の端末が全く利用できない状態となり、
Ｔ社のお客様からの問い合わせや、カードの発行など全ての業務がストップ
してしまい、被害は甚大なものとなってしまう。
また、ＡＤサーバーはその他の社内インフラであるファイルサーバーや
グループウェアからも認証を行っており、社内のポリシーでファイルは
必ずファイルサーバーに置くルールの為、ファイルサーバーの利用率も
非常に高い。
１．２ 作業ミスによる障害と作業ミスについて
（１）作業ミスによって発生した障害
ＯＳの開発元からリリースされた更新プログラムには、管理に
役立つ新機能が追加されていたことが分かった。私たちは開発元を信頼し、
オンライン終了後に更新プログラムを用いてＡＤサーバーを更新した。
同日に実行した端末や社内インフラへのログインテストは正常に完了
していた為、問題無いと考えられていた。
しかし、実際はＡＤサーバーと連携を取るファイルサーバーで、通常使用
する上では問題無いが、新規ユーザーを作成した場合のみ、ＡＤサーバーに
認証を拒否されていた。
この為、新規ユーザーを追加することができなくなり、派遣など、ユーザーの
入れ替えが激しいＴ社にとって由々しき問題であった。
（２）作業ミス
これは、システム管理者の作業ミスといえる。それは、「大丈夫だろう」
という油断や安易な思い込みがあったからだ。
２．作業ミスの原因と実施した対策
２．１ 作業ミスの原因
障害を発生させる原因には、
①不注意
誤クリック、ケーブルの誤切断など
②知識不足
ＯＳ、ネットワーク、ハードウェアに関する専門知識
③思い込み
大丈夫だろう、問題ないはずだ、など
④慣れ
自宅・以前と同じ手順で大丈夫
以上のような４つがある。特に、今回は上述のことから、③と④について
の対策が必須であると考えた。
２．２ 実施した対策
具体的な対策として以下のようなものが挙げられる。
①チェックリストに基づいた作業の実施
作業のチェックリストを作成し、１つ１つ確認しながら
作業を行うこと
②複数人での作業の実施と相互確認
複数人でチェックリストのレビューから作業までを
実行し、相互確認をすることでチェックの精度を高める
③作業手順書へのチェックポイントの追加
設定変更の際には作業を中止してでも、元に戻さなければ
ならないタイミングを設定しておく
④重要な操作に対する確認メッセージ表示機能の追加
画面への表示によって管理者へ警告を行い、誤判断、思い込み
が少しでも起きないようにする
今回問題となったのは、「思い込み」「慣れ」であったが、他にも
問題が残っていた。
それは、
■作業時における体制
である。作業が出来るメンバーが私を含めて２名しかおらず、夜間
対応後の翌日などは残りの１名がカバーする体制となる為、作業は
どうしても、立会いを行うお客様と、システム管理者１名という体制
である為、作業中の相互チェックができないことが問題となっていた。
その為、私は以下のような対策を考え、実行した。
■作業チェックリストの強化・精度アップ
相互チェックが出来なければ、作業チェックリストを強化し、精度を
上げる他に手はないと考えた。その理由は、作業前であれば２名体制の
リソースがフルに活かせると考えたからである。
事前にテスト環境を用意した上で作業の検証を行い、その結果を資料に
反映させ、実際に画面を操作しながら、チェックリストの項目と内容を
全てチェックする。その中で、管理者同士で声に出して読みあわせを行う
ことで、慣れによるミスも防ぐことが出来る。
２．３ 重要と考えた対策とその理由
私が最も重要と考えたのは、お客様との連携である。以前は、作業内容に
ついてはシステム管理者任せとされており、お客様に対して作業内容を
説明することが無かったのである。しかし、作業前に内容をご説明し、ご理解
頂けるかどうかで作業の可否を検討することが出来る。また、実作業に立ち会って
頂くことから、一時的にお客様の力を借り、簡単なメッセージを一緒に読み取って
頂くなどで、不可能であった相互チェックも可能になると考えたからだ。
この結果、技術的に難しい作業であったとしても、お客様との連携も合わせて
スムーズに進むようになり、作業効率が上昇した。
３．対策の評価と今後の課題
３．１ 対策の評価
私が行った対策はおおむね良好といえる。それは、今までシステム管理者の
考え方だけで行っていた作業で、お客様の知恵をお借りできる為、多数の方面から
問題を解決しようとする風潮が生まれたからである。その障害から３年経った今でも
その風潮は根付いており、定期的にサーバー関連の報告会を行い、作業前には必ず
全ての作業情報をシステム管理者側で話合ってからご相談出来るようになったことから
特に夜間の構成変更における作業効率が概算で３０％以上上昇したと見られる。
更に、油断、思い込みによる作業ミスは全く無くなった。
３．２ 今後の課題
お客様との連携による作業プロセスの改善は効果的であったが、プロセス改善中に
確認の為の打ち合わせ等が多くなり、作業前に行う確認時間が逆に増えてしまって
いた。今後は、報告用のファイルのテンプレート化、ノウハウのデータベース化など
トータルで見て早期に問題を解決できる仕組みを構築出来ることが必要と考えられる。
以上
[154] aki (2008/04/17 Thu 02:20) mail
akiさん
回答が遅くなりまして大変申し訳ございません。
以下にコメントさせてもらいます。
■
>エンジニアである
立場を明確にするために、「システム管理エンジニア」としましょう。
■
>ユーザー数は約３００人
お客様ではなく、利用者ですよね?迷いますので、迷わない表現にしましょう。
「このシステムの利用者は、T社社員300人」
■
>ユーザー管理サーバー（以下、ＡＤサーバー）
ADサーバと言い換える意味が不明です。「ユーザ管理サーバ」という言葉を以降も利用してください。
アカウント管理をしているので、ディレクトリサーバという表現が適切かもしれません。
■
>被害は甚大なものとなってしまう。
表現が抽象的です。売上停止、信頼の喪失など、具体的な言葉を入れましょう。
■アの文字数
４行オーバしていますね。この時点でアウトです。
■
>（１）作業ミスによって発生した障害
”障害”を述べてください。９割がそれ以外の内容です。
■
>（２）作業ミス
>
> これは、システム管理者の作業ミスといえる。それは、「大丈夫だろう」
>という油断や安易な思い込みがあったからだ。
ここでも”作業ミス”のみを述べてください。原因は不要です。イで書く内容です。
また、「作業ミスは何ですか？」と聞かれて、「作業ミス」では答えになっていません。
■
>以上のような４つがある。特に、今回は上述のことから、③と④について
>の対策が必須であると考えた。
「上述のことから」というのは何ですか？きちんと書きてください。
■
>２．２ 実施した対策
対策の中に、追加で問題点を書かれてます。これはダメです。２．１に書いて下さい。
実際の採点でも、ここまででBかCが確定します。
どれだけ内容が優れていても、聞かれたことに忠実に答えないと合格できません。
テストは明日なので時間がありませんが、「問われたことに忠実に答える」ことを守ってください。そうしないと、合格はありません。
内容に関しては、大きくマイナス点は無いと思います。書き方のマイナスですね。
[156] 管理者 (2008/04/19 Sat 08:22)
お忙しい中、コメントを頂き、ありがとうございます。
＞■アの文字数
＞４行オーバしていますね。この時点でアウトです
→”文字数”を勘違いしていました。
危なかったです・・。
ダメすぎて話にならないというほどではない、との
ことで、かなり自信になりました。
指摘されたポイントを頭に叩き込むだけでも、不合格に
なる要素を意識的に作り出さなくなると思いますので、
今日１日がんばりたいと思います。
ありがとうございました。
[157] aki (2008/04/19 Sat 10:47) mail
厳しいコメントで申し訳ありませんでした。
まだ大丈夫ですよ。
本試験２時間で完璧な論文を書ける人はほとんどいません。問題文に忠実に書けてさえいれば、合格ライン上にのります。
合格ライン上からは、また別のテクニックがあるのですが、その点は無視しましょう。（時間がないので）
私も添削できる自信はありませんが、可能であれば書き直した論文（別の論文では意味がありません。19-3で）を投稿してください。
なるべくコメントするようにさせてもらいます。確約ではないことだけご理解ください。
[158] 管理者 (2008/04/19 Sat 11:38)
返信ありがとうございます。
修正してみました。（修正作業約２時間・・遅いですね（汗）
途中で少し書き加えるだけで行数がばらばらになって、
しまうのですが鉛筆で書く場合には流れと組み立てに
時間をかけて修正する時間を減らすといった工夫が必要
なんでしょうか。
内容に関して、ギリギリのこの時間で大変申し訳ないのですが
評価頂けると幸いです。
よろしくお願いいたします。
-----------以下本文------------------
１．携わった情報システムの概要と作業ミスによる障害
１．１ 携わった情報システム
私はお客様先として、クレジットカードの取り扱いに
関する業務を行っているＴ社の情報システム課に常駐し
ているシステム管理エンジニアである。このシステムの
利用者はＴ社の社員約３００人、端末約３００台、サー
バー約２０台がネットワークに参加している。
そのサーバーのうち、ディレクトリサーバーは、社内
のすべての端末のログイン操作で必ず使用している為、
このサーバーがダウンするとＴ社の端末は全て使えなく
なることから、全ての業務がストップしてしまい、社会
的な信頼の損失に繋がってしまう。また、ディレクトリ
サーバーはファイルサーバーへのアクセスの為の認証も
提供しており、ディレクトリサーバーの認証を受けた利
用者だけが顧客データや社内情報が保存されているファ
イルサーバーにアクセスできるというシステムである。
１．２ 作業ミスによる障害と作業ミスについて
（１）作業ミスによって発生した障害
ＯＳの開発元からリリースされた更新プログラムの新
機能を使用する為、更新プログラムを用いて夜間にディ
レクトリサーバーを更新した。翌日から業務に問題が発
生しなかった為、作業に問題はなかったと考えていたが、
ディレクトリサーバーに作成した新規ユーザーをファイ
ルサーバーが認識しない問題が発生しており、既存の利
用者以外はファイルサーバーを使えないことから、Ｔ社
の新入社員はファイルサーバー上にある業務で使用する
ファイルを利用出来なくなってしまった。
（２）作業ミス
１つ１つの作業に誤りは無かったが、作業そのものに様
々な問題があったことから、作業の準備段階から全体と
して、システム管理者の作業ミスであったと考えている。
２．作業ミスの原因と実施した対策
２．１ 作業ミスの原因
障害を発生させる原因には、一般的に
①不注意
誤クリック、ケーブルの誤切断など
②知識不足
ＯＳ、ネットワーク、ハードウェアに関する専門知識
③思い込み
大丈夫だろう、問題ないはずだ、など
④慣れ
自宅・以前と同じ手順で大丈夫、など
以上のような４つがある。今回の作業では、作業自体は
マウスを数回クリックする単純作業であった事から、
（１）思い込み、慣れ
大きな問題は発生しないだろう、簡単だから大丈夫、
といった作業者の勝手な思い込みで作業を行った事。
（２）作業の妥当性の確認不足
事前に社内レビューをするなど、検討を行わず、作業
の妥当性を確認していなかったこと。
以上の２点が原因として考えられる。また、体制として、
（３）作業体制の問題
作業を行うシステム管理エンジニアは２名しかおらず、
夜間対応後の翌日などは残りの１名がカバーする体制と
なる為、作業は、立会いを行うお客様と、システム管理
エンジニア１名という体制になり、相互チェックが出来
ないこと。
私は以上の３点に原因があると考えた。
２．２ 実施した対策
２．１の（１）の原因に対して、以下の施策を実施した。
①チェックリストに基づいた作業の実施
作業のチェックリストを作成し、１つ１つ確認しなが
ら作業を行うこと。
②作業手順書へのチェックポイントの追加
設定変更の際には作業を中止してでも、元に戻さなけ
ればならないタイミングを設定しておく。
③重要な操作に対する確認メッセージ表示機能の追加
画面への表示によって管理者へ警告を行い、誤判断、
思い込みが少しでも起きないようにする。
（２）の対策については、２．３で述べる。
（３）の原因に対しては、事前に作成する作業チェック
リストを強化する対策を行った。その理由は、作業前で
あれば２名体制のリソースがフルに活かせると考えたか
らである。事前にテスト環境を用意した上で作業の検証
を行い、その結果を資料に反映させ、実際に画面を操作
しながら、チェックリストの項目と内容を全てチェック
する。その中で、管理者同士で声に出して読みあわせを
行うことで、同時に慣れによるミスも防ぐことが出来る。
２．３ 重要と考えた対策とその理由
私が最も重要と考えたのは、２．１の（２）への対策
として、お客様との連携が最重要であると考えた。以前
は、作業内容についてはシステム管理者任せとされてお
り、お客様に対して作業内容を説明することが無かった
のである。しかし、作業前に内容をご説明し、ご理解頂
けるかどうかで作業の可否・妥当性を検討することが出
来る。また、実作業に立ち会って頂くことから、一時的
にお客様の力を借り、簡単なメッセージを一緒に読み取
って頂くことで、不可能であった相互チェックも可能に
なると考えたからだ。
この結果、技術的に難しい作業であったとしても、お
客様との連携も合わせてスムーズに進むようになり、作
業効率が上昇した事、情報システム課社員と連携する事
で社内へのアナウンスが迅速に行えるようになった。
３．対策の評価と今後の課題
３．１ 対策の評価
私が行った対策はおおむね良好といえる。それは、今
までシステム管理者の考え方だけで行っていた作業に、
お客様の知恵をお借りできる為、多数の方面から問題を
解決しようとする風潮が生まれたからである。その障害
から３年経った今でもその風潮は根付いており、定期的
にサーバー関連の報告会を行い、作業前には必ず全ての
作業情報をシステム管理者側で話合ってから資料を作成
し、情報システム課内で検討するようになったことから、
特に夜間の構成変更における作業効率が概算で３０％以
上上昇したと見られる。更に、油断、思い込みによる作
業ミスは全く無くなった。
３．２ 今後の課題
お客様との連携による作業プロセスの改善は効果的で
あったが、プロセス改善中に確認の為の打ち合わせ等が
多くなり、作業前に行う確認時間が作業工数を増加させ
てしまっていた。
今後は、報告用のファイルのテンプレート化、ノウハ
ウのデータベース化などトータルで見て早期に課題を解
決できる仕組みを構築出することが必要と考えられる。
以上
[159] aki (2008/04/19 Sat 14:41) mail
明日は「問われたことに忠実に答える」これだけを意識してください。修正いただきましたが、この点が直っていません。これでは、100回受けても不合格です。
■１．２ 障害と作業ミスについて
①障害を具体的に述べてください。障害以外の内容が多すぎます。
②作業ミスの内容を30字で述べてください。
指摘させて頂いたことが修正されていませんね。
「作業ミスは何ですか？」と聞かれて、「作業ミス」では答えになっていません。
問題文のように、「誤操作や確認漏れ」といった具体的な作業ミスを書いてください。誤操作であれば、誤操作の経緯を詳しく書きます。
サンプル（私の論文）
障害を引き起こした作業ミスは、とても単純な誤操作であった。具体的には、奈良営業所のメインルータとバックアップルータに対して間違った設定を投入したため、修復作業をした際に必要な設定を削除してしまった。必要な設定が削除されていることに気がつかないまま設定を有効にしたため、ネットワーク停止の障害が発生した。
■
>２．１ 作業ミスの原因
>障害を発生させる原因には、一般的に
問題文をよく読んでください。アで述べた作業ミスの原因を書くのです。一般論は不要です。
一般論であっても、今回の原因であるかのようにうまく”表現”してください。
・・・・
くどいですが、「問われたことに忠実に答える」これにつきます。
[160] 管理者 (2008/04/19 Sat 15:15)
手厳しい返信ありがとうございます。
申し訳ありません。
＞①障害を具体的に述べてください。障害以外の内容が多すぎます
まず、長いという認識をしました。文字の配分を考えたいと思います。
（１）作業ミスによって発生した障害
新機能を利用する為、夜間にＯＳの開発元から手に入
れた更新プログラムでディレクトリサーバーを更新した
ところ、翌日からＴ社の新入社員全員がファイルサーバ
ー上にある業務で使用するファイルを利用出来なくなる
という障害が発生した。
このような表現ではどうでしょうか。
＞②作業ミスの内容を30字で述べてください。
作業前に技術文書の情報収集を行っておらず、確認に
漏れがあった。
このような表現ではどうでしょうか。後半で内容を修正
する必要があるかもしれませんが。
バグがあり、新規の利用者が使えなくなるという現象が
発生することは、とっくにＷＥＢに公開されていました
が、何も確認しないで行った、ということで「確認漏れ」
という表現にすればよかったんでしょうか。問題文を
よく読みます。
>２．１ 作業ミスの原因
>障害を発生させる原因には、一般的に
＞問題文をよく読んでください。アで述べた作業ミスの原
＞因を書くのです。一般論は不要です。
＞一般論であっても、今回の原因であるかのようにうまく
＞”表現”してください。
→了解しました。問題文を忠実に抜き出したら、それを
中身を加えて題材に当てはめれば良いということ宜しい
でしょうか。
＞くどいですが、「問われたことに忠実に答える」これ
＞につきます。
出題された問題を良く読むことにします。。
[161] aki (2008/04/19 Sat 16:05) mail
akiさん
こんかいはパーフェクトです。
素直に答えるだけでいいので、案外簡単でしょ。
難しく肝がんが得る必要はありません。とにかく問題文を引用して忠実に答えてください。
それができたら、以下のURLの３をよく読んでください。これで合格できます。
http://sm.xn--n9q36mh1hnxuksz7wt.net/archives/64669625.html
明日はがんばってください。
お願い。復元答案をその日に作って、お送りいただけませんか？今後の参考にさせてもらいます。
[162] 管理者 (2008/04/19 Sat 17:11)
ご返信ありがとうございます。
もう１度ご指摘頂いたポイントを確認しながらこの
論文を読み直し、出来ればあと１問ほど本番を想定して
書いて最後の対策としたいと思っています。
それこそ”確認漏れ”の無い様に頑張ります（笑）
復元答案は記憶の新しいうちに出来れば作って
お送りさせて頂きます。
本当にありがとうございました。
[163] aki (2008/04/19 Sat 17:31) mail
こんばんは
いよいよ明後日がが試験です。やばいです。
やばすぎます。
急な仕事でもあれば試験を受けずに済むのですが
[155] max (2008/04/18 Fri 20:40)
最後の投稿をさせていただきます。
今回も論文が冗長になってしましました。
対策案の検討及び決定プロセスを中心に
書こうとしましたが、結果は、実施事項の
列挙になってしまいました。
-------- 以下 2950字 --------------
１．情報システムの概要と機密情報について
１．１．私が携わった情報システム
私は、自動車部品製造会社の情報システム部門に所属
しており、システム管理エンジニアとして技術情報管理
システムの運用管理を担当している。
技術情報管理システムは、各種技術情報を格納するサ
ーバと設計者が技術情報にアクセスするパソコン１５０
台から構成されている。
当社の設計部門では、顧客である自動車メーカから新
型車の設計仕様書などの貸与を受け、部品の設計を実施
している。顧客からは、発表前の新型車の情報は極秘事
項であり、厳重な管理が要請されている。また、当社は、
複数の自動車メーカと取引をしている。そのため、顧客
より貸与された技術情報は、他の自動車メーカの情報と
は、完全に分離した状態で、管理を要請されている。
１．２．機密性の高い情報と漏洩時の影響
（１）機密性の高い情報の特定
私は、設計部門と共同で技術情報管理システムにおけ
る情報資産を洗い出し、機密性の高い情報を特定した。
その結果、以下の２点を機密情報として定義した。
・顧客より貸与を受けた全ての技術情報
・当社の製品及び部品図面
（２）機密漏洩時の影響
顧客から貸与を受けた情報が漏洩した場合には、顧客
からの信頼を喪失する。特に、発表前の新型車に関する
情報など重要機密として指示された情報が漏洩時には、
訴訟問題だけでなく、取引停止にもなりかねない。
また、当社の製品及び部品図面が、競合会社に漏洩し
た場合は、設計・製造ノウハウやコスト情報が流出し、
顧客での入札において、当社の優位性が失われてしまう。
２．機密漏洩のリスク明確化と防止策について
我々、システム管理エンジニアには、機密性の高い情
報に対して、システムの物理面、管理面及び技術面から
漏洩を防止するための対策と、漏洩した場合の損害を最
小限に食い止めるための対策が求められる。
２．１．機密漏洩リスクの明確化
私は、設計部門の協力を得て、技術情報管理システム
における機密情報漏洩のリスク分析を実施した。
当社では、情報セキュリティ委員会が設置され、各部
門の情報セキュリティ監査を実施している。 次に、技術
情報管理システムのシステム監査結果報告書を参考にし
て、設計部門にヒアリングし、機密漏洩リスクを以下の
ように明確化した。
（１）サーバ室や技術書庫への権限者以外の入室
（２）技術情報管理システムへの不正アクセス
（３）ＵＳＢメモリ等による社外への不正持ち出し
２．２．機密漏洩の防止対策
私は、リスク分析で明確化した機密漏洩リスク３項目
に対して、発生頻度、発生時の損失予想額、対策費用を
算出して、一覧表にまとめた。私は、設計部門とインフ
ラ管理部門の協力を得て、機密漏洩防止対策検討会を開
催し、物理面、管理面及び技術面からの対策を検討した。
私は、上記の検討会の結果を踏まえ、発生頻度、損失
予想額、対策費用に追加して、実施効果及び利便性との
関係を鑑み、以下の対策を実施した。
（１）物理面での対策
技術情報管理サーバが設置されているサーバ室と図面や
技術文書が保管されている書庫に、入退室管理システム
を設置した。当社では、社員証にＩＤカードを採用して
おり、サーバ室と書庫にＩＤカードと連動する電磁ロッ
クを設置した。入室許可を与えた社員のＩＤカードのみ
開錠可能とし、入退室記録も保管するようにした。
（２）管理面での対策
技術情報管理システムのアクセス管理を以下のように強
化した。①人事異動や退職などの人事イベントと連動し
ユーザ認証情報を適宜変更する仕組みに改訂した。具体
的には、人事情報システムの社員マスタとユーザ認証を
連携するように変更した。②顧客の要請事項である自社
データの独立管理は、サーバに顧客毎のディレクトリを
作成し対応した。顧客毎のディレクトリには、その顧客
を担当する設計者のみにアクセス権を与えた。
（３）技術面での対策
当初は、ＵＳＢメモリの使用を全面禁止の方針で、進め
たが、設計部門から拒否された。顧客へのプレゼンテー
ションや社内会議で、サーバからＵＳＢメモリへの情報
のコピーが必須だからである。代替案を調査の結果、暗
号機能付きＵＳＢメモリとＵＳＢ書込み制限ソフトの組
合せで、設計部門からの要件と漏洩防止対策を実現した。
暗号機能にて、社外持ち出し時の紛失等への対処が可能
ある。また、設計部門のパソコンには、ＵＳＢへの書込
み制限ソフトの導入を必須とした。但し、各設計課長の
パソコンからは、上記の暗号機能付きＵＳＢメモリのみ
に、書込みが可能な設定した。なお、このＵＳＢメモリ
は、各課長が厳重に管理するルールを設定した。
２．３.損害を最小限にする対策
機密漏洩の各種対策を実施しても、漏洩リスクを１０
０％排除することは不可能である。私は、漏洩時の損害
を最小限にするには、漏洩の事実を早期に発見すること
が重要と考えた。
技術情報管理サーバのアクセスログの定期確認方法を
改善した。月末に、サーバのアクセスログを設計者毎に
集計し、アクセス回数の降順に並び替えたリストを作成
した。このリストを、各設計課長に配布し、アクセスの
妥当性の確認を依頼した。アクセス集計ログには、アク
セス回数の集計だけでなく、ファイル数やアクセス時間
帯、設計者のパソコンへのダウンロード回数など、設計
者の異常行動が事前察知できるものとした。
３．対策の評価と今後の課題
３．１．対策の評価
私が実施した対策は、有効であったと評価している。
その評価のポイントを以下に述べる。
（１）顧客のセキュリティ監査で上位評価を得た
対策実施後に、複数の顧客からの定期セキュリティ監査
にて、前年度を大きく上回る評価を得た。
（２）設計部門のセキュリティ意識の向上
書庫への入室制限、アクセスログ分析、ＵＳＢメモリ書
込み制限の実施時に、設計部門への主旨と目的を十分に
説明したので、設計者のセキュリティ意識が大幅に向上
した。その結果、書庫やサーバから機密情報の持ち出し
時には、必要最小限の情報に限定された。
３．２．今後の課題
今回の対策で、設計部門からの機密漏洩については、
一定の対処ができたと考えている。しかしながら、設計
部門から機密情報が、業務上必要な営業部門や購買部門
に回覧されている。今後は、設計部門が管理する機密情
報が、設計部門以外の社内部門から、２次的に漏洩する
リスクに関しても、早急に対処が必要と考えている。
＜以上＞
[151] やまぽん (2008/04/10 Thu 06:27)
やまぽんさん、こんにちは
遅くなりました。
コメントさせてもらいます。
■評価
AA
■評価のコメント
・問題に即して忠実に書かれてあります。ブレがありません。
・具体的に書かれてあり、なおかつ内容が経験に基づいた納得性の高いものです。
・以下にマイナス点を書いてますが、それほど気にする必要はありません。十分な合格ラインです。
■「機密性の高い情報の特定」に関しては、アで書くべきかイで書くべきか悩むところですね。
アでは「機密性の高い情報の概要」と書かれてあるので、「特定」という言葉とそれに関する内容は、アでは触れないのが得策ですね。
■「関係部門と協力して」という点に関して、もう少し
踏み込めると良いですが、なかなか難しい箇所です。
■アにて、以下の情報を特定しましたよね。
・顧客より貸与を受けた全ての技術情報
・当社の製品及び部品図面
特定した情報にあった対策が書けるとベストです。やまぽんさんの論文では、特定した情報とその後の対策がリンクしていませんよね。これは難しいので、きちんと書ける人はほとんどいませんが。
■管理面での対策
①はどれだけ実効性があるのかが疑問です。
②は当たり前の対策ですが、従来はどうしていたのでしょうか？
■アクセスログの定期確認方法を改善した。
改善前がわからないので、どのような効果があるか、分かりません。
■今後の課題
「２次的に漏洩するリスクに関しても、早急に対処が必要と考えている。」
2次的な漏えいリスクであっても、そのリスクの評価を
きちんとするべきです。リスク評価の際に、2次的な漏えいをもらしていたと思われないような表現にしてください。
テストがんばってください。
可能であれば、復元答案を作成してお送り願います。
[152] 管理者 (2008/04/13 Sun 15:20)
やまぽんです。
ご多忙中、コメントありがとうございます。
ぎりぎりですが、論文のコツが判りかけてきました。
本番試験で、大きく外さないように、かんばります。
[153] やまぽん (2008/04/14 Mon 11:11)
ハチです。いつもお世話になっております。
試験まで残り２０日となりました。
いまだに不安がいっぱいですが、
今回の試験勉強を通して、少しでも自分の中に残るものがあれば良い。と思っています。
お時間のあるときに、またよろしくお願いします。
Ｈ１８問３
分散配置されたシステムの運用管理について
１．分散システムの運用管理体制と問題点
１－１．情報システムの概要と運用管理体制
私は全国に２０の拠点と東京に本社を持つクレジットカード会社に勤務するシステム管理エンジニアである。私は東京本社の情報システム部に所属している。
私が携わった情報システムは顧客管理システムである。各拠点に寄せられるクレジットカード利用者からの問い合わせに答える為、登録内容や利用状況を参照するシステムである。データベースサーバは東京本社に設置されており、各拠点にアプリケーションサーバが設置されている。各拠点ごとに約３０台のクライアントがあり、拠点のアプリケーションサーバ経由で顧客情報を参照する３層構成となっている。
各拠点のアプリケーションサーバの運用管理は、拠点毎の社員が兼任しており、人事異動などで頻繁にシステム担当者は交替する。
１－２．拠点での運用管理の問題点
各拠点のシステム担当者は社員が兼任していることもあり、システム管理についての知識が不足していることがあった。また、システム管理の教育を行うにしても十分な時間を割くことができていない。この為、システムの障害に対して、適切な措置や迅速な対応が行えないなどの問題が発生していた。
仮にシステム担当者としての教育を施したとしても、人事異動により担当者が交替してしまうと新しい担当者へ教育を行う必要が出てきてしまい、属人的な運用となっていた。システム担当者が使用するマニュアルについては、本社の情報システム部員と同じマニュアルを使用していた。このマニュアルを使用するには、ある程度のコンピュータに対するスキルが必要だった。
２．問題解決の施策と実施のための支援
２－１．問題解決策の立案
各拠点でのこのような問題に対処するため、システム管理エンジニアは、運用管理面での施策を立案し、システム担当者を指導・支援する必要がある。
主な施策として下記の策が挙げられる。
（１）システム担当者の役割の明確化や体制の見直し
（２）障害発生時の対応方法などを記載したマニュアルの整備
（３）システム操作やユーザ支援などのための研修や訓練の実施
私は、どのような施策を実施するべきか考察を重ね、まずは「（２）障害発生時の対処方法などを記載したマニュアルの整備」を実施することとした。今回の問題点はシステム担当者が頻繁に交替するにも関わらず、属人的な運用となっていることが問題である。交替の都度、教育を行うにしても、現状のマニュアルでは短期間の教育を行うのは難しいと判断した。まずは、マニュアルを整備しマニュアルを見るだけで最低限の作業を行えるようにする。その後、教育プランを策定して運用管理の品質を向上させる施策とすることにした。
２－２．問題解決策の実施に当たっての支援
運用マニュアルの整備は全拠点で使用するマニュアルとなる為、情報システム部の担当者である、私が再編に当たることになった。
私はマニュアルの整備にあたり、現状の分析を開始した。具体的には、実際にシステム担当者として勤務している社員へヒアリングを行った。ヒアリングの実施にあたっては、運用管理の重要性を理解しているか？マニュアルの記述は理解できる技術レベルで書かれているか？という内容を重点項目とした。
再編されたマニュアルを本運用とする前に、東京近郊の２拠点（横浜・千葉）を選びパイロット移行を行った。このパイロット移行により、再編されたマニュアルでシステム担当者の業務が行えることを確認することが狙いだった。
２－３．施策の実施にあたり工夫した点
私が今回の施策の実施にあたり工夫した点は、マニュアルの記述をスキルの無い人間でもわかりやすい記述にしたことである。
具体的な例をシステムを停止する手順で示す。
元々のマニュアルでは「シャットダウンを選択しシステムを停止する」となっていた。これだけの記述では、シャットダウンはどこから選択するのか？どうなれば停止されたのか？など、一定レベル以上のスキルがなければ判断することができなかった。この記述を３項目に分割した。
（１）○○メニューよりシャットダウンを選択する。
（２）停止の確認画面が表示される為、はいを選択する。
（３）本体前面の電源ランプが消灯していることを確認する。
項目を分ける際に各項目に画面エビデンスを挿入し、マニュアル上の確認箇所にマーキングを行った。
マニュアルの記述レベルをスキルの無い人間に合わせることで、教育の度合いによって運用管理の品質のバラツキを押さえることができた。
３．マニュアル再編に対する評価と今後の課題
３－１．マニュアル再編に対する評価
私が行ったマニュアル再編に対して、社内より高い評価を得た。評価のポイントが下記となる。
・各拠点のシステム障害時に混乱なく対応できたこと
マニュアル再編後のシステム障害において、拠点のアプリケーションサーバのコールドスタートが必要となったが、混乱することなく正規の手順で行うことができた。このことのより復旧にかかる時間が長時間となることを防ぐことができた。
３－２．今後の課題
今回の施策を行ったこと運用管理の属人化を低減することができた。しかし、確実な作業を行う為には定期的な対応訓練を行うことが重要だと考えている。運用改善のための継続的な取り組みが今後の課題である。
以上
[142] ハチ (2008/03/31 Mon 15:34)
■１．１
DBサーバは本社、アプリケーションサーバは拠点というのは一般的ですか？
そうであればこれで問題ありません。
単純に「分散型のシステム」としてもいいかもしれませんね。
■１．２
問題点を書いてください。
問題点というよりは、事実を述べている感じですね。
「適切な措置や迅速な対応が行えないなどの問題」
これによる、会社への損害などまでつなげた方がいいですね。なぜなら、問題点として
①困っているけど、なんとかやりくりしている
②問題発生により、顧客からのクレーム、売上減
この2つでは、対策のレベルが違います。
①であれば、がんばれよ。
②であれば、専門スタッフを入れるべきなどの、抜本的
な対策につながります。
■２．１
（２）が適切である理由は、分かりました。
では、（１）と（３）の対策を選ばなかった理由は？
そこまで踏み込めると説得力が増します。
■２．３工夫した点
「マニュアルの記述をスキルの無い人間でもわかりやすい記述にした」
工夫した点が、ありきたりですね。
具体的なマニュアルの内容を記載するより、「工夫の内容」について詳しく書いて下さい。
例えば、
①実際に作業する人のレベルに合わせたマニュアルにした。
②作成したマニュアルが適切かどうかを評価するため、
実際の作業員に実施してもらった。
③緊急時にマニュアルを全て読むことは困難である。
FAQを整備し、よくある注意点をわかりやすく整備した。
・・・
思いつきなので、ハチさんの論文に合わせて修正してください。
■全体として
１．２にからんで、SLAが欲しいです。
「SLAからどれだけかけ離れているから、○○の対策をした。その結果、SLAが守れた。」
この記述がないと、ハチさんの対策の有効性が評価できません。
■総合評価
A
厳しいコメントばかり書きましたが、本試験2時間では、このレベルの論文がかければ合格だと判断します。ただ、BとAの境目です。
私がコメントさせていただいた点を参考に、さらに良い論文を期待してます。
※時間の関係で、今後はレスできる保証がありません。その点をご了承ください。
[149] 管理者 (2008/04/08 Tue 11:56)
ハチです。
お忙しいところ、ありがとうございました。
「合格ボーターライン」ということですね。
他の方の論文も拝見していて感じたのは、
私の論文には「ビジネス視点」が欠けているようです。
本番までに調整していきたいと思います。
合否の結果を含めて、また書き込みさせて頂きます。
お時間を頂きありがとうございました。
[150] ハチ (2008/04/09 Wed 08:34)
ご無沙汰しております。すぎエモンです。
そろそろ、本番試験も近づいて来ました。
論文の完成度がどれだけ高くなっているかは自分では不明ですが、
何度も書いて投稿する事で、レベルアップが出来ている事を祈ります。
～～～～～～～～～～～～～～～～～～～～～～～
Ｈ１７＿ＰＭ２＿Ｑ３
１．情報システムの概要と機密性の高い情報について
１．１私が携わった情報システムの概要
Ｉ社は、ソフトウェアの開発を行う企業である。Ｉ社は、開発のために一人１台のパソコンを導入している。
これらのパソコンは、サーバ室に設置された開発用サーバ１１台と、ＬＡＮで接続され、社内システムを構成している。ＬＡＮについては、有線ＬＡＮと無線ＬＡＮを併用している。
私は、Ｉ社のシステム管理エンジニアとして、社内システムの運用管理を担当している。
１．２機密性が高い情報の概要
私が、社内システムで取り扱う情報の中で、機密性が高いと考えている情報は以下の通りである。
・開発用サーバに蓄積された個人情報
開発用サーバには、顧客から借り受けているテスト用のデータベースが存在する。このテストデータは全て架空のものであるという前提があるが、実際には実在する人物のデータが混入している可能性があると考えた。
・開発用サーバに蓄積されたプロジェクト管理情報
プロジェクト管理におけるデータには、損益情報や見積もりの計算式などが含まれており、機密性の高い情報と判断した。
１．３その情報が漏えいした場合の影響
テストデータベースの中に実在する人物の個人情報が
含まれていた場合は、この情報が外部に流出した時点で、個人情報の流出となり、個人情報保護法に違反する事になる。また、プロジェクト管理情報が、ライバル会社等に漏えいした場合は、Ｉ社の企業ノウハウが流出することになり、会社として大きな損失になると考える。
２．漏えいリスクの明確化と対策
２．１関係部門と協力して明確にした漏えいリスク
情報漏えいに関する対策を検討する際には、関係部門とともに、機密性の高い情報を特定し、その漏えいリスクと明確にする必要がある。
私は、開発部門と協力し、「情報漏えい対策委員会」を結成した。この中での話し合いで、以下の項目が、漏えいリスクとして洗い出された。
・サーバ室からの情報漏えいリスク
・社内パソコンからの情報漏えいリスク
・無線ＬＡＮからの情報漏えいリスク
２．２漏えいを防止するための対策
私は、洗い出されたリスクの対策は、物理面と管理面、技術面の３つの方面からアプローチすることにした。これにより、多方面から機密性を強化し、システムの弱点になる「抜け穴」の部分を少なくする事が狙いである。具体的な対策の内容は以下の通りである。
①物理面での対策
・サーバ室の入退室者の厳格な本人確認
従来サーバ室は、５桁の数字コード入力による入退室管理を行っていた。しかし、私はこれでは入退室コードを教え合う事で誰でも入室でき、セキュリティ上のぜい弱性になると考えた。よって、指紋認証装置を導入して、バイオメトリクス認証による入退室管理に変更する事で、厳格な本人確認を行う事にした。
②管理面での対策
・アクセス権限の適切な更新
現在、サーバ上にある機密性の高い情報資源は、アクセス権を設定し、権限の無いユーザからは使用できない建前になっている。しかし、私はアクセス権限の設定状況を詳細に調査し、退職した旧システム管理者や、サーバ導入時のテスト用管理者権限ユーザなどのユーザアカウントが削除されないまま残留している事を発見した。
これらのユーザは、不正利用されることで、システムに対するぜい弱性になると考え、不要なユーザを削除する事にした。さらに、現在のユーザとアクセス権の関係も再度チェックして、矛盾のある設定が無いようにした。 さらに、ユーザとアクセス権は、時間と共に変化するものであるから、ユーザの変更があるたびに定期的に定義を見直すことにした。ユーザの変更情報については、人事課に協力を仰ぎ、人事異動の情報を提供してもらう事にした。さらに、ユーザの変更設定を人事課のメンバとシステム管理者が協力して行う事で、システム管理者自身が情報漏えいを行いにくいように工夫した。
③技術面での対策
・無線ＬＡＮのセキュリティ強化
現在無線ＬＡＮに対するセキュリティは、ＷＥＰによる暗号化を行っているが、私はこれだけではセキュリティ上の対策としては弱いと考えた。なぜなら、ＷＥＰの暗号化はクラックツールの使用で数時間内にＷＥＰキーを解読する事が可能になっているからである。
よって、無線ＬＡＮの暗号化にはＷＰＡを新規に導入して、暗号化強度を向上させる事にした。また、ＲＡＤＩＵＳサーバを導入し、ＩＥＥＥ８０２．１ｘを使用する事で、無線ＬＡＮを使用するパソコンの厳密な認証も行う事にした。ここで、ＩＥＥＥ８０２．１ｘの暗号化キー再配布機能を利用して、各パソコンへの暗号化キー更新作業を省力化するという工夫も行った。
２．３漏えいした場合の損害を最小限にする対策
情報が漏えいした場合の被害を最小限に食い止めるには、漏えいの事実を早期に把握して迅速に対応する事が重要であると考えた。このために、以下の対策を行う事にした。
①情報システムへのアクセスログの継続的な取得
②１ヶ月に１度のアクセスログ評価の実施
③情報漏えい事故発生時に、関係部門と連携した対応を行うための全社的な連絡体制表と対応マニュアルの作成
私は、連絡体制表を対応マニュアルの有効性を確認するために、情報漏えいが発生した場合を仮定した対応訓練を行うことにした。これは、実施の事故発生時には各関係者が自分の役割を認識し、スムーズに対応作業を行う事ができる様にする為の工夫である。
私は、これらの対策を行うことで、情報漏えいに対抗する事にした。
３．評価と今後の課題
３．１評価
私が今回行った対策を行って以降、情報漏えいの事故は発生していない。よって、最低限の要求事項は達成できていると評価している。
また、これらの対策を行った結果に対する、Ｉ社経営陣の評価は非常に高く、特に無線ＬＡＮの対策が評価されたようである。よって私の行った対策が「情報漏えい対策モデル」として、Ｉ社の子会社にも採用される事になった。私はこの点も評価できると考えている。
３．２今後の課題
今後は、今回行った対策も踏まえた上で、更なるセキュリティの強化を行い、最終的にはＩ社としてＰマークの認証を取得する事を検討している。
以上
[121] すぎエモン (2008/03/18 Tue 08:37)
■総合評価
B
■コメント
書かれている内容が多すぎます。これでは、いつまでたってもAにはなりません。
まずは、書く情報を少なくしてください。そのうえで、ひとつ一つ理由をつけてください。理由を付ける場合、「その他の選択肢も検討したが、採用した案が最善である」ということを丁寧に書いてください。
そうすれば、書く内容を減らしても字数は軽く2400をオーバします。
勝手ですが、すぎエモンさんの論文の情報を少なくしました。これをベースに、理由をつけて論文を仕上げてください。
■情報を少なくした論文
１．情報システムの概要と機密性の高い情報について
１．１私が携わった情報システムの概要
Ｉ社は、ソフトウェアの開発を行う企業である。
これらのパソコンは、サーバ室に設置された開発用サーバ１１台
私は、Ｉ社のシステム管理エンジニアとして、社内システムの運用管理を担当している。
１．２機密性が高い情報の概要
私が、社内システムで取り扱う情報の中で、機密性が高いと考えている情報は以下の通りである。
・開発用サーバに蓄積された個人情報
開発用サーバには、顧客から借り受けているテスト用のデータベースが存在する。このテストデータは全て架空のものであるという前提があるが、実際には実在する人物のデータが混入している可能性があると考えた。
１．３その情報が漏えいした場合の影響
テストデータベースの中に実在する人物の個人情報が
含まれていた場合は、この情報が外部に流出した時点で、個人情報の流出となり、個人情報保護法に違反する事になる。また、プロジェクト管理情報が、ライバル会社等に漏えいした場合は、Ｉ社の企業ノウハウが流出することになり、会社として大きな損失になると考える。
２．漏えいリスクの明確化と対策
２．１関係部門と協力して明確にした漏えいリスク
情報漏えいに関する対策を検討する際には、関係部門とともに、機密性の高い情報を特定し、その漏えいリスクと明確にする必要がある。
私は、開発部門と協力し、「情報漏えい対策委員会」を結成した。この中での話し合いで、以下の項目が、漏えいリスクとして洗い出された。
・サーバ室からの情報漏えいリスク
２．２漏えいを防止するための対策
②管理面での対策
・アクセス権限の適切な更新
現在、サーバ上にある機密性の高い情報資源は、アクセス権を設定し、権限の無いユーザからは使用できない建前になっている。しかし、私はアクセス権限の設定状況を詳細に調査し、退職した旧システム管理者や、サーバ導入時のテスト用管理者権限ユーザなどのユーザアカウントが削除されないまま残留している事を発見した。
これらのユーザは、不正利用されることで、システムに対するぜい弱性になると考え、不要なユーザを削除する事にした。さらに、現在のユーザとアクセス権の関係も再度チェックして、矛盾のある設定が無いようにした。 さらに、ユーザとアクセス権は、時間と共に変化するものであるから、ユーザの変更があるたびに定期的に定義を見直すことにした。ユーザの変更情報については、人事課に協力を仰ぎ、人事異動の情報を提供してもらう事にした。さらに、ユーザの変更設定を人事課のメンバとシステム管理者が協力して行う事で、システム管理者自身が情報漏えいを行いにくいように工夫した。
２．３漏えいした場合の損害を最小限にする対策
情報が漏えいした場合の被害を最小限に食い止めるには、漏えいの事実を早期に把握して迅速に対応する事が重要であると考えた。このために、以下の対策を行う事にした。
情報漏えい事故発生時に、関係部門と連携した対応を行うための全社的な連絡体制
私は、連絡体制表を対応マニュアルの有効性を確認するために、情報漏えいが発生した場合を仮定した対応訓練を行うことにした。これは、実施の事故発生時には各関係者が自分の役割を認識し、スムーズに対応作業を行う事ができる様にする為の工夫である。
私は、これらの対策を行うことで、情報漏えいに対抗する事にした。
[125] 管理者 (2008/03/19 Wed 21:23)
ご査読ありがとうございます。
いつも低レベルの論文でスミマセン。
指摘に従い、記述ポイントを絞り込んで、書き直してみます。まずは、お礼を兼ねて書き込み致します。
[128] すぎエモン (2008/03/21 Fri 15:16)
すぎエモンさん
いつもご丁寧な対応ありがとうございます。
厳しいコメントばかりですいません。私も心を鬼にしてコメントしてます。ご理解いただけると幸いです。
>理由を付ける場合、「その他の選択肢も検討したが、採用した案が最善である」ということを丁寧に書いてください。
私がこのように書かせていただいたのは、すぎエモンさんの書かれている案の妥当性に、疑問を感じているからです。
すぎエモンさんはベストな案を述べてもらっているつもりだと思いますが、実はそうではありません。おそらくご本人は気付いておられません。
それに気付くには、考えられるすべての案を列挙することです。そして、すべての案について、論理的に比較をするのです。その結果として導かれた案は、納得性の高いものになります。
すぎエモンさんには、このプロセスをじっくりやってほしいのです。案外簡単です。この思考プロセスは仕事でとても役に立ちます。また、論文試験は次々と合格します。
例をあげてみます。
>１．２機密性が高い情報の概要
機密情報は、「開発用サーバに蓄積された個人情報」と
「開発用サーバに蓄積されたプロジェクト管理情報」だけですか？なぜこの２つを選んだのですか？
機密情報を列挙すると
①開発用サーバに蓄積された個人情報
②開発用サーバ以外に蓄積された個人情報（たとえば、顧客管理システム、名刺、社員の個人情報、取引先の情報
③開発用サーバに蓄積されたプロジェクト管理情報
④電子メールの情報
⑤ファイルサーバにある社内のノウハウ
・・・・
たくさんありますよね。この中で、どれが重要なのかを論理的に判断する必要があります。
①の重要度は低いのではないでしょうか？テスト用のデータであれば、入手する段階で個人情報を消せばすみますよね。
③のプロジェクト管理情報が何を意味するか分かりませんが、管理情報って他社は欲しがりますか？私はいりません。
ソフトウェア会社であれば、⑤のノウハウの優先度が高いと思いますよ。また、②の取引先の情報は漏えいするとまずいですよね。
⑤のノウハウでストーリを作るとすると、
①②の個人情報は基本的に保有ししていない。大手の通販会社のように大量の個人情報を有する企業とは違い、保有する個人情報が少ないため、万が一の際にも被害が少ない。
③～⑤ ソフト開発のノウハウは企業秘密である。プロジェクト管理情報、見積もり情報、電子メールなどたくさんのノウハウがあるが、中でもファイルサーバに蓄積されたソフトのライブラリ（部品）が最も重要である。我々は高度なライブラリをたくさん保有しており、これにより、他社より高品質で短納期のソフト開発を実現している。
こんな感じです。どれが重要かは企業特性によります。
※私を含め、市販されているサンプル論文において、すべてがこのように複数案の比較を記述しているわけではありません。やりすぎるとくどくなるからです。ですが、複数案を比較した結果、最善の案を採用するというプロセスは実施されています。プロセスの過程を省略しているだけです。
長くなりましたが、メゲずに投稿をお願いします。
大丈夫です。まだ、1か月あります。
[130] 管理者 (2008/03/21 Fri 20:40)
詳細にわたるご指摘ありがとうございます。
本来であれば、上記の「■情報を少なくした論文」に従い
記述するべきなのかもしれませんが、対策案の的はずれな選定など
根源的な問題がありますので、一から書き直しました。
また、何度も論文を書き直してみましたが、
今だに根本的に何かが不足しているようです。
今後は、論文の基礎を一からやり直していこうと思っています。
-------------------------------------------------
１．情報システムの概要と機密性が高い情報について
１．１私が携わった情報システムの概要
工務店Ｍは、住宅の設計・施工を行う会社である。工務店Ｍでは、施主からの依頼に応じて建物の設計を行う際に、ＣＡＤを利用したの設計システムを使用する。
設計システムは、３０台のパソコンと４台のサーバから構成されており、それぞれの機器は、ネットワークを介して相互接続されている。また、工務店Ｍのネットワークは、以下の用途のために、インターネットにも接続している。
・外部の関連企業とメールをやり取りする用途
・必要なＷｅｂサイトを閲覧する用途
私は、システム管理エンジニアとして、工務店Ｍの設計システムの管理を担当している。
１．２機密性が高い情報
工務店Ｍで扱っている情報の中で、機密性が高い情報は以下の通りである。
①顧客の個人情報が記載された顧客データ
②ＣＡＤシステムにて作成した設計図
③自社の社員データ（個人情報を含む）
④名刺や契約書などの物理的な顧客情報
⑤伝票や請求書などの会計情報
１．３情報が漏えいした場合の影響
機密性の高い情報は、個人情報や、会社の機密情報を多く含む。よって、このような情報が社外に漏えいした場合、個人情報漏えいによる法律違反や、内部情報流出による会社の信用失墜が起こる。
私は、機密性の高い情報の漏えいにより、企業の存続にも関わる大きな問題になる可能性があると考えた。
よって、漏えいに関わるリスクを明確化するとともに、その対策案を検討する事にした。
２．漏えいリスクの明確化と対策
私は機密性の高い情報に対して、まず関係部門と共に漏えいリスクを明確する事にした。その後、システムの物理面、管理面及び技術面から漏えいを防止するための対策を検討する事にする。更に漏えいした場合の損害を最小限に食い止めるための対策検討も必要になると考えた。
２．１協力した関係部門
私が、漏えいリスクを明確化するに当たって、協力を仰いだ関係部門は、設計部門と総務部門である。これらは、業務における「実務部隊」と「管理部隊」に相当する。これらの関係部門と協力して、さまざまな視点からしっかりとしたリスクの洗い出しを行う事にした。
２．２漏えいリスク明確化の方法
漏えいリスクの明確化については、まず、各関係部門に考えられる漏えいリスクを箇条書きにしてもらう事から始めた。その後、全社レベルでの「漏えいリスク検討会議」を開催し、それぞれ持ち合ったリスクを整理統合するという手法で明確化した。私はこの会議で出た案を系統図に纏めて、体系的にリスクを整理するという工夫を行った。
２．３明確化した漏えいリスク
関係部門と共に明確にした漏えいリスクは以下の通りである。
①電子データが、社内パソコンから漏えいするリスク
②インターネット経由でデータ漏えいするリスク
③紙などの物理媒体が持ち出されるリスク
２．４漏えいを防止するための対策
漏えいを防止させるための対策案として、物理面からは、社内立ち入り者の厳格な認証や、外部媒体の持ち込み・持ち出しなどを検討した。管理面か