見出し画像

「ITオンチな組織」と思われないために

日本がIT後進国という評判は既に定着してしまった感があります。もちろんテックベンチャーもどんどん増えていますが、既存の組織、とりわけIT関連ではない業種ではいわゆる「ITオンチ」問題が深刻化しているようです。

このような「ITオンチ」組織に対しては、すでに様々な立場から様々な助言が提供されていますが、ここではそれらとは少し異なる切り口で、実際的な解決の可能性を探ります。

「ITオンチ」が組織にもたらすもの

「ITオンチ」自体がどういった状態を指すのかはいろいろあるでしょうが、それが組織にもたらす影響は、「発散」の一言で表現できるでしょう。

「発散」とは、「将来がコントロールできない状況」です。クルマがテールを振り出して止まらない、とか、放置された構造物が経時劣化していく、といった例があるでしょう。

「ITオンチ」であることで、組織のIT環境も「発散」します。成功裏に終わった(とされる)数多のプロジェクトで導入されたさまざまなシステム、それらを互いに繋ぐインターフェース、その一方でひっそりとサポート切れを迎えるIT資産の数々、それらの稼働を支えるサポート要員。これらの長期的増加傾向が止まらないという状況です。

発散は最後には破局を迎えるわけですが、それはシステムに関わる人々による日々の献身的な努力と、最終的にはおカネのチカラで、時には荒療治を伴いながらも、なんとか避けられているのでしょう。

昨今ではDXとかAIとかも加わって、プロジェクトが上手く行けばそれはそれで素晴らしいのですが、組織全体ではさらに発散が進んでいるということも有り得ます。しかしそれに気が付くことができないのも「ITオンチ」な組織の特徴の一つです。

ITオンチな組織にたりないもの

ITがいくら発散しようとも、組織の事業そのものの発散は決して許されません。いわゆる「継続事業の原則 (ゴーイング・コンサーン)」に拠って立つ、上場企業であればなおさらです。

逆に言えば、ITを発散させないようにするには、ITを事業に従属させればよい、ということになります。

「そんなの今でもそうだろ」と思われるかも知れませんが、ここでの問題は「意思や意図の有無」です。事業がなければインハウスITも無いので従属しているのは当然ですが、「結果的にそうなっている」のと「意図的にそうしている」のでは大違いです。

意図や意思は表現されなければなりません。表現には言語が必要です。この場合では「ITの事業への従属」という「意図的な構造」の存在を、何らかの言語をもって表現する、もしくは「語る」必要があるわけです。

一般的にこのような言語化能力、表現・読解能力を「リテラシー」と呼びます。ここではその対象は、継続事業 (エンタープライズ) の概念構造 (アーキテクチャ)ということになります。エンタープライズ・アーキテクチャのリテラシーですね。長いのでEAリテラシーと呼ぶことにしましょう。

「ITオンチではない組織」とは、つまりEAリテラシーがある組織、ということが出来るでしょう。

EAリテラシーがたりないワケ

「エンタープライズ・アーキテクチャなんてオワコン」と思われた方もいらっしゃるかも知れません。しかしエンタープライズ・アーキテクチャにはいろいろな定義や解釈があります。今でもそうですが、エンタープライズ・アーキテクチャに関する世の中の大半の言説は、エンタープライズ「向けの」手法のプロジェクトへの適用、ツールの導入といった「インプリイベント」寄りの内容が大半です。

しかしそもそも「事業」は「イベント」ではありません。ここでのエンタープライズ・アーキテクチャは、エンタープライズ、言い換えればゴーイング・コンサーン「そのものの」構造、つまりアーキテクチャです。

このような「文字通りの」エンタープライズ・アーキテクチャが一般的なリテラシーとして普及していけば、「ITオンチ」な組織は徐々に減っていき、ひいてはIT後進国の汚名をそそぐことにもつながるのでしょうが、現実にはなかなかそうなりません。それにはもっともな理由があります。

「ベンダー丸投げ」という表現に代表されるように、日本は欧米と比べてインハウスITの割合が少ない、と言われています。しかしベンダーがインハウスITを代替するかというとそんなことはなく、ベンダーはあくまでベンダーであって、クライアントのゴーイング・コンサーンにまでコミットしてはくれませんし、することも出来ません。

ベンダーは、ゴーイング・コンサーンそのもののエンタープライズ・アーキテクチャは知らないし、知っていてもそれが自分の収益にならない限り、その知見が提供されることもありません。うがった見方をすれば、クライアントのITオンチがLTV最大化に繋っている、とも取れるでしょう。

またそういう日本のIT業界の構造から、ITについて発信される情報も、ITベンダーの収益に繋がるインプリイベントに対する関心が反映されたものが大半です。業界団体や公的機関でさえ、それらに属する人々の大半のキャリア・バックグラウンドはITベンダーなので、結局発信される情報はインプリに偏った内容にならざるを得ません。

個々のプロジェクトは、継続事業の構造の局所的な変化であり、EAといえばその関心はまず継続事業の構造全体に向けられるべきで、それがインハウスITの本来の役割なのですが、業界全体で見れば少数派のインハウスITは、これまでそういうインプリに偏った情報にしか触れることが出来ず、ゴーイング・コンサーンの一部たるインハウスITとして本来必要なはずのEAリテラシーを学ぶ機会に恵まれていた、とはとても言えません。

また、EAリテラシーが広まらないもう一つの本質的な要因として、エンタープライズ・アーキテクチャによって表現される「ゴーイング・コンサーンの内部構造」は本質的に「営業秘密」に当たる情報なので、そのリテラシーも異なる組織の間ではなかなかシェアしにくい、という側面もあります。

日本国内で、特に継続事業のインハウスITでEAリテラシーが広まらない要因として、このような構造的課題があるように思います。このテキストは、そのギャップを少しづつでも埋めようとする一つの試みです。

EAリテラシーがあると出来るコト

EAリテラシーは具体的にはどのようなカタチで発揮されるのでしょうか。それは一言でいえば「モデルの読み書き」です。ゴーイング・コンサーンは「概念」ですから、その「構造」もモデルによって概念的に表す必要があります。

エンタープライズとは大がかりなもので、そこには当然インハウスITに限らず、事業部門 (Line of Business) も含む、様々な立場の多くの人々がインボルブされています。ですから、モデルもごく一部の高度な専門知識を習得出来た人しかわからない、難解なものであってはなりません。

モデルの完成が目的ではないことを十分意識しましょう。モデルはその組織と事業の抽象表現で、同じライフサイクルを辿ります。即ち、事業の入れ替わりなどはあるにせよ、ゴーイング・コンサーンが維持される限り、そのモデルもまた、事業の有り様の変化を反映しつつ、存在し続けるわけです。

EAのリテラシーを身に付けることで、モデルを使ってITの発散を抑止し続け、またその望ましい将来をガイドし続けていくことがゴールです。

もちろん時間は掛かります。しかし事業のライフサイクルを考えれば、EAリテラシーを習得するまでの時間は一瞬でしかありません。

そのような取り組みに着手している組織は、これから決して「ITオンチ」と思われることは無いでしょう。

次回はモデルについて引き続き記していきたいと思います。お楽しみに。

この記事が気に入ったらサポートをしてみませんか?