プロジェクトの資源管理：要員計画とチームアサインを「空いてる人ベース」から「スキルベース」へ変える実務手順

「手が空いている人」に振ると、なぜ手戻りが起きるか

週次のアサイン会議で最初に聞かれるのは、たいてい「来週、誰が空いていますか」です。手が空いている人に次の作業を割り振る。一見合理的なこの進め方が、レビューでの大量の指摘、担当者の学び直しの時間、結局は後ろにずれるスケジュールの原因になっているケースは珍しくありません。空いているかどうかは稼働率の問題であって、その作業をやり切れるかどうかとは別の軸です。

PMIの枠組みでリソースと呼ぶのは、プロジェクトに投入する人・モノ・費用など資源全般です。資源管理が扱うのは、必要な資源の種類と量を見積もり、調達し、チームとして機能させ、稼働を統制するという一連の営みで、要員計画とチームアサインはその中核にあります。稼働率だけを見て割り当てる運用は、この一連の営みのうち「調達」の一部しか見ていません。

2025年11月に英語版が公開されたPMBOK第8版では、「リソース」が独立したパフォーマンス領域として立てられています。7つの領域はガバナンス、スコープ、スケジュール、ファイナンス、ステークホルダー、リソース、リスクです。第7版までの8領域に「リソース」という名称の領域はなく、資源配置に関わる観点は「チーム」領域を中心に分散していました。第8版では、人だけでなく設備・資材まで含む資源全体が、スケジュールやスコープと並ぶ独立した管理対象として扱われています（第8版の全体像はPMBOK第8版の変更点にまとめています）。

以下では、WBSで洗い出した作業に必要なスキルを言語化し、スキルマトリクスで保有スキルを数値化し、RACIで実行責任者を1人に絞り、資源ヒストグラムで過剰配分を検知し、レベリングかスムージングで調整する、という順で手順を組み立てます。「誰が空いているか」は、この手順の最後に効かせる条件の1つに位置づけ直します。

出発点はWBS：作業ごとに必要なスキルを言語化する

手順の起点は、WBSで洗い出したワークパッケージです。WBSの作り方は別記事で扱っていますが、資源管理の観点で1つ問いを足す必要があります。「この作業は誰にでもできるか、それとも経験を持つ人でなければ品質が保てないか」です。この問いに答えないまま「誰が空いているか」だけで埋めていくと、専門性が要る作業に経験の浅い担当者が就き、レビューで差し戻される、という流れが起きます。

この問いを体系立てて扱う道具が、資源分解構成図（Resource Breakdown Structure、RBS）です。プロジェクトに必要な資源（人員・設備・資材など）を、資源のカテゴリを最上位に置き、部門やチーム、役割、個々の資源という順に階層化して整理します。WBSが「何を作るか」という作業を軸に分解するのに対し、RBSは「何を投入するか」という資源を軸に分解する点が異なります。人員のRBSでは、部門・チームの下に職種、さらにその下にスキルセットという形で掘り下げると、実務での運用がしやすくなります。

実務でRBSを作る効用は2つあります。第1に、WBSの各ワークパッケージに必要な資源をRBSの階層と突き合わせることで、「このスキルを持つ人が組織のどこにいるか」を機械的にたどれるようになります。第2に、特定のスキルセットに需要が偏っていることが、RBSを作った時点で見えます。1つの枝に必要な作業が集中していれば、その枝のスキルを持つ人員が不足するリスクを、実際に割り当てる前の段階で把握できます。

スキルマトリクスで「保有スキル」を数値にする

RBSで資源の種類を体系立てたら、次はチームメンバー個々の保有スキルを数値化します。使う道具がスキルマトリクス（コンピテンシーマトリクス）です。行にメンバー、列に必要なスキル項目を並べ、各セルに習熟度を記入した表で、「誰が何をどこまでできるか」を1枚で見渡せる状態にします。

