ソフトウェア開発の流れ｜発注者のためのシステム開発工程表の読み方とチェック観点

ベンダーから提示された工程表に「基本設計」「結合テスト(IT)」「ST」といった言葉が並んでいて、正直どこで何が起きるのか分からない——システム開発を外注する経営者・決裁者の多くが、この状態のまま契約書に判を押しています。

先に結論をまとめます。

• ソフトウェア開発の流れは、大きく 要件定義 → 基本設計 → 詳細設計 → 実装 → テスト → リリース・保守 の6工程です。
• テストは一般に 単体テスト(UT) → 結合テスト(IT) → システムテスト(ST) → 受入テスト(UAT) の順に範囲を広げながら進みます。工程表の「IT」「ST」はこの略称です。
• 発注者の作業が集中するのは工程の**最初(要件定義)と最後(受入テスト・検収)**です。中間の設計・実装はベンダー主体ですが、「何もしなくてよい」わけではなく、レビューと判断のポイントが各工程にあります。
• 工程表を受け取ったら、発注者レビュー期間・テスト期間の長さ・支払条件との対応・クリティカルパス・遅延時の扱いの5点を確認してください。この5点が読めれば、工程表は「ベンダーの社内資料」から「発注者の管理ツール」に変わります。

本記事は、システムを作る側であるGXOが、発注者が工程表を読めるようになることをゴールに、各工程の中身と確認ポイントを開示するものです。なお、開発会社の探し方や見積もり・契約までの手続きの流れは別の話題なので、ここでは扱いません。本記事が扱うのは契約したあと、システムが実際に作られていく工程の中身です。受託開発という取引形態そのものの仕組みから知りたい方は、受託開発とは何か・契約形態と発注の基礎を先に読むと理解が早くなります。

ソフトウェア開発の流れ全体像｜工程×発注者の役割 早見表

まず全体を一枚で掴んでください。各工程で「ベンダーが何をするか」だけでなく「発注者が何をすべきか」「そこで手を抜くと何が起きるか」を並べたのがこの表です。

この表から読み取ってほしいことは一つです。設計と実装はベンダーの仕事ですが、要件定義と受入テストは発注者の仕事です。ここを「ベンダーがやってくれるもの」と誤解したまま進むと、どれだけ優秀なベンダーに頼んでもうまくいきません。以下、各工程を発注者視点で解説します。

各工程の中身と発注者の仕事

1. 要件定義｜プロジェクトの成否を最も大きく左右する工程

要件定義は、「何を作るか」「何を作らないか」を文書で確定させる工程です。ベンダーが業務をヒアリングし、要件定義書としてまとめますが、材料を出すのは発注者です。現場の業務実態、例外処理、繁忙期の件数、既存システムとの関係——ベンダーはこれらを知らない前提で臨んでください。

発注者がすべきことは3つです。

1. 現場のキーパーソンを会議に出す。 経営者と情シス担当だけで決めた要件は、現場の例外処理を拾えず、稼働後に「これでは仕事にならない」と言われます。
2. 優先順位を決める。 要望を全部盛り込むと予算も期間も膨らみます。「必須」「あればよい」「今回は見送り」の3段階に自社で仕分けるのは、ベンダーにはできない発注者の意思決定です。
3. 要件定義書を精読して承認する。 分厚くて読めないなら「読める形で説明してほしい」と要求してください。ここでの承認は、後の工程すべての前提になります。何をどう文書化すべきかは要件定義書の書き方とテンプレートで具体的に解説しています。

なお、経済産業省が2007年に初版を公表し、IPA(情報処理推進機構)が第二版(2020年)として改訂・公表している「情報システム・モデル取引・契約書」の契約書ひな型群では、システム開発を複数の工程に分け、工程ごとに契約を分けて締結する多段階の契約構成が採られており、要件定義のような上流工程と、その後の開発工程とでは契約の性質(準委任・請負)の使い分けが論点として整理されています。要件定義だけを先に契約して切り出す進め方は、この公的なひな型でも前提とされている実務であり、「要件が固まる前に開発全体を一括で契約させようとするベンダー」への警戒材料になります。

2. 基本設計(外部設計)｜発注者が見える最後の設計工程

基本設計は、要件を「画面・帳票・機能の仕様」に落とす工程で、外部設計とも呼ばれます。発注者から見える部分を設計するのがこの工程、見えない内部を設計するのが次の詳細設計、と覚えてください。

