12
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

応用情報技術者試験 マネジメント編

Last updated at Posted at 2021-10-28

プロジェクトマネジメント

限られた時間(有期性)で独自の成果を想像する(独自性)ための業務をプロジェクトという。
プロジェクトを管理して、限られた予算・期間内に終わらせるためのプロセスをプロジェクトマネジメントという。

  • プロジェクトマネージャー:プロジェクトを成功させるためのプロジェクトの責任者。
  • PMO(プロジェクトマネジメントオフィス):プロジェクトマネージャの作業を代行・補佐する組織。
  • プロジェクトスポンサ:プロジェクトへの資源や支援を提供したり、エスカレーションの受け手になる。
  • プロジェクトマネジメントチーム:プロジェクトマネジメントに関与しているメンバーのこと。
  • ステークホルダ:プロジェクトの利害関係者のこと。
  • ステップ:ソースコードの行数。
  • 1人月:一人で一か月かかること。
  • 生産性:人月当たりのステップ数。

プロジェクト統合マネジメント

全プロセスに共通するプロジェクトマネジメント。

プロジェクト憲章の作成

  • プロジェクトの目的
  • 測定可能なプロジェクト目標と関連する成功基準
  • プロジェクト全体のリスク
  • プロジェクトのステークホルダーリスト
  • プロジェクト終了条件
  • 任命されたプロジェクトマネージャー

プロジェクト計画書作成

プロジェクトのマネジメントの方法を記した包括的な内容。
統合したプロジェクトマネジメント計画書を作成する。

統合変更管理(プロジェクトの監視・コントロールプロセス)

プロジェクトの仕様や成果物への変更要求を受け付けて、レビューし、承認して変更を行う。

構成管理(コンフィギュレーションマネジメント)

設計者やプログラムなど成果物のバージョンを識別して、最新状態を維持し正当性を担保すること。
ハードウェアやソフトウェアの構成も記録して管理する。

  • 構成管理の対象成果物:ソースコード、設計書等、プロジェクトで作成するすべての成果物。
  • 構成管理担当メンバ :全成果物を最新状態に維持するために構成管理担当メンバを選任する。
  • 構成管理ソフトウェア:効率よく構成管理をするために構成管理ソフトウェアを導入する。
  • 世代管理:ファイルの変更、リリースのたびにそのファイルのバージョンを1つ上げる。

プロジェクトスコープマネジメント

プロジェクトのスコープの定義

  • スコープ:プロジェクトが提供するプロダクト、サービス、所産の総体のこと。
  • 除外事項:スコープから除かれるもの。
  • 前提条件:プロジェクトの計画に当たっての前提。
  • 制約条件:プロジェクトの実行に影響を及ぼす影響要素。

WBSの作成

プロジェクト・チームが実施する作業の全範囲を要素分解したもの。
最上位の要素はプロジェクト名、最下位の要素をワークパッケージ。
ワークパッケージは、プロジェクトタイムマネジメントで、アクティビティに分解される。

プロジェクトの資源

教育技法

  • インバスケット:一定時間内に数多くの問題を処理させて、総合的な判断力を高める技法。
  • ケーススタディ:実際の事例の研究や、一般的な理論やモデルの応用などを通して、実践的な能力を高める技法。
  • OJT:実務の中で、上司や先輩から個別に指導を受けて、実体験から知識を得る技法。
  • ロールプレイング:参加者に特別の役割を演じさせて、役割に応じたスキルを高める技法。

プロジェクトタイムマネジメント(プロジェクトスケジュールマネジメント)

プロジェクトの計画をし、スケジュール通りにプロジェクトが進むようにマネジメントする。

アクティビティの定義

スコープマネジメントで定義したWBSのワークパッケージを実際に作業ができるように、さらに細かく分解されたもの。
ワークパッケージが十分に分解されている場合、ワークパッケージとアクティビティが一致する。

アクティビティの順序設定

計画プロセス群に属して、アクティビティの順序関係を特定して文書化する。

プレジデンス・ダイアグラム法(PDM)

アクティビティを四角のノードで示して、先行アクティビティと後続アクティビティを矢印で接続した図。

