情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

がんばる人を応援する

 本格的な勉強というのにはほど遠い状況である。ここ1週間、監査の対策本をまったく開いていない。ブログ開設1周年企画としてアップしたSM合格時の再現論文、そういう方向に気持ちがいってしまい、私自身のモチベーション維持や向上というよりも、読者の役に立つ情報の提供がメインになっている感じがする。それならそれでいいのだが・・。ブログを訪れる人はそれぞれに目標があるはず。努力すればきっと目標は達成できる、そう私は信じているので、がんばる人を陰ながら応援していきたいと思っている。テクニカルエンジニア(システム管理)に初めて挑戦する人も前回のリベンジを狙っている人も、その他の試験を受ける人も、みんな頑張ろう! まるで「青年の主張」みたいになってしまったが、少し気合いを乗せないとこのままズルズルいってしまいそうだから。というわけで、今後は春試験に向けて、システム監査やシステム管理をはじめ、いろいろな試験区分に適用できる情報やノウハウを紹介していく。
 システム監査の勉強については、2月頃から少しずつ午後1対策にとりかかる予定。それと、下記のサイトが参考になったので紹介しておく。特にAUを初めて受ける人は読んでおいたほうがいいだろう。
 基礎から分かるシステム監査入門

スポンサーサイト

SM合格時の再現論文

平成17年度 春期 テクニカルエンジニア(システム管理)

【午後2 問題文】

問1 システム障害の再発防止策について

 今日では、情報システムの障害発生が、企業や官公庁の基幹業務に多大な影響を与える可能性が高くなっている。このような状況を踏まえて、障害発生時には、まず障害からの迅速な復旧を図る。その後、発生した障害の根本原因を究明し、再発防止策を検討して実施することが重要である。
 システム管理エンジニアとしては、運用上の仕組み、運用手順、関係者間の情報伝達方法など、システム運用面からの再発防止策を講じる必要がある。例えば、システムを確実に運用するために、運用手順の作成時に、同様なシステム運用の経験をもつエンジニアに参加してもらいレビューを行うことや、作業結果を確実に確認するために、目視確認からツールによる自動確認に変更することなどが考えられる。
 システム運用面からの再発防止策は、次の手順に従って関係者と協議し、実施が決定される。
 (1) 障害発生時に特定された直接的な原因の背景にある根本原因を究明する。
 (2) 根本原因を取り除くための対策案を、システム運用面から幾つか列挙する。
 (3) 列挙された対策案に対し、費用対効果、体制面などから採否を決定する。
 あなたの経験に基づいて、設問ア~ウに従って論述せよ。

設問ア
 あなたが携わった情報システムの概要と、発生したシステム障害の概要及び業務への影響について、800字以内で述べよ。
設問イ 
 設問アで述べた障害に対し、究明された障害発生の根本原因は何か。また、その根本原因を取り除くために検討した、システム運用面からの再発防止策は何か。さらに、それらの採否をどのように決定したか。工夫した点を中心に、具体的に述べよ。
設問ウ
 設問イで述べた再発防止策について、どのように評価しているか。今後の課題は何か。それぞれ簡潔に述べよ。


【再現論文 Pman wrote】

1.システム概要及び発生した障害
1-1.私が携わった情報システムの概要
 首都圏を中心に約200支店を有する金融機関(以下、ユーザと呼ぶ)は、個人向け住宅ローンを主力商品の1つとしている。ユーザ業務は、6年前に稼働開始した住宅ローン情報管理システムにより運営されている。当システムの開発・運用は、情報処理サービス会社J社がアウトソーシングの形で受託しており、J社に勤務する私はシステム管理者として保守・運用に携わってきた。
 当システムは、J社に設置される汎用コンピュータ上のデータベース(以下、DBと呼ぶ)に対し、公衆回線を経由して、各支店の専用端末からアクセスする集中処理方式である。運用時間は、平日9時から17時までをオンライン時間帯、同17時から20時頃までをバッチ処理時間帯としている。
1-2.発生したシステム障害
 稼働開始から2年程たった頃、オンライン時間中にあるユーザ支店の端末で、システムの異常終了が発生した。私はまず、障害事象を正確に把握するため、ユーザ窓口の担当者に状況を確認したところ、経理業務中にある顧客データのDB更新処理で、突然エラーメッセージが表示され更新不可になったという事象であった。次にJ社内部でダンプリスト取得により障害の原因を調査したところ、該当データのDB不整合のためアプリケーションエラーでアベンドしていたことが判明した。
