本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 |
情報システムのリスク管理上の最大テーマとして，情報セキュリティを巡る論議が花盛りである。だが，自社のシステムにとって，何がどの程度リスクなのかを見極めた上で取り組まないと，無駄な労力をかけることになる。セキュリティと目先のコストや利便性はトレード・オフの関係にある。したがって，最新技術を含む各種の情報セキュリティ対策をバランス良く組み合わせることが重要である。
富永 新
「21世紀はセキュリティの世紀」とまで言われ，情報セキュリティ問題は今や情報システム・リスクの最大テーマとなった感がある。だが，なんでもセキュリティ問題に結び付け，対応を迫るようあおり立てる「情報セキュリティ狂想曲」に踊る必要はまったくない。しばし立ち止まって自分の頭で冷静に考えてみる必要が高まっているように思われる。
セキュリティの問題は，あくまで自社の立っているポジションを基点に考えてみる必要がある。セキュリティ対応にどの程度の資源（人，物，金）を投入するかは，リスクの大きさとのバランスの問題である。「インターネットで商売したい，しかも高額の取引に使いたい」という企業は，手間とお金をかけても十分な備えをする必要がある。
一方，「伝統的な商売を続ける。スタンドアロンのマシンをたまにインターネットにつないで情報を検索すれば十分」という企業があった場合，それで本当に生き残れるか否かはさておき，セキュリティ・コンサルタントを雇ってセキュリティ対策を検討してもコストに見合わない。
したがって，まずは自社を取り巻く客観情勢をよく見極めたうえで，どのような経営戦略を取り，どう情報化投資をするのか，ビジネス・チャンスと引き換えにどこまでリスクをとるのか，といった点を経営レベルで決断する必要がある。その場合，オープン・ネットワークの世界で航海するのかどうかがひとつの判断ポイントとなろう。
情報システム・リスクは，自社が持つシステム・ポートフォリオとIT戦略にリンクして変動するという視点を改めて確認すべきである。したがって，「標準的なセキュリティ対策」なるものはあり得ないし，「共通のガイドライン」もない物ねだりである。「とりあえず世間相場並みのセキュリティ対策を打っておけ」といった指示は，本末転倒でなんの意味もない。
以上の前提を踏まえ，本稿では二つの点を述べたい。第一は，情報システムの最近の動向とそれに伴うリスクの変化である。情報システムに関してはさまざまなリスクがあり，情報セキュリティがすべての企業にとって最大のシステム・リスクであるとは限らない。もっと大きなリスクを放置して，セキュリティにだけ取り組むようでは，リスク管理能力が高いとは言えない。
第二は，情報セキュリティ対策に取り組む際の基本的なポイントである。情報セキュリティだけに気をとられるのはバランスを欠いているが，これを無視することはできないし，自社の身の丈に合った総合的な対応を図る必要があるからである。
昨今の情報システム・リスク
かつて，メインフレームのみを前提としたレガシーなシステム文化が存在した。もちろん今でも大量・高速データ処理の分野，あるいはデータベース・サーバーとして，メインフレームは引き続き一定の地位を占めている。ただ，クライアント/サーバー・モデルやLAN/WANの時代を経て，今やWeb /IP技術全盛の世を迎えつつある。大方のユーザー企業では，急速な流れに人材育成が追い付かず，「オープン系技術のスキルを持った要員の確保」が共通の課題となっている。
こうしたことから，「システムの時代」の真っ只中にありながら，肝心の自社の情報システムに関する開発・運営業務を全面的にアウトソーシングし，ベンダーに頼らざるを得ないという，一見矛盾した動きが出てきている。
アウトソーシングのリスク
アウトソーシングは一つの経営判断であろうが，アウトソース先の管理に当たっては，「アウトソースしてもリスク管理の最終的な責任は自社に残る」という意識が不可欠である。単に「自分では分からなくなったので外へ出そう」というのでは主体性のない話だ。自社内で最低限のシステム企画をし，アウトソース先のパフォーマンスをラフにでも検証できる程度のスキルを維持する必要があると考えられる。
もとよりすべてに口を出そうとすれば，「何のためにアウトソースしたのか分からない」とか，「ベンダーとの力関係で無理だ」とかさまざまな困難が想定される。しかし，少なくとも自社にとって重要な基幹業務をアウトソースする場合には，定期的なモニタリング手段の確立，立ち入り監査権の確保などを通じ，実効ある管理の仕組みを手当てしていくことが賢明であろう。
短期開発のリスク
今や，システムの稼動時期は経営戦略によって規定されるケースが増えている。他企業との提携を含むインターネット・ビジネスについては，多くの場合，経営トップないし営業企画部門が先行して話を進めてしまう。システム部門には，決まった話が説明され，数カ月単位でシステムを開発することが求められる。かつての数カ月におよぶテスト期間など夢のような話で，多少のバグが残っていても運用でカバーすればよいという判断で，とにかくカットオーバーすることが優先される。
すべてをシステムで処理するのでなく，運用で補うことは当然としても，本来なら，システム部門も参画してビジネスプロセスを十分に検討し，余計な開発負担を減らすといった工夫を凝らすことが有効であろう。
じっくり取り組んでいたら競争に勝ち抜けない時代にはいたし方ないとはいえ，それも程度問題である。システムの安定性にとって肝心なテストが十分にこなされているかどうかについて，システム部門の強い発言力が担保されていることが健全な姿と言えよう。そうでなく，受け身で対応するだけの場合には，本誌のトラブル関連記事として参考事例を読者に提供できても，自社の評判は下がり，経営レベルでのダメージにつながりかねない。
パッケージのリスク
最近は既成のパッケージ・ソフトを組み合わせて利用することが多い。標準化されたオープン技術の時代なので，マルチベンダー化に伴う維持管理や問題判別の困難さをかつてほど気にする必要はないとしても，パッケージ・ソフト同士の親和性の難点は依然として残る。
個別の製品としては完成度が高く利用実績が豊富でも，組み合わせや利用条件によって，潜在していたバグにぶつかるケースが見受けられる。特に，事実上のファーストユーザーとなる場合には，事前の十分なテストが欠かせない。メーカーのうたい文句を信じ込むことなく，各種のヒアリングなどを通じて，問題点や限界を事前に把握するよう努めることが得策と思われる。
パフォーマンスのリスク
インターネット上での不特定多数を対象としたビジネスの場合，特にサービスの初日や特定日にアクセスが集中し，レスポンスが著しく悪化したり，ダウンしてしまうケースも少なからず耳にする。
インターネット時代の最大の問題点は，ユーザー数や最大処理量およびその該当時間帯を読めず，ピーク時対応が取りにくいことである。この結果，ユーザーにレスポンスの悪化が認識され，時には「利用できないシステム」として認識されてしまう。そうした事態はユーザーにはっきり見えてしまうだけに，リスクは大きい。
したがって，ベンダーの提示するサーバーの処理能力などを鵜呑みにせず，十分な負荷をかけたパフォーマンス・テストを行うことなどにより，こうした事態を未然に防ぐよう注意する必要があろう。「インターネットだからそういうことも許される」という段階は，そろそろ卒業したいものである。
キャパシティのリスク
システム障害の原因として，かつてはディスク制御装置などの障害に起因する，いわば不可抗力とも言えるものが多かった。最近ではファイル設計やテストの不十分さに起因するトラブルが増えてきているように感じられる。
例えば，何らかのデータが特定のファイルにたまりすぎ，オーバーフロー（限界値超え）したり，その結果他のデータを壊してしまうといった事例である。業務要件サイドからは普段特に意識しない部分であるが，システムサイドでは事前にこうした可能性のあるファイルを洗い出したうえで，定期的なモニタリングを含め，キャパシティ面でもきめ細かな対策を講じておくことが望まれる。
システム統合のリスク
長引く景気低迷と国際化の進展に伴う経営環境の変化に対応するため，企業の合従連衡の動きは旺盛である。並行して，合従連衡に伴ったシステムの統廃合が盛んに行われている。しかし，システムの統合は，それほど簡単な話ではない。特に生い立ちが異なる各種のプラットフォーム上で複雑に相互連携して動いているシステムを結び直す場合には，かなり骨の折れる作業となる。
システムに大きな変化が生じる際にリスクも変動する。そういう意味で，システムの統合プロジェクトは，合併企業のシステム部門にとって最大の課題であると同時に，経営面でもカルチャー統合と並んで最大の課題である。従って，リスク管理面でも十分な意識をもって，全体をモニタリングする要員を配置したり，開発途上でもシステム監査の対象とするなど，その推移と影響を慎重にウオッチしておくことが適当と思われる。
