システム開発の工数管理が破綻する原因と立て直し方｜記録設計・予実管理・定着の手順

SEを抱えるIT企業でも社内の開発部門でも、システム開発の工数管理は、入力が止まったときではなく、入力は続いているのに数字で判断できなくなったときに破綻しています。予定と実績がいつも近い値で並び、遅れは月末の締めで初めて見え、仕様変更の追加分は元の計画の超過として埋もれる。こうした状態の入口は、記録の仕方と、仕様変更や遅れへの対応の癖にあります。

この記事では、破綻の典型パターンを入口に、作業コードと記録粒度の決め方、進行中の予実管理、仕様変更時の再見積り、アジャイル開発での時間記録の扱い、入力を定着させる運用までを、IPAのモデル契約やスクラムガイドの原文を根拠に整理します。工数の単位換算や見積り手法そのものは関連記事に譲り、記録した工数を判断に使える状態に保つことに絞ります。

まとめ：システム開発の工数管理を立て直す要点

• 破綻は記録の仕方から始まる。締め日前の一括入力、見積りと対応しない作業コード、仕様変更の未反映、人員追加での挽回、工数の個人評価への流用が典型。
• 作業コードは見積りのWBSと同じ階層で切り、間接作業と管理作業は別コードにする。記録単位は30分から始め、入力は当日中に締める。
• 予実の差は「遅れ」と「超過」に分けて読む。CPIは実績工数（AC）の未入力で過大に出る。SPIはACを使わず、予定値（PV）と出来高（EV）の更新に左右される。
• 仕様変更は工数の再見積りとセットで扱う。IPAのモデル契約第37条は、変更管理書に費用の額と変更作業のスケジュールを書くよう定めている。
• スクラムガイド2020は時間の記録もストーリーポイントも定めていない。受託開発で原価や請求に時間が要るなら、時間記録は別に持つ。
• 入力の定着は、必須項目の少なさと、集めた数字が週次で現場に返ってくるかで決まる。工数を個人評価に使うと数字が整えられる。

システム開発の工数管理が破綻する典型パターンと前兆

工数管理の破綻は、ツールの不具合より運用の癖から起きます。どれも入力率だけを見ていると気づけないので、前兆の見分け方と組にして押さえてください。

締め日前の一括入力で実績が予定に寄る状態

週末や月末にまとめて入力すると、何に何時間使ったかを記憶から組み立て直すことになります。思い出せない部分は予定の配分で埋められやすく、実績が予定に寄ります。結果として予実差が小さく見え、遅れの発見が締め日まで遅れます。

前兆の目安はあります。全員が毎日8.0時間ちょうどで、タスク別実績も予定とほぼ一致する場合は、入力日時や作業記録を照合し、予定値の転記や一括配分がないか確認してください。

見積りのWBSと作業コードがずれて予実を比べられない状態

見積りは「受注画面の詳細設計」「在庫引当バッチの実装」のようなWBS要素で積み上げたのに、工数は「設計」「開発」「打合せ」の粗い区分で記録している現場があります。この場合、どの作業が見積りを超えたのかを後から特定できません。予実管理の前提は、予定と実績が同じ単位で並ぶことです。WBSの切り方はWBSとは？作り方5ステップとガントチャートとの違いを具体例で解説で確認できます。

仕様変更が工数計画に反映されないまま進む状態

打合せで出た仕様変更を口頭で引き受け、元のタスクの中で対応すると、追加の作業時間はすべて元タスクの超過として記録されます。見積りが甘かったのか、範囲が増えたのかを区別できなくなり、追加費用の交渉材料も失われます。変更を別管理にする手順は後半の「仕様変更を変更管理書と再見積りで扱う手順」で扱います。

遅延を人員追加で取り返そうとする判断