終了-開始関係(FS関係)、終了-終了関係(FF関係)、開始-開始関係(SS関係)、開始-終了関係(SF関係)

アクティビティ所要期間の見積もり

計画プロセス群に属していて、個々のアクティビティを完了するのに要する作業期間を見積もるプロセス。

  • 類推見積もり:類似のアクティビティやプロジェクトでの過去のデータを元に、所要期間を見積もる方法。
    トップダウン見積もりとも呼ばれており、見積もりの精度が見積もり担当のスキルに依存する。
  • 三点見積もり:楽観値(最良のケースを想定した見積もり)、再可能値(最も起こる可能性が高い値)、悲観値(最悪のケースを想定した見積もり)の加重平均をして見積もり値を算出する方法。

スケジュールの作成

アクティビティのリスト、プレジデンス・ダイアグラム、所要期間の見積もりを用いてスケジュールを作成する。

クリティカル・パス:全作業工程の中で、最も所要日数のかかる作業群のことを言う。

クリティカルパス法

全作業工程の中で最も所要日数のかかる作業群、クリティカルパスを用いて作業期間の見積もりをする方法。

アローダイアグラム

作業と作業日数を矢印で、結合点を丸印で表す図。作業日数が0だが、作業間で依存関係のある作業を”ダミー作業”と言って、破線の矢印で表す。

  • 往路時間計算(フォワード・パス)分析:作業の開始時点から終了時点に向かって所要日数を加算して最早結合点時刻(開始点からその結合点に最も早く到達できる日)を求める。
  • 復路時間計算(バックワード・パス)分析:作業の終了時点から開始時点に向かって所要日数を減算して最遅結合点時刻(プロジェクト全体の遅れにつながらない範囲で最も遅くなっても良い日)を求める。
  • 余裕時間分析:各結合点でプロジェクト全体の遅れにならない範囲でとどまれる時間(フロート)を算出する。最遅結合点時刻-最早結合点時刻で求められる。

フロートが0の結合点をつないだ経路がクリティカルパスになる。

プレジデンス・ダイアグラム

アクティビティを四角形で表し、先行アクティビティと後続アクティビティを矢印で接続した図。

  • 往路時間計算(フォワード・パス)分析:作業の開始時点から終了時点に向かって所要日数を加算して最早結合点時刻(開始点からその結合点に最も早く到達できる日)を求める。
  • 復路時間計算(バックワード・パス)分析:作業の終了時点から開始時点に向かって所要日数を減算して最遅結合点時刻(プロジェクト全体の遅れにつながらない範囲で最も遅くなっても良い日)を求める。
  • 余裕時間分析:各結合点でプロジェクト全体の遅れにならない範囲でとどまれる時間(フロート)を算出する。最遅結合点時刻-最早結合点時刻で求められる。

フロートが0の結合点をつないだ経路がクリティカルパスになる。

スケジュールの短縮方法

  • クラッシング:資源(人員等)を投入してスケジュールの所要時間を短縮する方法。
  • ファスト・トラッキング:順番に実行される先行アクティビティと後続アクティビティを並行して実施する手法。

プロジェクト・スケジュール

  • ガント・チャート(バー・チャート):縦軸に作業項目、横軸に月や日付を取って、作業の予定期間を線で示した図。
  • マイルストン・チャート:縦軸に作業項目、横軸に各作業の通過点として表の中には、実施する日付を記載する。

プロジェクトコストマネジメント

プロジェクトのコストを見積もり、コストをコントロールする。

パラメトリック見積もり

関連する過去のコストデータとその他の変数(ソースコード行数)との相関を用いて、プロジェクトのコストを見積もる技法。

COCOMO法

見積工数 = (予想プログラムステップ数 × 開発生産性)指数倍率 × 補正係数
  • 予想プログラムステップ数:作成するプログラムの予想行数(類似プロジェクトの実績から求める)。
  • 開発生産性:: 1ステップ作成するのに必要は人月(類似プロジェクトの実績から求める)。
  • 指数倍率:開発規模が大きくなると、開発メンバの数が増加して、それにつれて打ち合わせの数も多くなり、開発効率が落ちる。これを見積工数に反映させるための値。
  • 補正係数:プロジェクトの特性を考慮して見積もるために用いられる。

