開発プロセスとは？わかりやすく解説
システムを作る流れと、ウォータフォール・アジャイルの違いを学びます。
最初に考えてみよう
システムをいきなり作り始めると、完成してから「思っていたものと違う」と分かることがあります。どうすれば、大きな失敗を減らしながら開発を進められるのでしょうか？
解説
1工程は「成果物」でつながっている
各工程は、前の工程の成果物をもとに次の成果物を作ります。 設計書は要件定義書を、プログラムは設計書を土台にしています。
- 要件定義要件定義書何を作るか
- 設計設計書どう作るか
- 実装プログラム実際に作る
- テストテスト結果正しく動くか確かめる
2仕様変更は、前の工程まで波及する
例：「会員ランク機能を追加したい」という同じ変更。気づいたタイミングで、直す量がこれだけ変わります。
- 要件定義書修正
- 設計書まだない
- プログラムまだない
- テスト結果まだない
- 要件定義書修正
- 設計書修正
- プログラム修正
- テスト結果やり直し
3ウォーターフォールとアジャイルをくらべる
| ウォーターフォール | アジャイル | |
|---|---|---|
| 進め方 | 工程を順番に下る | 小さく作って反復 |
| 計画 | 最初に全部決める | 区切りごとに見直す |
| 変更 | 弱い（後戻りが大変） | 強い（次の反復で対応） |
| 向く開発 | 仕様が固まっている | 要望が変わりやすい |
※ 開発の工程そのもの（要件定義→設計→製造→テスト→運用）はどちらも同じ。進め方が違うだけです。
4これはどっち？
最初に全体を決め、工程を順番に進めて完成させる
小さく作って利用者に見せ、反応を見て改善する
仕様が固まっていて、後から大きく変わらない開発
要望が変わりやすく、早く形にして試したい開発
5開発モデル4つと、向いている場面
ウォーターフォール
要件を確定してから、工程を上から順に進める
向く：要求事項が明確で、仕様変更が少ない
プロトタイピング
早い段階で確認用のソフトウェア（試作品）を作り、利用者に見せて要求を確かめる
向く：利用者の要求が目に見えないと固まらない
スパイラル
設計・開発・評価などのサイクルを、渦巻きのように何周もくり返して大きくしていく
向く：大きなシステムを、リスクを見ながら少しずつ
アジャイル
機能を小さい単位に分け、優先度の高いものから短期間で開発とリリースをくり返す
向く：変更が多い。例：2週間ごとに新バージョンを出す
アジャイルは、ウォーターフォールの課題を改善する形で提唱され、開発工程で生じる種々の変更に迅速に対応できるようにした手法の総称です。 新機能の候補や不具合を一覧表で管理し、優先順位をつけて逐次リリースするのもアジャイル。
6アジャイルの手法：XPとスクラム
アジャイルは手法の総称で、代表が XP と スクラム。どちらも短いサイクルでリリースをくり返します。
XP（エクストリームプログラミング）
要求の変化に対応した高品質のソフトウェアを、短いサイクルでリリースするアジャイル開発のアプローチの一つ。次のような実践を含みます。
- ペアプログラミング
- 1つのプログラムを2人のプログラマが、1台のコンピュータに向かって共同で開発する
- テスト駆動開発
- テストプログラムを先に作成し、そのテストに合格するようにコードを書く
- リファクタリング
- プログラムの振る舞い（機能仕様）を変えずに、内部構造を改善する
スクラム
数週間のスプリントごとに、チームで計画・開発・振り返りをくり返す。
試験では「XPの説明は？」に、ペアプログラミングやテスト駆動開発の説明が誤りとして並びます。それらはXPの中の実践の1つで、XPそのものの説明ではありません。
7DevOps：開発と運用が手を組む
Dev（開発）とOps（運用）を合わせた言葉。開発側と運用側が密接に連携し、自動化ツールを取り入れて、機能の導入や更新を迅速に進めます。
開発側（Dev）
- 計画
- 開発
- テスト
運用側（Ops）
- リリース
- 運用
- 監視
運用で見つけた改善点を、すぐ次の開発へ。この輪を速く回す
| DevOps と並ぶ誤りの選択肢 | 本当は |
|---|---|
| 要件定義で開発側がプロトタイプを作り、画面イメージを確かめる | プロトタイピング |
| 設計・開発・テストを順に行い、全部揃えてから運用側に引き渡す | ウォーターフォール |
| 1つのプログラムを2人で共同開発する | ペアプログラミング |
| 固定された短期間のサイクルをくり返し、機能を順次追加する | アジャイル |
8作ったソフトウェアを読み解く・本番に入れる
運用中のソフトウェアの仕様書がないとき、ソースコードを解析して仕様書を作るのがリバースエンジニアリング。 似た名前の言葉と区別します。
- リバースエンジニアリング
- ソースコードなどを解析して、仕様書を作る（仕様を明らかにする）
- リファクタリング
- 機能仕様を変えずに、内部構造を改善する
- コードレビュー
- 書いたプログラムを、他の人が読んで誤りを見つける
- デザインレビュー
- 設計書を、関係者が確認して誤りを見つける
ソフトウェア導入
開発が完了したソフトウェアを本番環境にインストールする手順を明確にし、それを実施する工程。順番は必ずこう：
- 1導入計画書を作る→
- 2関係者の合意を得る→
- 3本番環境に導入（インストール）する
新規開発でも、自社開発でも、本番稼働中のソフトウェアへの機能追加でも同じ。導入してから計画書を作る・合意を後回しにするのは誤り。
統合（部品を組み合わせる）・妥当性確認（使う目的に合うか確かめる）・利用者教育は、導入とは別の作業です。
9どの言葉？
- 開発側と運用側が連携し、自動化ツールで新機能の導入や更新を迅速に進める。
- テストプログラムを先に作り、それに合格するようにコードを書く。
- 仕様書のない運用中のソフトウェアを解析して、仕様書を作った。
- 要求事項が明確で、仕様変更が少ないと見込まれる開発に向く。
- 機能追加したソフトウェアを本番に入れる。最初にすることは？
試験のポイント
ITパスポート試験での問われ方
開発モデルの特徴と向いている場面が問われる
間違えやすいポイント
- アジャイルは計画しない開発だと思う
- ウォータフォールは古いので常に悪いと思う
関連用語
ウォータフォール、アジャイル、スプリント、要件定義
図解の内容を文章で読む
開発プロセスをイメージでつかむ
システム開発は、要件を決め、設計し、作り、テストし、運用する流れで進みます。ウォータフォールは工程を順番に進める方法、アジャイルは小さく作って確認しながら改善する方法です。
たとえると：家を設計図通りに一気に建てるのがウォータフォール、試作品を少しずつ試して直すのがアジャイルです。
システム開発は、要件定義（何を作るか決める）→設計→プログラミング→テスト→運用、という流れで進みます。この進め方に2つの代表的なモデルがあります。ウォータフォールは、滝の水が戻らないように工程を順番に進め、前の工程を完了させてから次へ進む方法です。全体の計画が立てやすい一方、あとからの要望変更に対応しにくいのが弱点です。アジャイルは、動くものを短い期間で小さく作り、利用者の反応を確かめながら「作っては直す」をくり返す方法です。変化に強い一方、「無計画に作る」という意味ではありません（計画も文書もあります）。試験では「途中の変更に柔軟に対応しやすい開発手法はどれか」（＝アジャイル）のように、特徴と向いている場面が問われます。
押さえどころ
- 開発は要件定義から運用までの流れ
- ウォータフォール = 順番に進める
- アジャイル = 小さく反復する
確認問題（4問）
確認問題は本サービスのオリジナル問題です。ログインなしで解けます（結果は保存されません）。
「開発プロセス」の過去問（13問）
IPAが公開しているITパスポート試験の公開問題から、このテーマの問題を集めました。
つながるテーマ
学習を記録して、合格まで続ける
教材と確認問題はこのページで全部無料で使えます。登録すると「開発プロセス」の結果や習熟度が記録され、苦手分野の復習提案、試験日までの学習計画、合格準備度の見える化が使えます。最初の7日間は学習記録も無料です。