管理工数の比率は何％が妥当か｜10％の根拠をIPA原典と実証研究で検証

プロジェクトの見積もりで管理工数を積むとき、多くの現場が「総工数の10％」「1〜2割」といった目安を参照します。ところがその出所をたどると、根拠を示している資料はなかなか見つかりません。ここでは独立行政法人情報処理推進機構（IPA）が公開する『ソフトウェア開発分析データ集2022』の原典と、292件のプロジェクトデータを分析した学会発表にあたり、管理工数の比率をどう決めればよいかを整理します。

まとめ：管理工数の比率（割合）の結論

先に結論を示します。公的機関が定めた「管理工数比率の標準値」は存在しません。一方で、企業の実データを分析した公表資料はあります。この2つを区別したうえで、比率が自社の体制で何を意味するかを換算して判断します。

• 公的な標準比率はない：IPA『ソフトウェア開発分析データ集2022』（2022年9月26日公開・5,546プロジェクト）の全264ページを確認すると、「管理工数」は工数区分の定義とデータ収集フォームの任意入力項目として登場するだけで、比率の統計値は掲載されていません。
• 実証研究による目安は「開発工数の1割」：日本電気がソフトウェア品質シンポジウム2018で発表した292件の分析では、品質基準を達成したプロジェクトの管理工数÷開発工数の中央値が0.10でした。総工数を分母に置き直すと9.1％にあたります。
• 比率は人数に換算して判断する：総工数に対する管理工数10％は、専任のプロジェクトマネージャー1人がメンバー9人を含む10人体制を見る規模に相当します。20％なら5人体制です。
• 分母の取り違えに注意：総工数の10％と、開発工数への10％上乗せは別物です。総工数比10％は開発工数に対して11.1％の上乗せにあたります。

以降では、管理工数に含める作業範囲の線引き、流通する目安の出所の検証、比率と人数の換算表、IPAが実際に公開している工程別のデータ、そして自社比率を実測する手順の順に説明します。

管理工数に含める作業範囲｜IPAの工数4区分による線引き

比率を議論する前に、分子である管理工数の範囲を決める必要があります。範囲が違えば比率は簡単に2倍変わるためです。公開データと同じ土俵で比較できる区分としては、IPAがデータ収集フォームで採用している社内実績工数の4分類が使いやすいものです。

開発・管理・その他・作業配分不可の4区分

『ソフトウェア開発分析データ集2022』のp220は、社内実績工数を「社員（社員と一緒に作業する派遣社員を含む）の実績工数」と定義したうえで、次の4つに分けています。定義列はIPA原典の表記で、作業例の列は(c)以外は本記事の補足です。

(c)その他の例としてIPAが挙げているのは「テスト環境構築、インフラ構築、運用構築、移行、業務支援、コンサルティングなど」です。加えてIPAは、社内工数の内数としてレビュー実績工数を別項目で収集しており、外部委託工数は社員工数とは別枠で集計します。工数の数え方そのものについては工数の単位とは？人時・人日・人月の換算早見表と1人月160時間の根拠で整理しています。

移行やインフラ構築を管理工数へ入れない理由

実務でよく起きる誤りは、「開発ではない作業はすべて管理工数」とまとめてしまうことです。IPAの区分では、テスト環境構築・インフラ構築・移行・業務支援は管理ではなく「その他」に入ります。これらを管理工数へ寄せると、比率は実態より大きく出て、他社の目安とも自社の過去案件とも比較できなくなります。

逆に、管理業務を開発工数へ紛れ込ませる運用も比較を壊します。プレイングマネージャーが自分の稼働をすべて開発工数として計上すれば、管理工数比率は限りなくゼロに近づきます。区分の線引きと開発作業そのものの区別については直接工数と間接工数の違いとは？区分の判断基準・グレーゾーン・比率の目安を解説もあわせて確認してください。

「管理工数は10％」「1〜2割」という目安の一次的根拠の有無

検索でよく見かける目安が、どの資料に由来するのかを確認しました。記事媒体の目安に出典はなく、一方で企業の実データを分析した公表資料は存在します。

目安を掲載している主要記事の記述（2026年9月4日時点）

