ITプロジェクトを見える化する：The Rational Edge（4/4 ページ）

[Anirban Dutta，IBM ITポートフォリオ管理プロフェッショナル]

PPMをインプリメントする準備は？

　ベンダを選択したら、特定のPPMソリューションをインプリメントする前に、IT部門や会社内におけるPPMの全体的完成度の現状把握に向けて準備状況を評価する必要がある。ここではうやむやにすることはせず、いくつかの重要な質問に組織として答えていく必要がある。これらの質問には、PPMのインプリメンテーションサービス製品を評価する前に取り組むのが最適だ。

・幹部の囲い込み

　ポートフォリオ管理プロセスを進めるに当たり、幹部の支援は得られるだろうか？ これのインプリメントに適した予算、人材、および時間は確保できるだろうか？

・プロジェクト／プロセス管理

　現在、プロジェクトやポートフォリオ管理プロセスはあるだろうか？ どの程度の頻度と精度でドキュメント化を行っているだろうか？ このツールは、既存のプロジェクト管理インフラに適しているだろうか？ 自分の戦略目的とプロジェクトの成果物はどのように結び付けるのだろうか？

・パフォーマンスベンチマーク

　われわれの新しいツールから想定できる現実的かつ測定可能なパフォーマンス基準は確立できただろうか？

・組織構造

　自分のITおよびビジネススタッフはどの程度柔軟に対応できるか？ 既存のプロセスは変えられるだろうか？

・資源の信頼性

　自分の資源（部署、事業部、etc……）はPPMインフラに適したものを提供するだろうか？ 資源や資産などの正確な数字は把握しているか？

・PPMスタッフ

　PPMベンダの選択、成功のための基準確立、PPMインプリメンテーションが予定どおり進まなかった場合の代替案の実行、ベンダの成果物やプロセスの監視など、組織内におけるPPMの進展プロセス全体を管理できるPPM専門家は社内外にいるだろうか？

・技術

　同僚にはそのソフトウェアを最大限活用するだけの技術知識があるだろうか？ ソリューションのインプリメントに必須の技術基盤のインプリメントに必要なネットワーク、ハードウェア、ソフトウェアなどはそろっているだろうか？

　これらの質問に対する回答が、特定のビジネスに適したサービスを作り出せる適切なベンダを発見し、選択するための堅牢な基盤を作ることになる。

PPMソリューションのインプリメンテーションを成功させるための8つの手順

　PPMの準備状況評価を行った結果、PPMソリューションの導入に問題がないようであれば、インプリメンテーションを成功させるために以下の手順を踏むことを推奨する。

1）基盤

　先に説明したように、PPMツールを導入する前には必ず自分の既存の環境（システムやプロセスなど）を評価することが重要だ。この評価は、ベンダがクライアントのニーズを詳しく理解するのに役立つ。これにより、いまどのような状況にあり、現実的に何ができるのかが分かる。ベンダからは、上司を囲い込むための最優良事例のアドバイスや、ビジネスを正当化するための情報を得ることが期待できる。どのアドバイスを追求するかはそれから決めればよい。ベンダからは、ツール導入までの時間、導入活動、成果物、トレーニング、自分の環境にそのツールをうまく導入するために必要なリソースを概説するロードマップの提供があるはずだ。

2）導入プラン

　チームはベンダと協力してチームのビジョン、意図、役割、リソース、そしてコミュニケーションプランを定義しなくてはならない。役割分担が適切に定義されていないと、ソフトウェアを最大限に活用することが相当困難になる。そこで、導入スケジュールを立て、マイルストーンを一致させ、進ちょく状況判断基準を固定するのだ。

3）環境仕様ドキュメント

　ITの専門担当者とベンダチームのテクニカルスペシャリストを密接に協力させ、ツールのどこの部分にどのソフトウェアコンポーネントをインストールするのか決めさせる。ベンダには環境仕様レポートの作成を依頼する。

4）使用モデル

　ベンダチームのメンバーと協力し、自分のチームで特定した役割（幹部、PM、プログラマなど）ごとにツールの使用方法を定義する。密接に協力し、使用モデルの設計資料作成のためにプロセスと測定基準をデザインする。ここで作成した設計資料がコンフィギュレーション作業の基盤になる。

5）インストールと設定

　ベンダは環境仕様ドキュメントに沿ってPPMツールをインストールし、使用モデルドキュメントに沿ってこれを設定する。設定したツールの試作バージョンは必ず試し、ニーズが満たされているかどうか確認する。完全な導入を行う前にここで調整をしておく。

6）導入

　ベンダは導入の段階でトレーニング資料を提供する。導入時間の短縮には、実地研修や指導でベンダを活用する。

7）ツールの運用

　ベンダはシステム管理者やデータベース管理者と密接に協力し、ツール運用のロードマップや、保守手順、役割、責任分担を定義する。このロードマップは、管理／保守プランに組み入れておく。そのほか、経営陣とベンダで再度話し合いの機会を設け、導入結果、教訓、不足部分、および今後の方向性について協議する。

8）フォローアップ

　ベンダは、ツール利用開始後1カ月程度経過してからエンドユーザーのフォローを行い、パフォーマンスに関するフィードバックを取得する。このときが、これまで聞けなかった疑問を解消するチャンスでもある。

---

　今日の多くの企業は、IT投資の妥当性とROIを最適化するに当たり、ITポートフォリオ管理戦略を頼みの綱としている。しかし、プロジェクトポートフォリオ管理（PPM）ソリューションをインプリメントしてからユーザーエクスペリエンスが最適でないことに気付き、ソリューションが期待された結果を出せず、業務上のメリットも得られていないと感じるケースは頻繁にある。筆者は、本稿で概説したPPMソリューションに対するアプローチ方法が、PPMのニーズを評価し、PPMへの投資を最大限に活用できるよう企業を支援するシステムの良識的インプリメント方法であると信じている。

---

本記事は「The Rational Edge」に掲載された「A guide to successful PPM implementation」をアットマーク・アイティが翻訳したものです。

---

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

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）