プロジェクトの振り返りで「どの工程に一番時間がかかったか」を数字で答えられるでしょうか。
「設計が少し長引いた気がする」「テストで想定外の修正が出た」——感覚はあっても、記録がなければ残るのは記憶だけで、記憶は時間とともに都合よく書き換わります。「思ったより大変だった」は残っても、「設計は見積もりの1.8倍かかった」は記録なしには残りません。
これを数字で言えるようにするには、分析手法ではなく記録の構造が要ります、という話です。
工程ラベルだけでも「合計」は出る。ただし罠がある
先に誤解を解いておくと、工程別の工数を出すだけなら階層構造は不要です。作業時間に「これは設計」「これは実装」とラベルを付ければ、タグやプロジェクト分けの代用でも工程ごとの合計は出せます。
ただ、工程をひとつの大きな塊として計測すると、出てくる数字は思ったほど当てになりません。理由は3つ。
1. 大きな単位ほど計測を取りこぼす
「設計フェーズ」という大きなタイマーを回しっぱなしにする方式は、中断・別案件への移動・打ち合わせといった切れ目で押し忘れ・付け替え忘れが起きます。計測されていない時間が積み上がり、合計は実態より小さく出ます。計測単位を「ワイヤーフレーム作成」「画面設計レビュー」のようなタスクまで落とすと、タイマーの単位と作業の単位が一致して、記録のヌケが自然と減ります。
2. どの工程に入れるかが曖昧になる
「設計」とひと括りにすると、レビュー対応・仕様変更の反映・クライアントとのやり取りのような工程をまたぎがちな作業が、どこに計上されたのか分からなくなります。タスクに分けておけば帰属が記録の時点で確定するので、後から「この時間、本当に設計だったか？」と疑わずに済みます。
3. 「なぜ長引いたか」が残らない
フェーズ合計で分かるのは「設計が1.6倍かかった」まで。タスクまで割れていれば「WFの作り直しが2回発生した」「レビュー対応だけで設計の4割を占めた」という中身が残ります。原因の分からない数字は、振り返りでも見積もり補正でも使いどころが限られます。
分解と集計のトレードオフを解くのが「階層」
タスクまで分解すると今度は「フェーズ全体で何時間か」を出す集計の手間が増えます。ここを解くのが階層構造で、タスク単位で測った時間が属する成果物・フェーズへ自動で合算される仕組みがあれば、分解の細かさと集計の手軽さを同時に取れます。フェーズ→成果物→タスクの階層が効くのは、この一点です。
記録するときの構造が、後から見えるものを決めます。
数字で言えるようになると何が変わるか
- 工程別の乖離が見える: 「設計: 見積20h・実績32h（160%）」「実装: 見積50h・実績48h（96%）」→「自分は設計の見積もりが甘い」が数字になる。次から「設計は1.5倍見ておく」という根拠ある補正ができます。
- 案件をまたいだ比率が持てる: 「設計は実装のだいたいX割」という自分の傾向が、新しい案件の見積もりの参照先になります。
- 遅延を早期に察知できる: 「設計フェーズで予算の80%を消化、まだフェーズが終わっていない」がリアルタイムで見える。終盤の発覚が、途中の予測に変わります。
- 報告の質が変わる: 「設計で仕様変更が多く、見積もりの1.5倍かかりました。記録上、レビュー対応が通常の2倍です」という説明は記録がないとできません。「長引いた気がします」との差は大きい。
まとめ
感覚で語る工数管理から数字で語る工数管理へ移るのに必要なのは、立派な分析手法ではなく記録の構造です。チェックポイントは3つだけ——階層で記録できるか、上位へ自動集計されるか、見積もりと実績を並べられるか。
ただし、数字が出れば仕事がうまくいくというほど単純でもなく、出た数字を次にどう使うかは結局こちら側の判断です。そこは私も毎回うまくやれているわけではありません。
この記事は自分のブログ記事をQiita向けに再構成したものです。詳しい版はこちら → 「どの工程に時間がかかっているか」を数字で語るための工数管理