tag:www.sos-soumu.com,2008:/column/risk/governance//20 2008-10-22T00:01:00Z Movable Type 3.2-ja-2 tag:www.sos-soumu.com,2008:/column/risk/governance//20.307 2008-10-22T00:00:00Z 2008-10-22T00:01:00Z

SOX法におけるIT統制に限らず、ISO9001、ISO14001など、電子帳簿...

soumu_admin SOX法におけるIT統制に限らず、ISO9001、ISO14001など、電子帳簿保存法等の各種コンプライアンスに適合するために電磁的記録を行う場合には、一定の技術要件をみたす必要がある。具体的には、蓄積された情報の改ざんを不可能とする仕組み、簡単に言えば、上書き不可能・追記のみ可能とする仕組み（例えば削除の場合、削除したというフラグが立つだけで、どのような情報が削除されたか、後に確認可能）が存在するかどうか、また、証跡管理として情報の登録、変更、削除等の各種操作の操作履歴（例えば、いつ、誰が、どこから、何の情報に対して削除行為をしたか）がすべて記録されており、自在に確認可能かどうかなどがあげられる。このような電磁的記録に関する基準を盛り込んだ記録管理の国際基準がISO15489であり、WTO（世界貿易機関）で2001年9月に採択されている。また、日本国内ではISO15489が2005年7月にJISｘ0902として制定されている。 ところが、この記録管理が情報システムとしてほとんど実現されていない。 なぜ、記録管理が実現されないのだろうか。もっとも大きな理由はIT業者側の認識の低さと技術力不足である。IT業者側の問題により、記録管理（ISO15489）に曲がりなりにも対応する製品が極めて少ない状態になっている。一般に出回っているファイリングシステムの多くが、パッチ投入などでデータ更新（上書き）が可能な仕組みとなっており、さらにまずいことに、そのパッチ投入に対する履歴管理などの機能がない場合が多い。これでは証跡管理として利用不可能である。上書き不可能なように順次書き込み方式を採用している場合もあるが、これでは検索性能を確保できず、実用性に問題がある。さらに具合がわるいことに、IT業者側の認識が低いことも手伝って、ユーザー側が記録管理の重要性を認識していない場合が多い。ユーザー自身がその必要性を理解していなければ、記録管理が実装されるわけがない。 もっとも、一部の先進的企業や団体では、記録管理に適合した製品・サービスを実装し始めている。例えば、佐賀県では各種台帳を管理する仕組みとして記録管理に適合したシステムを実用化している。佐賀県の場合、記録管理の実現だけでなく、コスト面、ユーザーサービス面でもメリットを享受しているとのことである。読者の皆さんの職場で、もし、電磁的記録の記録管理が導入されていなければ、このような先進事例を参考にされてはいかがだろうか。 tag:www.sos-soumu.com,2008:/column/risk/governance//20.284 2008-07-02T00:00:00Z 2008-07-02T00:01:01Z

読者のみなさんは、情報戦略という言葉にはなじみがあるだろう。ひょっとして、「IT...

soumu_admin 読者のみなさんは、情報戦略という言葉にはなじみがあるだろう。ひょっとして、「ITは疎い」という方もいるかもしれないが、少なくとも耳にしたことはあるはずである。では、IT戦略はどうであろうか？　この言葉も同様によく知られており、なおかつ頻繁に使われている。 さて、情報戦略とIT戦略、何が違うのだろうか？ 現在、この両者の使われ方には差がないといっていい。本来は、この両者には明確な差があるはずだが、その差が認識されていない。いや、それどころか、実際にはIT製品導入および情報システム構築に関する戦略（というよりも、正しくは戦略レベルではなく施策レベル）をIT（情報技術）戦略と呼んでいるのが実態である。語義に従えば、ベンダーがIT戦略、要は技術戦略を論じるのは当然かもしれないが、ユーザー企業はどうであろうか？　もっとも、このような情報機器（ハードウエアとソフトウエア）と関連サービスを表現するには、IT戦略という言葉はとりたてて問題があるわけではない。 では、情報戦略とは本来何を指しているのか？　最近、CIと言うことばを耳にするようになった。Corporate Identityではない。Competitive Intelligenceのことである。ここでは詳細な説明は省くが、端的に表現すれば、企業経営（ほかにも軍事、外交などさまざまな領域で使用されている）に関連する重要な情報をintelligenceと定義している。このintelligenceの収集、分析、管理、活用をCIと呼んでいる。情報戦略とは、CIを行うとともに、必要であれば他者の行動に影響を与えうるintelligenceの発信を行い、その効果を分析することに関する戦略、ということである。従って、普通に考えれば多くの企業、組織にとって情報戦略は必須といっていい。 さて、ここまで、IT戦略と情報戦略の違いを簡単に説明してきたが、皆さんの会社では、「情報戦略」は構築されているであろうか？　IT業者に振り回されIT機器選定に追われて肝心のintelligenceを忘れていませんか？ tag:www.sos-soumu.com,2008:/column/risk/governance//20.278 2008-05-28T00:00:00Z 2008-05-28T00:01:01Z