作成手順は4段階です。第1に、関係者と一緒に、プロジェクトに必要な中核スキルを洗い出します。技術スキルだけでなく、交渉力や合意形成力といったソフトスキルも対象に含めます。第2に、各メンバーの現状の習熟度を評価します。本人による自己評価とマネージャーによる評価を両方取ると、認識のズレが可視化されて精度が上がります。第3に、そのスキルへの本人の意欲も別の軸で記録します。習熟度が高くても意欲が低い仕事に配置し続けると、離職や生産性低下につながるためです。第4に、ギャップが大きい箇所を特定し、育成計画や採用計画に反映します。

評価尺度は「得意」「普通」「苦手」のような曖昧な言葉ではなく、全員が同じ基準で読める数値の尺度にします。0を「経験・知識なし」、4を「卓越した経験・知識」とする5段階評価はその一例です。尺度が曖昧だと、同じ「3」でも人によって指す実力が違い、マトリクスの信頼性そのものが崩れます。

作って終わりにしないことも同じくらい重要です。チーム構成や要件が大きく変わったタイミングで見直さないと、マトリクスは古い自己申告のまま放置され、実態とずれた割り当て判断の根拠になってしまいます。更新の周期を固定の月数で決め打ちにするより、フェーズ移行や体制変更などプロジェクトの節目に合わせて棚卸しする運用のほうが、実際に続きやすいでしょう。

RACIで実行責任者を1人に絞る

スキルマトリクスで「誰が何をどこまでできるか」が見えたら、ワークパッケージごとに役割を割り当てます。ここで使うのがRACIチャートです。作業への関与を、実行するResponsible、最終的な説明責任を負うAccountable、意見を求められるConsulted、結果を知らされるInformedの4種類に分けて整理します。

RACIの実務上の要点は、1つの作業に対してAccountableは必ず1人だけに絞ることです。Accountableを複数人に置くと、問題が起きたときに誰も最終判断をせず、責任の所在が宙に浮きます。ResponsibleとAccountableは兼務してもよく、多くの現場では担当者がResponsibleを、その上長やPMがAccountableを務めます。

ここでスキルマトリクスが効いてきます。Responsibleを決めるとき、稼働状況だけでなく、そのワークパッケージに必要なスキルのマトリクス上の評価点を突き合わせます。最も稼働が空いている人からではなく、必要なスキル項目で一定水準に達している人の中から、稼働状況で絞り込む順番に変えるだけで、割り当ての質は変わります。該当スキルを持つ人が稼働の都合で担当できない場合は、その人をConsultedに置き、実行はスキルの低いメンバーが担いながらレビューを受ける、という設計もRACIの中で表現できます。

ステークホルダー管理でもRACIは使われますが、そこでの用途はステークホルダーとの関与密度を決めることです。資源管理での用途は、実行そのものの担い手を決めることにあります。同じ表の形式でも、埋める対象が違う点は区別しておいてください。

資源ヒストグラムで過剰配分を可視化する

RACIで個々の作業の担当が決まると、次に起きる問題は、1人のメンバーに複数のワークパッケージが同時期に積み上がることです。個々の割り当ては妥当でも、合算すると稼働の上限を超えている、という状態は、表形式のRACIだけでは気づけません。ここで使うのが資源ヒストグラムです。

横軸に期間、縦軸に必要人数または工数を取り、メンバーやスキル種別ごとに積み上げ棒グラフとして表示します。ある期間の棒が稼働の上限（たとえば1人あたり1.0人日）を超えていれば過剰配分、逆に低い水準が続いていれば配置が薄いことが視覚的に分かります。

作成・更新の頻度は、固定の周期を決め打ちにするより、週次や隔週の進捗会議のタイミングに合わせるほうが運用が続きやすくなります。頻度を上げすぎると作成そのものが負担になり、更新されないヒストグラムが放置される結果になりがちです。

