PM管理費は削ると品質が落ちる — 資料の分量を変えずに、3人時を1.5人時にした記録

受託開発の見積もりには、プロジェクト管理の費用が入っています。値引きの相談になると、まずここが削られます。

削れと言われた側は、二択に見える場所に立たされます。削れば、あとで品質の問題が出たときに自分の判断が問われる。削らなければ、金額が通らない。

この記事は、その二択に三つ目を足せるかを試した記録です。管理の水準は落とさず、人が通る工程のほうを減らす。 繋いだツール、渡したプロンプト、置き換える前と後の実測、そして「出てくる資料が薄くなっていないか」を10回分数えた結果を出します。

前提と、測っていないことは最後にまとめてあります。

削れと言われる管理費と、削ったときに落ちるもの

まず、管理費がどのくらいの大きさなのかを業界の数字で置きます。

大手SIer1社が2015〜16年度に完了した受託開発292件の実績工数を分析した発表があります。進捗管理や品質管理といった管理工数は、開発工数の10%（中央値）でした。

面白いのは次です。

図：管理工数が開発工数に占める割合。出荷後バグの基準を達成した群は10%、達成しなかった群は7%。削った側のほうが品質が落ちています。

出荷後バグの基準を達成したプロジェクトは10%、達成しなかったプロジェクトは7%。Wilcoxonの順位和検定で5%水準の有意差がついています。

論文自身が書くとおり、これは相関であって因果の証明ではありません。それでも、管理工数は削ってよい余剰ではなく、削ると別の場所が壊れるコストだった、と読めます。

発注側の調査も近い水準です。ユーザー企業658件の間接工数比率は9.7%、規模別でも9.0〜11.4%。母集団も視点も違う2つの調査が、どちらも「おおむね1割」を指しています。

管理費を削れと言われた側は、削れば品質の責任を負い、削らなければ金額を通せない。

誰も測っていないので、中身が分からないまま削られる

では、その1割の中身は何でしょうか。

ここで手が止まります。IPAのソフトウェア開発データ白書には、プロジェクト管理という工程区分がありません。 公式FAQが「PM・PMO・品質保証の工数は、基本的には各工程の全体工数に含まれる」と明記しています。累計5,546件の国内最大のデータベースでも、分離されていない。

プロジェクト専門職への国際調査では、「レポートを手作業で集約する」ことに月半日以上を使っている人が72%。同じ設問を10年続けていて、2020年版では「月1日以上」が約3分の1、2021年版では約50%でした。

図：報告資料の集約にかかる時間の調査。「月1日以上」と「月半日以上」で閾値が違うため、2群に分けて並べています。横に並べた比較はできません。

設問の閾値が違うので1本の線では結べませんが、減っていないことは3版に共通しています。 放っておいて勝手に軽くなる工程ではない、ということです。

発行元は英国のプロジェクト管理ツール導入コンサルティング会社で、同じ報告書で自社の導入効果も訴求しています。国際公募の自己申告で、日本の数字でもありません。それでも、PM専門職に限定して同じ設問を10年続けた調査は他に見つかりませんでした。

測られていない工程は、中身が分からないまま削減の対象になる。

繋いだ5か所と、渡したプロンプト

ここから当社の話です。当社が担当している受託の業務システム開発案件で、毎週1回、顧客向けの定例があります。その資料づくりが対象です。

定例の前に目を通す対象は5か所あります。

図：定例の前に目を通す5か所と、直近7日間の物量。チャットとメールは件数が数えられますが、残る3つは随時更新で件数が数えられません。

いちばん重いのは開発者とのチャットです。直近7日間で15件。1件が数千字あり、判断を待つ案件がそのまま積み上がります。顧客からのメールは担当者ごとに別のスレッドで、新着は古いスレッドの末尾に付くため単純な検索では見つかりません。

繋いだのは次のとおりです。

図：繋いだ5か所と、出す側の5つ。アイコンは simple-icons（CC0）。チャットだけは公式に再配布が認められたものが無いため、ロゴを出していません。

読む側が5か所、出す側が5つで、うち3つをAIが作ります。

置き換える前は、この5か所を人が順番に開いていました。

図：渡す前の6工程。5か所を開くところから定例での説明まで、全部が人の手でした。