読者のみなさんにお聞きしたい。 たとえば、Eメールを導入する場合、その投資対効果...

soumu_admin 読者のみなさんにお聞きしたい。 たとえば、Eメールを導入する場合、その投資対効果を検討しただろうか？　インターネットへの接続はどうだろうか？　おそらく、ほとんどの場合、定量的に投資対効果を検討してはいないであろう。 「このような情報系ないし情報インフラへの投資は、結局、導入後にどれだけ利用するかによって得られる効果が異なるわけであり、したがって、いかにして利用を推進するかがカギである」という考え方がある。このこと自体は誤りではないが、投資意思決定を行う側から見ると乱暴な意見である。 Eメール導入やインターネット接続だけであれば、確かにそれほどコストはかからないが、問題はセキュリティをはじめとする「IT統制の維持」である。これに莫大なコストがかかるのだ。実際、笑えない話が転がっている。ある企業の事業部長が、「HPを開設して情報発信しようとしたら、開設費用は安いところに頼めば数十万円なのに、なんでセキュリティ診断と対策に数百万円もかかるんだ！」と怒っていたが、それが実態なのだ。 たとえは良くないかもしれないが、中古自動車を5000円で買うことはできても、ガソリン代、税金、高速道路料金、車検など、もろもろの公道を走る上での入場料的費用は他車と同様にかかる。要するに、インターネットを利用する場合、このような入場料が高いことを意識すべきなのである。 ある北陸の企業では、営業情報の支店間での情報交換にFAXを利用していた。だが、FAXでは受信後に紛失することもあり、なかなか情報の有効な活用がはかれなかった。そのため、情報交換に、FAXの代わりにEメールを導入したのである。効果はいうまでもないであろう。情報蓄積、編集、交換が容易になったことから、以前に増して、競合他社の価格情報や提案情報を分析し、より有利な提案が可能となったのである。現在では、それを掲示板に発展させて使用している。しかしながら、このような例は、残念ながら少ない。 これも笑えない話だが、ある製造業で、熱心にパソコンに向かって作業をしている女性がいた。上司は彼女を高く評価していたが、あるとき、ログ解析ツールを入れて作業状況を分析したところ、彼女は１日平均７時間近く、チャットをしていたのである！　つまり、この会社は２重に損失を出していたわけである。一つは、インターネットを導入したことで従業員が上司に気付かれずに怠業していたこと、さらに、１日７時間チャットをしていても、残った時間で仕事をこなせる優秀な人材に気が付いていなかったことだ。 さて、みなさんの会社のEメールやインターネットはいかがだろうか？ tag:www.sos-soumu.com,2008:/column/risk/governance//20.229 2008-03-31T10:45:21Z 2008-04-02T01:01:16Z

IT投資対効果(ROI)の課題は、古くて新しいものである。筆者もだいぶ前から雑誌...

soumu_admin IT投資対効果(ROI)の課題は、古くて新しいものである。筆者もだいぶ前から雑誌や単行本で意見を述べているが、必ずしもこれは、という絶対的な解があるわけではない。ここでは、なぜ、このテーマが厄介なものであるかを、簡単に解説したい。 おそらく1980年代前半くらいまでであれば、ITROI（ITという言葉もなかったわけだが）の評価はそれほど厄介ではなかった。この時代のITは、基本的にバッチ処理であったため、ビジネスプロセスとのインタフェースは限定されており、たとえばビジネスの結果、伝票集計等の計算を代行する、ある意味で自動そろばんのようなものであった。このようなITであれば、それまで人手で伝票を集計していた業務を、コンピュータでまとめて計算した場合のROIは、容易に算出可能であったはずである。 ところが、最近では、ITの発展によって、ビジネスプロセス上の大半にITが組み込まれた状態になっている。さらに、最近では、インターネットショッピングなどのように、ITなくしてあり得ないビジネスモデルも存在している。このような状況では、得られるはずのリターンがITによる効果なのか、ビジネスプロセスの改善による効果なのかが明瞭ではなくなっている。要は、ビジネス全体の評価をせずに、ITのみの投資対効果をしても意味がないし、そもそもITのみを切り出すことが困難という状況となっている。 このような状況では、かつてのITが存在しない状況にITが出現した形での投資対効果の評価は、はっきりいって意味がない。したがって、現存するビジネスプロセス上のITを置き換えた場合という想定で、ITROIを計算する場合が多いはずである。たしかに、既存ビジネスプロセスがあまり変化しないならばそれでいいが、ビジネスプロセスが大幅に変化する場合、業務アプリケーションが統合化されたカバレッジが拡大し、影響が多方面にわたる場合、さらに、インターネットショッピングなどの全く新規のビジネスモデルの場合は、IT単独の評価が難しい。では、このような場合、どうすればいいか？　まず、ビジネス全体を評価することである。インターネットショッピングの場合であれば、インターネットショッピング・ビジネスモデルの投資対効果を算出し、投資の妥当性を判断すべきであろう。その結果、投資OKであれば、ITの実現方式に関して、代替案を加えた数案での評価を行うべきである。 次回は、上述した業務系と違い、投資対効果そのものの計算がしにくいEメールなどの情報系に関して、述べることとする。 tag:www.sos-soumu.com,2008:/column/risk/governance//20.219 2008-02-19T14:55:54Z 2008-02-19T02:12:01Z

