ホーム > ブログ > 関和美の記事一覧 > 【第6回】実際の現場を見てみよう (1)

【第6回】実際の現場を見てみよう (1)

Pocket

< 前回 | 目次 | 次回 >

前回はPMOへの要求事項はトップダウンとボトムアップ両方からアプローチする必要があると書きました。
では私の実体験を例にしてみましょう。この例は、以前ご支援していた製造業A社のお話です。

何時までたっても安定しないシステム

A社の大規模システムのPMOメンバーとして参画することになりました。ユーザ企業のPMOという位置づけです。初期構築から1年近くたっていますが、サービス追加・サービス改善のための追加開発を行っています。

<プロジェクトの特徴>

  •  元々が大規模であるため、追加開発といっても相当な規模になる。
  •  サービス追加・変更が頻繁にあるため、2,3か月に1回はリリースしている。
  •  社員の人事異動によりサービス・システムに対する知識・スキルが流出する。

<問題>

     
  •  上記事象が重なり品質が安定しない。
  •  開発ベンダ側に依存しすぎているため、品質向上の策がうてない。

上記理由により、PMOを設置することになり、私も含めて4人がPMOメンバーとして参画することになりました。

恐ろしい要求が・・・

A社の組織長がまとめたPMOのスコープです。
seki_chart120501a
これを見た瞬間
「???アレッ?PMOの仕事多くない???」
「要件定義、基本設計ってPMOの仕事だっけ?」
「っていうかPMOにアサインされたの4名だしっ!」
とパニックです。
無理です。作業ボリュームもさることながら、スキル的にこれを全部できるスーパーマンみたいな人、そうはいません。

まずプロジェクトを見てみる

このようなトップからの要求が目の前に出されると何をしてよいやら検討がつきません。
「第3回PMOの役割」であげた「実プロジェクトに参画し管理や技術支援を行うPMO」「プロジェクトマネジメントや開発の基準・標準を作成するPMO」「プロジェクト状況をまとめ組織長に報告するPMO」のすべてを盛り込んだ要求です。
検討がつかないなら、開発ベンダとの進捗会議に参加してプロジェクトの状況の確認を始めました。

開発ベンダB社にはリリース毎にサブプロジェクトの体制を作っています。
seki_chart120501b
進捗会議の状況はというと・・・・

<サブプロジェクトCの進捗会議>
「設計レビューでのA社側からの指摘が多すぎる。ちゃんと要求事項を理解しているのか?そもそもどのようなサービスはわかっているのか?」

<サブプロジェクトDの進捗会議>
「試験のちゃんとやっていたらこんなことになるはずがないだろう。」

<サブプロジェクトEの進捗会議>
「リリース失敗したじゃないか。なぜリハーサルでミスを発見できなかったのか。」

とA社の怒号が飛び交います。そしてB社は疲弊しています。
この会議は毎週同じような状況が続いており、以下が問題ではと考えました。

  • 発注側と受注側はWin—Winの関係にはなっていない。
  • 問題発生時の原因・対策についてはすべて開発ベンダB社作業に閉じており、発注側のA社作業に言及していない。

次はA社内の活動をみることにしました。ちょっと長くなるので、続きは次回ということで。

*********
4月27日の夕方に喉の痛みが出てきました。今年初の風邪の兆候です。でもなんでGW直前なのよ!そして、GW明けても鼻がムズムズ。元気が取り柄だったのに…なんだか長引きそうです。

< 前回 | 目次 | 次回 >

Pocket

目次

Profileプロフィール

関和美
関和美
奈良女子大学 理学部 物理学科(現 物理科学科)卒業 日本電信電話株式会社に入社(NTT分社化によりエヌ・ティ・ティ・コミュニケーションズ株式会社に転籍)。主に金融系のSEとしてNWシステム 構築の設計、アプリケーション開発の要件定義、設計工程を経験し、その後プロジェクトマネジャーとしてプロジェクトに携わる。 2007年より現職。大規模プロジェクトにおけるPMO(Project Management Office)の運営およびプロジェクトマネジメント支援や、IT構想企画の支援を行っている。PMP。

Recent Entries最近の記事

このページのトップへ