Comments
Description
Transcript
ガバナンスの全体像: 開発組織をビジネス戦略に合わせるための運 営と測定
ガバナンスの全体像: 開発組織をビジネス戦略に合わせるための運 営と測定 レベル: 入門 Maria Ericsson, IBM Rational Services, IBM 2007 年 2 月 15 日 「The Rational Edge」より: 組織のガバナンスについての明確な説明が欲しいとお考えですか。この記 事では、さまざまなレベルのガバナンスと、それらが生産性やリスクといった管理上の重要な懸念事項にど のように影響するかについて説明します。また、優れたガバナンスと、ソフトウェア開発組織がプロセスをビジ ネス戦略に合わせることができる能力との関連についても考察します。 今日のグローバルな企業が競争力を維持するには、より高い柔軟性を手に入れ、リソースをこれまでよりも 効果的に使用する必要があります。そのような企業の大半は、社内ビジネス・プロセスの運用においても、 また社外で使用されるソフトウェアやソフトウェア関連製品の生産においても、これらの要件を達成するた めにますますソフトウェアに依存するようになってきています。 このような要件により、すでに多くの従来型開発チームは、より広範囲にわたる一連の責任に対処するソフ トウェア配信組織へと変貌しました。そのようなソフトウェア配信組織は、アプリケーションの開発と保守を行 うだけでなく、ソフトウェア製品とサービスの評価、獲得、および複雑なシステムへの統合も行います。それに は多くの場合、品質と法規制の厳格な要件が伴います。言い換えれば、開発組織はソリューションを提 供するようになったのです。これらのソリューションのためのプロセスのセットには、開発、調達、保守、ユーザ ー・コミュニティーへの移行、運用との統合、および配信プロセスが含まれます。 これらの作業は、組織内の広範な機能を網羅し、効果的なガバナンスを伴う強力なビジネス・プロセスを 必要とします。すなわち、責任、権限、およびコミュニケーションの明確なチェーン、そしてこれらのチェーンを 実行可能なものにするための測定、ポリシー、および統制のメカニズムが求められます。ガバナンスは、組 織内のさまざまな機能にわたるビジネス・プロセスと資産を統制するための鍵となります。優れたガバナンス・ プラクティスの目標は、1) すべてのリソースを全体的なビジネス戦略に戦略的に合わせること、および 2) 組織の運用と投資のリスクを管理することの 2 つです。 優れたガバナンス・プラクティスを策定した開発組織は、ビジネスにおいて貢献の価値に対する認識方法を 変革することができます。そのような組織は、ビジネスに対してベンダーとして振る舞う (ビジネス側の要件に 応じて製品を構築する) のではなく、同じ戦略と価値観を共有し、社内プロセスの改善と新規ビジネスの 獲得の機会についてコラボレーションを行う、ビジネスにおける不可欠のパートナーとなります。すなわち、経 営陣が開発組織をコスト・センターではなくバリュー・センターと見なすようになるのです。 この記事では、開発組織に影響を及ぼすガバナンスの全体像に焦点を当てます。これは 、IBM Rational 組織がテクノロジーとサービスのオファリングの中心的な対象としている領域です。これら のオファリングには、次のようなものがあります。 • グローバルな開発と配信のガバナンスを支援するソリューション。分散開発はグローバリゼーション の結果としてだけではなく、スキルやリソースをその所在場所を問わず効果的に使用しようとする 結果として生じるものです。 • 法令順守とリスク管理の実装を支援するソリューション。法令がより具体的になり、法令違反が 起きた場合に生じるコストがきわめて高くなっています。 • モジュラー式で柔軟なアーキテクチャーのガバナンスを支援するソリューション。例えば、サービス指 向アーキテクチャーには、その使用を促進する特別なガバナンスとライフサイクル管理のメカニズム が必要です。 また、IBM Rational の対象範囲を拡張して、ソフトウェアとシステムの配信のその他の主要面のガバナ ンスを改善できるよう支援する方法についても説明します。 さらに、プロジェクト・ポートフォリオ・ガバナンスの問題、すなわちビジネスのイノベーションのために必要な高 リスクの活動と既存のシステムと製品を維持するために必要な低リスクの投資との間のバランスをとる必要 性についても触れます。大半の企業にとって課題となるのは、後者をより効果的に管理して、リソースをより 高い価値をもたらし企業の競争力の維持に役立つ革新的な製品に集中させるようにすることです。 ガバナンスとは何か 今日の企業は、ビジネス・プロセスを実行するためにソフトウェアに大きく依存しており、依存度は高まる一 方です。また、その多くは、顧客が使用するソフトウェアを作成するか、自社製品にソフトウェアを組み込む かしています。使用するソフトウェアの信頼性と効率性を確保するためには、ソフトウェアを取得、作成、お よびデプロイする際に使用するビジネス・プロセスのガバナンスが必要になります。物理的な在庫や部門の ビジネス・インテリジェンスといったあらゆる重要な企業資産と同様、ソフトウェアとソフトウェア関連資産につ いても、リスクを軽減しながらビジネスにもたらす価値を最大限に高めるためには、慎重なガバナンスが必 要です。 業界共通の定義によると、ガバナンスには次の 2 つの構成要素が含まれます。 • 組織構造内のスタッフが業務を遂行できるようにする責任、権限、およびコミュニケーションのチェ ーン (ガバナンスの静的または構造上の構成要素) • スタッフが組織上の役割と責任を担うことができるようにする測定、ポリシー、および統制のメカニ ズム (ガバナンスの動的または測定上の構成要素) ガバナンスは、管理とは異なります。ガバナンスとは、意思決定を行う権限を持つのは誰かを決定するもの です。一方、組織のガバナンス・アプローチが日常的に確実に実行されるようにするのが管理活動です。 優れたガバナンスとは、創造性を抑えつける拘束手段とビジネス統制で構成されるものではありません。 優れたガバナンスとは、反復可能な測定手段に基づきながらも、起業家精神、高品質の達成、および効 率的な実行を導くという意味を持つものでなければなりません。ガバナンスの測定手段は、実際に作業を 行う人に受け入れられるものであるためには、実証可能な値を持つものでなければなりません。従業員は 、これらの測定手段が、組織をより効果的で生産的にするものであることを理解する必要があります。 優れたガバナンスとは、価値に焦点を置きます。優れたガバナンスは、企業が目標を達成し、ビジネス利 益を享受できるよう支援します。また、効果的な測定と統制を可能にし、適切なコミュニケーションを促進 することにより、リスクの軽減およびチームの有効性の向上も支援します。ガバナンスが不十分な組織は、 成果よりもプロセスに集中してしまうという罠に陥りがちです。そのような組織は、戦略的な目標と実際の 成果への見通しを持たずに、測定のみに基づくインセンティブを提供するようになります。 ガバナンスの主要な目標の 1 つは、組織のビジネス・プロセスの成果が企業の戦略的ビジネス要件に整 合するようにすることです。もう 1 つの重要な目標は、組織の業務運営と投資のリスクの程度を軽減する ことです。 ガバナンスを運用可能にするということは、明確にリスクを減らし、適切な意思決定のための適切な洞察を 提供する測定と統制を整備することを意味します。これには通常、組織的な変革の活動が必要となりま す。一朝一夕に達成できることではありません。ガバナンスを達成するには、十分に定義されたマイルスト ーンと測定可能な成果を含むロードマップに従って段階的に取り組むことが最善です。また、教訓に基づ いて進む道を調整できるよう、途中で適宜見直しを行うことも重要です。 ガバナンスの全体像 ガバナンスの全体像は、企業内の責任の数だけ存在します。この記事では、開発の全体像から見て特に 関連性の高い次のものについて説明します。 • • • • エンタープライズ・ガバナンス ＩＴ ガバナンス 製品開発ガバナンス 開発ガバナンス 図 1 のように、これらのガバナンスの全体像は必ずしもすべてが同じ抽象レベルを共有するものではありま せんが、相互に密接に関連しています。 エンタープライズ・ガバナンスは、全体を包含する全体像です。ＩＴ ガバナンスは、エンタープライズ・ガバナン スのサブセットです。製品開発ガバナンスもエンタープライズ・ガバナンスのサブセットで、ＩＴ ガバナンスの兄 弟にあたり、類似する点や重なる点が多数あります。自動車業界やエレクトロニクス業界など、ＩＴ システ ムだけでなく製品の開発も行う組織にとって関連性があります。開発ガバナンスは、ＩＴ ガバナンスと製品 開発ガバナンスの両方のサブセットです。IBM Rational 製品およびサービスは長年この領域を対象とし てきたため、Rational チームはこの領域について深い専門技術･知識を有しています。 開発ガバナンスは、ＩＴ 分野でも製品開発分野でもほとんど同じと思われるかもしれませんが、実際はそう ではありません。過去の経緯という理由から、焦点、優先順位、用語までも異なっています。 図 1: ガバナンスの全体像 開発組織が成熟するにつれて、2 つの全体像の間には重なる点が多くなります (図 2 参照)。IT 組織 は資産を製品として取り扱うようになり、製品開発組織はよりビジネス中心となっていきます 。IBM Rational では、このよく似た 2 つの全体像を表すのにソフトウェア/システム配布ガバナンスという 用語を使用しています。ただし、この記事では今後も、Rational のもっとも深い専門分野であるこのガバ ナンスを表すのに、より馴染みのある開発ガバナンスという用語を使用します。 図 2: ソフトウェア/システム配布ガバナンス成熟した組織では、これらのすべての全体像が緊密に整合し ています。効果的で戦略的に整合した IT ガバナンスや製品開発ガバナンスなしに、優れたガバナンスを 得ることはできません。 エンタープライズ・ガバナンス エンタープライズ・ガバナンスは、主に企業の会計士や経営陣にとっての懸念事項となります 。Information Systems Audit and Control Foundation では、エンタープライズ・ガバナンスを次の ように定義しています。 ...戦略的な方向性の提供、目標の確実な達成、リスクが適切に管理されていることの確認、組織のリソ ースが確実に使用されていることの検証を目的とした、取締役会および経営陣によって実行される責任と プラクティスのセット エンタープライズ・ガバナンスの 2 つの面、すなわち適合と遂行のバランスをとる必要があります。 • 適合面は「コーポレート・ガバナンス」とも呼ばれます。取締役会の構成、役割、および責任といっ た、特に経営レベルの問題を対象とします。規範や標準の順守も対象となる場合があります。例 えば、多くの企業は 2002 年サーベンス・オクスリー法の規制フレームワークに関する監査を受け ています。とはいえ、適合と順守は同義語ではありません。順守には、意思決定がどのように実 行されたかを証明する特定の文書が必要です。 • エンタープライズ・コンプライアンスの遂行面では、戦略と価値創造に焦点を置きます。この面は、 標準や監査の体制作りにすぐに役立つものではありません。その代わりに、組織では価値を定義 し、その価値をさまざまな組織レベルでどのように測定および監視できるかを定義することに取り 組みます。 エンタープライズ・セキュリティー・ポリシーを適合という面の一部と捉えることもできますが、セキュリティーは多 くの場合、複雑な文化的な問題です。多くの企業は、どのように意思決定がなされるか、および意思決定 がどのような指標に基づいたものか、に関する情報を制限することを選択します。そのようなポリシーは、ガ バナンス・ポリシーの実装方法を制限することになります。セキュリティー・ポリシーのために特定のガバナンス 指標を公表することができない場合には、外部からはそれらの指標に基づく意思決定には論理的根拠が ない、または危険であると思われる可能性があります。 優れたコーポレート・ガバナンスだけでは、企業の成功を達成することはできません。企業は常に、境界的 な状況をもたらすセキュリティー上の懸念を持ちながら、適合と遂行の間のバランスをとるよう努めなければ なりません。 エンタープライズ・ガバナンスの背景の詳細については、[9] を参照してください。 ＩＴ ガバナンス IT ガバナンスは、組織の情報テクノロジー・プロセスと、それらがビジネス目標をサポートする方法に関連す るものです。図 3 のように、IT ガバナンスの全体像は、IT 組織内のさまざまな責任を表す複数の中心 領域に分けることができます。これらの領域をガバナンス領域と呼んでいます。 IBM Rational ソリューションは、プロジェクトおよびポートフォリオの管理とプロセスのためのツールと専門 技術･知識により、IT 戦略ガバナンス領域と IT ポートフォリオ・ガバナンス領域で顧客をサポートします 。また、Tivoli との組み合わせにより、運用ガバナンス、およびリスクと法令順守のガバナンスについてもサ ポートします。 図 3: IT ガバナンスの全体像 多くの IT 組織は、標準的なガバナンス・フレームワークを使用して、意思決定権の割り当てとプロセス指 標の策定を行います。もっとも広く使用されているフレームワークとしては ITIL や COBIT があります。 • ITIL (IT Infrastructure Library) は、組織が現在および将来のテクノロジー上の課題を克 服できるよう支援することを意図した、国際的に認知され現在も進化を続けている IT ベスト・ プラクティス集です。ITIL は主に実行を対象としており、活動の一環として統制に対処します。 世界中の IT 部門が、IT サービス管理戦略の実現を含め現在のテクノロジーを効率的かつ効 果的に実装するための指針となるロードマップとして ITIL を使用しています。詳細については 、ITIL 公式 Web サイト (http://www.itil.co.uk/) を参照してください。 • 米 国 IT ガ バ ナ ン ス 協 会 (ITGI) に よ る COBIT (Control Objectives for Information and Related Technology) バージョン 4.0 も広く使用されています。COBIT は、マネージャーが 統制要件、技術上の問題、およびビジネス・リスクの間のギャップを解消できるようにする IT ガバ ナ ン ス ・ フ レ ー ム ワ ー ク お よ び サ ポ ー ト ・ ツ ー ル セ ッ ト で す 。 COBIT の 詳 細 に つ い て は 、http://www.isaca.org/cobit を参照してください。 IBM® Tivoli® Unified Process (ITUP) は ITIL と緊密に整合しています。詳細については 、http://www.ibm.com/software/tivoli/features/it-serv-mgmt/itup/index.html を参照してく ださい。 製品開発ガバナンス 製品開発ガバナンスは、社内使用向けの IT システム (自動給与計算システムなど) ではなく製品 (携 帯電話や航空機など) の開発を行う組織向けのガバナンスで、IT ガバナンスの兄弟にあたります。抽象 化した全体像からは、IT ガバナンスと製品開発ガバナンスは非常によく似ているように見えますが、過去 の経緯や開発とデプロイメントのテクノロジーの違いから、実際にはいくつかの違いがあります。例えば、製 品開発ガバナンスでは、製品戦略、製品ライフサイクル管理、および製品マーケティングに関するプラクティ スも対象となります (図 4 参照)。 開発と配布のプロセスの経済の管理という面では、製品開発ガバナンスと IT ガバナンスにはいくつかの共 通点があります。ソフトウェア中心の製品については、プロジェクトのリスク曲線を管理して、活動がビジネス とエンド・ユーザーの両方に価値を提供できるように注力する必要があるという点は共通しています。 図 4: 製品開発ガバナンスの全体像 開発ガバナンス 開発ガバナンスは、IBM Rational がもっとも深い専門技術･知識、広範な製品とサービスのオファリング 、および長年にわたる成功の実績を持つガバナンス領域です。開発ガバナンスは、開発組織に対する、ま たその開発組織が開発プログラムを実施する際に使用するビジネス・プロセスに対する、ガバナンスの適用 です。優れた開発ガバナンスとは、次のようなものを意味します。 • アプリケーション/製品、アプリケーション/製品のポートフォリオ全体、およびアプリケーション/製品 のベースとなっているアーキテクチャーに対する組織内の所有権が明確に定義されている。 • 複数の開発プログラムに対する一貫したプログラム評価の推進と一貫した運用メカニズムの使用 を目的とした組織全体にわたる測定プログラムがある。 優れた開発ガバナンスのプラクティスは、開発投資によって、期待される価値がどの程度実現可能である かを組織が判断できるようにします。期待は常にリスクにさらされています。リスクの程度はプロジェクトの特 性により異なります。解決すべき問題がどの程度よく知られているか、以前に同様のことを行ったことがある か、といった特性です。図 5 は、プロジェクト・ポートフォリオに関連するリスク曲線を表したものです。 • リスク曲線の低い位置にあるのは通常、保守や移行に関する問題に対処するプロジェクトです。 ソリューションの開発プロセスは多くの場合、トランザクション中心であり、結果が比較的予測可 能です。開発ガバナンスのプラクティスとプロセス改善活動は通常、コスト効率に焦点を置きます 。 • 新しいテクノロジー、プラットフォーム、または一般に知られていないものを導入するプロジェクトは、 リスク曲線の中間に位置します。解決すべき問題がより複雑になるため、アプリケーション/製品の アーキテクチャーとプロジェクト管理により大きな焦点が置かれます。開発プロセスの特性としては やはりトランザクション中心と分類できますが、結果は上述のカテゴリーのプロジェクトほど予測可 能ではありません。プロセス改善活動とガバナンス・プラクティスの一般的な目標は、開発と配布 のプロセスを迅速に実行できる環境を作り出すことです。解決できない問題にリソースを浪費する ことを避けるには、繰り返し型開発手法が重要です。 • 革新的な概念を探究するプロジェクトはもっともリスクが高くなります。とはいえ、企業に競争優位 性をもたらす可能性がもっとも高いのもこの種のプロジェクトです。企業の将来にとって新しい選択 肢を生み出す重要な投資です。 図 5: さまざまなプロジェクト・タイプのリスク (予測に差異が生じる可能性) の程度 企業が競争力を維持するには、曲線の 3 つの部分すべてに該当するプロジェクトを実行する必要があり ます。低リスク・プロジェクトは、生き残るために必要です。中リスク・プロジェクトは、企業がテクノロジーの変 化に適応し、それを利用することを可能にします。高リスク・プロジェクトは、成長のために必要です。 また、1 つのプロジェクトをこのリスク曲線に置いてみると、プロジェクトの実行の過程でリスクがどのように変 化するかも把握することができます。プロジェクトの特性が配布ライフサイクルの過程で変化するからです。 十分なガバナンスを受けたソフトウェア配布組織と配布プログラムは、このようにしてプロジェクトのトラッキン グを行い、変化するリスクの程度に対処する方法を理解します。 組織全体またはプロジェクトごとの全体像のいずれからであっても、ガバナンス・プラクティスを使用してリスク を管理するには、意思決定者が誰か、および責任はどこにあるかを知る必要があります。それをしなければ 、投資が独り歩きして、企業の目標と戦略から逸脱しかねません。また、ガバナンスとは、測定手段を整 備して、結果のトラッキングを行い、結果が期待したとおりでない場合には投資を制限することでもあります 。 差異と、適用したリスク分析の詳細については、[4] と [10] を参照してください。 ガバナンスの開始点 組織がより優れたガバナンス・プラクティスを導入しようとする取り組みに着手する理由はさまざまです。ここ では、そのうちのいくつかを紹介します。IBM および IBM Rational は、サービス指向アーキテクチャー (SOA) を構築する取り組み、法令順守のための IT サポート、および GDD (地域的分散開発) のた めのソリューションを数多くサポートしており、またこれらの領域のガバナンス・サポートも行っています。下記 では、開発組織とそのプロセスをより効果的なものに変革する取り組みをより総合的に捉えている組織の ためのガバナンス・プラクティスについても説明します。 SOA ガバナンス SOA ガバナンスは、IT ガバナンスを拡張して、特に組織のサービス指向アーキテクチャーにおけるサービス 、メタデータ、および複合アプリケーションのライフサイクルに焦点を置くガバナンスです。 SOA ガバナンスは、SOA プロセスを実行し、アーキテクチャー内のサービスを保守および使用する人のた めの意思決定権と指標を確立します。例えば、各サービスを「所有」するのは誰か、およびサービスが時と 共に進化すべき方向性を決定するのは誰かが明確になっていなければなりません。また、各プロジェクトに ついて、サービスを使用するか否かを決定するのは誰か、またその際の基準はどのようなものかが明確にな っていなければなりません。多くのサービス指向アーキテクチャーは、十分に活用されているとは言えない状 況です。製品開発/IT 組織が、適切な測定手段を整備しておらず、また従業員がアーキテクチャーを十 分に活用するための指針となる意思決定権を明確化していないからです。 法令順守のためのガバナンス 法令順守のためのガバナンスは、エンタープライズ・ガバナンスを拡張したものです。法令順守では、特定の 規制フレームワークを補強するためにガバナンスの測定が実行されていることを文書化し、実証する必要 があります。これにより、フレームワークに関連する意思決定が確実に文書化され、実行に移されます。法 令順守フレームワークは、業種や製品によって異なります。多くの企業は、サーベンス・オクスリー法を順守 する義務を負っていますが、製薬業界の 21-CFR-11 や銀行業界の新 Basel II などの業界固有の標 準にも従う必要がある場合があります。 地理的分散開発のガバナンス 今日のグローバル化したビジネス環境において、企業は、リソースの所在地に関わらず使用可能な最良の リソースを使用して、ソフトウェアをいつでもどこでも開発および配布できるようになることを求めています。こ のような現象は、アウトソーシング、オフショアリング、ライトソーシングなどさまざまな呼び方で呼ばれていま す。これを達成するためには、企業には異なる大陸、タイム・ゾーン、および文化を横断するコラボレーショ ンをサポートする開発環境、および十分に定義され合意された開発プラクティスが必要です。ガバナンスは 次の点に焦点を置く必要があります。 • • 分散開発組織全体にわたる資産に対する責任と所有権を明確にすること。 分散開発組織の構成要素の間のサービス・レベルの測定と制御。 開発組織変革のガバナンス IBM Rational のビジョンは、企業が開発組織に対する社内の見方をコスト・センターからビジネス価値 創造センターへと変革できるよう支援することです。これは単に新しいベスト・プラクティスとツールを導入す るだけではなく、人々の姿勢と文化を変えることです。そのためには、SOA、法令順守、および地理的分 散開発を含む多数のソリューション領域の構成要素を対象とする組織変革が必要です。通常、成熟した 開発組織は開発プラクティスを定期的に変更して、開発組織がビジネスに提供する価値を継続的に最 適化します。 このような組織変革活動を監督し、変革活動が長期間にわたり期待される成果を達成するようにするた めには、優れたガバナンス原則が必要です。 • 変更施策には、測定可能な成果に対する期待を設定する、定義されたマイルストーンまたは意 思決定ポイントが必要です。その上で、開発組織は、成果、およびリスクが軽減された程度に応 じて、プロジェクトを進めるべきか否か、およびどのように進めるべきかを決定することができます。 • 変更施策には、ビジネス・プロセスの中断の程度を制御し、変革による良い影響を評価するため の指標も必要です。これらの指標は、プロジェクト・コストの予測可能性、配信サイクルの長さな ど、もっとも目に見えやすい要素に焦点を当てたものでなければなりません。ただし、施策の早期 の段階では、開発組織内で認識される影響を評価するために、より主観的な指標を使用するこ ともできます。主観的な指標としては、プロジェクト・マネージャーに対する調査や、特定の新しい プラクティスを使用しているプロジェクトの数を決定するための指標などが考えられます。 開発組織変革の詳細については、[8] を参照してください。 ガバナンスのライフサイクル ガバナンスとは、企業のプロセスを実行する人のための意思決定権、制御メカニズム、および指標を設定 し、その上でビジネス戦略またはその他の緊急課題との整合状況を監視することです。ガバナンスは、1 つ のプロセスでもあります。権限と指標、制御メカニズム、および順守と有効性の監視を指定する一連のイベ ントが必要です。開発組織においては、ガバナンス・プロセスは、マネージャーが上記のガバナンス領域にお けるビジネス・プロセスの構造と実行の難しさについて十分な検討に基づく意思決定を行い、開発作業と ビジネス戦略との整合性を高めることを可能にします。 図 6 のように、ガバナンス・プロセスには、ガバナンスを必要とするビジネス・プロセスのライフサイクルとは別 に、ガバナンス･プロセス自体のライフサイクルがあります。 図 6: ガバナンスのライフサイクル (IBM Rational Unified Process® (RUP®) SOA ガバナンス・プ ラグインでの表示) ガバナンス・ライフサイクルの目標は、組織のガバナンス・プラクティスを長期的に強化し、成熟させることで す。組織のガバナンス・モデルを既存のガバナンス成熟度モデルに照らして評価することは有用かもしれま せんが、ソフトウェア組織が必要とするものをすべて完全に反映した既存のガバナンス成熟度モデルという ものはありません。COBIT フレームワークには、組織が COBIT の規範的プロセス・セットをどの程度適切 に制御しているかを判断できる成熟度モデルが含まれています。ただし、COBIT は主に制御目標に焦点 を当てたものであり、他のガバナンスの指標やメカニズムを評価するものではありません。 Forrester Research では、次のような 4 段階の IT ガバナンス成熟度モデルを推奨しています。 • ステージ 1: アドホック。正式な IT ガバナンス・プロセスが整備されておらず、必要とも認識され ていない。 • ステージ 2: 断片的。組織のいくつかの部分においては IT ガバナンス・プロセスを定式化しようと する動きがあるが、全社レベルの取り組みは行われていない。 • • ステージ 3: 一貫性。IT ガバナンス・プロセスが企業全体にわたり一貫して適用されている。 ステージ 4: 最適化。IT ガバナンス・プロセスが企業全体にわたり最適化されている。現在およ び将来両方の IT 投資も最適化できる強力な IT ポートフォリオ管理プロセスが整備されてい る。 結論 ソフトウェア関連ガバナンスの性質と目的を理解することは、優れたガバナンスを達成するための第 1 歩 です。IBM は、プロセスに関する深い専門技術･知識と、長年にわたり組織変革をサポートしてきた優れ た実績に基づき、お客様がソフトウェア/システムの配信のビジネス・プロセスについて効果的なガバナンスを 導入して進化させていくことができるよう支援する、強力かつ包括的なプラットフォームを提供します。今後 の記事で、このプラットフォームの詳細について紹介していきます。 謝辞 この記事は、IBM Rational ディスティングイッシュド・エンジニア Murray Cantor と主席コンサルタン ト David Lubanko のディスカッションを元に作成されました。使用した図の多くもこの 2 人が作成した ものです。IBM Rational の専門家 Walker Royce、Darrel Rader、John Smith、Mary Ellen McElroy、および Geoffrey Bessin からも貴重な情報を提供していただきました。 参照 注: [1] Rational Unified Process、SOA ガバナンス・プラグイン [2] Lin Barnett お よ Murray び Cantor 共 著 「Governing the Business Process of Software and Systems Development」 (IBM ホワイト ペーパー、DeveloperWorks に掲載) [3] Sunita Chulani、Clay Williams、Avi Yaeli、Mark N Wegman、および Murray Cantor 共著「Understanding IT Governance: Definitions, Contexts, and Concerns」 (2006 年 5 月 、 IBM ホ ワ イ ト ペ ー パ ー 、 http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b36006 6f0d4/38905eea124cddfb852571fe00569cce?OpenDocument に掲載) [4] Murray Cantor 著 「 Estimation variance and governance 」 (2006 年 3 月 、 「The Rational Edge」掲載記事) [5] Murray Cantor 著「Making Governance Operational」 (2006 年 10 月、IBM ホワイト ペーパー、公開予定) [6] Patrick McKenna 著「Assessing the economic value of software projects」 (2005 年 11 月、IBM ホワイトペーパー、DeveloperWorks 掲載) [7] Craig Symons 著「IT Governance Framework」 (2005 年 3 月、Forrester レポート) [8] Zoe Eason 、 Maria Ericsson 、 Lynn Mueller 共 著 「 Transforming your software development capabilities: A framework for organizational change」 (2005 年 9 月、「The Rational Edge」掲載記事) [9] 「 Enterprise Governance: Getting the Balance Right 」 (IFAC の PAIB (Professional Accountants in Business Committee)、2004 年 2 月) [10] Jonathan Mun 著 Applied 「 Risk Analysis: Moving Beyond Uncertainty in Business」 (Wiley 2005 年) 著者について Maria Ericsson は、IBM Rational の SSO (Strategic Services Organization) の主席コンサ ルタントです。1990 年に Objectory AB でソフトウェア・エンジニアリングとオブジェクト・テクノロジーの分 野 で の キ ャ リ ア を 開 始 し 、 Ivar Jacobson と 共 著 で 「The Object Advantage: Business Process Re-engineering with Object Technology」を執 筆しました。1995 年に IBM Rational に入社後は、プロセス、ビジネス・モデリング、および要件管理の 指導者兼トレーナーとして業務に従事し、3 年間 RUP 開発チームの一員としても活躍しました。現在 は SSO の業務の一環として、ソリューション・デプロイメント戦略に注力し、IBM Rational のフィールド ・トレーニング・チームにもコンサルタントとして参加しています。スウェーデン在住、キスタ事業所に勤務して います。