しばしば期待外れに終わるIT投資に、「情報系の開発」が挙げられる。多額の投資をし...

soumu_admin しばしば期待外れに終わるIT投資に、「情報系の開発」が挙げられる。多額の投資をしたにもかかわらず、何も価値を生み出していないところが少なくない。 たとえば、データウエアハウスが一世を風靡（ふうび）した時代、多くの企業がデータウエアハウスの構築にまい進したことがある。そのとき、次のような掛け声が振るっていた。「何でもデータを入れておいてください。今、必要でなくとも、将来、必要になるかもしれません。そのときに力を発揮するのがデータウエアハウスです」――いっていること自体に間違いはない。確かに必要になることもありえるかもしれない。だが、「将来、必要になるかもしれない」というわずかな可能性のために、IT関連だけでハードウエアやソフトウエアなどのIT設備に膨大な投資と運用部隊の整備が必要だった。運よく格納したデータが必要になった場合でも、そのデータがどれだけの価値を生み出したのだろうか？　ほとんどの場合、投資に見合った効果は得られなかったはずである。 このような事例は枚挙にいとまがない。このような経験をした多くの企業が「羹（あつもの）に懲りて膾（なます）を吹く」状態になり、「ITは金がかかるだけで役に立たない」とIT投資を控えがちになる。結局、当初はIT業者の思惑通り、ITへの支出が増加したが、しばらくすると減少してしまうわけである。もちろん、責任がIT業者のみにあるわけではない。適切な投資判断ができない企業の方が罪は重い。 将来を予測することは、はっきりいって困難である。不可能といってもいいかもしれない。だが、自社の現状はわかるはずである。たとえば、上記のケースだが、そもそも、大量のデータを分析するスキルが自社内にあるのだろうか？　その結果を活用するリソースはいるのだろうか？　なければどうするつもりなのか？　育成か、外部からの獲得か、外注か……。要はシステムを導入する前に、業務がどう変化するのか、新プロセスは移行可能かつ効率的か、そのために必要なスキルとリソースの確保は可能なのかなど、平たくいえば運用開始後のイメージを固め、フィージビリティを評価することが必須のはずである。 だが、実際には、ITまわりのことにのみ考えが集中し、肝心（ITが効果を発揮するのは運用後である）のことが抜けている場合が多い。しばしば成功事例をうのみにし、自社もそうなれると考えがちのようだが、成功事例の会社と自社の違いすら分析されていない場合が多い。これでは失敗しても不思議ではないであろう。 tag:www.sos-soumu.com,2007:/column/risk/governance//20.199 2007-12-17T07:06:24Z 2007-12-21T08:24:27Z

先日、ある民間企業を訪問したときのことである。そこの情報システム部の管理職の方が...

soumu_admin 先日、ある民間企業を訪問したときのことである。そこの情報システム部の管理職の方が、全社の経営計画やラインの中期事業計画の中で、ITにほとんど触れられていないことを嘆いており、なんとかITの認識を高め、ITに関しても言及されるようにしたいと述べられていた。計画段階からITの必要性を認識し、IT活用の方向性を明確にしたいということらしい。その話をうかがい、私が「つまり、EAの認識を広めようということですか？」と聞いたところ、とんでもない、という表情をされた。「なんで、あんな面倒くさい、無駄なものを作る必要があるんだ！」ということらしい。 EAはITアーキテクチャの発展系である。自組織のIT（と情報）の将来的な方向性を描くための方法論がITアーキテクチャであり、IT企画において、ITの将来構想を描く場合にもっとも有効な方法論のひとつである。それが、ITの発展によって、ビジネス全体におけるITの重要性が高まったことから、ビジネスアーキテクチャも合わせて検討しないと適切なITアーキテクチャが描けないため、ビジネスアーキテクチャも包含した「EA」へと発展してきたのである。実際に、欧米の先進的な企業では、以前からITアーキテクチャを構築しており、その延長線上でEAに取り組んでいるところが多く、EAに対する違和感はさほど大きくない。 では、日本はどうだろうか？　確かにほんの一時期、EAが話題となったが、すぐに下火になってしまった。そのブームのときに、EAが誤解される形で日本に定着したことが、上記のような反応になってしまっていることは間違いない。おそらくは、ブームになったときに流行した、ボトムアップ的なこてこてのモデリングをする、ある意味で間違ったEAのイメージが染み付いているのだろう。悪いことに、日本ではITアーキテクチャが存在しない土壌にEAが突如出現したため、ほとんどEAの本質も理解しないまま、EAを構築すれば、何らかの「ご利益」が得られるかのように、EA構築そのものが目的化してEA構築が進められ、多くは徒労で終わったのである。大半の企業はボトムアップ的なアプローチのために途中で挫折してしまったであろう。一通り構築した企業でも、効果を十分満喫できたところは少ない。EAは企画段階の方法論であり、従ってEAを構築しただけではほとんど効果が得られない。効果を挙げるためには、実プロジェクトに展開し、必要に応じてその結果をEAにフィードバックしていく、いわゆるPDCAのマネジメントサイクルにのせていくことが必須である。 企画やIT部門でしばしば、お題目のように、「全体観」、「全体最適」、「全体像」、「トップダウン」などのキーワードが飛び交っているが、実は、それだけ、EAの必要性が指摘されているといえる。EAは企画や開発の外側にある余分なものではない。企画の中核をなすものであり、開発、運用における実プロジェクトの方向性を明確に指し示すものである。 さて、みなさん、EAを利用していますか？ tag:www.sos-soumu.com,2007:/column/risk/governance//20.188 2007-11-06T00:21:52Z 2007-11-07T04:24:39Z

