【公式】TimeTracker NX Blog

「配員計画」ちゃんと”計画”になっていますか?   —Excelと勘と根性から卒業するためのセルフチェック

作成者: TimeTracker NX カスタマーサポート|Dec 19, 2025 2:38:51 AM

「配員計画って、ちゃんとやっていますか?」
と聞かれて、即答できる会社は意外と多くありません。

  • とりあえずプロジェクト計画(WBS)を作っている

  • なんとなく“この人が空いているから”で割り当てている

  • Excelで各チームがそれぞれ配員表を持っている

どれも現場では“あるある”ですが、
冷静に見ると「配員“計画”」というよりは「配員“対応”」になっているケースがほとんどです。

この記事では、配員計画をテーマに

  1. ありがちな3つのタイプ

  2. そこから生まれる“3つの壁”

  3. 自社がいまどこにいるかのセルフチェック

  4. これから配員計画を見直すときのポイント

を整理します。
TimeTracker NXなどの工数管理ツールをお使いの方はもちろん、
「配員計画ってそもそも何から考えればいいの?」という方にも、
自社の“いまの立ち位置”を確認するヒントになれば幸いです。

1. あなたの会社はどのタイプ?配員計画の「3つの状態」

まずは、部長クラス・PMO・現場PMにぜひ問いかけてほしい3つの質問があります。

タイプ①:そもそも配員計画をしていない層

キラー質問:
「配員計画って、ちゃんとやっていますか?
それとも、いきなりプロジェクト計画に落とし込んでいますか?」

典型的な状態はこんな感じです。

  • いきなりWBS/ガントチャートを作り始める

  • 「この人、今あいてる?」でアサインが決まる

  • リソース配分は、管理職の“頭の中”とミーティングだけで決まる

一見まわっているように見えても、

  • 忙しい人に仕事が集中する

  • プロジェクトが増えた途端に破綻する

  • 「誰が何%ぐらい埋まっているか」が誰にも説明できない

という“じわじわ型のリスク”を抱えています。

タイプ②:配員計画はあるが「Excelが火を噴いている」層

キラー質問:
「配員計画、うまく回っていますか?
Excelが壊れたり、どれが最新版かわからなくなったりしていませんか?」

多くの現場がここに当てはまります。

  • チームごと/部門ごとにExcel配員表がある

  • 担当者しか式が理解できない

  • 列・行を少し変えただけで式が崩壊する

  • 「最終版_最新_ver3_final.xlsx」がフォルダ内に並ぶ

この状態の“怖さ”は、

  • Excelが壊れた瞬間に、配員の“全体像”も壊れること

  • 計画の履歴(いつ・どのタイミングでどう変えたか)が残らないこと

です。

タイプ③:計画はきれい…でも「実績と結びついていない」層

キラー質問:
「配員計画はうまくできているようですが、
計画と実績の比較を、どのくらい定期的に見ていますか?」

この層は、一見“優等生”に見えます。

  • 配員表はきれいに整っている

  • プロジェクト開始前に、それなりの精度で計画が作れている

  • レビュー会議でも「とりあえず計画」は説明できる

ただし、よく聞くとこういう状況になりがちです。

  • 実績が別システム・別ファイルにあり、簡単に突き合わせできない

  • 「当初計画 vs 現在の配員」を定点観測していない

  • 気づいたら、計画と現実のギャップが“見なかったこと”になっている

結果として、**「計画が独り歩きしている」**状態になります。

2. 多くの会社を悩ませる「3つの壁」

上の3タイプからは、共通する“3つの壁”が見えてきます。

壁①:Excelが壊れる

  • 行・列が増えるたびに式の参照が崩れる

  • 担当者が異動・退職すると、誰も修正できなくなる

  • マクロや複雑な関数に依存していて、ブラックボックス化する

結果:

  • 「このExcelがなければ配員ができない」という属人化

  • 少し構成を変えたいだけなのに、怖くて触れない

壁②:ベースライン(節目の計画)が残らない

  • 計画を上書きしてしまい、「当初案」が消える

  • 月単位・四半期単位での“計画FIX”がどこにも残っていない

  • 「あのとき何を前提にしていたか」を検証できない

結果:

  • 「当初の読みが甘かったのか」「途中で何が起きたのか」がわからない

  • プロジェクトが終わるたびに、学びが残らず、毎回“ぶっつけ本番”