ファンクションポイント法

内部論理ファイル、外部インターフェースファイル、外部入力、外部出力、外部参照を求める。

  1. 複雑度に応じてファイルの数を分ける。
  2. 複雑度に対する重み係数を設定する。
  3. ファンクションポイント数を求める。
  4. ファンクションポイント数に補正係数をかける。
補正後のファンクションポイント数 = ファンクションポイント数 × 補正係数
  1. 見積もり工数を算出する。
見積もり工数(人月) = ファンクションポイント数 × 開発生産性(人月/ファンクションポイント)

ボトムアップ見積もり法

WBSから作業を洗い出し、過去の経験から作業ごとに工数を割り当て足し合わせる。

標準タスク法

全体を細かい標準作業に分割して、その細かい作業に対してあらかじめ定めた工数を割り当てる。
それを足し合わせて全体の工数を求める。

類推見積もり法

過去に経験した類似のシステムについてのデータを基にして,システムの相違点を調べ,同じ部分については過去のデータを使い,異なった部分は経験から規模と工数を見積もる方法。

コストのコントロール

「監視・コントロール」プロセス群に属していて、プロジェクトのコストを更新するために、プロジェクトのコスト状況を監視してコントロールする。

アーンド・バリュー分析(EVM: Earned Value Management)

  • プランド・バリュー(PV: Planned Value):スケジュールされた予定作業に割り当てる認可済み金額。
  • アーンド・バリュー(EV: Earned Value):完了した作業量を、認可済みの予算で換算した金額(出来高)。
  • 実コスト(AC: Actual Cost):完了した作業のために実際に支出された金額。
  • スケジュール差異(SV):アーンド・バリュー(EV) – プランド・バリュー(PV)
  • コスト差異(CV):アーンド・バリュー(EV) – 実コスト(AC)
  • スケジュール効率指数(SPI):アーンド・バリュー(EV) / プランド・バリュー(PV)
  • コスト効率指数(CPI):アーンド・バリュー(EV) / 実コスト(AC)
  • BAC(Budget AtCompletion):完成時の総予算で、当初計画した完成時のプランド・バリュー。
  • EAC(Estimate AtCompletion):完成時の総コスト見積額。現時点でのAC+ETC。
  • ETC(Estimate ToCompletion):現時点から完了するまでの、総コスト見積額。
  • VAC(Variance AtCompletion):EAC-BAC。プラスの場合赤字プロジェクト。

プロジェクトリスクマネジメント

プロジェクトのリスクを特定して、対策をするプロセス

リスクの特定

計画プロセス群に属するプロセス。リスクを特定して、リスク登録簿に登録する。

  • ブレーンストーミング:複数の人が互いの意見に批判を加えずに、リスク案を自由に出す手法。
  • インタビュー:ステークホルダーにあって、リスクがないのか聞き取る。
  • デルファイ法:複数の専門家にリスクについて聞く手法。
  • リスク登録簿:リスク特定プロセスのアウトプットで、特定されたリスクと実行可能な対応策の一覧を記録する。

リスクの定性的分析

リスクの性質を元に、発生確率と影響度から優先順位をつける。

リスクの定量的分析

特定したリスクがプロジェクト目標全体に与える影響を数量的に分析する(リスクの詳細化)。

  • 感度分析:プロジェクトに与える影響の大きいリスクを明確にする。分析された複数のリスクの要素のうち、ある一つの要素の発生確率や影響度が変化した場合に、プロジェクト目標の達成にどの程度の影響があるかを分析する。
  • ディシジョン・ツリー分析:いくつかの行動と代替案の中から、最良の選択をするための分析手法。

リスク対応の計画

脅威への戦略

  • リスク回避
  • リスク共有(移転)
  • リスク軽減
  • リスク保有(受容)
  • エスカレーション

機会への戦略

  • 活用:好機が来るように、その可能性を上げるための対策。
  • 強化:好機の発生確率、プラスの影響、あるいはその両方を増加させる対策。
  • 共有:好機をとらえる可能性の高い第3者に好機の実行権限の一部または全部を割り当てる。
  • 受容
  • エスカレーション

