ソフトウェア開発プロセスは、成功するプロジェクトの基盤となる重要な要素です。
効率的で体系的な開発プロセスは、プロジェクトの品質向上、リスクの軽減、コストの削減、そしてスケジュールの遵守に大きく貢献します。
代表的な3つの開発プロセスの概要とその特徴について紹介します。
- ウォーターフォール型開発
- プロトタイプ型開発
- アジャイル型開発
ウォーターフォール型開発は、開発プロセスを一連の段階に分けて順次進める方法です。
名前の由来は、各工程が滝のように次の工程へと流れていくことからです。大規模で安定した要件が確定しているプロジェクトに適しています。
デメリットとして、柔軟性が低く、変更に対応しにくい特徴があります。
主な工程を以下に示します。
-
要件定義：
何を開発するかを明確にする。ユーザーのニーズやシステムの要件を収集し、ドキュメント化する。 -
システム設計：
要件定義に基づいてシステムの全体を設計する。アーキテクチャ設計やデータベース設計、インタフェース設計などを行う。 -
詳細設計：
システム設計を基に、各コンポーネントやモジュールの詳細を設計する。プログラムの構造やフローを詳細に設計する。 -
実装：
詳細設計に基づいてコーディングを行う。各モジュールを実際にプログラムとして実装する。 -
テスト：
実装したプログラムをテストし、要件通りに動作することを確認する。ユニットテスト、システムテスト、受け入れテストなどが含まれる。 -
導入：
テストが完了したシステムを本番環境に導入する。ユーザーにシステムを提供し、運用を開始する。 -
運用と保守：
システムを運用し、必要に応じて保守する。問題やバグが発生した場合は修正し、システムの改善を図る。
プロトタイプ型開発は、製品やシステムの初期モデル（プロトタイプ）を迅速に作成し、ユーザーやステークホルダーからのフィードバックを基に改善を反復する開発手法です。
原則としてプロトタイプ作成サイクルと製品版作成サイクルの2つで構成されています。
後述のアジャイル型開発では、繰り返すサイクルの中で仕様や機能が決定していくのに対し、プロトタイプ型開発はプロトタイプ作成の段階で、仕様や要件がある程度決まっている必要があります。
アジャイル型開発ほどフィードバックを反映する自由度はないため、時間とコストの管理が重要であり、過度なスコープ拡大を防ぐための適切なマネジメントが求められます。
主な工程を以下に示します。
-
要件収集：
ユーザーやステークホルダーのニーズや要求を収集し、初期の要件を定義する。この段階では、詳細な仕様よりも全体的なニーズや問題点に焦点を当てる。 -
プロトタイプの設計：
要件に基づいて、初期プロトタイプの設計をする。デザインスケッチやワイヤーフレームなどを使って、システムの大まかな構造を示す。 -
プロトタイプの開発：
初期の簡単なモデルを作成する。この段階では、実装が難しい部分は省略してもよいので、ユーザーインタフェースや基本的な機能を重視する。 -
ユーザーテストとフィードバック収集：
ユーザーにプロトタイプを実際に使用してもらい、フィードバックを収集する。フィードバックを基に、プロトタイプの改善点を洗い出す。 -
改善と改良：
フィードバックに基づいてプロトタイプを改良する。フィードバックを基にプロトタイプを最終製品に近づける。 -
製品の完成：
ユーザーの要求を満たす最終プロトタイプが完成後、最終プロトタイプを基に正式な製品やシステムの開発に移行します。
アジャイル開発は、柔軟性、迅速な対応、ユーザーのニーズへの応答を重視した開発手法です。
特徴として、プロジェクト全体をスプリントと呼ばれる複数の小さな開発サイクルに分割し、各スプリントで部分的な製品を開発していきます。
先述のウォーターフォール型・プロトタイプ型とは対照的に、継続的な開発・リリースによるアプローチが特徴です。
柔軟に機能を追加したりユーザーやステークホルダーからのフィードバックを迅速に反映したりできる反面、マネジメントが複雑になりコストの算出が難しくなったり、最初から厳密に方針を定めないことも多いので開発途中で構想のブレなども生じやすいです。
詳細な工程については、後述のスクラム開発で説明します。
Tips. 4つの基本価値と12の原則
アジャイル開発は、2001年に発表された「アジャイルソフトウェア開発宣言」に掲げられている以下の4つの基本価値と12の原則に基づいています。
- 基本価値
- 個人と対話をプロセスとツールよりも重視する。
- 動くソフトウェアを包括的なドキュメントよりも重視する。
- 顧客との協調を契約交渉よりも重視する。
- 変化への対応を計画に従うことよりも重視する。
- 12の原則
- 顧客満足を最優先し、価値のあるソフトウェアを早期かつ継続的に提供する。
- 要求の変更を歓迎し、たとえ開発の後半であっても対応する。
- 短い時間間隔で動くソフトウェアを頻繁に提供する。
- 開発者とビジネス側の人々が日々協力する。
- プロジェクトを動機づけられた個人で構成し、必要な支援と信頼を提供する。
- 対面でのコミュニケーションが最も効率的かつ効果的である。
- 動くソフトウェアが進捗の最も重要な指標である。
- 持続可能な開発ペースを維持する。
- 技術的卓越性と良い設計に対する継続的な関心が敏捷性を高める。
- シンプルさ（やらないことの最大化）が重要である。
- 自己組織化チームが最良のアーキテクチャ、要求、設計を生み出す。
- 定期的にチームがどのように効率を高めるかを振り返り、行動を調整する。
スクラム開発は、アジャイル型開発の1つで、チームが効率的に作業を進め、継続的に価値を提供するためのフレームワークです。
スクラムは、自己組織化された技術横断的なチームが短期間のスプリントと呼ばれる開発サイクルを通じて、機能を段階的に開発していくフレームワークです。
スクラム開発では、円滑に開発を進めるためにそれぞれが重要な役割を担当します。
以下に、各役割について説明します。
-
- プロダクトのビジョンと目標を保持し、プロダクトバックログを管理する
- 顧客やステークホルダーのフィードバックを反映し、バックログアイテムの優先順位を設定する
-
- チームがスクラムのルールを理解し、適用するのを支援する
- チームの障害を取り除き、スプリントの円滑な進行をサポートする
-
- プロダクトを作成する
- 設計、開発、テストなどの全工程を担当する
スクラム開発を進行するために、知っておくべき概念や用語を説明します。
以下に、各用語について説明します。
-
- プロダクトの開発指針となるもの、プロダクトがどんなものなのかを示す
- ターゲット、ニーズ、強み、ユーザーが使う理由、主要な競合、差別化ポイントなど
- スクラムチーム全員が唱えられるくらいを目標に
- プロダクトの開発指針となるもの、プロダクトがどんなものなのかを示す
-
- プロダクトに必要な全ての機能や要件をリスト化したもの
- プロダクトオーナーが管理し、優先順位をつける
-
- 1〜4週間の固定期間で、プロダクトの成果物を作成するための開発サイクル
- 計画、実装、レビュー、振り返りで構成される(後述)
-
- そのスプリントで実装する予定のプロダクトバックログ項目と、その実現のための具体的なタスクのリスト
- 開発チームが作成し管理する
スクラム開発を進める上で、重要な会議が4つあります。
以下に、各会議について説明します。
-
- スプリントの開始時に行うミーティング
- 開発チームがスプリントで何を達成するかを決定しスプリントバックログを作成する
-
- 毎日行う15分のミーティング
- 開発チームが進捗を確認し、障害を共有し、次の24時間の作業を計画する
-
- スプリントの終了時に行うミーティング
- チームが成果物をデモンストレーションし、ステークホルダーからフィードバックを受け取る
-
- スプリントの終了後に行う振り返りミーティング
- チームがプロセスを評価し、改善点を見つけるために行う
ここまでの話をまとめると1スプリントあたりの流れは以下の図のようになります
このようなスプリントを繰り返し、段階的に開発を進めていきます
演習として、実際の流れを体験してみましょう。 実際のスクラム開発を想定して、以下のように進めます。
- アイデア出し
- ビジョンの決定
- 担当の割り振り
- プロダクトバックログの登録
- スプリント計画
- 作業(4日)
- スプリントレビュー
- スプリント振り返り
- 次スプリント計画
- 5.に戻ってくり返す
- 全体振り返り
今回は「しりとりアプリ」をチームで開発する想定で、スクラム開発を体験してもらいます。
実際にコードを書いて開発する時間はないので、代わりにサイコロを振って、出目に応じて開発が進んでいくことにします。
- 1スプリントを4日とします
- スプリントは第3スプリントまでとします
- 上記の5〜10の手順を3回やります
- 1日ずつサイコロを1回振り、出目の数を進捗とします
- サイコロがない場合は、Googleで"1d6"と検索
- それぞれのタスクごとに工数を設定するので、進捗の数が工数を満たしたら作業を完了とします。
- 工数12のタスクは、サイコロの出目の合計が12を超えたら完了になる
今回は、仮に「しりとりアプリ」をテーマにします。
ビジョンは「小学生をターゲットとした地図を使って地名でしりとりをするアプリ」とします。
話し合ってPO(プロダクトオーナー)と開発チームを決めてください。
スクラムマスターはメンターが担当します。
グループの人数が少ないため、POやスクラムマスターも開発チームのメンバーとして開発作業(サイコロ)を兼任することにします。
- プロダクトオーナー(1人)
- スクラムマスター(メンター)
- 開発チーム(各1人以上)
- サーバ
- クライアント
- デザイン
アプリのビジョンからどのような機能を実装するか洗い出し、プロダクトバックログに登録します。
アプリ名、ビジョン(今回は全チーム共通)、機能一覧をまとめます。
実装する機能は以下の5つとします。
- 環境構築(1人、工数18)
- ログインの実装
- DB設計(工数18)
- API実装(工数18)
- デザイン(工数12)
- フロント実装(工数12)
- 通知の実装
- DB設計(工数18)
- API実装(工数18)
- フロント実装(工数12)
- ホーム画面の実装
- DB設計(工数12)
- API実装(工数12)
- デザイン(工数18)
- フロント実装(工数18)
- 地図画面の実装
- DB設計(工数12)
- API実装(工数12)
- デザイン(工数12)
- フロント実装(工数24)
ここからはスプリントの作業となります。
スプリント計画では、スプリントバックログの作成とタスクの割り振りの2つを行います。
スプリントバックログには、プロダクトバックログからこのスプリントで着手するタスクを洗い出して登録します。
プロダクトバックログのタスクからこのスプリントで各人が担当するタスクを決めます。
スプリントバックログとしてまとめておきましょう。
工数の見積もりですが、今回は1スプリントを4日としています。
開発メンバー1人ずつ1日1回サイコロを振れるので、1スプリントあたりの進捗はサイコロの出目(4〜24)×開発メンバー数となります。
各々の技術力(運の良さ)から担当できるタスクの内容や量を見積もってください。
実際に作業に取り掛かります。
まずはデイリースクラム(朝会)です。朝の挨拶をして、自分がその日担当するタスクをチーム内で共有してください
その後、1人ずつサイコロを振って出目を手元に記録してください
（記入例: API実装: Bさん (4,4,3,6) 合計17）
担当しているタスクの工数に対して、進捗を割り振っていきます！
工数分の進捗が出たタスクは完了としてください。
もし進捗が余った場合、着手されていないタスクの担当を自分に割り振って、進捗させてください。
スプリントレビューで成果物のレビューを行います。 以下の指摘例を参考に2つ指摘を挙げて、指摘事項をプロダクトバックログに登録してください。
指摘例
- 通知の処理が遅い
- ホーム画面の表示が崩れている
- 地図の表示が遅い
- ボタンの色が変
- レスポンシブじゃない
(開けずに待っててください)
おっと、ここで仕様が変わったようです！POはサイコロを振ってください。
出た目が1か2の場合、このスプリントで進捗した任意のタスクから進捗を減らします。 1なら10個、2なら5個だけ減らしてください。
KPTで振り返りをします。まず良かったこと(Keep)、改善すべきところ(Problem)を記入します。その後どう改善するか(Try)を検討し、記入します。
実際の開発では、Tryに書かれたものを次スプリントで改善できるようにしましょう。
この演習では以下のような振り返りが出ました。
スクラムマスターがサイコロを振り、偶数の目が出たらTryがうまく作用したことにします。成功した場合、次のスプリントで１人だけサイコロを2つ振れるようになります！
振り返りが終了したら、次のスプリントが始まります！ スプリント計画から、始めましょう。
この流れを第3スプリントまで行い、全てのスプリントが完了したら全体振り返りを行います。
KPT例
- よかったこと(Keep)
- Aさんが環境構築やってくれた
- BさんAPI実装感謝
- 改善点(Problem)
- Cさんの出目が悪い
- 改善方法(Try)
- Cさんのサイコロを増やす
全てのスプリントが完了して、今回の開発全体をKPTで振り返ります。 今回の演習では、具体的に書けることが少ないと思うので、代わりに分かったこと・分からなかったことを振り返ります。
書いた項目には誰が書き込んだかわかるように名前を書きましょう。
反省はインターンの実開発で活かしてみましょう。
振り返り例
- わかったこと
- だいたいの流れがわかった(Aさん)
- わからなかったこと
- スクラムマスターって実際には何をするんだろう(Cさん)
実際の開発では、もっとたくさんハプニングが起きるはずです。
頑張りましょう！