はじめに
プロダクト開発を行うにあたり、とりあえず開発を進めるのではなく開発プロセスに沿うことで、効率的かつ品質を保ちつつ進めることが出来るとされます。そこで、どのような開発プロセスがあるのか代表的なプロセスの概要をまとめてみたいと思います。
開発プロセスとは？
そもそもプロセスとは工程（や処理）を意味する言葉ですので、開発プロセスとはプロダクト開発にあたり各工程を実施する順序や、その中で行う処理や成果物を定めたものです。
開発プロセスを用いる目的
- システム開発の効率化・品質向上
- 多数のメンバー間で開発を進める際の共通認識を取りやすくする
- どのようなシステムを構築しているのかクライアントとの共通認識を取りやすくする 等
今回紹介するモデル
ウォーターフォールモデル
概要
要件定義・外部設計・内部設計といったシステム開発の各工程を、上流工程から下流工程へ順に行っていく手法
特徴
- 始めに全体の計画・設計を決定し計画に沿って実装する
- 工程が次工程に進んだら前工程に（基本）戻らない
- 大規模開発で適用されやすい
- すべてが揃ってからリリースされる
メリット
- スケジュールを組みやすい、計画通りに進めやすい
- 予算が立てやすい
- 工程ごとのリソース管理がしやすい
- 品質の担保がしやすい
デメリット
- 開発が長期化しやすい
- 仕様の変更は難しい
- 作業ミスが発覚した際の戻りが大きい（予算・納期）
向いている案件
- 規模の大きなプロジェクト
- スピードより品質が重視されるプロジェクト
開発の流れ
| 工程 | 概要 |
|---|---|
| 1．要件定義 | クライアントの要件をヒアリングし要件定義書にまとめる |
| 2．設計 | 要件定義書に基づき、外部設計書（I/F）、内部設計書を作成。DB定義書や外部連携・ファイルレイアウトなど必要に応じて定義する |
| 3．開発 | 設計書に基づき開発を進める |
| 4．テスト | 要件定義書・設計書等に基づきテストを実施 |
| 単体テスト | 機能単位で行うテスト |
| 結合テスト | 各機能を連結させ動作を評価するテスト |
| システムテスト | システム全体を対象としたテスト |
| 受入テスト | 本番環境で要件を満たせているか評価するテスト・ユーザーも実施 |
| 5．リリース | 旧システムからのデータ移行なども含む |
| 6．運用・保守 | システム監視・障害時の対応・不具合改修 等 |
また、ウォーターフォールモデルでは、品質向上のため、V字モデルが併せて採用されることがある。（各工程で作られた定義・設計書をどのテスト工程で検証に利用するか定義されているモデル）
V字モデル簡易図
アジャイルモデル
概要
従来の開発手法に比べ開発期間が短縮されることから、アジャイル（素早い、機敏な）と呼ばれている。今回は開発手法として、スクラム、エクストリーム・プログラミング（XP）を後述で紹介します。
特徴
- システムを機能単位で分け、実装・テスト・リリースを繰り返す（イテレーション）
- 事前にすべてを計画することは難しいという前提で、始めは7,8割程度の仕様を決める
- 仕様を決め切らないため臨機応変に対応できる（= 仕様変更に強い）
- ユーザーと密な意思疎通を行う必要がある
- リリースまでのスピードを重視した開発に向いている
メリット
- 仕様調整にユーザーとコミュニケーションを頻繁に行う必要があり齟齬が少ない
- 1つのリリースまでの開発期間を短くしやすい
- 作業ミスが見つかった場合の戻りが小さい、仕様変更に強い
デメリット
- 全体のスケジュール進捗が把握しにくい
- 機能単位で開発するためシステム全体の整合性にずれが発生する場合がある
- 仕様変更が頻繁に発生すると開発の方向性があやふやになる
- 要件を収束させないと長期化したり予算が膨れる
向いている案件
- 仕様が決まり切らない新規事業
- 機能を徐々に作りこんでいくWEBサービスやアプリ開発 等
スクラム
特徴
- プロダクトバックログと呼ばれる要求や必要性などを基準に並べ替えたリストを作成する
- 役割（ロール）が定義されている
- 実施する作業のイベントが定義されている
ロール
- プロダクトオーナー（プロダクト全体、プロダクトバックログ責任者）
- スクラムマスター（チーム活動の運営・効率化、作業における障害の除去）
- 開発メンバー（理想は全員が設計～運用までのスキルがあることだがチームとしてでも）
イベント（この一連の流れをスプリントと呼ぶ）
- スプリントプランニング（ゴール達成に向けた作業を計画）
- デイリースクラム（ゴール達成に向け進捗・問題・解決策などの共有）
- バックログリファインメント（プロダクトバックログの優先度や見積もりなど詳細化）
- スプリントレビュー（スプリントの結果を披露しフィードバックを得る）
- スプリントレトロスペクティブ（スプリント中の活動やプロセスの振り返り）
開発の流れ
基本の流れは下記のスプリントをイテレーション単位で繰り返す
| 工程 | 概要 |
|---|---|
| 1．プロダクトバックログ | プロダクトバックログから機能を選定 |
| 2．スプリントプランニング | ゴール達成に向けた作業を計画 |
| 3．デイリースクラム | 日々ゴール達成に向け進捗・問題・解決策などの共有 |
| 4．開発 | |
| 要件定義 | 該当機能の要件をヒアリングし要件定義書にまとめる |
| 設計 | 要件定義書に基づき設計を実施 |
| 開発 | 設計書に基づき開発 |
| テスト | 要件定義書、設計書に基づきテストの実施 |
| 5．リファインメント | バックログの優先度や見積りなどの精査・詳細化 |
| 6．スプリントレビュー | ステークホルダーに披露しフィードバックを得る |
| 7．レトロスペクティブ | スプリント中の活動やプロセスの振り返り |
その他、成果物や完成の定義、基準をクライアント・プロダクトオーナー・開発チームで定めておく。
エクストリーム・プログラミング
特徴
- 小規模な人数の開発に適している
- 開発技術を要する活動が多くある
- 重視すべき「5つの価値」が定められている
- 実践すべき4つの領域/19のプラクティスにまとめられている
（当初は12のプラクティスだが内容の追加・変更が行われている）
5つの価値
- コミュニケーション（開発者間、クライアントとコミュニケーションを密にとり円滑に）
- シンプル（始めから複雑な設計にせず必要最小限とし状況に合わせ設計を変更）
- フィードバック（頻繁なフィードバック、ユニットテストの自動化を繰返し精度をあげる）
- 勇気（途中で大きな設計変更があっても立ち向かう）
- 尊重（他のメンバーを尊重し生産性を高める）
実践すべき4つの領域/19のプラクティス
共同プラクティス
- 反復（機能を細分化しイテレーションを繰返し実施）
- 共通用語（用語集の作成、コミュニケーションミスを防止）
- 作業空間（開発者とクライアントのコミュニケーションを取り易くし集中可能な環境を）
- 回顧（状況の把握、フィードバックの対応を迅速に、振り返り可能な体制）
開発プラクティス
- テスト駆動開発（まずテストコードを作成し機能を明確化したシンプルな設計とする）
- ペアプログラミング（2人1組で実装・コードレビューを行い不具合のリスクを減らす）
- リファクタリング（内部構造を適宜改善を実施し最適化する）
- ソースの共同所有（全コードの責任を全員が担い、自由に修正を行える）
- 継続的インテグレーション（コードのビルド・テストを頻繁に行い不具合の早期発見）
- YAGNI（必要な機能だけのシンプルな実装）
管理者プラクティス
- 責任の受け入れ（開発責任の受け入れ）
- 援護（開発の補助・障害の除去）
- 四半期ごとの見直し（四半期ごとにレビュー・状況により計画を見直し）
- ミラー（全体状況を把握し現状の状態や位置を見える化する）
- 持続可能なペース（負荷が高くなり過ぎぬよう計画的に作業を調整し集中力を高める）
顧客プラクティス
- ストーリーの作成（機能のコンセプトを記したカードを作成）
- リリース計画（どのストーリーをイテレーション対象とするか全員の合意の上決定する）
- 受け入れテスト（イテレーションごとにストーリーカードの内容が実現されているか確認）
- 頻繁なリリース（動作可能なソフトウェアを2-3週間から2-3ヶ月でリリース）
開発の流れ
- 基本的な流れは要求が記されたストーリーから計画を立てイテレーション開発のため割愛
- 開発を行う上でテスト駆動開発やペア・プログラミングなど実施するのが特徴
プロトタイプモデル
概要
プロトタイプモデルは、早い段階でプロダクトの試作品を設計・開発・評価・改善と繰り返して作成し、完成した試作品を元に最終的なプロダクトの完成を目指す手法
特徴
- 動作する試作品を評価・改善しながら作成する
- 完成イメージが不明瞭でも凡そのイメージから初期開発が進められる
- プロダクト完成後のイメージが掴みやすい
メリット
- 早い段階でユーザーがチェックするため認識のずれが少ない（＝手戻りになり難い）
- レビュー・フィードバックが頻繁に入るため品質が高くなりやすい
- 試作品により問題点など早期発見につながる
デメリット
- 試作品を作るのに工数がかかる（大規模開発にはやや不向き）
- 試作品をクライアントが触ることで新規要件や要望が増え長期化するリスク
（＝ 試作品の改修・作り直しが頻繁に発生 ＝ コスト増） - 大規模案件だとステークホルダーが多く長期化する恐れも
向いている案件
- 仕様が決まり切らない新規事業・サービスの立ち上げ
- クライアントがシステム開発の発注に慣れていないケース
開発の流れ
| 工程 | 概要 |
|---|---|
| 1．要件定義（簡易） | 試作品のレビュー後にさらに要件を詰めて具体化する |
| 2．プロトタイプ開発 | |
| 設計（簡易） | 簡潔にシステムを設計する |
| 開発 | 設計に基づいて、実際の試作品を開発 |
| 確認・評価 | 試作品を確認してもらい、認識のずれを確認 |
| 要件修正 | 要件定義の修正 |
| 修正・改善 | フィードバックを元に試作品の改善を実施 |
| 3．設計 | 要件定義書と試作品から設計書を作成 |
| 4．開発 | 設計書に基づき開発を進める |
| 5．テスト | 設計書・試作品どおり作られているか確認 |
※ 2．の工程は繰り返し試作品の完成を目指す。
スパイラルモデル
概要
スパイラルモデルは、作成するシステムを複数の機能（サブシステム）に分け、それぞれの機能ごとにクライアントからレビューを受けながら開発を進めていく手法。
特徴
- サブシステムごとに要件定義、設計、開発、テスト、試作品の評価・改善の工程を繰り返す
- 機能単位のためウォーターフォールの後戻りできないデメリットを緩和したようなモデル
メリット
- スケジュールの変更が比較的容易・臨機応変に対応可
- 早い段階でユーザーがチェックするため認識のずれが少ない（＝手戻りになり難い）
- レビュー・フィードバックが頻繁に入るため品質が高くなりやすい
デメリット
- 開発機能以上に設計を行わないため全体像・整合性が把握しにくい
- 機能単位のためスケジュール管理・進捗把握が難しい面も
- 試作品をクライアントが触ることで新規要件や要望が増え長期化するリスク
（＝ 試作品の改修・作り直しが頻繁に発生 ＝ コスト増） - 大規模案件だとステークホルダーが多く長期化する恐れも
向いている案件
- ウォーターフォールのプロセスを残しているため品質重視の開発にも適用可
- 仕様が決まり切らない新規事業・サービスの立ち上げ
- クライアントがシステム開発の発注に慣れていないケース
開発の流れ
| 工程 | 概要 |
|---|---|
| 1．要件定義 | システムの目的・用途・機能をまとめる |
| 2．設計 | 開発するサブシステムを選定しその機能の設計を行う |
| 3．開発 | ウォーターフォールと同等の手法を採用 |
| サブシステムを画面ごとなど更に細かい単位に分けて開発し結合 | |
| 4．テスト | 仕様・設計書通り作られているか確認 |
| 5．評価・改善 | クライアントに共有し認識のずれについてフィードバックを受ける |
| 6．繰り返し | 次のスパイラル（2～5の繰り返し）に入る |
※ アジャイルとの違いはすべてのサブシステムの評価がおわり品質が担保されてからリリースされる。
おわりに
ひとえに開発プロセスと言っても、様々な手法があり、それぞれメリット・デメリットが存在するため、開発するシステムによって最適な手法を取り入れる必要があります。
また、発注側にも開発プロセスの流れを理解してもらえると、今が全体のどの位置にいるのか、次に何をやるのかなど、スケジュールやタスクの共通認識が取り易くなりプロジェクトが進めやすくなる場合もあります。
とは言え、実際の開発にプロセスを適用するには推進する人の知識やパワーがかなり掛かると思いますので、周りのメンバーにも協力してもらいつつ、チームとして定着するようにしていきたいですね。（場合によってはプロセスをアレンジして使うのも良いかもですね）
今回紹介したプロセス以外にも、DevOpsと呼ばれる開発と運用メンバーが継続的にビジネス価値を向上させるため、協調して開発を進めやすいようツールによって自動化を行い開発スピード・生産性をあげる手法などもありますので、開発するプロダクトに適した手法が見つかるといいですね。
どの開発プロセスを使うか検討されている方の参考になれば幸いです。