プロジェクト品質マネジメント

プロジェクトの品質が、顧客のニーズを満足するために行うマネジメント。

  • 品質の計画:プロジェクト目標を元に品質の要求事項、規格、品質活動の方法などを決定。
  • 品質保証の遂行:成果物のレビュー。
  • 品質管理の遂行:品質を満たしているかを明らかにし、不足があれば、原因を除去する。

品質管理の対象特性

  • 機能性:ソフトウェアが、指定された条件で利用するときに、明示的、暗示的必要性に合致する機能を提供すること。
  • 信頼性:指定された条件で利用する際に、指定された水準を維持するソフトウェアの能力。
  • 使用性:指定された条件で利用する際に、ユーザが理解、習得、利用できやすいこと。
  • 効率性:使用する資源の量に対して、十分な性能を提供すること。
  • 保守性:ソフトウェアを修正がしやすいこと。
  • 移植性:ある環境から別の環境に移すことが容易であること。

品質コスト

  • 適合コスト:予防コスト、評価コストなど、欠陥を回避するためにプロジェクト期間中に支出する金額。
  • 不適合コスト:バグなどの不良により、プロジェクト期間中、期間後に支出する金額。

品質管理の対象

サブシステム、システム全体。プログラムだけでなく、ドキュメントなどの成果物すべて。

品質管理とQC7つ道具

  1. 特性要因図:結果である特性がどのようにしてもたらされたかを図式化して、そこに潜んでいる問題点をあぶり出すのに用いられる手法。
  2. 管理図:異常なデータを発見するために使う時間軸でグラフを作成する。管理限界線を設定して、はみ出したデータを異常値とする。
  3. フローチャート化:手順などをフローチャートで分かりやすく表すこと。
  4. ヒストグラム:データを階級ごとに分けて集計をして、データの分布を調べるグラフ。
  5. パレート図:値が大きい順に並べた棒グラフとそれを集計した折れ線を組み合わせたグラフ。
  6. ランチャート:データの発生順に打点した折れ線グラフ。プロセスの傾向や変動を把握するのに用いる。管理限界のない管理図に似ている。
  7. 散布図:2つの項目を縦軸と横軸に取って、点のばらつきから2項目の関連性を分析する。

プロジェクト調達マネジメント

請負契約、委任契約などを締結してプロジェクトの人員を調達したり、ソフトウェア、ハードウェアなどの調達する方法を管理する。

プロジェクトコミュニケーションマネジメント

ステークホルダーが必要となる情報を把握して、正確な情報伝達を行う。

インタビューの方法

  • 事前に質問内容を渡してインタビューを実施する。その方が有益な情報を得られる可能性が高い。
  • インタビューは業務担当者のみでなく、幅広いひとから行う。
  • インタビュー内容が事実なのか意見なのかは区別するように注意する。

コミュニケーションツール

  • プッシュ型:特定の相手に向けて情報を発信する方法。メール、手紙、FAX 等
  • プル型:受信者が自分の意思で確認をする方法。掲示板 インターネットなど。
  • 双方向:複数の参加者がリアルタイムで情報のやり取りをする方法。会議、電話など。

サービスマネジメント

ITサービスマネジメント

IT部門の業務を「IT サービス」としてとらえ,体系化することで IT 運用の効率化を図り,可用性をはじめとするサービスの品質を高めようとする運用管理の方法。

ミッションクリティカル:障害発生時の多額の賠償など企業活動に重要な影響を及ぼすようなシステム。

ITサービスマネジメント規格

  • ITIL:サービスマネジメントにおけるベストプラクティス(成功事例)を集めたもので、標準規格となっている。
  • BS 15000:ITILをベースに英国規格協会で作成された規格。
  • ISO/IEC 20000:BS15000をベースに、ISOで標準化された規格。
  • JIS Q 20000:ISO/IEC 20000をベースに日本産業規格化されたもの。

サービスライフサイクル

