外部リソースのメンバでプロジェクトをチーミングするするときに忘れてはいけない2つのこと

過去を振り返るとこれまでワタシ自身がプロジェクトマネージャのときのプロジェクトチームのメンバのキーパーソンに当たるロールは必ず正社員を引き当ててきたんですね。どちらかというと、プロジェクトメンバのほぼ全員が組織のリソースだったりとか。

今の世の中は、アウトソーシングから内製化にその潮流の向きが変わって自社開発をする組織が多いと認識しているけれど、その前まではアウトソーシングの延長でプロジェクトメンバも外部リソースを引き当てよとプレッシャがあったものです。

ワタシがキャリーしていたプロジェクトはワタシ自身の経験値の不安材料からくる懸念と適用技術、それを実装するスキルセットを持つエンジニアの調達の実現性などを鑑みた結果、リスクを正社員を当てて回避する策を選択していたわけです。

とはいえ、いわゆるゼネコンタイプのプロジェクトチームの構成にも興味があって、それはビジネスを負うマネージャなら数字を背負っているので食指が動くのも当然なのです。でも、ほとんどやってこなかったのは、リーダとなる組織のエンジニアの適性の話とゼネコンをするにもそれを補完する外部リソースの確保の問題などがあって結局、ワタシが機会を得ることはなかったんです。とはいっても、まったくやってこなかったというわけでもなくて、少しはありましたけどやってきました、というほどでもないので。

たまたま、支援に入ったプロジェクトがあって気づいたら、というか策略もあったのでしょうけど、一度は何でもやってみたい性分なのものあるのですがそれにトライする機会があったんです。これから書くことは、いやそれ、「ゼネコンタイプのプロジェクトと組織のリソースを使うのとあまり変わらないじゃん？」って思うかもしれないけれど、変わらないけどインパクトの度合いが違うんです。組織の中のリソースなら、力技でどうにでもなる。けれど、外部リソースの場合は間に“契約”は挟まるのでフリーハンドではオペレーションできないんで。

キーパーソンは選べ
これ、ワタシが自分でキャリーするなら必ず気にするところです。キーパーソンはキモですから。

外部リソースの人をキーパーソンに据えるなら、一度は一緒にプロジェクトをやりきった人を選ぶこと。

こういうのって、本当にプロジェクトの中で苦労しちゃうと身に染みるんですよ。二度とこれで苦労したくない！！！って。

キーパーソンに対する期待があるわけで、その期待に応えてもらわないとプロジェクトはそこから崩れていくのです。だから、そのキーパーソンに充てる人の“人なり”や“パフォーマンス”を知っていないとプロジェクトをキックオフして、走りながらポテンシャルを探りつつ場合によっては対策をしてことに当たる必要が出てくるんですね。

そのキーパーソンに充てる人への期待が吉と出ればいいのですが、最悪なケースは、改善と経過観察、入れ替えまで至る場合です。プロジェクトをキャリーしつつ、そうした人的トラブルが発生するとそっちにリソースを取られるのでとてもしんどいです。メンタル的にも堪える。

一言で“パフォーマンス”と書きましたが、ワタシがプロジェクトマネージャのときに期待するパフォーマンスは、スピードと思考の柔軟性が含まれているので、期待するスピードでアウトプットを出してくれないと今度はワタシがストレスを感じてしまうんです。なのでどのくらいのスピードがでるかを知っておきたいのですね。

組織の中のリソースなら、所属するところにって周りにインタビューすれば人なりも大体想像つくし、経験してきたプロジェクトの名前を聞けばある程度の想像は働きますし。もし何かウィークポイントがあれば、そっと教えてくれることもあるし。そうしたセンシティブなことはやってみて初めて分かるというのが怖いんです。

メンバは固定しなさい
プロジェクトをキャリーするためにチーミングするわけですが、局面ごとの作業のボリュームに応じてそれを担うメンバが必要です。当たり前なことですが、局面の作業に応じたスキルを持つメンバがいなければそれは人的リスクとなって具現化してしまうのですが、そうにもかかわらず、必要なスキルセットを持ったリソースを確保できないこともあるわけです。

例えそうした場合でも、その局面に必要なスキルを持つ人的リソースを確保できなくても、コアとなる最低限と設定するスキルや関連するスキルを持っているならプロジェクトの中でその必要となるスキルが必要な局面までに用意できればいいわけで、予算的に遣り繰りをしてでもそうした期間を持って要員計画を立てることが、必要な時に必要なスキルを持たないエンジニアを投入することで抱え込んでしまうリスクで発現するエクスボージャより安価であることは理解しておくことも必要です。

アジャイルを採用するチームが高パフォーマンスなのは、実際は、必要なスキルセットを持つエンジニアを固定で維持しようとするからです。つまり、解はそこにあるのです。

人はプロジェクト全体の局面のロールとスケジュールを通して考える必要があるのです。特にキーパーソンは工程でのロールが変わることがあっても固定しておくべきです。その上で、局面で必要なスキルセットをプロジェクト当初で必ず洗い出し、プロジェクト当初から重要局面までは確保できるように山積みを平準化するときに指針としてチーミングの材料とするのです。

多くのメンバを外部リソースで賄うとき、そうした人の調達がその外部リソースを持つ組織に委ねられてしまうんですね。これはこれで当たり前なんですが、そうだからこそ、外部リソースを持つ組織の都合でプロジェクトの局面にかかわらず、入れ替えが発生することがあるんですよ。これ、いい感じで経験を積んできてこれから、って時にやられるとチョー困ります。というか、ふざけるなーって思う。

だから最初にプロジェクトチームにジョインするときにいつまでいて欲しいかきちんと伝えないといけないんですね。これ、発注側で意外とやらない人が多いので注意が必要なんですよ。