業務改善・組織運営

システム導入のスケジュールの作り方|担当者・確認日・開始条件をそろえる

SIの工程計画はどう作る?成果物と前提から日程を組むの実務ガイド。SIの工程計画:記入メモ

「設定は来週終わります」と言われても、現場で試す人の予定が空いていない。中小企業でシステム導入を任され、普段の仕事と調整を兼ねる担当者は、工程表に日付を入れるだけでは準備が揃わず、利用を始めてよいか迷うことがあります。

この記事では、作業の順番に加えて「何が揃えば始められるか」「誰がいつ確認するか」を工程表へ書く方法を説明します。架空の設備点検会社の例を見ながら、自社の工程表を1行ずつ見直し、決められる日程と、責任者に相談する必要がある日程を分けられます。最後に、一工程を見直すための確認事項をまとめています。

完成させる仕事を決め、各工程に必要な資料・作るもの・確認する人を書きます。その人と試用環境が使える日を確かめてから、開始日を置きましょう。

  • 設定が終わる日と、現場で利用を始められる日を分ける。
  • 順番に進める作業と、条件が揃えば同時に進められる作業を見分ける。
  • 未決事項と確認先を工程メモに残し、責任者へ具体的に相談する。

以下の泉点検、日数、予定、判断は全て説明用の架空例です。実在企業の導入実績や一般的な所要日数ではありません。

1.日付を書く前に、誰が何をできれば導入完了かを決める

最初に、今回の導入で使えるようにする仕事を揃えます。ここが曖昧だと、後から作業が増えて日程を組み直すことになります。

資料の入力項目と閲覧範囲、試用環境と架空の予定、担当者と確認する時間の3つが、開始日を決める判断へつながる図。
資料・試用環境・確認する人は、どれも開始に必要な条件です。順番に選ぶ3案ではありません。架空の準備計画であり、実際に準備が揃ったことを示す図ではありません。

架空の設備点検会社「泉点検」では、一つの部署が翌週の点検予定を入力し、各担当者が自分の予定を確認できるようにします。請求や顧客への通知は、今回の対象に含めません。

業務責任者は、入力する項目と誰がどの予定を見られるかを決めます。導入担当者は、その条件をもとに試用環境を設定します。試用環境とは、本番の仕事を始める前に、架空の予定などで動作を確かめる場所です。実際の製品でこの使い方ができるかは別途確認します。

完了を確かめるために、業務条件をまとめた表、設定した試用環境、試した結果の記録、利用手順を残します。予定が表示されても、現場担当者が操作できるか、問題が残っていないかが分からなければ、利用開始を決める材料はまだ揃っていません。

泉点検で今回決める範囲(架空例)
決めること今回の例確認する人
使えるようにする仕事一部署の翌週の点検予定を入力し、本人が自分の予定を確認する業務責任者
今回含めない仕事請求、顧客への通知業務責任者と導入担当者
利用開始を判断する材料確認記録、利用手順、残る指摘と対応方針業務責任者とIT責任者

自社の工程表の上に「誰が、どの仕事をできれば今回の導入が完了するか」を1文で書いてください。

2.各工程に、受け取る資料・作るもの・確認する人を書く

次に、工程同士の受け渡しを見えるようにします。「前の作業が終わった」だけでは、次の人が何を受け取ればよいか分かりません。

架空例。業務責任者が入力項目と閲覧範囲を確認した条件表を、導入担当者が受け取ってから試用環境の設定と設定内容の確認を予定します。未確認なら設定前に確認します。
図:架空例です。実際の確認や対応を行った実績ではありません。

たとえば「試用環境の設定」の開始条件を「条件整理が終わる」とだけ書くと、入力項目だけ決まった段階でも着手できるように見えます。「業務責任者が入力項目と閲覧範囲を確認した条件表を受け取る」と書けば、何を待っているかが分かります。

作るものと確認する人も、同じ行に置きます。確認者には、名前を載せてよいかだけでなく、何を見てもらうかと、いつ時間を取れるかを確かめます。まだ決まっていない箇所は「未確認」と残します。

下の期間は、計画の考え方を説明するための仮の見積もりです。資料作成だけでなく、その工程で必要な確認まで期間内に行えると仮定しています。自社では、作業量と確認時間を担当者に聞いて見直してください。

開始条件と受け渡しを書いた工程表(架空例)
工程と仮の期間始めるために必要なもの残すもの・確認する人
業務条件の整理:3営業日対象業務と現場の要望条件表。業務責任者が入力項目と閲覧範囲を確認
試用環境の設定:3営業日確認済み条件表、利用できる試用環境設定した環境。導入担当者が設定内容を確認
現場での試用確認:2営業日設定した環境、架空の予定、現場担当者の確認時間確認記録。現場担当者が操作と表示を確かめる
利用手順の準備:2営業日設定後の画面、手順を作る人の時間利用手順。現場担当者が自分で操作できるか確認

まず「設定」「確認」など工程表の1行を選び、受け取る資料と確認する人を追記してください。

3.8営業日で終わる条件を、順番と同時進行に分ける

