開発その2（システムライフサイクルの監査）

システムライフサイクルの監査／情報戦略／移行／
システムライフサイクルの監査／情報戦略／プロジェクトマネジメント／

今回はシステムライフサイクルの「開発」のチェックリスト作成の後半です。引き続き、チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。今回は、「移行」と「プロジェクトマネジメント」です。

1. 設計
2. プログラミング
3. テスト
4. 移行
   
5. プロジェクト・マネジメント

  必要な統制

1. 移行手順書
2. プロジェクトマネジメント資料
   

  チェックリスト

    4．移行

1. ユーザーを含めた移行の体制・役割、移行スケジュールは明確にされているか
• 移行手順書に移行の体制・役割、移行スケジュールが記載されていることを確認
2. 移行の妥当性確認方法、移行完了の判定基準は明確にされているか
• 移行手順書に移行の妥当性確認方法、移行完了の判定基準が記載されていることを確認
3. サービス・イン判定基準、判定プロセスは妥当か
• 移行手順書にサービス・イン判定基準、判定プロセスが記載されていることを確認
• サービス・イン判定基準、判定プロセスの根拠を確認
4. 移行のコンティンジェンシープランは策定されているか
• 移行手順書にコンティンジェンシープランが記載されていることを確認
  
5. 開発されたシステムを正しく利用できるように、ユーザー研修が実施されているか
• ユーザー研修の実施記録を確認
  

    5．プロジェクト・マネジメント

1. 進捗遅延等の問題発生に対する対策が講じられているか
• プロジェクトチームのミーティング記録から対策検討の実施を確認
  
2. 必要に応じてユーザーが品質の確認に参加しているか
• プロジェクトチームのミーティング記録からユーザーが品質の確認に参加していることを確認
• 参加していない場合はその理由を確認
  
3. プロジェクト推進過程で新たなリスクが予想される場合、リスク予防策もしくは不測事態計画が追加されているか
• プロジェクトチームのミーティング記録からリスク予防策・不測事態計画が検討されていることを確認
• プロジェクトマネジメント資料に追加施策が反映されていることを確認
  
4. フェーズごとの実績から、システム完成時のコストを予測しているか
• プロジェクトマネジメント資料にコスト予測が記載されていることを確認
  
5. 予算に対して実績が大きく超過するような場合、原因分析の上、対策が講じられているか
• プロジェクトチームのミーティング記録から予算超過の原因分析や対策検討が実施されていることを確認
  
6. 要員数だけではなく、投入する人材のスキルを勘案した要員計画が策定されているか
• プロジェクトマネジメント資料にリソースのスキルに関する記述があることを確認
  
7. プロジェクト・チームのメンバーの役割と責任権限が明確にされているか
• プロジェクトマネジメント資料からプロジェクトの体制を確認
  
8. 変更実施が、直接的な関わりをもつかもしくはその影響を受けるすべての関係者に知らされているか
• プロジェクトチームのミーティング記録から変更に関する伝達が行われていることを確認
  
9. プロジェクト・チーム内で、問題指摘、問題共有がされているか
• プロジェクトチームのミーティング記録から問題の指摘・共有が行われていることを確認
  
10. 必要かつ正確な情報が、タイムリーに開示されているか
• プロジェクトチームのミーティング記録からミーティングが適時に開催され、情報伝達がなされていることを確認

開発の監査を行うにはSEの人たちが作成・使用しているドキュメントに何があるかを知る必要があると思いました。次回から「運用」の監査に入ります。

開発その１（システムライフサイクルの監査）

システムライフサイクルの監査／開発／設計／
システムライフサイクルの監査／開発／プログラミング／
システムライフサイクルの監査／開発／テスト／

今回はシステムライフサイクルの「開発」のチェックリスト作成に挑戦します。チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。開発の構成は、

1. 設計
2. プログラミング
3. テスト
4. 移行
   
5. プロジェクト・マネジメント

となっています。今回は１．設計と２．プログラミング、３．テストについてチェックリストの作成に挑戦します。

  必要な統制

1. 要求仕様書
2. プログラム仕様書
   
3. プログラミングルール
   
4. テスト仕様書
5. 障害記録

  チェックリスト

