2026年8月7日に加筆・統合しました
「システム開発の流れ」と「システム開発手法」の2本を1本にまとめ、V字工程がなぜV字なのかの説明と、手法の選び方の表を足しました。
この記事はV字工程と開発手法の全体像をまとめたものです。公開後、実際に作って測る記事を何本も書くなかで「V字のどこが抜けると、何が起きるのか」が具体的に分かってきたので、実例つきの章を足しました。
この記事について
身のまわりのシステムは、どういう手順で作られているのか。この記事では作る順番（工程）と、その順番をどう回すか（開発手法）をまとめて見ていきます😊
システム開発の全体像
システム開発は、大きく「決める」「作る」「確かめる」の3つに分かれます。この流れを図にすると、アルファベットのVの形になるのでV字工程と呼ばれます。
V字工程の8つの段階
| 工程 | やること | |
|---|---|---|
| 1 | 要件定義 | 「何を作るか」を決める。使う人の要望を聞き取り、必要な機能を洗い出す |
| 2 | 基本設計（外部設計） | 全体像を決める。画面・帳票・データの流れなど、使う人から見える部分 |
| 3 | 詳細設計（内部設計） | プログラムの中身を決める。処理の分け方・データの持ち方・手順 |
| 4 | 実装 | 設計をもとにプログラムを書く |
| 5 | 単体テスト | 1つ1つの部品が正しく動くか確かめる |
| 6 | 結合テスト | 部品どうしを繋いで確かめる |
| 7 | システムテスト | 全体として要件を満たしているか確かめる |
| 8 | 受入テスト | 使う人が実際に確認し、問題なければリリース |
★なぜ「V字」なのか
ただ順番に並べるだけなら、Vの形にする必要はありません。この形にすると、テストと設計の対応関係が見えるからです。
| 決める側 | ↔ | 確かめる側 | 何を確かめているか |
|---|---|---|---|
| 要件定義 | ↔ | 受入テスト | そもそも欲しかったものになっているか |
| 基本設計 | ↔ | システムテスト | 全体として決めたとおりに動くか |
| 詳細設計 | ↔ | 結合テスト | 部品どうしの繋ぎ方が設計どおりか |
| 実装 | ↔ | 単体テスト | 1つの部品が書いたとおりに動くか |
★左と右が対になっている
「単体テストが通ったのに受入で落ちる」のは、部品は正しいが、そもそも欲しかったものと違うという意味になります。どの段階の決めごとが間違っていたかが、テストの落ち方から逆算できる——これがV字にする値打ちです。
1周では終わらない
ここまでが「作る順番」の話です。ただ、この流れを1周回したら終わり、ということはほとんどありません。使ってみて初めて分かることがあるからです。
そこで「V字をどう回すか」に、いくつかのやり方が生まれました。
ウォーターフォール開発
各工程を順番に、後戻りせずに進めるやり方です。滝（waterfall）のように上から下へ流れるので、この名前がついています。
- 向いているとき … 作るものが最初から決まっている。人数が多い。品質の記録を残す必要がある
- つらいとき … 途中で要望が変わる。後の工程で問題が見つかると、前に戻る手間が大きい
アジャイル開発
短い期間（スプリント）で「決める→作る→確かめる」を回し、動くものを少しずつ増やしていくやり方です。
| やり方 | 特徴 |
|---|---|
| スクラム | 1〜4週間の区切りで計画・実施・振り返りを繰り返す。役割と会議の形が決まっている |
| カンバン | 作業を board に並べ、流れを見える化する。同時に進める数を制限する |
| XP | テストを先に書く、2人で1台を使って書く、といった実践の集まり |
早い段階で動くものが見えるので、「思っていたのと違う」に早く気づけます。その代わり、全体の完成時期や総額を最初に確定させるのは苦手です。
ウォーターフォールとの違いを並べると、こうなります。
| ウォーターフォール | アジャイル | |
|---|---|---|
| 進め方 | 全工程を1回、順番に | 短い周期を何度も |
| 動くものが見えるまで | 終盤 | 最初の数週間 |
| 要望の変更 | 苦手（前の工程に戻る） | 前提として組み込まれている |
| 完成時期・総額 | 最初に決めやすい | 決めにくい |
| 記録・書類 | 多い | 必要な分だけ |
| 向く規模 | 大人数・長期 | 少人数・中短期 |
大事なのは「早く出して直せるか」と「最初に確定させられるか」は両立しないという点です。どちらを取るかが、そのまま手法の選択になります。
スパイラル開発
試作を繰り返しながら、少しずつ完成に近づけるやり方です。危なそうなところから先に試すのが特徴で、「本当に実現できるのか分からない」部分を早めに潰せます。
どの手法を選ぶか
| 状況 | 向いているやり方 | 理由 |
|---|---|---|
| 作るものが最初から固まっている | ウォーターフォール | 計画が立てやすく、進み具合が測りやすい |
| 使ってみないと分からない | アジャイル | 早く出して、反応を見ながら直せる |
| 技術的にできるか不安がある | スパイラル | 危ないところを先に試せる |
| 止まると影響が大きい（金融・医療など） | ウォーターフォール寄り | 記録と手順を残す必要がある |
近年はアジャイルを採り入れる場面が増えていますが、どちらが優れているという話ではありません。実際には「全体はウォーターフォール、中の一部だけ短く回す」といった混ぜ方もよく使われます。
【追記】V字の左右がつながっていないと、何が起きるか
V字工程の図は「左で決めたことを、右の同じ高さで確かめる」という形をしています。言葉にすると当たり前ですが、実際に手を動かすと「テストは通ったのに動かない」という形で跳ね返ってきます。
実際に踏んだ例を1つ挙げます。ゲームエンジンからAIを呼ぶプログラムを書き、単体テストを40件用意して全部通しました。ところが実機で動かすと、3回目のリクエストから必ず失敗するという現象が出ました。
原因は、通信を1回終えたあとの後片付け（使い終わった接続を閉じる処理）が抜けていたことでした。使える接続の本数には上限があり、閉じずに次を開き続けると、いずれ在庫が尽きます。
単体テストは「その関数を1回呼んだときに正しい答えを返すか」を見ています。後片付けの漏れは、1回では絶対に表に出ません。連続して呼んで、はじめて在庫が尽きます。これはまさに、V字の右側で「単体テスト」より上にある結合テスト・システムテストが受け持つ範囲でした。
この経験から、テストの段階を次のように読み替えるようになりました。
| テストの段階 | 教科書的な説明 | 実際に何を拾うか |
|---|---|---|
| 単体テスト | 部品が仕様どおりか | 計算間違い、条件の書き間違い |
| 結合テスト | 部品どうしがつながるか | ★後片付けの漏れ、順番の依存、状態の持ち越し |
| システムテスト | 全体が要件どおりか | 性能、長時間動かしたときの劣化 |
| 受入テスト | 依頼した人が納得するか | そもそも作るものを間違えていないか |
もし工程を削るなら、削っていいのは段階そのものではなく「その段階にかける時間」です。段階ごと飛ばすと、そこが拾うはずだった種類の不具合が、まるごと素通りします。
【追記】小さな開発では、V字はどう縮むのか
V字工程は大きなシステムの話に見えますが、1人で作る小さなものにも同じ形が入っています。名前が付いていないだけです。
| V字の段階 | 1人で作るときの実際 |
|---|---|
| 要件定義 | 「何が知りたいのか」を1行で書く |
| 基本設計 | 測る数字と、比べる条件を決める |
| 詳細設計 | どの関数に分けるか、どこにログを出すか |
| 実装 | 書く |
| 単体テスト | 関数ごとに小さく動かす |
| 結合テスト | ★通しで3回以上まわす（1回では出ない不具合があるため） |
| システムテスト | 本番と同じ条件で測り直す |
| 受入テスト | 最初に書いた1行に答えられているかを読み返す |
特に効くのが、右側の一番上——「最初に書いた1行に、答えが出ているか」を読み返すことです。作っている途中で目的がずれることは珍しくありません。左端に書いたものが残っていると、そこに戻れます。
もう1つ、測るプログラムを書くときの実務的なコツがあります。結果を記録する表に「成功したか、失敗したか」の列を最初から持たせておくことです。これが無いと、途中でエラーになった回が「速い結果」として混ざり込み、平均値が静かに狂います。
【追記】どの手法を選ぶかの、もう少し具体的な目安
本文でウォーターフォール・アジャイル・スパイラルを紹介しましたが、実際の判断は「どちらが優れているか」ではなく「作り直しの費用がどれくらいか」で決まります。
| 状況 | 向いている進め方 | 理由 |
|---|---|---|
| 作るものが法令や規格で決まっている | ウォーターフォール | 要件が動かない。文書を残す義務があることも多い |
| ハードウェアの製造を伴う | ウォーターフォール寄り | ★作り直しの費用が極端に高い。基板を焼き直すことになる |
| 使う人の反応を見ながら決めたい | アジャイル | 早く出して直すほうが、当てにいくより安い |
| 技術的に「できるかどうか」が不明 | スパイラル | 危ないところから小さく試して、無理なら方針を変える |
| 1人で作る小さなもの | アジャイル寄り | 合意を取る相手がいないので、回す速さがそのまま効く |
マイコンを扱っていると、ソフトだけアジャイルにしても、ハードの日程が動かないという場面によく出会います。そのため「ハードの仕様が固まる前にできることを、先に小さく試しておく」というスパイラルに近い進め方になりがちです。手法は名前で選ぶより、何が動かせて、何が動かせないかから逆算するほうが実際に合います。
まとめ
- システム開発は決める→作る→確かめるの流れ。図にするとV字になる
- ★V字の左右は対になっている。テストの落ち方から、どの決めごとが間違っていたか分かる
- 1周で終わることはほとんどないので、回し方に手法の違いが出る
- 要件が固まっているならウォーターフォール、使ってみないと分からないならアジャイル
- 技術的な不安が大きいならスパイラル。混ぜて使うことも多い
それでは、今回はここまで。最後までありがとうございました😊