工程を並べたら、待つ必要がある作業と、同時に進められる作業を分けます。各工程の日数を足しただけでは、全体の期間は決まりません。

架空の工程比較。条件整理3日、設定3日の後に試用確認2日と手順準備2日を並行できれば8営業日。同じ担当者が両方に丸2日ずつ必要で順に行う場合は10営業日。
図の日数は全て営業日です。必要な確認が各期間内に終わり、待ちや修正がないと仮定しています。上は並行できる人と時間がある場合、下は同じ担当者が両方に丸2日ずつ必要な場合です。実際の工期や成果を示す数字ではありません。

泉点検の仮の計画では、業務条件の整理に3営業日、試用環境の設定に3営業日、現場での試用確認に2営業日を置きます。この3工程を順番に進めると、3+3+2=8営業日です。

利用手順の準備には、別に2営業日を見込みます。設定後の画面を使えること、手順を作る人の時間があることを確かめ、試用確認と同じ2営業日に進められるなら、全体は8営業日という案になります。

同じ担当者が試用確認と手順作成を両方行い、それぞれに丸2営業日かかる場合は、同時には進められません。確認の後に手順を作るなら、単純計算でも3+3+2+2=10営業日です。さらに、確認待ち、担当者の不在、設定の修正があれば、その影響を加えて見積もり直します。

8営業日も10営業日も、指定した条件だけの架空の計算です。休日を含む暦の日数や、自社で約束できる納期を示す数字ではありません。

条件整理3日と設定3日の後、確認と手順準備にそれぞれ2日を見込む架空例です。待ち時間や修正がなく、必要な確認も期間内に終わる前提で比べます。

確認と手順準備の進め方による違い
同時に進められる場合同じ人が順番に行う場合
8営業日10営業日

担当者の空きや修正時間が未確認なら、全体期間は未定です。8日や10日で確約しません。

詳しい前提と作業の並べ方は、次の表で確認できます。

同時に進められるかで全体の期間が変わる(架空例)
条件と作業の並べ方仮の全体期間
条件:確認と手順準備を同時に行える。必要な確認も期間内に終わる
作業:条件整理3日→設定3日→確認2日と手順準備2日を並行
8営業日
条件:同じ担当者が両方に丸2日ずつ必要で、同時に行えない
作業:条件整理3日→設定3日→確認2日→手順準備2日
10営業日
条件:確認者の空きや、修正にかかる時間が分からない
作業:未確認の時間を担当者に確認して組み直す
未定。8日や10日で確約しない

工程表で同じ日に重ねた作業を一組選び、同じ人の時間を二重に使っていないか確かめてください。

4.担当者の確認時間と、試用環境が空く日を押さえる

計算上の日数を、実際に着手できる予定に変えます。作業に必要な日数と、担当者が確保できる日程を区別しましょう。

架空例。設定担当者の作業時間、現場担当者の確認時間、試用環境と架空データを確認します。未確認なら確認先と候補日を記録します。
図:架空例です。実際の確認や対応を行った実績ではありません。

3営業日分の設定作業があっても、担当者が途中で別の仕事に1日かかるなら、開始から3営業日後に終わるとは限りません。1日にその仕事へ使える時間と、使えない日を確認します。

試用確認では、現場担当者の時間だけでなく、試用環境へ入れること、使う架空の予定が用意できていることも必要です。設定完了日だけを押さえ、確認者への依頼を後回しにすると、次の工程が待つことになります。

導入担当者は必要な条件を一覧にし、業務責任者へ確認時間の確保を相談します。IT責任者には、試用環境や閲覧範囲、使ってよいデータを確認します。実データを使う場合の扱いは、自社の規則に沿って決めます。

開始日を決める前に確かめること
必要なもの誰に確認するか決まらない場合の記録
設定作業に使える時間導入担当者・その仕事の責任者作業できる日と時間は未確認
現場の試用確認に使う時間現場担当者・業務責任者確認担当と候補日の調整が必要
使える試用環境と閲覧範囲IT責任者・環境を準備する担当者環境の準備日と利用条件は未確認

次に始めたい工程について、人・資料・環境のうち未確認のものを一つ選び、確認先を決めてください。

5.遅れや変更が出たら、待つ作業と先に進める作業を分ける

計画が変わったときは、関係する工程と担当者をたどります。元の予定と、見直した予定を両方残すと、変更の理由を説明できます。

架空例。閲覧範囲が未決ならその範囲の設定と試用は条件待ちとし、入力項目の見本を先に作れるか確認します。試用で本人の予定が見えない場合は、設定修正と再確認を予定し、画面が変われば手順も修正します。
図:架空例です。実際の確認や対応を行った実績ではありません。

たとえば、誰がどの予定を見られるかが未決なら、その範囲の設定は確定できません。一方、閲覧範囲に左右されない入力項目の見本を作れるかは、導入担当者が確かめられます。すべて進める、すべて止めると一括で決めず、必要な条件ごとに分けます。

試用中に「担当者本人の予定が見えない」と分かった場合は、設定の修正と再確認を工程表へ追加します。画面が変わるなら、利用手順の修正も必要です。どの作業が増えるかを記し、所要時間を見積もり直します。

