受託開発の工数集計AI自動化｜PM月20時間→15分の5ステップ

金曜の夜、また工数集計か。チームメンバー10人分のSlack履歴とJira／Backlogを開いて、案件ごとに振り分けて、Excelに転記して……気付けば土曜日まで潰れている

受託開発のPMを毎週苦しめる工数集計を、生成AIで月20時間から15分まで圧縮する5ステップを、IT非専門の経営者・現場マネージャーにも分かる粒度で解説します。

なぜ受託開発のPMは「金曜夜の工数集計」から逃げられないのか

本記事のテーマに関連するサービスとして、BoostXではIT/Web企業の支援を提供しています。

受託開発の現場でPMが疲弊する最大の業務が、毎週末の工数集計です。要件は単純ではありません。月内の稼働時間をメンバー別・案件別・工程別に切り分け、契約上の工数枠と突き合わせ、超過案件は来週の打ち合わせ資料にまとめ、経営層には粗利見通しまで添えて報告する——。一見すると「Excelの集計作業」ですが、入力元が分散していることで作業時間が膨張します。

工数情報が10種類のツールに散らばっている

PMが工数を把握するために覗く先は、Jira／Backlog／GitHub／Slack／カレンダー／勤怠／請求書下書き／顧客の発注書／メール／自社ナレッジと、軽く10種類を超えます。チケット粒度の作業時間はJiraのワークログに、コミット時間はGitHubに、議事録ベースの追加作業はSlackと議事録ツールに、外出時間はカレンダーに、と情報の住み家がバラバラ。1人分を集計するだけで30〜40分、10人分なら1日仕事です。

「コピペExcel」では拡張も再利用もできない

多くの会社が手作りExcelで凌いでいますが、これには3つの限界があります。第一に、メンバーが増えるたびにシートが増殖して属人化します。第二に、案件が複数フェーズにまたがると、フェーズ別粗利が出せません。第三に、工数の途中段階で「あと何時間で予算を食い潰すか」を予測できないため、超過してから気付く後追い管理になります。結果として、案件が赤字化していても直前まで誰も止められない構造が固定化します。

受託開発業界の構造的事情も追い打ちをかける

受託開発は粗利が薄い業態であり、PMの工数集計精度が直接利益率に効く構造です。経営層は「工数管理を強化せよ」と言いますが、現場のPMにこれ以上の手作業負荷をかける余力はもはや残っていません。生成AIで根本から仕組み化する以外に、出口は見えません。

AI自動化で実現する月20時間→15分のPM週次オペレーション

理想の到達点を先に共有します。生成AIで仕組みを組むと、PMの「月20時間集計作業」は次のような週次オペレーションに置き換わります。集計時間そのものは月15〜20分まで圧縮できる規模感です（自社支援先での実測レンジ）。

この領域でつまずきやすいのは、ツール選定よりも「業務の中のどこに組み込むか」の設計です。BoostXの業務自動化サービスは、業務ヒアリングから設計・定着支援までをサービス対応範囲としてカバーできる領域です。

月曜朝7時、PMがコーヒーを取りに行っている間に終わっている

月曜朝、PMが出社する前に「先週の全案件×全メンバーの工数集計」「予算消化率」「超過リスク案件のアラート」「経営層向け週次サマリー」が、Slackと社内ポータルに自動配信されています。PMがやるのは画面を眺めて15分、超過リスク案件3件にだけ「今週の打ち手」をコメント追加する作業のみ。Excel転記もメール作成も発生しません。

人間の判断が必要なところだけ人間がやる構造

この仕組みのポイントは、PMの仕事を「集計係」から「判断係」に再配置することです。AIは「データの収集・整形・要約・異常検知」までを担い、PMは「赤字化リスクへの打ち手判断」と「メンバーとの対話」に時間を集中投下します。これが、受託開発における「PM時間あたり付加価値」を底上げする本筋です。

経営層が見たい数字も同じ仕組みで配信できる

経営層が知りたいのは「今月の見込み粗利」「赤字リスク案件」「メンバーごとの稼働率」の3点です。同じ自動化パイプラインから経営層用ダッシュボードを派生させれば、月次会議の資料作成自体が消滅します。PMが集計に時間を使わなくなれば、その分が新規案件の見積精度向上やチームメンバーとの1on1に振り向けられます。

5ステップで作る工数集計自動化パイプラインの全体像

ここからは、ビジネス層がプロに発注するときに「中身を理解している立場」で議論できる粒度で、5ステップを解説します。実装コード／API仕様／関数定義は本記事では深掘りしません（プロが設計する領域です）。経営者・PMが押さえるべき意思決定ポイントに絞ります。

ステップ1：データ源を「正」と「補完」に分類する

最初の意思決定は「工数の正データはどのツールに置くか」です。Jiraのワークログを正にする会社、Backlogを正にする会社、勤怠ツール（freee人事労務など）を正にする会社で、設計が大きく変わります。SlackやGitHubは「補完」扱いにし、AIが正データを補強する役割を担わせるのが定石です。複数の正を許すと整合性が崩壊します。

ステップ2：案件マスタを社内SSOTに固定する

「案件名の表記揺れ」と「案件IDの欠落」が、自動化を必ず詰まらせる2大障害です。AIは曖昧な名寄せを得意としますが、AIに名寄せを任せた瞬間に集計結果がブラックボックス化します。案件マスタ（案件ID／案件名／担当PM／契約工数枠／契約形態／開始日終了日）を1ヵ所に集約し、全ツールから参照する構造を作ります。

ステップ3：AIによる集計・要約・異常検知レイヤーを置く

