システム導入のスケジュール｜選定から本稼働までの進め方

2026年10月24日

＠SOHO編集部

この記事のポイント

✓システム導入のスケジュールを
✓本稼働まで工程ごとに整理しました
✓クラウドと独自開発の期間の目安

会計や販売管理、勤怠管理などのシステムを新しく入れることになり、いつまでに何を決めればよいのか、全体のスケジュールを引くよう任された。システム導入の経験がないと、どの工程にどれくらいの時間がかかるのか見当がつかず、手が止まってしまいます。

結論を先に書くと、システム導入のスケジュールは「目的の整理」「選定」「要件定義」「設定と開発」「テスト」「データ移行と教育」「本稼働」の7つの工程に分け、本稼働の日から逆算して組むのが基本です。クラウドのサービスをそのまま使う場合でも、目的の整理から本稼働まで3か月から6か月、独自に開発する場合は半年から1年以上を見ておくと、無理のない日程になります。

この記事では、工程ごとにやることと期間の目安、スケジュール表の作り方、遅れやすい工程と対策、補助金を使う場合の日程の組み方までを順に説明します。導入の作業を複数人で分担し、担当と期限を共有したい場合に使えるPinatecaのようなプロジェクト管理の道具にも、後半で触れます。

システム導入の全体の流れ

システム導入は、大きく次の7つの工程で進みます。工程の名前は会社やベンダーによって少しずつ違いますが、中身はおおむね共通しています。

工程	主にやること	主な担当
1 目的の整理	導入する理由、解決したい課題、対象の業務と部署を決める	自社
2 選定	候補のサービスやベンダーを比べ、見積と提案を受けて決める	自社
3 要件定義	システムでできるようにすることを、具体的に書き出して合意する	自社とベンダー
4 設定と開発	画面や帳票の設定、必要なら追加の開発を行う	ベンダー中心
5 テスト	実際の業務の流れで動かし、不具合や使いにくい点を直す	自社とベンダー
6 データ移行と教育	今のデータを移し、使う人に操作を教える	自社とベンダー
7 本稼働	新しいシステムで業務を始め、問い合わせに対応する	自社とベンダー

ベンダーとは、システムを提供したり開発したりする会社のことです。クラウドのサービスを使う場合は、そのサービスを提供する会社や、導入を手伝う販売代理店がベンダーにあたります。

この流れの最初の工程について、システム導入を扱う記事は次のように説明しています。

システム導入の最初のステップは、目的の定義と課題の整理です。これは、後の方向性を決定する上で非常に重要な作業となります。まずは、なぜシステムを導入したいのか、どんな課題を解決したいのかを明確にします。その上で、現状の業務フローを整理して問題点を洗い出し、実際にどの部門や業務について導入するのかを決定します。出典: bqey.com（システム導入の流れとスケジュール）

スケジュールを組むときに大事なのは、1から3の工程を自社が主体になって進めることです。4の設定と開発はベンダーが中心になりますが、1から3の決定が遅れると、ベンダーは作業を始められません。システム導入の遅れの多くは、ベンダーの作業ではなく、発注する側の決定の遅れから生まれます。

クラウドと独自開発で変わる期間の目安

システム導入にかかる期間は、どの形で導入するかによって大きく変わります。

導入の形	内容	目的の整理から本稼働までの目安
クラウドのサービスをそのまま使う	提供されている機能と設定の範囲で使う	3か月から6か月
クラウドのサービスに追加の開発を加える	足りない機能を連携や追加の開発で補う	6か月から9か月
パッケージのソフトを入れて調整する	既製のソフトを自社に合わせて設定と改修をする	6か月から1年
独自に開発する	自社のためにゼロから作る	1年以上

この表の期間は、従業員が数十人から数百人規模の会社で、1つの業務のシステムを入れる場合の目安です。対象の部署が多い場合や、複数のシステムを同時に入れ替える場合は、さらに長くなります。逆に、数人の会社で月額制のサービスを使い始めるだけなら、1か月程度で本稼働できることもあります。