工程は6つ。5か所を開く、差分を探す、要点を抜き出す、判断が要る件を選ぶ、スライドに起こす、説明する。全部が人の手でした。

渡したプロンプトの骨格です。顧客固有の記述を外して、そのまま使える形に書き直してあります。

あなたはこのプロジェクトのPMの補助です。前回の定例からの差分だけを扱います。

1. 次の5か所を、前回確認時刻より後だけ読む。
   メール／チャット／コード管理／共有ドライブ／進捗の表
   検索結果の一覧やスニペットで判断しない。動きのあったスレッドは全文を開く。
   チャットは親メッセージだけでなく、未完了のスレッドの返信も取る。

2. 読んだものを1件1ブロックで出す。形式は次のとおり。
   【ID】: そのスレッドが扱っている話題
   進捗: 今回の書き込みで何が起きたか（1〜2文）
   判断: PMが決めることがあれば1文。なければ「特になし」
   返答: 必要なら「要（いつまで）」、不要なら「不要」

3. 仕様書と照らして、顧客の要望を1件ずつ次に分類する。
   仕様変更／バグ／仕様漏れ／保留（事実が未確認）／仕様どおり
   条文を原文のまま引用できないものは、判定せずに「条文なし」と書く。

4. 定例資料の下書きを作る。構成は前回と同じ。
   先週からの差分、判断を仰ぐ件、次週の予定。
   数字は読んだ原文から取る。推測で埋めない。

守ること
- 送信・投稿・コードの書き換えはしない。すべて文案で止める。
- 読めなかったもの（添付・権限が無いもの）は「読めていない」と書く。
  読んだことにしない。
- 前回確認時刻を最後に更新する。

最後の「読めていないものを読んだことにしない」が効きます。これが無いと、AIは読めなかった添付を飛ばして、それらしい要約を作ります。

資料そのものはPythonスクリプトで組み立て、毎回ゼロから生成し直しています。

人が通る工程を、6つから3つにした

全部をAIに渡したわけではありません。

図：渡したあとの6工程。数は変わらず、担い手だけが変わりました。網かけが人に残した3つです。

工程の数は6つのまま変わっていません。担い手だけが変わりました。回収・差分・要点の抜き出し・作図をAIに渡し、判断が要る件を選ぶことと定例で説明することを人に残しています。

残した理由は3つです。

判断の選別は、残すと決めたから残っています。AIが出すのは「判断が要る」という候補までで、どれを定例に上げるかは人が決めます。ここを渡すと、顧客に出す前の最後の網が無くなります。

顧客への送信は、当社が公開APIを確認できていない画面を経由します。確認できていないだけで、無いとは書けません。

仕様書の更新は、顧客の書面での合意を取ってからにしています。口頭や定例でのOKは根拠にしません。緩めると、後から「言った・言わない」になります。

落とし穴も1つ。チャットのチャンネル履歴だけを読ませると、スレッド内の返信が見えません。 最初の数回、これで判断待ちの件を取りこぼしました。未完了の親メッセージは、返信まで取りに行かせる必要があります。

3人時が1.5人時に、資料の分量は変わらず

前と後の両方に実測があります。

置き換える前は、定例当日の朝に2人で作っていました。1人がチャットとメールの履歴から進捗と先方への確認事項を拾い、もう1人がそれを資料に起こす。これで1時間半。2人がかりなので3人時です。

ここは先に書いておきます。その時点でも、履歴を追う部分にはすでにAIを使っていました。 完全な手作業から半分になったのではなく、一部をAIに任せた状態から、さらに半分です。

図：置き換える前は朝2人がかりで1時間半＝3人時。置き換えた後は1人〇93分・104分・83分＝1.4〜1.7人時。

置き換えた後は93分・104分・83分。1人なので1.4〜1.7人時。3人時から、おおよそ半分になりました。

ただし、人時が減っても出てくる資料が薄くなっていたら意味がありません。市場の数字が言っているのは、まさにそれです。そこで、切替の前後5回ずつ、10件を1枚ずつ開いて数えました。

図：切替の前5回と後5回を1枚ずつ開いて数えた結果。人時は半分になりましたが、枚数も文字数も変わっていません。

スライドの枚数は平块20.2枚のまま。文字数は8,772字から8,725字。どちらも変わっていません。

同じ分量の資料が、半分の人時で出ている。

