『COBIT等各種取り組みと「ＩＴの戦略的活用」の関係についてのまとめ その4』

　　
本日は私がこれまでに「経営に貢献するＩＴを実現する」と
いう事に関して取り組んできたことと、ＣＯＢＩＴやValIT、ＩＴＩＭ、
ＥＡ、ＵＩＳＳなどの各種取り組みの関係について整理したいと
思います。

私がどのような形で「経営に貢献するＩＴを実現する」という
ことに取り組んできたかは、拙書「経営戦略の実効性を高める　
情報システム計画の立て方・活かし方」に記載されています。

もちろん、その周辺領域についての各種取り組みが多々ある
わけですが、主として　

　　・事業戦略から必要となるＩＴを如何に導きだすか

　　・その実現を如何にマネジメントするのか

が、拙書のテーマになっています。

　　
ＣＯＢＩＴなどの各種取り組みとの関係で言えば、前者の「事業
戦略から必要となるＩＴを如何に導き出すか」は、ＥＡにおける
戦略からビジネスアーキテクチャ、アプリケーションアーキテク
チャの設計の領域とほぼ重なっています。また「その実現を
如何にマネジメントするか」については、ValITやＩＴＩＭにおける
ＩＴ投資マネジメントの仕組み構築の領域と重なっています。

対象とする領域としては、上記の重複があるわけですが、
重きをおいている部分には違いがあります。一つは、ＥＡや
ValITなどの取り組みが、「経営に貢献するＩＴを実現するための
概念を整理し、実現に向けてのフレームワークの定義」に
重きを置いている一方、拙書では、フレームワークの定義に
加えて、「実際にどのようにして、その仕組みを実現するのか」
を明らかにすることに重きを置いています。

例えば、ＥＡにおいて、ビジネス、アプリケーション、データ、
テクノロジーの４つの領域について整合性をもったアーキテ
クチャを設計すべきとの考え方が示されています。そして、
その実現方法としては、現行アーキテクチャと将来アーキテク
チャを明らかにし、そのギャップを段階的に埋めていくことで
将来アーキテクチャの実現を行うとなっています。