期間を短くしたい場合に最も効果があるのは、独自の開発や改修を減らし、サービスに用意されている機能に業務を合わせることです。追加の開発が1つ増えるごとに、要件定義、開発、テストの時間がそれぞれ延びます。「今の業務のやり方をそのままシステムにする」のではなく、「サービスの標準の使い方に業務を寄せる」と決められるかどうかで、スケジュールは大きく変わります。

社内の体制を先に決める

スケジュールを引く前に、誰がこの導入を進めるのかを決めておきます。体制が決まらないままスケジュールだけを作っても、決定の日に決める人がいなければ、その日は守れません。

役割	主な仕事	選び方の目安
責任者	予算と本稼働の日を決め、部署の間の意見が割れたときに最終的に決める	対象の業務を持つ部署の部長や役員
推進の担当	スケジュール表を管理し、ベンダーとの窓口になり、進み具合を報告する	業務とITの両方を少しずつ分かる人
各部署の担当	自部署の要望をまとめ、テストに参加し、部署内に使い方を広める	実際にその業務を毎日している人
ベンダーの担当	設定と開発、テストの支援、移行と教育の支援を行う	契約の際に担当者の名前を確かめる

推進の担当は、ほかの仕事と兼ねることが多い役割です。兼務の場合は、導入の作業にあてる時間を週に何時間と決め、上司の了解を取っておきます。導入の作業は、日々の業務に押されて後回しになりやすいからです。

各部署の担当には、要件定義とテストの時期に時間を割いてもらう必要があります。スケジュール表を作った段階で、各部署の担当が忙しくなる時期と重ならないかを確かめ、重なる場合は前後にずらします。月末や決算の時期にテストを入れると、担当者が参加できず、テストの質が下がります。

スケジュールに入れ忘れやすい作業

システム導入のスケジュールを作ると、7つの工程の大きな作業は書けても、細かい作業が抜けがちです。抜けた作業は、本稼働の直前になって慌てて行うことになり、遅れの原因になります。

入れ忘れやすい作業	入れる時期	抜けたときに起こること
社内の稟議と契約の手続き	選定の終わり	導入先が決まっても契約が結べず、開発が始まらない
利用者のアカウントと権限の一覧づくり	設定と開発の時期	本稼働の日にログインできない人が出る
取引先や顧客への切り替えのお知らせ	本稼働の1か月前	請求書や注文の形式が変わったことに相手が戸惑う
古いシステムの解約の手続き	本稼働の2か月から3か月前	解約の期限を過ぎて、使わない月の料金がかかる
手順書と問い合わせ窓口の準備	教育の前	本稼働の直後に同じ質問が何度も来る
パソコンやネットワークの確認	選定の後	古いパソコンや通信の環境で動かないことが分かる

特に注意したいのは、古いシステムの解約の手続きです。年間契約のサービスは、更新日の1か月から3か月前までに解約を申し出ないと自動で更新されることがあります。今のシステムの契約書を早めに確かめ、解約の期限をスケジュール表に書き込んでおきます。

工程ごとにやることと期間の目安

ここからは、クラウドのサービスに一部の追加の開発を加える場合を例に、工程ごとにやることと期間の目安を説明します。

1 目的の整理（2週間から1か月）

なぜシステムを入れるのかを、数字で言える形にします。「業務を効率化したい」では、選定のときに候補を比べる基準になりません。「月末の請求書の作成に3人で4日かかっているのを、2人で1日にしたい」のように、今の状態と目標を数字で書きます。

目的を数字で書く例を挙げます。

導入するもの	あいまいな目的	数字で書いた目的
勤怠管理	勤怠の集計を楽にしたい	月末の集計にかかる2日を半日にする
販売管理	受注の管理を効率化したい	受注から出荷の指示までの時間を1日から当日中にする
経費精算	紙の申請をなくしたい	申請から支払いまでの日数を14日から7日にする
顧客管理	顧客の情報を共有したい	担当者の不在時の問い合わせに、その日のうちに答えられるようにする

数字で書いた目的は、選定のときに候補を比べる基準になり、本稼働の後には効果を測る物差しになります。数字が分からない場合は、目的の整理の期間中に、今の業務に何時間かかっているかを1週間ほど記録して測っておきます。

