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

» 2008年04月03日 08時00分 公開
[谷誠之,ITmedia]
  • AI1 コンピュータ化対応策の明確化

新しいアプリケーションや機能を必要とする場合は、実際の調達または構築の前に、それらがビジネス要件を効果的かつ効率的なアプローチで確実に満たすものであるか分析する必要がある。この分析のプロセスには、ニーズの定義、代替となる調達元の検討、技術的および経済的実現性の見直し、リスク分析および費用対効果分析、アプリケーションを「開発」するか「購入」するかの最終決定が含まれる。これらすべての手続を踏むことにより、ソリューションの実施および導入費用が最小限に抑えられ、ビジネス目標の達成を確実に支援できるようになる。


(要約) COBITでは何度も触れているが、ITとはビジネスを支援するために存在しているものである。それはITを調達する段階でも忘れてはならない。調達を予定しているITがちゃんとビジネス要件を満たすものがどうか、正しく判断する必要がある。また、ITの調達にはリスクが付きものである。さまざまなリスクを考え、リスクが顕在化した時のためにあらかじめ代替案を考えておこう。IT調達が原因でビジネスに悪影響を与えてしまったら、本末転倒である。

  • AI2 アプリケーションソフトウェアの調達と保守

アプリケーションは、ビジネス要件に沿った形で利用可能になっている必要がある。このプロセスには、アプリケーションの設計、業務処理統制とセキュリティ要件の適切な組み込み、および各種標準に準拠した実際の設計と構成が含まれる。このプロセスにより、組織は自動化された適切なアプリケーションを利用して、ビジネス運営を的確に支援できる。


(要約) ITの調達、ことにアプリケーションの調達においては、その導入前に受け入れ基準を決めなければならない。アプリケーションに期待する「品質」とは何なのか、ということを明確に定義しておく必要があるのだ。また、導入段階においてセキュリティ面、可用性面、既存のアプリケーションとの整合性、そして監査面などの点において十分な検討が必要である。それらが担保されてこそ、アプリケーションがビジネスを正しく支援できると言える。

  • AI3 技術インフラストラクチャの調達と保守

組織は、技術インフラストラクチャの調達、導入、およびアップグレードに関するプロセスを策定する必要がある。これを実現するには、合意された技術戦略に基づいてインフラストラクチャを調達、保守、および保護するためのアプローチを計画し、開発環境とテスト環境を用意する必要がある。この結果、ビジネスアプリケーションに対する継続的な技術的サポートが確保される。


(要約) ITインフラの調達は、アプリケーションの調達と似て非なる注意が必要である。可用性面、監査面での検討はもちろんのこと、技術的なリスク、移行に関する費用や社員教育に関する費用、その使用期限、保守などについても細かく考えておく必要がある。ITインフラが正しく導入・動作しなければ、その上で動作するアプリケーションもビジネスに便益をもたらさないであろう。

  • AI4 運用と利用の促進

新たなシステムに関する知識を利用可能にする必要がある。このプロセスでは、ユーザおよびIT部門のための文書や資料を作成し、アプリケーションとインフラストラクチャの適切な使用と運用を確保するための研修を実施する。


(要約) 導入すればおしまい、ではない。新たに導入したアプリケーションやITインフラが、ビジネスに対してきちんと便益をもたらすように使えるかどうかは利用者にかかっている。そのためにはさまざまな情報の文書化、管理者教育、エンドユーザ教育、運用スタッフ教育を怠ってはならない。

  • AI5 IT資源の調達

要員、ハードウェア、ソフトウェア、サービスを含むIT資源を調達する必要がある。そのためには、調達手続の策定と実施、ベンダの選定、契約等の整備、および実際の調達が必要である。これらを行うことにより、組織はタイムリーかつ費用効率よく、必要なIT資源をすべて確保可能になる。


(要約) 何をどこから調達するのか、ベンダと自社組織との役割や責任の分担はどうするか、実際の導入はいつ、どのように行うのかということを整合性のとれた手法で管理しなければならない。ベンダとの契約には、技術的な内容のみならず、法律的な観点や支払の観点などにおいても十分注意が必要である。

  • AI6 変更管理

インフラストラクチャおよびアプリケーションに関連する緊急保守やパッチ適用を含む、本番環境におけるすべての変更は、コントロールされた方法で、正式に管理されなければならない。変更(手続、プロセス、システムパラメーター、およびサービスパラメーターを含む)は、変更の実施前に記録、評価、および承認されなければならず、変更の実施後には計画された成果に照らしてレビューしなければならない。これにより、本番環境の安定性やインテグリティに悪影響を及ぼすリスクを低減できる。


(要約) 導入後の保守において、IT資源に対してさまざまな変更が必要になってくる場合がある。その変更はすべてコントロールされていなければならない。コントロールされていない変更がビジネスに悪影響をもたらすことは日常茶飯事だが、それを許してはならない。変更がすべて正しくコントロールされていれば、変更による悪影響を最小限に抑えることが可能となる。

  • AI7 ソリューションおよびその変更の導入と認定

新規システムの開発完了後、そのシステムを実際に運用可能な状態にする必要がある。これには、適切なテストデータを使用した専用環境における公式的なテストの実施、展開と移行の指示書の策定、リリース計画策定と実際の本番環境への移行、および導入後のレビューが必要である。これにより、運用システムが合意された計画と成果に合致していることを保証する。


(要約) 保守における変更を本番環境に実施するためには、導入計画、テスト計画、実際の導入、テスト結果のレビューなどが盛り込まれている必要がある。また、要員への教育計画も変更の中に含まれる。これらはすべて、実際に変更を実施するより前に、関係者の合意を得る必要がある。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