発注者の仕事は画面設計書のレビューです。チェックすべきは見た目の好みではなく、業務との整合です。

• この画面遷移で、実際の入力業務が現実的な時間で回るか
• 例外ケース(キャンセル、訂正、月次の締め処理など)の画面があるか
• 帳票のレイアウトが取引先・税理士などの提出先要件を満たすか

基本設計の承認後に画面を変えると、詳細設計・実装のやり直しが発生し、追加費用の根拠になります。「後で見て言おう」は通用しない工程だと認識してください。

3. 詳細設計(内部設計)｜原則ベンダーに任せる工程

詳細設計は、基本設計をプログラムの内部構造に落とす工程で、内部設計とも呼ばれます。データベースのテーブル構造や処理ロジックが対象で、発注者がレビューしても中身の妥当性は判断できません。ここは任せてよい工程です。

発注者がすべきことは、工程表どおりに進んでいるかの確認だけです。逆に言えば、詳細設計の設計書レビューを発注者に義務付け、「発注者承認済み」を盾に品質責任を転嫁しようとする進め方には注意が必要です。読めない文書への形式的な承認は、責任だけ引き受ける行為になります。「内容を判断できないので、品質担保の方法(レビュー体制、テスト計画)を説明してほしい」と返すのが正しい対応です。

4. 実装・単体テスト(UT)｜遅延が最初に表面化する工程

実装(プログラミング)と、プログラム部品単位の動作確認である単体テスト(一般にUT: Unit Testと呼ばれます)は、通常ひとまとめで進みます。発注者の作業はほぼありませんが、この工程の進捗報告だけは毎回確認してください。理由は単純で、開発の遅延はほぼ必ずこの工程で最初に数字に表れるからです。

確認すべきは「順調です」という言葉ではなく数字です。「全120機能中、実装完了が何本か」「先週の予定と実績の差は何本か」。予実の差が2週続けて広がっているのに工程表の終了日が動かないなら、そのしわ寄せは後続のテスト期間に行きます。これが後述する「テスト圧縮」の入口です。

5. 結合テスト(IT)・システムテスト(ST)｜品質が作り込まれる工程

実装が終わると、テストの範囲を段階的に広げていきます。プログラム同士をつないで確認するのが結合テスト(一般にIT: Integration Testと略されます)、システム全体を本番相当の条件で検証するのがシステムテスト(ST: System Test。総合テストとも呼ばれます)です。工程表に並ぶ「IT」「ST」の正体はこれで、ITは情報技術のITではありません。

ここはベンダーの工程ですが、発注者にできる貢献が2つあります。

• 実データに近いテストデータの提供。 きれいなサンプルデータでは通るのに、実際の顧客データ(旧字体の氏名、桁あふれ、過去の入力ミス)で落ちる、というのは典型的な本番障害のパターンです。
• テスト結果報告書を「件数」で確認する。 「テスト完了しました」ではなく、「テスト項目数・実施数・不具合検出数・未解決数」を確認します。未解決の不具合を残したまま次工程に進む場合は、その一覧と対応期限を文書でもらってください。

6. 受入テスト(UAT)・検収｜発注者が主役になる最後の関門

受入テスト(一般にUAT: User Acceptance Testと呼ばれます)は、発注者自身が、実際の業務シナリオでシステムを動かして「これで検収してよいか」を判断する工程です。ベンダーのテストが「仕様書どおりに動くか」の確認であるのに対し、受入テストは「自社の業務がこのシステムで回るか」の確認であり、これはベンダーには代行できません。

受入テストで最低限やるべきことは次のとおりです。

• 月初〜月末の一連の業務(受注→出荷→請求→入金消込など)を、現場担当者が実際に通す
• 繁忙期相当の件数・例外ケース(返品、赤伝、期またぎ)を意図的に流す
• 発見した不具合を「検収前に直すもの」「検収後の対応でよいもの」に仕分け、文書で合意する

検収書に署名すると、契約上は納品物の受け入れが確定し、以後に見つかる不具合は契約不適合責任の範囲かどうかという交渉事になります。受入テストの期間が3日しかない工程表は、この最後の関門を形骸化させる工程表です。検収の具体的な進め方と確認項目はシステム開発の納品物と検収の完全ガイドにまとめています。

7. リリース・保守運用｜「完成後」の設計も工程のうち

