カテゴリ: 9.マネジメント

■H28秋AP午前
問55 Jis Q 20000-1 は,サービスマネジメントシステム(SMS)及びサービスのあらゆる場面でPDCA方法論の適用を要求している。SMSの実行(DO)の説明はどれか。
ア SMS及びサービスのパフォーマンスを継続的に改善するための処置を実施する。
イ SMSを確立し,文書化し,合意する。
ウ サービスの設計,移行,提供及び改善のためにSMSを導入し,運用する。
エ 方針,目的,計画及びサービスの要求事項について,  SMS及びサービスを監視。測定及びレビューし,それらの結果を報告する。
【正解】ウ

問56 1Tサービスマネジメントにおいて,災害による重大なサービス停止に関する事業影響度分析は,どのプロセスで実施するか。
ア インシデント及びサービス要求管理
イ サービス継続及び可用性管理
ウ サービスレベル管理
エ 問題管理
【正解】イ

問57 次の処理条件で磁気ディスクに保存されているファイルを磁気テープにバックアップするとき,バックアップの運用に必要な磁気テープは最少で何本か。
〔処理条件〕
(1)毎月初日(1日)にフルバックアップを取る。フルバックアップは1本の磁気テープに1回分を記録する。
(2)フルバックアップを取った翌日から次のフルバックアップまでは,毎日,差分バックアップを取る。差分バックアップは,差分バックアップ用としてフルバックアップとは別の磁気テープに追記録し, 1本に1か月分を記録する。
(3)常に6か月前の同一日までのデータについて,指定日の状態にファイルを復元できるようにする。ただし,6か月前の月に同一日が存在しない場合は,当該月の末日までのデータについて,指定日の状態にファイルを復元できるようにする(例:本日が10月31日の場合は,  4月30日までのデータについて,指定日の状態にファイルを復元できるようにする)。
ア 12  イ 13  ウ 14 エ 15
【正解】ウ

■H27秋AP午前
間55 ITILは,各プロセスに対する重要成功要因(CSF)と重要業績評価指標(KPI)を例示している。次のインシデント管理のCSFに対するKPIとして,適切なものはどれか。
〔CSF〕
インシデントをできるだけ迅速に解決し,事業へのインパクトを最小限にする。
ア インシデントの総件数
イ サービスデスクが他のサポート・レベルに問い合わせずにクローズできたインシデントの割合
ウ サービスデスク担当者当たりの処理したインシデントの件数
エ 変更とリリースに関連するインシデントの件数と割合
【正解】イ

問56 ITサービスマネジメントにおけるサービスレベル管理プロセスの活動はどれか。
ア ITサービスの提供に必要な予算に対して,適切な資金を確保する。
イ 現在の資源の調整と最適化,及び将来の資源要件に関する予測を記載した計画を作成する。
ウ 災害や障害などで事業が中断しても,要求されたサービス機能を合意された期間内に確実に復旧できるように,事業影響度の評価や復旧優先順位を明確にする。
エ 提供するITサービス及びサービス目標を特定し,サービス提供者が顧客との間で合意文書を交わす。
【正解】エ

問57 ITサービスマネジメントにおける問題管理プロセスにおいて実施することはどれか。
ア インシデントの発生後に暫定的にサービスを復旧させ,業務を継続できるようにする。
イ インシデントの発生後に未知の根本原因を特定し,恒久的な解決策を策定する。
ウ インシデントの発生に備えて,復旧のための設計をする。
エ インシデントの発生を記録し,関係する部署に状況を連絡する。
【正解】イ

■H27春AP午前
問55 ITILの可用性管理プロセスにおいて,ITサービスの可用性と信頼性の管理に関わる
  KPIとして用いるものはどれか。
ア サービスの中断回数
イ 災害を想定した復旧テストの回数
ウ 処理能力不足に起因するインシデントの数
エ 目標を達成できなかったSLAの項目数
【正解】ア

問56 情報システムの障害対策の一つである縮退運用の説明はどれか。
ア システムを一斉に停止させるのではなく,あらかじめ決められた手順で段階的に停止させること
イ 実行中のジョブが異常終了したとき,他のジョブに影響を与えないように,システムの運用を続行すること
ウ 障害箇所を切り離し,機能又は性能が低下してもシステムを稼働させ続けること
エ 障害が発生した時点で,その後に実行する予定のジョブのスケジュールを変更すること
【正解】ウ

■H26秋AP午前
問55 SLAに記載する内容として,適切なものはどれか。
ア サービス及びサービス目標を特定した,サービス提供者と顧客との間の合意事項
イ サービス提供者が提供する全てのサービスの特徴,構成要素,料金
ウ サービスデスクなどの内部グループとサービス提供者との間の合意事項
エ 利用者から出されたITサービスに対する業務要件
【正解】ア

問56 日標復旧時点(RPO)を24時間に定めているのはどれか。
ア 業務アプリケーションをリリースするための中断時間は,24時間以内とする。
イ 業務データの復旧は,障害発生時点から24時間以内に完了させる。
ウ 障害発生時点の24時間前の業務データの復旧を保証する。
エ 中断したITサービスを24時間以内に復旧させる。
【正解】ウ

問57 ディスク障害時に,交換したディスクにフルバックアップを取得したテープからデータを復元した後,フルバックアップ取得時以降の更新後コピーをログから反映させてデータベースを回復する方法はどれか。
ア チェックポイントリスタート イ リブート  ウ ロールバック エ ロールフォワード
【正解】エ

■H26春AP午前
問55 1Tサービスマネジメントにおける回避策(ワークアラウンド)の説明として,適切なものはどれか。
ア インシデント対応手順として採られる,サービスへの影響を低減又は除去する方法のこと
イ 検出したイベントを膺報,警告又は例外のカテゴリに分類すること
ウ 特定の期間に発生したインシデントや問題に対して,影響を受けた人数,停止時間の長さなどを考慮に入れて事業への影響を分析すること
エ 特定のサービス又は作業負荷をピーク時間外の時間帯に移動させて,作業負荷の平準化を図ること
【正解】ア

問56 データの追加・変更・削除が,少ないながらも一定の頻度で行われるデータベースがある。このデータペースのフルバックアップを磁気テープに取得する時間間隔を今までの2倍にした。このとき,データベースのバックアップ又は復旧に閧する記述のうち,適切なものはどれか。
ア フルバックアップ1回当たりの磁気テープ使用量が約2倍になる。
イ フルバックアップ1回当たりの磁気テープ使用量が約半分になる。
ウ フルバックアップ取得の平均実行時間が約2倍になる。
エ ログ情報によって復旧するときの処理時間が平均して約2倍になる。
【正解】エ

問57 電源の瞬断時に電力を供給したり,停電時にシステムを終了させるのに必要な時間の電力を供給したりすることを目的とした装置はどれか。
ア AVR  イ CVCF  ウ UPS
工 自家発電装置
【正解】ウ

■H25秋AP午前
問55 1TILによれば,障害が発生した場合にインシデント管理プロセスで行う活動はどれ
  か。
ア ITサービスを迅速に復旧させるために回復策を実施する。
イ 既知のエラーレコードを作成して,データベースに登録する。
ウ 障害対応として, RFCに基づいてシステムの構成を変更する。
エ 障害の根本原因を追究し,解決策を見つけ出して実施する。
【正解】ア

問56 データベースのバックアップ処理には,フルバックアップ方式と差分バックアップ方式がある。差分バックアップ方式による運用に関する記述のうち,適切なものはどれか。
ア 障害からの回復時に差分だけ処理すればよいので,フルバックアップ方式に比べて復旧時間が短い。
イ フルバックアップのデータで復元した後に,差分を加えて復旧する。
ウ フルバックアップ方式と交互に運用することはできない。
エ フルバックアップ方式に比べ,バックアップに要する時間が長い。
【正解】イ

問57 ミッションクリティカルシステムの意味として,適切なものはどれか。
ア OSなどのように,業務システムを稼働させる上で必要不可欠なシステム
イ システム運用条件が,性能の限界に近い状態の下で稼働するシステム
ウ 障害が起きると,企業活動に重大な影響を及ぼすシステム
エ 先行して試験導入され,成功すると本格的に導入されるシステム
【正解】ウ

■H25春AP午前
問55 SLAを説明したものはどれか。
ア ITサービスマネジメントのベストプラクティスを集めたフレームワーク
イ 開発から保守までのソフトウェアライフサイクルプロセス
ウ サービス及びサービス目標値に関するサービス提供者と顧客間の合意
エ 品質マネジメントシステムに関する国際規格
【正解】ウ

問56 (1)~(4)はある障害の発生から本格的な対応までの一連の活動である。(1)~(4)の各
  活動とそれに対応するITILV3の管理プロセスの組合せのうち,適切なものはどれか。
(1)利用者からサービスデスクに“特定の入力操作が拒否される”という連絡があっ
 たので,別の入力操作による回避方法を利用者に伝えた。
(2)原因を開発チームで追究した結果,アプリケーションプログラムに不具合がある
 ことが分かった。
(3)原因となったアプリケーションプログラムの不具合を改修する必要があるのかど
 うか,改修した場合に不具合箇所以外に影響が出る心配はないかどうかについて,
 関係者を集めて確認し,改修することを決定した。
(4)改修したアプリケーションプログラムの稼働環境への適用については,利用者へ
 の周知,適用手順及び失敗時の切戻し手順の確認など,十分に事前準備を行った。
9-2 H25h_56
【正解】ア

問57 新システムの開発を計画している。このシステムのTCOは何千円か。ここでシステムは開発された後,3年間使用されるものとする。
9-2 H25h_57
ア 40,500   イ 90,000   ウ 95,000   エ 135,500 
【正解】エ

■H24秋AP午前
問55 ITサービスマネジメントにおけるインシデント管理の主な活動はどれか。
ア インシデントから発生する問題の解決策の評価
イ インシデントの解決とサービスの復旧
ウ インシデントの根本原因の究明
エ インシデントのトレント分析と予防措置
【正解】イ

問56 ITサービスマネジメントの可用性管理のKPIとして用いるものはどれか。
ア 災害を想定した復旧テストの回数
イ サービスの中断回数
ウ 性能不足に起因するインシデントの数
エ 目標を達成できなかったSLAの項目数
【正解】イ

■H24春AP午前
問55 1Tサービスマネジメントのイベント管理における,フィルタリングのレベルの設定方針のうち,適切なものはどれか。
ア 既知のエラーに関するイベントだけを,検出するようにレベルを設定する。
イ ささいなイベントも漏らさず,全てを検出できるようにレベルを設定する。
ウ 事前に設計され,合意された設定レベルを変更せずに固定する。
エ 有効欧評価プロセスでの評価結果に基づき,設定レベルを継続的に見直す。
【正解】エ

