システム監査のノート

• P社・・・情報処理サービス業
  • 社内の各種活動実績把握と新たな施策立案のため、データ分析システムを構築

様々な目的でデータ分析が可能だが、従業員の満足度を高めることを目的にして
当面のテーマは「働き方改革」とした。

[勤怠管理システム]        [人事管理システム]        [スケジュール管理システム]        [認証基盤システム]
　　　↓　　　　　　　　　　　　　↓　　　　　　　　　　　　　　↓　　　　　　　　　　　　　　↓
（勤務データ）　　　　　　　（人事データ）　　　　　　（スケジュールデータ）　　　　　（個人認証データ）

　　　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　　　　　　　　＜＜　　　データ分析ツール　　　　　　＞＞ 
　　　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　　　　　　　　　　　　　（レポート出力）

• 4つのシステムからデータを月次で収集
  • 勤怠管理システム（業務システム課）
  • 人事管理システム（業務システム課）
  • スケジュール管理システム（基盤システム課）
    • 現在は部署ごとの会議の合計時間だけを収集。⇒今後は詳細なデータ（会議ごとの参加者と時間）を収集する
  • 認証基盤システム（基盤システム課）

各部門が利用を希望する場合の流れは以下の通り

1. 情報システム部が実データの一部をサンプルデータとして抽出し提供する
2. 利用希望部門がそのデータを使って分析の試行をする
3. 意図した分析が可能であれば、データ利用申請書を提出し利用開始

• 障害発生時の停止時間は1時間

• 各利用部門は、データ分析ツールを使用して、月次定型レポートと随時の分析レポートを作成できる

関連しそうなデータをできるだけ多く収集し、分析を繰り返してどのように活用するか検討すればよいのでは？

―――　分析目的があいまいなままデータを収取すると、収集に時間と手間がかかる。その一方で、期待する成果が得られない可能性が高い。

• すべての会議の参加者、時間、頻度の見直しにより、一人当たりの会議時間を低減する
• 会議の目的区分を「アイディア創出」「意思決定」「情報共有」に区分
  • 情報共有については電子メールやチャットシステムなどで代替し削減する
• データ分析ツールを使って「会議開催実績表」を作成し、上記の効果を確認する

• 現在のデータ分析内容は、1日システムが停止しても事業運営に支障がない

• システムの有効活用のため、活用検討会を開催。

現在本番運用中のサーバからデータを収集しているが、今後詳細なデータを収集するため
取得元が本番環境では運用面でリスクがある。
　　↓
レプリケーションサーバを構築し、そこからデータを収集するなど本番運用のサーバとは別の場所から取得すべき

• 詳細なデータ収集により本番運用サーバの負荷が増大し、スケジュール管理システムのレスポンスが低下するリスクがある

• データ利用申請について、現状の運用フローでは個人情報にかかわるコンプライアンス確保が不十分。

　　　　　↓

サンプルデータ提供時に個人情報についてはマスキング処理を行っているか確認（ヒアリング）をする必要がある

• 要件検討会の議事録を閲覧
  • 業務停止の影響について検討せず、業務システム課の他システムとあわせてサービスレベルを設定しているだけだった

　　　　　　　　　　　　　　　　　　　　　↓

障害発生時の停止時間は1時間としているが、現在のデータ分析内容では1日システムが停止しても事業運営に支障がない。
従って、サービスレベルが高すぎることにより運用コストが高くなるリスクがある。

• 成果が得られない可能性を低減するための施策を行っているか確認する

　　↓
活用検討会の議事録を確認し、データ分析の目的が明確に説明されているかを確認する

• 会議開催実績表を確認し、確かに一人当たりの会議時間が減少していることを確認する