1-3.ユーザ業務への影響
 経理業務は、月単位で締め処理を行う期間が決まっている。この処理は、ローン残高の集計など企業経営に関わる重要な事務処理であるため、システム障害による業務の停止は避けなければならない。私は、早急に障害対策を講じる必要があると考えた。

2.システム障害の再発防止策について(設問イ)
2-1.障害発生の根本原因
 障害発生の当日、ほかに13支店で同じように異常終了が発生した。このことから、特定の顧客データに何らかの異常が起きたのではないかと私は推測した。調査の結果、前日の夜間におけるDBパッチ作業のミスが判明した。DBパッチとは、ユーザからの依頼により、J社において特定のデータを強制的に塗り変える例外作業で、ユーティリティを用いた手作業である。ところが、本来パッチを当てるべきデータとは異なるデータに対し誤ってパッチを当てたため、DB不整合が発生したものであった。こうした作業ミスを引き起こすような運用方法に、障害の根本原因が潜んでいたと私は認識した。
2-2.システム運用面からの対策案
 以上の根本原因を取り除くための対策案を列挙する。
案(1) 作業要員の増強
 DBパッチ作業を実施するのは週1~2日、夜間バッチ処理後の2時間程度であったため、当初、作業担当者は1名で十分と考えていた。しかし、今回のシステム障害は、担当者のケアレスミスを防止または発見できなかったことに原因がある。また、顧客データを更新するという重要な作業を一人で行うことは、J社にとってリスクが高いと考えられる。そこで私は、作業要員を2名に増強し、パッチ作業時にダブルチェックを行い、ミスがないかどうかの検証を強化することを考案した。
案(2) 運用手順書の見直し
 運用記録の証跡書類を見ると、通常の運用作業における手順はほぼ確立されていたが、DBパッチ作業等の例外運用については確立されていなかった。例外運用の手順書は、ユーティリティの操作方法や障害発生時の対処方法が中心であり、J社の責任範囲や作業の承認ルールが不明確であった。今回のシステム障害は、パッチ作業における承認者及び確認者が曖昧であるなど、手続上の不備があったことに起因する。このため私は、運用手順書を全面的に見直し、改版することを考案した。
案(3) 検証ツールの導入
 パッチ対象のデータ件数が大きいほど、今回のような障害発生による影響も大きくなる。そこで、今までは作業結果をDBダンプリストの取得による目視確認としていたが、検証ツールによる自動確認に変更することを考案した。ツールは表計算ソフトのマクロ機能を利用したものであり、確認作業の省力化が期待できる。
2-3.対策案の採否の決定方法
 まず案(1)については、ダブルチェックの効果がある反面、作業時間が深夜に及ぶこともあるため、要員の工数確保が難しかった。体制面を変更するにはユーザからの承認が必要であったが、私の提案に対し、ユーザ側は「1名で十分」との見解を示した。確かに、発生確率の低い障害に対して体制面を強化するのは非効率である。このため私は案(1)を不採用とした。案(2)については、J社の各関係者に対しヒアリングを行ったところ、安定運用のために手順書は整備すべきとの意見が多かった。加えて、DBパッチ作業は一時的なものでなく、今後も継続する見通しであることを勘案し、私は、運用手順書を改版することに決定した(採用した)。案(3)については、ツールの開発工数・費用が膨らむことを懸念したが、必要性の高いチェック機能に絞り込むことで費用を抑えられる。さらに、ツールの入力となるチェック用データをユーザ側で作成して頂けるなど協力体制が得られたことから、私は案(3)を採用した。

3.評価及び課題(設問ウ)
3-1.評価
 運用手順書の見直しにより、DBパッチ作業時の承認~実施~検証の流れが明確になり、例外運用でありながら実際には定型的な業務として標準化することができた。また、検証ツールの導入により、パッチ作業時間が従来より30%短縮するなど、省力化及び効率化を図ることができた。これらの対策により、障害の再発防止ができていることから、私の実施した活動は全体的に効果があったと評価する。
3-2.今後の課題
 システム障害の再発防止策を検討して実施した結果、運用手順に関しては、改善すべき点が残っていると感じた。なぜなら、手順書の一部の項目については、運用環境の変化により形骸化したり、実態とかけ離れている部分もあったからである。したがって、今後も継続的に運用手順の有効性や妥当性を確認していく必要があろう。

以上

