SOAガバナンスを究める

協調性を発揮してガバナンス・プロセスを押さえよ

（2007年05月09日）

石に刻んだガバナンス・ポリシーはSOA（サービス指向アーキテクチャ）とは無縁である。それは“DOA（Dead On Arrival：来院時心停止）”だとも言えよう。本稿では、“生きた”SOAガバナンス・ポリシーを確立するために、ガバナンスの協調性や効果を維持する方法を紹介したい。

フィリップ・ウィンドレイ
Infoworld 米国版

　現在、ほとんどの組織は、SOAへの取り組みをパイロット・プロジェクト的なものからスタートしており、それを通してこの技術への理解を深め、有益なサービスを構築する方法を学んでいる。しかしながら、隔離されたかたちで実施されるパイロット・プロジェクトでは、複数のグループが協調しながら、より広範なSOAを開発するときに必要となるスキルを習得することはできない。

　ウェブメソッドのSOA製品マーケティング担当副社長、ミコ・マツムラ氏によると、独立したSOAプロジェクトから複数の部署、事業部をまたぐイニシアチブへ移行するときには、ルビコン川を渡るほどの決意が必要になるという。「連邦に新しい部族が合流する瞬間が変曲点となる。新しい人々は固有の文化を持ち込む。パイロット・プロジェクトは単一の文化だが、次の段階に進むときには、多様な文化を取り込む必要があるのだ。そしてそこから先は、まったく新しい世界に突入することになる」

　簡単に言えば、優れたガバナンスには強固なコラボレーションが欠かせないということだ。実は、SOAは、技術的にはそれほど難解ではない。難しいのはむしろ、専門家たちが言うところのOSI参照モデルの“第8層と第9層”、すなわちエコノミクスとポリティクスの部分だ。ガバナンスは、その第8層と第9層を管理するものにほかならないのである。

　『IT Governance』という解説書を著したピーター・ウェイル氏とジーン・ロス氏は、同書の中で、ガバナンスを「IT利用における望ましい行動様式を督励する意思決定権と説明責任のフレームワークを確立すること」と定義している。一方、ジョンズ・ホプキンス大学応用物理研究所のエンタープライズ・アーキテクト、アニル・ジョン氏は、複数の領域にまたがる意思決定権、プロセス、ポリシーを取り扱い、SOAの導入、運用を督励するために整備されるSOAガバナンスは、既存のITガバナンスの拡張として考えるべきだと主張する。

　ガバナンスが取り扱うのは、インタラクションのパターン、受け入れ可能な標準、そしてコミュニケーション・チャネルの確立などである。ガバナンスはまた、組織のインセンティブをSOAの目標に合致させたり、SOAサポート・ストラクチャの構築を促したりといったことにも寄与する。

　ITガバナンスをSOAに適合させる作業は、決して厄介でも退屈でも困難でもない。ただ、合理的かつコラボレーティブなアプローチを必要とするだけだ。

ガバナンス・プロセスを構築する

　SOAの世界にどっぷりと浸ったITマネジャは、SOAガバナンスをプロジェクトのプラニングや予算化という観点でとらえがちだ。もちろん、そうしたアクティビティも重要ではある。だが、SOAガバナンスの肝は、むしろテクニカル・ガバナンス──ポリシー、相互運用性フレームワーク、リファレンス・アーキテクチャ──にこそあると言えよう。そして、ガバナンス・プロセスにおいて最も重要なのは、それらの事項を作成、承認、広報するコミュニケーション・パターンを確立することなのである。

図：ガバナンス・フィードバック・ループ

　コンサルティング会社モメンタムSIのトッド・ビスケ氏によると、SOAガバナンスを確立する秘訣は、それぞれのフェーズにおいて適切なガバナンス・ツールを利用することだという。「適切な時期に適切なパート（プロジェクト、予算化、技術）を実装する必要がある」（同氏）というわけだ。適切な方法でガバナンスを実装し、アーキテクトや開発者たちにガバナンスを明確に示すためには、プロジェクト、アーキテクチャ、予算、および顧客のレビューが不可欠なのである。

　また、ガバナンスに組み込む強制メカニズムも重要だ。ポリシーは強制しなければ、単なる提案にすぎない。とはいえ、暴力組織のように、強制のための手段として脅迫を用いたりするのはもちろん行き過ぎだ。プロジェクト・プラニングや予算計画書、コード・プロモーションの段階で、アーキテクチャ・レビューや日常的な監査、プロジェクト・スコアカード、その他の測定基準を適切に組み込めば十分である。

　同様に、プロセスに組み込むべきものとして、“効果的なフィードバック・ループ”を忘れてはならない。ウェブメソッドのマツムラ氏は、それに関してこう語る。

　「ガバナンス・メカニズムは本質的に連邦制だ。“このレシピでなければならない”と決まっているわけでもなければ、まったく融通無碍というわけでもない。もっとも、ある程度変化を許容する構造にはすべきだろう。その上で、ポリシーは規則として明文化し、規則はフィードバックを参考に修正できるようにするとよい。例えば、ガバナンス・プロセスに判定プロシージャをビルトインすれば、強制プロセスのフィードバックを取り込むことが可能になる」

　フィードバック・メカニズムはまた、プロセスそのものを対象とするレビュー・ボードを持つ必要がある。プロセスの継続的な変更、進歩改善を図るうえでは、レビュー・ボードが不可欠だからだ。

　さらに、ガバナンス・プロセスは、それぞれの組織の風土に適合したものである必要もある。例えば、一元化されたプロセスが適合する企業もあれば、分散化が進んだプロセスが適合する企業もあるのである。

｜1｜2｜3｜ > 次のページへ