記事案件別採算と工数記録の判断

案件別採算を見るには工数をどこまで記録する?|日報・SaaS・連携・個別開発の選び方

案件別採算を見るための工数記録を、現行集計・日報標準化・SaaS・連携や開発から選ぶガイド

案件ごとの売上は追えても、実際にどれだけ時間がかかったかが分からなければ、価格を見直す案件や、工程を調べ直す案件を選びにくくなります。ただし、日報を細かくしすぎると入力は続きにくくなります。入力が欠けたままでは、集計の仕組みを作っても判断に使える数字は残りません。

工数管理の範囲は、次に変える判断から逆算します。価格見直し、案件継続、工程改善、人員配置のうち一つに絞り、その判断に必要な顧客・案件・工程・時間・人件費だけを記録します。何に使うか決まっていない、または分類が揺れている段階なら、最初の一案は現行の日報に最小項目をそろえる短期試行です。入力と確認が続くと分かってから、既存SaaS、限定連携、個別開発・再構築を比べます。

工数を使って何を変えるのか、一つに絞る

同じ工数データでも、使い道によって必要な細かさが変わります。次の表から、今回の判断を一つ選びます。

今回の判断 最初にそろえる情報 検討できること その情報だけでは決めないこと
価格を見直す 顧客、案件、契約金額、実績時間、人件費の計算ルール 見積条件や更新価格の見直し候補 顧客が感じる価値、将来の受注量
案件を継続するか決める 顧客、案件、契約範囲、実績時間、契約外作業の区分 継続、条件変更、終了を検討する案件 将来の関係性や営業上の価値
工程を改善する 案件、工程、実績時間、手戻りや待ちの区分 詳しく調べる工程 個人の能力や人事評価
人員配置を見直す 案件、工程、担当区分、実績時間、期限 配置や応援を見直す案件 個人の適性や成果の質

価格見直しが目的なら、すべての作業を細かな工程へ分ける必要はありません。まず案件単位の時間と人件費を比べ、原因を調べたい案件だけ工程を分けます。工程改善が目的なら、顧客別の合計に加えて、どの工程で時間を使ったかを分ける必要があります。

最小記録は「請求の単位」と「仕事の区切り」から決める

最小記録は、日報画面に置ける項目数ではなく、価格や継続を判断する単位から決めます。

そろえるもの 決める内容 増やさない条件
顧客 請求先と採算を見たい相手の単位 部門別の判断をしないなら部門まで分けない
案件 見積、契約、継続判断と対応する仕事の単位 一つの契約を理由なく複数案件へ割らない
工程 見直したい仕事の区切り 工程別の判断をしない段階では増やさない
時間 合計時間で足りるか、開始・終了も必要か 時間帯や重複を判断しないなら開始・終了を必須にしない
人件費 誰のどの単価を、いつから使うか 比較中に計算ルールを変えない
確認方法 誰が誤分類や未入力を直すか 入力者だけに確認責任を残さない

契約金額や時間単価は、日報のたびに入力する必要はありません。案件台帳や単価表に一度登録し、日報の案件番号から参照できれば、入力者は案件と時間に集中できます。

共通作業は無理に案件へ配らない

社内会議、教育、営業準備など、どの案件へ入れるか決めにくい時間があります。配分ルールがない段階では、共通作業として分けて残します。担当者ごとに異なる感覚で案件へ振り分けると、数字は細かくても比較条件がそろいません。

案件へ配る必要が出たら、配る対象、基準、適用開始日を決めます。過去の記録まで無理に精密化せず、新しいルールを使った期間同士で比べます。

人件費は「何を含む単価か」を固定する

人件費の見方には、担当者ごとの単価、役割ごとの共通単価、全員共通の比較用単価などがあります。どれを使う場合も、給与だけか、会社が負担する費用まで含むか、外注費を別にするかを明記します。

最初の試行では、今回の判断に使う計算ルールを一つ決め、比較中は変えません。経理で使う原価との一致が必要なら、工数側だけで独自に決めず、同じ費用の範囲と適用期間を使います。

架空例:保守案件の更新価格を見直したい場合

以下は架空の例です。ある保守案件の日報には、作業内容が自由記述で残っています。ただし、どの案件の作業か、契約内の対応か追加対応かがそろっていません。経営側が決めたいのは、次回更新時の価格と契約範囲です。

最初の試行でそろえるのは、顧客、案件、契約内・契約外の区分、作業時間、確認者です。問い合わせの種類や技術分野まで細かく分けるのは、価格を見直す候補が見つかり、原因を調べる段階まで待ちます。

