システム開発の工程｜発注側が各フェーズで決めること5つ
見積書には「要件定義・設計・実装・テスト・移行」といった工程の一覧が並んでいます。ところが、それぞれの工程で発注側が何をすればいいかまでは、たいてい書かれていません。工程名だけを見て「開発会社にお任せしていれば進む」と考えていると、設計の承認待ちで止まる、仕様変更の相談先が分からない、稼働直前になって引き継ぎ範囲でもめる、といった手戻りが起きます。この記事では、要件定義から移行・引き継ぎまでの5つのフェーズで、発注側が実際に決めておく判断を、業務システム開発の実務から整理しました。読み終えたときに、次の打ち合わせで何を確認すればいいかが分かる状態を目指しています。
- 見積書の工程一覧に書かれていない、発注側の役割
- 要件定義から移行・引き継ぎまで、5つのフェーズで決めること
- 判断を先送りにすると起きる3つのつまずき
- フェーズごとの判断をすり合わせて進めた開発事例
工程一覧だけでは、発注側が何をすればいいか分からない
見積書の工程一覧は、開発会社が「何をいつまでにやるか」を示すものです。発注側が各フェーズで何を確認し、何を決めるかは、別の話として抜け落ちやすいのが実情です。工程ごとの役割分担を整理すると、次のようになります。
| フェーズ | 開発会社が主に行うこと | 発注側に求められること |
|---|---|---|
| 要件定義 | ヒアリング・要件の整理・文書化 | 現状業務の言語化・関係部署の招集・優先順位の判断 |
| 基本設計 | 画面・帳票・データ項目の設計 | 設計内容の確認・承認者の明確化 |
| 実装・結合テスト | プログラミング・機能間の結合確認 | 仕様変更が出た場合の申請・判断 |
| 受入テスト | テスト環境の提供・不具合対応 | 業務シナリオでの検証・合格基準の判定 |
| 移行・引き継ぎ | データ移行・マニュアル整備 | 並行稼働期間の判断・保守範囲の合意 |
この右側の列を、着手前に発注側が知っているかどうかで、後工程の進み方が大きく変わります。特に基本設計以降は、開発会社が作業を進めるためには発注側の確認・承認が必要になる場面が多く、発注側の対応が遅れると、そのまま全体の進行が止まります。工程の順番そのものを一から確認したい場合は業務システム開発の進め方ガイドで、要件の固め方から契約形態の選び方までを解説しています。工程ごとの日程の組まれ方はシステム開発のスケジュールはどう決まるかで扱っていますので、あわせてご覧ください。
発注側の役割が抜け落ちやすい理由の一つは、見積書や提案書が開発会社の作業内容を中心に書かれていることにあります。開発会社にとっては当然の前提でも、発注側にとっては「いつ・誰が・何を確認すればいいか」が初めての経験であることが多く、質問しなければ教えてもらえないまま工程が進んでしまいます。フェーズが切り替わるタイミングで、次のフェーズに発注側の対応が必要かどうかを開発会社に確認しておくと、この抜け落ちを防ぎやすくなります。
発注側が各フェーズで決める5つの判断
工程が進むタイミングで、発注側が何を決めておけばいいかを、フェーズごとに整理します。
要件定義：誰が現状業務を言語化するか
要件定義で最も時間がかかるのは、現状の業務の流れを言葉にする作業です。この作業を主導する社内担当者と、関係部署のうち誰を巻き込むかを、着手前に決めておきます。担当者が定まらないまま始めると、確認の往復が増え、要件定義そのものが長引きます。
基本設計：誰が画面・帳票を承認するか
基本設計の資料は、画面数・帳票数が多いほど確認項目も増えます。設計内容を最終的に承認する人を1人に決めておかないと、複数の担当者から異なる指摘が出て、設計のやり直しが発生しやすくなります。
実装・結合テスト：仕様変更をどう申請するか
実装が進む中で、現場から「ここも直したい」という要望が出ることはよくあります。この要望を誰が受け付け、開発会社にどう伝えるかの窓口を決めておかないと、要望が複数の経路から個別に伝わり、対応の優先順位が付けられなくなります。
受入テスト：何をもって合格とするか
受入テストは発注側の担当者が主体になって進める工程です。どの業務シナリオを、誰がテストし、何が確認できれば合格とするかを、テスト開始前に文書として決めておきます。基準が曖昧なままだと、稼働直前になって不具合の扱いをめぐる調整が発生します。
移行・引き継ぎ：並行稼働の期間と保守範囲
新システムへの移行時に、旧システムとどのくらいの期間並行稼働させるか、稼働後の保守をどこまで開発会社に依頼するかを決めておきます。ここが曖昧なまま稼働すると、初期トラブルが起きたときにどちらが対応するかで時間を取られます。
「開発会社に任せているので大丈夫」と考えて5つの判断を先送りにすると、基本設計の承認待ちで工程が止まる、仕様変更の窓口が無く現場の要望がバラバラに伝わる、受入テストの合格基準が無いまま稼働してしまう、といった事態につながります。5つの判断は、いずれも着手前か各フェーズの開始時点で決められる内容です。
判断を先送りにすると起きる3つのつまずき
5つの判断のうち、特に先送りにされやすく、後工程に影響が出やすい3つを取り上げます。
基本設計の承認者を「部署内で確認します」とだけ決めて進めると、担当者ごとに異なる意見が出て、設計の確定が先延ばしになります。承認者を1人に絞り、他の担当者の意見はその人を通して集約する運用に変えるだけで、設計の停滞は減らせます。
現場の要望を開発会社の担当者に直接、複数の社員が個別に伝えている状態は、後から「その変更は聞いていない」という食い違いを生みます。窓口を1つに決め、要望を必ずそこを通して伝える運用にしておくと、対応状況を追いやすくなります。
「稼働したら開発会社が面倒を見てくれるだろう」という前提のまま契約すると、保守契約に含まれる対応範囲と、含まれない対応範囲の境界で認識が食い違います。稼働前に、初期トラブル対応がどこまで契約に含まれるかを文書で確認しておくと、この食い違いを避けられます。
3つのつまずきに共通するのは、「誰が決めるか」「誰が窓口か」を決めないまま進めている点です。フェーズが変わるタイミングで、担当者と窓口を明確にしておくことが、手戻りを防ぐいちばん確実な方法です。外注先そのものの比較基準は基幹システム開発の外注先の選び方で、費用の内訳はシステム開発の費用はどう決まるかで扱っています。
3つのつまずきは、いずれも発生してから気づくものではなく、フェーズの開始時点で担当者・承認者・窓口が決まっているかを確認すれば、事前に予兆をつかめます。契約時点で「基本設計の承認者は誰にするか」「仕様変更の連絡先はどちらに置くか」「保守の対応範囲はどこまでか」の3点を開発会社と発注側の双方で書面に残しておくと、フェーズが進むたびに同じ確認を繰り返さずに済みます。
フェーズごとの判断をすり合わせて進めた開発事例
5つの判断と3つのつまずきが、実際の開発でどう活きるかを事例で見てみます。
見積書作成の自動化
見積書の作成業務を自動化するシステムの開発を行いました。基本設計の承認者を発注側の窓口担当者1人に決めたうえで進めたことで、帳票のレイアウト確認における往復を最小限に抑えられています。
与信管理・債権回収の効率化
与信管理と債権回収の業務を効率化するシステムの開発を行いました。受入テストの合格基準を実際の業務シナリオに沿って事前に文書化したことで、稼働直前の判断に迷いが生じないまま移行できています。
このほか、生産管理システムのリプレイス、受注書処理の自動化など、業務領域の異なる開発実績があります。いずれもフェーズが変わるタイミングで発注側の担当者と窓口を明確にしたうえで進めており、業種や業務が異なっても、判断を先送りにしないという進め方自体は共通しています。発注前の要件の固め方から相談したい場合はAI受託開発の進め方も参考になります。
よくある質問
まとめ｜フェーズが変わるたびに、担当者と窓口を決めておく
システム開発の工程一覧は、開発会社が何をするかを示すものであって、発注側が各フェーズで何をするかは別に決めておく必要があります。要件定義の言語化担当者、基本設計の承認者、仕様変更の窓口、受入テストの合格基準、移行時の保守範囲という5つの判断を、フェーズが始まる前に決めておくことで、承認待ちの停滞や「言った言わない」の食い違いを防げます。
当社は京都市左京区（百万遍）を拠点に、中小企業から上場企業までを対象に、要件定義から実装、運用引き継ぎまでを担う業務システム開発を提供しています。各フェーズで何を決めればいいか整理する段階からご相談いただけます。
登壇・セミナー実績
神戸商工会議所・石川県庁など、各地の商工会議所や自治体でAI活用セミナーに登壇しています。現場で得た知見をもとに、中小企業から上場企業までのAI導入を支援しています。
監修
仙入 功樹 せんにゅう こうき
代表取締役
吉村 祐樹 よしむら ゆうき
COO
本記事はAI導入支援の実務担当が監修しています。中小企業から上場企業まで、AI導入の相談から開発・研修・運用定着までを支援しています。監修者の経歴と登壇実績はメンバー紹介をご覧ください。
ご相談と資料
読んだ内容を、
自社の業務に当てはめたい方へ
どの業務から手を付けるか、何を作るかが決まっていなくても構いません。30分の無料相談で、今の状況から伺います。
ご相談はオンラインでも、京都・百万遍のオフィスでもお受けします。秘密保持契約を先に結ぶこともできます。
コメント