IT成熟度をどのように向上させるか

東京

A4
ＫＰＭＧビジネスアシュアランス株式会社
シニアコンサルタント

16:00

吉川 正弘

定義された標準プロセスに従って業務が進められているか

はじめに
ここでは、IT成熟度（※1）をどのように向上させていくか、つまりどのようにITリスクを認識し、予防／発見的なコントロールを設定／実施し、強化していくか、をテーマとする。筆者
は、年間35社以上のクライアントに対してシステム監査を行っており、その経験から、どうすればスムーズかつ着実にIT成熟度を向上させられるかを、できるだけ具体例を交えながら解説していきたい。

モニタリングしている（また、その体制がある）
・レベル 3 ：定義されている
標準プロセスがきちんと定義され、組織としてそれを認証している・レベル 2 ：反復可能標準プロセスがあり、ほとんどがそのプロセスに従って業務をこなしているが、遵守は個人に依存している・レベル 1 ：初歩的場当たり的な対処・レベル 0 ：存在しない

1．IT成熟度を高めていくことの必要性
IT リスクには次のように多種多様なものが存在する。

ルールや問題についての認識がない
ここで留意すべき概念として、「IT 成熟度の広がり」が挙げ（図− 1 参照）られる。IT成熟度の広がりには、縦の広がり、横の広がりがあ・経営戦略に沿わない IT 投資

り、それぞれ次のようになる。

・基幹システムダウン

縦の広がり：ITにとどまらない全社的なコントロールの向・不正アクセスや顧客情報漏洩

上（経営の成熟度の向上）、更には、社会の IT 成熟度の向上

・システムの開発遅れやコストオーバー（高度 IT 活用社会の実現）に繋がっていくこと。

・プログラムバグ

横の広がり：自社単独ではなく、ソフトハウスや社外デー・運用ミス

タ／運用センターといった、IT 開発･運用の委託先、グルーこれらの事態が発生した場合、ビジネスに多大な影響を及ぼプ企業等との協働に繋がっていくこと。

すものも少なくない。
例えば、経営戦略に沿わないIT投資を行ったことによる投資回収期間の長期化、基幹システムのダウンによる取引先への迷従って、IT 成熟度の向上を検討する際には、IT コントロー
ル、もしくは自社の問題、としてだけ捉えるのではなく、IT以外、自社以外への影響を検討する必要がある。

惑、顧客情報漏洩による顧客離れ、等が挙げられる。
自社で起こり得るITリスクとは何かを、全く把握していなけ
れば、問題が表面化してから対応を行わざるを得ず、常に対応

それでは、IT成熟度を如何に向上させていくべきなのであろうか。

は後手に回ることになる。つまりどこに地雷が埋まっているか分からずに地雷原を歩いているようなもので、非常に危険な状
況だと言える。
逆に、ITリスクの状況（どのようなことが起こり得るか、発生可能性、発生した場合のビジネスへの影響）を把握し、それ2．IT成熟度向上の手順
IT成熟度向上のための手順は、次のサイクルを回していくことである。（図− 2 参照）

ぞれのリスクに対するコントロール（予防／発見等の措置）を①現状の把握、② IT リスクの洗い出しと評価、構築しておけば、必要以上に恐れることはない。

③改善策の策定、④改善策実施、⑤フォローアップ（改善策の評価）

コントロールの構築に関しては、成熟度の概念が非常に参考になる。
コントロール成熟度の例として、ここでは、COBIT（※ 2）の 6 段階（レベル 5 〜 0）の成熟度を挙げる。
・レベル 5 ：最適化されている
標準プロセスを改善･改良し、常に最適化された状態を維持している・レベル 4 ：管理されている

確実にこれらの手順を進めていくためにも、①〜⑤のステップごとに責任者および実施期限を定め、それぞれのステップ終了時には、成果物をきちんと文書で残しておく必要がある。
それぞれのステップ終了時の成果物としては、例えば次のよ
うなものが挙げられる。
①あるべきコントロールと現状の対比表②ITリスク一覧表（緊急性、重要度等により評価を行ったも83しまう。の）③改善策の実施計画書②システム部門直属の利用部門に便宜を図るようなシステム開発やシステム変更を行う（システムの全体最適化が図ら④関係者への実施説明資料、整備した規程類れない）。

⑤改善策の評価報告書

このように、現状からどのような問題点が引き起こされる可次に、これらステップについて、留意点を解説する。実施に能性があるかを検討することが必要である。

あたっては、必要に応じて専門家の助力を仰ぐのが望ましいことが多い。

IT リスクの洗い出しについて、もう一つ例を挙げる。
採用したフレームワークで、システム運用のコントロール目（1）現状の把握
現状を把握するには、例えば情報システム部門の体制や、システムの開発手順といったITプロセスに関する何らかのフレー

標の 1 つが「利用部門の業務運用マニュアルを整備すること」となっているが、現状では業務運用マニュアルがなく、運用が担当者に依存していたとする。

ムワークを使用するのが望ましい。フレームワークを使用する

