システム調達を人任せにしない――好みで決めるのもダメ：今日から学ぶCOBIT（4/5 ページ）

[谷誠之，ITmedia]

　コントロール目標の詳細は、次のようになっている。

---

• AI2.1 概要設計

組織の技術的方向性や情報アーキテクチャを考慮の上、ビジネス要件をソフトウェア開発の概要設計仕様に反映させる。さらにこの概要設計がビジネス要件に確実に対応していることを踏まえ、設計仕様への承認を得る。

• AI2.2 詳細設計

詳細設計およびソフトウェアアプリケーションの技術的要件を策定する。このとき、要件の受け入れ基準も定義する。この要件が、概要設計に確実に対応していることを踏まえ、要件への承認を得る。検討すべき項目として、インプット要件の定義と文書化、インタフェース定義、ユーザインタフェース、ソースデータの収集設計、プログラム仕様、ファイル要件の定義と文書化、処理要件、アウトプット要件の定義、コントロールと可監査性、セキュリティと可用性、およびテストなどの事項も適宜考慮する必要がある。開発または保守の際に重大な技術的矛盾または論理的矛盾が生じた場合は、評価を再度実施する。

• AI2.3 業務処理統制および可監査性

ビジネスコントロールが業務処理統制に適切に反映され、それにより、処理が正確、完全かつタイムリーとなり、承認され監査可能になることが必要である。特に検討すべき項目として、認可方法、情報のインテグリティ、アクセスコントロール、バックアップ、および監査証跡の記録方法が挙げられる。

• AI2.4 アプリケーションのセキュリティおよび可用性

アプリケーションのセキュリティおよび可用性は、識別されたリスク、データの機密区分、組織の情報セキュリティアーキテクチャおよびリスクプロファイルに対応した要件を目指すこと。課題として考慮すべき項目は、アクセス権と特権の管理、全てのプロセスにおける重要情報の保護、認証やトランザクションのインテグリティおよび自動回復である。

• AI2.5 調達したアプリケーションソフトウェアの構成および導入

調達したアプリケーションを、構成、受け入れ、およびテストの手続によりカスタマイズし、導入する。検討すべき項目として、契約条項に照らし合わせた検証、組織の情報アーキテクチャ、既存アプリケーション、既存アプリケーションとデータベースシステムとの相互運用性、システムパフォーマンスの効率性、文書およびユーザマニュアルの作成、統合計画およびシステムテスト計画などが挙げられる。

• AI2.6 既存システムの大幅なアップグレード

現行の設計や機能に多大な影響を及ぼす大幅な変更を既存システムに加える場合、新規システムの開発の場合と同様の開発プロセスに従う。検討すべき項目として、影響分析、費用/便益の調整、要件の管理などが挙げられる。

• AI2.7 アプリケーションソフトウェアの開発

アプリケーションが、確実に設計仕様、開発標準と文書化標準、および品質要件に従って開発されるようにする。アプリケーションソフトウェア開発プロセスの主要な各段階において、機能レビュー、パフォーマンスレビュー、品質レビューで問題がないことを確認し、承認する。検討すべき項目として、設計仕様がビジネス要件、機能的要件、および技術的要件を満たしていることの承認、変更要求の承認、アプリケーションソフトウェアが本番環境に適合し、また移行可能であることの確認などが挙げられる。さらに、サードパーティが開発したアプリケーションソフトウェアに関して、法律上および契約上のすべての側面が、確実に識別され、対応されるようにする。

• AI2.8 ソフトウェアの品質保証

要件定義および組織の品質に関するポリシーと手続で規定された品質を確保するために、ソフトウェア品質保証計画を策定、提供し、実施する。品質保証計画で検討すべき項目として、品質基準の規定、および検査、ウォークスルー、テストを含む検証と確認のプロセスなどが挙げられる。

• AI2.9 アプリケーション要件の管理

設計、開発、導入の際に、個々の要件(否認されたすべての要件を含む)の状況が確実に追跡され、要件への変更が、確立された変更管理プロセスを経て確実に承認されるようにする。

• AI2.10 アプリケーションソフトウェアの保守

ソフトウェアアプリケーションの保守およびリリースに関する戦略と計画を策定する。検討すべき項目として、リリースの計画とコントロール、資源調達計画、バグ修正と不具合修正、小規模な機能拡張、文書の改訂、緊急変更、他のアプリケーションやインフラストラクチャとの相互依存性、アップグレード戦略、サポートやアップグレードなどの契約条件、そしてビジネス上の必要性、リスク、およびセキュリティ要件に対する定期的なレビューなどが挙げられる。

---

　セキュリティや可用性に関しては、導入前から細心の注意を払う必要がある。また、「どの程度の品質が確保できていればよしとするか」という品質基準や、「その品質を確保するためにはどうするか」といった保証計画といったようなものも、この段階で明確にしておく必要がある。

　「マネジメントガイドライン」は、図2から図4の通りである。関連のある他プロセスのアウトプットの中に「サービス・レベル・アグリーメント（SLA）」があるのが興味深い。念のためにSLAとは、サービス提供者と利用者が互いに合意した、サービスの具体的な内容と品質を定めたものである。どんな形にせよ、SLAは明確に定めておく必要がある。利用者はサービスを過大に期待するし、サービス提供者にとっては、利用者はやっかいな存在以外の何者でもないからである。

図2：インプットとアウトプット

図3：RACIチャート

図4：達成目標とその評価指標