初AU受験申し込み完了

 早くも申し込んでしまった、システム監査技術者。
 思えばここ数年、いつも申し込む試験区分は決まっていた。だから今までは、また同じか・・というマンネリ感さえあったのだが、今回やっと、その感覚から抜け出すことが出来たんだーと実感した。と同時に「春の最高峰」へようやくたどり着いたのだ、という思いを抱いた。
 そんな希望とは裏腹に、勉強のほうは、あまり進んでいるという感じではない。前回は1月6日に下記の対策本でやることを宣言していた。
書籍名:情報処理教科書 システム監査技術者 2006年度版
出版社:翔泳社


 今は、各章の基礎解説と午前問題だけを先に、非常にスローペースでやってるという感じである。午後対策は後回し。とりあえず、関連法規を除いた基礎解説のところは一通り読んだ。しかし、理解できたかと言えば、じつはよくわからない。監査とはそもそも何なのか?というのは感覚的にわかったが、実務経験が無いせいか、各論になるとどうもピンとこない。まあでも初めて足を踏み入れる世界なのだから、少しずつ理解を深めていけばいいと思っている。
 この一冊で終わらせるかどうかは未定。

資格取得のための効率的な勉強法

 効率的な勉強法は、ない
 なんて言ってしまうと、ここで話しは終わってしまう。でも私は、本当に無いと思っている。短い期間で要領よくやろうとしても限界があるし、どんな試験でも、必ずある一定以上の勉強量を消化しないと、良い結果は出ないと考えている。合格への道は、近道でも花道でも王道でもなく、地道な努力を続けることだと信じている。
 しかし、実際には多くの人が「仕事が忙しくて、勉強する時間を十分に取れない、限られた期間と時間で、効率よくできないものか・・」と思っているのではないだろうか。そこで、私の経験に基づき、効率化のポイントをいくつか挙げてみたい。

1.すきま時間を有効に利用する

 例えば、通勤途中、仕事の合間、昼休みなど、少しでも時間を使えるときに使う。私の場合、通勤途中は貴重な時間となる。午前の選択式問題を解くのは、ほとんど電車の中である。満員で座れないときは、ドアのすぐ横の手すりに寄りかかり、問題集を開くスペースを確保する。午後1の記述式問題を解くときは、問題集を台紙にして、A4の白紙を四つ折りしたもの(もちろん裏も使う)に答えを書いていく。乗車時間は1時間くらいなので、午前問題なら20問程度、午後1なら1問、答え合わせを含めて勉強した。さらに電車を待っているときなども、たとえ1~2分でも時間があれば午前の問題を1~2問解いた。このようなやり方で、効率アップできたと思う。

2.最適な反復タイミングを知る

 一度やったテキストや問題集を二度くり返してやるのは多くの人がとる方法だろうと思う。でも、こんな経験はないだろうか。最初にやって覚えたはずの内容を、二度目にやると忘れている、という経験だ。では覚えるまで三度でも四度でもやればいいかというと、それでは効率が悪い。一体どうすればいいのか。人間の記憶というのは、時間がたつと薄れていく。だから、薄れないうちに復習する必要がある。私の場合、午前の選択式でできなかった問題は、翌日にもう一度やってみることにしている。翌日というのがポイントだ。当日だと間違えようがないし、1週間後だと暗記的な要素が濃い問題(例えば法規など)になると忘れている場合が多い。でも、翌日なら、一晩たっても覚えていたという実感が持てる。

3.完璧より80%を目標にする

 本に書いてあることは漏れなく身につけようという意気込みがあっても、完璧を目指すのは効率がよくない。たしかに好奇心が旺盛な人になると、本に書いてないことまで詳しく調べないと気が済まない場合もあるだろう。このように重箱の隅を突付くぐらい貪欲なほうが、技術者としては伸びる可能性が高い。しかし、試験勉強に関しては、少しくらい理解できないところがあっても、先に進むほうが効率的だと私は思う。私の経験上、80%マスターできれば十分である。合格レベルを70%として、さらに10%向上というのがもっとも現実的な目標だろう。

4.関連分野をついでに勉強する

 問題集には大きく分けて2種類ある。1つは、出題分野のカテゴリ別に章立てしているもの。例えば、午前問題でいうと、システムの開発と運用、セキュリティと標準化、情報化と経営・・などという感じである。もう1つは、過去の問題を時系列に並べたもの。平成14年度、15年度、16年度・・という章立てである。さて、どちらを使うべきか? 効率化という観点から言えば、私は前者のほうがいいと思う。各カテゴリの知識・キーワード等は、断片的に覚えるよりも、カテゴリ単位にひっくるめて体系的に理解するほうがいい。何かを学んだら、それと関連する知識もついでに吸収することにより効率アップが図れるからだ。ちなみに年度別の過去問題集などは、時間を計って解答の訓練をするのに向いている。