遅れが見えた時点で要員を足すのは自然な判断に見えますが、フレデリック・ブルックスは1975年の『人月の神話』（原題 The Mythical Man-Month）第2章で、これを「ブルックスの法則」として “Adding manpower to a late software project makes it later.”（遅れているソフトウェアプロジェクトへの要員追加は、さらに遅らせる）と書いています。新しい人の立ち上がりと、引き継ぎ・調整の時間が既存メンバーの工数を食うためです。工数台帳の上では総工数が増えるのに出来高が増えない、という形で表れます。人月と工期の関係は人月とは？計算方法・人月単価の相場と発注者が見積もりの妥当性を見抜く方法で詳しく扱っています。

工数が個人評価に使われて数字が整えられる状態

工数の予実差だけを個人評価に使うと、超過を少なく見せようとする誘因が生じます。超過分を別のタスクや間接作業へ付け替える、見積り時に最初から多めに積む、といった調整が起きるため、組織として見積りを改善する材料が消えます。見積りの精度を個人の評価指標にしない理由は見積もり精度とは？予実差の測り方と段階別の目安、精度が上がらない原因と改善手順でも取り上げています。

工数記録の設計：作業コード・記録粒度・入力タイミング

破綻の多くは記録の設計で防げます。決めることは、何の単位で記録するか、何分刻みで記録するか、いつ締めるかの3点です。

作業コードを見積りのWBSと同じ階層で切る基準

作業コードは、見積りで使ったWBSの階層をそのまま写すのが原則です。案件、工程、WBS要素の順に階層を持たせ、予定工数もこの単位で登録します。プロジェクトに直接ひもづかない作業は別系統のコードにします。

プロジェクト管理作業を直接作業と分けておくと、管理工数がどれだけ膨らんでいるかを後で測れます。比率の目安は管理工数の比率は何％が妥当か｜10％の根拠をIPA原典と実証研究で検証、直接と間接の線引きは間接工数とは？直接工数との違いと区分の判断基準・直工率の計算方法を参照してください。変更対応を独立したコードにすると、変更管理書の番号ごとに追加工数を集計できます。

工数の記録単位：30分刻みを試す条件と15分刻みの用途

1日8時間を30分刻みで記録すると16枠、15分刻みでは32枠になります。入力の負担は枠数だけでなく、作業の切り替え回数や、続けて行った作業をまとめて登録できる入力方式かどうかでも変わります。見積りが人日単位でも、細かく記録した実績は合算して人日に換算すれば予実比較に使えるので、細かさの代償は入力の手間の側に出ます。

判断基準は集計の用途です。短時間の作業切り替えが少なく、集計誤差が判断に影響しない場合は、30分刻みを開始案にできます。保守契約で問い合わせ対応を時間単位で請求する、複数案件を短時間で行き来する体制で案件別原価を出す、といった用途があるときだけ15分刻みを選びます。人時・人日・人月の換算は工数の単位とは？人時・人日・人月の換算早見表と1人月160時間の根拠にまとめています。

当日中の入力締めと勤怠記録との週次照合

入力は当日中に締めます。前章の「実績が予定に寄る」問題を減らすには、当日入力に加え、作業中のメモやタイマーなどの記録を使います。日次の締めが定着しない場合は、終業時に未入力者へ通知を送る仕組みを先に作るほうが、入力ルールを増やすより効きます。

週に一度は、各メンバーの工数合計と勤怠の労働時間を突き合わせます。差があれば、まず休憩や間接作業の扱い、丸め単位、重複入力、勤怠の打刻漏れを確認し、残った差について作業記録と照合します。勤怠側は法律上の記録です。労働安全衛生法第66条の8の3は事業者に労働時間の状況の把握を義務づけ、同法施行規則第52条の7の3はその方法をタイムカードやパソコンの使用時間の記録などの客観的な方法とし、記録を3年間保存するよう定めています。工数記録はこの代わりにはならないので、照合の基準は勤怠側に置いてください。突き合わせの具体的な手順は実工数とは？標準工数・予定工数との違いと計算式、予実差異の見方で解説しています。