注目したいのは3行目です。プロジェクト管理製品を自社開発しているベンダーが、管理工数については「テスト工数のようにベースとなる対象が明確でなく、判り易いモデルもありません」と述べ、数値を提示していません。テスト工数のように他工程を基準に算出できる指標とは性質が異なる、という指摘です。

企業の実データによる唯一の公表値｜SQiP2018の292件分析

記事媒体の目安とは別に、実データにあたった発表があります。日本電気ソフトウェアエンジニアリング本部の齊藤拓也氏・柳田礼子氏がソフトウェア品質シンポジウム2018で発表した「ソフトウェア開発プロジェクトにおける工数の構成分析 – 適切な管理工数とは -」です。

分析対象は、2015年度または2016年度に完了した特定顧客向けのSI系開発プロジェクトのうち、開発規模・開発工数・管理工数・顧客対応工数のすべてが計上されている292件です。ここでの開発工数は設計製造テスト工数とレビュー工数の合計、顧客対応工数は移行・展開やユーザ教育を指します。主な結果は次のとおりです。

達成プロジェクトと未達プロジェクトの差はWilcoxonの順位和検定で5％水準の有意差が確認されており、論文は「適切な管理工数は、開発工数および顧客対応工数の1割程度」と結論づけています。管理工数は開発規模との相関が弱く（相関係数0.59）、開発工数との相関が強い（同0.74）ことも示されており、規模ではなく作業量に応じて積むべき工数だと読み取れます。

注意すべきは分母です。この0.10は開発工数を分母にした値であり、総工数を分母に置き直すと0.10÷1.10＝9.1％になります。未達プロジェクトの0.07は6.5％、重回帰の係数0.094は8.6％に相当します（いずれも顧客対応工数をゼロとした場合）。記事媒体が示す「総工数の10〜20％」とは分母が異なるため、そのまま並べて比較できません。

IPAの分析データ集に管理工数比率が載っていないと考えられる理由

IPAが管理工数の比率を公表していないのには、データの構造上の事情があります。p225の導出指標の定義では、実績工数について「工数には社員工数（開発工数、管理工数、その他工数、作業配分不可工数）と外部委託工数を含む」と記されています。つまり管理工数は各工程の工数の内数として扱われており、独立した工程として集計されていません。

さらにデータ収集フォームの注記には「プロジェクト管理工数を分けて収集している場合は、その数値を記入してください」とあります。管理工数を分けて記録していない企業は入力しないため、母数が揃わず統計として成立しにくいと考えられます。なおこの理由づけはIPAが述べているものではなく、収集様式からの解釈です。

また同シリーズは終了しています。IPAの公開ページには「事業終了に伴い『ソフトウェア開発分析データ集』の今後の発行予定はございません。」と明記されており、2022年版が最終版です。今後この統計が追加される見込みはありません。

管理工数比率10％・20％を人数と工数へ換算する早見表

比率の数字だけを眺めても妥当性は判断できません。その比率が体制として何を意味するかへ換算すると、現場感覚で検証できます。

比率とプロジェクトマネージャー1人あたりのチーム人数

管理業務に専念する担当者を1人置き、メンバー全員が同じ稼働率で参加し、メンバー側は管理工数を計上しない（管理工数＝専任1人ぶん）という単純化したモデルで換算します。比率は「管理工数÷総工数」で定義します。

この表を使うと、比率の議論が体制の議論に変わります。たとえば5人チームで管理工数10％を掲げた場合、管理に使えるのは0.5人分であり、専任を置く前提とは合いません。逆に20人規模で20％を積むと管理に4人分を充てる計算になり、その4人が何をするのかを説明できなければ過大です。専任を置かず兼務でまわす体制では、比率は目標値ではなく「兼務者の稼働のうち何割が管理に消えるか」の実測値として読む必要があります。

「総工数の10％」と「開発工数への10％上乗せ」の違い

見積もりの現場で最も多い取り違えが、比率の分母です。総工数の10％と、開発工数に10％を足すことは同じ結果になりません。以下では説明を単純にするため、管理工数以外の工数（その他・作業配分不可・外部委託を含む）をまとめて開発工数と呼びます。

開発工数を90人月と見積もったケースで比べます。総工数比10％にしたいなら、総工数＝開発工数÷（1−比率）より90÷0.90＝100人月となり、管理工数は10人月です。一方、開発工数90人月に単純に10％を足すと99人月にしかならず、そのときの管理工数比率は9人月÷99人月＝9.1％にとどまります。上乗せ率＝比率÷（1−比率）で換算すると、総工数比10％は上乗せ11.1％です。

