LASSIC Media らしくメディア
システム導入のスケジュール表｜工程ごとの期間と延びる理由
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム導入のスケジュール表は、企画から稼働後までの工程に、やること・期間・区切りの承認を並べた表です。
- IPAの集計では全体の工期の中央値が10.1か月で、設計からテストまでの中では製作の比率が最も高くなっています。
- 延びやすいのは要件の追加と待ちの期間なので、変更の手続と承認の日程を先に工程表へ書き込みます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
「年内に稼働できますか」と聞かれても、答える根拠がない。外部から届いた工程表が妥当なのか、比べる物差しもない——。初めてシステム導入を任された担当者には、こうした迷いがつきものです。システム導入のスケジュール表は、企画から稼働後までの工程を並べ、それぞれにかかる期間と区切りの時期を示す表です。
工程表のひな形があれば、全体の流れはつかめます。ただし万能ではなく、日数を埋めただけの表では、どこで延びやすいのか、どこまで縮められるのかが見えません。本記事では、システム導入の計画を初めて立てる担当者に向けて、工程ごとのやることと期間の目安、全体の期間の幅、延びやすい理由と手当て、そして外部に頼むときに確認したい点を整理します。
目次
システム導入のスケジュール表とは
IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」（以下、モデル契約）は、情報システムの取引を企画、開発、運用・保守の段階に分けて整理しています。*3 スケジュール表もこの区切りに沿って工程を並べると、社内の承認や外部との契約の区切りと合わせやすくなります。
- 企画の段階：システム化の方向性、システム化計画、要件定義の順に進みます。「超上流工程」とも呼ばれる部分です
- 選定：パッケージ（既製のソフトウェア）を使う場合に、製品の情報を集めて業務に合うかを比べます
- 開発の段階：設計、製作（プログラムづくり）、テストを進めます
- 移行：疑似の運用環境でテストをしたうえで、実際の運用環境に切り替えます
- 稼働後：運用と保守に入り、不具合の修正や問い合わせへの対応を続けます
スケジュール表の列は、工程・やること・期間・担当・区切りの承認の5つがあれば足ります。抜けやすいのは「区切りの承認」の列です。モデル契約では、要件定義を終えたところで経営層の実行稟議と承認を受ける流れが示されています。*3 承認の時期を表に入れておくと、決裁を待つあいだ工程が止まる日数も見込めます。
工程ごとのやることと期間の目安
工程ごとの期間を数値で示した一次情報に、IPAの「ソフトウェア開発分析データ集2022」があります。企業から集めた開発プロジェクトの実績を集計した資料で、2022年9月の公開、5,546件のデータをもとにしています。*1 工程別の月数は、基本設計から総合テストまでの「開発5工程」がそろった新規開発192件について、5工程の合計に占める比率で示されています。*2
| 工程 | やること | 期間の目安 | 延びやすい理由 |
|---|---|---|---|
| 企画 | 導入の目的、対象の業務、予算、体制、全体の日程の案を決め、経営層の承認を得る | 決め手：関係する部門の数と、承認を得る回数 | 部門どうしの調整と、承認の待ち |
| 要件定義 | 業務の要件と、機能・非機能の要件を決めて要件定義書にまとめる | 決め手：対象の業務の広さと、決める人が集まれる頻度 | 後の設計で、性能や運用の要件が新たに出てくる |
| 選定（パッケージの場合） | 製品の情報を集め、業務に合う部分と合わない部分を比べる | 決め手：比べる製品の数と、試す業務の数 | 合わない部分が見つかり、業務や目標の見直しにさかのぼる |
| 設計 | 画面や帳票などの外部設計と、内部の詳細設計を行う | 開発5工程の月数のうち、基本設計19.0％、詳細設計16.3％（中央値） | 外部設計の承認の後に、要件の追加や仕様の変更が出る |
| 開発（製作） | 設計に沿ってプログラムを作る | 同じく24.4％（中央値） | 設計で決まらなかった点が持ち込まれる |
| テスト | 結合テストと総合テストで、要件を満たすかを確かめる | 結合テスト19.2％、総合テスト17.3％（中央値） | テストデータの受け取りなど、作業が止まる期間 |
| 移行 | 疑似の運用環境で運用テストを行い、実際の運用環境に切り替える | 決め手：移すデータの量と、旧システムを止められる時間 | 移行の要件を後回しにして、手順の準備が遅れる |
| 稼働後 | 運用と保守に入り、不具合の修正や問い合わせに対応する | 決め手：支援を受ける期間と、保守の契約の範囲 | 引き継ぎが足りず、問い合わせが社内で止まる |
設計からテストまでの比率は、工程ごとに別々に求めた中央値なので、足しても100％にはなりません。*2 「開発5工程のうち、どこに時間がかかりやすいか」をつかむ目安として使います。比率が高いのは製作と基本設計で、画面や帳票を決める工程にも、作る工程に近い時間がかかります。企画・要件定義・移行・稼働後は、日数ではなく、何で期間が決まるかを書いています。自社の条件を当てはめて見積もる部分です。
全体の期間はどのくらいか
同じデータ集では、プロジェクト全体の工期の中央値は10.1か月でした。*2 ここでいう全体は、開発5工程に加えて、システム化計画やユーザー側の確認テストを含むことがある期間です。ばらつきは次のとおりです。
- 中央値：10.1か月（1,396件）*2
- 短いほうから4分の1の位置は6.0か月、4分の3の位置は15.0か月
- 1年以内に収まったプロジェクトは、およそ6割
規模が大きいほど期間は延びますが、比例はしません。IPAは、新規開発の工期は工数（作業の量）の3乗根に比例する傾向があるとしています。*2 作業の量が増えても月数はそれほど伸びない一方、人を増やしても月数は縮めにくい、ということです。同じ資料は、工数が500人月の場合でも、半数が収まる範囲で工期に約11〜21か月の幅があると説明しています。*2 計算で出した月数を1点で当てにいくより、幅で持つほうが現実的です。
なお、このデータ集は、数値で進み具合を管理している組織のプロジェクトを多く含む集計です。*2 社内で初めて取り組む導入なら、中央値よりも長めの側を見込んでおくと、計画の見直しが少なくて済みます。
延びやすい理由と手当て
延びる原因は工程ごとに違いますが、型はいくつかに絞れます。モデル契約が取り上げている点を中心に、起きやすい工程と手当てを並べると次のようになります。*3
| 理由 | 起きやすい工程 | 手当て |
|---|---|---|
| 要件の追加・仕様の変更 | 設計から後 | 外部設計の承認の後に出た変更は、変更管理の手続で費用と納期を話し合って決め直す |
| 非機能要件が後から出る | 設計 | 要件定義の段階で、性能・運用・移行の要件まで洗い出しておく |
| セキュリティの仕様が後回し | 設計の後 | 設計が固まりきらなくても、セキュリティの検討を早めに始める |
| パッケージが業務に合わない | 選定 | 合わない点が分かったら、目標や業務の見直しを変更の手続に乗せる |
| 承認やデータを待つ | すべての工程 | 社内の承認の日とデータを渡す日を、工程表に別の行で書く |
見落とされやすいのは、最後の「待ち」です。IPAのデータ集は、顧客のサイン待ちやテストデータの受領待ちのように作業が止まる期間を「非活動期間」とし、総工期から差し引いて活動期間を出す項目を設けています。*2 発注する側の確認や承認が遅れると、作業する人が待つだけの期間が積み上がります。社内の決裁の日程を先に押さえて工程表に書き込んでおけば、この延びは防ぎやすくなります。
外部に頼むときに確認しておきたい点
外部の事業者から工程表を受け取ったら、日数そのものより、前提と区切りを確かめます。IPAのデータ集も、提示された工期が計算式どおりでも、信頼性や性能の要件が厳しい案件では、難易度とリスクを話し合ってスケジュールを見直す使い方を勧めています。*2
- 範囲：工程表が企画から稼働後のどこまでを含むか。移行と稼働後の支援が入っているか
- 前提：発注する側が承認する日、データを渡す日が書かれているか。遅れたときの扱いが決まっているか
- 体制：工程ごとに、社内の誰が確かめて承認するか
- 変更の手続：要件が増えたときに、費用と納期をどう決め直すか
- 引き継ぎ：稼働後の運用と保守に誰が入り、いつまで支援を受けられるか
工程表は、社内の決裁の資料としても使います。要件定義と開発で決裁を区切る書き方はシステム導入の稟議書の書き方で、複数の見積もりを同じ条件で比べる方法はシステム開発の相見積もりの取り方で扱っています。
まとめ：システム導入のスケジュール表で確かめておきたい3つの点
システム導入のスケジュール表を作るうえで、確かめておきたい点は3つに整理できます。第一に、企画から稼働後までの工程を並べ、移行と稼働後の支援まで表に入れること。第二に、期間は1つの数字ではなく幅で持ち、公表された比率や中央値を目安に、自社の条件で決まる部分を見積もること。第三に、変更の手続と、社内の承認やデータを渡す日を工程表に書き込んでおくことです。この3点を踏まえておけば、「稼働の直前になって数か月延びた」という事態を避けやすくなります。工程表の作り方や見積もりの妥当性に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
パッケージを使う場合も、期間の考え方は同じですか
工程の並びは似ていますが、時間のかかる場所が変わります。パッケージでは、製品を選ぶ工程と、業務に合うかを確かめる工程に時間を取ります。合わない部分を作り足す量が多いほど、設計からテストまでの期間も延びます。
スケジュール表はどの形式で作ればよいですか
表計算ソフトでも工程管理のツールでもかまいません。大事なのは形式より列の中身で、工程・やること・期間・担当に加えて、区切りの承認の日と、社内からデータを渡す日を行として入れておくことです。外部の事業者と同じ表を見て更新できる形にしておくと、遅れに早く気づけます。
稼働後はどのくらいの期間、支援を受ければよいですか
決まった期間はなく、契約で決めます。IPAのデータ集は、稼働後6か月間に報告された不具合の数を品質の指標として集めています。*2 支援の期間を決めるときの一つの参考になります。
システム導入の計画づくりのご相談
工程表の作成から、要件定義の支援、移行の計画、稼働後の運用・保守まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：公開日（2022年9月26日）と、5,546プロジェクトの定量データをもとにした分析であることの記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：表1-3-3（プロジェクト全体の月数）、表A3-3-5（工程別の実績月数の比率（新規開発））、A3.3.1（工期と工数の関係）、A4章の利用例（500人月の工期の幅、見積り工数とスケジュールの見直し）、A4.5（本書利用にあたっての注意事項）、アイドリング期間（非活動期間）と発生不具合（稼働後6か月）の定義を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：第二版（2025年4月8日更新）の本文のうち、企画段階・開発段階・保守運用段階の工程の説明、要件定義後の実行稟議、確定見積後の変更管理手続、非機能要件が外部設計の段階で新たに出る場合の注意、セキュリティ仕様の検討を早期に始める必要、パッケージのフィット＆ギャップ評価と変更管理の記述を参照（2026年10月確認）