1. 設計
1. 入出力仕様、業務処理仕様、セキュリティ仕様、障害・災害対策の検討は、ユーザー要件に基づいて行われているか
• 仕様検討の会議の記録から、入出力仕様、業務処理仕様、セキュリティ仕様、障害・災害対策の検討にユーザー部門の参加があることを確認
2. ピーク時のデータ量を想定した処理時間や応答時間が考慮されているか
• 要求仕様書に、データ量の想定や達成すべき処理時間・応答時間が記載されていることを確認
  
3. 関連するシステムの間のインターフェース、サブシステム間の整合性に関して検討が行われているか
• 要求仕様書に、関連するシステムに関する事項が掲載されていることを確認
  
4. 障害・災害発生時の代替機能、復旧時間、復旧手順・復旧作業等の、障害・災害対策の検討がされているか
• 要求仕様書に、障害・災害発生時の対策と対応基準について記載されていることを確認
  
5. システム設計の成果物が明確になっており、内容について、関係部門によるレビューが行われているか
• プログラム仕様書に、予定成果が記載されていることを確認
• ヒアリング等で関係部門が予定成果について認識していることを確認
  
2. プログラミング
1. プログラミングは定められた標準にしたがって行われているか
• プログラミングルールが存在していることを確認
• 開発部門のミーティング記録からプログラミングルールの確認が行われていることを確認
  
2. プログラム仕様書に基づき、プログラミング内容のレビューが行われているか
• 開発部門のミーティング記録からプログラミング内容のレビュー実施を確認
  
3. プログラム・テストの予想結果は事前に明らかにされているか
• テスト仕様書にプログラムテストの予想結果が記載されていることを確認
  
4. プログラム・テスト・ケースは網羅的に作成されているか
• プログラム・テスト・ケースの選定基準を確認
  
3. テスト
1. ユーザーを含めたテスト体制・役割・テスト・スケジュール、テスト実施項目は明確にされているか
• テスト仕様書に、ユーザーテストの仕様が記載されていることを確認
  
2. テスト結果の検証方法が明確にされているか
• テスト仕様書に、テスト結果の検証方法が記載されていることを確認
  
3. テストの実施には、ユーザーが参加し、ユーザーによるテスト結果の検証が行われているか
• 開発部門のミーティング記録からユーザーの参加と結果検証の実施を確認
  
4. テストで発生した障害は、速やかに原因が分析されているか、また、記録されているか
• 開発部門で管理する障害の記録を確認
  

開発の監査について、監査人にプログラミングそのものの知識を求めるべきではないと思いますが、ソフトウェアの開発工程に関する知識は必要だと思います。

企画（システムライフサイクルの監査）のチェックリスト

システムライフサイクルの監査／企画／

今回はシステムライフサイクルの「企画」のチェックリストの作成に挑戦します。チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。

  必要な統制

1. （案件ごとの）システム企画書
1. 目的
2. 範囲
3. スケジュール
4. 費用対効果
   
2. プロジェクト管理資料
1. スコープ・期待される成果
2. 体制
3. 開発規模・工数
4. コスト
5. スケジュール
   

  チェックリスト

 　（青字はコメント）

1. 企画
1. システムの目的は経営戦略に適合したものか
• システム企画書とIT計画書に記載されている目的が整合しているか確認
  
2. システム化の範囲は明確にされているか
• システム企画書にシステム化の範囲が記載されていることを確認
  
3. 開発対象システムの実現可能性が検討されているか
• システム企画書に具体的なスケジュールが記載されているか確認
4. 費用対効果の算出根拠が明らかにされているか
• システム企画書に案件ごとの費用対効果算出根拠が記載されているか確認
  
2. プロジェクト計画
1. ユーザーの満足度基準が明確にされているか
• プロジェクトのスコープにユーザーの満足度の基準が記載されていることを確認
• ユーザーの求めているものを明確にすることと解釈
  
2. プロジェクトの体制、開発規模・工数、コスト、スケジュールは明確にされているか
• プロジェクト管理資料に体制、開発規模・工数、コスト、スケジュールが記載されていることを確認
  
3. 開発工数・スケジュールで、問題対応、リスク対応等、プロジェクト・マネジメントに係る対応が見積もられているか
• プロジェクトのスケジュールに問題対応、リスク対応等、プロジェクト・マネジメントに係る工数が見積もられていることを確認
4. 進捗管理、変更管理、品質管理、問題管理についての管理方法が明確にされているか
• プロジェクト管理資料に進捗管理、変更管理、品質管理、問題管理の管理方法とアウトプットイメージがあることを確認
5. 必要なスキル、要員数等資源の調達量および時期が明確にされているか
• プロジェクトのスケジュールに要員数等資源の調達量と時期が記載されていることを確認
  