〜新たなコンプライアンスにいかに対応するか〜 　最近、IT関連業界で、進行基準と...

soumu_admin 〜新たなコンプライアンスにいかに対応するか〜 　最近、IT関連業界で、進行基準という言葉を耳にする機会が増えた。この進行基準とは、正式には「工事進行基準」のことであり、会計上の収益計上基準の１つである。これまでは、ソフトウエア受託開発の場合、収益計上の方法には、「工事進行基準」と「工事完成基準」の２種類があり、ほとんどの企業で「工事完成基準」が適用されていた。それが「工事進行基準」に一本化されるということで、注目されるようになったわけである。 　この「工事進行基準」と「工事完成基準」とは、その名が示す通り、土木、建設工事、造船などの長期請負工事の収益計上に関する基準のことである。これまで日本では、この２つの基準のいずれかを選択適用することが認められていたが、企業会計基準委員会の公開草案によれば2009年4月から原則として「工事進行基準」に一本化することになった。IT業界にとって、これだけであれば人ごとなのであるが、実は、この「公開草案」に適用対象となる範囲として、「受注制作ソフトウエアについても、前項の工事契約に準じて、本会計基準を適用する」と記載されていたため、IT関連業界でも急に注目されるようになったわけである。 　「工事完成基準」であれば、工事終了後に、実績値を合計することにより原価総額を算出し、計上すればよいわけであり、受託システムの進ちょく状況の把握はある意味で不要であった。ところが、「工事進行基準」ではそうはいかない。進ちょく状況を的確に把握する必要がある。ここで問題なのが、建設など、いわゆる工事とシステム開発における進ちょく度把握の容易性の違いである。工事の場合には「原価比例法」により、進ちょく度を決定するが、システム開発の場合、工事のように単純に割り切ることはできない。たとえば、EVM（Earned Value Management）を用いて計画に対する開発進ちょく状況と、コスト予算全体におけるコストの消費状況を適切に把握することができなければ、「工事進行基準」を適用することは不可能である。 　おそらく、「どんぶり勘定」が当たり前であった、多くのシステム開発業者が対応に苦しむであろう。だが、考えてみてほしい。「工事進行基準」に対応できない現状が何を意味しているのか。多くのIT企業がEVMという名前は知っているが取り組んでいないのはなぜなのか。面倒くさいからではない。たとえば、プロジェクト全体をWBS（Work Breakdown Structure）に落とし込み、個々のWBSの進ちょく度を把握する能力がないなど、基本的な開発管理能力が低いからである。 　「JSOXに続いて、またもとんでもないものがやってきた」という声もあるようである。だが、このような後ろ向きの考え方では勝ち組に入るどころか、生き残ることも難しいであろう。それよりも、これらの新たなコンプライアンスの出現を千載一遇の好機と捉えるべきである。JSOXにせよ「工事進行基準」にせよ、取り組み方によっては、企業に多大な価値をもたらすからである。 ]]> tag:www.sos-soumu.com,2007:/column/risk/governance//20.184 2007-10-07T11:12:22Z 2007-10-09T01:49:53Z

21世紀に入り、ITの進化はさらに進んできている。また、ベストプラクティスもそれ...

