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

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






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

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

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

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


最近の記事


リンク集




自己紹介など

    くつろぐ

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


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


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

メールフォーム

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

広告エリア2












スポンサーサイト

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

公開模試の結果

 アイテック公開模試の結果が返ってきた。ほぼ予想通り、
ボトルネックは午後1であることが判明した。
 逆に言えば、午後1さえクリアすれば合格の可能性がある、ということになる。受験者の数が本試験に比べるとかなり少ないので、合否についての判定材料としては弱い気もするが、数値データに基づいた客観的な評価であることは確かなのだ。
 具体的な成績は非公開とさせていただくが、とにかく、午後1次第である。これで、残り2週間余りの正念場をどのように乗り切るか、はっきりした。とはいえ、午前と午後2も決して油断できない。直前対策がけっこう大切なことは、過去の経験上よくわかっている。
スポンサーサイト

【スキル標準】の整理

 試験センターから公表されている「情報処理技術者スキル標準」を整理しておこう。スキル標準とは、技術者として持つべき知識・技能・能力の水準を規定する指針のようなものである。試験区分ごとにあり、試験センターのHPからダウンロードできる。テクニカルエンジニア(システム管理)のスキル標準は、次の体系から成る。
  1.概要
  2.主要業務
  3.スキル基準
  4.知識体系
 このうち2の主要業務は、システム運用管理業務プロセスと称して、以下10種類のアクティビティに分解される。
   1.システム管理計画
   2.システム管理
   3.資源管理
   4.障害管理
   5.セキュリティ管理
   6.性能管理
   7.システム保守
   8.新規システム開発とシステム移行
   9.運用管理に関するシステム評価
  10.システム利用者対応
 各アクティビティでは、さらに詳細な業務(タスク)に分解され、タスク毎に業務概要を定義している。これらの業務を技術者が適切に遂行できたかどうか、その達成状況を確認するための指標を示すものが「スキル基準」となる。スキル基準では、タスク毎に「達成指標」「要求される知識」「要求される技能」を定義している。
 長々と退屈な話になってきたが、私が言いたかったのは、システム管理エンジニアが目指すべきところは、この「スキル基準」にあるのではないか、ということだ。体系的な整理をする意味で1日1アクティビティずつに分け、達成指標から抽出した要点を列挙してみよう(過去に遡ってアップする)。各々15字以内にまとめたので意味不明の部分もあるかと思うが、実際のスキル標準と照合すれば明らかになるだろう。

1 システム管理計画

 1-1 システム管理要件の定義
  111 経営層・ユーザへの適切な質問
  112 標準的な手法による情報収集
  113 対立するユーザ要求への説得
  114 経営目標との整合性の確保
  115 管理対象外の領域の明示
  116 問題点への対応の優先順位付け

 1-2 システム管理サービスの明確化
  121 サービス項目と範囲の区分け
  122 ユーザとの役割分担の明示
  123 文書化とユーザからの承認

 1-3 サービスに関する費用/対価の算出
  131 運用費用の算出根拠の明示
  132 サービスの種類と技術水準の明示
  133 例外・目標未達成時の処置の明示
  134 ユーザへの説明・承認

 1-4 運用ルールの作成
  141 全管理業務に対する適切なルール
  142 全資源に対する適切な利用規則
  143 運用部門とユーザへの説明・承認
  144 運用ルールの適宜見直し

 1-5 システム管理計画書の作成
  151 システム管理要件の反映
  152 ユーザとの共同レビューの実施

