いろいろある基準をどう考えて、どう使うか？：システム部門Q＆A（28）（2/3 ページ）

[木暮 仁，＠IT]

方法論では――EAについて考える

　ここでは、EA、特に行政での「業務・システム最適化計画」を例にします。先に、「勉強するのに資料が得られない」という不満をいいましたが、このEAは国が推進しているだけあって、経済産業省「EAポータル」で、EAに関する豊富な資料が入手できます。

　政策・業務体系、データ体系、適用処理体系、技術体系の4つの体系につき、現状を分析し理想の姿を構築するための方法を示し、12の標準図法を挙げています。

　　　　関係者に解読する能力がない 　　　　

　標準図法を重視するのは、ITという見えないものを、関係者に理解させるために可視化することが重要だからです。それでIT分野では、従来のDFDやクラス図、最近でのUMLなど多様な図法が提案され、活用されてきました。EAの12図法もそれらを採用しています。

　しかし、可視化するということは、関係者がそれを見て理解できることが前提になります。ところが、経営者や実務部門はなかなかそれを理解できません。例えば、個別の情報システムの構築でも、要求分析や外部設計の段階で承認を得たはずなのに、実施の段階になってから、誤解があったり理解されなかったりしていることに気付くことが多くあります。また、UMLの普及が進まない理由の1つに、関係者の読解能力が未熟なことがあるといわれています。

　経営者や実務部門に、これらの図を理解できる能力を持たせることが急務になります。

　　　　体裁を整えることが目的に 　　　　 　

　図は単に関係者の理解を助けるための手段であり、EAは決して図を描くことではありません。これから中央官庁をはじめ、地方自治体にEAを推進することになっていますが、おそらくコンサルタントを活用するなどによって、きれいな図は作ることができるでしょう。しかし、本来の目的である「業務・システム最適化」が本当に実現するでしょうか？

　これまでも、行政は多様な計画を作り、立派なパンフレットを配布してきました。しかし、その多くは完成予定図であり、なかなか完成図にはならないようです。税金を使ってEAの図を作ったことが成果だ、というのでは困ります。

　　　　途中で投げ出さないか 　　　　 　

　民間企業では、さらに危険があります。図の作成には多大な調査や作業が発生します。途中で息切れしないでしょうか。EAは全体の最適化を追求するのですから、部分的な対応では困りますし、図の辞書的な利用もするのですから、抜けがあっては効果がありません。中途半端な図は役に立たないのです。

　　　　逐次アップデートしなければ 　　　　

　業務もシステムも常に変化します。それに伴い、EAの図も更新しなければなりません。ITでは、以前から仕様書が重視されていました。ところが、西暦2000年問題では、「仕様書がない」「仕様書はあるがシステム開発当時のもので、その後の更新は反映されていない」といった状況が露呈したケースが多くありました。

　その原因は、仕様書を直さなくてもプログラムを直せば、システムは動くことにあります。EAの図は、個別システム仕様書よりもさらに間接的なものですから、アップデートされないままに放置する危険が大きいのです。

チェックリストでは――COBITを例に考える

　ここではCOBITを例にします。COBITは、ITガバナンス能力の成熟度を評価する基準です。戦略的な情報化企画から運用に至るまでのプロセスを定義して、それぞれのプロセスについて、CSF／KGI／KPIを例示し、それを成熟度モデルにより評価します。

　漏れのないチェックリストを用いれば、専門家の定めた成熟度レベルと比較して、自社の成熟度が分かりますし、どこに足りない個所があるのか発見できます。また、成熟度を向上させるのに、どの分野でどのようなことを実現するべきかの目標設定に役立ちます。非常に有効な手段だといえます。

　　　　自社重点化が必要だ 　　　　 　

　漏れがなく網羅的であるということは、汎用的だということです。逆にいえば、自社の環境に特化したものではありません。COBITで高いレベルだとしても、その分野では自社はもっと高くなければならないこともあるし、低いレベルであっても特に問題はないということもあります。

　COBITの第3版では、4つの分野、34のプロセス、318のコントロール目標がありますが、それらを平均的に適用するのは不適切です。そこで挙げている例示も、CSFはともかくとして、KGIやKPIでは自社の業務と合致していないものも多くあります。

　自社に合わせた翻訳が必要ですが、自社の重要分野とは何か、どの項目でどのレベルを目標にするかを設定することは、かなり難しいし、そこに恣意（しい）が入り込みます。単にCOBITそのものを適用するのも不都合だし、さりとて、自社に特化するのも問題があるというジレンマがあります。

　　　　適切な評価者が得られるか 　　　　 　

　評価を実施するのに直面するのは、適切な評価者が得られないことです。その項目についてあまり知らない人がムードで評価したのでは困ります。COBITでのチェック項目は多岐にわたっていますので、それぞれについて、知っている人が異なります。誰が何を知っているのかすら分からないこともありますし、職制だけで判断するのは危険なこともあります。経営者の参加は必要ですが、経営者がすべての項目について知っているとは限りません（むしろ、その逆が多いのではないでしょうか？）。

　ISMSやプライバシーマークなど、外部からの審査であっても、それに応対する人が不適切だと誤った判断になることがあります。それで、文書が整備されているかが中心になりがちです。当然、それが実際に順守されているかのチェックもしますが、時間制約などにより、ごく少数のサンプリングになります。審査目的としては十分だとしても、実際にどうなのかを認識するにはあいまいさが残ります。

　　　　プロセスを重視せよ 　　　　 　

　このような評価は、人によって異なります。ある人は「すでに達成している」というし、「いまだ到底そのレベルではない」という人もいます。ITに関する経営者のアンケートでは、中小企業の方が大企業よりも満足度が高いという結果が得られることもありますが、それで中小企業の方が大企業よりもIT活用が進んでいるとはいえません。

　COBITでは、このような個人差を防ぐために、詳細な評価基準を示しています。しかし、現実には「全然していない」ことも「すべて行っている」ことも少なく、「○○はしているが××はしていない」状況であり、人によって○○と××の重要度が異なるのです。COBITといえども、これまでも吸収できるようにはなっていません。

　評価をするには、何らかの手段により、どこかに収斂（しゅうれん）させる必要がありますが、あまりそれにこだわるのは不適切です。むしろ、違いがあるのは当然であり、その違いが生じる根拠は何かを相互認識するプロセスが大切なのです。