LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

リリース日が迫ってきたので、人を増やして追い込もうとした。あるいは、増やしたのに日程が1日も縮まらなかった——。リリース前の局面では、多くの現場が「増員で縮む残り日数はどれだけか」に突き当たります。手がかりになるのが、IPA（独立行政法人情報処理推進機構）が公開している「ソフトウェア開発分析データ集」です。案件の工期を記録するときに、手が動いていない期間を分けて数えるよう定めています。*1

この分け方を使えば、残り日数のうち増員で埋まる部分がどれだけかを先に確かめられます。ただし万能ではなく、どれだけの期間になるのが普通かは書かれていませんし、待ちを短くする手立ても載っていません。本記事では、開発の現場を預かるマネージャに向けて、IPAが記録しているリリース前の項目、2つの総合テストの違い、なぜ増員では縮まない日があるのか、どう見積もるのか、つまずきやすい点、そして外注の勘所を整理します。

IPAが記録しているリリース前の項目

IPAの「ソフトウェア開発分析データ集2022」は、企業から提供された開発案件の実績を集計した資料です。発行は社会基盤センターで、案件ごとに集める項目が1つずつ定義されています。*1 リリース前に関わる項目は、工期の節と品質の節に分かれて並んでいます。*1

工期の側で目を引くのが806番の「アイドリング期間」です。定義は「プロジェクトの非活動期間月数（例．顧客のサイン待ち、テストデータの受領待ち）」で、「この月数をプロジェクトの総工期から引くと、プロジェクトの活動期間が算出される」と書かれています。*1

実際、プロジェクト全体工期（実績）の月数は「プロジェクト終了年月日（実績）－プロジェクト開始年月日（実績）－アイドリング期間」で自動計算されます。*1 待っていた期間は、はじめから工期に数えない作りになっています。

2つの総合テストの違い

品質の側では、総合テストが2つの項目に分かれています。片方は、ユーザが主導するものです。*1

ユーザが主導するほうには、範囲がはっきり書かれています。「出荷後からサービスインまでの間に実施されるユーザ主導の総合テスト（受入れテストを含む）を対象とする」。*1 出荷してからサービスインまでに、もう一段テストがある前提です。

どちらも、検出バグを現象数と原因数の両方で数えます。*1 ユーザが主導するほうはさらに重大・中度・軽微に分けて記録します。*1 リリース前に出たバグを「何件」とだけ数えていると、この資料の粒度には届きません。

なお、ここでいう検出バグ現象数と検出バグ原因数はソフトウェアに起因するものを指す、と両方に補足が付いています。*1 環境の設定やデータの不備で止まったものは含みません。

なぜ増員では縮まない日があるのか

残り日数を一様に扱うと、増員の効果を読み違えます。手が動いている日は人を増やした分だけ進みますが、サインを待っている日やテストデータの到着を待っている日は、何人いても進みません。

IPAが非活動期間を別に数えているのは、その2つを混ぜると案件どうしを比べられなくなるからだと考えられます。ただし、この理由は資料に書かれているものではありません。書かれているのは、総工期から引いて活動期間を出す、という計算までです。

同じことがユーザが主導する総合テストにも当てはまります。主導するのはユーザ側なので、こちらが人を増やしても日程は動きません。増員で埋まるのは、そこで出たバグを直す時間のほうです。

どう見積もるのか

見積もり方は、リリースまでの残り日数を2つに割るところから始めます。手が動いている日と、待っている日です。カレンダーに線を引く前に、この2つを別々に数えてください。

待っている日については、中身を書き出します。誰の何を待っているのか。顧客のサイン待ちなのか、テストデータの受領待ちなのか、別部門の確認待ちなのか。相手と待ち物が書けたら、そこは段取りで動かす部分です。

手が動いている日だけが、増員で埋まる部分になります。その日数に対して、いま何人で何を進めているのかを並べれば、何人ぶん足りないのかが出ます。残り日数の全体に人数を掛けると、実際より多い見積もりになります。

つまずきやすい難所

一つめは、アイドリング期間を遅れと同じに扱うことです。資料は非活動期間として総工期から引く扱いにしており、遅れかどうかの判断は含まれていません。

二つめは、ユーザが主導する総合テストを自社の工程として数えることです。定義はユーザ主導と書かれており、受入れテストを含みます。*1 日程を自社だけで決められる工程ではありません。

三つめは、この項目に期間の目安を求めることです。アイドリング期間は月数を記入する欄で、どれだけの月数になるのが普通かは含まれていません。

外注時に確認しておきたい点

外部の要員に入ってもらうなら、手が動いている日に当たる作業を書き出します。「受入れテストで出た重大なバグの修正を2週間」といった粒度で構いません。外部の要員（フリーランスを含む業務委託）は、作業と期間がはっきりしているほど合わせやすい調達の仕方になります。

リリース前は着任から戦力になるまでの時間が取れません。現行の仕様を読み解くところから任せるのは難しいので、再現手順と直す箇所が特定できているバグを渡すほうが現実的です。何を渡せるかは、バグを重大・中度・軽微に分けておけば選びやすくなります。

一方、リリースの日程を動かすかどうかの判断は社内に残してください。ここを社外に委ねると、待ちの期間とバグの残り具合のどちらで押しているのかを判断する人がいなくなります。正社員の採用と外部の要員のどちらを選ぶかも、この判断が社内にあるかで変わります。

テストの人手不足をスキルと人数に分ける話は外部エンジニアのテスト体制、IPAが定める4つの区分にあります。同じ資料の別の項目です。

稼動後に出た不具合の数え方は性能改善とは｜IPAの定義は応答時間から資源使用量までで扱っています。

日程が押したときの切り分けは開発遅延の要因は社員のスキル不足が46.5％を占めるにあります。

誰が何をできるかを社内で把握する話はスキルマップの整備の違い、未対応42.8％と整備済み33.7％にあります。

まとめ：リリース前の増員で押さえる3つの視点

リリース前の残り日数は、一様ではありません。押さえておきたい視点は3つに整理できます。第一に、IPAは顧客のサイン待ちやテストデータの受領待ちを「非活動期間」として定義し、総工期から引いて活動期間を出すこと。*1 第二に、リリース前の総合テストは2つの項目に分かれ、後者は出荷後からサービスインまでのユーザ主導の総合テスト（受入れテストを含む）だと範囲が書かれていること。*1 第三に、ユーザ主導のほうの検出バグは重大・中度・軽微に分け、現象数と原因数の両方で記録することです。*1 この3点を踏まえておけば、「人を増やしたのに日程が1日も縮まらなかった」という事態を避けやすくなります。残り日数を手が動く日と待つ日に割り、待ちの中身を書き出すところまでは社内でできます。その先、手が動く日の人数が足りなければ、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。A5.2.9「工期」のデータ項目806_アイドリング期間、プロジェクト全体工期（実績）、およびA5.2.11「品質」のデータ項目総合テスト（ユーザ確認）の検出バグ数（定義・回答内容・補足説明）の一次情報として。本書の著作権はIPAが保有し無断の改変や公衆送信などは禁じられているため、この記事は示された定義を引用し、図と表は定義をもとに筆者が作成した。資料の図表そのものは複製していない（2026年9月確認）
2. *2　参考：IPA「ソフトウェア開発分析データ集2022」（公開ページ）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本編と業種編・サマリー版という構成と、収録されている指標の範囲の確認として（2026年9月確認）
3. *3　参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されていることの確認として（2026年9月確認）

Tweet