数えたのは分量だけで、資料の品質は測っていません。 中身が良くなったか悪くなったかは、この10件からは言えません。

組織に広げたときに必ず止まる場所

ここまでは、個人が自分の端末で試せる話です。組織に広げようとすると、別の問題が出ます。

図：読む権限5つと書く権限5つ。一人で試すうちは線の位置を自分で決められますが、2人目に広げた時点で決裁事項になります。

読む側に渡したものには、顧客の氏名、連絡先、業務の中身が入っています。

「誰の、どのツールの、何を、どのAIに、どこまで見せるか」。担当者が自分で決められる話ではなく、決裁事項です。一人で試すうちは出てこず、2人目に広げた瞬間に出ます。

金額にしておきます。自分の案件の数字を入れて引ける表です。

図：頻度×1回の人時で、年間の時間と金額を引く表。灰が置き換える前（毎週3人時＝年67万円）、緑が後（毎週1.5人時＝年33万円）。

時間単価は、厚生労働省の職業情報提供サイトにある平均年収889万円を、同サイトの月間労働時間173時間（年2,076時間）で割って約4,280円としました。請求単価ではなく人件費側の数字です。

毎週・3人時なら年156人時で約67万円。毎週・1.5人時なら年78人時で約33万円。1案件・1人分で、差は年33万円です。

「削ります」でも「削れません」でもなく、「管理の水準は落とさずに、人の手数のほうを半分にしました」と言える。

経営陣に持っていくときに必要なのは、この3つです。削ると品質が落ちるという業界の数字。人時を半分にしても資料の分量は変わらなかったという実測。そして自分の案件でいくら動くかという金額。

ここまでの配線を自分の組織でやろうとすると、最初に止まるのは権限の設計です。どのツールのどの範囲を、誰のAIに、どう記録を残しながら渡すか。Latens OSは、そこを一箇所で設計して監査できるようにするための製品です。15分のデモで、実際の権限画面をお見せします。

この記事の前提と、測っていないこと

外に出した測定値は3つです。

• 置き換える前の1回あたり3人時（定例当日の朝、2人で1時間半）。作業時間の実績です。この時点でも、履歴を追う部分にはAIを使っていました。
• 置き換えた後の1回あたり93分・104分・83分（1人）。案件フォルダのファイル更新時刻から復元した、人の確認を含む実時間です。
• 切替前後5回ずつの資料の分量（スライド20.2枚→20.2枚、8,772字→8,725字）。ファイルを python-pptx で開いて数えました。

測っていないもの。

• 資料の品質。 数えたのは枚数と文字数だけです。
• 人が通る工程が6つから3つになったこと自体は、当社の設計です。測定ではありません。
• プロンプトを書いた時間と、配線にかかった時間。
• 定例以外のPM作業にかかっている時間。
• 読者の環境（別の体制、別のツール構成）で同じことが起きるか。

前と後で取得方法が違います。前は作業時間の実績、後はファイル更新時刻からの復元です。同じ物差しではないので、半分という数字はおおよそとして読んでください。分量の比較は5回ずつなので、言えるのはこの10件の範囲です。統計的な主張はしていません。

業界の数字は母集団と調査年を本文に書いたとおりで、292件は大手SIer1社の実績、業界平均ではありません。

顧客名・業種・規模・体制・時期は出していません。公開したプロンプトは記事用に書き直したもので、実際に使っているものをそのまま載せたわけではありません。

出典

• 齊藤拓也・柳田礼子「ソフトウェア開発プロジェクトにおける工数の構成分析 － 適切な管理工数とは －」ソフトウェア品質シンポジウム2018（日本科学技術連盟）https://www.juse.jp/sqip/library/shousai/download/index.cgi/B3-2.pdf?id=414
• 日本情報システム・ユーザー協会「ソフトウェアメトリックス調査2014」https://juas.or.jp/cms/media/2017/02/14swm_pr_dev.pdf
• 情報処理推進機構「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答 https://www.ipa.go.jp/archive/publish/wp-sd/qa.html
• Wellingtone, The State of Project Management 2026 https://pmworldlibrary.net/wp-content/uploads/2026/03/260316-Wellingtone-state-of-PM-2026-press-release.pdf
• 厚生労働省 職業情報提供サイト job tag「プロジェクトマネージャ（IT）」https://shigoto.mhlw.go.jp/User/Occupation/Detail/322