この春、プロジェクトマネージャになるシステムエンジニアの方へ

出版社の方の話しでは、技術書の「はじめての…」「…の教科書」のような新しいことを始めるための本は年度始めの４月を挟んで動くようです。まぁ、なんとなく感覚でわかりますね。そのシステムエンジニアのいくつかあるキャリアパスの中で、あまり人気のないと言われて久しいプロジェクトマネージャになってみようと思ったシステムエンジニアの方のちょっとした道標になれば幸いと思いついたので今日はそれを書くこととします。

アサインの瞬間から始まる期待
経験によらず、プロジェクトのロールにアサインした瞬間にアサインしたマネージャは、そのロールを全うすることを期待します。同じようにあなたがプロジェクトマネージャになってメンバをロールにアサインすると決めた瞬間からそのメンバがフルパワーでアウトプットすることを期待します。

これは幾つかの示唆を含んでいることに気付かされます。

１つは、立場が変わると相手に期待をするということです。もちろん、仕事で対価を得る以上、成果を出すことが求められますがその期待は定量的ではありませんし、明示的でもありません。

定量的でない期待のような要求は要求する側がエスカレートするので認識の違いからのフラストを起こす要因になってしまいます。チームとしての共通の価値観を持つことが必要なことの一つにこうしたことへの対応が含まれています。

もう１つはアサインされた方の立場としてです。いくら仕事としてでもプロジェクトに対してロイヤリティを持てるかどうかはプロジェクトの中での関係にかなりバイアスされます。チームの中での関係づくりが上手にできれば高いロイヤリティを持つでしょうし、チームの中での関係の維持にストレスがかかるのであればプロジェクトに対してロイヤリティは持てません。

いくら口で協力して欲しいと言われても、関係づくりが醸成できなければメンバはいるのにプロジェクトマネージャの期待するアウトプットは得られない要因にはこのようなことも含まれます。

これらはSIのシステム開発の技術やプロジェクトマネージメントの方法論に直接関係しませんが、人的リソースマネジメントのツールとして必要とされる知識です。

プロジェクトスタートから必要なプロセスとhow to
プロジェクトがスタートしたその瞬間からコストが消費されます。要件定義や設計作業を始めてからではありません。契約を終え、プロジェクトの開始日にアサインされるメンバが着任した時点でプロジェクトに課金が始まります。

始まった瞬間から、プロジェクトを動かさないといけないのですからそこにはプロジェクトの最初のフェーズが始まるわけですがそのフェーズのプロセスがなければメンバは動けませんし、下手に動かれても成果として作成しなければならない契約したアウトプットに求められる品質を満たしたものができるわけではありません。

プロジェクトをスタートさせるとは、全体のシナリオ、最初のフェーズとして作成するアウトプット、そのアウトプットを作成するために必要なプロセスとhow toが一度に必要になります。

ここで必要なことは、そのプロジェクトに必要とされるプロジェクトマネジメントの管理手法とシステム開発手法になります。これは、方法論や適用する技術にあたります。

広く求められる知識と実行力
たった２つの例示からだけでも広い領域の知識とその知識を使う実行力が求められることがわかっていただけたでしょうか。もしかしたら、それを知って引いてしまったでしょうか。

でも、心配はしないで良いと思います。誰だって、一度に全ての知識を得てからプロジェクトマネージャになったわけではないのです。システムエンジニアとしてプロジェクトのメンバとしてアサインされて経験を積み歩んできたときから自分の実践知として得ているのですから。

１つ違うとすれば、これまではその実践知は自分だけのノウハウとして抽出して暗黙の形式知として使っていれば良かったところが、プロジェクトマネージャとしてメンバが理解して実行できるモデルとして明示的に見せることが必要になるところです。

そのためには、経験知を形式知に変えプロジェクトの要求を達成できるパターンのストックをためておき、必要とされるタイミングで活かすことこそ必要になるのです。

プロジェクトマネージャになるためのパスはそれを目指す人の数だけあると思っています。人の数だけ世界線がある。そこにはやり遂げようとする意志と実行力が欠かせません。