あわせて、対象の業務と部署、使う人の人数、今使っているシステムや表計算のファイル、予算の上限、本稼働の希望の時期を決めます。本稼働の時期は、決算期や繁忙期を避けて決めます。会計のシステムなら期の初め、勤怠のシステムなら給与の締め日の切り替わりに合わせると、データの切り替えが楽になります。

2 選定（1か月から2か月）

候補のサービスを3社から5社程度に絞り、資料の請求、説明の依頼、無料の試用を行います。試用では、実際の業務のデータに近いものを10件ほど入れてみて、操作の分かりやすさと、自社の業務に足りない機能がないかを確かめます。

候補を比べるときは、機能だけでなく、月額の料金と初期費用、導入の支援の内容、問い合わせの窓口、データの書き出しができるかどうかも比べます。データの書き出しは、将来別のサービスに乗り換えるときに必要になります。料金や機能は改定されることが多いので、比べるときは各社の公式の料金ページを開いて、その日時点の記載を確かめます。

3 要件定義（1か月から2か月）

要件定義とは、システムでできるようにすることを具体的に書き出し、自社とベンダーで合意する工程のことです。画面の項目、帳票の形式、ほかのシステムとの連携、権限の分け方などを決めます。

要件定義の結果は、文書にして双方で確認します。この文書に書かれていないことは、後から追加で頼むと費用と期間が増えるのが普通です。テストの段階で「この機能もあると思っていた」と気づいても、要件定義で決めていなければ、ベンダーには対応する義務がない場合があります。

4 設定と開発（1か月から3か月）

ベンダーが、要件定義で決めた内容に沿って設定と開発を行います。この工程は、発注する側の作業が少ない時期ですが、何もしなくてよいわけではありません。ベンダーからの質問に早く答えること、途中の画面を見せてもらって認識のずれを早めに直すことが、自社の役目です。

この時期に、次の工程のテストで使う業務の流れの一覧と、移行するデータの準備を始めておくと、後の工程が詰まりません。

5 テスト（2週間から1か月）

テストでは、実際の業務の流れに沿ってシステムを動かし、決めたとおりに動くか、使いにくい点がないかを確かめます。

システム導入のテスト運用は、開発されたシステムが計画通りの要件を満たしているか、導入目的に合致しているかを確認するために不可欠です。試運用では実業務の流れの中でシステムを利用し、実際の環境で問題なく利用できるかを確認します。この段階では、不具合やバグの発見、システムの操作性やパフォーマンス、安定性の評価が重要です。出典: bqey.com（システム導入の流れとスケジュール）

テストは、ベンダーに任せきりにせず、実際にそのシステムを使う部署の人に参加してもらいます。毎日その業務をしている人でないと気づけない使いにくさがあるからです。

6 データ移行と教育（2週間から1か月）

今のシステムや表計算のファイルから、新しいシステムにデータを移します。取引先の一覧、商品の一覧、過去の取引の記録など、移すデータの範囲を決め、形式をそろえてから移します。古いデータには、表記の揺れや重複が含まれていることが多く、その整理に予想以上の時間がかかります。

使う人への教育も、この時期に行います。操作の説明会を開き、よく使う操作の手順書を用意します。説明会は本稼働の直前に行うと、内容を忘れないうちに使い始められます。

7 本稼働（初日から1か月）

新しいシステムで業務を始めます。本稼働の直後は、操作の質問や想定していなかった不具合が集中するので、問い合わせを受ける担当を決め、ベンダーにも支援をお願いしておきます。

今のシステムをすぐに止めず、1か月ほど新旧を並べて動かす方法もあります。手間は増えますが、新しいシステムに問題があったときに業務を止めずに済みます。

予備の期間をどれくらい取るか

スケジュールには、遅れを吸収するための予備の期間を必ず入れます。予備の期間がないスケジュールは、どこか1つの作業が数日遅れただけで、本稼働の日を守れなくなります。

目安として、全体の期間の1割から2割を予備の期間にあてます。半年の導入なら、3週間から5週間ほどです。予備の期間は、最後にまとめて取るよりも、遅れやすい要件定義の後とテストの後に分けて入れるほうが使いやすくなります。予備の期間を使わずに済んだ場合は、テストを追加で行ったり、教育の回数を増やしたりする時間にあてられます。

スケジュール表の作り方

