システム開発を外注しようとすると、費用と同じくらい早い段階で聞かれるのが「で、いつ使えるようになるの」という質問です。社内から期初に間に合わせてほしいと言われていて、逆算していつ動き出せばいいのかを知りたい。そういう状況で調べ始める方が多いと思います。
先に結論をお伝えします。契約してから稼働までの期間は、小規模なら3か月前後、中規模で6か月から10か月、大規模になると1年を超えます。ただし、この数字だけを持って社内に説明すると、たいてい足りません。実際には会社選定と社内稟議に数か月かかりますし、稼働後に現場が慣れるまでの時間も要ります。この記事では、規模別と工程別の目安を整理したうえで、期間が延びる典型パターンと、提示されたスケジュールが短すぎるときのサインまでをまとめます。
この記事のポイント
- 契約後の期間は小規模3か月前後・中規模6〜10か月・大規模1年超が目安
- 会社選定と社内稟議で契約前に2〜4か月かかることを見落としやすい
- 規模が2倍になっても期間は1.25倍程度にしか延びない
- 機能を半分に削っても期間は2割ほどしか縮まない
目次
システム開発の期間の目安を規模別に見る
調べ始めると、すぐに気づくことがあります。サイトによって書いてある数字がまるで違うのです。まずはその理由から整理します。
どこからどこまでを期間と呼ぶか
小規模開発の目安として「数週間」と書いている記事もあれば、「2〜6か月」と書いている記事もあります。3倍以上の開きです。これは、どちらかが間違っているというより、数えている区間が違うことが原因です。
期間の数え方は、大きく次の3つに分かれます。
| 数え方 | 含まれる範囲 | 誰の視点か |
|---|---|---|
| 製造期間 | 設計が固まってから実装とテストが終わるまで | 開発会社の作業視点 |
| 契約後の期間 | 契約してから稼働判定まで（要件定義を含む） | 一般的な記事で使われる範囲 |
| 社内の体感期間 | やろうと決めてから現場が使いこなすまで | 発注側が本当に知りたい範囲 |
開発会社が「3か月でできます」と言うとき、多くは1つ目か2つ目を指しています。一方で社内の役員が「いつ使えるのか」と聞くときに求めているのは3つ目です。ここがずれたまま話が進むと、稼働時期の認識が数か月単位でずれます。この記事では以降、断りがない限り2つ目の「契約後の期間」で書きます。
規模別の期間の目安
契約後の期間を規模別に整理すると、次のようになります。規模の感覚がつかみにくいと思うので、機能の数と利用者数の目安も添えます。
| 規模 | 目安の内容 | 契約後の期間 | 契約前に必要な期間 |
|---|---|---|---|
| 小規模 | 画面10本前後、1部門で利用、既存業務の置き換え | 2〜4か月 | 1〜2か月 |
| 中規模 | 画面30本前後、複数部門、他システムと連携あり | 6〜10か月 | 2〜3か月 |
| 大規模 | 画面50本以上、全社利用、基幹業務や外部連携を含む | 12か月以上 | 3〜4か月 |
ここで見落とされやすいのが右端の「契約前に必要な期間」です。開発会社を探して、相談して、提案と見積もりをもらって、社内で稟議を通す。この工程に、中規模でも2〜3か月はかかります。期初の4月に稼働させたい中規模案件なら、前年の6月ごろには動き出している計算になります。逆算せずに年明けから探し始めると、その時点でもう間に合いません。
なお、ここに挙げた数字はあくまで一般的な目安です。同じ画面数でも、業務ルールの複雑さ、既存システムとの連携本数、社内で意思決定できる速さによって大きく変わります。実際の判断は、自社の要件にもとづいて出された個別のスケジュールで確認してください。基幹システムの刷新のように既存業務の移行を伴う場合は、基幹システム刷新の期間と遅れる原因のほうが実態に近い目安になります。費用の側から規模感をつかみたい場合はシステム開発の費用相場とあわせて見ると、規模の輪郭がはっきりします。
工程ごとの時間配分
次に、その期間が工程ごとにどう配分されるかを見ます。中規模で8か月のプロジェクトを例にすると、おおよそ次のような形になります。
| 工程 | 期間の目安 | 発注側の作業量 |
|---|---|---|
| 要件定義 | 1.5〜2か月 | 最も多い。ヒアリング対応と意思決定が集中する |
| 基本設計 | 1〜1.5か月 | 多い。画面と帳票のレビューと承認 |
| 詳細設計・実装 | 3〜4か月 | 少ない。質問への回答が中心 |
| テスト | 1〜1.5か月 | 多い。受入テストは発注側が主役 |
| 移行・稼働準備 | 0.5〜1か月 | 多い。データ移行の確認と操作説明 |
注目してほしいのは右端です。発注側の作業は、前半の要件定義と後半のテスト以降に集中します。実装期間は開発会社が動いている時間なので、こちらは比較的余裕があります。つまり、担当者の予定を空けておくべきなのは最初と最後で、真ん中ではありません。ここを勘違いして、要件定義の時期に別の繁忙期を重ねてしまうと、回答待ちで全体が止まります。各工程で何が作られ、発注側が何を承認するのかは、システム開発の工程と流れで工程別に整理しています。
規模が倍でも期間は倍にならない
ここからは、あまり語られていないけれど発注側にとって非常に重要な話をします。期間と作業量の関係です。
直感的には、作る量が2倍になれば期間も2倍かかりそうに思えます。ところが実際はそうなりません。人を並行して投入できるため、作業量が増えても期間はそこまで延びないのです。独立行政法人情報処理推進機構が公開しているソフトウェア開発データ白書のよくある質問では、開発5工程の工期について、工期は工数のおよそ0.32乗に比例する傾向があると説明されています。データ白書2018-2019版を基準とした記述で、現在はアーカイブとして公開されている点には注意が必要ですが、傾向として押さえておく価値はあります。
この関係を、発注側が使いやすい倍率に直すと次のようになります。
| 作業量が変わると | 期間はどうなるか | 発注側にとっての意味 |
|---|---|---|
| 2倍になる | 約1.25倍 | 規模が倍でも期間は25%増しで済む |
| 4倍になる | 約1.56倍 | 大規模でも期間は思ったほど延びない |
| 半分に減らす | 約0.80倍 | 機能を半分に削っても2割しか縮まない |
実務で効いてくるのは3行目です。納期が厳しくなったとき、発注側はよく「機能を半分に削るので、その分早めてほしい」と持ちかけます。ところがこの関係にしたがえば、機能を半分にしても期間は2割ほどしか縮みません。要件定義もテストも移行も、機能数に単純比例しては減らないからです。削る交渉が無意味という話ではありませんが、期待する効果と実際の効果には大きな差があります。
同じ理屈で、「予算を増やすから人を足して早めてほしい」もほとんど効きません。人を倍にして作業量を消化できたとしても、期間の短縮は2割程度が限界です。しかも増員した人が仕様を理解するまでの時間が別にかかるため、実際にはさらに縮みにくくなります。私の感覚では、期間を本気で縮めたいなら、機能を削るより先に「稼働範囲を分ける」ほうが現実的です。第1弾で業務が回る最小限だけを出し、残りを第2弾に回す。これなら最初の稼働日は確実に前倒しできます。
システム開発の期間が延びる理由と発注側の備え
目安が分かったところで、その目安から外れる理由を見ていきます。ここを知っておくと、提示されたスケジュールの読み方が変わります。
期間が延びる典型パターン
遅れの原因は、開発会社の作業が遅いことよりも、発注側の動きに起因することのほうが多いというのが実感です。よくあるのは次の4つです。
- 質問への回答が滞る。持ち帰って社内確認している間、開発が止まる
- 要件が後から追加される。「ついでにこれも」が積み上がる
- 受入テストで大量に差し戻す。要件定義で詰め切れていなかった分が表面化する
- 自社側の作業が計画に入っていない。マスタ整備やデータ整理が想定外の負荷になる
4つ目は特に見落とされます。既存データの名寄せや商品マスタの整理は、開発会社では代行できません。誰がいつやるのかを決めないまま進むと、稼働直前になって数週間分の作業が残っていることが判明します。工程表に自社の作業が1行も載っていないなら、その工程表はまだ完成していないと考えたほうが安全です。
提示された期間が短すぎるサイン
逆に、開発会社から出てきたスケジュールが短すぎる場合もあります。受注したい気持ちから楽観的に引かれていることもあれば、単に発注側の作業が計算に入っていないだけのこともあります。次のような形になっていたら、一度確認したほうがよいサインです。
| 見えているサイン | 疑うべきこと | 確認する質問 |
|---|---|---|
| テスト期間が実装の2割未満 | 不具合が出た場合の余裕がない | 不具合が想定より多かった場合はどう吸収しますか |
| 要件定義が2〜3週間で終わる | 要件を固めきらずに設計へ進む前提 | 要件が固まらなかった場合の扱いはどうなりますか |
| 自社の確認期間が書かれていない | レビューや受入テストの日数が未計上 | 弊社が確認に使える日数はどこに入っていますか |
| 移行と操作説明の記載がない | 稼働準備が範囲外になっている可能性 | データ移行と操作説明は誰の作業になりますか |
これらは相手を疑うための質問ではなく、前提をそろえるための質問です。早い段階で聞いておくほど、開発会社も正直な数字を出しやすくなります。見積もりとスケジュールはセットで届くことが多いので、金額の妥当性とあわせて点検すると効率がよいです。システム開発見積もりチェックシートでは、危険サインを項目ごとに確認できます。
逆算して動き出す時期を決める
最後に、実務としての使い方です。多くの場合、稼働したい時期のほうが先に決まっています。期初の4月から使いたい、繁忙期前の9月までに切り替えたい、といった形です。そこから逆算します。
中規模で契約後8か月、契約前に3か月かかるとすると、稼働の11か月前が動き出しの目安になります。4月稼働なら前年5月です。ここに、稼働直後の並行運用や現場が慣れるまでの期間を考えると、もう少し前倒ししておくと安心です。ずいぶん早いと感じるかもしれませんが、会社選定と稟議は思った以上に時間を使います。
逆に、どうしても時期が動かせない場合は、期間を縮めるのではなく範囲を分けます。前の章で触れたとおり、機能を削っても期間は2割ほどしか縮みませんが、稼働を2段階に分ければ最初の稼働日は確実に前倒しできます。どちらの打ち手を取るにしても、早めに開発会社へ相談したほうが選択肢は多く残ります。
システム開発の期間に関するよくある質問
- Q. 要件定義にはどれくらいの期間をかけるべきですか？
- A. 契約後の全期間のうち、2割前後を要件定義に充てるのが一つの目安です。中規模で8か月なら1.5〜2か月ほどになります。ここを短く見積もると、設計以降で仕様の確認が繰り返し発生し、結果として全体が延びます。逆に、発注側の意思決定が速い会社では短く収まることもあります。決裁者が打ち合わせに同席できるかどうかで、必要な期間はかなり変わります。
- Q. 提示された開発期間が短すぎる気がします。どう判断すればいいですか？
- A. 工程表の中で、自社が確認に使える日数が明記されているかを見てください。レビューや受入テストの期間がゼロ、あるいは数日しか取られていない場合、その工程表は発注側の作業を計算に入れていません。テスト期間が実装期間の2割を下回っている場合も、不具合が想定より多かったときに吸収する余裕がない状態です。どちらも、責める前に「この日数はどういう前提で置いていますか」と聞くところから始めるのが穏当です。
- Q. 人を増やしてもらえば期間は縮まりますか？
- A. ほとんど縮みません。作業量と期間の関係から見ると、投入量を2倍にしても期間の短縮は2割程度が上限です。さらに、増員した人が仕様を理解するまでの時間が別にかかるため、途中からの増員はむしろ既存メンバーの手を止めることもあります。期間を前倒ししたい場合は、人を足すより稼働を2段階に分けるほうが確実です。
