ROUTE 1 — 各駅停車
アプリもWebサービスも、いきなりプログラムを書き始めるわけではありません。「何を作るか決める」駅から「作ったあとの面倒を見る」駅まで、6つの駅を順番にたどっていきます。急行はありません——どの駅も飛ばすと、あとで必ず引き返すことになるからです。
Requirements Definition
「そもそも、何を作るのか」を決める工程です。 お客さま（または自社の企画担当）に「誰が、どんなときに使うのか」「何ができれば成功なのか」を細かく聞き出し、作るものの条件を文章にまとめます。
ここで決めたことが、あとのすべての工程の土台になります。逆に言うと、ここがあいまいなまま進むと「思っていたものと違う」が完成間際に発覚します。システム開発のトラブルの多くは、実はこの駅で起きた行き違いが原因です。
Design
「どうやって作るのか」を図面に起こす工程です。 画面の見た目やボタンの配置を決める設計、データをどう保存するかの設計、システム同士のつなぎ方の設計など、作る前に細かい図面と仕様書を用意します。
大きく分けて、利用者から見える部分を決める「基本設計」と、プログラマーが作業できるレベルまで細かくする「詳細設計」の2段階があります。
Development
設計書をもとに、実際にプログラムを書く工程です。 世間の「エンジニアの仕事」のイメージはたいていこの工程ですが、実際には全体の一部にすぎません。画面側を作るフロントエンドエンジニアと、裏側の仕組みを作るバックエンドエンジニアが、分担しながら組み立てていきます。
プログラムを書くことを、現場では「実装（じっそう）」や「コーディング」と呼びます。書いたそばから小さな動作確認を繰り返し、設計どおりに動くように仕上げていきます。
Testing
「本当にちゃんと動くのか」を徹底的に確認する工程です。 部品ひとつひとつを確かめる「単体テスト」、部品を組み合わせて確かめる「結合テスト」、全体を通しで確かめる「総合テスト」と、小さい単位から順に検査していきます。
「正しく動くか」だけでなく、「変な操作をされても壊れないか」「1万人が同時に使っても耐えられるか」も確認します。不具合（バグ）を見つけるのは悪いことではなく、リリース前に見つかるほど「良いテスト」です。
Release
完成したシステムを、実際に使える状態で世に出す工程です。 作ったプログラムを本番用のサーバーに配置する作業を「デプロイ」と呼びます。利用者への告知、古いシステムからのデータ引っ越し、万一問題が起きたときに元へ戻す手順の準備まで、この駅の仕事です。
リリースの瞬間はチーム全員が画面を見守る、いちばん緊張感のあるイベント。深夜や早朝など、利用者が少ない時間帯を選んで行われることもよくあります。
Operation & Maintenance
リリースはゴールではなくスタート。作ったあとの面倒を見続ける工程です。 システムが止まっていないか24時間監視し、不具合が見つかれば直し、利用者の増加に合わせてサーバーを増強し、データを分析して「次はこう改善しよう」を考えます。
実は、システムにかかる費用と時間の大半は、作るときではなくこの「作ったあと」に発生します。長く愛されるサービスほど、この駅で働く人たちの存在が大きいのです。
ここまで紹介した「要件定義→設計→開発→テスト→リリース」を、滝の水が落ちるように一方通行で進めるやり方をウォーターフォール開発と呼びます。銀行のシステムのように「最初に全体をきっちり決めたい」大規模開発で使われます。
一方、この6つの駅を1〜2週間の短いサイクルで何周も回すやり方がアジャイル開発です。小さく作って利用者の反応を見て、また少し作る——スマホアプリやWebサービスの多くはこの方式です。
どちらが正解というものではなく、「路線は同じで、走り方がちがう」と考えるとわかりやすいです。