(続)プロジェクトに新規参入者するメンバの受け入れ −あの日参画したメンバのスキル領域とレベルをまだ僕達は知らない。−

前回までの「プロジェクトに新規参入者するメンバの受け入れ」では、情報共有の視点での切り口で整理しました。その最後で、こんな言い回しで終わったわけです。

「ところで、この「プロジェクトに新規参入者するメンバの受け入れ」は受け入れる立ち上げ時のメンバが情報共有の観点で考慮しなければならないテーマを検証してきましたが、このテーマだと別の切り口もあるのですが、どのような切り口、テーマになるか想像つきますか。」


つまり、「別の切り口もあるけど思いつくかな」と。


project of resources
プロジェクトの資源を思い出しましょう。


「人物金」と「時間」


前回までの情報は物に括ります。では、人はどうでしょう。人の参画という行動については言及していました。でも、人そのもの、については及んでいませんでした。


なぜプロジェクトに人が必要なの
この標題には間違いが1つあります。プロジェクトのリソースとして、人が必要なのではありません。プロジェクトのアウトプットを期日までに完成できる技術を持っているリソースが必要なのです。


制約条件は、アウトプットを要求仕様に応じて実現することです。さらに、期限が制約条件として付されます。
前提条件は、技術仕様と範囲の中でアウトプットを実現することです。


技術仕様では、適用する技術が示されます。これによりプロジェクトに必要なスキルセットが明示的になりますから、プロジェクトチームは、技術仕様で自ら要求するスキルによりチーミングされることになります。


技術仕様の実現には、スキルのリソースは何であるかは問う必要はありません。前提条件のコスト計画の内輪であれば。スキルの実現は機械でも人でもかまわないのです。


これを踏まえると、

「プロジェクトに人が必要」ではなく「プロジェクトにスキルを有するリソースが必要」


なのです。それを取り違えて、頭数だけで揃えるから…(以下略。


あの日参画したメンバのスキル領域とレベルをまだ僕達は知らない。
あたりを引いたらいいのですが、ハズレを引いたらプロジェクトは大変です。何のあたり、ハズレかって。それはメンバのスキルです。


ふと思ったのですが、スキルの範囲とレベルを明示的に要求して参画するメンバを選定しているプロジェクトはどのくらいあるのでしょうか。現実の話として「ダイジョウブカナー」って心配になるチーミングをするプロジェクトを見るとそう思っても自然というか。


スキル範囲とレベルがフィットしても、人間性でメンバと関係性を作れないとこれはこれでつらいですし。


でも、やっぱりプロジェクトに参画して、割り振られたロールに対する責務をアウトプットで返してくれないと一番堪えます。使ってしまった時間と予算は取り戻せないですから。