プロジェクトマネジメントの薦め～ITプロジェクトを成功に導く～　最終回：プロジェクトマネジメント・オフィス《後編》｜建設情報クリップ

 

 

①現状の分析
PMOの活動は、自組織のプロジェクトマネジメントの問題を把握することから始まります。
混乱したプロジェクトがあれば、その原因を分析します。
また、組織内のプロジェクトデータを収集して統計的に分析し傾向を把握することも必要です。
プロジェクトデータの収集には、PMOの監視対象となるプロジェクトの決め方やデータの収集方法
（収集するデータの種類、単位、タイミングなど）も含みます。
定期的に動向調査や先行している企業とのベンチマークを行うことも考慮します。
このような活動から、取り組むべきプロジェクトマネジメント上の課題を特定します。
 
②プロジェクトマネジメント施策の立案
現状分析の結果に基づいて、期あるいは年度単位で組織としてのプロジェクトマネジメント施策を立案します。
PMOを立ち上げた初期段階で、「プロジェクトの成功」とは何かを議論しておくことが必要です。
QCDの視点から、稼働後、プロジェクトに起因する大きな不具合がないこと、予算や納期を守れていること、
利用者満足度の視点から利用者からの評価が一定基準を超えていることなどを設定しておきます。
これを基にプロジェクトの成功率などの指標を決めておくと、施策の効果が測りやすくなります。
 
 

①プロジェクト環境の整備
プロジェクトは有期の活動ですから、立上げ時にはプロジェクトで仕事ができる環境を作り、
完了時にはその環境を撤収しなければなりません。
どんなものを準備しなければならないでしょうか。
大きなプロジェクトになると、まず考えなければならないのがプロジェクトルームです。
コロケーション（Co-location）と呼びますが、プロジェクトメンバーが全員同じ場所で仕事ができれば効率はあがります。
プロジェクトルームが決まれば、プロジェクトメンバーが使うPCやメールなどのコミュニケーション環境も揃えなければなりません。
プロジェクトで利用する開発支援ツールやプロジェクト管理ツールなどがあればセットアップが必要です。
また、プロジェクトの運営には会議室やプロジェクト用のサーバなども考慮しなければなりません。
これらの環境を整えるには、手配のための事務手続きも必要ですから、かなり負荷がかかります。
プロジェクト側で手配するケースがほとんどでしょうが、こうした作業をPMOがサポートして、
大事な立上げ段階でプロジェクトマネージャが計画作成に集中できるようにします。
 
②プロジェクトマネージャへの直接支援
PMOが、プロジェクトマネージャの指導をしたり、メンタリングを行います。
例えば、プロジェクトマネージャがステークホルダーとの関係で悩んでいれば、相談にのり、アドバイスをします。
PMOメンバーにも経験とスキルが要求されますが、
プロジェクトマネージャは、孤独でストレスのかかる仕事ですので大きな効果があります。
 
③プロジェクト状況の継続的な把握と評価
PMOは、第三者として冷静な目でプロジェクトの状況を見極めます。
もっと早く手を打っていれば、こんなに傷口は広がらなかったのにというケースは往々にしてあります。
早めに是正処置を促すことが大切です。
プロジェクトが混乱する予兆を検知するには、プロジェクトステータスレビューなどを開催して、
有識者の知恵を借りることも有効です。
こうした会議のセットアップもこの活動の中に含みます。
会議などであがった懸案事項については、解決状況を追跡していきます。
 
④レポーティング
把握したプロジェクト状況をプロジェクトオーナーや経営幹部にPMOの見解を加えて報告します。
レポートは、週次や月次で定期的に発行する場合とプロジェクトステータスレビューを行ったタイミングで随時発行する場合があります。
受け取った側は、リソース配分を決めたり、経営判断をするときの材料にします。
また、プロジェクトへのフィードバックを行います。
 
⑤教訓の整備
プロジェクトチームは、目的を達成して完了すれば、そこで解散します。
ここでせっかく得られたノウハウが散逸してしまうことを防止しなければなりません。
プロジェクトのノウハウは、組織にとって大事な資産です。
特に混乱したプロジェクトの完了時の振り返りには、PMOも参加し、プロジェクトの記録を整理し教訓をまとめます。
ノウハウは、PMOが蓄積、管理して後続のプロジェクトでも使えるようにして、同じ失敗を防止します。
 
 

①PM制度の構築
ここでいうPM制度は、プロジェクトマネジメントに関して組織として定めた規則やルールです。
プロジェクトに義務付ける会議体やドキュメントを決めます。
プロジェクトが開催する会議は多いと思いますが、PM制度で定める会議は、処理方式などの技術的な課題を検討するのではなく、
対象とするのは、スコープやスケジュール、コスト、体制、調達、リスクなどです。
プロジェクトをこのまま進めてよいのかどうか、マネジメント上の意思決定をするチェックポイントとなります。
こうした会議は、「フェーズゲート」、「ゲート会議」、「関所」などと呼ばれることもあります。
図-2にフェーズゲートのイメージを示しました。
留意して欲しいのは、フェーズゲートは、単にフェーズとフェーズの間にある会議ではなく、
ゲートに至るまでのプロセスも含めてチェックしてGo／No Goを判断する会議であることです。
 

 
また、プロジェクトの成否に影響するドキュメントの作成を規則化します。
スコープ定義書やプロジェクト計画書、プロジェクトステータス報告書、完了報告書などです。
こうしたドキュメントは、フェーズゲートの入力にもなります。
ただし、すべてのプロジェクトにフェーズゲートやドキュメントの作成を義務付けるわけではありません。
組織として監視しなければならないのは、
規模が大きい、納期などの制約条件が厳しい、新しい技術を使うなど、混乱するリスクの高いプロジェクトです。
PM制度にのせて監視するプロジェクトの基準も合わせて作ります。
 