ITILのアプローチ方法の1つ。

  • SLA(Service Level Agreement):顧客とプロバイダ間で決めたサービスレベルに関する合意書。
  • サービス・ポートフォリオ:サービスプロバイダによって管理されているすべてのサービスのこと。
  • サービス・カタログ:稼働中の全てのITサービスに関する情報を格納するデータベース又は構造化された文書。
  • サービス・パイプライン:現在、検討中、または開発中のサービスの一覧。
  • サービス・パッケージ:コアサービス、実現サービス、強化サービスの組合せで構成された,特定の種類の顧客ニーズへのソリューションを提供する複数のサービスの集まり。

サービスストラテジ(戦略)

競合他社よりも優れたサービスの提供のために、戦略的に提供するサービスを定義する。

サービスデザイン(設計)

顧客の満足を満たす品質のサービスを提供できるように設計と分析を行う。

  • サービスレベル管理(SLM):サービスレベルの合意と監視に関する活動。サービスカタログを元にSLAを作成する。
  • キャパシティ管理:システムへの負荷に対応するために必要な資源を提供する活動。
  • 可用性管理:サービスの停止時間がSLAに達するように管理すること。
  • ITサービス継続性管理(ITSCM):自然災害などの停止からサービス復旧するための管理。
  • RTO:普及に許される時間で目標復旧時間とも呼ばれます。
  • レプリケーション:ハードウェアやソフトウェアの複製を作成して、本番環境と同様の状態に保ち、災害時に稼働するようにすること。

サービストランジション(移行)

新規サービス、新規機能や変更内容を本番環境へ移行する。

  • 変更管理:システムの変更を標準化して、変更の実施を管理してサービス品質の低下を最小限に抑える。
  • サービス資産管理及び構成管理:組織の管理するITサービス提供に必要な構成要素(CI)を常に最新情報にするための管理。
  • リポジトリ:システムを開発する際にシステムを構成するデータやプログラムの情報を集めたデータベースのこと。
  • リリース及び展開管理:テストをして本番環境に投入するソフトウェア、ハードウェア。
  • 切戻し:リリース後に不具合が生じた場合に元に戻す作業。

サービスの移行

  • 移行:運用テストを完了したシステムを本番環境へ移す工程。
  • 受入れテスト:受入れ環境でシステムが、ユーザの要件を満足しているのかシステムの発注者がチェックするテスト。
  • 移行テスト:安全性や効率性の観点で,既存システムから新システムへの切替え手順や切替えに伴う問題点がないか確認する。
  • 運用テスト:システム開発の最終段階で行う。本番環境で実際の業務と同じように使用してみて、正しく動作するか試す。
  • 運用引継ぎ:開発担当者から、運用担当者にシステムの利用方法、運用・監視方法をドキュメントで整理して引き継ぐ。

TCO(Total Cost Of Ownership)

システムのハードウェア・ソフトウェア導入(イニシャルコスト)から、運用後の維持・管理(ランニングコスト)も含めた総所要コストのこと。

TCO = イニシャルコスト + ランニングコスト

移行方式

  • 一斉移行方式:新システムへの移行を一辺に行う。
  • 段階移行方式:段階的に移行を行う。
  • 並行運用移行方式:新・旧両システムを並行稼動させて,少しずつ移行し、新システムで問題が発生しても業務への影響を最小にする。
  • パイロット移行方式:一部を先行的に試験して移行し、問題がなければ他の部分も移行する方式。

サービスオペレーション(運用)

サービスを提供して、合意したサービスレベルを維持するため、効率的にITサービスを提供してサポートする。

  • イベント管理:イベントを直接処置するのでなく、適切なプロセスに処置を依頼する。
  • 記録:ログに記録する。すべてのイベントに対して行う。
  • 自動応答:定義されたイベントについては、自動的に対応する。
  • アラート:人の介入が必要なイベントは、警告(アラート)を出す。
  • 処置の依頼:インシデント管理に送り処理を依頼する。
  • インシデント管理及びサービス要求管理:インシデントが起きた場合にその影響を排除、低減してサービスの早期復旧をする。
  • 機能的エスカレーション:インシデントを解決しないためにより高度な技術とリソースを持つ組織に引き渡す。
  • 段階的エスカレーション:現在の担当者では解決できなかったインシデントの対応を、広範にわたる関係者を招集する権限を持つ上級マネージャに委ねる。
  • ワークアラウンド:一時的・暫定的にインシデントをなくす対処のこと。
  • 問題管理:インシデントの根本原因を排除するための活動。
  • ベンチマーキング:現行業務と他社の成功事例と比較する。
  • フィット・ギャップ分析:現状で何ができていて(フィット)、何ができていないか(ギャップ)を明らかにする。

