システム開発の流れ

「何を作るか決める」から「使い続けられるようにする」まで。システム開発の6つの工程を、レストランの新メニュー開発と、飲食店のWeb予約システムという2つの例で、順番に見ていきます。

30秒でわかるシステム開発

むずかしい言葉はあとで大丈夫。まずは6つの「やること」を順番に。工程を押すと、くわしい説明に移動します。

6つの工程をくわしく

それぞれの工程で「何をするのか」「何ができあがるのか」を、🍴 新メニュー開発と💻 Web予約システムの2つの例で見ていきます。例はどちらも、6つの工程を通して同じ話が続きます。

1要件定義

要件定義のイメージイラスト。タブレットを手にした男性が、ヒアリング内容をまとめたボードを指差している

何を作るか決める

この工程でやること

「誰が、何のために、どんなシステムを使うのか」を整理して、作るものを決める工程です。必要な機能だけでなく、「いつまでに作るか」「どのくらいの人が使うか」「どんな条件を守る必要があるか」なども確認します。

ここがあいまいだと、あとから「欲しかったものと違う」となり、大きな作り直しにつながることがあります。

🍴 新メニューでたとえると

新しいメニューを考える最初の段階です。「誰に食べてもらいたいか」「どんな料理にするか」「いくらで提供するか」「アレルギーへの対応は必要か」などを決めます。まだ料理は始めません。まず「何を作るのか」を決めます。

💻 Web予約システムなら

「24時間ネットから予約できる」
「日付・時間・人数を選べる」
「お店側も予約を確認できる」

など、必要な機能を決めます。

要件定義書のイメージ。チェックリストの形で、24時間・日付・お店側の確認といった条件が並んだメモ

この工程でできあがるもの: 要件定義書（作るものの条件をまとめた文書）

次の「設計」は、この要件定義書をもとに進みます。

関わる職種：プロジェクトマネージャー、データアナリスト

2設計

設計のイメージイラスト。女性がノートパソコンに向かい、背後に画面のワイヤーフレームが表示されている

どう作るか決める

この工程でやること

要件定義で決めた「何を作るか」を、実際に作れる形まで具体的にする工程です。どんな画面にするか、どんなデータを保存するか、ボタンを押したときに何が起きるかなどを、図や文書にして整理します。

要件定義＝何を作るか設計＝どう作るか

🍴 新メニューでたとえると

料理のレシピを作る段階です。使う材料、分量、調理手順、盛り付け方などを決めます。「ハンバーグを作る」と決めるのが要件定義なら、「どんな材料を使ってどう作るか」を決めるのが設計です。

💻 Web予約システムなら

予約入力画面、予約確認画面、お店側の管理画面を考える。
予約日時、人数、名前などの情報をどのように保存するか決める。データをためておく場所のことを「データベース」と呼びます。

この工程でできあがるもの: 設計書（画面の設計図、データの設計図など）

次の「開発・実装」は、この設計書を見ながら作ります。

関わる職種：Webデザイナー、バックエンド、インフラ

3開発・実装

開発のイメージイラスト。眼鏡をかけた男性がノートパソコンでプログラムを書いている

実際に作る

この工程でやること

設計で決めた内容をもとに、実際にシステムを作る工程です。プログラムを書いたり、データベースを作ったり、システムを動かすためのコンピューター（サーバー）を用意したりして、設計図だったものを実際に動くシステムへ変えていきます。

一般にイメージされる「エンジニアがプログラムを書く仕事」は、この工程です。現場ではこの作業を「実装」や「コーディング」とも呼びます。

🍴 新メニューでたとえると

作ったレシピを見ながら、実際に料理を試作する段階です。料理人ごとに担当を分けながら、レシピを本物の料理にしていきます。作っている途中でレシピに足りない部分が見つかったら、設計を見直すこともあります。

💻 Web予約システムなら

予約フォームを作る。
予約内容を保存するプログラムを作る。
店舗側が予約一覧を確認できる管理画面を作る。

プログラムのイメージ。コードが書かれたエディタの画面と、ファイルの入ったフォルダ

この工程でできあがるもの: プログラム（書かれた中身は「ソースコード」と呼びます）と、動く状態のシステム

次の「テスト」で、このプログラムが決めたとおりに動くかを確かめます。

関わる職種：フロントエンド、バックエンド、インフラ

4テスト

テストのイメージイラスト。虫眼鏡を手にした人が、チェックリストを1つずつ確認している

正しく動くか確かめる

この工程でやること

作ったシステムが、決めたとおりに動くか確認する工程です。普通に使った場合だけでなく、「間違った情報を入力したら？」「同時にたくさんの人が使ったら？」「途中で通信が切れたら？」といったケースも確認します。

うまく動かない箇所は「バグ」と呼ばれます。見つかったら修正し、もう一度確認します。

補足：テストの種類

現場では、部品ひとつずつを確かめる「単体テスト」、部品を組み合わせて確かめる「結合テスト」、全体を通して確かめる「総合テスト」のように、小さい単位から順に進めることが多いです。くわしくは「テストとは？」をご覧ください。