進行中の予実管理：スケジュール遅延と工数超過の判別

予実管理で見るべきなのは、予定に対して作業が遅れているのか、作業量が予定を超えているのかの区別です。両者は打ち手が違います。

EVMのCPIが工数記録の遅れで過大になる仕組み

EVM（アーンド・バリュー・マネジメント）では、予定作業の予算価値をPV、出来高の予算価値をEV、実際に発生したコストをACとします。本記事の例では金額の代わりに人時で統一し、PVを予定工数、EVを出来高に対応する予算工数、ACを実績工数として、SPI＝EV÷PV（スケジュール効率）、CPI＝EV÷AC（コスト効率）を出します。SPIが1を下回れば遅れ、CPIが1を下回れば超過です。計算手順の全体はシステム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注で扱っています。

金額ベースで採算を評価する場合は、単価や外注費などを反映した実際のコストが必要です。入力が遅れてACが過少に入っていると、CPIは実態より良く出ます。架空の数値で比べると次のようになります。

同じ現場でも、未入力があるだけで「予算内で進んでいる」という逆の結論が出ます。EVMを導入する前に、当日入力が守られているかを先に確かめてください。

予実差が出たときの打ち手の順番：再見積り・範囲調整・要員追加

CPIが1を下回り続けているときは、まず残作業を見積り直します。CPIが今後も変わらないと仮定した完了時総コストの見込み（EAC）は、AC＋（BAC−EV）÷CPI で求められます。BACは当初の予算総額です。上の表の当日入力の例で、BACを1,000人時とすると、CPIは160÷180で約0.89、EACは180＋（1,000−160）÷（160÷180）＝1,125人時となり、およそ125人時の超過が見込まれます。

見込みが出たら、範囲を削るか納期を延ばすかを発注者と協議します。要員追加は最後の選択肢にしてください。残り期間が新メンバーの立ち上がりを吸収できるほど長く、追加する人に任せる作業が既存の作業から切り離せる場合に限って検討します。どちらかが満たせないなら、ブルックスの法則どおり遅れを広げる可能性が高いと判断します。赤字の見込みが会計上どう扱われるかは見積もり精度が損益に与える影響｜赤字になる超過率の計算と契約形態別の負担、受注損失引当金を参照してください。

仕様変更を変更管理書と再見積りで扱う手順

IPAが公開している「情報システム・モデル取引・契約書」（第二版）は、仕様変更について、変更提案書と変更管理書を用いて協議する手続を定めています。第34条で、仕様書等の変更が必要と認めた側は「変更の内容、理由等を明記した書面（以下「変更提案書」という。）」を相手方に渡し、受け取った側は第37条により一定の日数以内に「変更管理書」を交付して協議します。

第37条が変更管理書の記載事項として挙げるのは、①変更の名称、②提案の責任者、③年月日、④変更の理由、⑤変更に係る仕様を含む変更の詳細事項、⑥変更のために費用を要する場合はその額、⑦検討期間を含めた変更作業のスケジュール、⑧その他変更が契約条件に与える影響の8項目です。条文が工数の再見積りそのものを求めているわけではありませんが、⑥と⑦の根拠を作るには、変更分の工数、単価、外部費用、作業の依存関係を確認することになります。契約条件に影響する場合は、第33条の変更契約を結んだ時点で変更が確定します。

工数管理の側でやることは2つです。変更ごとに作業コード（前章の「変更No.」）を発行し、追加分の工数を元の計画と分けて記録すること。そして変更管理書に書いた見積りと実績を、変更の単位で後から比べられるようにしておくことです。このひな型をそのまま契約に使っていない現場でも、変更を書面と番号で管理する考え方は流用できます。見積りの根拠の作り方は工数見積もりの指針｜手法の選び方と根拠の作り方・妥当性の精査手順で解説しています。