差は比率が上がるほど開きます。総工数比20％は開発工数への25％上乗せに相当し、90人月の開発工数なら総工数112.5人月・管理工数22.5人月です。見積書を受け取る側も出す側も、提示された比率がどちらの分母なのかを最初に確認してください。計算の手順そのものは工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順で扱っています。

IPAが公表している工程別工数比率の実データ

管理工数比率の統計はない一方で、IPAは工程ごとの工数比率を実データで公開しています。管理工数はこの各工程の内数に含まれるため、配分を検討する際の土台として使えます。

新規開発と改良開発の工程別工数比率

対象は開発5工程（基本設計〜総合テスト）がすべて実施されたプロジェクトです。新規開発はN＝270、改良開発はN＝580です。

平均は新規開発で合計99.9％、改良開発で合計100.1％となり、5工程で全体を構成します。中央値は工程ごとに別々の分布から取るため合計が100％にならず、新規開発で95.8％、改良開発で94.4％です。改良開発は新規開発より総合テストの比率が高い点が特徴で、IPAも同様に指摘しています。

流通する工程比率の目安との比較で気をつける点

サン・アスタリスクの解説記事のように「要件定義10〜15％、設計20〜30％、開発30〜40％、テスト15〜25％」といった配分が示されることがあります。ここで確認が必要なのは分母です。IPAの比率の分母は基本設計から総合テスト（ベンダ確認）までの開発5工程であり、システム化計画と要件定義を含みません。要件定義を含む目安値と数字を直接並べると、それだけで数ポイントずれます。

分母を揃えて新規開発の中央値を束ねると、設計（基本設計＋詳細設計）32.2％、製作31.6％、テスト（結合＋総合）32.0％となり、ほぼ3等分です。テスト工程の比重は目安値として語られる範囲より高く出ます。自社の実績を評価するときは、比較相手の分母がどの工程までを含むかを必ず確認してください。

自社の管理工数比率を実測する手順

外部の値をそのまま当てはめられない以上、最終的な判断材料は自社の実績です。IPAの区分をそのまま使えば、少なくとも定義の面では公開データと同じ土俵に乗れます。

1. 工数入力の分類を、開発・管理・その他・作業配分不可の4区分に合わせます。既存の分類がある場合も、対応表を作って読み替えられるようにします。
2. 管理に入れる作業を先に列挙して固定します。進捗の収集、報告資料の作成、定例会議、課題とリスクの台帳運用、顧客との調整などです。列挙を後から変えると比率の時系列が切れます。
3. 1四半期にあたる3か月を記録します。プロジェクト単位ではなく人単位で記録すると、兼務者の管理時間が可視化されます。
4. 比率を「管理工数÷（開発＋管理＋その他＋作業配分不可＋外部委託）」で算出します。分母を毎回同じにすることが、比較可能性を保つ唯一の条件です。
5. 新規開発と改良開発、受託と自社開発のように案件区分ごとに分けて中央値を出します。平均は少数の大型案件に引きずられます。

記録期間中に工程が偏ると比率はぶれます。要件定義の期間だけを切り取れば調整業務の比率が高く出ますし、製作工程だけなら低く出ます。最低でも1つの案件が複数工程をまたぐ期間を確保してください。記録の仕組みづくりでつまずく典型的な要因は開発現場で工数管理が破綻する背景と見積もり精度を左右する構造的要因に、表計算ソフトで始める場合の設計はエクセルで工数管理を始める前に押さえたい基本知識と全体設計の考え方にまとめています。

管理工数が膨張する構造と削減の優先順位

実測した比率が想定より高い場合、原因の多くは会議と報告の重複にあります。承認の階層が増えるほど、同じ進捗情報を宛先ごとに作り直す工数が積み上がるためです。

• 最も効くのは、意思決定に使われていない報告を止めることです。作成した資料がどの判断に使われたかを1か月さかのぼって確認すると、止められるものが見つかります。
• 同じ数字を二重に集計している経路を1本にします。ツールと表計算ソフトの両方へ入力している状態が典型です。
• 会議は本数ではなく参加人数を掛けた延べ時間で管理します。それが管理工数の実体だからです。