問56 レプリケーションが有効な対策となるものはどれか。
ア 悪意によるデータの改ざんを防ぐ。
イ コンピュータウイルスによるデータの破壊を防ぐ。
ウ 災害発生時にシステムが長時間停止するのを防ぐ。
エ 操作ミスによるデータの削除を防ぐ。
【正解】ウ

問57 新システムの開発を計画している。提案された4案の中で,TCOが最小のものはどれか。ここで,このシステムは開発後,3年間使用されるものとする。
9-2 H24h_57
ア A案   イ B案   ウ C案   エ D案
【正解】ウ

■H27春AP午前
問52 PMBOKによれば,“アクティビティ定義”プロセスで実施するものはどれか 。
ア 作業順序,所要期間,必要な資源などから実施スケジュールを作成する。
イ 作業を階層的に要素分解してワークパッケージを定義する。
ウ プロジェクトで実施する作業の相互関係を特定して文書化する。
エ プロジェクトの成果物を生成するために実施すべき具体的な作業を特定する。
【正解】エ

■H26秋AP午前
問52 ソフトウェア開発プロジェクトで行う構成管理の対象項目として,適切なもの はどれか。
ア 開発作業の進捗状況            ウ プログラムのバージョン
イ 成果物に対するレビューの実施結果   エ プロジェクト組織の編成
【正解】ウ

■H24秋AP午前
問54 プロジェクトの品質マネジメントにお いて,プロセスが安定しているかどうか, 又はパフォーマンスが予測のとおりである かどうかを判断するために用いるもので あって,許容される上限と下限が設定さ れているものはどれか。
ア 管理図     イ 実験計画法
ウ 流れ図     エ ペンチマーク
【正解】ア

■H24春AP午前
問54 システムの要求分析時に行うインタ ビュー実施上の留意点のうち,適切なもの はどれか。
ア インタビュー対象者の回答が,事実であるか推測であるかを区別すべきである。
イ インタビューの対象者は,その業務を直接行っている担当者に限るべきである。
ウ 質問内容を記入した用紙を事前に渡すことは,避けるべきである。
エ 質問は,“はい"か"いいえ"で答えられるものに限るべきである。
【正解】ア

問51 あるプロジェクトのステークホルダとして,プロジェクトスポンサ,プロジェクトマネージヤ,プロジェクトマネジメントオフィス及びプロジェクトマネジメントチームが存在する。ISO 21500 によれば,組織としての標準化,プロジェクトマネジメントの教育訓練,プロジェクトの監視などの役割を主として担うのはどれか。
ア プロジェクトスポンサ
イ プロジェクトマネーシャ
ツ プロジェクトマネジメントオフイスエ プロジェクトマネジメントチーム

問52 組織が遂行する業務を定常業務とプロジェクトとに類別したとき,定常業務の特性はどれか。
ア ある業務のために編成された期間限定のチームで遂行する。
イ 成果物を反復的に生産して提供する活動を継続的に遂行する。ウ 独自のプロダクトやサービスを創造する。
エ 目的を達成するために開始し,目的を達成したときに終了する。

問53 プロジェクトのスケジュールを短縮したい。当初の計画は図1のとおりである。作業Eを作業El,  E2,E3に分けて,図2のように計画を変更すると,スケジュールは全体で何日短縮できるか。
図1
図2
ア 1
凡例
作業名
○濤O…………>:ダミー作業
イ 2
ウ 3
24 -
工 4

問54 システム開発における工数の見積りに関する記述のうち,適切なものはどれか。ア COCOMOの使用には,自社における生産性に関する,蓄積されたデータが必要である。
イ 開発要員の技量は異なるので工数は参考にならないが,過去に開発したプログラムの規模は見積りの参考になる。
ウ 工数の見積りは,作業の進捗管理に有効であるが,ソフトウェアの品質管理には関係しない。
エ ファンクションポイント法による見積りでは,プログラムステップ数を把握する必要がある。

1.システム監査とは
システム監査は、独立した立場のシステム監査人が,情報システムに対するリスク対応が適切に整備・運用されているかを監査します。参考ですが、監査には公認会計士が行う会計監査や、企業の監査役が行う業務監査もあります。
システム監査というのはイメージしにくいのですが、ざっくりと言うと、システムが適切かどうかをチェックすることです。人間で言うと、医師が実施する患者への健康診断のようなものです。
システムを監査する人がシステム監査人で、監査をされる側は被監査部門と言います。システム監査を行う際に重要なのが、被監査部門からの「独立性」です。たとえば、同じ組織の人が監査をすれば、重大な問題を発見したとしても、指摘をするのをためらう可能性があるからです。

