「プロジェクト管理」を管理するために：The Rational Edge （25）（4/5 ページ）

[Michael F. Hanford（IBM），＠IT]

◇ プログラムのインフラ

　インフラは、ソフトウェア開発でサービスやサポートを提供すべく組織がまとめて統合する役割、ツール、および業務の描写に有用な用語だ。プログラムの成功に必要なインフラを理解するために、最初にプログラム・マネジメント・オフィス（PMO）を構成する管理と運営の役目、ツール、そして業務を探ってみたい。それから、技術環境とツールの要件を考えるのだ。

○ 運営インフラ

　もちろん、さまざまな形式を取り得るPMOを、単純に設置し、運営するだけでも、プログラムをプロジェクトから差別化することができる。本稿では主に、1つのプログラムをサポートするPMO（プログラム作業の終了と同時に解散）に重点を置く。しかし、一部のIT部門ではEnterprise PMOが恒久的で、複数の（そして変化を続ける）プログラムにサービスを提供することに留意する必要がある。

PMOの役割

• プログラム部門の管理
• 資源のコーディネート
• 予算の管理と調達
• リスク評価
• 作業成果物のトラッキングと検査
• 設備管理
• 契約管理
• 技術サポート連絡係
• トレーニングのコーディネート
• 方法論とプロセスのサポート
• 問題点管理
• コミュニケーション管理
• 現状報告管理

　PMOは、プログラムマネージャ／ディレクターと、プログラムの参加者全員の運営および管理をサポートする。また、特定分野の専門知識を持つ専門スタッフを提供する。

　PMOには多くの分野や作業をカバーする役割が多数ある（［PMOの役割］参照）。プログラムマネージャ／ディレクター、スタッフメンバー、幹部専門家グループの支援に加え、プログラムに絶対不可欠な役割も果たしている。大規模で複雑なプログラムでは、経営者にプログラムの進展を知らせておくべくPMOが適切な作業プロセス、規制、報告機能の確立と保守を支援する。また、各種作業の定義、立案、そして遂行も行う。

　例として、設備管理というPMOの役割の1つを検証し、これがプログラムの成功にどのように寄与しているのか見てみたい。この役割の担当者は、プログラム固有もしくは常設のPMOに必要なすべての設備を特定し、計画、および導入する必要がある。そのためには、設備マネージャには次のようなことが必要となる。

• PMOマネージャやプログラムマネージャと協力し、設備に含める必要のあるものを明らかにし、設備のニーズの定義と優先順位付けをする
• 設備計画を立て、その承認を得る
• 設備計画の実行と、それに伴う搬入、建設、設置を管理する
• インフラや技術環境のコーディネーターと密接に協力する

　ではここで、この役割のプロジェクトにおける価値と、プログラムにおけるそれとを比較してみたい。構築チームに最高で7人の社員が参加する単独の小規模プロジェクトでは、この役割の付加価値はあまりない。チームのメンバーは、自分の部屋や机を与えられ、予約システムを使えば会議室も予約できる。

　しかし、立ち上げに4週間もかかるプログラムがあるとする。この間、200人のコンサルタントがオフィスキャンパス内に机を置き、260人のITスタッフがプログラム担当として配備され、3人のプロジェクトマネージャが効率化のために各自のプロジェクトチームを同じ場所に配置するよう迫る。また、専用のコピー機が12台、会議室用に5台、プログラム室など、ほかにも必要なものが出てくる。コンサルタントには200人合計で1日当たり36万ドルが掛かる。従って、これらの設備の稼働が5日遅れてコンサルタントが現場で作業できないことになると、どれだけの損失が出るかは簡単に計算できるだろう。作業を遂行するための適切なスペースとツールを用意する責任を誰かが「負う」必要があることは明らかだ。

　実のところ、PMOの作業について書き続けると本稿のスペースがなくなってしまうし、この役職が役割のすべてでもない。いまのところは、PMOが提供するインフラがプログラムに参加するすべてのプロジェクトチームの生産性を実現しているのだとしておく。

○ 技術環境とツール

　プログラムのインフラには、ハードウェア（ストレージや通信用のデスクトップおよびネットワーク機器）と、デスクトップソフトウェアと開発ツールを搭載した共有プラットフォーム、モデリングソフトウェア、プランニングツール、コミュニケーションツール（電子メール、インターネットブラウザ、仮想会議／コラボレーションプログラム、通信プログラム）、そしてドキュメントの保存と複製を行うソフトウェアを含む各種ソフトウェアの両方が含まれる。

　個々のプロジェクト、特にその立ち上げ作業では、それができることとできないことを理解すべく新しいツールやハードウェアが持ち込まれる場合がある。ハードウェアやソフトウェアの取得、インストール、「チューニング」のために、プロジェクトマネージャがテクニカルサポートやインフラの機能に関与することもある。通常、ここではITスタッフもインストレーションも少数に限られる。定期的な変更や開発環境への追加作業は多数のITスタッフに影響するが、これらは一般的には別々のプロジェクトとして定義および管理される。

　対照的に、技術的な作業計画では、さまざまな場所（社内および社外）から集まったさまざまな技術バックグラウンドを持つ多数のスタッフが関与するのが普通だ。マネージャがプログラムを構成するプロジェクトを特定し、スタッフを配置するときは、各プロジェクトの技術環境とツールも特定、取得、インストールしなくてはならない。これらが集まってプログラムの技術インフラが構成される。このような作業としては、新しいリモート開発サイトの設置や、合併後の2社の技術統合などが考えられる。

　このインフラ作業は社内のプログラムプロジェクト（クライアントにコンポーネントや結果を提供する社外プロジェクトではない）として扱うべきだ。技術環境の構築では、マネージャが、入念に定義され、迅速で、簡潔なライフサイクルを計画すべきだ。この取り組みには、ニーズと要件の定義、範囲の設定、インストール、テスト、そして全役職の設置が含まれる。プログラムスタッフの一部にとって初めて使うツールがある場合は、短期トレーニングを規定する必要があるかもしれない。

　マネージャは、プログラムの範囲外にあるインフラのハードウェアやツールの利用方法も考えなければならない場合があるかもしれない。現在の企業のIT構造とは異なる技術の選択を余儀なくされると感じた場合は、これらの技術とともに構築された新しいソフトウェア・アプリケーションのサポートおよび保守には、新たな担当者、ソフトウェア、そしてトレーニングが必要になるかもしれない。マネージャは、実際に購入に踏み切る前に、自分たちが既存のITアーキテクチャや資源を踏まえて選択するプログラム技術の潜在的な影響（そしておそらくは将来的な方向性も）を常に慎重に評価すべきだ。