#2-7　チームの構築ルールを決める

プロジェクトマネージャー（PM）として任命されたら、次はチームを構築するためのルールを決めます。
この分野は、突き詰めれば経営組織論まで深堀出来たり、奥の深い分野です。
ですが今回は、あくまでプロジェクトマネジメントの範囲で参考になるアイディアをご紹介していこうと思います。

「プロジェクト」とは、有期的であり、独自性のあるモノやサービスを開発する活動です。

そして、プロジェクトの目的に応じて、求められるスキルや人材が変わってきます。
例えば、同じ建築事業会社でも、商業施設とスポーツ施設の建築では、求められる能力やアウトプットが近いますよね。
お手洗いの設置場所、動線、適切な窓の数、守るべき建築基準法の規定……など、その道の経験者にリードしてもらった方が、効率よく物事を決めて進行することができます。
そこで、そういった「必要なスキルを持ったメンバーで構成する」など、チームを構成するためのルールづくりをします。

学校で言うと、校則ではなく、学校設立のための法律（学校教育法）の方です。

以前の記事で、プロジェクトマネジメントの教科書的な本『PM
 BOK』（ぴんぼっく）では、「チームの構成」について、計画プロセス以降は「資源」という知識エリアで扱われる、というお話をしました。
”資源”というのは、基本的に「ヒト」と「モノ」のことを指します。

プロジェクトマネジメントのプロセスマップ

【計画】×「資源」の知識エリア
　　・資源マネジメントの計画
　　・アクティビティ資源の見積もり

この「資源マネジメントの計画」がチーム構築のルールに関わるプロセスです。

資源マネジメント計画

資源マネジメント計画書

プロジェクト資源の獲得・アサイン・コントロールの方法や資源に関するスケジュールを記述した計画書です。
他には
　・プロジェクトメンバーの役割と責任
　・プロジェクト組織図
　・トレーニング方法
等が明記されています。

そもそもプロジェクトの活動では、「プロジェクトマネジメント計画書」という全体的な計画書も用意するのですが、「資源マネジメント計画書」はその一部です。

〇〇書

余談ですが、プロジェクトマネジメントの教科書的な本『PM BOK』では「〇〇書」という項目が非常に多く出てきます。状況を言語化して資料化する業務がPMには多いです。

状況を言語化することについては、「PMに必要なマインド」として以前言及しているので、ピンとこない場合は、下記記事も読んでいただけますと幸いです。

プロジェクトの目的によって、求められる専門スキルなどは変わってきますが、どのジャンルのプロジェクトのチーム構築のために必要とされる共通項があり、今回は代表的な2つを紹介します。

チーム構築ルールのポイント

①単一障害点を回避すること
ある作業をこなせる人を1人しか置かないと、その人がお休みしたりすると、全体の進行止まってしまうリスクがあります。
こういう、作業を実行するのに必須なスキルを持つ資源（ヒト）が一つしない部分を単一障害点と言います。
必要なスキルを持つヒトが単一しかないことで生まれる障害点を回避したチームの構成が大事です。

たまに、ノウハウや作業を抱え込んで自分しか作業できない状態を作って、仕事上の評価を得ようとする方がいますが、そういう方は本質的に仕事が出来ない方なので重視しない、というのが個人的な意見です。

「この人にしか任せられない」という評価は、ノウハウが流出した程度で変わるほど簡単に得られるものでもないです。
ただ、そういう抱え込むヒトが生まれないようにする仕組み作りもプロジェクトマネージャーの仕事なので、もしそういうヒトが存在していたら、（PMの自分が）反省すべき、と思っています。

②包括的なスペシャリストがいること
言い換えると、多能工なスペシャリストがいることが大事です。
多能工とは、一人で複数の業務や作業を行うことが出来るヒトや複数のスキルをもったヒトのことを言います。多能工の反対の言葉が、単能工。一つの作業のみ行うヒトのことを言います。

例えば、プログラムもＵＩ（※）デザインも出来る人がいたら、仕様のすり合わせなどで共有にかかる時間がカット出来たり、プログラミングとUIデザインのスケジュールを合わせて組むことで、全体としての生産性上げることが出来ます。また、２つの領域にまたがる問題が発生した時に、原因を特定するのが比較的早い傾向にあります。

※ＵＩ：ユーザーインターフェース。簡単に言うと「使い勝手の良さ」のコト。

単能工のスタッフのみで構成すると、マネジメントだけでもコストがかかり、PMの負担も必要な人数も多くなってしまいます。

③ゆとりを持つこと
ここでいう”ゆとり”は人数のことではなく、一人あたりの仕事量を100/100で考えずに、80/100程度に考えておく、という意味です。

基本的に、プロジェクトの活動は計画通り進みません。

それは、計画することに意味がない、ということではないです。
計画しても半分くらいしか想定通りにならないので、きちんとした計画がないプロジェクトの成功はほぼ不可能、ということです。

ある程度見通しを立てていても、ほとんど計画通りに進まないので、想定外のリソースの使用は不可避です。
計画段階とピッタリ一致するようなリソース総量しか確保していなければ、不足が生じます。ヒトに限らず、カネも、時間も。

ただ、計画時には、”何が”想定外の出費になるかまではわかりません。そのため、ピッタリではなく、バッファ（ゆとり）を設けておくことが大事です。

カネも時間も固定されたモノなので、物理的に不足していれば目に見えてわかります。

しかし、ヒトに関しては、稼働時間を延長したり、ランチの時間をなくしたり、無理矢理変動させることが出来ます。そのため、強制的な補填が行われやすくなります。

１人に100の業務を想定していて、アウトプットが足りなくなった時、120を課せば、なんとか乗り切れることもありますし、一時期な付加はある程度やむを得ません。

ただ、それが日常になってしまっていたら、破綻するまでそう時間はかかりません。

そういったことを想定して、最初からすべてのスタッフの仕事量を100/100で考えないことが大事です。

落ち着いている時期には、40/100や60/100の稼働で、空いた時間はコミュニケーションやトレーニングの時間に充てることで、問題が起こった時に素早く対処できる可能性も上げられます。

大事なのは、きちんとした成果物が生み出せるプロジェクトの活動が継続することです。