これまでArchiMateの各要素をご紹介してきましたが、今回は趣向を変えて、少しテクニカルな話題を取り上げてみたいと思います。

解るヒトが多ければ多いほど良い

エンタープライズ・アーキテクチャは継続事業全体を包含するので、そのモデルも当然大きくなります。ここで気を付けなければならないのは因果関係ですね。こういう取り組みでは先に大きなモデルを作ることをゴールにしがちですが、そうすると大体やっているうちに疲弊してしまって、最後にはこれも「発散」してしまいます。

組織内の誰もがモデルを読んだり描いたり出来るようにすれば、だんだんわかるヒト、つまりEAリテラシーの高いヒトが増えていって、より多くの人々がエンタープライズ・アーキテクチャに関わるようになって、その「結果」モデルも大きくなった、という展開をたどりたいものです。

結局何が重要かというと、組織的なリテラシーであって、モデルはそのためのベースライン、あるいはプラットフォーム、ということになります。そこでプレイする人々の数と多様性、そして能力をいかに増やすか、が成果に繋がる、といえるでしょう。

なんとなくチームスポーツっぽくもなくはないですね。フィールドとルールが有って、そこで戦うプレイヤーがいる訳です。フィールドやルールは継続しますが、個々のプレイヤーはデビューしたり引退したりしながら、そのチームスポーツ自体は歴史を重ねていくわけですね。

プレイヤーの数ですが、全員が一軍というワケには行きませんよね。「高EAリテラシー人財」として、組織の人財ポートフォリオの一部と捉えられるべきでしょうが、これもパレートとかニッパチが当てはまるのでしょうか。仮にそうすると、全組織人員の2割が読めるヒト、そのうちさらに2割が描けるヒト、くらいになるとちょっとすごいことになるのかもしれません。

たとえば社員5000人いるとして、その2割だと1000人ですね。ちょっと多く見えますがどうでしょうか。DXの全社的推進とかやるのだったらその位居てもいいような気がします。また昨今システム内製化などでプログラマ人財を増やす傾向が企業にあるようですが、多分それとのバランスなのだと思います。ダイエットと同じですね。偏食はいけません。

またnon-ITのヒトにデジタル・スキルを身に付けてもらうとして、それがPythonとかのプログラム言語だけ、というのも極端な話で、それに比べればArchiMateはずっと簡単で、それこそリスキリングの選択肢としてもアリでしょう。

そういう人材の絶対数が増えたとして、ArchiMateはデジタル・ネイティブ、つまりデータがモデルの実体で、テクノロジーを使って簡単にスケールさせ、プレイヤーの増加に対応することが出来ます。今回はその方法をご紹介します。

GitHubを眺めてみる

GitHubアカウントをお持ちのかたは、"archimate path:/model/diagrams"でパブリック・リポジトリに検索を掛けてみましょう。検索結果の一つを適当に開いてみて、さらにパスをひとつ上の"/model/"に遡ってみます。

何か見覚えがありますね。そう、Archiのモデルツリーと同じです。検索で使った"diagrams"は、Archiのモデルツリー上のViewsにあたります。

フォルダを開けてみて、要素なり関連なりのxmlファイルがあれば、その中身を見てみましょう。例えば要素だったらこんなのが入っています。これが要素の正体で、簡単なxmlで書かれたテキストデータです。

<archimate:ApplicationComponent
   xmlns:archimate="http://www.archimatetool.com/archimate"
   name="Application Component"
   id="id-fd34d7bea9c04b579f3b8b0ef0b29cfb"/>

GitHub (やGit) に関する情報は、ネット記事とか専門書とかマンガとか、様々なかたちで豊富に提供されているのでここではくわしく触れませんが、ひとことでいえば、プログラムコードを複数人のチームで書いたりレビューしたりするのに使うものですね。

ArchiMateのモデルも、Gitをつかってプログラムコードと同じように、チームで手分けして、変更履歴やバージョンを管理しながら作っていくことが出来る、というわけです。

モデルを描くのに使うのはもちろんArchiです。Archiはアドオンを入れてGitに繋げることができます。自前のローカルリポジトリを持っているのでGitクライアントは不要です。先ほどの検索結果に表示されたリポジトリは、どれもこの「Archi+アドオン」を使ってGitHubにPushされたものです。

