今回は「導入と移行 ("Implementation and Migration") 」要素のご紹介です。一般的にアーキテクチャの変化をあらわすとき、「使用前」「使用後」のような図を書きますが、その差分も含めてデータにするのに使えます。

プラトー

プラトーは「アーキテクチャにさしたる変化がない期間」です。ただし、これには2つの異なる意味があって、それらの区別を理解する必要があります。

一つは名前通りに「アーキテクチャ目線」で、アーキテクチャのある部分の今の状態、将来の状態という意味の、"As-Is"、"To-Be"、あるいはArchiMate (というかTOGAF) でいう"Baseline"、"Target"と表現される状態です。

ここでの「ある部分」とは、継続事業全体のアーキテクチャのうち、アウトカムやコース・オブ・アクションによって表現される「打ち手」の実現に関わる範囲、ということになります。ベースラインとターゲット両方に生じる変化を合わせると、後述する「ギャップ」となります。

この場合、一つの絶対日付 (年月単位でも) が、ベースラインの終わりとターゲットの始まりとして入ります。

もう一つは「プロジェクト目線」で、そのプロジェクトそのものの表現です。アーキテクチャ目線では、”Baseline"と"Target"の間の移行段階として"Transitory"と呼ばれます。このプラトーにはプロジェクトの終了と開始の絶対日付が入ります。プロジェクトの成功によって「ギャップ」が埋まり、アーキテクチャはベースラインからターゲットに移行します。

「3年中計」はプログラムとしてプラトーに見立てることができます。その下に個々のプロジェクトのプラトーがぶら下がります。

アジャイルも同様に、SAFeでいえば「ロードマップ」「リリース」「プロダクト・インクリメント」はプラトーとして表現できます。

プラトーをガントチャートの矢羽根の代わりにして、タイムラインを表現する、といった使い方もあります (そういうビューを実装しているEA管理ツールもあるようです)。

プラトーは前回のストラテジーレイヤーの「コース・オブ・アクション」と一緒に、シナリオ・プランニングに活用するのが最も有効でしょう。「変更可能な未来」には当然複数のオプションがありますが、それらの着地点をプラトーとして表現するのです。VUCAの世の中ですから少々極端なケースも考えるとして、それらをきちんと描くことが出来るのはとても便利ですね。

ギャップ

プラトー間の、厳密にいうと「ベースライン・アーキテクチャ」と「ターゲット・アーキテクチャ」の間の差異です。ストラテジ・レイヤーの「コース・オブ・アクション」に基づいて、今の構成要素のうち「消すもの」「足すもの」「変えるもの」を、ベースラインとターゲットで特定した結果が含まれます。

構成要素のうち、「消すもの」はベースラインに含まれます。「足すもの」と「変えるもの」はターゲットに含まれます。

これはいわゆる初期のスコーピングに当たります。もちろんこれがそのままプロジェクトスコープではなく、それはギャップのスコープよりも小さくなります。この時点では「このコース・オブ・アクションをやろうとすると、どこを変えるか、どこまでハネるか」の解析が目的です。

ワーク・パッケージ

プログラムやプロジェクト計画、及びそこに含まれるプロジェクト・タスクです。プロジェクト名やタスク名がそのまま使えます。ギャップはワーク・パッケージの入力になります。一つのギャップを一連の複数のプロジェクトで埋めるのが一般的でしょう。

ワークパッケージはもちろん個々のプラトー(＝プロジェクト) に紐着きます。プロジェクトの期間はプラトーに入っているので、プロジェクトの予算金額や規模をワーク・パッケージのほうに入れておきましょう。タスクの期間はその前後にあるインプリメント・イベントで押さえられます。

ベースラインやターゲットのプラトーには、ワーク・パッケージは紐着かないので、プラトーがアーキ、プロジェクトのどちらの目線なのか、という区別になります。

インプリメント・イベント

ガントチャート上のマイルストーンです。必須の属性として絶対日付をもつことは言うまでもありません。プロジェクト・タスクであるワーク・パッケージとは「トリガする・される」関係にあります。