システム監査について、IPAのシステム監査技術者試験の資料には次のように述べられています。
システム監査は、監査対象から独立した監査人が、情報システムを信頼性、安全性及び効率性の観点から総合的に点検・評価し、関係者に助言・勧告するものであり、コンピュータ・セキュリティの確保とシステムの有効活用を図る上で極めて有効な手段であり、情報化社会の健全化に大きく貢献するものである。
(https://www.jitec.ipa.go.jp/1_11seido/s44_h6har/old_au.htmlより)

ポイントの一つは、「監査対象から独立した」という点です。独立した監査人が、客観的にシステムを評価します。
独立性には次の2つがあります。
(1)外観上の独立性
(システム監査基準2.1を参照)
システム監査を客観的に実施するために、監査対象から独立していなければならない。
(2)精神上の独立性
(システム監査基準2.2を参照)
偏向を排し、常に公正かつ客観的に監査判断を行う。
kansa 
システム監査人は,助言をする立場であり、対策方針を決定したり、改善命令を出すことなどの権限はありません。医者が患者に対し、手術を強制することができないのと同じです。しかし、システム管理者や関係部署に対し、監査の実施への協力要請はできます。

2.「信頼性」「安全性」「効率性」
「信頼性」「安全性」「効率性」という3つのキーワードを覚えましょう。
それぞれの言葉の意味に関しては、旧システム監査基準より引用します。
(3) 信頼性・・・・・・・情報システムの品質並びに障害の発生、影響範囲及び回復の度合
(4) 安全性・・・・・・・情報システムの自然災害、不正アクセス及び破壊行為からの保護の度合
(5) 効率性・・・・・・・情報システムの資源の活用及び費用対効果の度合

例を挙げます。安全性という観点で、不正アクセスが発生しないように、アクセスログを取得するという統制(コントロールという)が適切にとられているかを監査します。

3.(参考)
H19午後1問4に、システム監査の具体例が表にまとめられているので掲載します。具体例を見ることでイメージがわきやすくなると思います。ただ、監査目的などは、この事例に限ってのことなので、あくまでもイメージとして考えてください。

表2 監査の概要
項目内容
(1)監査目的システム開発部で実施しているデータ修正業務が、定められた手順に従って行われ、不正や操作ミスなどが発生していないかどうかを確認する。
(2)監査対象部門システム企画部システム開発部
(3)監査手続システム企画部が作成した“システム保守運用基準書”に記載されているデータ修正の手順が、不正や操作ミスなどを防ぐ手続として有効かどうかについて、記載内容を確認する。データ修正が、“システム保守運用基準書”に従って行われているかどうかを確認する。具体的には、ユーザ部門によって作成された“データ修正依頼書”を入手し、ユーザ部門の責任者及びシステム開発部の責任者の事前承認が得られているかどうかを確認する。
(4)発見事項“システム保守運用基準書”には、緊急の場合のデータ修正のルールが記載されていない。また、部署名などが更新されていない箇所が散見された。“データ修正依頼書”に、ユーザ部門の責任者又はシステム開発部の責任者の承認印がないケースが多数見つかった。特に、緊急依頼の場合に承認印がないケース多い。
(5)改善勧告“システム保守運用基準書”に緊急の場合のデータ修正のルールが記載するとともに、記載内容を最新状態に保つことデータ修正を行う場合には、“システム保守運用基準書”に従って、事前にユーザ部門の責任者及びシステム開発部の責任者の承認を得ることを徹底すること

システム監査基準はとても重要です。 http://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kansa.pdf
システム監査の流れやを理解しましょう。

応用情報技術者シラバス
システム監査基準に関して次のように述べられています。
① システム監査基準
  システム監査における監査人の行動規範,手順,内容は,経済産業省が策定したシステム監査基準によって規定されていることを理解する。

システム監査基準の概要
以下に概要を整理します。

Ⅰ.前文
・システム管理基準に準拠しているかどうかの視点を原則とする。
・情報セキュリティ監査基準と整合性を図る。

Ⅱ.システム監査の目的
・リスクコントロールが適切に整備、運用されているかを評価する。
・独立かつ専門的な立場のシステム監査人が実施

Ⅲ.一般基準(監査人としての適格性及び監査業務上の遵守事項を規定)
独立性、客観性、職業倫理

Ⅳ.実施基準(監査実施上の枠組みを規定)
1.監査計画を立案する必要がある。
2.監査の手順
監査計画に基づき、予備調査→本調査→評価・結論
3.監査の実施
3.1監査証拠の入手と評価
 監査結果を裏付ける十分かつ適切な監査証拠を入手する
3.2監査調書の作成と保存
 監査の結論に至った過程がわかるように秩序整然と記録する
4.監査業務の体制

Ⅴ.報告基準(監査報告に係る留意事項と報告書の記載方式を規定)
1.監査報告書の提出と開示
2.監査報告の根拠
合理的な根拠に基づく必要がある。
3.監査報告書の記載事項
 監査の対象、監査の概要、保証意見又は助言意見、
 制約又は除外事項、指摘事項、改善勧告、その他特記すべき事項
 
5.監査報告に基づく改善指導(フォローアップ)
監査結果に基づいて所要の
措置が講じられるように、適切な指導性を発揮する。

システム監査基準(全文)
平成16年10月8日改訂 ※経済産業書が発表したもの
    Ⅰ.前文
     今日、組織体の情報システムは、経営戦略を実現するための組織体の重要なインフラストラクチャとなっている。さらに、それぞれの情報システムがネットワーク化されることにより、社会の重要なインフラストラクチャとなってきている。一方、情報システムはますます多様化、複雑化し、それに伴い様々なリスクが顕在化してきている。また、情報システムに係わる利害関係者も組織体内にとどまらず、社会へと広がっている。従って、このような情報システムにまつわるリスクを適切にコントロールすることが組織体における重要な経営課題となっている。システム監査は、組織体の情報システムにまつわるリスクに対するコントロールが適切に整備・運用されていることを担保するための有効な手段となる。また、システム監査の実施は、組織体のITガバナンスの実現に寄与することができ、利害関係者に対する説明責任を果たすことにつながる。
     組織体が情報システムにまつわるリスクに対するコントロールを適切に整備・運用する目的は、以下の通りである。

     ・情報システムが、組織体の経営方針及び戦略目標の実現に貢献するため
     ・情報システムが、組織体の目的を実現するように安全、有効かつ効率的に機能するため
     ・情報システムが、内部又は外部に報告する情報の信頼性を保つように機能するため
     ・情報システムが、関連法令、契約又は内部規程等に準拠するようにするため

     システム監査基準は、システム監査業務の品質を確保し、有効かつ効率的に監査を実施することを目的とした監査人の行為規範である。本監査基準は、監査人としての適格性及び監査業務上の遵守事項を規定する「一般基準」、監査計画の立案及び監査手続の適用方法を中心に監査実施上に枠組みを規定する「実施基準」、監査報告に係わる留意事項と監査報告書の記載方式を規定する「報告基準」からなっている。
     システム監査基準は、組織体の内部監査部門等が実施するシステム監査だけでなく、組織体の外部者に監査を依頼するシステム監査においても利用できる。さらに、本基準は、情報システムに保証を付与することを目的とした監査であっても、情報システムの改善のための助言を行うことを目的とした監査であっても利用できる。

     システム監査の実施に当たっては、組織体における情報システムにまつわるリスクに対するコントロールの適否を判断するための尺度が必要である。システム監査は、本監査基準の姉妹編であるシステム管理基準を監査上の判断の尺度として用い、監査対象がシステム管理基準に準拠しているかどうかという視点で行われることを原則とする。しかし、システム管理基準に基づく監査に限らず、各種目的あるいは各種形態をもって実施されるシステム監査においても本監査基準を活用することができる。

     システム監査基準は、昭和60年(1985年)1月に策定されたもので、その後平成8年(1996年)1月に改訂され、今回は2度目の改訂である。今回の改訂は、昨年4月に創設された情報セキュリティ監査基準との整合性を図り、従来の実施基準の主要部分を抜き出し、システム管理基準として独立させ、それぞれに大幅な加筆・修正を行ったものである。

    Ⅱ.システム監査の目的
     システム監査の目的は、組織体の情報システムにまつわるリスクに対するコントロールリスクアセスメントに基づいて適切に整備・運用されているかを、独立かつ専門的な立場のシステム監査人が検証又は評価することによって、保証を与えあるいは助言を行い、もってITガバナンスの実現に寄与することにある。


    Ⅲ.一般基準
    1.目的、権限と責任
     システム監査を実施する目的及び対象範囲、並びにシステム監査人の権限と責任は、文書化された規程、または契約書等により明確に定められていなければならない。

    2.独立性、客観性と職業倫理
    2.1 外観上の独立性
     システム監査人は、システム監査を客観的に実施するために、監査対象から独立していなければならない。監査の目的によっては、被監査主体と身分上、密接な利害関係を有することがあってはならない。

    2.2 精神上の独立性
     システム監査人は、システム監査の実施に当たり、偏向を排し、常に公正かつ客観的に監査判断を行わなければならない。

    2.3 職業倫理と誠実性
     システム監査人は、職業倫理に従い、誠実に業務を実施しなければならない。

    3.専門能力
     システム監査人は、適切な教育と実務経験を通じて、専門職としての知識及び技能を保持しなければならない。

    4.業務上の義務
    4.1 注意義務
     システム監査人は、専門職としての相当な注意をもって業務を実施しなければならない。

    4.2 守秘義務
     システム監査人は、監査の業務上知り得た秘密を正当な理由なく他に開示し、又は、自らの利益のために利用してはならない。

    5.品質管理
     システム監査人は、監査結果の適正性を確保するために、適切な品質管理を行わなければならない。

    Ⅳ.実施基準
    1.監査計画の立案
     システム監査人は、実施するシステム監査の目的を有効かつ効率的に達成するために、監査手続の内容、時期及び範囲等について、適切な監査計画を立案しなければならない。監査計画は、事情に応じて適時に修正できるように弾力的に運用しなければならない。

    2.監査の手順
     システム監査は、監査計画に基づき、予備調査、本調査及び評価・結論の手順により実施しなければならない。

    3.監査の実施
    3.1 監査証拠の入手と評価
     システム監査人は適切かつ慎重に監査手続を実施し、保証又は助言についての監査結果を裏付けるのに十分かつ適切な監査証拠を入手し、評価しなければならない。

     3.2 監査調書の作成と保存
    システム監査人は、実施した監査手続の結果とその関連資料を、監査調書として作成しなければならない。監査調書は、監査結果の裏付けとなるため、監査の結論に至った過程がわかるように秩序整然と記録し、適切な方法によって保存しなければならない。

    4.監査業務の体制
     システム監査人は、システム監査の目的が有効かつ効率的に達成されるように、適切な監査体制を整え、監査計画の立案から監査報告書の提出及び改善指導(フォローアップ)までの監査業務の全体を管理しなければならない。

    5.他の専門職の利用
     システム監査人は、システム監査の目的達成上、必要かつ適切と判断される場合には、他の専門職による支援を考慮しなければならない。他の専門職による支援を仰ぐ場合であっても、利用の範囲、方法、及び結果の判断等は、システム監査人の責任において行われなければならない。

    6.情報セキュリティ監査
    情報セキュリティ監査については、原則として、情報セキュリティ管理基準を活用することが望ましい。


    Ⅴ.報告基準
    1.監査報告書の提出と開示
     システム監査人は、実施した監査の目的に応じた適切な形式の監査報告書を作成し、遅滞なく監査の依頼者に提出しなければならない。監査報告書の外部への開示が必要とされる場合には、システム監査人は、監査の依頼者と慎重に協議の上で開示方法等を考慮しなければならない。

    2.監査報告の根拠
     システム監査人が作成した監査報告書は、監査証拠に裏付けられた合理的な根拠に基づくものでなければならない。

    3.監査報告書の記載事項
     監査報告書には、実施した監査の対象、実施した監査の概要、保証意見又は助言意見、制約又は除外事項、指摘事項、改善勧告、その他特記すべき事項について、証拠との関係を示し、システム監査人が監査の目的に応じて必要と判断した事項を明瞭に記載しなければならない。

    4.監査報告についての責任
     システム監査人は、監査報告書の記載事項について、その責任を負わなければならない。

    5.監査報告に基づく改善指導(フォローアップ)
     システム監査人は、監査の結果に基づいて所要の措置が講じられるよう、適切な指導性を発揮しなければならない。

    システム監査の流れをザックリ言うと、以下になります。
    ①予備調査
     被監査部門への協力要請などの監査の実施準備をした後、予備調査を行います。予備調査では、 被監査部門から事前に入手した資料を閲覧して,監査対象の実態を把握します。
    ②本調査
    現状把握の結果を踏まえ、どのように監査を実施するのかという監査手続きを検討します。その後、本調査として実際の監査を行います。
    監査手続きを行う手法として、例えば以下があります。
    ・システム管理者にチェックリストを基に運用状況をヒアリング
    ・設計書や運用報告書などの資料の閲覧
    ・実態を知るために、現場に出向いて実機設定やログなどを観察 
    ③監査報告
    監査を行った結果の総合評価や、指摘事項、改善勧告などの監査意見をまとめます。その結果を踏まえ、システム監査人は、監査報告書を作成し、監査の依頼者に提出します。監査報告書には、指摘事項や改善勧告を含みます。
    ④フォローアップ
    一定期間後に改善勧告に対する実施状況を確認し、改善指導を行います。

    では、試験センターが発表するシラバスを基に、「システム監査の実施」について具体的に述べます。

    ■2-1 実施準備
    ・個別計画書の再確認
    ・被監査部門への協力要請

    ■2-2 予備調査
    (1)関連資料の収集、インタビューなどによる情報収集
    30c7ee19
    なぜこんな面倒なことをするの?

    いきなり本調査してはいけないのですか?


    医者1
    それは非効率です。
    病院でも患者さんに問診票を書いてもらいますよね。

    問診票があれば、どこが悪いかをある程度把握できますが、ないとすれば顔、目、耳、鼻、手、足、肺、心臓などと全てを順番に検査するという非効率な検査になります。
    具体的には、文書の収集やインタビュー、チェックリスト(問診票のようなもの)の記入依頼と回収などを行います。

    (2)現状把握
      収集した情報を基に、現状の問題点を把握します。

    ■2-3 監査手続書の作成現状把握の結果を踏まえて、具体的な監査手続を検討し、監査手順書を作成します。

    ■2-4 本調査
     (1)現地調査
     (2)インタビュー
     (3)ドキュメントレビュー
     (4)その他のシステム監査技法
      システム監査技法には長所・短所があるので、状況に応じた監査技法を活用します。

    kansa 
    ■2-5 実施結果の記録(監査調書の作成)監査を行った都度(=監査手続きを行った都度)、その内容を記録します。
    これが監査調書(Working Paper)になります。

    ■2-6 監査意見の明確化(監査判断の形成)総合評価、指摘事項、改善勧告の原案をまとめます。

    ■2-7 評価・結論の総合検討

    ■2-8 監査報告書案の作成監査の結果を定められた様式で取りまとめます。
    あくまでも「案」です。

    1.内部統制とは
    内部統制の反対は何でしょう。・・・外部統制です。
    外部統制は、外部(法律や行政指導)による統制ですが、内部統制は自ら統制する活動です。

    金融庁のサイトから定義を引用します。
    1.内部統制の定義
     内部統制とは、基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守並びに資産の保全の4つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内のすべての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング(監視活動)及びIT(情報技術)への対応の6つの基本的要素から構成される。

    http://www.fsa.go.jp/singi/singi_kigyou/tosin/20070215.pdf より引用)

    c0c762ed 

    よくわかりませんね
    かなりざっくりですが、内部統制とは、不正が無いように、きちんとしたチェック体制を取ることと考えておけばいいでしょう。

    2.内部統制とJ-SOX法
    内部統制はこれまで、法的に義務付けられていませんでした。しかし、大手上場企業の不正が発覚したことにより、アメリカのSOX法サーベンス・オクスリー法)を参考にJ-SOX法金融商品取引法の一部)が2008年度決算から適用されました。
    過去問では、「2008年4月1日以後に開始する事業年度からは,財務報告の信頼性の確保を目的に,上場会社に対して内部統制報告書の作成が義務付けられた(H23年秋SC_PM1より)」とあります。

    過去問(H26年IP秋問43)を見てみましょう
    内部統制の整備と運用に関する基本方針に基づいて,内部統制を整備,運用する役割と責任を有している人又は組織として,適切なものはどれか。
    ア 監査役
    イ 経営者
    ウ 取締役会
    エ 内部監査人
    正解はイの経営者です。内部統制報告書も、経営者が責任をもって評価し、報告書を内閣総理大臣に提出する必要があります。

    3.内部統制の実現方法
    応用情報技術者シラバスには、内部統制に関して次のように述べられています。

    (1)内部統制
    内部統制とは,健全かつ効率的な組織運営のための体制を企業などが自ら構築し運用する仕組みであり,実現には業務プロセスの明確化,職務分掌,実施ルールの設定,チェック体制の確立が必要であることを理解する。

    ここにありますように、「業務プロセスの明確化」「職務分掌」「実施ルールの設定」「チェック体制の確立」などが必要です。
    職務分掌に関しては、難しい言葉なので、過去問から言葉を引用します。過去問(H27年春IP問33)では、職務分掌に関して、「内部統制の観点から,担当者間で相互けん制を働かせることで,業務における不正や誤りが発生するリスクを減らすために,担当者の役割を決めること」と述べられています。
    このとき、役割を明確にするだけでなく、実施者とチェック者を分けることが大事です。そうすれば、チェック体制が確立できます。

    過去問(H26年春AP午前)を見てみましょう。
    問60 営業債権管理業務に関する内部統制のうち,適切なものはどれか。
    ア 売掛金回収条件の設定は,営業部門ではなく,審査部門が行っている。
    イ 売掛金の消込み入力と承認処理は,販売を担当した営業部門が行っている。
    ウ 顧客ごとの与信限度の決定は,審査部門ではなく,営業部門の責任者が行ってい
     る。
    エ 値引き又は割戻しの処理は,取引先の実態を熟知している営業部門の担当者が行
     っている。
    正解はアです。ポイントは、営業部門ではなく,審査部門という他部門がチェックを行っていることです。イ、ウ、エのように、自部門でチェックを行えば、不正を隠す可能性があります。

    4.内部統制の6つの基本的要素
    内部統制の定義にありますように、「統制環境」「リスクの評価と対応」「統制活動」「情報と伝達」「モニタリング(監視活動)」「IT(情報技術)への対応」が内部統制における基本要素です。

    細かく理解をする必要はありません。イメージだけつかんでおけば十分です。たとえば、「統制活動」の一つに、先ほど述べた「職務分掌」が含まれています。

    5.ITへの対応
    (1)概要
    先の6つ目にある「ITへの対応」に関しては、重要なので補足します。
    「財務報告に係る内部統制の評価及び監査の基準のあり方について」の資料(http://www.fsa.go.jp/news/newsj/17/singi/f-20051208-2.pdf)には、次の記載があります。
    (6) ITへの対応
    ITへの対応とは、組織目標を達成するために予め適切な方針及び手続を定め、それを踏まえて、業務の実施において組織の内外のITに対し適切に対応することをいう。
    ITへの対応は、内部統制の他の基本的要素と必ずしも独立に存在するものではないが、組織の業務内容がITに大きく依存している場合や組織の情報システムがITを高度に取り入れている場合等には、内部統制の目的を達成するために不可欠の要素として、内部統制の有効性に係る判断の規準となる。
    ITへの対応は、IT環境への対応とITの利用及び統制からなる。

    (2)IT統制
    「ITへの対応は、IT環境への対応とITの利用及び統制からなる。」とありました。この中のIT統制に関して、もう少し詳しく解説します。
    まず、IT統制は、IT全社的統制、IT全般統制、IT業務処理統制の3つに分けられます。
    「システム管理基準 追補版(財務報告に係るIT 統制ガイダンス)」を詳しく見ましょう。
    http://www.meti.go.jp/policy/netsecurity/docs/secgov/2007_ZaimuHoukokuNiKakaruITTouseiGuidance.pdf

    この資料には、IT統制に関して以下の記載があります。
    ----------------------------------------
    IT 業務処理統制は、アプリケーション・システムにおいて処理される財務情報の信頼性に直接係ることになる。また、IT 基盤が、これらのアプリケーション・システムが稼動するために必要な情報システムのサポートを行う。このIT 基盤におけるIT 業務処理統制が有効に機能する環境を保証するための統制活動がIT 全般統制であり、財務情報に係る信頼性の基礎となる。さらに、アプリケーション・システムとIT 基盤全体を計画性と整合性を伴って統制する役割を持つのが、IT 全社的統制である。IT 全社的統制は、組織におけるIT 全体に係るものであり、IT 全般統制とIT 業務処理統制の基盤となる。これらの関係を図表Ⅱ.1-3に示す。
    ----------------------------------------

    図表Ⅱ.1-3は以下です。
    it

    ではここで、過去問を見て見ましょう。
    ----------------------------------------
    ■H26春AU午前2
    問10 金融庁の“財務報告に係る内部統制の評価及び監査の基準”におけるIT業務処理統制に該当するものはどれか。
    ア 外部委託に関する契約の管理
    イ システムの運用管理
    ウ システムの開発・保守に係る管理
    エ 利用部門によるエラーデータの修正と再処理
    ----------------------------------------
    上の図を見れば明らかですね。IT業務処理統制に該当するのは、エです。それ以外のア、イ、ウは、IT全般統制に該当します。

    エディットバリデーションチェック(edit validation check) 「validation」は「検証」などの意味を持ちます。

    過去問(H27春AP午前問57)を見てみましょう。
    問57 インプットコントロールの監査で,エディットバリデーションチェックが正しく機能しているかどうかの検証方法として,適切なものはどれか。
    ア 許可された担当者以外はログインできないことを試行する。
    イ 実際に例外データや異常データの入力を行う。
    ウ 入力原票の承認印を確認する。
    エ 入力対象データの件数とプルーフリスト上の合計件数を照合する。
    正解はイ


    過去問(H24秋AP午前問59)を見てみましょう。
    問59 業務システムの利用登録をするために,利用者登録フォーム画面(図1)から登録処理を行ったところ,エラー画面(図2)が表示され,再入力を求められた。このコントロールはどれか。
    59
    ア アクセスコントロール
    イ エディットバリデーションチェツク
    ウ コントロールトータルチェツク
    エ プルーフリスト
    正解はイ

    “ITサービス”とは何でしょうか。文字どおりITを使ったサービスのことです。例えば,ISP(インターネットサービスプロバイダ)にDNSサーバやメールサーバの運用管理をアウトソーシングしている場合,サービス提供者であるISPからITサービスを受けていることになります。

    では,ITサービスマネジメントとは何でしょうか。マネジメントは“管理”という意味なので,ざっくりいうと、ITサービスを適切に管理するということになります。

    応用情報技術者シラバスでは、試験センターのシラバスで,“サービスマネジメントの目的と考え方”が整理されているので確認してください。
    サービスマネジメントは,サービスの要求事項を満たし,サービスの設計,移行,提供及び改善のために,サービス提供者の活動及び資源を,指揮し,管理する,一連の能力及びプロセスであることを理解する。

    IT サービスマネジメントフレームワークとして、ITIL ( Information TechnologyInfrastructure Library)があります。

    1.ITIL(アイティル)とは
    ITIL(Information Technology Infrastructure Library)を直訳すると「ITの基盤となる図書」となります。Library(図書)といわれるだけあって,ITILv2では7冊の本にまとめられ,ITILv3では5冊の本にまとめられています。

    ITILはイギリス発祥のITサービスまた又はシステム管理におけるベストプラクティスであり,日本を含めて世界でのデファクトスタンダードといえます。ITサービスマネージャ試験は,ITサービスのベストプラクティスであるITILに沿った試験です。よって,ITILはぜひとも理解したい内容です。

    ITILは規格ではなく,単なるベストプラクティスでした。
    そこで,英国規格協会によってBS15000として規格化され,その後,日本ではJIS Q 20000として規格化されました。JIS(Japanese Industrial Standards)は,“Japanese”と名前が付いているように日本の規格であり,JIS Q 20000-1(第1部 仕様)とJIS Q 20000-2(第2部 実践のための規範)に分かれています。
    JIS Q 20000-1は、サービス事業者に対するサービスマネジメントシステムの要求事項です。サービスマネジメントのあるべき論と考えてもいいでしょう。

    2.「サービスサポート」と「サービスデリバリ」
    ITILの中で中心重要になるのが「サービスサポート」と「サービスデリバリ」です。サービスサポートは短期的(日常的)なITサービス活動で,サービスデリバリは中長期的なITサービス活動と考えることができます。
    サービスサポートは,“サポート”という言葉のとおり,ユーザへのサポートを行い,サービスデスク(ヘルプデスク)を単一の窓口として,利用者からの問合せやインシデント(障害)対応などを行います。サービスデリバリでは,中長期的にITサービスの維持・改善活動を行い,例えばITサービス継続性管理では,災害などに備えた事業継続性を管理します。

    (1)サービスサポート
    ・サービスデスク
    ・インシデント管理
    ・問題管理
    ・構成管理
    ・変更管理
    ・リリース管理

    (2)サービスデリバリ
    ・サービスレベル管理
    ・ITサービス財務管理
    ・キャパシティ管理
    ・ITサービス継続性管理
    ・可用性管理

    ITパスポートのシラバスには「IT サービスマネジメントでは,提供するサービスの品質と範囲を明文化し,サービスの委託者との合意に基づいて運用管理するために,サービスレベル合意書(SLA:ServiceLevel Agreement)を結ぶことを理解する。」とあります。

    SLAとは
    ITサービスマネジメントを行う中で,SLAは重要なキーワードです。SLA(Service Level Agreement)を直訳すると,“サービス基準の合意”となります。サービス基準というのは,前述したように,「オンライン業務の月間稼働率」,「障害発生時の復旧時間」などで,この基準に合意することをいいます。合意する主体はサービス提供者と顧客(ユーザ)です。

    過去問(H20秋NW午前)を見てみましょう。
    問18 SLAを説明したものはどれか。
    ア ITサービスマネジメントのベストプラクティスを集めたフレームワーク
    イ 開発から保守までのソフトウェアライフサイクルプロセス
    ウ サービスの品質に関する利用者と提供者間の合意
    エ 品質マネジメントシステムに関する国際規格
    アは、ITIL(IT Infrastructure Library)についての説明です。
    イは、SLCP(Software Life Cycle Process)についての説明です。
    ウは正解です。SLA(Service Level Agreement)は利用者と提供者間でのサービスの品質に関する合意です。
    エは、ISO 9000シリーズについての説明です。

    【解答】ウ

    過去問(H26秋AP午前)を見てみましょう。
    問55 SLAに記載する内容として,適切なものはどれか。
    ア サービス及びサービス目標を特定した,サービス提供者と顧客との間の合意事項
    イ サービス提供者が提供する全てのサービスの特徴,構成要素,料金
    ウ サービスデスクなどの内部グループとサービス提供者との間の合意事項
    エ 利用者から出されたITサービスに対する業務要件
    正解は、アです。

    なぜSLAが必要なのか
    ① 顧客(ユーザ)のメリット
    顧客(ユーザ)のメリットは,高い水準のITサービスを安定的に受けられることです。インターネット回線のベストエフォート型を例にして説明します。ベストエフォート型のインターネット回線は,回線が空いていれば高速な通信が可能であり,価格も安くなります。しかし,利用者が多くて混雑していると速度は極端に遅くなる場合があり,故障時の復旧時間もSLAとして定められていません。基幹業務などの安定した品質が必要な業務においては,通信品質がバラバラでは業務に支障をきたします。よって,基幹業務においては,ベストエフォート型ではなく,コストが高くてもSLAが定められたサービスを契約することが多いでしょう。高い水準(このケースでは業務に影響が出ない水準)のITサービスを安定的に受けたいからです。

    ② サービス提供者側のメリット
    サービス提供者側のメリットは,サービス基準を定めることで,責任範囲が明確になることです。もしSLAがなければ,顧客(ユーザ)から,「なんとなく応答時間が遅いから改善して」という要求に対応する必要も出てくるでしょう。どこまで改善すればよいのかの基準がなければ,サービス提供者側の負担は大きなものになります。責任範囲が明確になることで,際限なく費用と稼働をかけることを減らすことができます。

    SLAの具体例
    ① 平成20年度 SM 午後Ⅰ 問1より抜粋

    項番SLA項目内容サービスレベル値
    1可用性オンライン業務の月間稼働率99%以上
    2オンラインレスポンスデータ入力の応答時間遵守率5秒以内の遵守率90%以上
    3サービス開始時刻サービス開始時刻の遵守率遅延時間30分以内の遵守率100%
    4運用変更通知利用部門への通知時限運用変更の60分前

    SaaS向けSLAガイドライン(平成20年1月21日 経済産業省)より抜粋
    http://www.meti.go.jp/press/20080121004/03_guide_line_set.pdf

    サービスレベル項目例規定内容設定例
    平均復旧時間障害発生から修理完了までの平均時間1時間以内(基幹業務)
    12時間以内(上記以外)
    障害通知時間異常検出後に指定された連絡先に通知するまでの時間15分以内(基幹業務)
    2時間以内(上記以外)
    バッチ処理時間バッチ処理(一括処理)の応答時間4時間以内

    論文を書くにあたって
    SLAに関しては、「合意している」という点が重要である。
    顧客はともかく、サービス提供側が合意しているとなれば、SLAを遵守できる実現可能性が明確になっていなければならない。

    午前問題で出題されても、この点を間違える人はいないであろう。しかし、午後Ⅱの論文では、間違える可能性があるので注意しておく。

    例えば、以下のような記述はNGである。
    ・顧客にNOと言えず、しぶしぶ合意した。
    ・顧客の要望が「24時間365日の可用性」であったため、合意した。実際には、二重化されておらず、実現はほぼ不可能。だが、顧客もそれを分かっているので、それほど厳しく言われることもない。

    サービスマネジメントでは、いくつかのプロセスがあります。
    応用情報技術者試験のシラバスのシラバスから、各プロセスの概要を抜粋します。

    プロセス 概要(シラバスより抜粋)
    (1) サービスレベル管理 SLM(Service Level Management:サービスレベル管理)は,顧客とサービス提供者の間でSLA を締結し,サービスレベルを定義,合意及び管理することを理解する。また,
    PDCA マネジメントサイクルによってサービスの維持,向上を図る一連の活動であること,サービスレベルの監視結果に応じてSLA やプロセスを見直すことを理解する。
    (2) サービスの報告 十分な情報に基づいた意思決定及び効果的なコミュニケーションを促進するために,顧客との合意に基づいて,適時に信頼できる正確な報告書を作成することを理解する。
    (3) サービス継続及び可用性管理 平常な状況とサービス中断後の状況の両方の下で,顧客と合意したサービス継続性及び可用性についての要求事項を確実に実施するための活動を理解する。
    (4) サービスの予算業務及び会計業務 サービス提供費用の予算を計画・管理する予算業務を行う。会計業務として会計を行い,間接費の配賦及び直接費の割当てなどを行う。これらの活動によって,財務状況を効率的に管理することを理解する。
    (5) キャパシティ管理 キャパシティ管理は,容量・能力などの必要なキャパシティを管理し,最適な費用で,現在及び将来の合意された需要を満たすために,サービス提供者が十分な能力をもっていることを確実にする一連の活動であることを理解する。
    (6) 情報セキュリティ管理 情報資産の機密性,完全性,アクセス性を保つ,情報セキュリティ方針の要求事項を満たす,情報セキュリティに関連するリスクを管理するなどのために,情報セキュリティ管理策を導入し,運用することを理解する。
    (7) 事業関係管理 サービス提供者と顧客との間に良好な関係を確立するために,サービスのパフォーマンスレビューの実施,苦情の処理,顧客満足度の測定・分析・レビューなどの活動を行うことを理解する。
    (8) 供給者管理 サービス提供者が,サービスマネジメントプロセスの導入及び運用のために供給者を用いる場合の管理活動について,理解する。また,サービス提供者組織の一部である内部グループと結ぶ運用レベル合意書を理解する。
    (9) インシデント及びサービス要求管理 インシデント及びサービス要求管理は,顧客と合意したサービスを可能な限り迅速に回復するためにインシデントの対応を行う,又はサービス要求の対応を行うためのプロセスであることを理解する。また,重大なインシデントについては,定義を文書化し顧客と合意することを理解する。
    (10) 問題管理 問題管理は,問題の根本原因を突き止め,インシデントの再発防止のための解決策を提示する一連の活動であることを理解する。
    (11) 構成管理 構成管理は,サービスを構成するハードウェア,ソフトウェア,ドキュメントなどのCI(Configuration Item:構成品目)に関する情報を定義し,特定したCI をCMDB に記録するなど,正確な構成情報を維持する一連の活動であることを理解する。
    (12) 変更管理 変更管理は,全ての変更を制御された方法で,評価,変更要求の受入れ決定,変更スケジュールに従った変更の展開,実施後のレビューを確実に行い,リスクの回避,効率的な変更管理プロセス及び手順の実施などを行う一連の活動であること,また,変更によるサービスへの影響を最小限に抑えることを理解する。
    (13) リリース及び展開管理 リリース及び展開管理は,変更管理で承認された変更をリリースとして稼働環境に展開するプロセスであることを理解する。また,新たな版の導入の計画から実際の導入,万一リリース展開に失敗した場合に元に戻す作業などを行う一連の活動があって,構成管理及び変更管理との連携が必要であることを理解する。

    ■ITIL 2011 editionのサービスライフサイクル
    ITILv2では、サービスデリバリとサービスサポートの大きく2つに分けられていました。(個人的にはわかりやすかったと思います)。
    ITIL 2011 editionでは、5つのサービスライフサイクルに分かれます。
    内容は、過去問(H30秋午前1共通問20)をもとに整理します(といっても、内容の転記)

    ①サービスストラテジ→サービス戦略
    ITサービス及びITサービスマネジメントに対する全体的な戦略を確立する。
    プロセス:サービスの予算業務及び会計業務、事業関係管理など

    ②サービスデザイン→サービスの設計
    事業要件を取り入れ,事業が求める品質,信頼性及び柔軟性に応えるサービスと,それを支えるプラクティス及び管理ツールを作り出す。
    プロセス:サービス継続及び可用性管理、キャパシティ管理、サービスレベル管理、情報セキュリティ管理、供給者管理など

    ③サービストランジッション→サービスの移行や変更
    サービス及びサービス変更を運用に利用できるようにするために,前の段階の成果を受け取り,事業のニーズを満たすかどうかをテストし,本番環境に展開する。
    プロセス:構成管理、変更管理、リリース及び展開管理

    ④サービスオペレーション→サービスの運用
    顧客とサービス提供者にとっての価値を確保できるように,ITサービスを効果的かつ効率的に提供しサポートする。
    プロセス:インシデント管理、問題管理

    ⑤継続的サービス改善
    ITサービスマネジメントプロセスとITサービスに対する改善の管理を責務とし,効率性,有効性及び費用対効果を向上させるために,サービス提供者のパフォーマンスを継続的に測定して,プロセス,  ITサービス,インフラストラクチヤに改善を加える。


    過去問(H25春AP午前問56)を見てみましょう。
    問56 (1)~(4)はある障害の発生から本格的な対応までの一連の活動である。(1)~(4)の各活動とそれに対応するITILV3の管理プロセスの組合せのうち,適切なものはどれか。

    (1)利用者からサービスデスクに“特定の入力操作が拒否される”という連絡があったので,別の入力操作による回避方法を利用者に伝えた。
    (2)原因を開発チームで追究した結果,アプリケーションプログラムに不具合があることが分かった。
    (3)原因となったアプリケーションプログラムの不具合を改修する必要があるのかどうか,改修した場合に不具合箇所以外に影響が出る心配はないかどうかについて,関係者を集めて確認し,改修することを決定した。
    (4)改修したアプリケーションプログラムの稼働環境への適用については,利用者への周知,適用手順及び失敗時の切戻し手順の確認など,十分に事前準備を行った。

          (1)      (2)      (3)      (4)
    ア インシデント管理 問題管理 変更管理 リリース管理及び展開管理
    イ インシデント管理 問題管理 リリース管理及び展開管理 変更管理
    ウ 問題管理 インシデント管理 変更管理 リリース管理及び展開管理
    エ 問題管理 インシデント管理 リリース管理及び展開管理 変更管理
    正解はアです。

    1.SLM(サービスレベル管理)とは
    SLM(Service Level Management:サービスレベル管理)とは,合意したSLAを遵守するための継続的なマネジメント活動です。試験センターのシラバスには,SLMに関して次のような説明があります。
    ① SLM
     SLM(Service Level Management:サービスレベル管理)は,サービスの利用者とサービスの提供者の間でSLAを締結し,PDCAマネジメントサイクルによってサービスの維持,向上を図る一連の活動であること,モニタリングの結果に応じてSLA やプロセスを見直すことを理解する。また,OLA(Operational Level Agreement:運用レベル合意書)を理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)
    ※運用レベル合意書(OLA:Operational Level Agreement )に関して過去問(H27秋SM午前2問8)では、「ITサービスマネジメントにおいて,サービス提供者が内部グループと取り交わす合意」とあります。
    SLAが顧客とサービス提供者との合意であるのに対し、OLAはサービス提供者の内部での合意になります。また、サービス提供者が外部のベンダと締結するのは「基盤となる契約(UC:Underpinning Contract)」です。

    2.SLMのプロセス
    SLAとSLMについては,過去問で具体的に整理されているので紹介します。過去問に即して理解することは,試験センターの考え方と方向性を合わせることになり,かつ効果的な学習につながります。
    平成20年度 午後Ⅱ 問1
    問1  SLAに基づく情報システムの運用について
     
    ITを利用したサービスをデータセンタなどから提供する場合に,情報システムの運用を顧客や利用部門との間で合意されたSLAに基づいて行うことが多くなってきた。
    SLAを遵守したサービスを提供することはシステム管理エンジニアの重要な職務であり,そのためには次のようなSLA遵守のためのプロセスを確実に実行する必要がある。
     (1) サービスレベルの継続的なモニタリングとモニタリング結果の蓄積
     (2) サービスレベルの傾向分析と評価
     (3) サービスレベルが悪化した場合の原因究明と対策実施
     (4) 顧客や利用部門へのSLA遵守状況などの定期的な報告
    SLMの活動はSLA締結のプロセスと上記の(1)~(4)を加えたものそのものです。SLAを設定したらそれで終わりではなく,継続的にモニタリングを行います。そして,基準値とかい離していないかを確認し,SLAを守れないような傾向があればそれを分析します。サービスレベルが悪化した場合にはその原因をつかみ,対策を実施します。対策を実施するだけではなく,SLAは「利用部門との合意」で成り立っているので,定期的な報告を行います。

    1.プロジェクトとは何か
    プロジェクトと言えば、中島みゆきさんの「地上の星」が流れるプロジェクトXを思い出します。NHKのこのドキュメンタリーでは、黒部ダム、東京タワー、自動改札機などを作り上げるプロジェクトの様子が生々しく映し出されています。それらのように、明確な目標に向かってチームで進めていくのがプロジェクトです。

    IPA応用情報技術者試験シラバスでは、以下のように述べられています。
    プロジェクトは,目的を達成するために実施する有期的な活動であり,プロジェクトには開始日と終了日があることを理解する。
    https://www.jitec.ipa.go.jp/1_13download/syllabus_ap_ver3_0.pdf

    ですから、長年システムを運用しており、今後も続く・・・というのは、期間が定められていないのでプロジェクトではありません。

    【参考】
    プロジェクトマネージャ試験のシラバスにはプロジェクトの特性として、「有期性,独自性,段階的詳細化」の3つが記載されています。プロジェクトは、ルーティン業務ではありません。目指すべき目的を達成するための、期限がある活動です。
    ※段階的詳細化とは、プロジェクトの進行とともに詳細が決まっていくということです。大きなプロジェクトの場合、最初は大枠しか決まりませんよね。

    2.プロジェクトマネジメントとは
    プロジェクトは特に大規模なものになれば、参加するメンバーの数も、期間も長くなります。なにも管理せずに進めていくと、工期内に完成しないとか、品質が悪いなどの問題が発生します。どこで、プロジェクトを管理するプロジェクトマネジメントです。
    応用情報技術者試験シラバスの言葉を借りると、「プロジェクトを円滑に推進して目的を達成するために,計画する(Plan),計画に沿って作業を進める(Do),計画と実績の差異を検証する(Check),差異の原因へ対処する(Act)のPDCA マネジメントサイクルで管理すること」です。

    【参考】
    IPAのITパスポートのシラバスには、プロジェクトマネジメントのプロセスに関して次のように述べられています。
    プロジェクトを立ち上げ,計画に基づいてプロジェクトを進め,レビューなどを通じて進捗,コスト,品質及び人的資源をコントロールし,目標を達成する流れであることを理解する。

    3.プロジェクトマネージャ
    過去問(H24春IP問48)では、「プロジェクトの立上げ時に考慮すべき事項」として、「プロジェクト立上げに当たって,プロジェクトマネージャを任命し責任や権限を明確にしておく」とあります。このように、プロジェクト立ち上げ時には、まずプロジェクトマネージャを決めます。そして、プロジェクトマネージャがプロジェクトのメンバーを統括し、プロジェクトの指揮をとります。
    情報セキュリティマネジメント試験を目指す剣持成子_6 

    プロジェクトマネージャとは、野球部でいうと、キャプテンですか?
    いや、監督です。キャプテンは自らプレーをしますが、監督はプレーをしません。(ヤクルトの古田選手や谷繁選手は例外です)
    プロジェクトマネージャの力量で、プロジェクトの成否が大きく左右されます。よって、マネジメントに専念するべきでしょう。

    1.サービスデスク
    サービスデスクは,ユーザからの問合せ窓口である。ヘルプデスクやカスタマーサポート,コールセンタという言葉のほうが馴染み深いかもしれない。

    また,試験センターからのシラバスでは次のような説明がある。
    サービスデスク(ヘルプデスク)
     サービスデスクは,サービスの利用者からの問合せに対して単一の窓口機能を提供し,適切な部署への引継ぎ,対応結果の記録,記録の管理などを行う一連の活動であることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    サービスデスクには次の3つの形態があります。
    ①ローカルサービスデスク
     拠点ごとにサービスデスクを設置する形態です。過去問(H27秋FE問55)では「サービスデスクを利用者の近くに配置することによって,言語や文化が異なる利用者への対応,専用要員によるVIP対応などができる」と述べられています。
    ②中央(セントラル)サービスデスク
    複数拠点を統括し、1拠点で集中的に問い合わせを受け付ける形態です。過去問(H27秋FE問55不正解選択肢)では「サービスデスクを1拠点又は少数の場所に集中することによって,サービス要員を効率的に配置したり,大量のコールに対応したりすることができる」と述べられています。
    ③バーチャルサービスデスク
    物理的に分散していても、ユーザから見ると仮想的(バーチャル)に1カ所でサポートしているかのように思わせる形態です。過去問(H27秋FE問55不正解選択肢)では「サービス要員は複数の地域や部門に分散しているが,通信技術を利用することによって,単一のサービスデスクであるかのようにサービスが提供できる。」と述べられています。

    2.インシデント管理

    インシデント管理は障害管理と置き換えると分かりやすい。ただ,厳密には“インシデント”という概念が“障害”とは多少異なるので注意する。
    また,試験センターからのシラバスでは次のような説明がある。
    インシデント管理(障害管理)
     インシデント管理は,インシデントの検知から解決までの一連のプロセスであり,迅速にサービスを復旧させ,業務への影響を最小限に抑えることを目的とする一連の活動であることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    過去問(H22春FE午前)をみてみましょう。
    問54 ITサービスマネジメントにおいて,インシデント管理の対象となるものはどれか。
    ア ITサービスの新人への教育依頼
    イ ITサービスやシステムの機能,使い方に対する問合せ
    ウ アプリケーションの応答の大幅な遅延
    エ 新設営業所へのITサービス提供要求
    【解説】
    インシデントには問合せを含む場合もあります。しかし、基本的には、障害などのサービス品質の低下を引き起こすものがインシデントです。単なる「使い方に対する問合せ」などはインシデントにはなりません。
    正解はウです。アプリケーションの応答の大幅な遅延は、サービス品質の大幅な低下を引き起こしていますから、インシデント管理で対応すべき事象です。

    3.問題管理

    インシデント管理でも述べたが,問題管理は「根本原因の究明と解決」を行うプロセスである。
    また,試験センターからのシラバスでは次のような説明がある。
    問題管理
     問題管理は,問題の根本原因を突き止め,インシデントの再発防止のための解決策を提示する一連の活動であることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    問題管理では、大きく「問題コントロール」と「エラー・コントロール」の2つの活動があります。「未知の問題」、「既知のエラー」という言葉と合わせて理解しましょう。
    ①問題コントロール
    問題とは「インシデントの未知の根本原因」であり、「未知」の問題という点がポイントです。この問題を対処しようにも、「未知」の問題なので対処の方法が分からないのです。そこで、「未知」の根本原因を「既知」の根本原因にし、対処可能にする活動が問題コントロールです。
    ②エラー・コントロール
    問題コントロールによって把握できた「既知」の根本原因を解決するのがエラー・コントロールです。
    なので、未知の根本原因が「問題」で、既知の根本原因が「エラー」と考えることもできます。過去問(H26年春午前問56)では、「ITサービスマネジメントにおける“既知の誤り(既知のエラー)”の説明」として、「根本原因が特定されている又は回避策が存在している問題」と述べられています。

    過去問(H20春SW午前)を見てみましょう。
    問49 ITILにおける問題管理プロセスとして実施するものはどれか。
    ア システムダウンから暫定的に復旧させ,業務を継続できるようにする。
    イ システムダウンに備えて,復旧のための設計をする。
    ウ システムダウンの根本原因を究明し,抜本的な対応策を策定する。
    エ システムダウンの発生を記録し,関係する部署に状況を連絡する。
    【解説】
    アは、インシデント管理プロセスの説明です。
    イは、ITサービス継続性管理プロセスの説明です。
    ウは正解です。問題管理プロセスは,インシデントの根本原因を究明します。インシデント管理が、早期復旧を目的とするのに対し、問題管理では、抜本的な対策を検討する点を理解しましょう。
    エはインシデント管理プロセスの説明です。

    【解答】


    別の過去問(H29春AP午後問10)では、問題と「既知の誤り」を次のように整理しています。
    ITサービスに対する計画外の中断やITサービスの品質の低下をインシデントと定義している。一つ以上のインシデントの根本原因を[ a:問題 ]と呼び,“根本原因が特定されているか,若しくは回避策によってサービスへの影響を低減又は除去する方法がある[ a:問題 ]”を[ b:既知の誤り ]と呼んでいる。


    4.変更管理
    変更管理とは変更要求(RFC:Request For Change) を管理し,優先度などを基にからどの変更を実施するかを判断するプロセスである。
    また,試験センターからのシラバスでは次のような説明がある。
    変更管理
     変更管理は,すべての変更を制御された方法で,アセスメント,承認,実装,レビューを確実に実施し,リスクの回避,効率的な変更処理の実施などを行う一連の活動であること,また,変更によるシステムへの影響を最小限に抑えることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    5.リリース管理
    リリース管理では,変更管理で承認された変更を実際に適用する。
    また,試験センターからのシラバスでは次のような説明がある。
    リリース管理
     リリース管理は,変更管理で承認された変更を稼働環境に配送し,配布し,追跡するプロセスであることを理解する。また,新たな版の導入の計画から実際の導入,サービスの利用者とのコミュニケーション,万一導入に失敗した場合に元に戻す作業などを行う一連の活動であり,構成管理及び変更管理との連携が必要であることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    1.SLM(サービスレベル管理)
    SLM(Service Level Management:サービスレベル管理)とは,合意したSLAのマネジメントである。つまり,SLAがを遵守すされるための継続的なマネジメント活動である。
    また,試験センターからのシラバスでは次のような説明がある。
    SLM
     SLM(Service Level Management:サービスレベル管理)は,サービスの利用者とサービスの提供者の間でSLAを締結し,PDCAマネジメントサイクルによってサービスの維持,向上を図る一連の活動であること,モニタリングの結果に応じてSLA やプロセスを見直すことを理解する。また,OLA(Operational Level Agreement:運用レベル合意書)を理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    2.可用性管理
    可用性管理とは,RAS,つまりReliability(信頼性),Availability(可用性),Serviceability(保守性)を高めることで,ITサービスの可用性を高める活動である。
    また,試験センターからのシラバスでは次のような説明がある。
    可用性管理
     可用性管理は,サービスの利用者が利用したい時に確実にサービスを利用できるよう,IT サービスを構成する個々の機能の維持管理を行う一連の活動であることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)
    加えて、RTO,RPOという言葉も理解しておきましょう。
    http://nw.seeeko.com/archives/50536565.html

    3.キャパシティ管理
    “キャパシティ管理”と似た概念で,“性能管理”という言葉がある。狭義に考えると,“キャパシティ”とは“容量”を意味するのでハードディスク容量などを意味し,“性能”はオンラインサービスの応答時間などを意味する。だが,
    ITILにおけるキャパシティ管理はもっと広義にとらえられ,性能管理も包含する概念で定義されている。参考までに、JIS Q 20000では、キャパシティという言葉に“容量・能力”という訳を割り当てている。
    また,試験センターからのシラバスでは次のような説明がある。
    キャパシティ管理
     キャパシティ管理は,容量,能力などシステムのキャパシティを管理し,最適なコストで,現在及び将来の合意された需要を満たすために,サービス提供者が十分な能力をもっていることを確実にする一連の活動であることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)
    過去問(H22春AP午前)をみてみましょう。
    問55 ITILのキャパシティ管理において,監視項目となるものはどれか。
    ア インシデント発生件数
    イ オペレータ要員数
    ウ ディスク使用率
    エ 平均故障間隔

    【解説】
    キャパシティ管理とは、容量であったり性能を管理するものです。容量や性能に関する内容は、ウのディスク使用率です。エの故障間隔も、性能と考えられるかもしれませんが、こちらは信頼性に関する内容です。よって、可用性管理の指標と言えます。
    【正解】


    4.ITサービス財務管理
    ITサービス財務管理とは,ITサービスにかかわるコスト管理や,利用者への課金管理を行うプロセスである。
    また,試験センターからのシラバスでは次のような説明がある。
    IT サービス財務管理
     IT サービス財務管理は,IT サービスにかかわるコストの予測と実際に発生したコストの計算や課金の管理に関する一連の活動であることを理解する。また,サービスごとに必要なコストを算出し,基本的にはサービスの利用者(受益者)が負担するように課金を行うことを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    5.ITサービス継続性管理
    ITサービス継続性管理とは,BCP(Business Continuity Plan;事業継続性計画)やBCM(Business Continuity Management;事業継続性管理)のIT版と考えると理解しやすいだろう。また,試験センターからのシラバスでは次のような説明がある。
    ITサービス継続性管理
     顧客と合意したサービス継続を,あらゆる状況の下で満たすことを確実にするための活動であること,また,サービス継続に関する要求事項は,事業計画,SLA及びリスクアセスメントに基づいて特定されなければならないことを理解する。
     ITILでは,ITサービス継続性管理は,災害発生時に最小時間でITサービスを復旧させ,事業を継続するために,リスクアセスメントやサービスの継続の計画立案と試験を行う一連の活動とされていることを理解する。
    (※応用情報技術者シラバス 中分類15:サービスマネジメント より引用)

    過去問(H19秋NW午前)をみてみましょう。
    問19 ITサービスマネジメントのフレームワークであるITIL(Information Technology Infrastructure Library)におけるITサービス継続性管理の目的はどれか。
    ア 自然災害などの非日常的な要因でシステムが停止した場合の対策を立て,ビジネスへの影響を許容範囲内に収める。
    イ 日常的なハードウェア障害やソフトウェア不良による障害から業務処理が正常にできるまでに復旧させる。
    ウ ビジネス活動に必要なシステムを,必要なときに利用可能であるように保証する。
    エ 未知の問題が発生したときに,その問題を回避するための方策を立案する。
    【解説】
    アは正解選択肢です。ITサービス継続性管理は、BCPやBCMと同じ目的と考えていいでしょう。自然災害などの非日常的な要因でシステムが停止した場合の対策を立てることです。
    イはインシデント管理に関する内容です。
    ウは、可用性管理に関する内容です。
    エは、問題管理に関する内容です。

    【解答】

    プロジェクトマネジメントといえばPMI(Project Management Institute:米国プロジェクトマネジメント協会)のPMBOK(Project Management Body of Knowledgeプロジェクトマネジメント知識体系)が欠かせません。

    参考ですが、応用情報技術者試験シラバスでは、「サブジェクトグループ」というまとめ方をしています。内容は同じです。
    ④ プロジェクトマネジメントの十のサブジェクトグループ
    プロジェクトマネジメントの十のサブジェクトグループを理解する。
    サブジェクトグループ 統合サブジェクトグループ,ステークホルダサブジェクトグループ,スコープサブジェクトグループ,資源サブジェクトグループ,タイムサブジェクトグループ,コストサブジェクトグループ,リスクサブジェクトグループ,品質サブジェクトグループ,調達サブジェクトグループ,コミュニケーションサブジェクトグループ

    PMBOKでは、10の知識エリアで整理されています(かつては9でした)。覚える必要はありませんが、言葉だけはチェックしておきましょう。一度読んだら、あとは過去問で学習すれば十分です。

    ①統合マネジメント ←他の知識体系を統合する
    http://sm.seeeko.com/archives/65793478.html
    ②ステークホルダマネジメント

    ③プロジェクト・スコープ・マネジメント ※スコープ(scope)は「範囲」という意味
    http://sm.seeeko.com/archives/65793477.html
    ④人的資源マネジメント ←人の管理1
    http://sm.seeeko.com/archives/65793473.html
    タイムマネジメント ←進捗管理
    http://sm.seeeko.com/archives/65793475.html
    ⑥コストマネジメント ←費用管理
    http://sm.seeeko.com/archives/65793476.html
    ⑦プロジェクト・リスク・マネジメント
    http://sm.seeeko.com/archives/65793470.html
    ⑧品質マネジメント ←品質管理
    http://sm.seeeko.com/archives/65793474.html
    ⑨調達マネジメント
    http://sm.seeeko.com/archives/65793469.html
    ⑩プロジェクト・コミュニケーション・マネジメント ←人の管理2
    http://sm.seeeko.com/archives/65793471.html

    次の記事からは、この中で重要な以下の4つ内容に関して、詳しく解説します。
    ③プロジェクト・スコープ・マネジメント
    タイムマネジメント ←進捗管理
    ⑥コストマネジメント ←費用管理
    ⑧品質マネジメント ←品質管理
    応用情報技術者試験を勉強する成子 

    タイム、コスト、品質に関しては、QCDという言葉を使いますね。
    ※QCDは、「Quality:品質」「Cost:費用」「Delivery:納期」
    問題にチャレンジ
    例題(H28春IP午前問47)  
    問47 プロジェクトスコープマネジメントに関する記述として,適切なものはどれか。
    ア プロジェクトが生み出す製品やサービスなどの成果物と,それらを完成するために必要な作業を定義し管理する。
    イ プロジェクト全体を通じて,最も長い所要期間を要する作業経路を管理する。
    ウ プロジェクトの結果に利害を及ぼす可能性がある事象を管理する。
    エ プロジェクトの実施とその結果によって利害を被る関係者を調整する。
    アは、正解選択肢です。
    イはタイムマネジメント
    ウはリスクマネジメント
    エはステークホルダマネジメント
    【正解】 ア

    滋賀県に国際空港を建設するというプロジェクトが仮にあったとします。このプロジェクトに必要な工期や人員はどれくらいでしょうか。即答は難しいですよね。
    プロジェクトを管理する際に、作業を管理できるレベルに細分化しておかないと、必要な人員やスケジュールなどを立案できません。そこで、WBSによって、作業を管理できるレベルに細分化します。

    【参考】WBSを使用する目的
    過去問(H28春FE午前問51)では、「ソフトウェア開発プロジェクトにおいてWBS (Work Breakdown Structure)を使用する目的」として「作業を階層に分解して,管理可能な大きさに細分化する。」と述べられています。
    過去問(H17秋PM午後Ⅱ問2)の出題趣旨では、「プロジェクト計画では,スコープ定義段階で作成されるタスク構成(WBS)を基に資源や要員の計画を行いながらスケジュールを作成し,稼働開始時期を定める。」と述べられています。

    応用情報のシラバスを見てみましょう。
    WBS は,プロジェクト計画に基づき,プロジェクトで作成する成果物や実行する作業を階層的に要素分解し,スコープ全体を定義し表現した構造であり,予算,工程,品質などの計画立案や管理に活用されることを理解する。
    IPA応用情報技術者試験シラバス より引用
    http://www.jitec.jp/1_13download/syllabus_ap.pdf
    WBS(Work Breakdown Structure)を直訳すると、Work(仕事)をBreakdown(分解)したStructure(構造)です。過去問では、「プロジェクト目標を達成し,必要な要素成果物を生成するために,プロジェクトが実行する作業を階層構造で記した文書(H25春PM午前2問4不正解選択肢)」「プロジェクトマネジメントにおいて計画を立てる際に用いられる手法の一つであり,プロジェクト全体を細かい作業に分割し,階層化した構成図で表すもの(H24春IP問41」と述べられています。

    WBSの例が過去問(H26春FE午前問52)に掲載されているので紹介します。
    ※問題文は「図のように,プロジェクトチームが実行すべき作業を上位の階層から下位の階層へ段階的に分解したものを何と呼ぶか」です。
    5ad3487a.jpg
    ②ワークパッケージ
    WBSは、プロジェクトにてコントロール可能な単位まで細分化されます。この最小の単位をワークパッケージといいます。どこまで細かくするかはプロジェクトの規模にもよります。あまり細かくし過ぎると、逆に管理が大変になります。

    ③アクティビティ
    ワークパッケージをさらに作業ベースにしたものがアクティビティです。過去問では、「ワークパッケージは、更にアクティビティに分解される」(H22ST午前1問18)と述べられています。
    以下の過去問(H22春IP問91)を例にします。
    問91 作業内容定義では,作業分割で作成したWBSを基に,担当,工数を加えた表を作成した。次の表はその一部を示したものである。画面設計での作業5の作業間には次の図に示す順序関係があるとき,画面設計のクリティカルパスの作業日数はどれか。図では,作業の流れを矢印で,作業名を矢印の上又は下に示している。
    aaa
    この問題の表にあるように、作業4にある画面設計や帳票設計というコントロール可能なワークパッケージにおいて、「画面一覧」を作ることや「画面フロー」を設計することなどの作業(アクティビティ)があります。
    作業(アクティビティ)およびクリティカルパスに関しては、このあとのタイムマネジメントで解説します。
    ※厳密には、この問題では、作業5がワークパッケージとして書かれています。が、開発規模が小さい場合には、作業4がワークパッケージ、作業5がアクティビティと考えてもいいでしょう。

    または、画面一覧を作るワークパッケージにおいて、画面設計、コーディング、テストなどの各工程をアクティビティ(作業)と考えることもできます。(こちらの方が一般的かと思います)

    2.WBSの書き方について
    35b07b6f.jpg
    WBSを書けと言われましたが、書き出すとやることがたくさんあって、このペースでいくと1000以上になっちゃいそうです。かなり悩んでます。


    WBSの書き方だけど、ポイントは2つある。一つはアウトプット(成果物)をイメージして書く。「~と打ち合わせする」「~に依頼する」「物品を発注する」「受領する」「メールを送る」など、仕事を細分化するときりがない。まずは作成するアウトプットベースで考える。プログラム開発であれば、画面や機能であろう。システム構築であれば、基本設計書、詳細設計書、Config、構築などのドキュメントや構築という成果をベースに考える。

    もう一つのポイントは今述べたようなやり方で、大きなカテゴリで作成し、徐々に細かくブレークダウンする。そうすることで、わかりやすくなるし、MECEという観点で、漏れやダブりもなくなる。
    317c39f8.jpg 
    作り方はよくわかりました。では、次にどのレベルまで細かく書けばよいのですか?

    細かければよいと言うものではないことは分かるでしょう。注意点は細かくしていっても、アウトプットベースであることを忘れないこと。
    例えば、「基本設計書」という工程を細分化していって、「基本設計書のラフ作成」「レビュー」「お客様確認」などのアウトプットに関係ないことを書き出したらきりがない。細分化するとすれば製品ごとに分けることや、「物理設計」「論理設計」などで分ける。(※基本は前者)
    WBSはセンスがいる。変なのを書くと会議で総つっこみが入るので、色々な例を参考にして、バランスの良いWBSを書きましょう。

    ■H27秋AP午前
    問51 WBS作成プロセスが含まれるマネジメントプロセスはどれか。
    ア プロジェクトコストマネジメントプロジェクト
    イ スコープマネジメント 
    ウ プロジェクト品質マネ ジメント
    エ プロジェクトリスクマネジメント
    【正解】イ

    ■H26秋AP午前
    問51 WBS (Work Breakdown Structure) を利用する効果として,適切なものはどれ か。
    ア 作業の内容や範囲が体系的に整理でき,作業の全体が把握しやすくなる。
    イ ソフトウェア,ハードウェアなど,システムの構成要素を効率よく管理できる。
    ウ プロジェクト体制を階層的に表すことによって,指揮命令系統が明確になる。
    エ 要員ごとに作業が適正に配分されているかどうかが把握できる。
    【正解】ア

    ■H24秋AP午前
    問51 WBS (Work Breakdown Structure)を利用する効果として,適切なものはどれ か。
    ア 作業の内容や範囲が体系的に整理でき,作業の全体が把握しやすくなる。
    イ ソフトウェア,ハードウェアなど,システムの構成要素を効率よく管理できる。
    ウ  プロジェクト体制を階層的に表すことによって,指揮命令系統が明確になる。
    エ  要員ごとに作業が適正に配分されているかどうかが把握できる。
    【正解】ア

    さて、次はタイムマネジメントについて解説します。プロジェクトにおいて、納期を守ることはとても大事なことです。応用情報のシラバスでは、以下の記載があります。
    3.プロジェクト・タイム・マネジメントの目的
    プロジェクト・タイム・マネジメントは,プロジェクトを所定の時期に完了させること
    http://www.jitec.jp/1_13download/syllabus_ap.pdf

    タイムスケジュールを管理する方法に、アローダイアグラム(またはPERT:Program Evaluation and Review Technique)と呼ばれる作業を矢印(アロー:Arrow)で表す方法があります。
    過去問(H22秋FE午前問51)を見てみましょう。
    問51 次のアローダイアグラムで表されるプロジェクトがある。結合点5の最早結合点時刻は第何日か。
    arrow
    ア 4  イ 5  ウ 6  エ 7
    ここにありますように、作業の結合点となるところが丸で表記され、作業は矢印(→)で表記されます。→の上にはアクティビティの作業名、下には所要日数が記載されます。前後関係がありますので、上記で言うと、いきなりGやHの作業をすることはできず、その前の工程であるDやEなどが終わっている必要があります。

    さて、矢印がいくつもあって、いくつかの工程があります。たとえば、A⇒D⇒G、A⇒E⇒H、B⇒F⇒Hなどなど。この中で、もっとも管理に注力する必要があるのは、どの工程でしょうか。
    応用情報技術者試験を勉強する成子

    納期を守るためには、もっとも時間がかかる工程を管理すべきだと思います。




    そうですね。それがクリティカルパスです。危機的(Critical)な道(path)と考えると理解しやすいでしょう。過去問(H24春IP問49)では、「プロジェクトの開始から完了まで最も所要時間が掛かるクリティカルパス」と述べられています。応用情報技術者試験では、アローダイアグラムおよびクリティカルパスの問題はとてもよく出題されます。内容を理解すればそれほど難しくはありません。必ず解けるようにしておきましょう。

    最早開始日(最早結合点時刻)、最遅開始日(最遅結合点時刻)、余裕日数
    最早開始日とは、その言葉の通り、作業を最も早く開始できる日です。ある結合点における最早開始日は、「最早結合点時刻」と表現されることもあります。(★要確認)
    同様に、最遅開始日とは、その言葉の通り、作業を最も遅く開始できる日です。ある結合点における最遅開始日は、最遅結合点時刻と表現されることもあります。(★要確認)
    応用情報技術者試験を勉強する成子 

    作業開始を遅らせようと思えば、いくらでも遅らせることができると思いますよ。




    前提として、「プロジェクト全体スケジュールを遅延させないこと」という条件が付きます。
    また、最早開始日と最遅開始日の差が余裕日数で、余裕日数がゼロの経路がクリティカルパスになるとも言えます。

    ■ダミー作業
    破線の矢印はダミー作業です。
    作業そのものは無いので、作業時間がゼロです。単に作業の前後関係だけを表します。

    クリティカルパスに遅れが生じている場合は、スケジュールを短縮するための手段をとることになります。その際の手法として、次の2つがあります。

    クラッシング
     アクティビティの関係を変えずに行う。最も簡単な例が、追加の人員を投入するやり方である。当然ながら、コストがかかる。
    過去問(H26春AP午前問53)では、「スコープを縮小せずにプロジェクト全体のスケジュールを短縮する技法の一 つである“クラッシング”では,メンバの時間外勤務を増やしたり,業務内容に精通し たメンバを新たに増員したりする。」とある。

    ファストトラッキング
     作業を並行して実施したり、順番を入れ替えるなどすることで、工期を短縮します。例えば、技術検証をしてから物品を発注するべきだが、物品の納期がかかる場合に、技術検証が成功すると仮定して先行して物品を発注します。しかし、検証が失敗したり、手戻りが発生するリスクもあります。

    過去問(H26秋AP午前問54)を見てみましょう。
    問54 工期を短縮させるために,クリティカルパス上の作業に“ファストトラッキング”技法を適用した対策はどれか。
    ア 時間外勤務を実施する。
    イ 生産性を高められる開発ツールを導入する。
    ウ 全体の設計が完了する前に,仕様が固まっているモジュールの開発を開始する。
    エ 要員を追加投入する。
    【正解】ウ
    このように、作業の順序を入れ替えるなどして工期の短縮を図るのがファストトラッキングです。アとエは、時間外勤務や要員を追加するという、最も典型的なクラッシングの手法です。また、イも作業の順番を変えていないので、クラッシングと言えるでしょう(★要確認)。

    ■H26春AP午前
    問53 スコープを縮小せずにプロジェクト全体のスケジュールを短縮する技法の一 つである“クラッシング”では,メンバの時間外勤務を増やしたり,業務内容に精通し たメンバを新たに増員したりする。“クラッ シング”を行う際に,優先的に資源を投入すべきスケジュールアクティビティはどれか 。
    ア 業務の難易度が最も高いスケジュールアクティビティ
    イ クリティカルパス上のスケジュールアクティビティ
    ウ 資源が確保できる時期に開始するスケジュールアクティビティ
    エ 所要期間を最も長く必要とするスケジュールアクティビティ
    【正解】イ

    ■H25春AP午前
    問51 ファストトラッキングの説明はどれ か。
    ア クリティカルパス上のアクティビティに 追加資源を投入して,所要期間を短縮する。
    イ 時期によって変動するメンバの作業 負荷を調整して,作業期間内で平準化する。
    ウ 通常は順番に行うアクティビティを並 行して行うことによって,所要期間を短縮する。
    エ 不測の事態に備えて所要時間をあら かじめ多めに見積もっておく。
    【正解】ウ

    ↑このページのトップヘ