「どの工程に時間がかかっているか」を数字で語るための工数管理
プロジェクトが終わったあとのレビューで、「どの工程に一番時間がかかったか」を正確に答えられる人はどのくらいいるでしょうか。
「設計フェーズが少し長引いた気がする」「テストで想定外の修正が出た」——こういった感覚はあっても、数字で答えられる状態にするには、記録の構造が必要です。
感覚で語る工数管理から、数字で語る工数管理に変えることで、見積もり精度の改善・状況の説明・チームへの共有が変わります。この記事では、その変化を作るための考え方を整理します。
「感覚で語る」から「数字で語る」への移行
工数管理をしていない、またはプロジェクト合計しか記録していない状態では、「どの工程で何時間かかったか」という問いに答えられません。
このとき、残る情報は「記憶」だけです。記憶は時間とともに薄れ、都合よく書き換えられます。「思ったより大変だった」という印象は残っても、「設計フェーズで見積もりの1.8倍かかった」という事実は記録なしには残りません。
数字で語れるようになるための第一歩は、「工程別に記録が分かれている状態を作ること」です。
工程別に集計できる記録の作り方
まず誤解を解いておくと、工程別の工数を出すこと自体は、立派な階層構造がなくても可能です。極端に言えば、作業時間を記録するときに「これは設計」「これは実装」と工程のラベルさえ付けられれば、工程ごとの合計は出せます。タグやプロジェクト分けで代用している人も多いはずで、それでも「設計に何時間使ったか」は集計できます。
ただ、ここに感覚的な落とし穴があります。工程をひとつの大きな塊として計測すると、出てくる数字は思ったほど当てになりません。 理由は主に3つです。
1. 大きな単位ほど計測を取りこぼす
「設計フェーズ」という大きなタイマーを回しっぱなしにする方式は、作業の切れ目——中断、別案件への移動、打ち合わせ——でタイマーの押し忘れ・付け替え忘れが起きやすくなります。気づけば計測していない時間が積み上がり、合計は実態より小さく出ます。一方、計測の単位を「ワイヤーフレーム作成」「画面設計レビュー」のようなタスクまで落とすと、タイマーの単位と作業の単位が一致するので、自然と記録のヌケが減ります。
2. どの工程に入れるか、が曖昧になる
「設計」とひと括りにすると、レビュー対応・仕様変更の反映・クライアントとのやり取りといった、工程をまたぎがちな作業がどこに計上されたのか分からなくなります。タスクに分けておけば、「クライアントレビュー対応＝設計フェーズのタスク」と記録の時点で帰属が確定するので、あとから数字を見たときに「この時間、本当に設計だったか？」と疑わずに済みます。
3. 「なぜ長引いたか」まで残る
フェーズ合計だけ見ても、分かるのは「設計が見積もりの1.6倍かかった」というところまでです。タスクまで割れていれば、「ワイヤーフレームの作り直しが2回発生していた」「レビュー対応だけで設計全体の4割を占めていた」という中身まで残ります。これは集計の前提というより、出てきた数字を次の行動に変えるための「解像度」の問題です。原因が分からない数字は、振り返りでも見積もり補正でも使いどころが限られます。
つまり——工程別の数字を「出す」だけなら、工程ラベルで足ります。ですが、その数字を信頼でき・説明でき・次の見積もりに使えるものにしたいなら、タスクまで分解して計測したほうが結果的に近道になります。
問題は、分解を細かくするほど「フェーズ全体で何時間か」を出す集計の手間が増えることです。ここを解くのが階層構造です。タスク単位で測った時間が、属する成果物・フェーズへ自動で合算される仕組みがあれば、「分解の細かさ」と「集計の手間のなさ」を同時に取れます。フェーズ→成果物→タスクの階層が効いてくるのは、まさにこの一点です。「記録するときの構造」が、「後から見えるもの」を決めます。
工程別の工数比較が生む発見
工程別に工数が集計できるようになると、以下のような発見が生まれます。
見積もりとの乖離が工程別に見える
「設計フェーズ：見積もり20時間・実績32時間（160%）」「実装フェーズ：見積もり50時間・実績48時間（96%）」という比較ができると、「自分は設計の見積もりが甘い」という傾向が数字として見えてきます。
この傾向を知っていれば、次の見積もりで設計フェーズを意識的に厚く見積もる補正ができます。感覚で「多めに見ておこう」とするより、「前回の実績から設計は見積もりの1.5倍見ておく」という根拠ある調整になります。
プロジェクトをまたいだ比較ができる
複数のプロジェクトで工程別の実績が記録されていると、「設計フェーズにかける工数は実装フェーズの大体X割前後」という自分の傾向が見えます。新しいプロジェクトの見積もりを作るとき、この比率が参照先になります。
早期に遅延を察知できる
フェーズが進行中に工数消化率を確認できると、「設計フェーズで予算の80%を使い切った、まだフェーズが終わっていない」という状況をリアルタイムで把握できます。プロジェクト終盤まで待つのではなく、フェーズの途中で問題に気づけます。
「どこで時間がかかったか」を伝えられることの価値
クライアントや上長への報告において、「どの工程に時間がかかったか」を数字で説明できることは、信頼につながります。
「設計フェーズで、当初の想定より仕様の変更点が多く発生し、見積もりの1.5倍の工数がかかりました。記録によると、クライアントレビューへの対応に通常の2倍の工数が発生しています」
という説明は、記録がなければできません。感覚で「長引いた気がします」と説明するより、根拠がある分、対話の質が変わります。
また、チームの状況共有にも使えます。「設計フェーズの工数消化率が78%です。このフェーズに割り当てた予算の残りは22%（約5時間）です」という伝え方は、「設計が順調に進んでいます」より具体的で、メンバーが次の行動を判断しやすい情報です。
工数管理ツールに求める機能
工程別の工数を「数字で語れる状態」にするためには、工数管理ツールにいくつかの機能が必要です。
階層構造での記録：タスクの上位にフェーズ・成果物の層がある。工程ラベルを付けるだけでも集計はできますが、タスクまで細かく分解しながら工程別に自動集計するには、この階層があると無理がありません。
上位への自動集計：タスクの時間がフェーズ・プロジェクト単位で自動的に合算される。手動で集計する必要がある状態では、継続的に確認する手間が大きくなります。
見積もり vs 実績の比較：フェーズ・タスクごとに見積もり時間を設定し、実績と差分を確認できる。「乖離がある」という事実を可視化するために必要な機能です。
これらが揃っていると、「どの工程に時間がかかったか」を都度集計せずに確認できるようになります。
記録の構造が「次の見積もり」を変える
工程別の工数記録を続けると、プロジェクトを重ねるごとに「自分の仕事のパターン」が見えてきます。
「デザインフェーズは毎回見積もりを超える」「テストフェーズは逆に余る」「外部APIが絡む案件はイレギュラー対応で10〜15時間余計にかかる」——こういった傾向が数字として積み上がると、次の見積もりの補正材料が増えていきます。
経験が「感覚」として蓄積されるのではなく、「データ」として残る。その違いが、見積もり精度の改善に直結します。
結局、効くのは「記録の構造」のほう
ここまでをひとことにまとめると、感覚で語る工数管理から数字で語る工数管理へ移るのに必要なのは、立派な分析手法ではなく記録の構造だ、という話です。フェーズ→成果物→タスクの階層で記録されていれば、工程別の比較が後から取り出せて、見積もりの補正も遅延の早期発見も状況説明も、そこから自然に派生します。ツールを選ぶときに見るべきも結局そこ——階層で記録できるか、上位へ自動集計されるか、見積もりと実績を並べられるか、の三点に尽きます。
「どの工程に時間がかかったか」を数字で言えると、報告でも振り返りでも話が早くなります。ただ、数字が出れば仕事がうまくいくというほど単純でもなくて、出た数字を次にどう使うかは結局こちら側の判断で、ここは私も毎回うまくやれているわけではありません。
関連記事
本記事で取り上げた「工程別の工数可視化」は、LayerClock でも対応しています。 4階層WBS（プロジェクト・フェーズ・成果物・タスク）でタスクの実績が上位層に自動集計され、フェーズ別の消化率をリアルタイムで確認できます。見積もり vs 実績の差分も自動で算出されます。無料から試すことができます。