もちろんこれと同じ方法を使って、これらのパブリック・リポジトリをArchiで読むことも出来ます。さっそく試してみましょう。

ArchiをGitHubにつなぐ

ArchiをGitHub (なり他のGitなり) に繋ぐには、「coArchi」なるアドオンをArchiに追加します。Archiのホームページ (またはGitHubリポジトリ) からこれもタダで入手できます。

ArchiからGitHubに繋ぐにはSSH認証が必要なので、GitHubリポジトリのWikiに書かれている手順に従ってキーファイルを作成し、ArchiとGitHubそれぞれに仕込みます。

GitHub側で面白そうなリポジトリを、あらかじめ自分のアカウントにForkしておきます。

Archiのツールバーに、青い丸印が三角に並んだボタンがあるので、それで"Collaboration Workspace"ペインを表示させます。ペインのツールバーの"+"ボタンを押して、先ほどForkしたリポジトリを "git@github.com:{自分のGitHubアカウント}/{forkしたリポジトリ名}" で指定します。

上手く行けば"Fetching..."というダイアログとプログレスバーが出てから、程なくして"Collaboration Workspace"にリポジトリが追加され、モデルツリーが表示されます。

こんな感じで動くことが分かれば、あとは自組織のモデル用のプライベート・リポジトリを作って、ブランチ切ったりコミットしたりプルリク出したりイシューあげたり、といったGitのお作法の練習あるのみです。最初は情シス内で一桁人数で始めて、徐々に組織内に仲間を増やしていきましょう。

自組織のホンモノのモデルを、GitHubのようなインターネット上のリポジトリに置くのはさすがに憚られるので、実際には自組織内のGitサービスに置くとして、既設の自前Gitがあれば良し、無くともまずはGitHubで、タダですぐPoCが始められる、というところがミソです。PoCの後に高額な支出の意思決定があるわけでも有りませんが。

モデルを公開する

ここまではモデルを「描くヒト」のお話でした。先ほどのニッパチでいうところの2割のさらに2割、全体の4%ですね。2割の「読むヒト」には何ができるでしょうか？

こちらはとても簡単で、Archiのファイルメニューからリポートを選び、htmlファイルのフルセットを書き出して、適当なウェブサーバーに置くだけです。

要素をクリックして説明文などを見ることもできますし、ビューのズームイン、モデルツリー上の要素検索も可能です。残念なのは関連の線がクリッカブルではないところくらいでしょうか。

事業変化のスピードにも拠るでしょうが、少なくとも例えば四半期決算の度など、定期的に更新すべきでしょうね。最初はショボくても良いのです。自分の関わる仕事がそこに描かれてない、あるいは孤立している、などに気づいた人に描いてもらえば良いのです。

「パーパス」を伝える

トラディショナルな大組織で縦割りのマネージメント・スタイルにどっぷり漬かってきたヒトには、相当抵抗があるかも知れませんね。organic growthな環境下で富を分配するとき、縦割りは目隠しとして役に立ちました。それが存在することで、他部署のやること (＝最近よく言うところのパーパス) に干渉しない、とか、自分の取り分が多いか少ないかわからないので不平不満もでない、といった「安定した秩序」が保たれていたわけです。

エンタープライズ・アーキテクチャはそういう「目隠し」を取っ払ってしまいます。そしてその構成要素の重要性は、SNSよろしく「繋がりの多さ」で評価されることになります。

アーキテクチャのすべての構成要素は当然パーパス (＝存在意義) を伴います。大事なのは、折角それを言語化するわけですから、それを組織内でアナウンスしなければ意味が無い、ということでしょう。その「パーパスを組織内でアナウンスするメディア」としてアーキテクチャ・モデルが役に立ちます。

そしてパーパス同士が繋がって、新しい価値が生まれたり、デシベル高いけどパーパスがない要素が淘汰されたり、といったことがエンタープライズ・アーキテクチャの変化 (＝トランスフォーメーション) として「デジタルに」記録され続けていくわけです。

----

次回からは何回かにわたって、ArchiMateの要素同士を結び付ける「線」のご紹介です。お楽しみに。