削減の対象をどう見極めるかは工数削減とは何か：現場担当者が知るべき定義と削減対象の正しい見極め方で、集計作業そのものを機械化する選択肢は工数管理ツール比較｜料金の実額試算と中小企業向けの選び方で扱っています。

規模・開発手法・契約形態による比率の変動条件

同じ社内でも、案件の性質によって管理工数比率は変わります。比率を1つの目標値で縛らず、条件ごとに基準を持つほうが実態に合います。

小規模案件では専任を置けないため、兼務者の稼働のうち管理に流れる割合が高くなりがちです。比率としては20％を超えることもありますが、母数が小さいので絶対工数は数人日にとどまります。比率の高さだけを問題視すると、必要な管理まで削ってしまいます。大規模案件では逆に、サブチーム間の調整とプロジェクトマネジメントオフィスの運営が加わって管理の階層が増えます。ここで効くのは比率の目標値ではなく、階層ごとに誰が何を判断するかの整理です。判断者のいない中間報告が最も削りやすい対象になります。

契約形態では、誰の工数として計上するかが比率を左右します。IPAが社員工数と外部委託工数を別項目で集計しているとおり、協力会社のリーダーが担う管理業務を外部委託工数に含めるか管理工数に含めるかで、同じ体制でも比率が変わります。開発手法についても、スクラムのセレモニーを管理工数とするか開発工数とするかに正解はありません。いずれも途中で変えると前後の比較ができなくなるため、社内の集計ルールを先に固定してください。見積もりの精度が損益に及ぼす影響については工数見積りの精度低下がプロジェクト全体の損益に直結する構造的背景で詳しく説明しています。

よくある質問

管理工数の比率は何％が正解ですか？

公的に定められた正解はありません。判断材料になる公表値は、日本電気がソフトウェア品質シンポジウム2018で示した292件の分析で、品質基準を達成したプロジェクトの管理工数÷開発工数の中央値が0.10（総工数を分母に直すと9.1％）でした。これを出発点に、比率が自社の体制で何人分に相当するかを換算し、自社の過去案件の実測値と突き合わせてください。

「PMBOKやIPAが15〜20％と示している」という記述は正しいですか？

IPAについては誤りです。『ソフトウェア開発分析データ集2022』を確認した限り、そのような比率は掲載されていません。同書で「管理工数」が登場するのは、実績工数の構成要素としての定義と、データ収集フォームの任意入力項目としての注記のみです。IPAが公開している工数比率は工程別のもので、管理工数はその各工程の内数に含まれています。PMBOKガイドについても、工数配分の標準値を示している箇所は確認できませんでした。この記述は当サイトの旧版にも含まれていたもので、本稿で訂正します。

管理工数の割合はどのように計算しますか？

分母を先に決めることが出発点です。総工数を分母にするなら「管理工数÷（開発＋管理＋その他＋作業配分不可＋外部委託）」、開発工数を分母にするなら「管理工数÷開発工数」です。同じ体制でも前者が9.1％のとき後者は10.0％になるため、社外の数値と比べるときは相手の分母を必ず確認してください。

管理工数と間接工数は同じものですか？

同じではありません。間接工数は成果物に直接ひもづかない工数全般を指し、管理業務のほかに教育や社内事務なども含む場合があります。IPAの区分では、管理に該当しない非開発作業は「その他」として分けられます。詳しくは直接工数と間接工数の違いの解説をご覧ください。

管理工数の単位は人月と人時のどちらで管理すべきですか？

実測の段階では人時、見積もりや報告の段階では人月へ換算する運用が実務的です。管理業務は1回30分の会議のような細かい単位で発生するため、人月で記録すると丸めの誤差が比率に直接効きます。IPAのデータ収集でも工数の単位は人時と人月から選択する形式ですが、集計に使う実績工数は人時で表され、人月で提出する場合は人時換算係数を別途申告する設計になっています。

関連記事

• 直接工数と間接工数の違いとは？区分の判断基準・グレーゾーン・比率の目安を解説
• 工数の単位とは？人時・人日・人月の換算早見表と1人月160時間の根拠
• 工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順
• 工数見積りの精度低下がプロジェクト全体の損益に直結する構造的背景
• 工数管理ツール比較｜料金の実額試算と中小企業向けの選び方