継続的サービス改善(PDCA活動)

サービスをより良い物に改善するサービスライフサイクルの1プロセス。
サービスライフサイクルの他のプロセスを包括した内容。

  • Plan(計画):サービスマネジメントシステムを計画し文書化し、SLAとのギャップを分析してそれを縮める計画をたてる。
  • Do(実行):サービスマネジメントシステムを実行する。計画時に設定したSLAとのギャップを縮める。
  • Check(監視):実施したサービスマネジメントシステムに効果があったのか確認する。
  • Act(改善):監視した結果を元に、サービスマネジメントシステムの改善を行う。

サービス改善プロセス(7ステップ改善)

  1. 改善戦略の識別
  2. 測定するものの定義
  3. データの収集
  4. データの処理
  5. 情報とデータの分析
  6. 情報の提示と利用
  7. 改善処置の実施

可用性の管理

可用性とは、利用者が継続的にサービスを利用できる性質のこと。

可用性(%) = 実際のサービス提供時間 / SLAで合意したサービス時間
  • 縮退運転:システムから切り離して、機能や性能を部分的に停止させた状態でもシステムの稼働を維持し続ける。
  • 予備系の待機:現用系で障害が起きた場合に予備系に処理を移す。
  • ホットスタンバイ:あらかじめ予備系のシステムを起動しておいていつでも切り替えられるように待機する。
  • コールドスタンバイ:現用系に障害が発生してから、OSの立ち上げソフトウェアの読込みを行う。
  • ウォームスタンバイ:現用系と同じようにOSは立ち上がっているが、システムは立ち上がっておらず、障害時に立ち上げる。

サービスデスク

サービスの利用者からの問合せに対して単一の窓口機能を提供し,適切な部署への引継ぎ,対応結果の記録,記録の管理などを行う。

  • ローカルサービスデスク:物理的・仮想的にサービスの利用者の近くに設定されたサービスデスク。
  • バーチャルサービスデスク:物理的には分散しているが、ITを用いることで擬似的に1拠点で機能しているようにしたサービスデスク。
  • 中央サービスデスク:全利用者からの問い合わせを1拠点で対応する。
  • フォロー・ザ・サン:2つ以上の異なる大陸上に拠点を置いて、24時間365日サービスを提供するサービスデスク。

ファシリティマネジメント

建物や設備などの資源が最適な状態となるように改善していくこと。

  • グリーンIT:情報通信にかかわる機器の省エネ、環境に配慮したIT製品を利用すること。
  • 無停電電源装置(UPS):停電などの電源異常が発生した場合に、システムに一定の電源を供給する装置。
  • 自家発電装置:地震等が発生して電源が通らなかった場合に利用する。
  • セキュリティワイヤ:コンピュータを盗まれないように固定するためのワイヤ。
  • サージ防護:雷などにより生じる過渡的な異常高電圧、その結果生じる異常大電流などから保護する機器。

システム監査

専門性と客観性を備えたシステム監査人が、一定の基準に基づいて情報システムを点検・評価・検証して監査報告の利用者に情報システムのガバナンス、マネジメント、コントロールの適切性に対する補償を与える活動。システム監査人は、独立かつ専門的な立場で監査を行う。

監査業務

  • 会計監査:会計(決算)に対して、一定の独立性を有する組織(会計士)が監査と最終的な承認を行うことである。
  • 業務監査:企業の会計業務以外の業務活動(組織や制度等)に対する監査。
  • 情報セキュリティ監査:「情報セキュリティマネジメント」が確立されているか。
  • システム監査:システムの様々なリスクに対して対策がとれているか評価・検証する。

システムガイドライン

  • システム監査基準:システム監査人のあるべき姿、監査の流れ、監査人の義務を規定。
  • システム管理基準:監査人の判断尺度として、何に着目して監査するのかを規定。

