新鮮

頑張らないために頑張る

EA の功罪(1) 理想を実現するのは難しい

f:id:hiizumix:20180220123444j:plain 

すこし昔の話をしよう。

システム構築方法論のひとつとして "EA"(Enterprise Architecture) がある。

EA とは「業務とシステムの最適化」を目指し、企業内のすべての業務とシステムを整理して「あるべき姿(tobe)」を計画し、その計画に沿ってシステム化を進めていくべきだ、という考え方である。

代表的な事例としては米国財務省や国防総省、そして日本の電子政府構築などがある。ある程度の大企業では一度は取り組んだ方法論だろう。

EA はウマくいくのだろうか。

業務のムリ・ムダ・ムラを廃絶し理想的な全社業務フローを描いたうえで、それに必要十分なシステムを用意していく。その言葉だけだといい方法論に感じる方もいると思う。

むしろそれが普通なんじゃない?という感覚なのかもしれない。誰でも無駄なものは持ちたくないし、そのうえシステム開発は安くないからだ。意外と知られていないのだが、大企業になると数十億円規模のシステム開発プロジェクトも珍しくなかったりする。

 

そして実際、数年前に EA が流行り(というかコンサルが流行らせ)、超絶高いシステム開発を必要最小限にできる米国発の方法論だとの甘言につられ、トップダウンで導入が推進された。その結果、日本企業で EA が上手くいった事例を僕はほとんど知らない。

儲かったのは上手く逃げ切ったコンサルとパッケージベンダだけである。

 

なぜウマくいかないのか。

僕の経験で話そう。

まず、システム利用企業はあるべき姿(tobe)を作ることが現実的にできない。それはなぜかというと、あるべき姿を描くためには全ての部署からキーマンを招集する必要があるのだが、この時点ですでに無理ゲーだ。

キーマンは当然のことながら多忙なので招集するのは難しいし、仮に招集できたとしても EA 活動に稼働を割くことはできない。すると、なんでこいつ?という方々が集まる。

 

とはいえ会社からの至上命令なのでそのメンツで計画を練り始めるわけだが、そこはまるで動物園の様相を呈することになる。ゴリラが「こういうフローになったらウチが困る」といえば、ライオンが「そもそもお前の部署の業務品質がゴミだ」といい、キリンが「あのシステムのこの画面が使いづらいんだよねー」という。

 

そんな楽しいショーが半年続いたあと、コンサルが綺麗なキングファイルを作り上げて経営層に提出する。紋切り型の市場動向・ポジショニング・経営課題を枕詞にして「EA 活動により素晴らしい計画ができました。これに従えば○○億円儲かります。ぜひとも私たちに任せてください」と言葉を添えて。

もちろんそのキングファイルには、半年におよぶ議論の内容はほとんど盛り込まれない。実施に向けての継続検討課題一覧が小さい字で羅列されるだけだ。

 

それなら実行しないのでは?

では、この EA 計画は実行されるのだろうか。

実行されないと思うのではないだろうか。

 

だが困ったことに実行されるのである。

 

経営層から見れば、社内の人間は信用できないが社外の人間は信用できる。お高いコンサルができると言っているし、儲かるとも言っている。そしてキレイな資料で自分の悩み事(システム開発が法外に高い)が見事に表現されている。そこに拒否する理由は一切ない。ん?またシステム部門が出来ないと言っている?それはオマエラの予算が減るのが怖いだけだろう?

業務部門の部長たちから見れば、プロジェクトに人を出した以上、失敗するとは絶対に言えない。しかも仮に実現できなくてもシステム部門の責任に転嫁できる。EA は素晴らしい成果です。ぜひとも一丸となって推進しましょう!多少の課題はありますが皆で力を合わせて乗り越えていきましょう!

 

そして悲劇が始まるのである。

 

長くなるので一旦切ろう。

僕は EA に懐疑的なスタンスだが実は良い部分もある。そしてそれは EA 以外のプロジェクトにも使える話になる。そんな EA の功罪までお話しできればと思う。

 

おわり

図解入門よくわかる最新エンタープライズ・アーキテクチャの基本と仕組み (How‐nual Visual Guide Book)

図解入門よくわかる最新エンタープライズ・アーキテクチャの基本と仕組み (How‐nual Visual Guide Book)