日本版SOX法・徹底解析

今やビジネスとITは不可分の関係にある。ITシステムが正常に動けばビジネスが動き、ITシステムが止まればビジネス自体が止まる。今や「ITはビジネスそのもの」であり、「ビジネスはITそのもの」なのである。昨今、ITシステムの運用保守の改革手法として用いられているのが、「ITサービス・マネジメント」という概念であり、そのガイドラインがITILである。

本稿では、「ライフサイクル・アプローチ」の採用で注目を集める最新のITILR V3を中心に参照しながら、ITサービスマネジメントの実践に関する考え方について考察してみたい。（IT Initiative vol.01より転載）

http://enterprisezine.jp/article/detail/746

開発コミュニティが集結。イベント情報など満載！

[PR] 開発コミュニティの情報コーナー。コミュニティの紹介から、各種イベント情報を掲載。開発者を支援します。新規コミュニティの受付も募集中！！

ITサービスマネジメントが求められる背景

　"IT is Business. Business is IT."　ITIL（IT Infrastructure Library）の冒頭に書かれている文章である。企業は、ビジネスを革新もしくは効率化していくために、様々なITシステムの導入を行ってきた。

　その結果、ITはビジネスに革新と効率化をもたらすと同時に、ビジネスはITに大きく依存することになった。つまり効果的なITシステムを導入すればビジネスが革新もしくは効率化し、逆に非効果的なITシステムを導入すればビジネスを非効率にする。

　そして、ITシステムが正常に動けばビジネスが動き、ITシステムが止まればビジネス自体が止まる。今やビジネスとITは切っても切れない関係で、「ITはビジネスそのもの」であり、「ビジネスはITそのもの」なのである。　「ITはビジネスそのもの」であるほど重要にも関わらず、ITをインフラストラクチャの視点で見ると、大きな課題が浮かび上がる。

　IT黎明期ではITシステムは主にメインフレームにより構築され、メインフレームはITシステムの安定稼働に大きく貢献した。今日においても、「オープン系のITシステムよりメインフレームによるITシステムの方が安定稼働する」ことは、一般的に認識されている。　

　しかし、厳しい経営環境に置かれた企業は、メインフレームによるITシステム構築及び運用によるコストに耐えきれなくなり、ITシステムへの投資額削減を目的に、初期投資コストの低いオープン系ITシステムへメインフレームから移行する流れが主流になった。

　だがオープン系システムは、各社様々な規格・仕様を組み合わせて構築することからITシステムは複雑化・ブラックボックス化し、一度トラブルが発生すると影響範囲や根本原因の特定に時間が掛かり、ITのサービスレベルは大きく低下した。　

　同時に、オープン系ITシステムは初期投資コストこそ安いものの、前述した複雑化・ブラックボックス化したことにもよりシステムの運用保守コストが増加し、システム運用保守費用がITシステムTCO（Total Cost of Ownership）の7割をも占めるようになった。　

　サービスレベルの低下、TCOの増加の改善に向けて、サーバ・ネットワークの監視や、システムの運用や保守業務の自動化を実現する運用基盤の導入や、そもそも運用保守の一部ないし全体を外部受託会社へのアウトソーシングを実施するなどして、サービスレベルの維持とシステム運用保守コストの削減を目指して来たが、根本的な解決には至っていない。

　その結果多くの企業は、ビジネスの変化に対応した新規ITシステム導入に予算が掛けられない状態になっている。　そして極め付けが、日本版SOX法である。日本版SOX法の制定により、ITシステムは内部統制におけるIT全般統制への対応、つまり「ビジネスはITそのもの」という考えのもと、ITシステムに対するリスクマネジメントが求められるようになった。

　今まではITシステムの安定稼働を低い費用で実現させてさえすれば良く、「AシステムはBさんが踏ん張ってくれているから、なんとか上手くいっている」という、過度に特定の個人に依存した「属人化された運用保守」でも、良い状態では無いが大きな問題とはされて来なかった。