5.アウトプット学習を重視する

 私は、テキストをじっくり読むという作業が苦手である。読み始めて少したって気がつくと、ただ字面を目で追っているだけで、頭の中では別のことを考えたりしていた、なんてことがよくある。しかしインプット学習は必要である。インプットがないとアウトプットできないからだ。ただし、インプットに多大な労力と時間をかけるべきではないと思う。情報処理試験の勉強は、吸収した知識をベースに、実際に問題を解くのが最も効果的(むしろ必須)である。このことは、合格した人の多くが感じているのではないか。読む勉強より書く勉強、アウトプット重視でいこう。

6.論文ネタは日頃から収集する

 午後2が論述式の試験では、よほど優秀な人でない限り、何も準備せずに本番の2時間で2400字以上の論文を書くことは不可能である。だから、何かしらの方法で事前の準備をすることになるが、論文ネタというのは、いざ考えようとしてもなかなか浮かんでこないものだ。仮に浮かんだとしても、今一つ論点が曖昧だったり説得力に欠けたりする。理想としては、普段の仕事をしている時に「あ、これはネタになりそう」と感じたことをメモしておき、あとで勉強時間にそのメモから論旨を展開してみる、という方法がいい。論文ネタのバリエーションが増やせる、リアリティのある文章が書きやすいなどのメリットがあり、試験対策としての効率は格段にアップする。

7.よく考えて学習計画を立てる

 以上に挙げたポイントを意識して学習計画を立てることが大切である。例えば、1と2を組み合わせて、会社帰りの通勤電車で選択式問題を解き、翌日の朝の電車では前日の復習をやる。あるいは、4と5を組み合わせて、午後1の問題をひととおり解いた後、二回目は弱点と思われるカテゴリだけに絞って集中的にやる。こうした工夫点を学習計画の中に組み込めば、もう試験対策は半分終わったようなものである(←これはちょっと言い過ぎかもしれないが、開発プロジェクト同様、計画は大切である)。

 以上は、長年の経験によって裏打ちされた勉強法のノウハウである、と自信をもって言える。少しでもお役に立てば幸いである。

 そろそろ春試験の申し込み受付、だな。

ブログアクセス件数の集計結果

以下のように結果をまとめてみた。

a. 1年間の総アクセス件数   24,192件
b. 1年間の月平均アクセス件数  2,016件(a÷12)
c. 1年間の日平均アクセス件数    66件(a÷365)

d. 7月~12月の総アクセス件数   21,184件
e. 7月~12月の月平均アクセス件数  3,531件(d÷6)
f. 7月~12月の日平均アクセス件数   115件(d÷184)

g. 月別アクセス件数ベスト3
  1位:10月 6,552件
  2位:12月 3,498件
  3位: 9月 3,054件

 これらの数字から、昨年は秋の情報処理試験があった10月、合格発表の12月を中心に、下半期にアクセスが伸びていったことが読み取れる。ランキングへの登録やタイムリーな記事の掲載が、徐々に効果となって現れてきたのだと思う。
 私の視野が狭いのかもしれないが、情報処理技術者試験をテーマとしたブログは、意外に多くないという気がしている。それだけに、これからも末永く、多くの人に読んでもらえるようなブログにしていきたい。

祝!ブログ開設1周年

 きょう1月10日は、ブログを開設して丸1年という記念すべき日である。よくここまで続けられたと思う。続けられた要因はいろいろある。まず何より、私は文章を書くことが生まれつき好きだということ(これは先日、冬休みの日記帳でも触れた)。また、取り上げるテーマに対する自分の思い入れが非常に強かったこと。予想以上にいろいろな方に読んでもらいコメントを頂いたことが励みになったこと、等々。1年という節目において、これからもブログを通じて自己研鑽の道を歩んでいくと共に、資格試験に向けて頑張るたくさんの方々を応援してゆきたい。
 1周年記念として、次の企画を予定している。

 ・当ブログへのアクセス数集計結果の掲載
 ・資格取得のための効率的な勉強法の掲載
 ・システム管理(SM)合格時の再現論文の掲載

システム監査の勉強スタート!