2 システム管理

 2-1 システム運用
  211 運用方針の文書化
  212 運転スケジュールのユーザ承認
  213 実施作業の継続的な記録
  214 評価用データの継続的な収集
  215 運用状況の定期的な報告・承認

 2-2 ユーザ管理
  221 ユーザ登録・抹消作業の標準化
  222 変更情報の管理台帳への反映
  223 管理台帳のセキュリティの維持
  224 ユーザ遵守状況の定期的な確認
  225 ユーザ側のセキュリティの維持
  226 管理状況の定期的な報告・承認

 2-3 オペレーション管理
  231 通常時と非常時の指示体制の確立
  232 オペレーション規約の文書化
  233 オペレータ業務範囲の理解・実行
  234 システムの安定
  235 業務の引き継ぎ手順の確立
  236 定期的な改善活動と品質評価

 2-4 課金管理
  241 課金基準の根拠の明示
  242 適切なツールを用いたデータ収集
  243 資源使用量に見合う課金額の算出
  244 予実差異への是正措置の提案
  245 ユーザへの課金情報の定期的報告

 2-5 コスト管理
  251 運用に関わる費目の適切な設定
  252 上位管理者による予算の承認
  253 費目別のコスト管理
  254 予実差異の的確な分析・報告
  255 運用費実績のユーザ承認
  256 効果的な費用削減案の提示

 2-6 要員管理
  261 勤務状況の労働関連法規への準拠
  262 健康管理への対応策の実施
  263 能力の評価と教育訓練の実施
  264 育成計画による要員配置の策定
  265 派遣要員に関する契約条項の実施

 2-7 分散サイト管理
  271 サイトのユーザへの説明・承認
  272 サイト責任者の設置と権限の割当
  273 要求水準でのシステム資源の利用
  274 ユーザへの教育訓練と支援

 2-8 運用管理システムの利用
  281 利用目的と期待効果の明確化
  282 利用による負の要因が生じない
  283 安定性・信頼性・効率性の向上

 2-9 標準化
  291 運用手順と各種基準の設定・適用
  292 標準の改廃ルールの記述
  293 周知徹底する方法の策定・実施
  294 遵守状況の調査と判断基準の明示
  295 現状と今後に関する定期的な報告

3 資源管理

 3-1 ハードウェア管理
  311 管理対象とする範囲の区分け
  312 保守方針の明示
  313 方針による全資源の適切な管理
  314 適切な資産・構成・変更管理
  315 遅延のない登録・変更・抹消
  316 管理状況と問題点の定期的な報告

 3-2 ソフトウェア管理
  321 管理対象とする範囲の区分け
  322 改修・リプレース方針の明示
  323 方針による全資源の適切な管理
  324 適切な構成・変更管理と報告
  325 遅延のない登録・変更・抹消
  326 管理状況と問題点の定期的な報告

 3-3 データ管理
  331 管理対象とする範囲の区分け
  332 データ保存期間と廃棄手順の明示
  333 データ資源の適切な管理
  334 データのライフサイクルの管理
  335 権限内での遅滞ないデータ利用
  336 データの適切な変更管理
  337 管理状況と問題点の定期的な報告
  338 監査に対する資料の作成・報告

 3-4 ネットワーク資源管理
  341 管理対象とする範囲の区分け
  342 拡張・増強計画の立案
  343 方針による資源の適切な管理
  344 適切な資産・構成・変更管理
  345 権限内での遅滞ない資源の利用
  346 管理状況と問題点の定期的な報告
  347 監査に対する資料の作成・報告

 3-5 施設・設備管理
  351 管理対象とする範囲の区分け
  352 中長期的な取得・廃棄計画の立案
  353 導入設置資源の遅滞ない利用
  354 管理状況と問題点の定期的な報告

4 障害管理

 4-1 障害の監視
  411 監視内容と監視方法の文書化
  412 監視システムの正常な機能
  413 障害発生時の連絡体制の確立
  414 障害の漏れない発見
  415 障害の発見に関する教育訓練
  416 関係部署への遅滞ない発見の報告

 4-2 障害原因の究明
  421 究明手順の正確かつ簡潔な文書化
  422 必要な情報の漏れない収集
  423 究明手順の体系化
  424 発見された障害の早期切り分け
  425 影響範囲の局所化
  426 原因究明に関する教育訓練
  427 関係部署への遅滞ない状況の報告

 4-3 回復処理
  431 回復手順の正確かつ簡潔な文書化
  432 影響範囲の拡大しない早期回復
  433 回復後の遅滞ないシステム利用
  434 回復作業予定と影響に関する連絡
  435 失敗した場合の代替方法の計画
  436 遅滞ない回復作業状況の報告
  437 障害回復処理に関する教育訓練

 4-4 障害記録・再発防止
  441 障害原因の分類・コード化
  442 適切な回復処理による再発なし
  443 回復までの正確かつ完全な記録
  444 再発防止策の策定と実施
  445 損失と防止対策コストとの比較
  446 経緯・原因・是正措置の報告

 4-5 分散システムの障害管理
  451 分散サイト管理責任者との連携
  452 発生から回復までの適切な対応