　しかし、リスクマネジメントの観点からみると、「Bさん」が職場を何かしらの理由によって離れることで、Aシステムを把握している担当者が存在しなくなり、何かトラブルが発生した時に対応が極度に後手に回るというのは大きなリスクであり、改善を行う必要が生じるのである。

　このように今までITシステムの運用保守では当たり前とまでは言わないが、ある程度「仕方ないこと」と捉えられていた状態が、「経営リスク上、絶対に避けるべきこと」に変わったのである。　このように、ITの重要性が高まりながらサービスレベルとコストの最適化及び法対応としてのリスクマネジメントまでを求められる状況であり、ITシステム運用保守の改革が求められている。

ITサービスマネジメントのベストプラクティス「ITIL」

　ITシステム運用保守の改革手法として昨今用いられているのが、ITサービスマネジメントの概念である。ITサービスマネジメントの「ITサービス」は、「テレビ」に例えると解りやすい。テレビを保有する目的は、何かの番組や映画を見るためである。

　決してテレビを保有すること自体が目的なのではなく、テレビは「テレビ視聴サービス」を提供するための手段なのである。　ITサービスもテレビと全く同じである。最近、ITシステムを保有せずに、自分たちの必要な機能のみをSaaS（Software as a Service）形式にて入手し、ITシステム自体の構築・保有を避けることでTCO（Total Cost of Ownership）を下げる事例も出始めている。

　このように、企業はITシステムを構築・保有することはあくまで手段であり、ビジネスでの成果を上げるために、自分たちのビジネスニーズに対応した「ITサービスを如何に高いサービスレベルを安い費用にて入手」するかが目的なのである。

　次にITサービスマネジメントの「マネジメント」を日本語に訳すと「管理」になるが、私はこの訳に大きな違和感がある。日本語で言う「管理」とは、「ある規準などから外れないよう、全体を統制すること」（大辞泉）であり、画一的で固いイメージを有する。

　しかし、マネジメントという概念を世界で初めて定義したドラッカー氏によると、マネジメントとは「共通の目標・価値観を持つ人たちが、適切な組織をつくり、訓練と研鑚によって、共同で成果を上げられるようにすること」と定義されている。

　つまりマネジメントとは、ある基準から外れているかいないかの「管理」ではなく、目標の達成もしくは目標を超える成果を目指すための「手法」なのである。　

　以上をITサービスマネジメントに当てはめると、「ビジネスニーズに対応したITサービスを適切なサービスレベルとコストを提供するために、最適のITシステムを構築し、パートナーと担当者から成り立つ組織を最大限活用することで、実現を目指す手法」となるのである。

　企業は旧態依然のITシステム運用保守のやり方を改め、ITサービスマネジメントの活動を通じて、ビジネス環境の変化や新たなビジネス機会に対応したITサービスの確保を目指すことで、その先にある企業価値及び顧客価値向上を追究すべきと考える。　

　そのITサービスマネジメントのベストプラクティスが「ITIL（IT Infrastructure Library）」である。英国政府作成のITILは、初版が1989-1990年にリリースされ2000年にITIL V2へバージョンアップが行なわれ、2007年5月にV3がリリースされた。

　ITIL自体はシステム運用のみをターゲットにしているのでは無かったが、ITIL V2での代表的な書籍がサービスサポート（青本）とサービスデリバリ（赤本）の2冊であることから「システム運用のベストプラクティス」というイメージが強かった。

　ITIL V3では明確に「ライフサイクル・アプローチ」を採用し、ITの新規企画から継続的な改善まで「ITサービス・ライフサイクルの全フェーズにおけるベストプラクティス」と生まれ変わり、次の5冊から構成されている。

サービスストラテジ

　ITIL V2と比べてITIL V3で一番大きく変わったのはこの書籍で、ITIL V2の「ビジネスの展望」から内容の30%を引き継ぎ、新たに70%が新規に書き下ろされ、下記項目から構成されている。

●サービス戦略の策定

●提供するサービスの定義

●サービス提供能力の獲得

●サービス戦略の策定

●サービスポートフォリオ管理

●需要管理

●財務管理

●ビジネスリレーションシップ管理　　