システム監査人

  • 外観上の独立性:監査対象から独立し、被監査主体と密接な利害関係を持たない。
  • 精神上の独立性:偏向を廃し、公正かつ客観的に監査判断する。

ITガバナンス

情報システムの策定と実行を制御して企業をあるべき方向へ導くこと。

コントロール

物事を正常・適切な状態にするための仕組みや環境。

  • 予防牽制機能:問題の生じる可能性のある行動、機会を事前に予防する。
  • 誤謬適示機能:問題が発生したことを即座に検出して警告する。
  • 修正回復機能:問題の発見時に修正して原状回復し、影響を抑制する。

可監査性

情報システムの信頼性、安全性、効率性をコントロールする仕組みがあり、コントロールを追跡する手段(監査証跡)があること。

監査証跡:事象の発生から、最終結果までの過程を追跡するための仕組みや記録(ログ)。

  • 物理的証拠:監査人が検証した現物(データなど)。
  • 文書的証拠:監査人が検証した文書・電磁的文書(マニュアルなど)。
  • 口頭的証拠:インタビューなどで得られた説明。

サンプリング(試査)

監査対象である母集団から一部の項目を抽出して実施する監査手続。

  • 統計的サンプリング:統計に基づいてサンプルを抽出する。
  • 非統計的サンプリング:統計的方法に基づかないサンプリング手法。
  • サンプリングリスク:抽出したサンプルから導き出す結論が、母集団すべての項目で導き出される結論と異なること。
  • 逸脱:所定のとおりにコントロールが運用されていない、監査での指摘事項。
  • 逸脱率:逸脱件数 / サンプル数
  • 許容逸脱率:不備の発生が許容される割合で監査人が決める逸脱率。
  • 予想逸脱率:監査人が予想する逸脱率の希望値。

監査の流れ

  1. システム監査計画:監査人が監査の目的、対象、日程を決めて監査計画書にまとめる。
  2. 予備調査(監査手続):本調査に先立って、調査する項目を決めるために管理者へのヒアリングなどを監査人が行う。
  3. 本調査(監査手続):監査計画で計画した監査項目に沿って監査人が調査する。監査証拠を収集する。
  4. 評価・結論:問題点や改善点の有無をシステム監査人の判断で評価する。
  5. 報告:監査人がシステム監査報告書を監査依頼者に提出する。
  6. フォローアップ:改善計画書を監査人が受領し、指摘した監査内容がきちんと改善されているか評価して、必要に応じて指導する。

監査技法

  • チェックリスト法:システム監査人が、あらかじめ監査対象に応じて調整して作成したチェックリストに対して、関係者から回答を求める技法。
  • ドキュメントレビュー法:監査対象の状況に関する監査証拠を入手するために、システム監査人が、関連する資料及び文書類を入手し、内容を点検する技法。
  • ウォークスルー法:データの生成から入力、処理、出力、活用までのプロセス、及び組み込まれているコントロールを、書面上で、又は実際に追跡する技法。
  • インタビュー法:システム監査人が、直接、関係者に口頭で問い合わせ、回答を入手する。
  • 突合法・照合法:関連する複数の証拠資料間を突き合わせること。
  • 現地調査法:被監査部門等に直接赴き、対象業務の流れ等の状況を、自ら観察・調査し、監査人が見た実態と被監査部門からの説明を総合的に判断して,監査証拠とする技法。
  • コンピュータ支援監査技法:システム監査を支援する専用のソフトウェアや表計算ソフトウェア等を利用してシステム監査を実施する技法。
  • テストデータ法:準備したテスト用データを監査対象プログラムで処理し、期待した結果が出力されるかどうかを確かめる技法。
  • 監査モジュール法:レポートを出力するモジュールを、本番プログラムに組み込む技法。
  • ペネトレーションテスト法:一般ユーザのアクセス権限又は無権限で、テスト対象システムへの侵入を試み、システム資源がそのようなアクセスから守られているかどうかを確認する技法。