本番リリースは、データ移行・切替日の業務停止時間・切り戻し(問題発生時に旧システムへ戻す)手順を含む移行計画に沿って行われます。発注者が確認すべきは「切替に失敗したらどうするか」が計画に書かれているかどうかです。切り戻し手順のない移行計画は、片道切符の飛行計画と同じです。

リリース後は保守運用工程に入ります。障害対応・問い合わせ・小規模改修が保守契約の範囲ですが、「どこまでが月額保守の範囲で、どこからが有償改修か」の線引きを、リリース前に文書で確認しておいてください。ここが曖昧なまま数年運用すると、見積もりのたびに揉める関係になります。

テスト工程の略称(UT/IT/ST/UAT)と「責任の境界」

テスト工程の略称は、単なる用語知識ではなく**「どこまでがベンダーの責任範囲か」を区切る線**として読むのが発注者にとって実用的です。

この表の要点は、UT・IT・STまでがベンダーの品質責任、UATが発注者の検収責任という構造です。工程表でUATの主体が「ベンダー」になっていたら、それは発注者の検収判断を実質的にベンダーが行うことを意味するので、必ず質してください。逆に、UATで発注者側の人員・期間を確保しないまま検収期限だけが来ると、「確認しきれないまま検収した」という最悪の形になります。

なお、テスト以外も含めた工程略称(RD、BD、PG など)はベンダーや現場によって流儀の揺れが大きく、同じ略語が別の意味で使われることさえあります。工程表に知らない略語があれば、推測せず「この略語はこの工程表では何を指しますか」と確認するのが最も安全です。

V字モデル｜「テストは対応する設計の答え合わせ」という構造

工程の並びを、左側に要件定義→設計、右側にテスト工程を配置してV字に描いたものが、一般にV字モデルと呼ばれる整理です。この図の本質は工程の順序ではなく、各テストが、どの設計・定義の検証に対応しているかという対応関係にあります。

• 単体テスト(UT)は、詳細設計どおりに部品が動くかの検証
• 結合テスト(IT)は、基本設計どおりに機能がつながるかの検証
• システムテスト(ST)は、要件定義どおりにシステム全体が成り立つかの検証
• 受入テスト(UAT)は、そもそもの業務要求が満たされたかの検証

発注者がこの構造から得られる実務的な教訓は2つあります。第一に、上流の文書が曖昧だと、対応するテストの合否も曖昧になるということです。要件定義書に「在庫を適切に管理できること」としか書いていなければ、システムテストで何をもって合格とするか誰にも判定できません。テストの合否基準は、テスト工程ではなく上流工程で書き込まれるものです。第二に、手戻りのコストは、対応関係の遠さに比例して増えるということです。受入テストで要件レベルの誤りが見つかると、V字の左側の頂点まで戻ってやり直すことになり、修正費用と期間は最大化します。要件定義に時間をかける経済合理性は、この構造から説明できます。

ウォーターフォールとアジャイル｜発注者の関与はどう変わるか

ここまで説明した「工程を順番に進める」やり方は、一般にウォーターフォール型と呼ばれます。これに対し、機能を小さな単位に区切り、短い期間(1〜4週間程度の反復)で設計・実装・確認を繰り返すのがアジャイル型です。発注者にとっての違いは、技術論よりも自分の関与の仕方に現れます。

注意してほしいのは、アジャイルは「発注者が楽になる方式」ではなく、むしろ発注者の稼働を恒常的に要求する方式だということです。週次の確認会議に意思決定できる担当者を出し続けられない会社がアジャイルを選ぶと、反復のたびに判断が持ち越され、費用だけが積み上がります。自社に専任を出せる体制がないなら、要件を固めてウォーターフォールで進めるほうが結果的に安全、という判断は十分に合理的です。IPAの「情報システム・モデル取引・契約書」にも、従来型を対象とした版とは別にアジャイル開発版が用意されており、両者は契約の組み立てからして別物として扱われています。

ベンダーの工程表を受け取ったら確認する5つのチェック観点

ここが本記事の核心です。工程表(スケジュール表)は、線の長さを眺めるものではなく、次の5点を読み取るものです。

観点1: 発注者のレビュー期間が線として引かれているか

