プレイングマネージャの嵌りどころ
プロジェクトマネージャは2つのタイプがある。プロジェクトマネジメントにフルアサインされているPM、もう1つはエンジニアと兼務、つまりパートタイムでアサインされているPMである。
プロジェクトマネジメントにフルアサインされているPMも、excelの進捗管理表と睨めっこしているような、なんちゃってPMは除く。
フルタイムでアサイメントされているPMはこの回では扱わない。パートタイムのPM、つまりプレイングマネージャを取り上げる。現実のところ、プレイングマネージャが大多数なのではないかと思う。
プレイングマネージャの良し悪しは別にして、プレイングマネージャだからこそ、嵌りやすいポイントがある。
- スイッチング
脱線をすると、エンジニアのパフォーマンスを最大限に発揮してもらおうと思ったら、プロジェクトを複数掛け持ちでアサイメントするのは極力避けたほうがいいと言う考え方がある。兼務をしているとプロジェクトを切り替えたとき、以前やっていた記憶を取り戻すためのスイッチングに相当のオーバーヘッドが掛かるからだ。そして、調子を掴んだ頃にまたスイッチングが、となる。
エンジニアで、同じような役割でもこんな調子なのだから、エンジニアとプロジェクトマネージャという全く違うロールを兼務したときのスイッチングの断絶感はハンパないことが容易に想像できるだろう。
- 深さと広さ
もう一つの見方がある。エンジニアは要件を実現するための仕様を考え、それを最適なコードに実装する。そのとき、様々な具体的な諸条件を想定しながら処理をイメージアップする。そのとき、対象の機能の世界に深く潜り込むため、外部と遮断したいし、イメージを具体的にしている最中には割り込みされたくない。これはこれとして、そうした思考にダイブ中には、周りが見えなくなる。
ところが、プロジェクトマネージャはそうはいかない。常に、プロジェクトの進行上のリスクの芽がないかを探して回る。深くではなく、広く、些細な違和感を見つけるために。エンジニアの思考と全く違う指向性を持っているのである。
実体験として、プレイングマネージャを担うなら、要件定義、基本設計のようなシステム方式まで（できれば要件の整理までにして、方式の主要タスクはアーキテクトに任せる）で、あとはテストでのちょっとした手伝い（テストデータ作りをPMがやると要件をわかっているので実装の抜けを見つけたりする）くらいにした方が良い。