インプリメント・イベントは、それにインボルブされる構成要素と紐付けることができます。新旧切替ならベースラインとターゲットにある要素のうち、どの要素が関連するかを紐づけて示します。そうすることで、イベントの影響範囲の見立てに抜けや漏れがないかをチェックすることが出来ますね。

デリバラブル

プロジェクトの成果物です。プロジェクト計画書に書いてあるのを抜き出し、プラトーに紐付けます。また、ターゲット・アーキテクチャの要素として追加や変更されるものを関連付けます。ベースラインからオフロードされた資産の除却も、忘れずに成果物に入れましょう。また設計文書などの付帯物もデリバラブルです。

デリバラブルが全部そろえばギャップが埋まり、ギャップが全部埋まればコース・オブ・アクションが実現し、コース・オブ・アクションが全部実現すれば、アウトカムになる、という寸法です。

また、プロジェクトで導入されたビジネス・アプリケーション・テクノロジーの各要素は、リソースやケイパビリティを実現し、これらもコース・オブ・アクションの実現に繋がります。

アジャイルの場合はデリバラブルは省略して、「リリース」プラトーが「フィーチャー」アプリケーション・サービスを直接吐き出す、という表現も可能です。

プロジェクト・ライフサイクルとアーキテクチャ

プロジェクトが終われば、その成功、失敗を問わず、導入移行レイヤーの要素は「用済み」となり、適切な「後始末」を経て、期末などのタイミングで、アーキテクチャ・モデルからも「物理削除」となります。計画したがボツになったシナリオも同様です。消さないとデータがバンバン膨らんでしまいますからね。このような手続きを、削除の承認者が出席する定例のイベントとして制度化すると良いでしょう。

アーキテクチャモデルのデータファイルは1年ごとくらいでアーカイブするでしょうから、過去のいきさつはそちらで参照します。

成功した (＝建仮から資産勘定に払出) プロジェクトは、前述のようにコース・オブ・アクションの実現に繋がります。以後前々回でご紹介したモチベーションのバリュー要素を使って、新しく獲得されたリソース、ケイパビリティ、ファンクションなどの将来価値を継続的に評価していくことになります。

失敗した (＝建仮から損金に直行) プロジェクトとは、要するに「アーキテクチャに変化を残せなかった」プロジェクト、ということです。作りかけの成果物がいくつかあるかも知れませんが、それらは機能的にはアーキテクチャ本体とはまだ繋がっておらず、孤立した状態にありますね。ギャップは残り、コース・オブ・アクションは実現されないままですね。

ですので、後始末としては環境や方針(コース・オブ・アクション)が変わらないのなら、ベースラインのプラトーをリスケして先に延ばすでしょうし、コース・オブ・アクションが変わった、或いは無くなったのなら、ギャップやターゲットのプラトーを見直すか、もはや不要なので削除、ということになります。

プロジェクトは「アーキテクチャを変化させてナンボ」ですから、「参入」は敷居低め、つまり承認は軽めにして、「退出」は厳しく、というやり方が今のご時世にはフィットしているのではないでしょうか。いくらカッコいいことを言っても、最終的にアーキテクチャを変えるに至らないプロジェクトはドロップアウトさせるわけです。何だか日本と海外の大学の違いと似てますね。

継続事業にとっては「その変化がポジティブインパクトを生んでナンボ」で、そちらは前述のように、アーキテクチャの全体的な価値評価プロセスの一部として、継続的にモニタする、ということになります。

--------

「導入と移行」要素は、それ自体がオペレーションやビジネスの一部とはなりませんが、いわば「チェンジ・エージェント」として、オペレーションやビジネスのアーキテクチャの変化に関与します。そんなものまで同じ一つのモデル上の要素として扱うことのできるArchiMateは、特に大きな組織のかじ取りに大きな助けとなるのではないでしょうか。

これまでアーキテクチャの「点」をご紹介してきました。組織の規模によっては、点だけ並べるのもけっこう大変ですが、それらを構造にするには「線」を引かなければなりませんね。

とはいえ、概念的なお話が続いたので、「線」のお話に入る前に、次回は少しテクノロジー的に面白そうな話題をひとつ取り上げてみたいと思います。最後にはArchiMate活用のスケールのさせ方に繋がります。お楽しみに。