壁③:計画が独り歩きし、実績と結びつかない

  • 計画は作ったが、実績との比較は“年に数回のレビューだけ”

  • 実績は工数管理ツールや勤怠で取っているが、配員表との関係が見えない

  • 経営会議では「なんとなくの感覚」で議論してしまう

結果:

  • 計画が「作ることが目的」になり、意思決定に活かされない

  • 赤字プロジェクトや人員逼迫に、後から気づく

3. 自社の「現在地」をざっくり診断してみる

いまの話を踏まえて、簡単なセルフチェックを用意しました。
「はい/いいえ」で答えてみてください。

  1. プロジェクト開始前に「誰を・いつ・どの業務に割り当てるか」を一覧で説明できる

  2. 配員の一覧は、Excelではなく全員が同じ画面・同じデータで参照できる

  3. 配員計画の「当初案」「見直し版」を、節目ごとに保存して比較できる

  4. 配員計画と、工数実績(TimeTracker など)のデータを同じ粒度で照合できる

  5. 「この配員計画で、この案件は黒字になるか?」を、開始前におおよそ判断している

「いいえ」が多いほど、

  • タイプ① or ②(やっていない/Excelで苦しんでいる)

  • 壁①〜③のどれか

にはまっている可能性が高い状態です。

4. 配員計画を見直すときの4つのポイント

では、ここからどう配員計画を見直していけばよいのか。
現場でよく使う視点を4つに絞って整理します。

① 「Whoの計画」をちゃんと切り出す

  • プロジェクト計画(What/When)とは別に、
    「Who(誰が・いつ・どのくらい)」の計画を一段手前で考える

  • 「空いている人を埋める」ではなく、
    役割・スキル・育成も含めた配員方針を明文化する

② Excelから「システム+ルール」への移行を検討する

  • いきなりすべてをやめる必要はありませんが、

    • 部門単位

    • 重要プロジェクト単位
      など、リスクの高い領域からExcel依存を減らすのがおすすめです。

  • ポイントは、

    • 配員情報を一元管理できること

    • 「誰が・いつ・どの案件に」という情報を、同じ画面で俯瞰できること

TimeTrackerのような工数管理ツールや、
配員計画に対応したシステムを組み合わせることで、
Excelの依存や属人化のリスクを減らせます。

③ ベースライン(計画の節目)を決める

  • 年度開始/四半期開始/大型案件のキックオフなど、
    **「ここで一度計画を確定する」タイミング(ベースライン)**を決めておく

  • ベースラインごとに、

    • 当初計画

    • 見直し後の計画

    • 実績
      を比較できるようにしておくことで、
      **「どこで読み違えたのか」「どこでリカバリできたのか」**が見えるようになります。

④ 計画と実績を“同じ粒度”で比べる

  • せっかくTimeTracker NXなどで工数実績が取れていても、
    配員計画と粒度がずれていると比較ができません。

  • たとえば、

    • 配員:人月/月単位

    • 実績:時間/日単位

だと、厳密な予実管理や分析が難しくなります。

  • 可能であれば、

    • 「人月/月」 or 「時間/月」など、
      計画と実績の単位・粒度を揃えることを意識してみてください。

5. まとめ:まずは「うちはどのタイプか?」を言語化する

この記事のポイントを改めて整理すると、次のようになります。

  • 多くの会社は、

    1. 配員計画をそもそもやっていない

    2. Excelでなんとかしているが壊れがち

    3. 計画はきれいだが、実績と結びつかない

    のどこかに当てはまる

  • そこには

    • Excelが壊れる

    • ベースラインが残らない

    • 計画が独り歩きする
      という3つの“壁”がある

  • 配員計画を見直す第一歩は、

    • 「うちはどのタイプか?」

    • 「どの壁に一番苦しんでいるか?」
      言葉にしてみること

  • そのうえで、

    • Who(配員)の計画を切り出す

    • Excelから一部でもシステム化を進める

    • ベースラインを決めて保存する

    • 計画と実績の粒度を揃える

    といった小さな改善から始めるのが現実的です。

「配員計画、ちゃんとやっていますか?」
この問いを、ぜひ社内で一度投げかけてみてください。

次のステップとして、

  • 自社の配員計画タイプをもう少し詳しく診断するチェックリスト

  • 配員計画と工数管理(TimeTracker RXなど)を連携させる考え方

なども整理していければと思います。

この記事が、その最初の一歩になればうれしいです。