5 セキュリティ管理

 5-1 セキュリティ管理体制の確立と方針の設定
  511 自社のセキュリティポリシに準拠
  512 管理体制の正確かつ完全な文書化
  513 損害額と対策コストとの比較
  514 対策未実施時のリスクの検討
  515 対策基準の遵守と目標水準の維持
  516 セキュリティ侵害対策の教育訓練

 5-2 セキュリティ侵害の監視と状況分析
  521 侵害発生時の連絡体制の確立
  522 監視方法の設定と監視データ収集
  523 侵害の漏れない発見
  524 侵害追跡調査と侵害の識別
  525 セキュリティ侵害監視の教育訓練
  526 発生状況の遅滞ない報告

 5-3 分散サイトのセキュリティ管理
  531 セキュリティ侵害が発生しない
  532 自社のセキュリティポリシに準拠
  533 サイト固有の管理要件の反映
  534 損害額と対策コストとの比較
  535 侵害発生時の連絡体制の確立
  536 侵害の漏れない発見
  537 発生状況の遅滞ない報告

 5-4 セキュリティ強度の確認
  541 目標セキュリティ強度の設定
  542 チェックリストによる確認テスト
  543 目標未達への対策と再チェック

 5-5 セキュリティ監査対応
  551 自社のセキュリティポリシに準拠
  552 適切な監査資料の作成
  553 監査指摘事項への改善策の明示

6 性能管理

 6-1 性能評価の実施
  611 監視モデル・評価尺度の文書化
  612 サービス項目に準拠した評価項目
  613 自社の特性に適合した評価モデル
  614 評価指標データの収集方法の明示
  615 構成変更に伴う評価基準の更新
  616 基準との差異分析と原因の究明
  617 性能評価結果の定期的な報告
  618 問題発生時の遅滞ない報告

 6-2 キャパシティ管理
  621 必要容量の管理とトラブル防止
  622 全資源の限界値の設定
  623 評価指標データの収集方法の明示
  624 需要拡大の予測と増強計画の立案
  625 資源の効率的な利用
  626 容量・性能限界到達リスクの分析
  627 資源の使用状況の定期的な報告
  628 問題発生時の遅滞ない報告

 6-3 分散システムの性能管理
  631 システム固有の管理要件の反映
  632 サービス項目に準拠した評価項目
  633 自社の特性に適合した評価モデル
  634 評価指標データの収集方法の明示
  635 性能評価結果の定期的な報告
  636 問題発生時の遅滞ない報告

 6-4 分散システムにおけるキャパシティ管理
  641 特徴を考慮した資源増強計画
  642 クライアント・サーバ両側の管理
  643 全資源の限界値の設定
  644 評価指標データの収集方法の明示
  645 資源の使用状況の定期的な報告
  646 問題発生時の遅滞ない報告

7 システム保守

 7-1 システム保守計画の作成
  711 適切な関係者の保守ニーズの収集
  712 保守ニーズの正確な識別と文書化
  713 保守ニーズの適切な管理
  714 システム管理要件に合致した計画
  715 中長期・短期の計画の策定
  716 項目の優先順位付け
  717 保守能力のある関係者の参加
  718 保守作業に伴う影響の分析・調査
  719 保守作業の未実施時のリスク分析
  71A 保守計画のユーザへの説明・承認

 7-2 保守業務の実施
  721 保守手順の文書化と関係者の承認
  722 実施結果の確認・評価・文書化
  723 保守情報の整理・分析
  724 保守作業状況の遅滞ない報告
  725 他のソフトウェアに影響ない保守
  726 投資効果を考慮した保守
  727 変更結果の遅滞ない報告

