DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

ＰＭＯの成功事例、失敗事例を挙げてきましたが、そもそも何を持って成功と言い、何を持って失敗というかについてはきちんと触れていませんでした。
これまで挙げた事例については、「元々ＰＭＯ活動計画にあがっていたことが遂行できた」ことが成功したＰＭＯ、「遂行できなかった」ことが失敗したＰＭＯといった風に読み取れたかもしれません。
では本当にそうでしょうか？

「効果は何だ」と問われ・・・

このブログの最初の頃にも書いた通りＰＭＯは以下のような特徴があります。

• ＰＭＯは組織やプロジェクトの裏方である
• 何をしているか解らないと思われていることも

これと比較しＩＴ系の一般的なプロジェクト（注）の特徴は以下の通りです。

• システムを構築するために要件定義、設計、製造、試験を行う
• スコープが明確なので、していることが解りやすい

プロジェクトはシステム構築を完成が目標で、品質が基準以上であり、予算内であり、期限内であれば成功です。非常に解りやすいですよね。
ではＰＭＯの成功は何でしょうか？

（注）“ＩＴ系で言う一般的なプロジェクト”と限定したのは、ＰＭＢＯＫでは「プロジェクトとは、独自の製品、サービス、所産を想像するために実施される有期性の業務である」（ＰＭＢＯＫガイド第４版）と記載されており、ＰＭＯの活動に関してもプロジェクトに当てはまるためです。

以前私が参画していたＰＭＯは、追加開発が多発しているプロジェクトを支援する為のＰＭＯであり、ＰＭＯ構築の目的としては「度重なる追加開発でも品質の安定したシステムにしたい。自分たちの力で品質を安定させるために開発ベンダへの依存度をさげたい」というものでした。（第６回〜第９回のブログを参照）

目的を達成すべくＰＭＯ活動計画を作成し遂行していたのですが、ＰＭＯ構築から半年ほど経ったとき組織長より「ＰＭＯを設置して効果があったかを定量的に示してほしい」との指示がありました。
定量的？これはなかなかの難題です。

ＰＭＯの効果を定量化する

効果を考える前にこのＰＭＯの活動を振り返りましょう。（第７回、第９回より）
(1) 充実した要件定義書を作成するために、要件定義の標準を策定し導入する
(2) 初期開発以降放置されていた開発標準を実情に合った形でメンテナンスし使える開発標準にする
(3) プロジェクトマネジメント標準を策定する。特にリスク管理、コミュニケーション管理を重点的に実施する

これら活動は、“度重なる追加開発”に適用する施策であり、“品質の安定したシステム”が目標ですので、効果を測る方法を以下のように考えました。
（前提として１追加開発はサブプロジェクトで実施され、複数のサブプロジェクトが発足、２、３ヶ月毎にリリースするようなプロジェクトです。）

＜ＰＭＯ効果測定の考え方＞
サブプロジェクトの品質ではなく、追加開発を繰り返す中で品質の推移（品質が安定・向上しているか）やコストの推移（生産性が向上しているか）を評価する

実際の測定としては開発期間中の品質・コストとサービスイン後の商用品質を見ることにしました。以下は一例です。

＜開発期間中の品質＞

• ＰＭＯ活動(1)の要件定義標準の策定の効果を評価する方法
  設計工程で実施した設計レビューエラーから要件検討不足のエラーが減少していること。
  仕様変更発行数が減少していること。
• ＰＭＯ活動(2)の開発標準のメンテナンスの効果を評価する方法
  設計工程で実施した設計レビューエラーから標準化違反のエラーが減少していること。
  試験工程で発生したバグのうち、設計エラーが原因のバグが減少していること。
• ＰＭＯ活動(3)のプロジェクトマネジメント標準の策定の効果を評価する方法
  コスト＝開発生産性が向上していること。

＜サービスイン後の品質＞

• ＰＭＯ活動全般的な評価方法
  商用での障害が減少していること。

このように、チームの目的を考えればそのチームの評価方法が見えてきます。よってＰＭＯ評価と実際にシステムを構築しているプロジェクト（ここではサブプロジェクト）の評価とは違ってくるのです。
【参考URL】
【第６回】実際の現場を見てみよう　（１） 　
https://www.it-innovation.co.jp/2012/05/01-132145/
【第７回】実際の現場を見てみよう　（２） 　
https://www.it-innovation.co.jp/2012/05/22-133809/
【第8回】実際の現場を見てみよう　（３） 　
https://www.it-innovation.co.jp/2012/06/05-135352/
【第9回】実際の現場を見てみよう　（４） 　
https://www.it-innovation.co.jp/2012/06/19-142112/

＊＊＊＊＊
先日、チームメンバーで飲んでいると「ブログに書いていることは現在のプロジェクトのこと？？」と聞かれました。確かにどのプロジェクトでも１つや２つは似たようなことがありますからね。確かに今のことを書く方が記憶を辿らなくてよいので楽な面もあるのですが、私の心の中が筒抜けになっちゃうし・・・やっぱりリアルタイムはやめておきます。

＜　前回　｜　目次　｜　次回　＞