🍴 新メニューでたとえると

完成した料理を試食する段階です。「味は狙ったとおりか」「量は適切か」「盛り付けは崩れていないか」「何度作っても同じ品質になるか」などを確認します。お客さんに出す前に問題を見つけます。

💻 Web予約システムなら

満席なのに予約できてしまわないか。
同じ時間に予約が重複しないか。
間違った日付を入力した場合にエラーになるか。

などを確認します。

テスト済みシステムのイメージ。チェックの入った確認リストと、虫眼鏡で確かめている画面

この工程でできあがるもの: テスト済みのシステム（確認した内容と結果の記録つき）

次の「リリース」で、確認を終えたシステムを利用者に届けます。

関わる職種：QAエンジニア（全職種が協力）

5リリース

リリースのイメージイラスト。ノートパソコンの前で親指を立てる人と、クラウドへの公開を表す雲と上向き矢印

利用者が使える状態にする

この工程でやること

完成したシステムを、実際の利用者が使える状態にする工程です。本番用のサーバーへプログラムを配置する作業などを行います。この作業を「デプロイ」と呼びます。

必要であれば古いシステムからデータを移したり、問題が起きた場合に元へ戻せるよう準備したりします。利用者はインターネット上の一般の人とはかぎらず、社内の人だけが使うシステムでも、同じようにリリースがあります。

🍴 新メニューでたとえると

試食をクリアした料理を正式なメニューに載せ、販売を始める段階です。材料を用意し、スタッフに作り方を共有して、実際のお客さんから注文を受けられる状態にします。

💻 Web予約システムなら

完成した予約システムを本番環境へ公開し、お店のWebサイトから実際に予約できる状態にします。

利用できるサービスのイメージ。予約完了の画面が表示されたスマートフォンと、公開を表す雲

この工程でできあがるもの: 利用できるサービス

ここからは「運用・保守」。システムが使われている間、ずっと続きます。

関わる職種：インフラ、QA、プロジェクトマネージャー

6運用・保守

使い続けられるようにする

この工程でやること

システムは公開したら終わりではありません。正常に動いているか確認し、問題が起きたら直し、利用者からの要望に合わせて機能を追加していきます。

利用者が増えれば、より多くのアクセスに耐えられるようシステムを強化することもあります。こうして、システムを安定して使い続けられる状態に保ちます。公開後も、長く運用や改善が続きます。

🍴 新メニューでたとえると

販売を始めたあとの改善です。「注文が多い」「量が多すぎる」「もっと辛くしてほしい」といった売れ行きやお客さんの声を見ながら、レシピや提供方法を改善します。必要なら新しいバージョンのメニューを作ります。

💻 Web予約システムなら

エラーが起きていないか確認する。
不具合を修正する。
「ネットからキャンセルできるようにしてほしい」などの要望があれば、新機能として追加する。

改善要望のイメージ。お客さんの声の吹き出しと売れ行きのグラフ、そして最初の工程に戻る矢印

この工程でできあがるもの: 安定して動き続けるシステムと、次の改善につながる「改善要望」

出てきた改善要望は、また「要件定義」に戻って、次の改善が始まります。

関わる職種：インフラ、データアナリスト（全職種が関与）

工程は「できあがったもの」でつながる

前の工程でできたものが、次の工程の材料になります。だから工程を分けて進めます。そして、使い始めたあとに出た改善要望は、また最初の工程に戻ってきます。

01 要件定義要件定義書
02 設計設計書
03 開発・実装プログラム
04 テストテスト済みシステム
05 リリース利用できるサービス
06 運用・保守改善要望

改善要望が出たら、また「01 要件定義」に戻ります。システム開発は一度作って終わりではなく、改善をくり返す流れです。

コラム：順番どおりに進む開発、小さく回す開発

ウォーターフォール開発とアジャイル開発

ここまでの6つの工程を、要件定義から順番に進めることを基本とする進め方がウォーターフォール開発です。最初に全体を決めてから作るので、大きなシステムや、はじめに決めるべきことがはっきりしている開発で使われることが多いです。前の工程に戻ることもありますが、戻るほど手間がかかるため、各工程をしっかり終えてから次へ進みます。

アジャイル開発は、最初にすべてを決めてから作るのではなく、小さな単位で「考える → 作る → 確かめる」を繰り返しながら、使える機能を少しずつ増やしていく進め方です。実際に使ってもらった反応を見ながら、次に作るものを変えることもあります。進め方やサイクルの長さは、チームやプロジェクトによって異なります。

どちらも、通る工程そのものは同じです。ちがうのは「どの順番で、どのくらいの大きさで進めるか」です。

2つの進め方のイメージ。通る工程は同じで、進め方がちがいます。

次のルートへ

エンジニア職種図鑑

各工程で登場した「フロントエンド」「QA」って結局どんな人？　7つの職種をレストランの仕事にたとえて紹介します。

IT用語集

「デプロイ」「バグ」など、このページに出てきた言葉ももう一度引けます。

ITの学び方ガイド

「自分でもやってみたい」と思ったら、教材の選び方へ。