システム監査の具体例

  • 有用性:公序良俗に反するものを除き、事業活動にとって必要な営業上、技術上の情報であること。
  • 秘密管理性:営業秘密保有企業の秘密管理意思が、秘密管理措置によって従業員に対して明確に示され、当該秘密管理意思に対する従業員等の認識可能性が確保されていること。
  • 非公知性:公然と知られていない情報であること。
  • 経済性:必要なものに対して、無駄のないコストを払っているか。
  • 情報の消失の予防:システム上の情報がなくならない、焼失しないこと。
  • システムテスト:システムが要件を満たしているのかテストで確認がとれていること。
  • 受入テスト:受入テストを適切にされている事。
  • ソフトウェア資産管理:ソフトウェアとその特許、ライセンス、著作権が正しく資産として管理されていること。
  • 事業継続計画(BCP):BCPは災害発生時に早期に復旧して事業を継続するための計画。それが適切に運営されていること。
  • 外部委託:ソフトウェア開発などを外部に委託する場合のリスクを考慮していること。
  • 守秘義務:従業員、外部委託者が守秘義務を守っていること。
  • 網羅性:発生した取引に抜け漏れ、重複がないこと。
  • アジャイル開発:適切な方法でアジャイル開発ができてること。

内部統制

自らが業務を適正に遂行していくために、体制を構築して運用する仕組み。
組織内で不正が発生しないように職務や部署の異なる担当者で作業を分担してお互いに牽制する。

内部統制を構成するための4個の目的

  • 業務の有効性・効率性:業務の達成度(有効性)及び資源の合理的な利用度(効率性)を測定・評価し、目標通りの達成ができたのか、また目標の見直しが必要なのか、といった適切な対応を図る体制を設ける。
  • 財務報告の信頼性:、財務諸表及び財務諸表に影響を及ぼす可能性のある情報の信頼性を確保すること。
  • 法令遵守:法令等を遵守して事業活動を営むための体制を整備し、運用すること。
  • 資産の保全:会社の資産(有形・無形、人的資源も含む)の取得やその使用、処分が正当な手続きや承認のもとで適切に行われるように資産の保全を図ること。

内部統制を構成するための6個の基本要素

  • 統制環境:経営者が内部統制の必要性を理解して内部統制の整備の最終的な責任を負う。
  • リスクの評価と対応:リスクを識別して、リスク分析を行い、適切な対策の策定と実施を進める。
  • 統制活動:各業務活動について責任者を明確にし、適切なチェック、承認、記録を行う。
  • 情報と伝達:必要な情報が識別、把握及び処理され、組織内外及び関係者相互に正しく伝えられること。
  • モニタリング:第3者により内部統制が有効に機能していることを継続的に評価する。
  • ITへの対応:情報システムを構築・活用して、適切な権限設定やログの記録を行うこと。

その他の用語

  • 情報システムのコントロール:システムの信頼性、安全性、効率性に影響を与えるリスクをなくしてシステムを構築・運用するためのコントロール。
  • CSA(統制自己評価):業務をよく知った担当者が、内部統制の状況を評価して、自律的に改善する仕組み。
  • レピュテーションリスク:企業に対する否定的な評価や評判が広まることによって、企業の信用やブランド価値が低下し、損失を被るリスク。
  • ITガバナンス:経営陣が経営資源を最大限に活用して企業の競争力を高めるために、ITを統制して、効率的かつ効果的に運用する仕組み。
  • EDMモデル
  • 評価:現在のシステムとあるべき姿を比較・分析する。
  • 指示:情報システム戦略実現に必要な責任と資源を組織に割りあてる。
  • モニタ:情報システムの効果、利用度合い、リスクの発生等の情報を集める。
  • 予防統制:リスクが起きないように防ぐための統制。
  • 発見統制:リスクを伴う事象が起きたことを気付くための統制。

内部統制の限界

  • 内部統制は、判断の誤り、不注意、複数の担当者による共謀によって有効に機能しなくなる場合がある。
  • 内部統制は、当初想定していなかった組織内外の環境の変化や非定型的な取引等には、必ずしも対応しない場合がある。
  • 内部統制の整備及び運用に際しては、費用と便益との比較衡量が求められる。
  • 経営者が不当な目的の為に内部統制を無視ないし無効ならしめることがある。
12
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?