0.全体像

実際の開発では、複数人で分担して 1 つのソフトウェアを作ります。企画から完成までをチームで進めるこの開発を チーム開発 と呼びます。本セクションでは、Web アプリケーションを題材に、その進め方を扱います。

チームでの開発には、2 つの側面があります。1 つは、企画から実装・テストへと進める 開発プロセス です。もう 1 つは、その進行や品質を管理する プロジェクト管理 です。

1. 開発プロセス

開発プロセスは、フェーズ に分かれます。

1-1. 5 つのフェーズ

フェーズは、企画・要件定義・設計・実装・テストの 5 つです。

1. 企画

   誰のどんな課題を解決するのかを明らかにします。解決策から考えるのではなく、ユーザーが抱える課題と、それを解く価値から考えます。

   例：Q&A サイトでは、「コーディングで行き詰まった開発者が、信頼できる回答に早くたどり着けない」という課題を取り上げ、最良の回答に早く届く価値を明らかにします。

2. 要件定義

   企画で明らかにした課題と価値を、実現すべき機能と条件に具体化します。ユーザーができることだけでなく、性能や安全性、守るべきビジネスルールといった、画面に現れない条件も洗い出します。

   例：「質問を投稿する」「回答に投票する」などの機能と、「自分の回答には投票できない」という条件を定めます。

3. 設計

   要件を、どう作るかに具体化します。ユーザーが見る画面、データの構造、プログラムの構成を決めます。

   例：質問一覧の画面、質問や回答を保存するテーブル、それらを処理するクラスの構成を設計します。

4. 実装

   設計にもとづいて、画面や処理をコードとして記述します。

   例：質問一覧の画面と、質問を保存する処理を実装します。

5. テスト

   作ったソフトウェアが要件のとおりに動作するかを確認します。期待どおりに動作することに加え、誤った操作でも不具合が生じないことも確かめます。

   例：投稿した質問が一覧に表示されること、自分の回答には投票できないことを確認します。

1-2. 成果物の受け渡し

各フェーズは、その成果を成果物として残します。企画で決めた内容は、要件定義書から順に、文書やコードとして形になります。

フェーズ	主な成果物
要件定義	要件定義書
設計	設計書（画面・ER 図・URL設計・アーキテクチャ設計）
実装	ソースコード
テスト	テストコード・テスト結果

残した成果物は、次のフェーズの前提になります。前のフェーズがあいまいなまま進むと、後のフェーズで不足が見つかり、前の段階までさかのぼって直すことになります。

2. プロジェクト管理

開発プロセスを計画どおりに進め、コードと品質を保つのがプロジェクト管理です。

2-1. 作業の管理

作業はメンバーで分担し、同時に進めます。必要な作業を整理して担当を決め、進捗を把握します。

作業	内容
作業の分解（WBS）	プロジェクト全体の作業を、担当できる大きさまで分解する
割り当て	分解した作業を、メンバーそれぞれに割り当てる
進捗の把握	各作業の状況を共有し、遅れを早めに見つける
振り返り（KPT）	区切りごとに進め方を見直し、次に活かす

担当が分かれていても、作るソフトウェアは 1 つです。何を作るか、機能どうしの連携をチームで共有しなければ、各自の成果を統合したときに不整合が生じます。

2-2. コードと品質の管理

複数人が同じコードに同時に変更を加えるため、それらを 1 つにまとめ、品質を保つ仕組みが要ります。

手段	役割
バージョン管理（Git）	各自の変更を 1 つにまとめ、競合を解消し、変更の履歴を残す
レビュー	取り込む前に、ほかのメンバーがコードを読んで確認する
テスト	動作をコードで確かめ、変更のたびに繰り返し検証する

Info

テストは開発プロセスの最後のフェーズであると同時に、変更のたびに繰り返し実行して品質を保ち続ける手段でもあります。