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

＜　前回　｜　目次　｜　次回　＞

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

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

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

＜プロジェクトの特徴＞

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

＜問題＞

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

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

恐ろしい要求が・・・

Ａ社の組織長がまとめたＰＭＯのスコープです。

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

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

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

開発ベンダＢ社にはリリース毎にサブプロジェクトの体制を作っています。

進捗会議の状況はというと・・・・

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

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

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

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

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

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

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

＜　前回　｜　目次　｜　次回　＞