工程と期間の目安が分かったら、スケジュール表に落とし込みます。表計算のソフトで作る場合は、次の手順で進めます。

本稼働の日を最初に決め、表の右端に書く
7つの工程を縦に並べ、それぞれの期間の目安を当てはめて、本稼働の日から逆算して開始日と終了日を決める
工程ごとに、さらに細かい作業を書き出し、担当者と期限を付ける
自社が決めなければならない日（選定の決定、要件定義の承認、テストの合格の判断）を「決定日」として目立たせる
工程の間に、1週間から2週間の予備の期間を入れる

横軸に週を並べ、作業の期間を色で塗ると、ガントチャートと呼ばれる形の表になります。ガントチャートとは、作業ごとの期間を横棒のような帯で表し、工程の重なりと順番をひと目で分かるようにした表のことです。

例として、本稼働を2027年10月1日とした場合の逆算のスケジュールを示します。

工程	期間	開始	終了	自社の決定日
目的の整理	1か月	2027年3月1日	3月31日	3月31日目的と予算の決定
選定	1.5か月	4月1日	5月15日	5月15日導入するサービスの決定
要件定義	1.5か月	5月17日	6月30日	6月30日要件定義書の承認
設定と開発	2か月	7月1日	8月31日
テスト	3週間	9月1日	9月21日	9月21日本稼働の可否の判断
データ移行と教育	1週間	9月22日	9月30日
本稼働		10月1日

表の右端の「自社の決定日」の列は、ベンダーの作業ではなく、自社の誰かが判断しなければならない日です。この日を責任者の予定に先に入れておくと、決定が先送りされるのを防げます。

この例では工程の間の予備の期間を入れていないので、実際にはテストと移行の前後に1週間ずつ余裕を持たせるか、本稼働の日を後ろにずらせるようにしておきます。

小さな会社でクラウドのサービスを入れる場合の日程

従業員が10人前後の会社で、月額制のクラウドのサービスを追加の開発なしで使い始める場合は、7つの工程をもっと短くまとめられます。

週	やること
1週目	目的と予算を決め、候補を3社に絞る
2週目から3週目	3社の無料の試用で、実際の業務のデータを10件ほど入れて比べる
4週目	導入するサービスを決め、申し込む
5週目	初期設定（会社の情報、利用者、権限、帳票の形式）を行う
6週目	取引先の一覧などのデータを移し、数件の業務で試しに使う
7週目	使う人に操作を説明し、手順書を共有する
8週目	本稼働

この規模なら、要件定義を文書にまとめる代わりに、試用の段階で「この業務がこの画面でできるか」を一つずつ確かめる形で十分です。追加の開発をしない分、設定とテストを同時に進められます。

ただし、短い日程でも、本稼働の日を月の途中にするか月初にするかは考えておきます。請求や給与のように月単位で締める業務は、月の途中で切り替えると、1か月のデータが2つのシステムに分かれてしまいます。月初や期初に本稼働を合わせると、集計が分かれずに済みます。

ベンダーとの打ち合わせと進み具合の確かめ方

設定と開発の工程に入ると、作業の中心はベンダーに移ります。この時期に自社の側が進み具合をつかめていないと、テストの直前になって大きな遅れが見つかることがあります。

ベンダーとは、週に1回か2週に1回、30分から1時間の定例の打ち合わせを持つのが一般的です。打ち合わせでは、次の4点を毎回確かめます。

予定どおりに終わった作業と、遅れている作業
遅れている作業の理由と、取り戻すための手立て
自社が答えるべき質問と、その回答の期限
次の打ち合わせまでに双方がやること

3つ目の「自社が答えるべき質問」は、遅れの原因になりやすい項目です。ベンダーから質問が来たまま社内で回答が止まっていると、その間ベンダーの作業も止まります。質問の一覧に回答の期限を付け、推進の担当が毎週確かめると、回答の遅れを防げます。

打ち合わせで決まったことは、その日のうちに議事録にまとめ、ベンダーと共有します。口頭で決めたことは、後から「言った」「言わない」の食い違いになりやすいからです。

遅れやすい工程と、その対策

システム導入のスケジュールが遅れる原因は、だいたい決まっています。

