要件定義
「そもそも、何を作るのか」を決める工程。
お客さま(または自社の企画担当)に「誰が、どんなときに使うのか」「何ができれば成功なのか」を聞き出し、作るものの条件を文章にまとめます。ここがあいまいなまま進むと、「思っていたものと違う」が完成間際に発覚します。開発トラブルの多くは、この工程の行き違いが原因です。
- 主にできあがるもの
- 要件定義書(作るものの条件を書いた文書)
- 活躍する職種
- プロジェクトマネージャー、データアナリスト
「何を作るか決める」から「作ったあとの面倒を見る」まで。システム開発の6つの工程を、順番に見ていきます。
上の6つを、ひとつずつ見ていきます。
「そもそも、何を作るのか」を決める工程。
お客さま(または自社の企画担当)に「誰が、どんなときに使うのか」「何ができれば成功なのか」を聞き出し、作るものの条件を文章にまとめます。ここがあいまいなまま進むと、「思っていたものと違う」が完成間際に発覚します。開発トラブルの多くは、この工程の行き違いが原因です。
「どうやって作るのか」を図面に起こす工程。
画面の見た目、データの保存のしかた、システム同士のつなぎ方を、作る前に図面と仕様書にします。利用者から見える部分を決める「基本設計」と、プログラマーが作業できる細かさにする「詳細設計」の2段階があります。
設計書をもとに、実際にプログラムを書く工程。
世間の「エンジニアの仕事」のイメージはこの工程ですが、全体の一部にすぎません。画面側を作るフロントエンドと、裏側を作るバックエンドが分担して組み立てます。現場ではこの作業を「実装」や「コーディング」と呼びます。
「本当にちゃんと動くのか」を徹底的に確かめる工程。
部品ひとつずつの「単体テスト」、組み合わせの「結合テスト」、全体を通しの「総合テスト」と、小さい単位から順に検査します。「変な操作をされても壊れないか」「1万人が同時に使っても耐えられるか」も確認します。不具合(バグ)は、リリース前に見つかるほど「良いテスト」です。
完成したシステムを、実際に使える状態で世に出す工程。
プログラムを本番用のサーバーに配置する作業を「デプロイ」と呼びます。利用者への告知、古いシステムからのデータ引っ越し、問題が起きたときに元へ戻す手順の準備まで、この工程の仕事です。
リリースはゴールではなくスタート。作ったあとの面倒を見続ける工程。
システムが止まっていないか24時間監視し、不具合を直し、利用者の増加に合わせてサーバーを増強し、データを見て次の改善を考えます。システムにかかる費用と時間の大半は、実はこの「作ったあと」に発生します。
「要件定義→設計→開発→テスト→リリース」を、滝の水が落ちるように一方通行で進めるのがウォーターフォール開発。銀行のシステムのように、最初に全体をきっちり決めたい大規模開発で使われます。
同じ6つの工程を1〜2週間の短いサイクルで何周も回すのがアジャイル開発。小さく作って反応を見て、また少し作る。スマホアプリやWebサービスの多くはこの方式です。通る道は同じで、進み方がちがうだけです。