|
RUP の拡張: ポートフォリオ管理作業分野 |
 |
このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。 |
ソフトウェアポートフォリオとは、計画中のもの、開発中のものの他、導入済みのシステムも含む、組織内の IT プロジェクトの集合です。IT ポートフォリオは、個人の投資ポートフォリオと同じように、ハイリスク・ハイリターンのものとローリスク・ローリターンのものを取り混ぜ、すべてが戦略的なビジネス目的をサポートするシステムの作成に貢献するものでなければなりません。
ポートフォリオ管理作業分野は、実行可能なソフトウェア開発プロジェクトを選択して管理することで、組織内のいくつもの情報技術 ( IT ) プロジェクト全体としての効率および有効性を改善できるよう、RUP を拡張したものです。そのためには、すべてのプロジェクトの情報を見えやすくし、ビジネス目的に向かって計画を立て、協調して進めなければなりません。成功するIT 部門は、1つのシステムのニーズだけでなく、その先を見越しています。研究によると、IT 投資の管理にもっとも成功した組織は、競合と比較して40%も高い利益を上げています。方向付けや初期構想から引退フェーズの終わりまで、システムのライフサイクル全体を通して、ポートフォリオ管理を行う必要があると認識することが非常に重要です。この作業分野のワークフローを図1に示しています。「現在のシステムを棚卸しする」および「ポートフォリオとプログラムを計画する」の2つの作業はときどき行うものですが、残りの 4 つの作業は、組織によってはほとんど毎日行います。
図1. ポートフォリオ管理作業分野のワークフロー
ポートフォリオ計画を作成する前に、現在社内にあるシステム ( 資産と呼ぶこともあります ) の棚卸しをしなければなりません。この作業の目的は、社内に既に何が存在し、現在何が作られているかを知ることです。これによって、何が計画中で何が進行中かの範囲を限定することができます。「サイドプロジェクト」から基幹業務のエンタープライズシステムまで、あらゆるシステムを洗い出す必要があります。これは通常、思う以上に大変な作業です。ただし、プロジェクトおよびプログラム ( 訳注: "プログラム"という用語は, EUP においては銀行, 証券など特定の分野に属するシステムやソフトウェアの集合を指す ) のチェックリストを作成する程度に簡単に済ませることもできますし、サードパーティのベンダーに依頼して、状況を評価し、調査結果の詳細報告を提出してもらうという方法もあります。
図2に示す計画サイクルは、通常、年に一度か四半期に1度の頻度で実施されます。ポートフォリオの計画が重要なのは、ビジネス目的を実現するための計画がなければ、会社の戦略的ニーズに合うようプログラムやプロジェクトを正確に調整することができないからです。
図2. 「ポートフォリオとプログラムを計画する」ワークフローの詳細
ポートフォリオ管理者の責任のうちで大きな部分を占めるのは、プロジェクト候補の評価と優先順位付けです。プロジェクト提案は、どの作業分野のどの役割の人が作成しても構いませんが、一般的に多くは、エンタープライズ・ビジネスモデラー、エンタープライズ・アーキテクト、プロジェクト管理者から出されます。ポートフォリオ管理者は、プログラムやプロジェクトそれぞれのビジネスにおける影響を分析して、ポートフォリオ内の優先順位を付けなければなりません。これを成功させるには、政治的な事柄に左右されない客観的な測定基準が欠かせません。優先順位を付けた一覧は一般の目につくところに掲示して、さまざまなプロジェクトチームのメンバーに、より大きなプログラムやポートフォリオのレベルに自分のプロジェクトがどう影響するかを知らせます。これによって、説明責任の水準が上がり、居心地の悪い思いをする人が出るかもしれません。最終的には、適切なプロジェクト管理者が自分のチームからの情報をもとに、一般に認められた優先順位更新方針に従って、この優先順位の付いた一覧を変更・更新することになります。
組織の全体的なビジネス目的を満たすシステムを確実に導入するには、プロジェクト間の相互依存関係を洗い出し、理解し、ポートフォリオに受け入れなければなりません。この相互依存には、共通アーキテクチャなどの成果物(計画がまとまったときに現れることがあります)、重要なリリース日、新しいインフラストラクチャハードウェアの到着、データベースや他のシステムのアップグレードの予定など、プロジェクトに関する無数の問題が含まれます。またこの機会に、リソースの依存関係またはスキルの重複や余剰を明らかにすることもできます。さらにもう 1 つの利点は、複数のプロジェクト間や、場合によってはプログラム間で、作業を同調させることができる点です。
また、プログラムやそのプログラム計画を定義する必要もあります。プログラムを定義するには、関連するプロジェクトを洗い出すという作業を行い、それをプログラムにまとめなければなりません。プログラム計画には、プログラム内の同種または関連するプロジェクトを、できるだけ効率的なやり方で実装する戦略を定義します。この計画は、1つのプログラム外で動いている他のプログラムやプロジェクトの間の依存関係を、ポートフォリオ管理者に示すときにも役立ちます。
最後に、エンタープライズ変更管理審査会 ( Enterprise Change Control Board: ECCB ) は、拡張や不具合などの変更依頼が来たら、それをレビューする責任があります。最初にまず優先順位を決定し、重大度の高い不具合はサポートチームに割り当てて、ホット・フィックスとして対処させます。重大度の低い不具合と拡張依頼は、審査会で評価し、どの変更依頼に対処するか、どのシステムが影響を受けるかを判断して、変更要求を適切に割り当てます。RUP の構成及び変更管理(C&CM)作業分野で行う1つのシステムの変更管理と、エンタープライズ変更管理とが異なるのは、この部分です。変更依頼は、現在システムが開発中の場合には個々のプロジェクトチームで適切に対処されますし、そうでなければ今後の検討事項として順番待ちの列に入れられます。
ポートフォリオ管理者はポートフォリオ計画にもとづいて動きます。プログラムの範囲をはずれたプロジェクトはこの作業の一環として、それ以外のプロジェクトはプログラム管理の範囲内で始められます。開発構想書の初期バージョンは、おそらくは箇条書きの形式で、ポートフォリオ管理者が作成します。プロジェクトの資金を確保する唯一の方法は、プロジェクトの成果がビジネスの目的に貢献すると確認することです。資金を確保したプロジェクトは、ポートフォリオ計画に組み込まれ、監視対象となります。RUP の視点でいうと、これはプロジェクトを開始するための「方向づけ前」の作業です。この作業の発生は、RUP では暗黙的に想定していますが、EUP では明示的に示しています。
状況は変わっていくものなので、ポートフォリオ管理者はプログラムやプロジェクトの状態を監視しておかなければなりません。2つのプロジェクトが同じ目標を持っていることにポートフォリオ管理者が気づいた場合は、いずれかのプロジェクトを廃止するか、2 つのプロジェクトを併合する必要があります。ポートフォリオ管理の作業が効を奏している場合には、このような問題は起きないはずです。そのため、どういった理由でそのような状況になったかを明らかにしなければなりません。また、プログラムが何かの機能を外部のプロジェクトに依存していて、そのプロジェクトがトラブルに巻き込まれた場合には、管轄するプログラムにしかるべき調整をする必要があります。
この作業はポートフォリオを管理するの作業と非常に似ています。プログラムの方が範囲や中心部分は小さいとは言え、この作業はたいてい、ポートフォリオ全体を管理するのと同じくらい複雑です。プログラム管理の主な目的は、範囲やビジネスの目的がよく似たプロジェクト群を管理することです。プロジェクトを開始するための主な作業はここで(またはポートフォリオを管理するの中で)行われ、その後プロジェクトがプログラム計画に沿っているかどうかをプログラム管理者が監視します。主な違いは、プログラムの進捗を監視するためのプログラムレビューが定期的に実施される点です。
ベンダー管理者は、図3に示すように、外部の受託業者を審査し、その後、契約を発注する責任があります。ポートフォリオ管理者とベンダー管理者は共に人事マネージャと協力して、異なる視点から発注した契約を監視します。ポートフォリオ内のプロジェクトやプログラムごとに、レベルの異なる要員配置が必要になります。
図3. 「契約を管理する」ワークフローの詳細
ポートフォリオ管理者は 契約 を管理し、ベンダー関係管理者はある1つのプロジェクトの 受託業者 を管理します。ポートフォリオ管理者は、さまざまなプログラムやプロジェクトにまたがって必要なリソースを管理することで、契約コストを下げ、開発チームや保守チームの全体としての生産性を上げ、結果として組織のビジネスの価値を向上することができます。要員に関する作業の契約管理を全社レベルで整理することは有効です。他のプロジェクトに影響を及ぼすプロジェクトもあれば、複数年にまたがるプロジェクトもあるからです。作業の重複を減らせば ( たとえば、法的や戦略的な窓口を一本化できるかもしれません ) 効率が上がるでしょうし、長期または大規模の契約の場合にはサービスベンダーは相当な割引もいとわないでしよう。
契約を発注した後、ポートフォリオ管理者とベンダー管理者は、プロジェクト管理者が要員などのリソースを取得する場合の進捗を監視しなければなりません。日々の作業に開発委託先をどう使うかの管理について、最終的に責任を持つのはプロジェクトマネージャですが、ポートフォリオ管理者には、契約先の組織との全体的な関係を管理する責任があります。ポートフォリオ管理者は、プログラム管理者やプロジェクト管理者と協力して、全社的な問題をすべて確実に処理・対処できるよう気を配らなければなりません。
組織の戦略的ビジネス目標の障害になる可能性のある問題を発見するには、全社レベルでリスクを管理する必要があります。プロジェクト管理者がプロジェクトリスクを管理する責任があるように、ポートフォリオ管理者はポートフォリオリスクを管理する責任があります。ポートフォリオリスクとは、エンタープライズレベルのリスクとも呼ばれるもので、文字通り成功裡の実現をつぶしてしまう可能性のある、プログラムあるいはプロジェクトレベルのさまざまな小さいリスクを、すべて集めたリスクです。
各プロジェクトのリスクは ( プロジェクトの視点で単独で見た場合には ) 低くても、ポートフォリオの視点から調査すると、すべてのプロジェクトが組み合わさって、組織にとって大きなリスクとなることがあります。たとえば、基幹業務システムを動かしている COBOL を専門とする組織であれば、社員の大部分が定年退職に近づいているかもしれません。また、会社のプロジェクトすべてが、新しい開発プラットフォームや技術をベースとして行われている場合はどうでしょうか。その技術やプラットフォームが市場で敗退すれば、プログラム全体が失敗するでしょう。ポートフォリオリスクを緩和するには、ポートフォリオ管理者は、プログラム管理者やプロジェクト管理者に協力して、個々のプロジェクトの成果物が会社の全体像とどう関わるかを見極める必要があります。
 |
本ページの原文 ( 改訂されている可能性あり ) : www.enterpriseunifiedprocess.com/essays/portfolioManagement.html Copyright 2004-2007 Scott W. Ambler
|