　ITIL V2で馴染み深いプロセスアプローチとは、かなり視点の違うまとめ方が行われているが、ライフサイクル・アプローチでのITによる企業価値及び顧客価値向上という目的を実現していくためには、現場視点による日々のカイゼンだけではなく、戦略的観点からドラスティックにやり方を変える必要がある。

　それをサポートするべく、「如何にビジネスとITを融合させ、ITサービスを過不足なく提供するか」という"最上流"テーマについてまとめられている書籍である。

サービスデザイン

　ITIL V2でのサービスデリバリがベースとなっている書籍で、40%が新規に書き下ろされており、下記プロセス群で構成されている。

●サービスカタログ管理

●サービスレベル管理

●キャパシティ管理

●可用性管理

●サービス継続性管理

●情報セキュリティ管理

●サプライヤ管理

●要求エンジニアリング

●データと情報管理

●アプリケーション管理　

　サービスデザインはITIL V2から存在しているプロセスが中心に書かれており、目次を見るだけでは目新しさは感じ難い。

　しかしライフサイクル・アプローチでのITによる企業価値及び顧客価値向上という視点において、大きく加筆・修正が行われている。

　例えば、サービスデザインはその名の通りITサービスを設計することに焦点を置いた書籍であるが、ITサービスの設計であって、ITシステムの設計では無いため、自社で賄うインソーシングだけでなく、アウトソーシングやコソーシング等のITサービスの調達方法についても言及が行われている等、自分たちの仕事の進め方を確認するために参考になる内容が多い。

サービストランジション

　主にITIL V2の変更管理、リリース管理、構成管理に焦点が置かれた書籍であり、以下プロセスにてまとめられている。

●トランジション計画とサポート

●変更管理

●サービス資産と構成管理

●リリースと展開管理

●サービス検証とテスト

●評価

●ナレッジ管理　

　単なるアプリケーション移行やハードウェアの導入ではなく、「サービスの移行」という視点で、ITIL V2のリリース管理と比べ、ITIL V3のそれでは大きく拡張されており、システム（ITサービス）を構築する、運用するということと同じくらい「開始する」という業務が重要であるということが反映されている。

サービスオペレーション

　ITIL V2のサービスサポートを中心に70%引き継がれ、30%が新規に書き下ろされており、下記プロセスにてまとめられている。

●イベント管理

●インシデント管理

●要求実現

●問題管理

●アクセス管理　

　ITサービスを提供するための「コントロール」に焦点を当てた書籍である。

　ITIL V2では、システムに何らかの影響を及ぼす出来事はすべてインシデント管理に集約されていたが、監視ツール等によるシステム上のイベントは「イベント管理」、ユーザからのサービス要求は「要求実現」へ分散されている。

　そもそもITIL V2では、インシデント管理と問題管理が非常に「こってり」しており、且つ章ごとに書き方が統一されていないため、どのように捉えて良いか悩む「行間」が多く見受けられた。ITIL V3ではその「行間」をきれいにブラッシュアップされた印象を持っている。

継続的サービス改善

　ITIL V2のサービスサポート及びサービスデリバリから30%を引継ぎ、70%が新規に書き下ろされた書籍で、下記プロセスにてまとめられている。

●プロセス改善の7つのステップ

●サービスの報告

●サービスの測定

●継続的サービス改善活動の投資対効果

●サービスレベル管理　

　そもそもITILはエドワード･デミング博士の提唱したPDCA（Plan-Do-Check-Act）サイクルを強く意識している。

　欧米の製造業向けに提唱されたPDCAサイクルであるが、日本に「カイゼン」へと変化しながら根付き、そのカイゼンが欧米に逆輸入されてITILに取り込まれており、そういう意味では、ITILは非常に日本人向けの考え方であるとも言える。

　ITIL V3では、Check-Actを書籍として独立させることで、ライフサイクル・アプローチ及びPDCAサイクルを通じた「カイゼン」の重要性を強調している。　ITILを読んで頂くと感じると思うが、ITILには至極「当たり前」のことしか書いていない。

図1：「ITIL V3」における5つのライフサイクル

