前回は製造業A社のPMOに参画し、まずは、A社とB社(開発ベンダ)の定例会に参画して二社間の問題を把握しました。
では、A社当該プロジェクトチームはというと・・・
一体どんなシステムなのですか?
これから携わるシステムですので、システムの概要を早く押さえたいところです。
ということで、何をやっているシステムか解る資料を探し始めましたが・・・なかなか見つかりません(汗)
関「システム概要が解る資料ありませんか?」
A社Tさん「ありません」
関「・・・・・・」
まあ、よくあることです。追加開発をすると初期構築から役割が広がったりすることはしばしばあります。では、初期構築時の要件定義(RFP)なんぞ見てみようとファイルサーバをゴソゴソ。ありました!内容を見てみると・・・あれ、薄っぺらな要件だこと。そして・・・用語がわからない。
ということで、用語集を探してみたところ、用語集の説明がわからない。用語集の説明にかかれている用語でさらに検索してみると、また解らない説明が・・・続けて説明に書かれている用語を検索すると・・・元の用語に戻ってしまいました。まあ、よくあることです。
では、とりあえず最近の追加開発の要件定義書を見てみると・・・またもや薄っぺら。内容を見てみると・・さっぱり解りません。
関「このRFPには何のサービスのためにシステム開発するかについて書かれていませんし、システム要求もずいぶん簡単で、読んでもさっぱり解りません。」
A社Tさん「そうでしょうね。でも初期開発から同じ開発ベンダなのでこれで通じるんです。解らないところは質問されれば答えていますし。」
関「・・・・」
このような状況で以下の問題に気づきました。
PMOの要求を纏めてみましょう
ここで、トップダウン要求とボトムアップ要求から、要求事項を整理しましょう。
トップダウン要求
ただこれは、組織長がプロジェクトの問題と感じている
の解決策として組織長がまとめたスコープであり、「度重なる追加開発でも品質の安定したシステムにしたい。自分たちの力で品質を安定させるために開発ベンダへの依存度をさげたい」が本来の要求(目的)です。
ボトムアップ要求
現場では、発注側と受注側の関係について以下の問題に気づきました。
次にA社内で気づいた問題です。
これより
「Win−Winの関係になり、両者で問題発生時の対策をうち品質を安定させる」
「サービス要求、システム要求を充実させ開発側と要求事項を共有する」
を一旦ボトムアップ要求としました。
(ここではまだ詳細を把握していないため「一旦」としています)
以上から、“当面”のPMO活動(PMO要求)を以下の2点に絞りました。
(1) プロジェクト活動で発生した解決していない問題・課題ものを収集し、開発ベンダとともに原因分析、対策を検討する。
(ここで言う問題・課題とは、例えばリリース作業でミスをした場合にミスは修正したが、なぜミスが発生したかの根本原因を解決していないことを指しています)
(2) 充実した要件定義書を作成するために、要件定義の標準を策定し導入する。
(1)については、品質向上(トップダウン要求)のために不可欠ですし、またプロジェクトの詳細状況を把握するために非常に有効な「本当のボトムアップ要求」がみえてくる活動です。先に“当面”と書いた通り今回のPMO要求は詳細な現状調査をしないままの“暫定”要求ですね。
(2)についてはPMOメンバーが“感じたこと”になりますが、PMOが理解できない要件定義書ということはプロジェクトに新規参画した人の誰もが同じです。またトップダウン要求「標準の策定」とも一致しているため有効だと判断しました。
では次回はPMO活動の様子についてです。
*********
GW前から風邪の兆候が...と前回書きましたが、まだ咳が残っています。普段風邪を引かないから長いのか、今年の風邪の症状なのか...皆さん気をつけてくださいね。ゲホッ