導入担当者は、変更した条件、影響する工程、必要な対応、確認する人、見直した開始予定をまとめます。業務責任者とIT責任者は、その情報と残る指摘をもとに利用開始を判断します。次の確認日が決まらない段階では「未定」と書き、確認を省いて元の開始日だけを守ろうとしないことが大切です。

条件が変わったときの工程の見直し(架空例)
変わったこと影響する工程次に決めること
閲覧範囲が未決その範囲の設定と試用確認業務責任者が条件を決める予定。先に作れる見本の範囲
試用で本人の予定が見えない設定の修正、再確認、必要なら手順修正対応する人、必要時間、再確認できる日
確認担当者が予定日に対応できない試用確認と利用開始の判断代わりに確認できる人、または別の確認日

工程表を直すときは、元の予定を保存してから、変えた理由と確認する人を添えてください。

まとめ:工程表の1行を、開始できる条件まで書き直す

工程表の目的は、次の人が動くために必要な準備を共有することです。冒頭の「設定は終わるが、現場の確認が決まらない」という悩みも、待っている条件を具体的にすれば相談しやすくなります。

使う仕事、順番と開始条件、人と環境の空きを順に確認する図。条件が揃えば開始日を決め、未確認があれば確認先と次の予定を残す。どちらも条件が変われば元の予定を残して工程表を見直す。
まず1工程について、必要な資料、作るもの、確認する人、使える日を記します。未確認があれば確認先を残します。開始日を決めた後でも、条件が変われば、元の予定を保存して見直します。

完成させる仕事を決め、各工程へ必要な資料、作るもの、確認する人を記す。その人と環境が使える日を確かめ、順番に進める作業と同時に進める作業を分ける。この順で、開始できる日程と、まだ決められない日程を整理できます。

工程表が埋まらないのは、担当者の段取りだけの問題とは限りません。確認する人や利用できる環境が決まらなければ、開始日も決められません。未確認の条件を言葉にすることも、計画を進めるための仕事です。

まず、自社の工程表から次に始めたい1行を選んでください。「何を受け取り、誰が何を確認すれば始められるか」を書き、分からない欄は確認先と一緒に残します。そのメモがあれば、責任者へ「何を決めてもらえれば進められるか」を具体的に伝えられます。

次の項目で1工程を整理し、未確認の条件を担当者へ確かめましょう。

一工程で確認すること

自社の工程表から次に始めたい一行を選び、次の項目を担当者と確認します。分からないところは未確認のままにし、誰にいつ確認するかを決めましょう。

  • 対象の仕事と今回の工程
  • 始めるために必要な資料・条件
  • 作るものと、終わったと判断する条件
  • 作業する人と確認する人
  • 使える時間・環境と確認日
  • 次に渡すものと、同時に進める仕事
  • 未確認のこと・確認先・次の確認予定
  • 変更前の予定・変更理由・見直した予定

たとえば試用環境の設定なら、業務責任者が確認した条件表と、利用できる試用環境を受け取れるかを確かめます。設定に3営業日を見込むのは架空の仮定です。担当者の空きや確認時間が不明なら、開始日や全体期間は未定のまま相談します。

よくある質問

作業日数を足せば導入日を決められますか?

各作業の順番、担当者と環境の空き、確認待ち、修正に必要な時間も確認します。本文の8営業日は、書いた条件が揃う場合だけの架空の計算です。

確認者が決まらないときは、日程欄をどう書けばよいですか?

未定と書き、確認先と次に相談する予定を残します。候補日と、関係者が合意した日を分けましょう。

WBSとは何が違いますか?

WBSは、完成させるものから必要な仕事を分けた一覧です。この記事は、その仕事を始める条件と順番、人や環境の空きを日程へ結ぶ部分を扱います。

本文の例を、そのまま自社の工程表にしてよいですか?

対象業務、作るもの、担当者、利用できる環境が異なります。項目の見本として使い、日数と完了条件は自社の担当者に確認して置き換えてください。

参考資料

  1. NASA Systems Engineering Handbook 6.1 Technical Planning

    必要な作業・期間・資源を現実的に見積もり、作業の順番と支援資源の利用時期を計画する考え方。

    NASAのシステム工学資料です。中小企業の標準工期や、本文の8営業日・10営業日という架空の計算を定めた資料ではありません。

    確認日:2026-10-12

  2. IPA DX SQUARE:要件定義とは?

    利用企業と開発側で必要なことを合意し、業務部門も主体的に関わる考え方。

    本文の会社、工程表、担当例、期間は記事独自の架空例です。実際の製品仕様や導入成果を保証しません。

    確認日:2026-10-12

仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。

AI・DXとマーケティングを一体で相談

KEEP EXPLORING

次のヒントを、もうひとつ。

すべての記事を見る

LET’S CONNECT THE DOTS.

次の一歩を、
一緒につくる。

業務も、AIも、集客も。
課題がまだ整理できていなくても、ご相談ください。

AI・DXとマーケティングを一体で相談