メディア

開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）：The Rational Edge（2/2 ページ）

» 2007年10月02日 12時00分公開

[Scott W. Ambler, Per Kroll，IBM]

前のページへ 1|2 　　　　　　

組織と会議（ビジネス主導のプロジェクトパイプラインおよびシナリオ主導開発と呼ばれる組織とミーティング）

　このカテゴリの手法は、適切な関係者と一緒に適切なレベルで重点を置くための、適切な組織構造と正式な報告メカニズムを定義するための指標を提供する。次のような手法がある。

ビジネス主導のプロジェクトパイプライン
シナリオ主導開発

ビジネス主導のプロジェクトパイプライン

　ITプロジェクトのニーズは常に手元のリソースを上回るため、準備中の潜在的プロジェクトの優先順位付けと、選択されたプロジェクトを戦略に沿わせるための最適化を余儀なくされる。優れたガバナンスソリューションは、開発に対する投資の事業価値を最大限に活用し、事業目標や目的との戦略的な整合性確保を保証しなくてはならず、これを実現するためのメカニズムが必要になる。これは、スコアカードなどの各種ポートフォリオ管理戦略を活用することにより効果的に行うことができる。そこでは、戦略的な整合性と事業価値を反映して定義された一連のパラメータと比較して各プロジェクトを評価する。

　スコアカードは事業価値モデルであり、どのモデルにも限界があることに注意したい。つまり、スコアの低いプロジェクトをスコアの高いプロジェクトより優先させ、手作業で強制的にルールを無視しなくてはならない場合もある。だがこのような場合は、スコアカードが戦略や事業価値に関する話し合いにつながり、まれにモデルに不適切な部分があったときの理由も明らかになる。

◎ メリット

　事業価値別プロジェクトパイプライン管理には次のようなメリットがある。

　事業価値中心の収束。パイプライン管理は、ビジネス戦略や、最大の事業価値につながるパラメータをめぐって組織が合意せざるを得なくなる。例えば、「IT部門は新しいビジネスチャンスのサポートに優先順位を付け、進行中のビジネスプロセスのコスト効率を改善するか、それとももっと迅速な組織の成長を可能にすべきだろうか？」という質問を考えた場合は、戦略的な整合性と事業価値に重点を置くプロジェクトの資金調達に関する話し合いがどうしても必要になる。

　ROIの向上。リスク、ROV （価値収益率）、および戦略との関連性のバランスが最もよく取れたプロジェクトが選択され、ROIが全体的に向上する。スコアカードは、IT部門全体が戦略との関連を深め、事業価値を最大限に活用するための強力なコミュニケーションおよび動機付けのメカニズムにもなる。プロジェクトの資金を調達したければ、それがビジネスにとって最も重要なものと深い関係にあることを保証する必要がある。

　透過性の向上。多くの組織では、資金調達判断の仕組みは謎になっている。事業価値によるパイプライン管理は、オープンで透過的な形で行うことができ、それが可視性を向上させ、信頼を築く。

◎ トレードオフ

　事業価値別プロジェクトパイプライン管理で考慮すべきトレードオフには次のようなものがある。

　戦略と価値の明瞭な表現。パイプライン管理では、投資誘因の定義が必要になる。これは難しいし、戦略の「あるべき姿」と「第六感」の両方への対応を余儀なくされる。

　コントロールの放棄。プロセスがさらに客観的かつオープンになり、各プロジェクトがその事業価値を明確にしなくてはならなくなる。これは誰もが魅力を感じるものではないかもしれない。現状に満足している人々には特にそうだろう。

　頻度。パイプライン管理はプロジェクトに遅延が発生しないよう、毎週もしくは毎月定期的に行う必要がある。そして、これを効果的に進めるには膨大な投資が必要となる。

◎ アンチパターン

　プロジェクトパイプライン管理には次のようなアンチパターンがある。

　主観的プロジェクトスコア。プロジェクトの選択が主観的になってプロジェクトごとに異なったり、判断の経緯をたどることも弁護することもできないと、十分に機能しないスコアリングプロセスとなってしまう（あまりに主観的過ぎてスコアカードが使いにくいのかもしれないし、適切な監視もなく、透過性も持たせずにスコアリングを行ってしまったのかもしれない）。

　ひずんだスコアカード。机上では良くても、実際には誤ったプロジェクトを優先するスコアカードは多い。これは、「お気に入りのプロジェクト」が一番になるよう問題を強調し過ぎたり、単純に自分が望む政略的な回答を得るためにプロジェクトのスコアリングでミスを犯すことにより発生する。一般的に、スコアカードは適切な結果が出るまで調整する必要がある。

　ポートフォリオの負担。パイプライン管理プロセスが非常に官僚的だったり、プロジェクト始動の大幅な遅延につながるような場合は、スコアリングの値が欠点に結び付くことはないかもしれない。

◎ 推奨デフォルト

　スコアリングは、重点を置くスコアカードのパラメータを5つ未満に抑え、厳格な尺度とするのではなく、優先順位付けを議論する会議で役立つものとして利用することを推奨する。