②プロジェクトマネージャの育成
プロジェクトマネージャを計画的に育成することもPMOの重要な活動です。
図-3にプロジェクトマネージャを育成するサイクルを示しました。
PMOは、プロジェクトマネージャを任命する仕組み、評価する仕組み、認定する仕組みを作ります。
 

 
任命は、プロジェクト開始時に「あなたがこのプロジェクトのプロジェクトマネージャですよ」と言い渡し、
責任と権限を明確にすることが目的です。
PMOは、
 
　●プロジェクトマネージャを選ぶ基準（例．認定者）
　●任命するタイミング
　●任命時にプロジェクトマネージャに伝達すべき内容（プロジェクトの目的や目標、成功基準など）
　●任命の手続き（例．上位の責任者による任命など）
　●プロジェクトマネージャ交代時の手続き
 
などを決めます。
 
評価は、プロジェクト完了時に任命時の条件に照らして、成功したかどうかを評価し記録します。
 
認定は、 ITスキル標準［2］などに基づいて、組織の制度として構築しているITベンダーが多いようです。
認定時に評価する項目は、スキルとキャリアです。
スキルは、「研修履歴」や「公的資格」で評価します（図-3）。
これに伴い、PMOは、認定レベルに応じたプロジェクトマネジメント研修を準備します。
外部の研修を選定する場合もあれば、自分たちで開発するケースもあります。
「公的資格」は、連載の第1回（2013年10月号）で紹介したPMI （Project Management Institute）の
PMP（Project Management Professional）資格などの取得により、必要な知識が備わっているかどうかを判定します。
 
キャリアは、「プロジェクトマネジメント経験」や「プロフェッショナル貢献」、「人物要件」などで評価します。
「プロジェクトマネジメント経験」は、認定要素の中でもっとも重視すべき項目です。
任命されたプロジェクトの評価結果などをもとに判断します。
「プロフェッショナル貢献」は、学会などPMコミュニティへの参加や後進の育成など、
プロフェッショナルとしての活動を行っているかどうかを評価します。
「人物要件」は、面談などにより総合的にプロジェクトマネージャとしてのパフォーマンスを評価します。
 
③プロジェクトマネジメント技術の提供
PMIの「PMBOKガイドⓇ」（Project Management Body Of Knowledge）［3］には、
知識エリアごとに様々なツールと技法が紹介されています。
もちろんPMBOKガイドに書かれているものをすべて導入するわけではありません。
効果のありそうなものから導入していきます。
初期段階では、以下のようなツールや技法の導入を検討します。
 
●標準WBS（Work Breakdown Structure）
WBSは、「目的を達成するために必要な作業を漏れなく分解し、構造化して見える化」（図-4参照）する技術です。
役割分担やスケジュールなどのプロジェクト計画の要になるのがWBSですが、
簡単に作れそうに見えて、いざ作ってみようとすると意外に難しいものです［4］。
WBSの出来栄えで計画の精度も決まってきますので、支援するツールとしてWBSの雛形（標準WBS）の準備を検討します。
 

 
●工程表作成ツール
プロジェクトが始まると、工程表を中心にマネジメントをすると思います。
表現方法を統一して、効率的に管理するために組織で推奨する工程表作成ツールを決めておきます。
 
●リスク登録簿
ITプロジェクトの混乱は、同じような原因で繰り返し起こります。
他のプロジェクトで起こったことを自分のプロジェクトで起こさないということが最大のリスク対策になります。
リスク要因を積み上げていけるような仕掛けを作っておきます。
 
●各種ガイドライン
プロジェクトマネージャが実施するコスト管理、進捗管理、調達管理などについて、PM制度に合わせたガイドラインを作成します。
 
 
この他にも、プロジェクト管理ツールなど、標準化したり、開発したりしなければならないものはあると思いますが、
プロジェクトマネジメントの成熟度に合わせて準備していきます。
PMBOKガイドのような知識体系は、分野横断的にまとめられていますので、
ITプロジェクトの特徴に応じてカスタマイズする必要があります。
 
様々なPMOの活動について紹介してきましたが、先に書いたようにすべての施策を実施する必要はありません。
即効性のある施策から実施し、長期的視点が必要な施策に展開していくとよいと思います。
 
3回にわたりプロジェクトマネジメントについて解説してきました。
ITプロジェクトの成功に少しでも寄与できれば幸いです。
 

［2］ 独立行政法人情報処理推進機構「ITスキル標準　概説書（V2 2006対応版）」、アイテック、2007
［3］ Project Management Institute: A Guide to the Project Management Body of Knowledge （PMBOK Guide） Fifth Edition, PMI, 2012
［4］ 初田賢司「システム開発のためのWBSの作り方」、日経BP社、2012
 
 
 

第1回：なぜプロジェクトマネジメントが大事なのか？《前編》
第1回：なぜプロジェクトマネジメントが大事なのか？《後編》
第2回：プロジェクトマネジメントの知識体系《前編》
第2回：プロジェクトマネジメントの知識体系《後編》
最終回：プロジェクトマネジメント・オフィス《前編》
最終回：プロジェクトマネジメント・オフィス《後編》
 
 
 
【出典】

---

月刊積算資料2013年12月号

 
 

最終更新日：2014-07-10

 

ピックアップ電子カタログ