要件定義書のレビュー、基本設計書のレビュー、受入テスト。発注者が作業する期間が、工程表に明示的な線として確保されているかを最初に見てください。ベンダー作業の線だけが並び、発注者レビューが工程間の「点」として扱われている工程表は、実質的に「発注者は即日承認する」前提で引かれています。要件定義書を営業日3日で承認しろというスケジュールは、精読しない承認を織り込んだスケジュールです。自社が現実に確保できるレビュー日数を伝え、線として引き直してもらってください。

観点2: テスト期間が全体に対して不自然に短くないか

開発全体に占めるテスト(結合以降)の期間があまりに薄い工程表は要注意です。絶対的な正解比率はありませんが、実装4ヶ月に対して結合テストからリリースまでが3週間、といった配分を見たら、「この期間で、テスト項目を何件消化する計画ですか」と件数で質問してください。まともなベンダーなら項目数の概算と根拠を答えられます。また、前工程が遅延したときに真っ先に削られるのがテスト期間です。実装の遅れを認識したら、「終了日は変えずにテストを短くする」のではなく「どの工程を延ばすのか」を明示させてください。

観点3: マイルストーンと支払条件が対応しているか

契約書の支払条件(着手金・中間金・検収後残金など)と、工程表のマイルストーン(要件定義完了、基本設計承認、検収など)が対応しているかを突き合わせてください。確認すべきは、支払いのトリガーとなる「完了」の定義が文書承認と紐付いているかです。「基本設計完了時に中間金」とだけあり、完了の定義がなければ、遅延時に「完了した・していない」の水掛け論になります。「発注者が基本設計書を承認した時点」のように、発注者の承認行為と支払いを紐付けるのが健全な形です。多段階契約(工程ごとの分割契約)であれば、この対応関係は自然に整理されます。

観点4: クリティカルパス(遅れが全体に直結する経路)はどこか

工程表の中には、「1日遅れたら全体が1日遅れる」作業の連なり(クリティカルパス)と、多少遅れても吸収できる作業があります。発注者がこれを自力で計算する必要はありません。**「この工程表のクリティカルパスはどこですか」とベンダーに質問してください。**即答できないベンダーは、自分の工程表を管理ツールとして使っていません。そして重要なのは、外部要因——発注者側のデータ提供、他社システムとの接続仕様の入手、機器の納品——がクリティカルパス上にあるケースです。この場合、遅延の引き金を引くのは発注者自身になり得ます。自社起因のボトルネックがどこかを把握しておくことは、発注者の自衛です。

観点5: 遅延したときの扱いが決まっているか

工程表は計画であり、計画は遅れます。確認すべきは遅れないことではなく、遅れたときのルールです。遅延が何日に達したら再計画を協議するのか。ベンダー起因・発注者起因・外部起因で費用負担はどう変わるのか。遅延の報告はいつ・どの会議で行われるのか。この取り決めが契約にも議事録にもない状態で遅延が起きると、責任の押し付け合いになります。工程表を受け取った打ち合わせの場で「遅延時の再計画ルール」を確認し、議事録に残すだけで、後の紛争リスクは大きく下がります。

工程をめぐる典型的な失敗パターン

実装側から見て、発注者側の失敗は驚くほど同じ形で繰り返されます。代表的なものを挙げます。

• 要件定義を「ベンダーの仕事」と誤解する。 材料を出さず、承認だけして、受入テストで「思っていたものと違う」となる。工程の前半をベンダー任せにした案件は、後半でほぼ例外なく費用交渉が発生します。
• 中間工程の承認を形式的に流す。 基本設計書を読まずに承認し、実装後に画面変更を要求する。承認済み文書からの変更は追加費用の正当な根拠になるため、交渉の余地がありません。
• 進捗報告を「順調です」で受け取り続ける。 数字(予実の件数)で確認しないため、遅延の認識がテスト工程まで遅れ、選択肢が「テスト圧縮」か「リリース延期」の二択しか残らない。
• 受入テストの体制を用意していない。 検収期限が来ても現場の手が空かず、ろくに確認しないまま検収書に署名。稼働後の不具合が「検収済み」を理由に有償扱いになり、関係がこじれる。
• 保守の範囲を決めずにリリースする。 稼働後の改修依頼のたびに見積もりで揉め、数年後にはベンダーを変えたくても、ドキュメントが整備されておらず変えられない状態になっている。

共通項は、発注者の仕事(最初と最後)を外注できると考えたことです。逆に言えば、要件定義と受入テストにだけは社内の時間を投資すると決めた発注者は、IT専任者がいなくても大きくは失敗しません。