8 新規システム開発とシステム移行

 8-1 開発計画の立案
  811 移行・運用の観点からのレビュー
  812 推進体制と障害時体制の定義
  813 システム運用管理の実現性の検証
  814 移行・業務手順の変更方針の定義
  815 教育訓練の目的・範囲の定義

 8-2 システム運用方式の設計
  821 オンバッチ・集中分散の方式設計
  822 既存の運用方式との整合性の検討
  823 市販の運用管理ツールの採用

 8-3 移行・運用テスト
  831 テスト評価指標とツールの整備
  832 移行時に予想される問題点の収集
  833 移行時に必要な環境・手順の予測
  834 本稼働を想定したテストの評価

 8-4 システム移行
  841 的確な移行計画のレビュー・承認
  842 本環境への移行と正常動作の確認
  843 移行時に発見した問題点の文書化
  844 問題発生時の続行の適否判断
  845 進捗状況と結果の遅滞ない報告
  846 移行後の運用作業の適切な引継ぎ
  847 評価データの集積と保存

 8-5 開発環境の管理 
  851 開発作業の特性に応じた管理方針
  852 利用者への管理方針の周知徹底
  853 管理状況の定期的な報告
  854 本稼働システムとの整合性の維持
  855 本稼働システムへの影響がない

9 運用管理に関するシステム評価

 9-1 評価目的・評価対象の設定
  911 運用に関する明確な評価目的
  912 明確な評価時期・内容・対象範囲

 9-2 評価項目・評価基準の設定と評価の実施
  921 明確な評価項目・評価基準
  922 評価指標データの収集方法の明示
  923 過去の評価結果の時系列な参照可

 9-3 システム改善提案
  931 運用上の問題点と要因の分析
  932 評価作業と結果の遅滞ない報告
  933 改善によるコストと効果の比較
  934 普遍的な改善案

 9-4 分散システムの評価
  941 システムの特徴を捉えた評価
  942 総合的な経済性を考えた評価
  943 運用上の問題点と要因の分析

10 システム利用者対応

 A-1 ユーザの遵守事項の明確化
  A11 ユーザ向けの用語での文書化
  A12 ルール遵守の重要性の認識
  A13 効率運用を阻害する利用例の説明
  A14 未熟なユーザへの指導・助言

 A-2 ユーザサポート
  A21 ユーザニーズの的確な識別
  A22 ユーザサポート範囲の定義
  A23 ユーザの水準に応じたサポート
  A24 ユーザ教育内容とニーズとの一致
  A25 教育訓練効果の評価

 A-3 ユーザ新要求への対応
  A31 サービスレベルの満足状況の管理
  A32 要求の逐一記録と時系列な参照可
  A33 新要求の分析とトレンドの把握

 A-4 ユーザコンサルティング

注目したいキーワード

 もう1ヵ月しかないと思うか、まだ1ヵ月もあると思うかで、今後の取り組みが決まってくる。私としては、まだ1ヵ月派であり、徐々にピッチを上げていきたいと考えている。せっかく模擬試験も受けたことだし、試験に出てきた気になる用語(キーワード)に注目してみよう。あえて用語の意味や説明は、省略する。何だろう?というものがあれば調べてみてほしい。自発的に調べると頭に残りやすいはずだ。

(午前問題から抽出)
 ・RAID
 ・TPC
 ・SAN
 ・SLA
 ・システム管理基準
 ・ISMS認証基準
 ・個人情報保護法

(午後1問題から抽出)
 ・ヘルプデスク
 ・IDC
 ・ハウジングサービス
 ・負荷分散装置
 ・スケールアウト

(午後2問題から抽出)
 ・コスト管理
 ・変更管理手順
 ・障害対応手順
 ・情報収集手順

