>前回はPMOへの要求事項はトップダウンとボトムアップ両方からアプローチする必要があると書きました。私の実体験を例にしてみましょう。この例は、以前ご支援していた製造業A社のお話です。何時までたっても安定しないシステムA社の大規模システムのPMOメンバーとして参画することになりました。ユーザ企業のPMOという位置づけです。初期構築から1年近くたっていますが、サービス追加・サービス改善のための追加開発を行っています。<プロジェクトの特徴>元々が大規模であるため、追加開発といっても相当な規模になる。サービス追加・変更が頻繁にあるため、2,3か月に1回はリリースしている。社員の人事異動によりサービス・システムに対する知識・スキルが流出する。<問題>上記事象が重なり品質が安定しない。開発ベンダ側に依存しすぎているため、品質向上の策がうてない。上記理由により、PMOを設置することになり、私も含めて4人がPMOメンバーとして参画することになりました。恐ろしい要求が・・・A社の組織長がまとめたPMOのスコープです。「っていうかPMOにアサインされたの4名だしっ!」とパニックです。作業ボリュームもさることながら、スキル的にこれを全部できるスーパーマンみたいな人、そうはいません。プロジェクトを見てみるこのようなトップからの要求が目の前に出されると何をしてよいやら検討がつきません。「第3回PMOの役割」であげた「実プロジェクトに参画し管理や技術支援を行うPMO」「プロジェクトマネジメントや開発の基準・標準を作成するPMO」「プロジェクト状況をまとめ組織長に報告するPMO」のすべてを盛り込んだ要求です。検討がつかないなら、開発ベンダとの進捗会議に参加してプロジェクトの状況の確認を始めました。開発ベンダB社にはリリース毎にサブプロジェクトの体制を作っています。進捗会議の状況はというと・・・・<サブプロジェクトCの進捗会議>「設計レビューでのA社側からの指摘が多すぎる。要求事項を理解しているのか?そもそもどのようなサービスはわかっているのか?」<サブプロジェクトDの進捗会議>「試験のちゃんとやっていたらこんなことになるはずがないだろう。」<サブプロジェクトEの進捗会議>「リリース失敗したじゃないか。リハーサルでミスを発見できなかったのか。」とA社の怒号が飛び交います。B社は疲弊しています。この会議は毎週同じような状況が続いており、以下が問題ではと考えました。発注側と受注側はWin—Winの関係にはなっていない。問題発生時の原因・対策についてはすべて開発ベンダB社作業に閉じており、発注側のA社作業に言及していない。次はA社内の活動をみることにしました。長くなるので、続きは次回ということで。*********4月27日の夕方に喉の痛みが出てきました。今年初の風邪の兆候です。なんでGW直前なのよ!そして、GW明けても鼻がムズムズ。元気が取り柄だったのに...なんだか長引きそうです。入社(NTT分社化によりエヌ・ティ・ティ・コミュニケーションズ株式会社に転籍)。経験し、その後プロジェクトマネジャーとしてプロジェクトに携わる。Office)の運営およびプロジェクトマネジメント支援や、IT構想企画の支援を行っている。社員の声アクセス採用情報ブログ株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。Inc.)の登録商標です。Provider)です。Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。アイ・ティ・イノベーションまたは各社の商標もしくは登録商標です。