LASSIC Media らしくメディア
設計レビューの工数の見積もり方｜ページあたりの中央値の使い方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 新規開発の基本設計のレビューには、設計書1ページあたり中央値で0.335人時がかかっています。
- 同じ新規開発の基本設計でも、真ん中の半分の案件のあいだで7.06倍の差があるため、幅を持たせて見積もります。
- 平均は一部の極端な案件に引っ張られて中央値の10倍以上になるので、見積もりの根拠にしません。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
設計書のレビューに、どれだけの工数を見込めばよいのか。人を割きすぎるとプログラムの作成に入るのが遅れ、削ると後の工程で手戻りが出る——。設計工程の計画を立てる現場では、こうした迷いが起こりがちです。手がかりになるのが、ページあたりのレビュー工数です。設計書1ページのレビューに何人時（1人が1時間働く量）をかけたかを示す値で、IPA（情報処理推進機構）が業界の案件から集めた分布を公開しています。*2
この値を使えば、設計書のページ数からレビューの工数をおおまかに見積もれます。ただし万能ではなく、同じページ数でも案件によって数倍の差が出ます。本記事では、設計工程の体制を組む実務担当者に向けて、基本設計と詳細設計の値、幅を持たせて見積もる理由、平均を使わない理由、見積もりの手順、そして外部に頼むときに確認したい点を整理します。
目次
ページあたりのレビュー工数とは
レビューの工数は、参加する人数と回数だけでは決まりません。読む設計書がどれだけあるかで変わります。そのため、量あたりの単位で置くと見積もりに使いやすくなります。IPAの「ソフトウェア開発分析データ集2022」は、この値を人時／ページ、つまり設計書1ページあたりに何人時のレビュー工数をかけたかという単位で集計しています。*2
資料の公開は2022年9月26日、最終更新は2025年8月28日で、これまでに収集した5,546プロジェクトの定量データから分析されています。*1 事業終了に伴い今後の発行予定はないと明記されているため、最新の調査ではありません。2022年より後の傾向は、この資料からは追えないことになります。
集計の対象は、開発の5つの工程がすべてそろった案件のうち、レビューの工数と設計書の分量がどちらも0より大きい案件です。*2 そのため、レビューをしていない案件や、設計書が残っていない案件はこの分布に入っていません。ここで見る数値は、レビューを実施した案件で、1ページあたりにどれだけの工数をかけたかを示すものです。
基本設計と詳細設計の値
新規開発の基本設計は、中央値（件数の真ん中の値）が0.335人時／ページでした。対象は71件です。*2 0.335人時は20分ほどで、設計書1ページのレビューに20分ほどかけている計算です。
新規開発の詳細設計は、中央値が0.207人時／ページで、基本設計の0.335より少ない値です。*2 0.335を0.207で割ると1.62倍になり、1ページあたりでは基本設計のレビューのほうが工数が多いという結果です。IPAの資料は、この値が2014年度から2019年度の0.289と比べて少なくなっていると記しています。
| 工程と種別 | P25 | 中央値 | P75 | 件数 |
|---|---|---|---|---|
| 基本設計・新規開発 | 0.139 | 0.335 | 0.982 | 71 |
| 基本設計・改良開発 | 0.143 | 0.313 | 0.561 | 197 |
| 基本設計・再開発 | 0.107 | 0.133 | 0.460 | 13 |
| 詳細設計・新規開発 | 0.119 | 0.207 | 0.713 | 71 |
| 詳細設計・改良開発 | 0.085 | 0.225 | 0.456 | 196 |
| 詳細設計・再開発 | 0.032 | 0.204 | 0.581 | 14 |
改良開発（既存システムの改修や拡張）では、基本設計の中央値が0.313、詳細設計が0.225でした。件数は197件と196件で、3つの種別の中でいちばん多くなっています。*2 新規開発に近い水準で、1ページあたりでは基本設計のほうが工数が多いという点も同じです。再開発（システムの作り直し）は基本設計が0.133、詳細設計が0.204で、3つの種別の中で再開発だけ詳細設計のほうが工数が多くなります。
なぜ幅を持たせて見積もるのか
表のP25は件数を小さい順に並べて4分の1の位置の値、P75は4分の3の位置の値です。新規開発の基本設計はP25が0.139、P75が0.982で、P75をP25で割ると7.06倍になります。*2 真ん中の半分の案件だけを見ても、少ない側と多い側でこれだけの差があります。
同じように表の値から計算すると、新規開発の詳細設計は5.99倍、改良開発の基本設計は3.92倍、改良開発の詳細設計は5.36倍です。新規開発と改良開発では、真ん中の半分の案件だけで4倍近くから7倍まで差が開きます。ページ数が分かっても、レビューの工数は数倍の幅でしか見込めません。
100ページの新規開発の基本設計で計算してみます。中央値で置くと33.5人時で、4人日ほどです。P25で置くと13.9人時、P75で置くと98.2人時になり、P25とP75のあいだで84人時以上、10人日を超える差が出ます。これだけ違えば、レビューに何人を何日あてるかという体制の組み方も変わります。見積もりの技法そのものについては「工数見積り技法を外注で精度向上」で扱っています。
平均を使わない理由
この資料には平均も載っていますが、中央値と大きく離れています。新規開発の基本設計は平均が3.543で、中央値0.335の10.6倍です。詳細設計は平均4.523で、中央値0.207の21.9倍になります。*2 改良開発も同じで、基本設計の平均3.717は中央値の11.9倍、詳細設計の平均3.844は中央値の17.1倍でした。
差を生んでいるのは、ごく一部の極端な案件です。いちばん大きい値は、新規開発の基本設計で72.024、詳細設計で74.800、改良開発の基本設計で178.154、改良開発の詳細設計で272.854と示されています。*2 1件でも極端な値があると、平均は大きく動きます。そのため見積もりには中央値と、P25・P75を使います。
どう見積もるのか
手順は4段に分けられます。1段目は、レビューの対象になる設計書のページ数を数えることです。2段目は、工程と開発の種別に合う行の中央値をページ数に掛けて、基準になる工数を出すことです。3段目は、同じようにP25とP75も掛けて、少なめと多めの見込みを2つ作ることです。100ページの新規開発の基本設計なら、13.9人時から98.2人時の幅を持ち、中央値の33.5人時を基準に置きます。
4段目は、実績を記録することです。レビューが終わったら、実際にかかった人時と設計書のページ数を残しておきます。自社の実績がたまってくれば、業界の分布ではなく自社の中央値で見積もれるようになります。ページ数から工数を出す前に人数と日数を決めてしまうと、実際の工数が数倍の幅のどこに来るかによって、途中で計画を立て直すことになります。
外部に委託するときに確認しておきたい点
見積もった工数を社内の人だけでまかなえないときは、レビューの作業を分けて考えます。仕様がよいかどうかを決める判断は社員が持ち、指摘の洗い出しや記録の整備は外部の人材に任せる、という分け方です。委託する前に、どの設計書のどの作業を任せるのかを決めておくと、見積もった工数と委託する工数を突き合わせやすくなります。
期間を区切って加わってもらうなら、フリーランスを含む業務委託の使い方が合います。設計工程の数か月だけレビューの担当者に加わってもらい、プログラムの作成に入る時点で契約を終える形です。コードレビューを委託する進め方は「アプリのコードレビュー外注の進め方」で、工程ごとの内製と委託の分け方は「工程別の内製化」で扱っています。
つまずきやすい点
一つ目は、再開発の値をそのまま使うことです。IPAの資料の4.3節の前文には、再開発はデータ数が基準を満たさないため掲載しないと書かれている一方で、表4-3-3と表4-3-6には値が載っています。*2 件数も13件と14件と少ないため、再開発の案件では表の値を参考にとどめ、自社の実績で置き換えることを優先します。
二つ目は、これまでレビューをしてこなかった案件に、この値を当てはめることです。分布はレビュー実績のある案件だけを対象にしています。レビューの進め方がまだ決まっていない案件では、何を見るのか、誰が見るのかを先に決める作業が入り、その分の工数も見込む必要があります。
三つ目は、指摘の件数と組み合わせて、指摘1件あたりの工数を出そうとすることです。同じ資料の表4-1-4には、基本設計の指摘件数が1ページあたり中央値0.216件と示されていますが、こちらは全開発種別の353件が対象で、工数の表とは対象の案件が違います。*2 そのため、指摘1件に何人時かかるという割り算はできません。
まとめ：設計レビューで確かめておきたい3つの点
設計レビューの工数を見積もるうえで、確かめておきたい点は3つに整理できます。第一に、設計書のページ数を数え、工程と開発の種別に合う中央値を掛けること。第二に、P25とP75でも計算して、少なめと多めの見込みを持っておくこと。第三に、平均は使わず、実績を記録して自社の値に置き換えていくことです。この3点を踏まえておけば、「ページ数から見積もったのに、レビューが予定の何倍もかかった」という事態を避けやすくなります。レビューの体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
レビューに工数をかけるほど、設計の品質は上がりますか
この資料からは言えません。集計には、工数と品質の関係や、指摘の質、手戻りの減り方は含まれていないためです。資料の値は、レビューを実施した案件でどれだけ工数をかけたかを示すものとして使います。
1回のレビューに何人が参加すればよいですか
人数の目安は、この資料には含まれていません。1回あたりの時間や参加した人数は集計されていないためです。人数は、ページ数から工数を見積もったあとで、その工数を何人で何日に分けるかとして決めます。
2022年の資料の値は、いまも目安として使えますか
目安としては使えますが、新しい調査は出ません。資料は事業終了に伴い今後の発行予定がないと明記されています。*1 ただ、新規開発の基本設計の中央値は、2014年度から2019年度の0.350と比べてあまり差はないとされており、水準は大きく変わっていません。*2
自社の実績は、どのように記録すればよいですか
案件ごとに、レビューにかかった人時と、対象の設計書のページ数を記録します。あわせて工程（基本設計か詳細設計か）と開発の種別を残しておくと、資料の表と同じ区分で自社の値を比べられます。
設計レビューの体制を相談したいとき
設計工程にどれだけの工数を見込むか、その見積もりから担当が一緒に検討します。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：公開日・最終更新日、5,546プロジェクトから分析したこと、事業終了に伴い今後の発行予定はないことの記述を参照（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」本編（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：4.3節と表4-3-1〜表4-3-6（設計レビュー実績工数の密度の基本統計量・層別定義・工数の出所・過去との比較）、表4-1-4（ページあたりの基本設計レビュー指摘件数）を参照。倍率と人時への換算は表の値から計算（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集2022グラフデータ」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000103288.zip）。出典：同じ表の値の確認に使用。著作権はIPAが保有（Copyright 2022 IPA）（2026年9月確認）
