開発の流れ
Lesson 3 では「誰が」システムを作るのかを学びました。今回は、その人たちがどんな順番で、何をしながら システムを完成させていくのかを見ていきます。
1. 家づくりで考える全体像
Lesson 3 に続いて、今回も家づくりで考えてみましょう。家が完成するまでには、だいたい次のような流れがあります。
| 家づくり | システム開発 | やること |
|---|---|---|
| 施主の希望を聞く | 要件定義 | 「何を作るか」を決める |
| 間取り図を描く | 基本設計 | お客様から見える部分（画面・機能）を決める |
| 施工図を描く | 詳細設計 | 中の作り（プログラムの構造）を決める |
| 工事をする | 開発（実装） | 実際にプログラムを書く |
| 完成検査・内覧会 | テスト | ちゃんと動くか、要望どおりかを確かめる |
| 引き渡し | リリース | お客様が使い始められる状態にする |
| 点検・修繕・リフォーム | 運用・保守 | 動かし続け、直し、改善していく |
2. 開発の工程
それぞれの工程を、もう少し詳しく見ていきます。各工程では、次の工程に引き継ぐための成果物（ドキュメントやプログラム）が作られます。 前半の「何を・どう作るか決める」工程を上流工程、後半の「作って確かめる」工程を下流工程と呼びます。
-
要件定義上流工程
お客様に「何に困っているのか」「システムで何をしたいのか」をヒアリングし、作るものの範囲と条件を決めます。 「何ができればゴールか」を、お客様と開発側で合意する、最も大切な工程です。
-
基本設計（外部設計）上流工程
要件をもとに、お客様から見える部分を決めます。どんな画面があり、どのボタンを押すと何が起きるか、 どんな帳票が出力されるか、他のシステムとどうつながるか、など。お客様に確認してもらいながら進めます。
-
詳細設計（内部設計）上流工程
基本設計を実現するための、システムの中の作りを決めます。プログラムをどう分けるか、データをどう処理するか、など。 PG がこれを読めば迷わずプログラムを書ける、というレベルまで具体的にします。
主な担当：SE ／ 成果物：詳細設計書
-
開発（実装・プログラミング）下流工程
詳細設計書をもとにプログラムを書きます。書いたプログラムが部品として正しく動くかを確かめる単体テストも、この工程で行います。 同時にインフラエンジニアは、システムを動かすサーバーなどの環境を用意します。
-
テスト下流工程
部品を組み合わせたとき、システム全体として動かしたとき、お客様が実際に使ったとき……と、範囲を広げながら段階的に確かめます。 見つかった不具合は修正し、もう一度テストします（詳しくは4章）。
-
リリース（本番移行）下流工程
完成したシステムを本番の環境に載せ、お客様が使い始められるようにします。 古いシステムからのデータの引っ越し（データ移行）や、利用者向けの説明・マニュアル作りもここで行います。
-
運用・保守
システムが毎日問題なく動いているかを見守り、トラブルがあれば対応し、要望に応じて機能を改善していきます（詳しくは7章）。
3. 作る工程と確かめる工程（V字モデル）
工程を左上から下へ「決めて作る」、下から右上へ「確かめる」と並べると、アルファベットの V の形になります。 これを V字モデルと呼びます。ポイントは、左右の工程がペアになっていることです。
たとえば、要件定義で決めた「お客様のやりたいこと」は、最後の受入テストで「本当にできるようになったか」を確かめます。 設計の段階から「これはどうやってテストするか」を考えておけるのが、V字モデルの良いところです。
4. テストの種類
テストは一度にまとめて行うのではなく、小さな範囲から大きな範囲へ、段階を踏んで進めます。
| テスト | 何を確かめる？ | 主に誰が？ | 家づくりでいうと |
|---|---|---|---|
| 単体テスト | 1つ1つの部品（プログラム）が正しく動くか | PG | ドア・窓・蛇口などの部品を、取り付ける前に検査 |
| 結合テスト | 部品同士を組み合わせたとき、正しく連携するか | PG・SE・テスター | 部屋ごとに、電気・水道がちゃんとつながっているか確認 |
| 総合テスト （システムテスト） | システム全体として、設計どおりに動くか。大量のアクセスに耐えられるか | SE・テスター | 家全体を通して、住める状態か完成検査 |
| 受入テスト （運用テスト） | お客様が実際の業務で使って、要望どおりか | お客様（開発側がサポート） | 施主さんの内覧会。「住んでみてどうか」を確かめる |
5. 「後から変更」はなぜ大変？
前の工程に戻ってやり直すことを手戻り（てもどり）と呼びます。 同じ「ここを変えたい」という変更でも、気づくのが後の工程になるほど、直すのが大変になります。
家で言えば、「窓の位置を変えたい」が間取り図の段階なら消しゴムで消すだけ。 でも、家が完成してからだと壁を壊して作り直しです。
6. 開発の進め方（ウォーターフォールとアジャイル）
工程をどんな順番・サイクルで進めるかには、代表的な2つのやり方があります。
ウォーターフォール
滝（waterfall）の水が上から下へ流れるように、工程を1つずつ順番に完了させて進める方法。 基本的に前の工程には戻りません。
- 良いところ
- 計画・予算・スケジュールを最初に立てやすい。進み具合がわかりやすい。
- 苦手なところ
- 途中の仕様変更に弱い。完成品を見られるのが最後になる。
- 向いているもの
- 作るものがはっきり決まっているシステム（銀行・行政・基幹システムなど）
アジャイル
アジャイル（agile）は「素早い」という意味。小さな機能単位で「設計 → 開発 → テスト」を短い期間で繰り返し、 少しずつ完成に近づける方法。1回の繰り返しは1〜4週間程度で、代表的なやり方の「スクラム」ではスプリントと呼びます。
- 良いところ
- 仕様変更に強い。動くものを早く見せて、意見をもらいながら改善できる。
- 苦手なところ
- 最終的な完成形・費用・期間を最初に見積もりにくい。お客様にも継続的な参加が必要。
- 向いているもの
- 変化の速い Web サービスやスマホアプリ、新しいサービスの立ち上げ
料理にたとえると
ウォーターフォールは結婚式のフルコース。メニューを事前にしっかり決め、当日はその通りに出します。途中で「やっぱり中華に」とは言えません。 アジャイルは常連さんの居酒屋。まず一品出して「もう少し濃いめがいい」と聞いたら、次の一品で調整する。食べながら一緒に最高の献立を作っていくイメージです。
7. リリースしてからが本番
システムは作って終わりではありません。むしろ、リリースしてから使われなくなるまでの期間のほうがずっと長いのが普通です。 何年、場合によっては10年以上、毎日動き続けます。
運用
システムが毎日正しく動くように見守る仕事。動いているかの監視、定期的なバックアップ、利用者からの問い合わせ対応など。
保守
システムを直したり、良くしたりする仕事。不具合の修正、法律や制度の変更への対応、新しい機能の追加、セキュリティの更新など。
家と同じで、定期的な点検や修繕をしないと、システムも少しずつ使いにくく、危なくなっていきます。 保守で新しい機能を追加するときも、小さな「要件定義 → 設計 → 開発 → テスト → リリース」の流れを繰り返します。
確認クイズ
選択肢をクリックしてください。
Q1. お客様に要望をヒアリングし、「何を作るか」を決めて合意する工程は？
Q2. 「どんな画面があり、どのボタンを押すと何が起きるか」を決める工程は？
Q3. 書いたプログラムを1つの部品として、正しく動くか確かめるテストは？
Q4. お客様が実際の業務で使ってみて、要望どおりかを確かめるテストは？
Q5. 「ここを変えたい」という変更が、いちばん少ない手間で済むのはどの段階で気づいたとき？
Q6. 新しいスマホアプリを、2週間ごとに少しずつ機能を追加し、利用者の意見を聞きながら改善していく。この進め方は？
まとめ
- システム開発は要件定義 → 設計 → 開発 → テスト → リリース → 運用・保守の流れで進む。
- 前半の「決める」工程を上流工程、後半の「作って確かめる」工程を下流工程と呼ぶ。
- V字モデルでは、決める工程と確かめる工程（テスト）がペアになっている。
- テストは単体 → 結合 → 総合 → 受入と、小さな範囲から大きな範囲へ進める。
- 変更は後になるほど大変（手戻り）。だから最初の要件定義がいちばん大切。
- 進め方には、順番に進めるウォーターフォールと、短いサイクルを繰り返すアジャイルがある。
- システムはリリースしてからが本番。運用・保守で長く支えていく。