書籍名:情報処理教科書 システム監査技術者 2006年度版
出版社:翔泳社


 昨年の春は、このシリーズのテクニカルエンジニア(システム管理)2005版を使っていた。当時のブログにも書いたが、とにかく誤字の多さにあきれてしまったものだ。しかし、せっかく買ったのだから最後まで大切に使おうという気持ちで勉強したところ、運よく合格できた。その縁起を担ぐというわけではないが、アマゾンのサイトを見ているうち、今回も、なんとなくこの翔泳社の本を選んでしまった。
 これから、ときどき勉強の経過などを報告していくことにしよう。
 ただし、はじめに宣言しておく。
 今回はいくら誤字があっても正誤表を作る気は毛頭ない。

 100日間でどこまで通用するか・・。

今年の抱負と夢

 冬休みはずっと「日記帳」カテゴリに書き込むつもりだったが、少々固い話になりそうなので、やはり「情報処理試験全般」カテゴリに含めることにした。

1.今年の抱負
 監査&アナリストへの挑戦!
 いずれも初めての受験になる。春のシステム監査技術者(AU)は、「ターゲットは伝統か新鋭か (11/6記事)」で述べたように、情報セキュリティと比較検討した結果、この道へ進んでみようと決心した。秋のシステムアナリスト(AN)は、システム屋である以上その道を極めたいという野心、そして昨年のプロマネ合格によって初めて午前試験免除の権利が得られたという好条件から、必然的に受験することになる。AU、AN共に、受験するからには本気で勉強し、結果を出したいところだが・・。じつはアナリストに絞って今から頑張ってみようかと考えたりしている。監査は経験ゼロでまったくと言っていいほど縁がないのに対し、アナリストは職制としての経験はないが、仕事に対する考え方とか視点という意味では、監査に比べてとっつきやすそうだからである。しかし、はたして10月までモチベーションを持続できるかというと非常に難しい。となれば、春は練習のつもりで監査を受け、5月あたりから秋のアナリストに照準を合わせて調整していく、というのが現実的だろう。
 以上を踏まえ、今年の目標
  監査は午後1突破
  アナリストは一発合格 を目指す!

2.今年の夢
 夢といえば普通は遠い先の将来のことを思い浮かべるのだろうが、1年という期間限定の夢でも私はいいと思っている。むしろ1年ぐらいのほうがワクワクするではないか。ということで、私の、ささやかな夢は
 ブログをもう1つ作ること
 かねてからブログにしたいテーマを持っていて、いつか機会があればやってみようと考えていたのだ。情報処理試験とはまったく関係のない趣味的なテーマなので、当ブログには含めず、別のブログとして新しく作りたい。興味のない人にとっては、ホントにつまらないブログになるかもしれないが、人間だれしもいろいろな面を持っているというわけで・・いずれ紹介できる日が来ると思う。

 2006年
  新たなる挑戦の年 夢を形にする年・・

冬休み5日目

1月2日(月)
 正月番組がつまらない。普段あまりテレビは見ないけれども、やはり新年は楽しく過ごしたいと思うので見ているが、お笑い系の番組など昔より面白くない、と感じる。番組の質が下がったのか、芸人のレベルが落ちたのか、いずれにしても、私にはつまらないと感じるのだ。なんでだろう。あるいは自分が変わったのだろうか。仕事や勉強ばかりして、感性が鈍ってきたのか、年をくったせいなのか(笑) そもそも正月=お笑いという固定観念がいけないのかもしれない。むしろいい映画を観たりしたほうが、ぐっと心が落ち着くのではないか。
 なんやかや言っても、冬休みはあと1日で終わり。有意義に暮らそう。
 明日は今年の抱負でも書いてみよう。

冬休み4日目 元旦

 あけましておめでとうございます
 今年も宜しくお願い申し上げます

1月1日(日)
 過去に、大みそかまで仕事していたことはあったが、元旦は無い。新年から稼働するシステムを経験していないせいもあるし、やはりサラリーマンなのだから三が日くらい休もうという意識が根付いているせいもある。なんにしても、会社や仕事のことは忘れ、ゆっくりと休める貴重な日であることは確かである。新年になったからと言って、すぐに初詣の人ごみに揉まれに行く習慣はない。少し日がたってから、たとえば仕事始めの日に明治神宮などに行くと、さあ今年も気を引き締めていくぞ! という気持ちになれる。
 というわけで、きょうは何もしない。これがホントの休日。
 | HOME |  ▲ page top


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。