ここで初めて生成AI（Claude／GPT等）の出番です。担うのは「集計後の数値を文章で要約」「予算消化率の異常検知」「超過リスクの理由分析」「経営層向けサマリーの自動執筆」の4つ。生のSQL集計や数値計算自体はAIにやらせず、決定論的な集計エンジン（GAS／Python／BigQuery等）に任せ、AIは「人間が読む形式への変換」と「異常の意味付け」に集中させます。これがハルシネーションを抑える肝です。

ステップ4：配信チャネルと頻度を「人間の判断頻度」に合わせる

日次・週次・月次のどれで配信するかは、案件の回転速度で決めます。SES／準委任で案件期間が3ヵ月以上なら週次配信、請負で2週間スプリントを回すなら日次配信が向きます。配信先はPMにはSlack DM、経営層には社内ポータルとメール、顧客には月次レポートPDF（自動生成）というように、受け手の業務リズムに合わせて出口を切り分けます。

ステップ5：ガードレールと運用ログを最初から組み込む

最後に、AIが誤集計したときの検知装置と、誰がいつ何を変更したかの監査ログを最初から仕込んでおきます。受託開発は「数字の根拠」を顧客に説明する責任を伴う業態です。AIが算出した数字には必ず「集計元データへのリンク」を付帯させ、PMが30秒で根拠を確認できる構造にします。これを後付けで足そうとすると、再設計コストが膨れ上がります。

内製で詰む4つの理由とプロ伴走に任せる判断基準

「ここまで読めば内製でいけそう」と感じた方ほど、立ち止まってください。受託開発会社のIT部門なら作れそうに見える領域ですが、本業の合間に内製した工数集計AIは、ほぼ例外なく半年以内に運用停止します。理由を4つに絞って整理します。

理由1：保守責任が「作った人」に固着する

内製で組むと、Jira／Slack／GitHubのAPI仕様変更が起きるたびに、作った担当者が休日対応する構造になります。本業の受託案件で炎上している最中に、自社の工数集計ツールの障害対応が同時に降ってくる——これが最も多い破綻パターンです。プロ伴走に任せれば、API変更の追従とエラー監視が運用契約の中で完結します。

理由2：エラー時の「業務継続」設計が抜け落ちる

AIが誤集計した日、配信が遅れた日、APIが落ちた日に、PMの業務をどう継続させるかを設計しないと、現場は1日で「やっぱりExcelに戻る」を選びます。プロは「正常時の華やかな自動化」より「異常時のフォールバック設計」に時間を使います。ここが内製とプロの最も大きな差です。

理由3：セキュリティと監査要件が想像以上に重い

受託開発の工数データは「顧客との契約工数」と直結する機微情報です。社内の誰がアクセスできるか、ログがどこに残るか、退職者のアカウントが即時無効化されるか、AI APIへのデータ送信時にマスキングされるか——これらをすべて社内ルールに沿って実装する負荷は、想像の3倍と思ってちょうどいい水準です。BoostX代表もよく言うことですが、「APIキーが1つ漏れたときのダメージは、Web版の学習利用よりはるかに大きい場合がある」「中小企業のデータ流出リスクの9割は人的ミスから生まれる」（BoostX社内方針）。仕組み側でミスを起こさせない設計が必須です。

理由4：AI連携は「単発実装」ではなく「育成」になる

AIによる要約や異常検知は、最初から完成形は出ません。3ヵ月単位でプロンプトを調整し、社内用語や案件特有の表現を学習させ、PMからのフィードバックを蓄積して精度を上げ続ける「育成サイクル」が必要です。本業の受託開発を回しながらこのサイクルを継続することは現実的ではありません。プロ伴走の月額契約で、PDCAそのものをアウトソースする構造が合理的です。

ビフォーアフター：受託開発PMの1週間がここまで変わる

ここまでの内容を、PMの1週間という生活感で具体化します。読み終えたあとに「自分の働き方はBefore寄りか、Afterに近づいているか」を判定してください。

Before：現状の苦しい1週間（受託開発PMの典型）

月曜：朝会で各メンバーの先週稼働を口頭ヒアリング。Slackで散発的に追加情報を取りに行く。火曜〜木曜：本業の顧客打ち合わせと開発レビューに追われ、工数集計は一切進まない。金曜夕方：「やばい、月次まで時間がない」と気付く。金曜夜：Jira／Backlog／Slack／GitHubを順番に開き、Excelに転記。10人分で6〜8時間。土曜：案件別粗利の試算と来週の経営報告資料の作成で半日潰れる。これを毎月繰り返し、PMが疲弊して離職率が上がる——受託開発業界で繰り返されている構造です。

After：仕組み化後の楽な1週間

月曜朝7時：自動配信されたサマリーをSlackで確認（5分）。超過リスク案件3件にだけ「今週の打ち手」をコメント（10分）。火曜〜木曜：本業に集中。途中で異常検知が走った案件があれば、Slackに通知が飛び、その場で5分で対応判断。金曜：定時退勤。土曜は家族の時間。月次の経営報告は、自動生成されたサマリーをPMが10分レビューして承認するだけ。集計時間そのものは月15〜20分まで圧縮できる規模感です（自社支援先実測レンジ・案件規模により変動）。

違いを生んでいるのはツールではなく「運用設計」

Before／Afterの差を生んでいるのは「ChatGPTを契約したかどうか」ではありません。データ源の正・補完を切り分け、案件マスタをSSOT化し、AIに「集計」ではなく「要約と異常検知」を任せ、配信チャネルを業務リズムに合わせる——この運用設計をやり切れたかどうかです。ツールは目的ではなく、設計の結果として選ばれるものです。

「うちはまだBefore寄りだ」「Afterに近づきたいが、内製で半年溶かす余裕はない」と感じた方は、次のセクションをご覧ください。

よくある質問