仕事を楽しめるチームを作るときにプロジェクトマネージャが考えていること

ワタシのプロジェクトマネージャの思考スタイルは、プレイングマネージャよりはマネジメントマネジメントしているプロジェクトマネージャなのですが、それなりにプレイングマネージャでも「いけまっせ」といえるドメインは持っているのでどっちもいけます、が正解といえば正解。

でもでも、「プロジェクトマネージャはかくあるべき」というならば、やはりマネジメントがミッションのプロジェクトマネージャありきで考えるのです。

だから、開発チームを編成するときにスコープで実現しなければならない成果物を作るために必要な技術とレベルのスキルセットを満たすメンバを手に入れるために画策するのです。

特に気をつけるのは、技術のキーパーソンですね。言い換えればSEリーダとも言えるし、技術リーダとも言える。ある意味、アーキテクトでもある。そうしたキーパーソンがチームの要に２人くらいはいるものです。それは絶対にリクエストするときに譲歩しない。

だって、プロジェクトの成功率を自分で下げてしまうじゃないですか。そんなことをしたら。

そうしてメンバを集めていくわけですが、キーパーソンとなるメンバには仕事の仕方の希望を聞いたりします。こちらとしては、対外的なことのうち技術以外は全部やるけど「技術的な設計とか実装はお任せしたいよ」とか「でもプロセスは相談しながらだけどこっちで決めるからどうプロセス設計したらメンバが一番仕事に集中できるか教えて」とか。

なんだかんだ言って上流の設計やもちろん主体的に書いて外部レビューを仕切ったりしましたが、一方、実コードは書かないんだけれど、それ以外で手が足らなくて足すこともできないならネコの手くらいにはなりますよ、でしたが。

「これでやって」ではなくて、「こうしたいんだけどキミの意見も取り入れたい」と折衷案にすることで「押し付けられ感」を含めたくないのと、提案しつつ内心では自分でほぼ決めているようなスタイルだけはどうもワタシ自身が受け付けないので、同じ思いをさせたくないんですよ。

だって、仕事を気持ち良く手をつけられないし、面白くないじゃないですか。どうしてかってですか。それは自分の気持ちいいやり方じゃないから楽しめないんですよ。

キーパーソンのメンバはとても優秀です。少なくてもワタシができない方式設計や実現仕様を設計したり、実装してくれるんですから。他のメンバだって実装やテストをしっかりやってくれる。こうしてチームのパズルが埋まっていくですよね。カチッと。

でもカチッとはまらないところもある。それでもプロジェクト期間中にメンバのいいところでワタシだけが知らないことを見つけようとするんです。それを知ることはプロジェクトの成功要因を高めるんです。知らなければそのスキルを生かせないんですから。

メンバのスキルを使い倒すこと、これはもしかしたら大変なプロジェクトかもしれない。メンバだってそう思うかもしれない。

であっても、彼ら彼女らにはワタシのプロジェクトは大変かもしれないけれど、プロジェクトを楽しんでほしいんです。で、どうして楽しんでほしいのか、です。

楽しめないとですね、工夫しないんです。頑張りもしない。ここを乗り越えよう、という気にもならない。でも、楽しめると乗り越えた自分スゲー、となる。大変でも楽しめるからやりきれるんです。

これってですね、仕事を楽しめると仕事に付加価値を付け始めるということなんですよね。自分が楽しいからもっと楽しめるように、ちょっと楽チンツールを作ってみたり、プロセス改善を考えたり。

仕事を楽しむってこういうことなんですよねー。