ここでの問題は、やはり業務運用マニュアルが整備されていことにより、検討漏れや、偏りを防止し、また、自社の全体状ないことそれ自体ではない。「業務運用マニュアルが整備され況を一覧できる、というメリットがある。ていないこと」としてしまうと、改善策は、「業務マニュアルフレームワークの中には、コントロール目標（あるべき姿）を整備すること」となる。しかし、現状では問題なく運用が行が設定されており、コントロール目標と比べて現状がどうなっわれている、とシステム部門が認識していれば、業務運用マニているかを確認できるようになっているものもあり、ITライフ

ュアルの整備への着手には抵抗感が強い。

サイクル全般を網羅的に捉えているものを利用すべきである。

「業務運用マニュアルが整備されていないこと」が引き起こ

例えば先出の COBIT では、4 つの管理プロセスの中で 34 の ITすと考えられる問題点には、例えば次のようなものが挙げられプロセスを評価するフレームワークとなっている。

る。

現状の把握は通常、組織図や開発手順、資産管理規程等の文①オペレーションが利用部門のオペレータに依拠されること

書類の査閲、関係者（主にシステム部門）への質問表の送付やで、処理の均一化がしづらい（継続性の保持が困難）こと

ヒアリング、ハードウェアの設置場所や利用部門への視察等を（特にデータ修正等のイレギュラー処理において、この傾通じて実施する。

向は顕著である）。
②急な要員交代時の引継ぎが困難なこと（2）IT リスクの洗い出しと評価
現状を把握した後で、コントロール目標とのギャップを整理①について例を挙げる。例えば、会計システムであれば、先し、ITリスクの洗い出しを行う。ここで留意すべきは、ギャッ

月入力･確定したデータに誤りが見つかった際のデータ修正のプが即、IT リスクとならない点である。ギャップは原因であ対応時には、次のような事項を判断する必要がある。

り、ギャップから発生するITリスク（問題、結果）を把握する

・誤った伝票取消のために、金額をマイナスした仕訳を入力するのかことが重要になる。

・誤った伝票取消のために、貸借逆の仕訳を入力するのか
例えば、採用したフレームワークで、システム部門の体制に・それらの仕訳を入力する際に、また修正した伝票を同時についてのコントロール目標の1つが、「システム部門は利用部門（セットで）登録するのかから独立していること」となっており、現状では、システム部・修正時の伝票番号をどのように採番するか門はなく、システム課が経理部門の下にあったとする。

・修正時の伝票の摘要欄に何を記載するか

ここでの問題を、「システム部門（課）が利用部門から独立これらの事項に関して、オペレータごとに処理が異なっていしていないこと」、としてしまうと、改善策は「システム部門ては、処理の妥当性の検証がしづらく、処理が誤っていても検を独立させること」となる。通常、組織改編はシステム部門だ

出されない可能性がある。

けではなく、全社的なバランスの基に実施されるものであり、組織戦略、人事戦略に係るため、すぐに何らかの手を打つのはこのように、あるべき姿とのギャップから、具体的にどのよ難しい場合が多く、このままでは有効なコントロールの設定がうな問題が発生するかを把握するのがITリスクの洗い出しであ難しい。

る。

ここで重要なことは、「システム部門が利用部門から独立し具体的な IT リスクの洗い出しの後、各 IT リスクを発生可能ていないこと」自体は問題ではなく、現状（あるべき姿とのギ性（頻度）、発生した場合のインパクト（影響度）で評価し、ャップ）であって、それによりどのような問題（ITリスク）が取り組むべき IT リスクの優先順位付けを行う。

引き起こされるかを検討する必要があることである。
「システム部門が利用部門から独立していないこと」による

84（3）改善策の策定

問題点は、会社によって異なってくるものと思われるが、例え（2）のITリスクの洗い出しにより、具体的な問題点が明確にば次のようなものが挙げられる。

なっていれば、改善策の策定はそれほど難しくはない。

①利用部門の指示により、直接データの（不正）操作を行っ例えば（2）の「システム部門が利用部門から独立していなたり、データ修正を行うプログラムの提供を行ったりしていこと」で挙げた問題点①や②に対して、やはりもっとも望ましい改善策は、「システム部門（課）の独立」となる。しかし、り、協力を取り付けやすくなる。また、説明の際には、ITリスそれが難しいとなれば、次善の策として次のようなものが考えク発生の原因を特定部門の責任としないよう、表現に注意を払られる。

うことも重要である。

・利用部門からシステム課に対して、データ操作の指示が行われていないかどうかを、独立した部門（内部監査部門等）が定期的に確認する・システム変更の意思決定がシステム課の直属の利用部門に

3 点目は、関係者ごとの IT に関する責任を考慮した上で、どの関係者にコントロールを設定するのかを検討することである。（図− 3 参照）

より影響を受けていないかの調査を行う
・運用規程、開発規程等に、他部門の指示による（不正）デ（1）〜（3）をより深く理解していただくために、現状、問題点、ータ操作の禁止や、特定の利用部門に便宜を図ったシステ

