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

＜　前回　｜　目次　｜　次回　＞

前回まで、ＰＭＯが必要な理由と仕事について触れてきました。
簡単に纏めると

• ＰＭがうまくマネジメントできるように支援する
• 組織の統制をとるための仕組みをつくる

ということでした。

でも皆さん、「なるほど、確かにその通りだ！」と思いましたか？それより
「報告書出せだの言うだけで、メンバーの業務が楽になるようなことは何もしてくれない」
「いろんな基準やチェックシートがどんどん増えてきてＰＭの業務が増えていく一方だ」
と感じていませんか？
では、まわりに「必要だ」と思われるＰＭＯにするにはどのようなことが必要なのでしょうか？

ここでちょっと話しはかわりますが、これを読んでいるのはＩＴ系のプロジェクトに従事している皆さんが多いと思うので、システム構築の「要求」を纏めるプロセスについて考えてみます。システム構築の「要求」をまとめるには、以下のようなプロセスを踏みます。

(1) ビジネスの方向性、新サービスを確認して、あるべき姿を描く。（トップダウンのアプローチ）

(2) 現行業務・システム仕様書やステークホルダーへのインタビューにより現行の業務およびシステムを把握するとともに、現行業務・システムの課題を洗い出す（ボトムアップのアプローチ）

(3) (1)と(2)をもとに要求事項を体系的に整理していく。その中でシステム化すべきものを定義する。

小難しくBA（注）っぽく書いてみましたが、もうちょっとわかりやすく書くとこんな感じでしょうか？

(1) 新サービスや新業務の内容を具体化するためにサービス企画・業務企画チームと検討を重ねる。

(2) 業務に従事している人やシステムを作った人にヒアリングをして現在の業務やシステムのどこを変更すればよいか考える。その中で既存の悪い部分もヒアリングを行う。

(3) 新しいシステムや業務プロセスに追加するものを整理する。

ほら、要件定義をしている人は「いつもやってるよ」って思いますよね。
システム構築する際には、トップダウンとボトムアップ両方のアプローチによって要求を明らかにします。
要求をうまくまとめ実現することができれば、会社の業績にも貢献でき業務に従事している人にも仕事がしやすい仕組みができるでしょう。誰もがハッピーです。（まぁ、そんなに簡単にはできないのですが・・・・）

では、ＰＭＯへの要求とは何でしょうか？
組織長から
「うちの組織にはプロジェクトマネジメント標準がないんだ。だから標準を作る必要がある」
「品質が悪いのは、品質管理がキチンとできていないからだ。ＰＭＯで品質管理のテンプレートを作ってほしい」
このような「要求」によりＰＭＯが設置され、標準やテンプレートを作り、プロジェクトへの導入を促すということはよくあることでしょう。
でもこれでは、先ほどの「システム構築の要求と纏める」プロセスとは違いますよね。ボトムアップのアプローチがありません。

ＰＭＯに対するトップダウンの「要求」のみで活動した結果、現場（プロジェクト）からは「面倒くさいＰＭＯ」になってしまいます。逆にプロジェクトからの「要求」のみで活動すると、現場よりの活動のみとなってしまい、気づけばただの便利屋さんになったり、組織長からは効果が見えないＰＭＯになるのです。

もし、あなたがＰＭＯのメンバーになった場合、システム構築の要求と同じようにトップダウンとボトムアップ両方からアプローチすることによって、組織長からも現場からも必要とされるＰＭＯになれるのではないでしょうか。

では、次回はもう少し具体的な例を入れながら掘り下げていきましょう。

注）ＢＡ：Business Analysis（組織のゴールを達成するためにステークホルダーから要求を引き出し、解決策を考え、それが実行可能な状態になるよう定義し、解決策が実行され効果を評価する一連の活動。）

*******
週末実家に帰ってきました。実家に帰ると親戚から「和美はいったいどんな仕事をしているんだ」と毎回聞かれて返答に困ってしまいます。業界が違い、プロジェクトの概念がない仕事をしている人にＰＭＯの仕事を説明するのは、この連載以上に難しいですね。
今回も適当に流してしまったので、次回帰省したときにもやっぱり同じ質問を聞かれるんだろうな～。

＜　前回　｜　目次　｜　次回　＞

待望の方法論（Modus PMO）をリリースしました！

• 「方法論 – プロジェクトマネジメントオフィス運営方法論のご紹介」はこちら。
• 「開発者よりのメッセージ」はこちら。

PMO要員育成のための研修コース

• 「研修 – プロジェクトマネジメントコース」はこちら。
• 「研修 – ビジネスアナリシスコース」はこちら。