開発工程の基本
ソフトウェア開発では、いくつかの「工程」を経てシステムを作り上げます。この章では、どの開発手法でも共通して必要となる工程について説明します。
開発工程とは
ソフトウェア開発は、「作りたいものを決める」から「実際に使えるようにする」まで、いくつかの段階を経て進みます。
料理に例えると分かりやすいです。
- 何を作るか決める（メニュー決め）
- どう作るか決める（レシピを確認）
- 実際に作る（調理）
- 味見して確認（テスト）
- 盛り付けて提供（リリース）
- 後片付けと次回への改善（保守）
ソフトウェア開発も同じです。いきなり作り始めるのではなく、「何を作るか」「どう作るか」を決めてから作り始めます。
基本的な工程
どのような開発手法を使っても、以下の工程は必ず存在します。やり方やタイミングは手法によって異なりますが、やること自体は同じです。
1. 要件定義
何を作るかを決める工程です。
やること
- お客様（またはユーザー）の要望を聞き取る
- システムで実現したいことを明確にする
- 「何を作るか」を明文化する
具体例：ネットショップの場合
| 項目 | 内容 |
|---|---|
| 誰が使うか | 一般消費者、20〜40代が中心 |
| 何ができるか | 商品を検索・閲覧、カートに入れる、購入、会員登録 |
| どのくらい使われるか | 1日1000人程度のアクセス |
| いつまでに作るか | 3ヶ月後にオープン |
ポイント
- 「なぜ作るのか」「誰のために作るのか」を理解することが重要
- 要件が曖昧だと、後で「思っていたのと違う」となる
2. 設計
どう作るかを決める工程です。
2つの段階
| 種類 | 何を決めるか | 具体例 |
|---|---|---|
| 基本設計（外部設計） | ユーザーから見える部分 | 画面レイアウト、画面遷移、機能一覧 |
| 詳細設計（内部設計） | システム内部の構造 | クラス構成、データベース構造、処理の流れ |
具体例：ネットショップの場合
基本設計の成果物
- 画面設計書：商品一覧画面、商品詳細画面、カート画面...
- 機能一覧：検索機能、カート機能、決済機能...
詳細設計の成果物
- クラス図：Productクラス、Cartクラス、Orderクラス...
- ER図：商品テーブル、ユーザーテーブル、注文テーブル...
ポイント
- 設計なしにコードを書き始めると、後で大きな手戻りが発生しやすい
- 設計の「深さ」や「形式」は開発手法によって異なる
3. 実装（コーディング）
実際にプログラムを書く工程です。
やること
- 設計に基づいてコードを書く
- コーディング規約（コードの書き方ルール）に従う
- コードレビューを受ける
具体例：ネットショップの場合
「商品をカートに追加する機能」を実装する場合：
- ユーザーがカートに追加ボタンを押す
- 商品IDと数量を受け取る
- カートに商品を追加する
- カート画面を表示する
これをもとに、実際のコードを書きます。
ポイント
- 1年目エンジニアが最も多く時間を使う工程
- 書いたコードは必ずレビューを受け、指摘があれば修正する
4. テスト
作ったものが正しく動くか確認する工程です。
テストの種類
テストには複数の種類があり、小さい範囲から大きい範囲へと段階的に行います。
| テストの種類 | 何を確認するか | 具体例 |
|---|---|---|
| 単体テスト | 個々の機能が正しく動くか | 「カートに追加」で商品がカートに入るか |
| 結合テスト | 複数の機能を組み合わせて正しく動くか | カート追加→カート表示→購入まで動くか |
| システムテスト | システム全体が要件を満たすか | 1000人同時アクセスでも動くか |
| 受け入れテスト | お客様の期待どおりか | お客様に実際に触ってもらう |
ポイント
- テストで見つかった問題は、原因を調べて修正する
- テストをしっかり行うことで、リリース後の問題を減らせる
5. リリース・運用
システムを本番環境で稼働させる工程です。
やること
- 本番環境への導入（デプロイ）
- 運用開始後の監視
- 問題発生時の対応
具体例
- サーバーが落ちていないか監視する
- エラーが発生していないかログを確認する
- 「動かない」という問い合わせがあれば調査する
6. 保守
運用中のシステムを維持・改善する工程です。
やること
| 種類 | 具体例 |
|---|---|
| バグ修正 | 「商品を2個カートに入れたのに1個しか入らない」→ 原因を調査して修正 |
| 機能追加 | 「お気に入り機能が欲しい」→ 新しい機能を追加 |
| 改善 | 「ページの表示が遅い」→ パフォーマンスを改善 |
ポイント
- 既存システムのバグ修正は、1年目によく任される仕事
- 既存のコードを読んで理解する必要があり、コードリーディング力が鍛えられる
開発手法による違い
これらの工程は共通ですが、「いつ」「どのように」行うかは開発手法によって異なります。
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 工程の進め方 | 順番に1回ずつ行う | 短いサイクルで繰り返す |
| 要件定義のタイミング | 最初に全部決める | 少しずつ決めていく |
| 設計の深さ | 詳細まで最初に決める | 必要な分だけその都度決める |
| テストのタイミング | 実装後にまとめて行う | 実装と並行して継続的に行う |
flowchart TD
subgraph WF["【ウォーターフォール】"]
WF1["要件定義"] --> WF2["設計"] --> WF3["実装"] --> WF4["テスト"] --> WF5["リリース"] --> WF6["保守"]
end
subgraph AG["【アジャイル】"]
subgraph S1["スプリント1"]
AG1["要件"] --> AG2["設計"] --> AG3["実装"] --> AG4["テスト"]
end
subgraph S2["スプリント2"]
AG5["要件"] --> AG6["設計"] --> AG7["実装"] --> AG8["テスト"]
end
subgraph S3["スプリント3"]
AG9["要件"] --> AG10["設計"] --> AG11["実装"] --> AG12["テスト"]
end
S1 --> S2 --> S3
end
どちらの手法でも、「要件定義→設計→実装→テスト」という流れ自体は存在します。違うのは「全体を一度にやるか」「小さく分けて繰り返すか」です。
詳しくは以下を参照してください：
1年目エンジニアの関わり方
1年目は主に以下の工程に関わることが多いです。
| 工程 | 1年目の関わり方 | 頻度 |
|---|---|---|
| 要件定義 | 要件定義書を読んで理解する | 少ない |
| 設計 | 設計書を読んで理解する | 中程度 |
| 実装 | 設計に基づいてコードを書く | 多い |
| テスト | テスト仕様書に基づいてテストを実行する | 多い |
| 保守 | 既存システムのバグ修正を担当する | 多い |
実装・テスト・保守が中心です。これらの作業を通じて、コーディングスキルやシステム理解を深めていきます。
まとめ
- ソフトウェア開発には「要件定義」「設計」「実装」「テスト」「リリース」「保守」という工程がある
- これらの工程はどの開発手法でも共通して存在する
- 開発手法によって「いつ」「どのように」行うかが異なる
- 1年目は主に実装・テスト・保守に関わることが多い
具体的な開発手法については、以下を参照してください：
- ウォーターフォール開発 - 工程を順番に進める手法
- アジャイル開発 - 短いサイクルで繰り返す手法