シナリオ主導開発

　コントロールプロジェクトを通じた段階プログラム配布手法のセクションでは、ますます複雑化するITシステムが包括的なビジネスプロセスには必要であること、そして、プロジェクトは小さい方が大きいプロジェクトより効率的かつ成功率が高いことを説明した。図4に示されるように、ITシステムは小さい部品に分割できる1つのシステムであり、各部品はそれぞれが単体のシステムとして開発されていると考えることができる。このコンフィギュレーションは「システムのシステム」と呼ばれ、各パーツは、それぞれ別のプロジェクトによって開発された独立アプリケーションとなっている。

　各部品を理解せずに全体を定義することはできないし、全体を理解せずに各部品を詳細に定義することもできない。部品がソリューション全体にどのような影響を与えるのか理解できないことで、相性の悪い部品の構築が行き詰まってしまうのがリスクだ。従って、全体と部品を密接な状態に保つテクニックの応用が必要になる。これは、すべてのレベルでユースケースを適用することで行う。

要件は、ユースケースシナリオを通じて（システム全体のユースケースを達成する部品のコラボレーション方法を示すことで）定義およびやりとりされる
アーキテクチャとインターフェイスも同じような方法で定義およびやりとりされる
ユースケースシナリオは、システムレベルの統合やテストシナリオも推進し、部品が必ずシステム全体にとって重要な包括的ユースケースを提供するようになる。

図4 システムのシステムでは、それぞれの部品が別のプロジェクトで開発された独立アプリケーションとなっている（クリックすると拡大）

　IBM Software Groupでは、これらのテクニックをかなりうまく応用している。数百のチームが数百種類のアプリケーションを開発し、顧客はわれわれのいくつもの製品を併用している。われわれは数年前から、パーツのより良い統合を推進する全体ソリューション向けの包括的ビジネスシナリオ（グリーンスレッドと呼ばれる場合もある）にますます重点を置くようになってきた。そしてわれわれは、これが顧客に最大の価値を提供できるようなリソースの優先付けを可能にしてくれることに気付いたのだ。

◎ メリット

　システムのシステムという考え方によるシナリオ主導開発には以下のように多くのメリットがある。

　ビジネス機能提供重視。これにより、部品が組織にどのような事業価値を提供するかに各プロジェクトが重点を置くようになる。

　多くの可動部品間の統合改善。異なるアプリケーションを開発するプロジェクトがアプリケーション間の統合向上に重点を置くようになる。事業価値は、個々の部品自体ではなく、包括的なビジネスシナリオを通じて提供されるため、統合を重視することは極めて重要だ。

　コントロールメカニズムの提供。コントロールメカニズムは、チームによる事業価値提供を保証する。さらに、このようなシナリオ主導のアプローチは、機能のギャップ排除に役立ち、矛盾点や進展のない部分の特定を可能にする。

◎ トレードオフ

　シナリオ主導開発には次のような2つの重要なトレードオフがある。

　ビジネスと技術のビジョン。この手法にはビジネスと技術に対する全体的なビジョンが必要だが、すべての組織がそれを提供できるだけのレベルに達しているわけではない。

　エンタープライズレベルのコーディネーション。この手法は、異なる部品の開発をコーディネートする能力がベースになっているが、すべての組織にここまで大規模なコーディネートの能力があるわけではない。

◎ アンチパターン

　シナリオ主導開発には次のようなアンチパターンがある。

　非公式のビジョン。ビジネスシナリオは、人の頭の中ではあいまいにしかとらえられておらず、共有されることも、文書化されることもない。包括的ビジネスシナリオは、決して明確になることはなく、決して配布されることもない。

　IT主導のビジネス。ITの役割はビジネスのサポートだが、このアンチパターンではその逆が発生する。これは、ビジネスプロセスが1つも定義されておらず、それがIT機能の拡張にも利用されていない場合に起こる。

　浮世離れしたビジネスモデル。ビジネスプロセスが開発されても、ITプロジェクトによってこれが効果的なIT機能の拡張に活用されていない。

　自己中心的プロジェクト。各プロジェクトは事業価値の提供に向け最善を尽くしているが、包括的ビジネスプロセスの明瞭な表現も、プロジェクト間のコーディネーションもない。

◎ 推奨デフォルト

　重要なビジネスプロセスを把握し、これらを使ってIT投資の推進とコーディネーションを行う。

　パートIIでは、「プロセス」（反復開発、「リスクベースのマイルストーン」、および「Continuous Improvement」を含む）のほか、測定値や監視手法もカバーする。ご期待いただきたい。

本記事は「The Rational Edge」に掲載された「Best practices for lean development governance」をアットマーク・アイティが翻訳したものです。

著者プロフィール

Scott W. Ambler,

Practice Leader, Agile Development,

Rational Methods Group, IBM

Per Kroll

Manager of Methods, IBM Rational, IBM

「The Rational Edge」バックナンバー