ヒストグラムの価値は、問題が起きる前に見えることです。稼働が積み上がっている状態に気づかないまま進行すると、担当者は複数の締切に同時に追われ、結局はどれかの品質かスケジュールを犠牲にします。週次の進捗会議でヒストグラムを都度確認する運用にしておくと、過剰配分は割り当ての初期段階で発見できます。

レベリングとスムージング：スケジュールを動かすか、動かさないか

資源ヒストグラムで過剰配分が見つかったら、調整の技法は2つあります。リソース平準化（レベリング）とリソーススムージングです。どちらも過剰配分を解消する点は同じですが、クリティカルパスへの影響が異なります。

レベリングは、フロートが残っている作業だけでなく、必要ならクリティカルパス上の作業の開始時期も動かして過剰配分を解消します。そのぶんプロジェクトの完了日が後ろにずれる可能性があります。資源の制約が納期の制約より優先される場面、つまり「この人数でしか回せない」という事情がある場合に使う技法です。

スムージングは、フロートの範囲内でしか作業を動かしません。クリティカルパスには一切手を触れないため、完了日は変わりません。ただしフロートの範囲でしか調整できないので、過剰配分を完全には解消できないことがあります。納期が固定されている場面、つまり「この日までに終わらせる」という制約が資源の制約より優先される場合に使う技法です。

スムージングは、PMBOKガイド第5版で、レベリングと並ぶ資源最適化技法（Resource Optimization Techniques）の1つとして位置づけられました。レベリングだけを知っていて、フロートの範囲内での柔軟な調整という選択肢を持たないと、納期を守れる場面でも安易にスケジュールを動かしてしまいます。過剰配分が見つかったら、まず「納期は動かせるか」を確認し、動かせないならスムージングの範囲で収まるかを検討し、収まらなければレベリングでクリティカルパスの変更を関係者と合意する、という順に検討してください。

「空いてる人ベース」から「スキルベース」に変える実務手順

ここまでの道具を、割り当ての現場で使える順番に並べ直します。個々の技法は単独でも使えますが、WBSからスキルマトリクス、RACI、ヒストグラム、レベリング／スムージングまでを1つの流れとしてつなぐと、「誰が空いているか」ではなく「誰のどのスキルを、どれだけの負荷でいつ使うか」という設計に置き換わります。

アサインが崩れる5つのパターン

第1は、稼働の空きだけで割り当てを決めることです。スキルマトリクスを作らずに「今週空いている人」で埋め続けると、専門性が要る作業ほど経験の浅い担当者に当たりやすくなり、レビューでの差し戻しが常態化します。

第2は、スキルマトリクスを作ったきり更新しないことです。古い自己申告のまま運用を続けると、育成で伸びたスキルも異動で抜けた穴も反映されず、割り当て判断の根拠として機能しなくなります。

第3は、RACIのAccountableを複数人に置くことです。「みんなで見る」という体制は聞こえがよくても、実際に問題が起きたときは誰も最終判断をせず、対応が遅れます。

第4は、資源ヒストグラムを作らず、個々の割り当てだけを見て安心することです。1人あたりの割り当ては妥当でも、合算すると稼働の上限を超えているケースは、表形式のRACIだけでは見つかりません。

第5は、レベリングとスムージングを区別せず、過剰配分が見つかるたびにクリティカルパス上の作業を安易に後ろ倒しにすることです。納期が動いてよいかを確認しないまま調整すると、後になって完了日が延びていたことに気づく事態を招きます。

要員計画とチームアサインは、空いている人に作業を当てはめる作業ではなく、必要なスキルを言語化し、保有スキルと突き合わせ、責任の所在を1人に絞り、稼働の合算を可視化するという一連の設計です。WBSで作業を洗い出し、スケジュールを引き、進捗を管理する体制を整えたあとに残る「誰にやらせるか」という問いに、ここまでの手順が答えを与えます。