試行後に、契約外作業の区分が担当者ごとに揺れているなら、集計機能を増やす前に契約範囲の言葉をそろえます。案件と時間を迷わず選べるのに集計だけが重いなら、そこでSaaSや連携を比べます。記録しない項目まで決めておけば、日報が際限なく細かくなるのを避けられます。

分類と元データが安定してから仕組みを選ぶ

仕組みを選ぶ前に、顧客・案件・工程の呼び方がそろっているか、契約金額・工数・単価をどの表やシステムから取るかを確認します。どちらも決まっていない段階で連携や個別開発を始めると、分類とデータの置き場所を変えるたびに修正が必要になります。

選択肢 選ぶ条件 引き受ける手間・弱点 選ばない条件
記録を増やさず、現行の集計を続ける 現在の集計で選んだ判断に答えられ、詳しい内訳を使う予定がない 判断できる時期と細かさは現状のまま 価格や継続を決める時点で、必要な案件の時間を追えない
現行の日報・表計算を標準化する 分類がまだ揺れており、最小項目を実際の業務で確かめたい 集計、版管理、転記が人に残る 同じ情報を複数箇所へ写さないと判断できない状態が続く
既存SaaSを使う 標準の顧客・案件・工数・原価区分へ業務を合わせられ、必要な帳票とデータ出力を確認できる 標準機能への合わせ方、利用契約、停止時の代替を決める 固有ルールを保つための追加対応が中心になる
必要な集計だけを連携する 日報、案件管理、会計などの元データが決まり、共通の顧客・案件番号を使える 連携エラーの確認、元データ変更への追随、更新担当が必要 同じ案件をシステムごとに別名で扱い、対応表を維持できない
限定アプリ・個別開発・改修・再構築 固有の工程や原価ルールが安定し、標準機能で扱えず、保守と引継ぎの担当を置ける 見積、変更判断、障害対応、手動代替、引継ぎを持つ 分類が頻繁に変わる、入力確認の責任者がいない、停止時の代替を決められない

既存システムに不具合があっても、記録ルールと使えるデータが残っているなら、修正範囲を限定できます。どこまで正しいか説明できない、変更を引き継げない、元データの置き場所も不明な場合は、現行修正と再構築を同じ完了条件で比べます。

試行は「次の判断に使えるか」まで通す

試行の終点は、日報を入力できた時点ではありません。次に価格、継続、工程、配置を決める場で、その記録を使えるかまで確認します。実際の判断日が先なら、すでに結果の分かる案件を使い、同じ集計と説明を通せるか確かめます。

確認すること 続ける条件 立ち止まる条件
入力 今回必要な顧客・案件などを迷わず選び、後から記録を作り直さずに済む 選択肢の意味が人によって違い、毎回自由記述で補う
確認 誤分類や未入力を見つけ、誰が直したかを追える 確認者が決まらず、集計日になっても修正が終わらない
集計 元の記録まで戻って、案件別時間と人件費の理由を説明できる 集計のたびに別表で補正しないと数字を出せない
判断 価格、継続、工程、配置のうち、選んだ判断の候補を挙げられる 集めた項目を使う会議や決定がない
運用 分類変更、担当交代、停止時の代替を決められる 担当者以外が直すための情報も手順もない

立ち止まる条件に当たったら、機能を追加する前に、記録項目を減らす、分類を直す、確認者を決める、使う判断を選び直す、のどれかを行います。入力が続かない状態で自動集計だけを作っても、判断材料は安定しません。

工数管理は、集める量より使い道で決める

案件別採算を見るために必要なのは、最も細かな日報ではありません。次に変える価格、継続条件、工程、人員配置のどれか一つへつながり、現場が記録でき、経営側が確認できる範囲です。

価格見直しなら、まず顧客・案件・時間・契約金額・人件費のルールをそろえる。工程改善へ進む案件だけ、工程や手戻りを追加する。分類が揺れている間は現行日報で試し、標準区分へ合わせられるならSaaS、元データと案件番号が安定しているなら限定連携、固有ルールと保守責任まで決まった場合に限定アプリ・個別開発・改修・再構築を選びます。

限定連携、個別開発、既存システムの改修・再構築へ進む場合は、発注前にシステム開発の発注前に書く7項目|要件整理テンプレートで、通常の流れ、例外、確認待ち、完了条件を整理してください。