PMOが直面する工数管理のリアル

プロジェクトの進捗会議で「今月の工数は問題ありません」という報告を受けたとき、PMOとして本当にそれを信じられるでしょうか。私は信じません。なぜなら、10年以上PMOとして様々なプロジェクトを見てきた中で、表面上は順調に見えるプロジェクトほど、メンバーの負荷が偏っていたり、突発タスクで本来の作業が圧迫されていたりするケースを数え切れないほど見てきたからです。
工数管理というと、多くの方は「各メンバーが何時間働いたか」を集計することだと思っています。確かにそれも工数管理の一部ですが、PMOとして本当に必要なのは「誰にどれだけの負荷がかかっているか」「今後どこにボトルネックが発生するか」を見抜くことなんですよね。そのために私が長年使ってきたのが「山積み表」という手法です。
山積み表とは、各メンバーの月別または週別の工数予定を積み上げて可視化する表のことです。縦軸にメンバー名、横軸に時間軸を取り、各メンバーがどのタスクにどれだけの工数を割り当てているかを積み上げグラフのように表現します。これにより、特定のメンバーに負荷が集中している状況や、時期によってリソースが逼迫する時期が一目で分かります。
しかし、この山積み表を正確に作成し、維持していくことが、現場では想像以上に難しいのです。
[EXPERIENCE: ここにTech-Tの実体験を300〜500字程度で入れる予定]
このように、工数管理の現場では様々な「見えない問題」が潜んでいます。特に中堅企業では、専任のPMOがいなかったり、PMO業務を兼務していたりするため、こうした問題がより深刻化します。Excelで山積み表を作っても、更新が追いつかず、気づいたときには実態と大きく乖離している。そんな経験をされた方も多いのではないでしょうか。
私がPMOとして最も重視しているのは、この「実態との乖離」をいかに小さく保つかということです。完璧な工数管理など存在しません。しかし、現実に近い状態を常に把握し続けることで、問題が大きくなる前に手を打つことができます。それがPMOの本質的な価値だと私は考えています。
山積み表が映し出す3つの隠れた負荷
山積み表を正しく運用すると、通常の進捗管理では見えない3つの「隠れた負荷」が見えてきます。
1つ目は、突発タスクによる計画外の負荷です。どんなプロジェクトでも、顧客からの急な仕様変更依頼、本番障害対応、他プロジェクトからのヘルプ要請といった突発タスクが発生します。これらは個別に見ると「今回だけ」「すぐ終わる」と判断されがちですが、山積み表で累積すると、メンバーの稼働時間の20〜30%を占めていることも珍しくありません。
2つ目は、特定メンバーへの依存による負荷の偏りです。「この人しかできない」という業務が存在すると、その人の山積み表は常に150%、200%といった数字になります。一方で他のメンバーは80%程度の稼働。これは組織全体の生産性を大きく損ないます。しかし、日々の進捗会議では「Aさんが忙しいのは仕方ない」で済まされてしまうことが多いのです。
3つ目は、見積もり精度の問題から生じる隠れた負荷です。経験の浅いメンバーは、自分のタスクを楽観的に見積もりがちです。「3日でできる」と報告していても、実際には1週間かかる。この乖離が積み重なると、プロジェクト後半で一気に負荷が顕在化します。山積み表を時系列で追っていくと、「計画では今月余裕があるはずなのに、実際はパンク寸前」という状況が可視化されます。
中小企業特有の工数管理の難しさ
特に中小企業では、大企業のように専用の工数管理システムを導入している例は少なく、ExcelやGoogleスプレッドシートで管理しているケースがほとんどです。私もそういった環境で何度もPMO業務を行ってきました。
中小企業の工数管理が難しい最大の理由は、「兼務の多さ」です。一人が複数のプロジェクトを掛け持ちしていたり、営業や保守といった定常業務も並行して行っていたりします。そうなると、山積み表に正確に入力すること自体が負担になります。「今週は何にどれだけ時間を使ったか」を振り返る時間すらない、というのが現実です。
また、メンバー数が少ない分、一人の負荷が増えた時の影響が大きくなります。10人のチームで一人が倒れても他でカバーできますが、3人のチームで一人が倒れたら、プロジェクトそのものが止まります。だからこそ、中小企業こそリソース管理を徹底すべきなのですが、現実にはそこに手が回らないというジレンマがあります。
なぜ工数管理は形骸化するのか
私が30年近くIT業界にいて、数え切れないほどのプロジェクトを見てきた中で、工数管理が形骸化するパターンには明確な共通点があります。それは「現場にとって価値がない」と思われてしまうことです。
多くの組織で、工数管理は「管理のための管理」になっています。毎週Excelに数字を入力させられるが、それが自分の仕事にどう役立つのか分からない。PMOや上司に報告するためだけの作業になっている。こうなると、メンバーは正確な数字を入れるモチベーションを失います。「適当に埋めておけばいいや」となり、データの精度はどんどん落ちていきます。
工数入力が「作業」になってしまう構造的な理由
工数管理が形骸化する根本原因は、フィードバックループの欠如です。メンバーが工数を入力しても、それが可視化され、改善につながるというプロセスが見えなければ、誰も真剣に入力しません。
私が見てきた失敗プロジェクトの多くは、PMOが工数データを集めるだけで、それを分析して現場にフィードバックしていませんでした。「先月の工数実績は○○時間でした」という報告はあっても、「だから来月はこうしましょう」という具体的なアクションがない。これではメンバーは「結局何のために入力しているのか」と疑問を持ちます。
また、工数管理ツールが現場の業務フローに合っていないことも大きな要因です。開発者は普段GitHubやJiraで作業しているのに、工数だけは別のExcelに入力しなければならない。これは二重管理であり、現場からすれば「無駄な作業」以外の何物でもありません。
見積もり精度が低いままになる理由
工数管理のもう一つの本質的な課題は、見積もり精度の問題です。特に経験の浅いメンバーは、タスクにかかる時間を過小評価しがちです。これは単に経験不足というだけでなく、心理的な要因も大きく関わっています。
「3日でできる」と言ってしまった手前、実際には5日かかっていても「まだできていません」と報告しづらい。結果として、ギリギリまで問題が表面化せず、締め切り直前になって「実は間に合いません」となります。私はこのパターンを何十回と見てきました。
また、見積もりの精度を上げるためのフィードバックが組織として機能していないことも問題です。「見積もりと実績がどれだけ乖離したか」を振り返り、次回の見積もり精度を上げるというサイクルが回っていない組織がほとんどです。PMOの役割の一つは、このサイクルを回すことなのですが、現実には「進捗管理」だけで手一杯になってしまいます。
山積み表が更新されない理由
山積み表は非常に有効なツールですが、維持していくのが大変です。私自身、Excelで山積み表を作成して運用していた時期がありましたが、正直に言って更新作業は苦痛でした。
メンバーが10人いれば、毎週10人分のタスクと工数を更新しなければなりません。新しいタスクが追加されれば、それを反映し、完了したタスクは削除する。突発タスクが入れば、それも追加する。この作業を毎週、あるいは毎日続けるのは、PMOにとって大きな負担です。
そして何より、Excelの山積み表は「静的」です。今日作成した山積み表は、明日にはもう古くなっています。プロジェクトは生き物であり、日々状況が変わります。その変化に追従し続けるためには、リアルタイムで更新できる仕組みが必要なのですが、従来のExcel管理ではそれが難しいのです。
現代のリソース管理ツールがもたらす変化
ここまで工数管理の難しさを語ってきましたが、現代のITツールは、私がExcelと格闘していた時代とは比較にならないほど進化しています。特にリソース管理に特化したツールの登場により、PMOの負担を大きく軽減しながら、精度の高い工数管理が可能になってきました。
私が現場で使うなら、また中小企業のPMOに勧めるとしたら、以下のようなツールを検討します。
Backlog:タスク管理と工数管理の一体化
Backlogは日本の企業が開発したプロジェクト管理ツールで、タスク管理と工数管理が自然に統合されている点が優れています。私がBacklogを評価するのは、「タスクを登録すれば自動的に工数が記録される」というシンプルな設計だからです。
開発者はBacklog上でタスクのステータスを更新し、実績工数を入力します。これがそのままプロジェクト全体の工数集計に反映されるため、二重入力の手間がありません。PMOとしては、Backlogのガントチャートや工数レポート機能を使えば、誰がどのタスクにどれだけ時間を使っているかがリアルタイムで把握できます。
山積み表に相当する機能もあり、メンバーごとの負荷状況を可視化できます。特に中小企業では、高額なプロジェクト管理ツールを導入するのはハードルが高いですが、Backlogは比較的手頃な価格で、かつ日本語のサポートも充実しているため、導入しやすいと思います。
Jira + Tempo Timesheets:開発現場との親和性
開発チームがすでにJiraを使っている場合、Tempo Timesheetsというプラグインを追加することで、強力な工数管理機能を得られます。私が30年の経験から見て、JiraとTempoの組み合わせは、開発プロジェクトの工数管理において最も現場に受け入れられやすい選択肢の一つです。
Tempoの優れている点は、開発者が普段使っているJiraのチケット上で、そのまま工数を入力できることです。GitHubと連携させれば、コミット情報から自動的に作業時間を推定する機能もあります。PMOとしては、Tempoのダッシュボードで各メンバーの稼働状況、プロジェクトごとの工数消化率、予算との乖離などを一目で確認できます。
ただし、JiraとTempoの組み合わせは機能が豊富な分、初期設定や運用ルールの整備に時間がかかります。中小企業で導入する場合は、最初はシンプルな使い方から始めて、徐々に機能を拡張していくアプローチが現実的です。
Microsoft Project for the web:エンタープライズからの降りてきたツール
Microsoft 365を既に導入している企業であれば、Project for the webも選択肢に入ります。従来のMicrosoft Projectはデスクトップ版で高機能すぎて扱いづらかったのですが、web版はクラウドベースで、よりシンプルに使えるようになっています。
私がこのツールを評価するのは、Teamsやプランナーといった他のMicrosoft 365アプリと連携できる点です。多くの中小企業ではTeamsを日常的に使っているため、そこから自然にプロジェクト管理や工数管理に移行できるのは大きなメリットです。
山積み表に相当する機能として、リソース管理ビューがあり、各メンバーのキャパシティと割り当てタスクを可視化できます。ただし、細かい工数集計や分析機能については、BacklogやJira+Tempoに比べるとやや弱い印象です。既にMicrosoft 365を使っている企業が、追加コストを抑えてプロジェクト管理を始めたい場合に向いています。
AI活用による工数予測の可能性
最近注目しているのは、AIを活用した工数予測機能です。まだ発展途上の分野ですが、過去のプロジェクトデータを学習させることで、新しいタスクの所要時間を予測する試みが進んでいます。
例えば、Jiraのプラグインの中には、過去の類似タスクの実績工数から、新規タスクの推定工数を自動提案するものがあります。完璧ではありませんが、経験の浅いメンバーが見積もりを行う際の参考値として有用です。私の経験から言えば、見積もり精度が20%向上するだけでも、プロジェクトのリスクは大きく減少します。
今後、AIによる工数予測はさらに進化し、「このメンバーにこのタスクを割り当てると、過去のパターンから見て遅延リスクが高い」といったアラートを出してくれるようになると期待しています。PMOとして、こうした技術の動向は常にウォッチしておく価値があります。
30年現場にいた私が思うこと
工数管理は、PMOの仕事の中で最も地味で、最も重要な業務です。華やかなプロジェクト立ち上げやステークホルダー調整に比べて、日々の工数データを追いかける作業は目立ちません。しかし、この地道な作業の積み重ねが、プロジェクトの成否を分けると私は確信しています。
30年近くこの業界にいて、成功したプロジェクトと失敗したプロジェクトの違いを振り返ると、技術力やメンバーの優秀さ以上に、「リソースを適切に管理できていたか」が大きな要因だったと感じます。どんなに優秀なエンジニアでも、過負荷が続けばパフォーマンスは落ちます。どんなに緻密な計画を立てても、実態を把握していなければ軌道修正できません。
山積み表という手法は、何十年も前からある古典的な手法です。しかし、その本質は今も変わっていません。「誰に、いつ、どれだけの負荷がかかるか」を可視化すること。これができているプロジェクトは強いです。問題が起きても早期に対処できるし、メンバーの疲弊を防げます。
中小企業だからこそできるリソース管理
中小企業の強みは、意思決定の速さと柔軟性です。大企業では、工数管理ツールを導入するだけで数ヶ月の稟議が必要だったりしますが、中小企業なら「来週から使ってみよう」と即座に決められます。
私が中小企業のPMOの方に伝えたいのは、完璧を目指さなくていいということです。最初から全メンバー、全タスクの工数を完璧に管理しようとすると、必ず挫折します。まずは「ボトルネックになりやすいメンバー」「クリティカルパスにあるタスク」だけを重点的に管理することから始めてください。
例えば、チームに一人だけしかできない業務を持っている人がいるなら、その人の山積み表だけでも作ってみる。毎週月曜日に、その人の今週の予定タスクと工数を確認し、キャパシティを超えていないかチェックする。たったこれだけでも、突然の欠員リスクや過負荷による品質低下を防ぐことができます。
ツールは手段、本質は対話
この記事では現代のリソース管理ツールをいくつか紹介しましたが、ツールを導入すれば全てが解決するわけではありません。私が30年の経験で学んだ最も重要なことは、「工数管理は人と人との対話である」ということです。
メンバーが工数を入力してくれるのは、PMOを信頼しているからです。「この人に正直に報告すれば、適切にサポートしてくれる」と思えるから、正確なデータを出してくれます。逆に、「工数を報告したら責められる」「数字だけ見て現場の状況を理解してくれない」と思われたら、どんなに優れたツールを導入しても、データの精度は上がりません。
私はPMOとして、毎週必ずメンバーと1on1で話す時間を作っています。工数データを見せながら、「今週は○○のタスクで予定より時間がかかっているけど、何か困っていることはある?」と聞きます。この対話の中で、ツールには現れない「隠れた負荷」が見えてきます。
明日から始められる小さな一歩
もしあなたが今、工数管理に悩んでいるなら、明日から次の3つのことを始めてみてください。
1つ目は、チームで最も負荷の高いメンバーを1人選び、その人の来週のタスクと予定工数を書き出すことです。Excelでもメモ帳でも構いません。月曜日に15分だけ時間を取って、その人と一緒に「今週何をするか」を確認してください。これが山積み表の原型になります。
2つ目は、週次の進捗会議で、必ず「今週突発で発生したタスク」を振り返ることです。計画にないタスクが週に何件発生し、それが誰の負荷になったかを記録します。1ヶ月続ければ、あなたのチームの「隠れた負荷」のパターンが見えてきます。
3つ目は、完了したタスクの見積もりと実績を比較する習慣をつけることです。「3日でできると思ったけど5日かかった」という事実を、責めるためではなく、次の見積もり精度を上げるために記録します。これを続けると、メンバー自身が見積もり上手になっていきます。
工数管理は、PMOの仕事の中で最も地味ですが、最もプロジェクトを守る力があります。私はこれからも現場でこの地道な作業を続けていきます。あなたも一緒に、一歩ずつ前に進みましょう。


コメント