よくある質問(FAQ)

Q1. 工程表の「IT」「ST」とは何の略ですか?

一般に、ITは結合テスト(Integration Test)、STはシステムテスト(System Test)の略称として使われます。プログラム同士をつないで確認するのがIT、システム全体を本番相当の条件で確認するのがSTです。情報技術(Information Technology)のITとは別物です。略称の使い方はベンダーにより揺れがあるため、工程表上の略語は「この表では何を指すか」を確認するのが確実です。

Q2. 発注者が一番時間を割くべき工程はどこですか?

要件定義と受入テスト(UAT)です。この2つは性質上ベンダーに代行できない、発注者自身の仕事です。中間の設計・実装工程は、レビューと進捗確認(数字での予実確認)に絞って関与すれば十分です。

Q3. 要件定義にはどのくらいの期間がかかるものですか?

規模と業務の複雑さによるため一概には言えませんが、中小企業の業務システムでも週1回程度の打ち合わせを数回〜十数回重ねるのが通常で、数ヶ月単位を見込むケースも珍しくありません。むしろ警戒すべきは「要件定義は1〜2回の打ち合わせで済みます」という提案です。ヒアリングが薄いまま作られたシステムの手直し費用は、要件定義に払う費用より高くつきます。

Q4. ベンダーのテストが終わっているのに、受入テストは必要ですか?

必要です。ベンダーのテスト(UT/IT/ST)は「仕様書どおりに動くか」の検証であり、受入テストは「自社の業務がこのシステムで回るか」の検証です。仕様書自体に業務とのズレがあった場合、ベンダーのテストは全部合格のまま、業務は回らないという事態が起こります。これを検収前に発見できる最後の機会が受入テストです。

Q5. 工程表どおりに進んでいるかを、専門知識なしで確認する方法はありますか?

定例会で「予定と実績の差」を数字で聞くことです。「実装対象120本のうち完了は何本か、先週時点の予定では何本のはずだったか」。この2つの数字の差が縮まらない、あるいは広がっているのに工程表が変わらないなら、どこかに無理が溜まっています。技術の中身が分からなくても、予実管理は経営者が普段からやっていることと同じです。

Q6. 途中で仕様変更をお願いしたら、追加費用と言われました。おかしくないですか?

承認済みの文書(要件定義書・基本設計書)からの変更であれば、追加費用の請求自体は正当です。確認すべきは金額の妥当性で、「どの工程まで戻る変更か」「影響する範囲はどこか」の説明を求めてください。V字モデルで見たとおり、手戻りコストは戻る距離に比例します。逆に、承認前の文書に対する指摘まで「変更」として課金しようとする場合は、契約上のレビュープロセスの位置づけを確認すべきです。

GXOに相談すべきケース

GXOは受託開発の実装側として、この記事に書いた工程を日々運用している立場です。そのうえで、次のような状況であれば、契約や検収の前に一度ご相談いただく価値があります。

• ベンダーから工程表と見積もりを受け取ったが、期間配分や金額の妥当性を判断できる人が社内にいない
• 工程表に発注者レビューの線がなく、テスト期間の配分にも不安があるが、指摘の仕方が分からない
• 進行中のプロジェクトで実装の遅延が続いており、テスト圧縮が始まりかけている
• 検収を求められているが、受入テストを何をどこまでやれば署名してよいのか判断がつかない

他社の見積もり・工程表を実装側の目で点検する見積もり・工程表のセカンドオピニオンでは、期間配分・支払条件との対応・レビュー期間の有無といった、本記事のチェック観点に沿った第三者確認を提供しています。開発そのものの相談や、要件定義だけを切り出した支援についてはお問い合わせからご連絡ください。工程表が読めるようになった発注者は、ベンダーにとっても最も仕事がしやすい相手です。本記事がその一歩になれば幸いです。

参考(一次ソース)

• IPA 独立行政法人情報処理推進機構「情報システム・モデル取引・契約書」 https://www.ipa.go.jp/digital/model/index.html
• IPA「情報システム・モデル取引・契約書(第二版)」(2020年12月22日公表、改正民法対応) https://www.ipa.go.jp/digital/model/model20201222.html

※工程名・略称(UT/IT/ST/UATなど)およびV字モデルの説明は、特定の規格文書ではなく業界で一般に用いられる慣行としての整理です。略称の用法はベンダーにより異なる場合があります。