前回は製造業A社のPMOに参画し、“当面”のPMO活動(PMO要求)を以下のように設定しました。
(1) プロジェクト活動で発生した解決していない問題・課題を収集し、開発ベンダとともに原因分析、対策を検討する。
(2) 充実した要件定義書を作成するために、要件定義の標準を策定し導入する。
その後実施した問題・課題の原因分析・対策検討や、要件定義の手法については弊社の研修を受けていただければよ〜くわかります(笑)
等々あります。ご参考までY(^^)Y
ここでは標準策定の手法ではなく、策定したものをどのように導入するかに焦点を当てたいと思います。
標準を策定し導入しようと...
PMOメンバーで作った標準(要件定義実施要領)を使ってもらおうと、A社当該プロジェクトメンバー向けに説明会を開きました。
PMO:
「PMOから提示の要件定義実施要領1章には作成するドキュメント一覧を書いています。」
「本システムのサービスやシステム全体像がわかるように、サービス一覧、サービス概要、サービス・機能マッピングが必要です。」
「次に機能一覧、機能概要、概念ERDと・・・・・云々」
「各種ドキュメントの記述方法については、3章に記載しています。サンプルもあります。」
と実施要領にそって説明を行い、その後意見を求めたところ
A社Sさん「説明されても、何からしてよいか解りません」
A社Rさん「そんなにドキュメントを作らなくても開発はできているし、必要性を感じていません」
A社Qさん「今でも忙しくて残業ばかりなのに、その上要件定義書を作成しろって言われても稼働がないからできない」
と全否定です。
そりゃあ怒るわ。反省です
説明会後はPMO反省会です。
確かにプロジェクトメンバーの皆さんはいつも夜遅くまで残ってサービス追加や業務改善のためのシステム開発対応を行い、商用で障害が発生した場合には障害調査や対応を行い、システムを止めることなく仕事をしているのに後からやってきたPMOが「今までのやり方ではダメです。こちらが言う手順を踏んでください」と言われたらカチンときますよね。
では何をすれば理解を得られるのでしょうか?
どれも全否定していたプロジェクトメンバーに必要性を感じてもらえるとは思えません。
そして弊社でも研修があるように要件定義を行う上で知識・経験そしてセンスも必要です。「実施要領」を見れば誰でもすぐ出来るというものではありません。
やるしかないです
いろいろ考えましたが、PMO自らが要件定義を行うことにしました。
新サービスや業務改善の検討が始まるとその体制にPMOもいちメンバーとして参画、サービス・業務要求(こちらはサービス/業務企画部という別の部署が主体で実施しています)からシステム化するための検討を行いました。
今までは、
(1) 課題管理表でサービス/業務企画部とQ&Aを行い
(2) そこで決定した内容を元にチーム内で影響を話し合い
(3) チーム内上がった影響箇所のシステム化方法案を文書で記載しRFPにする
という方法でしたが、(2)と(3)の間で、PMOメンバーがモデル化(要件定義の実施要領で定義したドキュメント)することにしました。
すると、
「チーム内でXX機能に影響があるということでしたが、同類のYY機能に影響はありませんか?」
「VV業務とWW業務の順序が逆になることはありませんか?」
という感じで当該システムを熟知していないPMOメンバーから(2)では気づかなかった影響箇所や、さらに前で検討しているサービス/業務要求の不足箇所を見つけることができるようになり徐々に要件定義の必要性を理解してもらえるようになりました。
ここで重要だったのはPMOが作成した「要件定義実施要領」は、要件定義書の作成を目的としていたわけではなく“要件定義を行うことによりサービス、業務、システムの検討漏れを減らす”ことが目的だということを体感してもらえたということです。
では、次回はプロジェクトのその後です。
*********
1年前父が60代後半で仕事をリタイアした時に、今まで履いたことのないジーンズとそれにあうシャツを買ってプレゼントしました。その時は着たことのない服に困った様子でしたが、1年経った今着こなしているではありませんか。またプレゼントしようか?と聞くと「ジジくさい服はやめてくれ」とまで言うように。
そして離れて暮らしている両親とはスカイプで電話し、リタイア後からスポーツクラブに通い始めてマッチョになった父はiPadを持って私から送った写真を見ており...
若返っていく両親を見ると、「20代の頃は朝まで仕事をしても飲んでも平気だったのに最近は無理ね」と言っている自分が恥ずかしくなります。
(ということで父の日のプレゼント用に私のダンナさまが着るような派手なポロシャツを買ってきました。)