遅れやすい場面	よくある原因	対策
選定が決まらない	比べる基準が決まっていない	目的の整理で数字の目標を決め、基準を先に書く
要件定義が終わらない	部署ごとの要望が出続ける	決定する人を1人決め、要望には優先順位を付ける
開発の途中で仕様が変わる	要件定義のときに現場の人が参加していない	要件定義に実際に使う人を入れる
テストで不具合が多い	テストの準備が遅く、確かめる範囲が狭い	開発の時期にテストの一覧を作っておく
データ移行が終わらない	古いデータの整理に時間がかかる	移すデータの範囲を絞り、整理を早めに始める

最も影響が大きいのは、要件定義の段階での決定の遅れです。部署ごとに「この機能も欲しい」「今の帳票と同じ形にしてほしい」という要望が出るのは自然なことですが、すべてを受け入れると、要件定義はいつまでも終わりません。要望には「本稼働までに必須」「本稼働の後に検討」の2つの印を付け、必須でないものは後回しにすると決めておくと、スケジュールを守りやすくなります。

システム導入の失敗の多くは、技術的な問題よりも、目的があいまいなまま始めたこと、現場の人を巻き込まなかったこと、決定する人が決まっていなかったことに由来します。スケジュール表を作るときに、技術の作業だけでなく、自社の決定の日と決定する人を書き込んでおくことが、何よりの対策になります。

テストとデータ移行の準備を早めに始める

スケジュールの後半で遅れが出やすいのは、テストとデータ移行です。どちらも、設定と開発の工程のあいだに準備を始めておくと、後半の日程に余裕が生まれます。

テストの準備では、確かめる業務の流れを一覧にします。一覧の行ごとに「誰が」「どの画面で」「何をして」「どうなれば合格か」を書いておくと、テストの当日に迷わずに進められます。

業務の流れ	操作する人	確かめること	合格の条件
新しい取引先を登録する	営業事務	必須の項目が入力できるか	登録した内容が一覧に表示される
見積から受注に切り替える	営業	見積の内容が受注に引き継がれるか	金額と品目が一致する
月末に請求書を発行する	経理	締め日で正しく集計されるか	手計算の結果と一致する
権限のない人が金額を変えようとする	営業	変更が止められるか	変更できない旨が表示される

最後の行のように、「できてはいけないこと」が止められるかも確かめます。権限の設定の誤りは、普段の業務の流れのテストだけでは見つかりにくいからです。

データ移行の準備では、移すデータの範囲を先に決めます。過去の取引の記録をすべて移すのか、直近の数年に絞るのかで、作業の量は大きく変わります。古い記録は今のシステムから書き出して保管し、新しいシステムには直近の分だけを移す方法もあります。移すデータは、表記の揺れ（「株式会社」と「（株）」など）や重複を事前に整えておきます。この整理を移行の直前に始めると、本稼働の日に間に合わなくなることがあります。

補助金を使う場合の日程の組み方

中小企業がシステムを導入するときは、国の補助金を使える場合があります。代表的なものが、中小企業基盤整備機構の「デジタル化・AI導入補助金」です。2025年までの「IT導入補助金」が名前を変えたもので、事前に登録されたITツールを導入する費用の一部が補助されます。

デジタル化・AI導入補助金2026の公式サイトによると、通常枠の補助率は2分の1以内（条件を満たす場合は3分の2以内）で、補助額は業務の工程の数に応じて5万円以上450万円以下です。申請は締切ごとに受け付けられ、事業スケジュールのページでは、たとえば2026年12月1日（火）締切の分は、交付決定が2027年1月19日（火）の予定、事業実施期間は交付決定から2027年7月30日（金）までの予定となっています。

補助金を使う場合、スケジュールの組み方で特に気をつけたいのは次の点です。

補助金の対象になるのは、事業実施期間、つまり交付決定の後に契約し、導入した分です。公募要領でも、交付決定前に契約、発注、納品、支払いなどを行った場合は補助金を受けられないとされています。選定の工程で契約を急がない
申請は、IT導入支援事業者として登録されたベンダーと一緒に行う。選定の候補に、登録された事業者とツールが含まれているかを確かめる
事業実施期間の終わりまでに、導入と支払いと実績の報告を終える必要がある。設定と開発、テスト、本稼働をこの期間に収める
締切から交付決定まで1か月半ほどかかるので、その間に要件定義を進めておく