soumu_admin 21世紀に入り、ITの進化はさらに進んできている。また、ベストプラクティスもそれに合わせて、進化した形で出現してきている。ただ、このような先進ユーザーとその他大勢の一般ユーザーとの差は、ますます拡大してきている。 同じITを利用していても、その差は歴然としている。これは、ITそのものに関する理解、つまり技術力の違いも影響していることは確かである。だが、それだけではない。ITガバナンスの水準が違うのである。平たくいえば、「ITの使い方」に差があるのだ。ITそのものがビジネス上の目的を実現するわけではない。ITが「イネーブリング・テクノロジー」と呼ばれるゆえんでもあるが、ITは目的を達成するための手段である。だからこそ、ITを利用する場合に、ITガバナンスの水準によって、利用した結果に大差がでるわけである。 業務パッケージのように、あまり使い方に差がないようなITでも、実は結構、差がある。ある企業では、それまで手作りのバッチシステムをリアルタイム型のERPパッケージに変更した。ところが、従前のビジネスプロセスをほとんど見直さず、ERPパッケージをカスタマイズしてそれに合わせようとしたのである。これでは、ERPパッケージの長所を殺して短所を際立たせているようなものである。これとは対照的に、同様の置き換えを行った別の企業では、ERPパッケージの利点であるデータのリアルタイム性、データの一元管理、分析用情報の付加の容易性を利用し、収集されたデータをモニタリングし分析することにより、業務上の問題点を早い段階で把握し、適切な対応がとれるようにしている。おそらく、投資額にはそれほど差がないはずだが、得られる効果には雲泥の差がある。これがBIツールなどでは、さらに大きな差となるであろう。 読者の皆さんの周りをごらんいただきたい。スプレッドシート、WEBの情報検索など、使い方に驚くほど差があることがわかるはずである。同じITを使っていても、使い方によってそこから得られる効果に差があることが一目瞭然と思うが、いかがであろうか？ tag:www.sos-soumu.com,2007:/column/risk/governance//20.176 2007-08-14T04:32:55Z 2007-08-18T08:21:52Z

前回、ITガバナンスの定義に関して記したが、では、（IT）コントロールはどうだろ...

soumu_admin 前回、ITガバナンスの定義に関して記したが、では、（IT）コントロールはどうだろうか？　また、ITマネジメントとは何を指すのであろうか？ 別に定説があるわけではないが、筆者は、IT機能および関連する組織に関して、何（WHAT）をどのように（HOW）管理（ここですでに管理という言葉がでてきてしまうが）および監視するかに関して、その全体構造をITマネジメント（管理）と定義している。これに対して、ITガバナンスはWHATの部分を具体的に定義するものであり、WHATに基づいて、HOW、つまり、具体的なチェック項目やそれに対する測定方法などを定義するのが（IT）コントロールであると考えている。 世間では、ITマネジメントとITガバナンスが同義と定義される場合も少なくない。ときには、「ITガバナンスにもとづいてITマネジメントが遂行される」という定義も見かけることがある。筆者としては、もちろん、定義が確定する方が望ましいとは思うが、このような状況に対して、特に非難するつもりはない。重要なことは、IT機能および関連する組織に関するWHATとHOWそれぞれに関して理解し、適切な実装が行われる必要があるということである。 コントロール（統制）といえば、最近、SOX対応で「IT統制」という言葉を耳にする機会が多い。しばしば、このIT統制、特にIT全般統制を「ITガバナンスと同等ないしその一部」などと説明される場合がある。実際、その方が理解しやすいようなので、筆者も方便として、このようないい方を用いたことがある。しかしながら、IT統制は、実態としては、ITガバナンスというよりは、ITコントロール、つまりHOWを適切に実装することを意味していると捉えるべきである。リスク・コントロール・マトリクスがSOXの統制の基本形であるが、これはまさにHOWの表現形式のひとつである。 では、SOX対策において、WHATは意識しなくてもいいのだろうか？　もちろん、そんなことはない。HOWを設計するためには、その前提としてWHATがあるべきであり、そうでなければ、全体感を欠いた重複や漏れが多いHOWになってしまう。したがって、まず、WHATを設計すべきである。そういう意味では、COBIT（Control Objectives for Information and related Technology：米情報システムコントロール協会ISACAが提唱するITガバナンスの成熟度を測るフレームワーク）をベースにWHATを設計した上で、ISOなど利用しながら、HOWを構築することが理にかなっている。 tag:www.sos-soumu.com,2007:/column/risk/governance//20.170 2007-07-02T06:50:47Z 2007-07-02T06:53:43Z

読者のみなさんは、「ガバナンス」とは何か、考えたことがあるだろうか。また、「マネ...

soumu_admin 読者のみなさんは、「ガバナンス」とは何か、考えたことがあるだろうか。また、「マネジメント」との違いは何なのだろうか？ ＯＥＣＤの定義によれば、ガバナンスとは「（組織）が方向付けられ、統制される仕組み（システム）」ということである。つまり、ある組織の目的達成のために、その組織の活動状況等に関してモニタリングを行い、目的達成に近づくように必要に応じて改善を行うことを指しているわけである。 先日、ＳＯＡを専門とする、あるベンダーのエンジニアと話をしたが、彼によれば、個々のコンプライアンスの評価やＳＬＡ順守状況の評価はガバナンスではない、ということであった。このような活動は、何らかの目的に方向付けられたものではなく、最低限かつ必須のチェック項目であり、目的達成のためにその達成状況をモニタリングするものではないということが理由だという。 確かに、このような、ある意味で「狭義」の考え方もあるだろう。逆に、「ガバナンス」の意味をもっと「広義」に捕らえて、上述したようなコンプライアンスの評価なども「ガバナンス」の対象と考えている人も少なくない。もっとも、この場合、「マネジメント」との違いがあいまいになりがちである。 では、ＩＴに関してはどうだろうか？　「ＩＴガバナンス」と「ＩＴマネジメント」の違いは？　明確に定義している人も、もちろんいるわけだが、コンセンサスを得ているとはいいがたい。 このコーナーでも、実はこれまで、かなりあいまいにしたままで話をしてきている。というより、ＩＴガバナンスそのものよりも、ＩＴガバナンスに関連した話をしているといった方が適切だろう。ただ、企業のＩＴ部門の方は、一度、「狭義」のＩＴガバナンスの観点から、自社のＩＴの状況を評価してみてはどうだろうか。実は、ビジネスの方向とは食い違っていたり、そもそも、ガバナンスのためのモニタリングがなかったりなど、何らかの気づきがあるかもしれない。 tag:www.sos-soumu.com,2007:/column/risk/governance//20.161 2007-06-05T03:06:20Z 2007-06-05T03:07:01Z