　一社のみが実施して上手くいった奇抜な手法ではなく、様々な企業へ適用可能なベストプラクティスとしてまとめられるという過程で自然と「当たり前」の内容に収斂されていくのである。しかし現実を見ると、その当たり前のことが全く出来ていない状況であることが多い。

　当たり前のことを当たり前に行うことは、とても難しいのである。ゆえに、「当たり前」が出来たときの効果は非常に大きく、「当たり前」のことを体系的にまとめてあるITILの存在意義は大きいと考える。

図2：ITIL V3とITIL V2の関係

ITサービスマネジメントの実践に関する考え方

　前述した通り、ITILには「当たり前のことを当たり前にやるべきであること」が書いてある。しかし、読んだ通りに実践すれば良いかと言えばそうではない。

　それは2つの理由からだと考えている。　

　1つ目の理由は、「ITILは教科書ではなく、参考書と考えるべき」だからである。世の中には様々な企業が存在し、それぞれ多種多様な企業文化を育んでおり、ITシステム及びシステム部門の形態にも大きな違いが存在する。それらの現状を無視し、ITILに書いてあることが全て正解と捉えて、行動を行うことは大きな間違いである。

　例えばITIL V2では変更管理において、変更要求の「優先度付けとカテゴリ化」を行った後、「認可とスケジュール」を行うことと書かれている。しかし、企業によっては開発期間でカテゴリ（変更作業の規模）の判断を行う場合もあり、「優先度付け、スケジュールとカテゴリ化」の後「認可」というステップの方がしっくりくるはずである。

　このようにITILという体系だった参考書・問題/例題集をベースに、自社の環境・文化にあったやり方を検討し、適用するべきである。　

　理由の2つ目は、「ITILは総論であり、各論ではない」ということである。ITIL V3では、5冊の書籍で合計1000ページを超える程の量であるが、ITサービスマネジメントと言う手法を語り尽くすにはまだ足りず、限られたページ数で網羅性を重視すると、どうしても突っ込んだ「各論」の話は少なくなってしまっている。　

　例えばまた変更管理を例にとると、ITIL V3では「変更のビジネスリスクや金額の規模に応じて承認者を分けるべきである」と書いてあるが、1行ソースコードを変更するだけの変更も、ITサービスを止めるリスクを有している。ITサービスを止めるリスクがあるからと言って、当然ながら毎回1行ソースコードを変更するためだけに、経営者へ報告するべきではない。

　ITILには残念ながら、このような詳細なケースについての言及はそれ程多くはない。重要な「各論」については、自ら考えることが必要なのである。

図3：添付ファイルフィールドの改善前と改善後

　ある企業では、インシデント管理をWebベースのツールにて管理を行うべく、プロセスとツールの導入を行っていた。

　しかし、ユーザからの依頼やユーザへの回答を添付ファイルで行っていたため、回答や報告を行うのに毎回メールを送信する必要が生じていた。

　そこで、Webツールにユーザと共有できる添付ファイルのフィールドを設け、メールを送信する時間を短縮することが出来たのである。

　メールを送信するまでの時間はたかが40秒であるが、その企業では4名の従業員が1日30件ずつ程度ユーザとのやり取りを行っている。計算を行うと、「40秒（メール作成時間）×30件（1日当たりの件数）×4名（担当者数）×240日（営業日）＝320時間」となり、添付ファイル用のフィールド1つ設けるだけで、年間320時間もの稼働を削減したのである。

　もちろん「添付ファイルフィールドを設けた方が良い」とはITILには書いていない。　繰り返しになるが、ITサービスマネジメントは「ビジネスニーズに対応したITサービスを適切なサービスレベルとコストを提供するために、最適のITシステムを構築し、パートナーと担当者から成り立つ組織を最大限活用することで、実現を目指す手法」である。

　そこに決して魔法の杖はなく、最適解は降って湧いては来ない。ベストは無く、ITILを参考にしながらベターを粘り強く繰り返し続けるしかない。それらの活動を通じてシステム担当者の能力が磨かれ、組織が成熟し、「ビジネスニーズに対応したITサービス」の提供が実現するのである。