DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回のブログはAMOの役割について述べてみたい。同じ“AMO”でもアプリケーション管理を外出しするApplication Management Outsource の事ではなく、アーキテクチャ管理チームの事である。末尾に同じOfficeが付く“PMO”（Project Management Office）がプロジェクト管理を束ねるのと同様に、AMOは企業システムのアーキテクチャ管理を束ねる。企業システムが大規模、複雑化するにつれ、どちらもIT部門に必要となってきた組織である。PMOについては既に一般化されており読者の皆さんもイメージし易いと思われるが、AMOについては未だ馴染みが薄いと思われるので、ここでご紹介することにしたい。（PMOについては弊社コンサルタント弘中氏の2011.12.6ブログが分かり易い。）

まずのっけから辛口でアンチパターンについて触れておきたい。AMOはPMOと同時に、会議招集やファシリテーターの単なる事務局ではない。ましてや、トラブル時の駆け込み寺や火消しでもない。Management Office を直訳すると“管理事務所”となり、受け身的イメージが残念である。現場が強い日本の企業組織において、このマネジメントオフィスが機能するには、具体的な役割の定義とそれなりの権限が必須である。さもなければ、現場にとっての事務局と化すのは時間の問題である。ちなみに現場とは、AMOから見た各個別プロジェクトを指し、既にEA組織がある場合は、BA､DA、AA、TA の各専門部隊を指す。

ではAMOが単なる事務局や敗戦処理役にならない為には何が必要なのであろうか？ダメな戦略の尻拭いをしなくて済む為には何が必要なのだろうか？その答えは、将来のアーキテクチャ戦略に対してリーダーシップを担う事である。常に数年先のアーキテクチャ青写真を自ら描き、詳細な落とし込みは各現場組織に委ねるといった振る舞いができるかどうかだ。この青写真の粒度は前回ブログで紹介したような“鳥の眼（バーズ・アイ）”のレベルで良いが、それでも、ある程度はBA､DA､AA､TAの中身に入り込み理解する必要がある。決して「表面的な管理に徹する」といったきれい事では済まない。

図１にAMOとして常に机の傍らに置いておきたい成果物「アーキテクチャ・ロードマップ」を示したのでご覧いただきたい。この図を見れば、およそAMOが何をやらねばならないのか、どんな情報を必要とするのかが解るのではないかと思われる。もっとも1枚の絵で表せない部分は詳細別紙となるが、ペーパレスの場合にはWEB画面でのハイパーリンクによるドリルダウンとなる。余談であるが、近年、EA関連の案件が増えるに連れ、弊社内の教育用に購入したA1版プリンタが大活躍している。

まずこの図のポイントであるが、大きく次の２つである。１つ目は、縦軸のBA⇔DA⇔AA⇔TA各層の相互の整合性のチェックである。2つ目は、横軸の時系列に沿ったEA各層の段階的マイグレーションの実現可能性のチェックである。具体的にそれぞれのチェック内容について触れてみると、縦軸では、目的とするビジネス・イノベーションに必要な情報を生成するためのデータ環境となっているか？⇒そのデータ環境を必要なタイミングで生成するアプリケーション環境となっているか？⇒そのアプリケーション環境が十分に稼働できるインフラ環境になっているか？といった点でのチェックがこれに相当する。横軸では、ビッグバンにより一気に新アーキテクチャ（ToBe）に切り替えるリスクを軽減するために、CanBe-1､CanBe－2といった段階的移行を考慮した青写真が、時系列に同程度の飛躍となっているか？といった点でのチェックが必要となる。

このようにして、縦軸、横軸の両方の制約条件をクリアーできるバランスの良い現実的な解としてのアープリケーション・ロードマップが完成する。エンタープライズ・アーキテクチャは個々のプロジェクトを越えて計画されるので、このロードマップはあくまでアーキテクチャ中心で作成されるので良い。しかし直近の２～３年に関しては、図１の上部にある個々のプロジェクト・スケジュールとの整合性（EAがどのような状況で新システムが稼働を迎えるか）をチェックしておく必要がある。

さて、一旦作成されたロードマップは、必ずしも予定通りに進捗するとは限らないので、毎年、微修正を加えながら同様のスパンで計画を練り直す必要がある（最後の一年分はたえず新設）。なお、年度毎のローリングプランが難しい場合は、微修正は毎年行うが新規追加はｎ年に１度、ｎ年分を追加するのでも構わない（中期計画方式）。如何であろうか。こうしてみると、プロジェクトを越えた次元で存在するアーキテクチャの変遷には終わりがない事が分かる。従って、AMOというチームはプロジェクトとは無関係に常設することが必要となる。

最後に、このAMOの設置で忘れてならないのが、十分な権限の付与である。通常、組織横断の横串を通すチームの設置にはかなり高位の権限が必要であり、システム部門長の直轄とするぐらいが好ましい。そろそろ、ITスラムからの脱却を図りアーキテクチャ主導への転換をお考えのユーザ企業の方、特に大規模複雑系のレガシーマイグレーション課題をお持ちの企業の方、少人数で構わないので、AMOの設置を考えてみてはどうだろうか。