ＩＴ化が業務のパフォーマンスの向上に貢献していることは、一部の例外を除いて、間違...

soumu_admin ＩＴ化が業務のパフォーマンスの向上に貢献していることは、一部の例外を除いて、間違いないであろう。ＩＴ化は、パフォーマンスの面だけでなく、コンプライアンスの強化に関しても寄与している。当然、ＩＴガバナンスの向上にも活用し得るものである。 ＩＴガバナンスに限らず、ビジネス上の目的を達成するためには、その達成状況をモニタリングする必要がある。ところが、この「モニタリング」という作業が厄介である。人手でやろうとすれば、人件費の増加につながることは目に見えている。さらにＩＴ化の進展によって、ビジネスプロセスにおけるＩＴプロセスの比重は増加しているわけだが、そのＩＴプロセス上のモニタリングを、ＩＴを使わずに行うことは、ほぼ不可能である。したがって、ＩＴをうまく利用してモニタリングを行うことが重要になってきている。ところが、これがなかなかできない。特に日本企業の場合、苦手にしているところが多い。というよりも取り組んでいないところが多い。 米国企業と日本企業のＰＤＣＡサイクル（Plan-Do-Check-Act cycle）上での得手不得手を比較した場合、米国企業はＰとＣ（モニタリングといい換えてもいい）に秀でており、Ｄが苦手である。ところが、逆に日本企業の場合は、Ｄが得意であるが、Ｃが苦手というかあまり意識されていない。これには、日本企業の場合、特に製造業においてＤが優れていることと、１９８０年代までの右肩上がりの高度経済成長のおかげで、結果を「真剣に」評価する必要がなかったことも影響している。さすがに、９０年代の不況を経て、モニタリングの重要性を認識するようになってきていることは間違いないが、満足できる水準からは、かけ離れているのが実態だろう。 手作業でのモニタリングも十分な経験がない状況でＩＴを活用しても、十分な成果が得られないことは当然である。さらに、上述したようにＩＴによるモニタリングの重要性が増加している状況を踏まえれば、一般的な日本企業でのＩＴガバナンス、ＩＴリテラシーの相対的な低さも考慮すると、問題はより深刻になっているはずである。 ではどうすればいいのか？　やみくもにモニタリング用のＩＴツールに飛びついても効果は期待できない。金をドブに捨てるようなものである。まずは、モニタリングに関してその本質を理解し、モニタリングの仕組みを設計することである。例えば、（ビジネス上の目的を達成するために）管理すべき項目と、それを評価するための指標は何か、その値の評価方法は設定されているか、その指標を、いつ、どこで、誰が、どのように収集し、誰が評価するのか、などなど。あとは、ＩＴ化が必須な指標、ＩＴ化可能な指標を抽出し、ＩＴ化した上で、手作業のモニタリングとＩＴ化モニタリングを包含したモニタリングを構築すればよい。 tag:www.sos-soumu.com,2007:/column/risk/governance//20.153 2007-04-23T07:33:11Z 2007-04-23T07:37:03Z

〜ビジネスに適した端末、シンクライアントの活用〜 　今回は、「環境負荷を低減し、...