6. プロジェクトの成果が及ぼす影響が明確にされているか
• プロジェクト管理資料にプロジェクトの成果物についての記載を確認
  
7. 各フェーズの開始・完了を確認するための条件が明確にされているか
• プロジェクト管理資料に各フェーズの達成目標と条件の記載を確認
  
8. プロジェクト計画の内容はユーザー部門と合意されているか
• プロジェクトの説明会の実施記録を確認

特に、プロジェクト計画を監査するにはプロジェクトマネジメントの知識が必要であると感じました。次回は「開発」です。

賀詞交歓会に行ってきました

本日、社団法人日本内部監査協会の賀詞交歓会へ行ってきました。
会場は、昨年と同様、地下鉄日比谷線の神谷町からほど近いホテルオークラ東京別館のアスコットホールです。
開宴10分前に到着したのでクロークと受付はかなりの混雑でした。
定刻よりやや遅れて開宴。伏屋会長の挨拶の後、乾杯～歓談という流れで進みます。
昼食時間帯なこともあり、きちんと食事をする立食パーティです。（笑）
昼の会合なのでノンアルコール飲料をもう少し充実させてくれるとありがたいと思います。

参加者をざっと見た感じでは法人会員の方が多いように感じました。
個人のCIAの皆さんの参加が増えればさらに輪が広がるかもしれません。
個人的には、昨年途中から研究会に参加したため、顔見知りの人が増え、お世話になっている方に新年のあいさつができました。年初にこのような機会があることは良いことだと思います。

来年はもっと知り合いが増えるように今年の活動をがんばりたいと思います。

ThinkPad改良！

昨日に引き続き、ThinkPadのお話です。

ハードディスクの残容量が少なくなったので秋葉原の若松通商に行きました。
若松通商ではHDDデータ移行サービスをやってくれます。
早速、ThinkPadを持ち込み、HDDの換装とメモリの増加、そして、調子の悪かったDVDドライブの交換をお願いしました。
残念ながらSSDは品切れだったので今回はHDDです。
移行には特に料金はかかりません。しかも1時間程度で移行完了です。

お昼前に持ち込んで、昼食後に引取りました。
しめて、20,940円（消費税込み）。

この結果、
ハードディスク：60GB→320GB（しかもスピードアップ！）
メモリ：1.5GB→3GB
DVDドライブ：CD-RW, DVD ROM→DVD MULTI RECORDER, CD-RW
に機能アップしました。

不足する機能をたった2万円分補強するだけで、まだまだこのThinkPadは使えそうです。

ハードディスク残容量の危機

今日は三連休中日バージョンです。

購入してからもうすぐ4年になる愛用のThinkPadのハードディスクの残量がわずかになってきました。
「そろそろWindows７を使いたいなぁ」とか 「DVDドライブの具合も少し悪いしなぁ」とか思っていたところに追い打ちをかけるようにハードディスクの残量不足が近づいてきました。

今までの私ならこの機会に新しいPCを買おうとするのですが、今回は地球に優しく（？）ハードディスクのアップグレードに挑戦しようと思います。
というわけで、明日は秋葉原へ行ってきます。 （つづく）

Wiiをネットにつなぐリスクとコントロール

週末なので内部監査を少し離れてネットのリスクの話です。

ニンテンドーのWiiをネットにつないでみました。
一般的な無線LANの接続要領で簡単につながります。
無線LANのセキュリティは今時の安全な接続が可能です。

ネットにつなぐと、Wiiで使えるゲームソフトのダウンロード ができるようになります。
それだけではなく、メールもWebサイトの閲覧もできるようになります。
USBのキーボードも使えるのでPCと同じ感じです。

当然ながら、検索もできます。ちゃんとGoogleで検索できます。
したがって、こんなページも見られます。

爆弾だけではなくアダルトサイトも閲覧できます。

こどもが使うゲーム機でここまでできてしまうのは明らかに危険です。

とりあえず、Webブラウザはペアレンタルコントロール下においてパスワードロックをかけました。（パスワードはたったの4桁です。）

Wii側からもフィルタリングソフト（有料）の案内もありますが、もう少しメーカー側でのガードが必要だと思いました。