補助金を使うかどうかは、目的の整理の段階で決めておきます。使うと決めた場合は、締切と交付決定の予定日をスケジュール表に書き込み、契約の日を交付決定の後に合わせます。

補助金の制度は年度ごとに見直されるので、申請を考えるときは、公式サイトの事業スケジュールと公募要領で、その時点の内容を確かめてください。

導入の作業を複数人で分担するとき

システム導入では、総務、経理、現場の部署、情報システムの担当など、複数の部署の人が作業を分担します。スケジュール表を表計算のファイル1つで作り、メールで回していると、どれが最新の版なのか、誰の作業が遅れているのかが分かりにくくなりがちです。

担当者が2人か3人で、作業の数が数十件までなら、表計算のファイルを共有のフォルダに1つだけ保存し、全員がそのファイルを更新する形で十分に回ります。担当と期限の列を作り、期限を過ぎた行に条件付き書式で色を付ければ、遅れている作業がすぐに分かります。

作業が増え、複数の部署の人で担当と期限と進み具合を共有したい場面では、作業を1件ずつカードにして並べるプロジェクト管理の道具を使う方法もあります。選択肢の1つが、国産のプロジェクト管理のPinatecaです。公式の料金ページによると、5人まで、ボード10個までは無料で使え、カードに担当と期限とコメントを付けられます。クレジットカードの登録も要りません。6人目または11個目のボードからはスタンダードのプランになり、1人あたり月額500円（税抜、年払いなら1人あたり月額400円）です。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

使い方の例を挙げます。「販売管理システムの導入」というボードを作り、7つの工程を列として並べます。各工程の作業を1件ずつカードにして、担当者と期限を付けます。ベンダーとの打ち合わせで決まったことや、テストで見つかった問題は、カードのコメントに残しておけば、担当者が休んだ日でも他のメンバーが経緯を確かめられます。工程全体の日程は表計算のスケジュール表で示し、日々の作業の分担と進み具合をカードで共有する、という分け方にすると、それぞれの役割が混ざりません。

本稼働の後にやること

本稼働はゴールではなく、新しいシステムで業務を回し始める日です。本稼働の後、1か月から3か月のあいだに、次のことを行います。

本稼働の直後に集まった質問と不具合をまとめ、手順書を直す
目的の整理で決めた数字の目標に対して、実際にどれだけ変わったかを測る
本稼働の後に検討すると決めた要望を見直し、追加するかどうかを決める
古いシステムを止める日を決め、データの保管の方法を決める
ベンダーとの保守の契約の内容と、問い合わせの窓口を確かめる

本稼働の直後は、使う人から「前のシステムのほうが使いやすかった」という声が出ることがよくあります。操作に慣れていないことが理由の場合も多いので、すぐに設定を変えるのではなく、1か月ほど様子を見てから、本当に直すべき点かどうかを判断します。その間に寄せられた声は一覧にして、ベンダーとの定例の打ち合わせで取り上げます。

特に、数字の目標に対する振り返りは忘れられがちです。「請求書の作成が4日から1日になった」のように結果を測っておくと、次にシステムを入れるときの判断の材料になり、社内で導入の効果を説明するときにも役立ちます。

運営者として見てきた、システム導入と外部の人材

在宅ワークやフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、システム導入で外部の人の力を借りる会社が増えています。要件定義の整理、データ移行の作業、操作の手順書の作成、本稼働の後の問い合わせの対応など、社内の人だけでは手が回らない作業を、在宅のフリーランスに依頼する場面です。中間の手数料が乗らない直接の取引なら、依頼する側は同じ予算でより多くの作業を頼め、受ける側は手取りが厚くなります。

システムの設定や開発の仕事に関心がある人は、アプリ開発のお仕事で、どのような仕事があるかを紹介しています。業務の進め方を見直し、システムや生成AIの導入を支援する立場で働きたい人には、AIコンサル・業務活用支援のお仕事も参考になります。福祉の事業所がシステムを入れる場合に使える支援については、福祉事業所のDXに使える補助金の記事で紹介しています。