soumu_admin 〜ビジネスに適した端末、シンクライアントの活用〜 　今回は、「環境負荷を低減し、ITガバナンスを向上させるにはどうすればいいのか」、についてお話する。 　ITガバナンスを向上させるには、モニタリングや是正措置等を効率的に遂行することがカギとなる。そのためには、かなり乱暴な言い方だが、管理する対象を「簡単」にすることである。では、「簡単」とはどういうことか？　要は、 ・管理対象の種類と数を減少させること ・管理対象を集約すること 　である。 　「簡単」にするにはいくつかの方法がある。ひとつはサーバ統合である。サーバ統合とはサーバを大型化して台数を減少するだけではない。サーバの種類の削減、サーバを設置するデータセンターの削減、サーバ上で動作するアプリケーションの削減も意味している。したがって、サーバ統合を推進することにより、管理対象は集約される上に種類も数も減少するため、管理コストは確実に低減可能となる。 　しかしながら、サーバ統合だけでは十分ではない。実際には、利用部門にパソコンに起因するソフトウエアやハードウエアが数多く存在し、組織内に分散している。このパソコン上のソフトウエアとデータの管理の方がはるかに問題である。では、どうすれば「簡単」に管理可能となるのであろうか？ 　これに対する解がシンクライアント化である。ここでいうシンクライアント化とはシンクライアント専用ハードウエアのみを意味するだけではない。「Go-Global」などのシンクライアント化を実現するミドルウエアや、「USBnux」などのUSBメモリーによる通常パソコンのシンクライアント化も含まれる。 　シンクライアント化によって、ビジネスに必要なソフトウエアとデータは、すべてパソコン上から削除され、サーバ上で集中管理されることになる。要は、「簡単」に管理可能な状態になるわけである。例えば、シンクライアント化により、ソフトウエアの一元管理が容易に可能となる。個々のパソコンをチェックする必要なく、サーバ上で環境設定と動作監視が可能となるからである。また、操作履歴の取得も容易になるため、JSOX対応や個人情報保護等のセキュリティ対策にも十分貢献するものである。 　データとソフトウエアがパソコン上にある場合、 ・組織内に分散したデータの保護やソフトウエアの監視などのために、ウイルスチェック、不正アクセス対策、資産管理等のツールの導入 ・ソフトウエアの高機能化に伴う動作遅延対策として、3〜4年に一度、最新パソコンに買い替え ・障害対策等のためのヘルプデスクの設置 　など、さまざまな形で非生産的な管理を強いられており、その結果として、膨大な費用をかけている。ところが、シンクライアント化により、このような対策の大半が不要となる。つまり、管理が容易になるうえに、コスト削減にもつながるわけである。 　最後に、どこが環境負荷低減なのか？　まず、シンクライアント化パソコンでは画面表示だけを行うことから、動作遅延による買い替えニーズが発生しないため、製品寿命いっぱいまで延命（通常使用に比べ１．５〜２倍の寿命）可能である。その結果、パソコン製造時に発生するCO２の削減があげられる。また、サーバ数の削減やデータセンタの集約による消費電力の低減も期待できるのだ。 ]]> tag:www.sos-soumu.com,2007:/column/risk/governance//20.142 2007-03-13T08:19:33Z 2007-03-13T08:21:01Z

〜ビジネス利用におけるパソコンの課題〜 　今回と次回は集中化の話。 　集中化、な...

soumu_admin 〜ビジネス利用におけるパソコンの課題〜 　今回と次回は集中化の話。 　集中化、ないし集約化はIT統制（ITガバナンス）を向上する上で必須といえる。この｢集中化｣という言葉は、かつてコンピュータ方式の主流であった中央集権的な汎用機システムが連想されるためか、あまり評判が良くないようである。たしかに汎用機システムは使い勝手が悪い代物であった。その反動で出現したのがクライアントサーバ・システムであり、パソコンの表現しやすさ、使いやすさを活かしたものであった。このときからパソコンが本格的にビジネスに取り込まれることになったわけである。 　だが、そもそも、パソコンをビジネスで使用する必要があるのだろうか？　俗にファットクライアントと呼ばれるように、パソコン上にはソフトウエアやデータが大量に存在している。これが、ビジネス外の私的使用、いわゆるパーソナル・ユースであれば、「パーソナル・コンピュータ」であるから、さほど問題ないといえる。もちろん、ディスク障害対策のためのデータ保存やマルウエア対策など、わずらわしい作業が存在するわけだが。 　ところが、この本来「私的使用を目的とした」パソコンをファットクライアントのまま、ビジネスに用いていることから、さまざまな問題が発生している。個人情報漏洩に限ったことではない。ハード障害による重要データの紛失やソフトウエアバージョンの違いによる障害、ソフトウエアのバージョンアップなどに伴う性能劣化による3年程度での買い替え（ハードウエアそのものはまだ老朽化していない）、さらに、新機種を購入すると、それに対応するためのアプリケーション・ソフトウエアのマイグレーション（ハードウエアや基本ソフトウエアの更新に伴い、アプリケーション・ソフトウエアを新たな環境で動作させるためにソースコードを書き換える作業。新たな価値を生み出すわけではないので、ある意味、無駄な作業）など、セキュリティのみならず、ITガバナンス全体に足かせとなっている。 　余談であるが、パソコンの製造に伴う二酸化炭素排出量は、重量比では、家電製品よりも多いそうである。さらにパソコンは、上述のようにライフサイクルが家電製品よりもはるかに短い。皮肉をこめていえば、パソコンを現状のファットクライアントのままで使用することは、環境問題が切実な時代に逆行するような資源大量消費、地球温暖化促進を行っているようなものである。 　では、環境負荷を低減し、かつ当コーナーのテーマであるITガバナンスを向上させるにはどうすればいいのか？　次回をごらんいただきたい。 ]]> tag:www.sos-soumu.com,2007:/column/risk/governance//20.126 2007-02-13T03:32:24Z 2007-02-15T08:56:07Z

