プロジェクトマネージャの覚悟

on

プロジェクトマネージャでもマネージャでもなんのために存在するのかといえば、判断するためにいるわけです。じゃあ、その判断はプロジェクトマネージャやマネージャだけがするのかといえば、そんなこともないです。

誰もが判断をしている

例えば、新入社員でさえ、自分のタスクを終わらすまでの間に情報収集をして、ツール＆テクニックを使って加工処理して、アウトプットするプロセスの中のツール＆テクニックのところで、アウトプットで求められている品質基準にそうように物事を判断して処理しているのですから、基準は外にあるかもしれないけれどそん基準に沿っているかの一次的な判断は新入社員でさえ行なっているのです。

役割による判断の違い

違いは何かといえば、自分が判断を下した後ろに誰かいるか、いないかの違いです。新入社員であれば、先輩のシステムエンジニアもいるから相談に乗ってくれるし、最終的にはプロジェクトマネージャもいるので、新入社員のアウトプットはそうした多層化されたフィルタで守られていると言ってもいいです。

ところが、リーダになれば内部レビューを掛けるプロセスをしてもアーキテクトかプロジェクトマネージャが見なければ、ほぼスルーな状況に置かれるから保護フィルターはあまり役に立たないというか、ロール的に担当するブロックに対しては権限移譲されているでしょうから、実質ないのと同じでしょう。

ましてや、アーキテクトであればプロジェクト全体のグランドデザインからプロジェクトに求められる品質要求の達成を求められますよね。

最終的には、プロジェクトのチームとしてプロジェクトマネージャが可否を判断するわけですが。

リカバリまで考えている（ハズ）

そこにある大きな違いは判断する覚悟です。覚悟とは、もし誤った判断をしたら別の判断にそうようにリカバリするところまでやりきると腹を括る、ということです。

システム開発は年々、複雑に、短期になっていることから、そうした判断の間違いは一発でリカバリが効かなくなってきています。プロジェクト単体の成功・失敗という結果もそうだし、財務的な観点でもそうです。顧客にしても間違った判断はビジネス機会をロスするものです。

だから、アジャイルのような開発が一部では指向されたり、フィージビリティスタディのように実現性を調査しながら進めたりするわけです。

まあ、従来のウォーターフォールでも局面での工程終了などは、誤った判断を共有していると言えばそうですけど。

思考の根拠

こうした仕事上の判断を早く、でも確実に行いたいと思うと必要になるのがロジックです。ロジックは判断プロセスといってもいいです。思考の根拠、と言ったほうがいいかもしれません。これは、型にはめて思考パターンを固定するために使うのではなく、

  • 判断した根拠を説明できるようにするため
  • 間違った判断をしたときにどこを変えればいいか明らかにするため

の２つの目的で使うものです。

プロジェクトマネージャやマネージャがいくら判断が早くてもこの思考の根拠を説明できないマネージャの判断は危なっかしいので注意が必要です。