プロマネは適用力に柔軟性を維持し続けなければ老害になってしまう
「新規プロジェクトを始める前に準備しておくこと」というスライドがあるのですが、これ、プロダクトやWebサービスなどの開発向けなんでしょうかね。いわゆる、SIのシステム開発とは違いますものね。
ワタシのイメージはこちらなのですよねぇ。
こうした自分の知っていることを文字にすることと他の人のやり方を知って、「いいな」と思ったらそこの部分を取り入れていかないと古いやり方になってしまうので怖いですね。
なぜ、怖いと思うかというと、プロジェクトマネージャの専門家としては、経験を持っていて自信を持ってやれる業務ドメインが基本的にあるものです。これはその業務ドメインで育ってきた、という言い方もできます。そうした背景は誰でも実務の経験値を持っているならあるものです。もしなければ、それは学者先生か机上の知識の人だけです。
所詮、PMBOKだってプラクティスといいつつ枠というかフレームワークでしかないのです。実務を回す為には、実務で角を削られ残ったアセット、これはプロジェクトで実際に使うツールやテクニックに相当するマテリアルですが、それらがなければプロジェクトマネジメントを管理、コントロールすることはできないのです。
例えば、実務で使うWBSは実現するプロジェクトの目的を達成する為に最適なシステム開発手法を選び、そのシステム開発の作業を標準化したものをテンプレートとして用意し、実際のプロジェクトの成果物を作る作業に当てはめるわけです。
プロジェクトマネジメントのフレームワークの上にあるシステム開発手法は、世の中の技術の変化で変わっていきます。今ではオンプレのシステム開発からクラウドを取り込んだオンプレ＋クラウドみたいなケースもあるし、全部クラウド、みたいなケースも増えてきています。
変遷するシステム開発手法をよくよく中を見てみれば、オンプレでシステム開発をしていた一部をクラウドサービスに置き換えているだけのことが多いのが現状ですが、この先座は変わっていくでしょう。
そうしたときに、プロジェクトマネジメントの専門家として対応できるかどうかということです。まずは、概念が理解できないと頭が受け付けませんから。実務、実装は、デザイン、インプリの専門家に頼めばいい。でも、プロジェクトの責任はプロマネですから。
そのときに、旧態依然としたプロジェクトマネジメントの管理手法で良いかといえば、それはプロジェクト最適化に成っていないのでダメな判断なわけです。
専門家に求められるのは、業務委託を受けたときの専門家としての知見を生かした案件のキャリーです。それができるためには応用力の柔軟性を保たなければなりません。それがこうした他者からの学びや学習なのです。
その裏側には、対応できない場合の怖さがあるのです。そのときは専門家としてはやっていけないから。
