「新年度から使いたい」「繁忙期が始まる前に切り替えたい」。
システム開発では、先に利用開始日が決まっていることがあります。
そのときに知りたいのは、単に「何か月かかるか」だけではありません。希望日に間に合わせるために、いつ相談し、いつ何を決める必要があるかです。
システム開発の期間は、規模や必要な機能によって大きく変わります。
目安として、小規模な開発では1〜3か月程度、中規模では3〜6か月程度、大規模になると6か月以上かかることもあります。
ただし、これはあくまで目安です。開発する機能の数や外部システムとの連携、データ移行の有無などによって、必要な期間は変わります。
さらに注意したいのが、開発期間だけを見ればよいわけではないことです。
開発会社への相談、社内での承認、契約、着手までの待ち時間なども含めて考える必要があります。
この記事では、利用開始日から逆算して、いつ相談し、いつまでに何を決めればよいのかを具体的に説明します。
開発規模ごとの費用や期間の目安については、こちらの記事でも詳しく紹介しています。
システム開発の費用相場は？規模別の目安と、見積もりが2〜3倍変わる理由
最初に「使い始めたい日」の意味をそろえる
希望日を伝える前に、何ができていれば利用開始といえるかを考えましょう。
| 希望日に実現したい状態 | 日程に入れる必要があるもの |
|---|---|
| 一部の担当者が試しに使える | 試行する範囲の開発、確認、利用環境の準備 |
| 新しい業務を一部で始められる | 必要機能の確認、対象者への説明、必要なデータの準備 |
| 全部署が旧システムから切り替えられる | 移行、各部署の確認、操作説明、切り替えの準備 |
同じ日付でも、目指す状態が違えば計画も変わります。
例えば「4月から使いたい」なら、4月に試行を始めたいのか、4月の第1営業日から全員が利用するのかを伝えます。
全員が利用する場合は、その日より前に操作説明やデータの準備を終えておく必要があります。
完成予定日と、業務で使い始める日は同じとは限りません。
開発会社と日付だけを合わせるのではなく、利用開始日にどのような状態になっている必要があるかまで共有することが大切です。
相談開始日は、開発と準備の両方から考える
日程を考えるときの基本は、次のとおりです。
利用開始日から、開発・確認・切り替えに必要な時間と、着手前の準備に必要な時間をさかのぼる。
例えば、着手後の作業に16週間、相談や社内承認などの準備に4週間かかる場合、利用開始の20週間前が相談を始める時期の一つの目安になります。
これは、逆算方法を説明するための例です。実際の期間は、開発する内容や社内の承認手続き、開発会社の着手可能日などによって変わります。
すでに開発会社から「着手後16週間」と言われていても、すぐに着手できるとは限りません。
相談時には、次の2点を確認しましょう。
- 開発を始めてから利用開始まで、どのくらいかかるか
- 最短でいつから着手できるか
この2つを確認することで、希望日から逆算しやすくなります。
利用開始まで20週間ある場合の逆算例
ここでは、ある部署の申請・承認業務をシステム化する例を考えます。
外部連携はなく、移行するデータは少量で、開発担当者を予定どおり確保できると仮定します。
以下は、逆算方法を説明するための一例です。実際の期間は、機能やデータ移行、外部連携などによって変わります。
| 利用開始までの残り期間 | その期間に進めること | 期間の終わりに必要な状態 |
|---|---|---|
| 残り20〜16週間の4週間 | 相談、提案の確認、社内承認、着手の準備 | 開発範囲の大枠と、着手日が合意されている |
| 残り16〜14週間の2週間 | 最初に使う範囲の具体化 | 判断が必要な事項と、回答期限が整理されている |
| 残り14〜11週間の3週間 | 画面や操作の確認 | 実装を進めるために必要な確認が終わっている |
| 残り11〜5週間の6週間 | 実装、途中確認、開発側のテスト | 受入確認を始められる状態になっている |
| 残り5〜2週間の3週間 | 発注側の確認、問題の修正、再確認 | 利用開始を妨げる問題が解消されている |
| 残り2〜0週間の2週間 | データ移行、操作説明、最終確認、切り替え | 対象者が業務で利用できる状態になっている |
「残り20〜16週間」は、4週間の区間を表します。
この例では、着手前の準備に4週間、着手後の作業に16週間を想定しています。
実際には、移行データの整理や操作説明資料の準備を、開発と並行して進められることもあります。
最後の2週間ですべてを準備するのではなく、切り替え前に何がそろっている必要があるかを早い段階で確認してください。
この表で大切なのは、週数をそのまま自社の計画に当てはめることではありません。
利用開始日に必要な状態を後ろから置き、それぞれに必要な日数を開発会社と一緒に埋めていくことです。
開発側の予定に、発注側の期限も重ねる
開発会社のスケジュール表に「画面確認」「受入テスト」と書かれていても、社内で誰もその時間を確保していなければ、確認待ちになることがあります。
発注側でも、次のような予定を同じ表に入れましょう。
| 発注側の予定 | 決めておきたいこと |
|---|---|
| 社内承認 | 決裁する人、必要な資料、承認される日 |
| 画面や操作の確認 | 確認担当者、意見をまとめる人、返答する日 |
| 移行データの準備 | データを集める人、不備を直す人、確定する日 |
| 受入テスト | 実際に確認する人、実施日、結果を返す日 |
| 利用者への説明 | 対象者、説明する人、実施日 |
| 切り替えの判断 | 利用開始を決める人、判断日、問題が残った場合の対応 |
例えば、開発会社が金曜日に確認を依頼し、社内で判断できる会議が翌週木曜日だけなら、その待ち時間も計画に含める必要があります。
担当者が内容を確認できる日と、最終的に承認できる日が違うことにも注意してください。
すべてに一律の回答期限を設定する必要はありません。確認内容の量や関係者に応じて、現実的な期限を決めることが大切です。
システム開発を相談してから発注するまでの流れを確認したい方は、こちらも参考にしてください。
システム開発の発注は何から始める？初めてでも迷わない11ステップと準備するもの
日程に余裕を置く場所を具体的に決める
スケジュールに「予備期間」と書くだけでは、何が起きたときに使う時間なのか分かりません。
次のように、想定する問題と対応する時間をセットで考えます。
- 受入テストで問題が見つかったときの修正と再確認
- 移行の試行でデータの不備が見つかったときの整理と再実施
- 切り替え日に問題があったときの、別の日程への変更
必要な余裕は、システムの重要度や移行の難しさによって変わります。
「すべての案件で2週間」などと一律に決めるのではなく、どのような問題を想定しているかを開発会社と確認しましょう。
また、予備期間を使って希望機能を増やすと、問題が見つかった場合の対応時間が足りなくなることがあります。
追加する機能は、利用開始日への影響を確認してから決めることが大切です。
希望する期間に収まらないときの3つの選択肢
必要な作業を並べてみて希望日に収まらない場合は、「もっと急いでほしい」と伝えるだけでは解決しないことがあります。
1. 最初に利用する範囲を絞る
一つの部署や一つの業務から始める方法です。
例えば、申請登録と承認を先に使い、集計画面は後から追加する案が考えられます。
ただし、単純に機能を減らせばよいわけではありません。
その範囲だけで実際の業務が成立するかを確認し、権限や安全性など必要な部分まで削らないことが大切です。
2. 試行する日と全面的に切り替える日を分ける
希望日には一部の担当者が試行を始め、確認後に対象を広げる方法です。
この場合は、試行中の業務をどこで処理するか、旧システムと新システムのデータをどう扱うかも決める必要があります。
二重入力や運用の混乱が増える場合は、段階的な導入が本当に適しているかも検討してください。
3. 利用開始日を見直す
止められない業務や、移行の失敗が大きな影響を与えるシステムでは、開始日の変更も選択肢です。
必要な確認を残したまま切り替えるよりも、問題を解消する時間を確保した方がよい場合もあります。
開始日を変更する場合は、影響する部署や利用者への案内日も一緒に見直しましょう。
希望するスケジュールで進めるためには、開発会社の選び方も重要です。比較するときのポイントはこちらで紹介しています。
システム開発会社はどう選ぶ？発注前に確認したい8つのポイント
開発会社へ希望時期を伝える例
日程の相談では、「日付」「理由」「最初に必要な状態」を伝えると、開発会社も実現できる範囲を検討しやすくなります。
4月の第1営業日から、営業部で申請登録と上司の承認を使い始めたいと考えています。新年度の業務に合わせたいことが理由です。集計画面は後からの追加でも構いません。受入テストと操作説明を終える日も含めて、いつ着手する必要があるか相談したいです。
これは相談文の例です。正式な期限や業務条件は、自社の状況に合わせて調整してください。
よくある質問
何か月前に相談すればよいですか？
対象範囲が分からない段階では、すべての案件に当てはまる月数を示すことはできません。
まず希望する利用開始日を伝え、次の3点を確認しましょう。
- 着手後にどのくらいの期間が必要か
- 最短でいつ着手できるか
- 社内の承認や準備にどのくらい必要か
納期に業務上の理由がある場合は、その理由も共有すると相談しやすくなります。
データ移行は、完成してから考えてもよいですか？
早い段階で検討することをおすすめします。
元データの状態によっては、整理や移行テストが必要になり、利用開始日に影響するためです。
誰がデータを準備するのか、いつ試しに移行するのかまで決めておくと進めやすくなります。
スケジュールが変わったら、何を確認すればよいですか？
遅れる作業だけでなく、その後の確認日や切り替え日への影響も確認します。
利用開始日を守れるのか、最初に利用する範囲を変える必要があるのか、開始日そのものを見直す必要があるのかを関係者と判断してください。
まとめ
システム開発の期間を考えるときは、単に「開発に何か月かかるか」だけを見るのではなく、利用開始日から逆算して考えることが大切です。
利用開始日に必要な状態を決め、そこから受入テスト、データ移行、操作説明、開発、社内承認、相談開始へとさかのぼって日程を組み立てます。
また、開発会社の作業予定だけでなく、発注側が確認や判断を行う日も同じスケジュールに入れておきましょう。
希望日に収まらない場合は、最初に利用する範囲を絞る、段階的に導入する、利用開始日を見直すといった方法があります。
まずは、次の2点を整理してみてください。
- いつから使い始めたいか
- その日に、誰が何を使える状態にしたいか
この2点が整理できると、開発会社にも具体的な相談をしやすくなります。
希望する時期に向けて、システム開発を相談したい方へ
ニチコマでは、Webシステムや業務システムの開発についてご相談を受け付けています。
「この時期から使い始めたいが、何を先に決めればよいか分からない」という段階でも、希望時期や現在の課題をお聞かせください。
必要な機能や進め方を一緒に検討します。
参考情報
各社が紹介している開発期間は、対象範囲や前提条件によって異なります。この記事内の20週間の逆算例は、考え方を説明するための例です。