ＥＡに関する最大の難しさは、将来アーキテクチャを如何に
設計するかにあります。まずは、ビジネスアーキテクチャー
ということで、現行ビジネスアーキテクチャーを元に、より業務
効率が高いビジネスアーキテクチャ(業務フロー）を設計しても
意味がありません。将来の事業のあり方（商品、地域、仕入先、
顧客、競合他社、事業規模、市場の成長性・・・等々）を踏まえて
このビジネスで自社が狙うべきポジションを得るために、どの
ような事業形態をとるべきかから、将来アーキテクチャを導き
だすことが必要です。つまり、事業戦略を明らかにし、その戦略
から将来アーキテクチャを導き出さなければなりません。

この戦略から将来アーキテクチャを導き出すために、具体的に
どのように考え、どのような作業を、どのような手順で行えば
良いのかが、ＥＡでは不明瞭です。ＥＡの解説書籍などを読ん
でも、戦略はＢＳＣで整理し、そこから将来ビジネスアーキテ
クチャの設計ドキュメントである業務フローや、組織モデルなどを
描き出すとされていますが、具体的にどのように検討を進めれ
ばよいのか記載されていません。

例えば、

ＢＳＣというのは業績管理のためのフレームワークとして開発
されました。それを戦略立案のためのフレームワーク、さらに
ＩＴのアーキテクチャを描き出すためのインプットして使用する
場合、業績管理用のＢＳＣとしての描き方と同じでよいのか、
別途留意すべきことがあるのか？

事業戦略をＢＳＣで記載する場合、その事業とはどのような
単位か？

立案する事業戦略は、何年先を想定すればよいのか？

ＢＳＣは誰が作成するのか？

ＢＳＣで導き出された戦略を、どのようにアーキテクチャに
落とし込めばよいのか？(具体的方法は？）

　
等々、実際に作業をしようと思うと、良く分からないことだらけ
だと思います。

ＢＳＣで経営課題を整理し、内部プロセスの視点で「在庫の
削減」が課題として導き出されても、「在庫の削減」が必要な
のはＢＳＣで戦略を整理するまでもなく、理解されているはず
です。そうなると何のための戦略の整理なのか、そんな戦略
をインプットにして、将来アーキテクチャを描き出す意味が
あるのかという不毛の議論に陥ってしまいます。

目的を実現するための方法の概念を整理し、その全体像を
フレームワークとして整理することは大切なことです。ただ、
概念とフレームワークだけでは不十分であり、その実現方法
が明確でなければなりません。

拙書では、戦略の整理からその戦略を実現するために必要と
なるＩＴを描き出すためのフレームワークに併せて、どのような
手順で、どのような作業を、どのような観点で実施していくのか
を明らかにしています。この「実現方法を具体的に明らかに
する」という部分に大きな違いがあると思っています。

例えば、戦略を整理し、そこから必要となるビジネスアーキ
テクチャやアプリケーションアーキテクチャを描き出すためには、
次のようなことを明らかにする必要があると考え、記載しています。

　
　事業戦略整理　・・・　経営課題の抽出
　

　　　・その戦略を表現するBSC(バランススコアカード）の書き方
　　　・BSCの各視点の記述に当たっての検討の観点
　　　・戦略をＩＴをつなげるためのBSCでの定義内容
　　　・経営課題を具体化するＫＰＩ（ＫＧＩ）の項目定義
　　　・戦略のゴール設定としてのＫＰＩ（ＫＧＩ）の目標値設定

　重点施策の整理　　・・・　経営課題から実現施策の抽出
　

　　　・経営課題からその実現策である施策の抽出方法
　　　　　(現状調査→仮説立案→シミュレーション）
　　　・施策の目的を明確化するＫＰＩのブレイクダウン方法　　　

　ＩＴ化要件の整理
　　　・戦略とＩＴを連携させる、ＫＰＩのブレイクダウンによる
　　　　ＩＴ化要件の抽出方法
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　等々

(どのようなことを記載しているかは、書籍の目次を参照いただ
ければイメージが湧くのではないかと思います。目次は、こち

らを参照ください。　URL : http://www.ipbc.co.jp/publish.html )

ＣＯＢＩＴをはじめとした各種取り組みにおいて、概念やフレーム
ワークが定義されていますが、これらの検討にあたっては、
おそらく多くの企業などでの活動がベースになり、検討がなされ
ているはずです。それらから、ポイントなる部分を精錬し、概念や
フレームワークにまとめられているのだと思います。

一方、その概念やフレームワークの導入(実現）方法は、その
企業なりがおかれている状況により、最善な方法は異なることが
想定されます。それゆえに、実現方法の詳細な解説は、
フレームワークの定義の範疇で行うことは、非常に難しいので
あろうと想像されます。

このような検討が米国を中心にして進められており、日本には
検討のベースとなった事例や具体的な導入方法などが抜け落ち、
精錬された結果としての概念やフレームワークのみが紹介され
ているように感じます。これは、自分で考えることなく答えだけ
教えられいるようなもので、実力がつかず、自分でいざ行おうと
しても、何もできないというようなことになりかねない事態だと
危惧をしています。

米国産の概念やフレームワークの方が、正しく、成功が約束
されているような気持ちになりますが、答えを丸写しをして
効果が上がるものではありません。実現方法を自ら検討し
それを実践し、結果概念やフレームワークを描き出さないと
意味がないという思いで取り組み、その内容をまとめたものが
拙書です。

「経営に貢献するＩＴを実現する」という目的が同じであるため
概念や全体像としてのフレームワークは、各種取り組みと拙
書では非常に似ています。しかし、概念にとどまらず、自ら
考え、具現化していった実際の活動をから得られた各種ポイ
ントや実現方法にまで踏み込んでいる点に違いがあるのでは
ないかと考えています。