アジャイル開発の工数管理：ストーリーポイントと時間記録の使い分け

スクラムで開発している現場では「工数（時間）を記録すべきか」で意見が割れがちです。まず確認しておきたいのは、スクラムガイド2020が時間の記録を求めていないことです。英語版本文に “story point” “velocity” “estimate” の語は出てきません。規模の見積りについては “The Developers who will be doing the work are responsible for the sizing.” とあるだけで、手法は指定していません。バーンダウンについても “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism.” と、数ある実践の一つとして挙げるにとどまります。

したがって、ストーリーポイントでスプリントの計画を立てることと、時間を記録することは両立します。役割を分けて考えてください。

• ストーリーポイント：スプリントに何を入れるかを決めるための相対的な規模。チーム内でだけ意味を持つ。
• 時間の記録：案件原価、準委任契約の稼働報告、請負契約の採算確認など、チームの外に出す数字の根拠。

受託開発で原価や請求に時間が要るなら、時間記録は別に持ちます。記録粒度は原価計算と契約上の報告・請求要件に合わせます。スプリントとプロダクトバックログ項目の単位で不足する場合は、作業区分や担当者別の時間も記録します。ポイントを時間に換算して個人の生産性を測るのは避けてください。前述の「数字が整えられる」問題がそのまま起きます。スクラムでの見積りの進め方はスクラム開発の5つの実践ポイント｜ストーリーポイント見積もりと完成の定義で扱っています。

工数入力を定着させる運用：入力負荷とデータの還元

入力が定着しない現場でまず疑うのは、手間に見合う見返りが現場に見えていないことです。負荷を下げる工夫と、集めた数字を現場に返す仕組みの両方が要ります。

必須項目を日付・作業コード・時間の3つに絞る入力設計

入力者をログイン情報などで自動記録できるなら、手入力の必須項目は日付、作業コード、時間の3つに絞れます。作業内容のメモや進捗率を必須にすると、1件ごとの入力時間が延び、未入力が増えます。進捗率はEVMのEVを出すために要りますが、メンバー全員に毎日入力させるより、タスクの完了・未完了をチケットの状態から取るほうが記録の手間が少なく、主観も入りにくくなります。

作業コードの選択肢は、本人が担当している案件とタスクだけに絞り込んで表示します。全案件のコードから選ばせると、誤ったコードへの記録が増え、予実比較の精度が落ちます。

週次の予実レビューで数字を現場に返す運用

集めた工数が経営や管理部門の報告にしか使われないと、現場にとって入力は「出すだけの作業」になります。週に一度、チームの予実差とSPI・CPIを共有し、超過したタスクについて原因を話す時間を取ってください。話すのは原因の分類（見積り漏れ、仕様変更、技術的な詰まり、割り込み）で、誰が遅れたかではありません。

この振り返りで出た分類は、次の見積りで補正する材料になります。仕様変更が原因の超過が多いなら変更管理の運用を、見積り漏れが多いならWBSの粒度を見直す、というように打ち手が分かれます。工数管理ツールを定着させた他社の運用例は、工数管理ツールの導入事例：6社の公開事例で比べる集計時間の削減幅と原価連携の分かれ目で紹介しています。

案件完了時に工程別の工数比率をIPAの公表値と比べる振り返り

案件が終わったら、工程別の実績工数の比率を出して公表値と比べます。IPAの「ソフトウェア開発分析データ集2022」表A3-3-8（新規開発・N=270）は、基本設計から総合テストまでの5工程の合計を分母とした比率の中央値を次のように示しています。

中央値は工程ごとに別々に取った値なので、合計しても100%にはなりません。比較時は、対象が新規開発であることを確認し、基本設計から総合テストまでの5工程について社内と外部委託の実績工数を合算してください。管理作業の工程への割り当てもそろえます。P25〜P75は対象データの中央約50%が入る範囲で、適正値の上下限ではありません。範囲から外れた工程は、案件特性や工程の定義、記録区分、見積りと実績の差を確認します。たとえば結合テストの比率だけが極端に低い場合は、テストの手戻りが製作のコードに記録されていないかを先に確認します。比率の数字だけで見積りを補正すると、記録の癖をそのまま次の案件へ持ち込みます。