公開模試・受験レポート

 1月21日の記事(公開模試について)で宣言したとおり、きょう3月13日、アイテックの公開模擬試験を受験してきた。その模様をレポートしておく。
 会場は、嘉悦女子中・高等学校。飯田橋駅から徒歩10分ほどで到着。アイテックの公開模試といえば、以前、青山学院大学で受けたが、そちらは今回、ソフ開とデータベースだけ。ほかの区分(監査、管理、基本情報、初シス)は嘉悦であった。この会場、私自身は初めてである。午前の試験が始まる前に、校内放送が流れ、試験の説明が行われた。教室で放送を聞くという状況は予期していなかったので新鮮だった。机と椅子は、よく大学の大教室にあるような横に長くつながったものでなく、一人用のいわゆる学校机なので、隣の人の振動などが気にならなくてよい。
 さて前置きはこのくらいにして、本題にはいろう。午前は、今回から5問増えて55問、時間も10分長くなり100分になった。だが実際に受験してみると、あまり気にならなかった。5問くらいであれば、計算問題でない限り、さほど時間はかからない。情報セキュリティに関する問題が増え、多少、迷った部分もあったが、標準的な出題ではなかったかと思う。まだ採点していないが、足切りラインは越えられる程度かと推測する。
 午後1。これは従来通り4問中3問を90分で解答するのだが、2問解いたところで、残り15分しか無かった。結局3問目は殆どまともに解答できなかった。帰ってから調べてみると、昨年のシステム管理本試験の午後1は、1問4ページ×4問。ところが、きょうの公開模試は、1問6ページ×4問。無理もない。問題の分量が多いのだ。意図的にこうしているのかもしれないが、それにしても私には多いと思えた。問題の難易度としては中くらいだが、時間内で完全解答するのは難しい。
 午後2。これも従来通り3問中1問を120分で解答する。本当はきちんと論文構成を書いてから取りかかるつもりだったが、時間が気になって殆ど構成も考えず、ただ闇雲に用紙のマス目を埋めただけになってしまった。2時間はあっという間に過ぎ、どうにか制限字数はクリアしたものの、支離滅裂な文章だったように思う。
 こうしてみると、自分の試験対策もまだ甘いのかもしれない。そこに気付いただけでも収穫があったと考えよう。あと1ヵ月で午後1&午後2をどのように進めるかだ。

のびない応募者数

情報処理技術者試験センターから公表された。いつもこのくらいの時期なのでHPを見たら、やはり掲載していた。以下の通り。

平成17年度春期試験の応募者数速報
試験区分
  応募者数 前年同期応募者数 増減数
システム監査技術者試験(AU)
  9,101 9,133 -32
テクニカルエンジニア(データベース)試験 (DB)
  22,624 23,613 -989
テクニカルエンジニア(システム管理)試験 (SM)
  12,463 12,949 -486

テクニカルエンジニア(エンベデッドシステム)試験 (ES)
  5,067 3,946 1,121
ソフトウェア開発技術者試験 (SW)
  71,652 79,410 -7,758
初級システムアドミニストレータ試験 (AD)
  86,542 94,804 -8,262
基本情報技術者試験 (FE)
  100,708 109,985 -9,277
合計
  308,157 333,840 -25,683

じつは、前年のシステム管理試験の合格者数は、475
ここで、今年のSMの増減数は-486であり、475に近い数字となっている。私のように前年に合格しなかった人ほぼ全員が再び応募するとしたら、こんな数字になるのだろうが、実際はどうなのだろう(こんなことを想像しても無意味なことは確かだ)。
それにしても、エンベ以外は軒並みダウンとは・・。
試験の成績照会が可能になったのは良いことだと思うが、そういう改善をしても応募者数が増えるわけではないようだ。センターの落胆が目に浮かぶ気がする。

正誤表打ち止め

書籍名:情報処理教科書 テクニカルエンジニア(システム管理)2005年度版
出版社:翔泳社


 週1ペースでアップしてきた正誤表であるが、ここで終わりとする。最後まで一通り読んでみて、単純な誤字はまだ少しあったものの、もうここに掲載するほどの価値は無いと判断した。出版社から公開されている正誤表と、このブログの過去5回にわたる正誤表をあわせて見ていただくといい。
 疲れる作業であったが、誤りはないかと注意深く読む癖がついたのか、勉強に集中して取り組めたような気がする。「災い転じて福となす」ならいいがなあ・・。

もうすぐ春

 3月になり、まだ寒さも残るなか、昼どきの陽射しは徐々にあたたかさを増してきた。春の足音と共に、試験の日も少しずつ近づいてくる。
 このブログを開設して50日が経過した。そして、試験日4月17日までは、あと47日。つまり、もう
折り返し地点を通過しているのだ。マラソンでいえば20~25kmあたりか。ここから35km付近までが最も苦しいだろう。ここを辛抱すれば、あとは結果がついてくる。
 「ランナーズ ハイ」という言葉がある。ランニングの途中で苦しさが消えて爽快な気分になる現象で、苦痛を軽減する脳内物質が分泌されるのだという。昔、私も走っていて、ランナーズハイを経験したことがある。
 資格の勉強も、こういった状態になれば理想的と言えよう。
 | HOME |  ▲ page top


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