改善策をまとめた他の例を用意したので、参考にされたい。

ム開発を禁止するといった条項を盛り込み、周知する。

（図― 4 参照）

これらの手続を設定することで、不正の予防、発見可能性を高め、さらにシステム課とその直属の利用部門に対する牽制機能を持たせることができる。

（4）改善策実施
改善策の実施にあたっては、責任者と期限を定め、必要があれば関連部署（場合によっては委託先や関係会社等、社外も含

また、（2）で挙げた「利用部門の業務運用マニュアルが整備されていないこと」については、オペレータが処理方法を迷ったり、実際に処理方法が異なったりしているようなイレギュラむ）と協働しながら実施することが重要である。
実施の際には、実施が適切に行われたか、効果的かを確認するために、フォローアップの周期を定めることが望ましい。

ーケースを中心に、重要性の高いシステムから、対応を文書化

また関連部署と一緒に検討する際には、実施メリットと、実（最初はメモ書き程度でも良い）していくのが現実的である。

施しない場合のリスクをよく吟味、理解しながら、合意を形成

最初から全体を作成するのではなく、重要度の高い部分から文しつつ進めていくことが必要となる。

書化を進め、徐々に完成度を高めていけば良い。
例えば、システムアクセスに関して、次のような検討を行い、このように問題点が明確であれば、改善策も現実的かつ具体的に設定することが可能となる。
新たなコントロール（改善策）を策定する際には、次の 3 点に留意すると良い。

改善策を決定したとする。
コントロール目標：利用部門で不要なユーザ、及び権限の定期的な確認は行うこと
現状：利用部門で不要なユーザ、及び権限の定期的な確認を行っていない

1 点目は、改善策の実施には、人／時間／費用といった経営問題点：①退職者や異動者のユーザIDが不正使用される可資源を投入する必要があるため、効果的かつ効率的なものを選能性がある、②適切な権限ではなく、以前の権限のままでの択する必要があることである。

使用が行われる可能性がある

コントロールには、予防的コントロール、発見的コントロー

改善策：ユーザ ID およびユーザ ID ごとの権限一覧を各利ルがあり、一般的に予防的コントロールのほうがコスト高とな用部門に配布し、適切な権限設定となっていることを定期的る。に（半期に一度程度）確認させ、利用部門長の承認の上で、上記の例でいえば、システム部門を独立させたり（つまり組システム管理部門に提出させる織上、不正データ操作を行う指示そのものを出せなくする）、規程類を整備したりすることが予防的コントロールであり、他改善策のスムーズな実施のために、関連部門に対しては、現部門により不正が行われていないかどうかを確認するのが発見状と問題点を説明し、なぜそのような取組を行う必要があるか的コントロールである。

を理解してもらう必要がある。上記の例では、システム部門だ

なお、コントロールは、効果的で、ITリスクに緊急性がある

けではユーザIDとそれぞれの権限の把握は難しいこと、ユーザものから設定すべきであるため、（2）で洗い出したリスクの重IDが不正使用された場合、被害が甚大だと予想されること、を

要性もしくは発生頻度が低い場合やコントロールの設定に多大訴えると良い。このように問題点が具体的に整理されていれば、なコストがかかる場合は、リスクの最適化という観点からは、比較的関連部門の協力は得やすい。

「何もしない」という選択もあり得る（例えば、火災や地震対策として、重要性の低いシステムに対しては、システムの二重化といった施策を行わない、等）。

（5）フォローアップ（改善策の評価）（4）で決定したタイミングで、フォローアップ（改善策の評価）を行う。

2点目は、改善策の策定の際には、教科書的なものではなく、実際には設定したコントロールが有効に機能し、運用されて実現可能なものを選択していくことである。最初から満点を目いるかを、関係者へのヒアリングや関連資料のサンプリングチ指すのではなく、徐々にコントロールを強化（成熟度の向上）

ェック等を行い、確認する。予定通りの成果をあげていない場を図っていけば良い。

合は、コントロールの改善を行っていくこととなる。

（2）で具体的な問題点が明らかになっており、問題点が発生した場合の影響を説明できれば、比較的現場の抵抗も少なくな85おわりに
ここまで、IT成熟度をどのように向上させていくか、その際の留意点は何かを、筆者の経験を交えて解説してきた。
最も大切なことは、まず起こり得るITリスク自体を認識すること、そして、限られた経営資源の中で、無理なく（徐々に）IT 成熟度を高めていくよう、常に改善を行っていく姿勢である。
（注 1）： IT 技術の利用度合、ネットビジネスの浸透度、ブロードバンドの普及率、等を意味する場合もあるが、ここで言う「IT 成熟度」は、「IT リスク管理の成熟度（IT コントロールの進展度合）」のことである。
（注 2）： Control Objectives for Information and related Technology。
米国の情報システムコントロール協会（ISACA ： Information
Systems Audit and Control Association）が提唱するITガバナンスの成熟度を測るフレームワーク。

86