Excel・専用ツール・基幹システム連携の選び方

記録設計と運用が固まっていれば、道具の選択は規模と連携先で決まります。数人のチームで案件が少なければ、表計算ソフトでも作業コードと当日締めのルールは守れます。設計の考え方はエクセルで工数管理を始める前に押さえたい基本知識と全体設計の考え方にまとめています。

複数案件を並行し、案件別の原価や請求まで出したい段階になったら、工数管理ツールの導入を検討します。料金体系は人数課金、ロール別課金、定額などに分かれ、人数によって最安が入れ替わります。比較は工数管理ツール比較｜料金の実額試算と中小企業向けの選び方で試算しています。会計や販売管理と工数を連動させたい場合は、基幹システムとの連携方式まで含めて工数管理システムとは？工数の単位・機能・勤怠管理との違いと選び方を解説で整理しています。

ツールを替えても、作業コードが見積りと対応していない、入力が週末にまとまる、といった問題はそのまま移ります。導入前に記録設計を見直すほうが先です。

システム開発の工数管理に関するよくある質問

システム開発の工数管理とは何をすることですか？

開発作業ごとに予定工数を立て、実際に投入した工数を記録し、両者の差から遅れや超過を判断して手を打つことです。記録するだけでは管理にならず、予定と実績を同じ単位（見積りのWBS要素）で比べられることが前提になります。集めた数字は、進行中の判断（再見積り・範囲調整）と、次の案件の見積り補正の2つに使います。

工数管理と予実管理の違いは何ですか？

工数管理は、作業時間を作業コードごとに記録・集計する仕組み全体を指します。予実管理はその中の一部で、予定（見積り）と実績を比べ、差の原因を調べて対応することです。工数の記録が当日入力されていない、作業コードが見積りと対応していない、といった状態では予実管理は成り立ちません。予実差の測り方は実工数の記事で詳しく扱っています。

工数は何分単位で記録すべきですか？

見積りと予実を比べることが目的なら30分単位から始めるのが現実的です。1日8時間を区切る場合、30分単位では16枠、15分単位では32枠になりますが、入力の手間が倍になるとは限りません。保守の問い合わせ対応を時間で請求する、短時間で複数案件を行き来するなど、細かい単位の数字を実際に使う用途があるときだけ15分単位を選んでください。

遅れているプロジェクトに人を追加すれば間に合いますか？

人を足しただけで間に合うとは判断できません。ブルックスが指摘したとおり、新メンバーの立ち上がりと調整の時間が既存メンバーの工数を消費するためです。要員追加を検討できるのは、残り期間が立ち上がりを吸収できるほど長く、任せる作業が既存の作業から切り離せる場合に限られます。先に残作業の再見積りと、範囲・納期の調整を検討してください。

アジャイル開発でも作業時間を記録する必要はありますか？

スクラムガイド2020は時間の記録を求めていないため、スクラムの運用だけを考えるなら必須ではありません。ただし受託開発で案件原価を出す、準委任契約で稼働を報告するといった用途があれば、時間の記録は必要です。その場合はストーリーポイントと時間を混ぜず、時間はスプリントやバックログ項目の単位で集計し、個人の生産性評価には使わないようにします。

関連記事

• 実工数とは？標準工数・予定工数との違いと計算式、予実差異の見方
• 見積もり精度とは？予実差の測り方と段階別の目安、精度が上がらない原因と改善手順
• システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注
• 工数管理ツール比較｜料金の実額試算と中小企業向けの選び方
• 工数管理システムとは？工数の単位・機能・勤怠管理との違いと選び方を解説