　標準化・集中化・自動化。よく耳にすることばである。もちろん、この三語はIT統制...

soumu_admin 　標準化・集中化・自動化。よく耳にすることばである。もちろん、この三語はIT統制のためだけではない。他のマネジメント領域でも、重要な概念である。先日、サン・マイクロシステムズの方と話をしたときも、SOXへの対応として、偶然同じキーワードを用いていたので驚いたのであるが、ガバナンスを向上することを追い求めれば、標準化・集中化・自動化に行き当たることは不思議ではないのであろう。 　まず、標準化である。共通化と表現してもいい。要は、組織内において、 ●規則・ルール・制度等の基準が統一されており、均一の判断で適用されていること、 ●プロセスが定義され、可視化され、文書化が行われており、組織内で同一業務のプロ　　　セスは基本的に同一であること、 ●このプロセスに関連する組織・リソースは明確であり、関わり方（実行、承認、記　　　録、モニタリング等）が上記の基準により定義され、実行されていること 　である。もちろん、例外となるプロセスもある。例えばグローバル企業の場合には、税務や労務関連では、国ごとに違いがあるのは当然であろう。 　では、標準化ができていないとどんな問題があるのだろうか。SOXに当てはめて説明しよう。例えば、同一業務のプロセスが支店によって違っていたりする場合である。この場合、それぞれの支店ごとの業務プロセスに固有のリスクが認識され、コントロールされている必要があり、それだけ、財務内部統制の整備及び運用において作業量が増加することになる。それだけではない。上述した基準類もそれぞれの支店用が準備・管理されていなければならない。要員教育も共通化できない部分が存在することから、支店間での人事異動には、異動先支店での再教育が必要となるなど、さまざまな負荷が存在する。おそらくは、対応するITも支店対応にカスタマイズしたり支店単位で開発していたり、という事態になっているはずである。 　このことは、しばしば全体最適VS部分最適として議論されてきたことでもある。すべての組織で全体最適がいいかというと、そうではない場合もあるが、おおかたの場合、全体最適の方がベターであろう。鉄道における線路の幅を考えてみるとよい。山間部などでは狭軌の方がよく、平野部で大量輸送が必要な場所では広軌がいいように思われるが、場所によって線路の幅がさまざまでは、全体として極めて非効率になるわけである。 tag:www.sos-soumu.com,2007:/column/risk/governance//20.116 2007-01-10T01:39:17Z 2007-01-10T01:41:26Z

　JSOXでは外部委託に関する監査も必要となる。これは明白である。ところが、IT...

soumu_admin 　JSOXでは外部委託に関する監査も必要となる。これは明白である。ところが、ITをアウトソースしている企業では、この点に関して認識が甘いところが多い。IT部門を有し、IT資産も所有している企業であれば、JSOXにおけるIT統制、特にIT全般統制を評価・監査しなければならないことは、ほとんどのJSOX関係者が認識している。このIT部門を子会社化している企業でも同様である。ところが、IT部門とIT資産を外部に売却した企業や、最初からIT部門を持たずにIT関連機能を外部委託している企業では、IT全般統制が必要であることが理解されていないようである。 　当然のことながら、ITを外部委託している場合でも、IT統制は必要である。IT業務処理統制に関してはマニュアル業務処理統制との関連で、IT機能を内部に有しない企業でも対応せざるを得なくなるはずであるが、IT全般統制に関しては、うっかりすると、手つかずのまま取り残すことになりかねない。 　業務を外部委託している場合の財務内部統制監査には２つの方法がある。ひとつは、その業務の内部統制の状況に関して、受託企業側で内部統制の監査を行った結果を利用する方法である。俗に18号監査等と称されている。これは米国のSAS70に相当する位置づけと言える（詳細は、公認会計士協会が発行している「監査基準委員会報告書第18号（中間報告）「委託業務に係る内部統制の有効性の評価」の改正について」を参照していただきたい）。もうひとつの方法は、委託企業の内部組織と同様に、委託企業の指示に従い、委託企業からの評価・監査をうけるという方法である。 　ITアウトソーサの場合、18号監査を実施している企業はそれほど多くない。たしかに、18号監査は、年金運用や給与計算などを複数の企業から受託している企業であれば、個々の企業からの個別の監査対応を避ける意味で適切な方法といえる。だが、１、２社からITアウトソーシングを受託している企業の場合には、自ら18号監査を実施するよりも、顧客企業から監査を受けるほうがコスト的にも時間的にもメリットがあるかもしれない。もっとも、実際には、ITアウトソーサが18号監査を知らなかったり、必要がなかったために実施しなかっただけの場合が多いのだが。 　いずれにせよ、ITをアウトソースしている企業は、IT全般統制への対応を忘れずに実行すべきである。また、ITアウトソーサは、当然のことながら、受託ITに関する内部統制監査への準備をすべきであると同時に、委託先に早期の対応を促すべきであろう。