【IFRS】プロジェクト成功の切り札「PMO」活用法【第2回】
事例で見る、プロジェクト別PMO使いこなし
第1回で説明したようにPMOの役割はさまざまだ。その役割はプロジェクトの特性によって変わり、プロジェクト管理スキルにとどまらず、業務・システム開発の知識や調整・問題解決スキルが必要とされる。連載第2回では具体的な事例を基にユーザー企業にとってのPMO活用法を解説しよう。
前回は、企業におけるプロジェクト運営の難易度が高まる中、プロジェクトを成功に導くためのプロジェクトマネジメントオフィス(以下 PMO)の在り方について、プロジェクトの特性に応じて求められる役割、類型を中心に考察した。今回は、実際にPMOとして参画した事例に基づき、プロジェクトの置かれた状況に応じて、具体的にPMOがどのような役割を果たしたのか紹介したい。
事例1 システム開発プロジェクトPMO/テーマ別検討支援PMO 〜ユーザー主導のシステム開発プロジェクト(製造業A社)
一般的に企業におけるシステム開発は、システム部門が中心的な役割を担っている。システム部門は上流工程では業務ユーザー部門と連携し要件定義などを行い、下流工程では開発ベンダを活用してシステム開発を行っている。
A社では、システム部門は基幹系システムこそ担当しているが、各業務ユーザー部門が個別に活用しているシステムには介在せず、各業務ユーザー部門が直接開発ベンダに開発作業を委託している状況であった。
A社では、業務ユーザー部門のシステム開発に関する知識の乏しさに起因する以下の問題を認識していた。
- 開発ベンダの提案内容・見積もりを評価できず、開発規模・金額の妥当性判断ができない
- 要件定義からテストまでほぼ全てを開発ベンダ主導で行っており、必要以上の機能が存在する
- 開発ベンダの作業管理のやり方が分からず、開発ベンダからの報告を鵜呑みにせざるを得ない
アクセンチュアはシステム開発プロジェクトのPMOとして参画したが、A社の状況から、それぞれの課題に対して以下のような取り組みを提言し、実現までのサポートを実施した。
(1)コンペの導入による横並び評価の実施
システムの刷新に当たり、既存の開発ベンダに継続して発注するのではなく、複数の開発ベンダによるコンペ形式とした。それにより複数の開発ベンダの提案内容・見積もり結果を横並びで比較することで、妥当性評価を可能とした。
その際、提案内容・見積もり結果を横並び評価するために、複数の評価観点を用い、採点方式による評価テンプレートを事前に用意することで、評価経験の少ないA社でも開発ベンダの選定を行えるようにした。
結果として、既存の開発ベンダが落札したが以前に比べ3割程度安い金額での落札となった。
(2)テーマ別検討支援PMOによる業務ユーザー部門主導での業務要件定義のサポート
今まではA社側からは大まかな要望を出すのみで、要件定義作業は開発ベンダが行っていたが、業務要件定義までをA社主体で行い、システム要件定義以降を開発ベンダに委託するよう作業範囲の見直しを行うことで、A社の望む要件が必要十分にシステムに反映されることを目指した。
その際、要件定義作業の経験がないA社単独では作業が困難であるため、要件定義工程開始時点で通常のPMO管理業務とは別途テーマ別検討支援PMOを組織した。具体的な支援内容としては、直接的な作業支援だけでなく、要件定義における作業手順を整理し継続的に活用可能なガイドラインを策定。さらに業務ユーザー部門のメンバーに対し要件定義の知識・スキルを定着化させるためのトレーニングを実施した。
(3)管理標準および品質標準策定による開発ベンダ管理の高度化
開発ベンダの進捗・品質状況を客観的に評価できるようにするため、管理メトリクス(指標)を定義し、定性的な報告だけでなくメトリクスに基づいた定量的な報告を開発ベンダに義務付けた。
加えて、各工程における開始/終了基準を定めたチェックリストを開発ベンダに展開し、開発ベンダによるチェック結果をA社側でも再度確認することで、同一のクライテリア(評価基準)に基づいた評価を双方で行うこととした。開発ベンダは内部でクライテリアを保有しているため、こちらが提示したクライテリアに準拠することに当初難色を示したが、お互いのクライテリアを持ち寄り、すり合わせを行うことで、最終的には双方が納得するクライテリアを作成することができた。
これら取り組みの結果、プロジェクトが問題なくカットオーバを迎えただけでなく、今後業務ユーザー部門が主導となってシステム開発を進めていくためのノウハウ・スキルを蓄積することができた。
事例2 統合PMO/システム開発プロジェクトPMO 〜全社的システム刷新プロジェクト(ハイテク業B社)
基幹システムおよび複数の周辺システムを一斉に更改する全社的なプロジェクトにおいて、アクセンチュアは業務ユーザー部門、システム部門におけるPMOおよび、双方を束ねる統括PMOとして参画した。システムごとにプロジェクトが立ち上がり、開発ベンダが異なるマルチベンダ開発であるため、いかに業務ユーザー部門を含めた部門間の調整をスムーズに行い、プロジェクト間で足並みを揃えた開発を推進していくかが運営上の大きな課題であった。このような状況から、大規模プロジェクトの円滑な推進を目的に主に以下の取り組みを実施した。
(1)業務ユーザー・システム間の決定・調整スキームの整理
** **経営層、プロジェクト管理層、現場リーダー層のそれぞれのレイヤーで、業務ユーザー部門とシステム部門の意見調整を行う会議体を設置、運営した。これによって要件変更や研修運営などの検討事項を随時調整するとともに、継続的にコミュニケーションを図ることが可能になり、各部門が一体となってプロジェクトを推進する体制を整えた。
部門間で解決すべき問題が突発的に発生した際にも、情報共有および調整する会議体が用意されていたことにより、大きな混乱を招くことなく対応できた。
(2)各種標準の策定
各開発ベンダは基本的にそれぞれの方法論に沿って開発しつつ、B社と連携する進捗、課題、品質、コミュニケーションなどの各種管理標準はPMO側で統一的に標準を作成し、各開発ベンダは標準に沿った運用を行うこととした。
しかし各開発ベンダは独自の標準を保有しており、統一することにより管理方法が変わることに抵抗したため、B社と開発ベンダおよび開発ベンダ間で発生する手続きのみを統一し、開発ベンダ内に閉じる管理は今まで通り、個別の標準に従うこととすることで、開発ベンダの理解を得た。
この対応で開発ベンダごとに管理方法を変えることが不要となり、管理負荷を最小限に抑えることができた。
(3)各プロジェクトへの直接モニタリング
アクセンチュアは当初複数プロジェクトを統括するPMOとして参画し、(2)のような標準策定を推進してきたが、各プロジェクト担当者のスキルが一定ではなく、情報の深度、網羅性の観点で問題があり、経営層が各プロジェクトの状況を十分に把握できないという状況が発生していた。そのため、各プロジェクトに対して支援メンバーとして参画し、作業状況のモニタリング、作業計画・報告資料の作成支援などプロジェクト管理作業を遂行し、随時横串で連携を図ることで、整合性の取れたプロジェクト管理を実現した。
しかし、統合PMOから支援メンバーが入ることに対しては当初、拒否反応があった。各プロジェクトからは監視役として捉えられたためだ。だが、課題の洗い出しと解決に向けた対応など地道な支援活動を通じてプロジェクトからの信頼を得ることができ、当初の目的を達成することができた。
これら取り組みの結果、適切なタイミングで適切な情報が届けられるようになったとの経営層からの評価を得られた。
事例3 システム開発プロジェクトPMO 〜グローバル展開プロジェクト(製造業C社)
C社はこれまで各国の拠点に独自のシステムを構築し、保守・運用も個別に行ってきた。そこで、新システムに移行するに当たり、システムの共通化・標準化を図ることで、開発・運用のコストダウンと、効率化を目指した。
プロジェクトでは、管理対象となる拠点が各国にまたがるため、意思決定の伝達・各拠点の情報集約といったコミュニケーションをいかに円滑に行うかが大きな課題であった。
(1)情報共有基盤の導入
文書(成果物、議事録など)の共有の他、進捗、課題、問合せ状況の一括管理など、共有各拠点の情報を一元的に管理できる情報共有基盤を構築した。これにより決定事項などの展開を容易にするとともに、各拠点の状況をタイムリーに捉えることを目指した。
既存グループウェアを利用することで、情報共有基盤の構築自体は順調に進んだが、実際に使用する段階では、各拠点において使用方法などの理解が不十分で、思うように定着化が進まなかった。そのため、担当者を各拠点に1、2人派遣し、2週間程度の期間で現地メンバーに対するトレーニングを実施した。内容は、情報共有基盤活用のメリットや操作方法、現地担当者に対するOJT実施などだった。直接的なコミュニケーションを図ることで、当初の目的通り、タイムリーに情報連携が進むことになった。
(2)共通的なマイルストーンの管理
各拠点のマスタースケジュールは個別に作成されており、プロジェクトが進むにつれ、システム間インタフェースの確定や試験開始のタイミングなど、拠点間で同期を取るべきスケジュール上の重要ポイントにズレが生じることが懸念された。
そのため、重要ポイントをマイルストーンとしてマスタースケジュール上に明記し、それぞれのマイルストーンに向けた進捗状況を会議の場で定期的に確認することで、統合的なプロジェクト管理を可能とし、一部の遅延などによって発生する他システムへの影響を見極め、早期の対策検討を可能とした。
また各拠点が、自らのマスタースケジュールを見直す際には、マイルストーンから他拠点への影響を調査することで、スケジュールの整合性を担保できるようになった。
この結果、今回構築した情報共有基盤は、プロジェクト終了後も定常的に運用され、各拠点とのコミュニケーションの改善に大きな役割を果たすこととなった。
弊社の事例からも、PMOに求められる役割はさまざまであり、プロジェクト管理スキルにとどまらず、業務・システム開発の知識や調整・問題解決スキルが必要とされることが分かる。また、業務ユーザー部門が主導する場合や、システム部門でも経験することの少ない合併・統合に関連する大規模プロジェクトの場合などは、企業側もPMOにどのような役割を果たしてもらうか定義することも困難な状況が予想される。PMOはプロジェクトを取り巻く状況を分析し、プロジェクトの成功に向け自らの役割を定義できる能力が求められることになるだろう。
プロジェクトを成功に導くためには具体的にどのようなポイントに注意をしてプロジェクトを遂行していけばいいのだろうか。次回以降、経営層、業務ユーザーの視点を踏まえ、プロジェクトを推進するためのポイントについて考えたい。
福島 毅(ふくしま たけし)
アクセンチュア株式会社
テクノロジー コンサルティング本部 金融サービスSIグループ プロジェクト・マネジメント・プロフェッショナル アソシエイト・プリンシパル
1999年アクセンチュア入社。金融機関におけるシステム開発およびプロジェクト管理のプロジェクトに参画経験多数。大規模システム開発の管理スキーム検討、品質標準の策定、PMO支援に従事。プロジェクト管理スキーム立ち上げ、大規模システム開発のPMOを強みとしている。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Excel至上主義」の終わらせ方 丸2日の手作業地獄から情シスと現場を救うには
-
2
取手市がVDIと決別した理由 更改費用「4倍超」を約1.7倍に圧縮
-
3
「Microsoft 365のセキュリティ運用」に関するアンケート
-
4
急増する「AIはこう言ってる」マン 判断を狂わせる「AI忖度」を防ぐには?
-
5
221人調査で分かった「情シス最大のストレス」は?
-
6
「Salesforceのテスト自動化ツール」に関するアンケート
-
7
「データストレージの活用方法」に関するアンケート
-
8
「AI時代の統合基盤・エンタープライズAI管理」に関するアンケート
-
9
AIで人を減らした企業がもう心変わり 「AIブーメラン現象」の実態
-
10
自宅のWi-Fiが「遅い」「途切れる」本当の原因は? Dellが推奨する鉄則
ホワイトペーパーランキング PR
-
1
年収2000万「クラウドセキュリティのプロ」になれる資格とは
-
2
セキュリティソフトをすり抜ける標的型攻撃メール、不審メールの見破り方とは?
-
3
Windows Updateの通信集中で回線が逼迫、ネットワーク刷新事例に学ぶ解決策
-
4
財務を戦略的組織へ進化させるAI活用術、4つの主要な障壁と解消方法
-
5
「NAS」「SAN」「DAS」は何が違う? いまさら聞けないストレージの基礎
-
6
“あのファイル転送”で暗躍するノーウェアランサム
-
7
標的型攻撃メールを見破るには? サンプル文面を例に傾向を解説
-
8
商用利用の安全性を確保し大量のコンテンツを高速で生成する、AI活用の秘訣
-
9
マンガで解説、1日で生成AI環境を構築できるワークショップの中身とは?
-
10
Dark AIが台頭する時代の新発想、「より高度なAIで対抗する」具体的方法とは?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー