ソフトウェア開発プロセス

内容

• 開発プロセス
• ソフトウェア開発モデル
• アジャイル開発

開発プロセス

開発プロセスとは

• ソフトウェアを計画的・体系的に開発するための手順や流れ
• 要件定義から設計、実装、テスト、運用・保守までの一連の工程
• 各工程で「何を」「どのように」進めるかを明確にすることで、品質や納期、コストを管理しやすくする
• 開発プロセスを定めることで、チーム全体で共通認識を持ち、効率的な開発が可能になる

開発プロセスの必要性

• 無計画な開発
  • 要求が曖昧なまま実装を始めると、後から仕様変更が頻発し、混乱や手戻りが発生
  • 結果として「動くけど使いにくい」システムになる可能性も
• スケジュールの遅延
  • 各工程の見積もりが不十分だと、後工程にしわ寄せが発生
  • 「テストする時間が足りない」「無理な残業でリリース」などの問題につながる
• 低品質なソフトウェア
  • バグや設計ミスが多いと、運用開始後に障害対応が頻発
  • 保守コストが膨らみ、新機能追加にも影響
  • 例：リリース後に「本番環境でしか起きない不具合」が多発し、信頼を損なう

• ソフトウェアは目に見えない資産であり、試作とやり直しのコストが高い
• 「何を作るか」「どう作るか」「いつまでに」「どのような品質で」を明確にする必要がある
• 再現性と改善性のある開発を可能にするために、標準化されたプロセスが求められる
• 開発チームの経験や規模にかかわらず、共通の枠組みを持つことで、属人化の防止や品質の均一化が図れる

ソフトウェアのライフサイクル

1. 要求定義（何を作るか決める）
2. 設計（システム構造を決める）
3. 構築（コードを書く）
4. テスト（バグを検出し修正）
5. 運用・保守（システムを継続的に改善）

要求定義

目的

• ユーザの要求を満足するような仕様（specification）を決める．
• ユーザの要求を明確にし，システムが何をするかを定義する．
• ユーザの要求を文書化し，開発チーム全体で共有する．
• 要求定義を行うことで、開発の方向性を明確にし、後工程での手戻りを減らす．

要求定義のイメージ

設計（Design）

目的

• 要求定義に基づいて、システムの構造や動作を具体的に設計する．
• ソフトウェアアーキテクチャ（architecture）や実装方法（implementation）を決める．
• システムの各コンポーネントの役割やインタフェースを定義する．
• 設計を行うことで、実装の効率化や保守性の向上を図る．

設計のイメージ

構築（Construction）

目的

• 設計に沿ってコーディングを行う．
• ソフトウェアの実装を行い、動作するプログラムを作成する．
• コーディング規約に従い、可読性や保守性の高いコードを書く．
• コードレビューを行い、品質を確保する．

構築のイメージ

テスト（Testing）

目的

• プログラム／システムが要求通り動作するかどうか確認する
• バグや不具合を検出し、修正する．
• テストを通じて、システムの品質を確保する．
• テスト工程は、単体テスト、結合テスト、システムテスト、受入テストなどに分かれる．

テスト工程

• 単体テスト（Unit Test）：単一モジュールの動作を確認する
• 結合テスト（Integration Test）：複数のモジュールを結合して，モジュール間のインタフェースなどが要求通り動作するかどうか確認する
• システムテスト（system Test）：実際の運用をシミュレートした環境で動作を確認する
• 受入テスト（Acceptance Test）：システムを受け入れるかどうか決定するためのテスト

テストのイメージ

テストのイメージ

運用・保守

目的

• システムを実際に運用し、ユーザに提供する．
• 運用中の問題を監視し、必要に応じて修正や改善を行う．
• ユーザからのフィードバックを受けて、システムを継続的に改善する．
• 運用・保守を行うことで、システムの信頼性や安定性を確保する．

保守のイメージ

まとめ

• ソフトウェア開発は、要求定義から運用・保守までの一連のプロセスを経て行われる
• 各工程での計画的な進行が、品質や納期、コストの管理に寄与する
• 開発プロセスを定めることで、チーム全体での共通認識が得られ、効率的な開発が可能になる

ソフトウェア開発モデル

ソフトウェア開発モデルとは

• 開発プロセスをどのように実行するかを定めた進め方のスタイル
• 各工程の順序や繰り返し、重点の置き方を体系的に示したもの
• 開発モデルを選ぶことで、プロジェクトの特性（例：変更の多さ、納期の厳しさ、規模の大きさ）に応じた最適な手法が適用できる
• 代表的なモデル：
  • ウォーターフォールモデル
  • アジャイル開発モデル（Scrum, XP など）
  • スパイラルモデル
  • V字モデル
  • etc.

開発プロセスと開発モデルの違い

ソフトウェア開発モデルの必要性

• ソフトウェア開発は複雑であり、計画的かつ体系的な進行が求められる
• 開発モデルを導入することで、以下のメリットが得られる：
  • 効率的な進行：各工程の目的や手順が明確になり、無駄な作業や手戻りを減らせる
  • 品質の向上：テストやレビューの実施タイミングが明確になり、バグや設計ミスを早期に発見できる
  • リスク管理：仕様変更やトラブルが発生した際の対応方法（例：イテレーションの再実行）が事前に定義されている
• プロジェクトの特性（規模、変更頻度、納期の厳しさなど）に応じた最適な開発モデルを選ぶことで、プロジェクトの成功率を高められる

ソフトウェアの種類と開発モデルの対応

ウォーターフォールモデル（Waterfall Model）

• 1970 年代に誕生
• 特徴
  • 各工程を順に進める「段階的開発」
  • 工程間のフィードバックは基本的に少なく、前工程に戻りにくい
• 工程
  • 要求分析：ユーザ要求からシステムの仕様を決める
  • 設計：仕様を実現する構造や実装方法を決める
  • 構築：プログラムを作成する
  • テスト：設計や仕様通りに動作するかを確認する
  • 運用・保守：バグ修正や機能追加などを行い、システムを維持・改善する

• ドキュメント駆動プロセス（Document-Driven Process）
  • 各工程の成果物（設計書・仕様書など）をドキュメントとして残し、次の工程へ引き継ぐ
  • ドキュメントのレビューを通じて品質を保証する

• V モデル（ウォータフォールモデルの変化版）
  • 各開発工程に対応するテスト工程が明示されており、要求仕様に対する受入テスト、設計に対する統合テストなどの関係が図で表される

• 長所
  • 各工程で，マイルストーン（達成目標）と成果物（この場合は成果物＝ドキュメント）があるのでスケジュール管理が行いやすい
  • 分業が容易
• 短所
  • リスク管理が難しい
  • ソフトウェア開発には必ず「戻り工程」が存在する
  • ユーザの本当の要求が完成まで見えにくく、リリース後の修正コストが高くなりやすい
• 対象例
  • 大規模で高い信頼性が要求されるシステム

プロトタイピングモデル（Prototyping Model）

• ウォーターフォールにおける「手戻り」リスクを低減
• 最終的に運用するソフトウェアシステムを作る前に，実験的なシステム（プロトタイプ）を素早く作り、ユーザと仕様のすり合わせを行う
• 特に「要求分析」段階（フェーズ）で行うことが多い
• どの程度の「プロトタイプ」を作成するかが難しい（短所）

インクリメンタルモデル（Incremental Model）

• 小さな機能範囲のシステムから作成
• 改良（バージョンアップ）によるシステム構築
• 典型的には「確実に必要な機能」から作成していく
  • プロトタイピング：不確実な要求を明確化する
  • インクリメンタル：確実な機能から順に開発し、段階的に完成に近づける
• 設計全体を初期段階で明確にしないと、後の段階で統合が困難になり、コードが複雑化する（短所）のでリファクタリング（再構築）が必要になる場合がある

モデルの比較（まとめ）

アジャイル開発

アジャイル開発とは

• アジャイル（agile）：すばやい，俊敏な
• 短い開発期間（イテレーション）を単位として反復的に開発を行う
• 顧客要求の変化や不確実性に柔軟に対応し、リスクを最小化することが目的

特徴

• 顧客とエンジニアで1つのチームを構成し、常に要求をすり合わせながら開発を進める
• 優先度の高い要求から順に実装を進める
• 開発期間単位毎に実装・テスト・リリースを行う→実際に動くソフトウェアを通じて顧客と確認し、次の開発に反映する

ウォーターフォールとの比較

The Myth of Incremental Development by Herding Cats

アジャイル開発に向いているケース

• 小規模ソフトウェア・機能が分離できるもの（プラグインなど）
  • 1チームで巨大なものを作成するのが難しい
• 品質よりもマーケットシェアが重要なソフトウェア（オンラインアップデートできるものなど）
  • 信頼性の作り込みが難しい

Webサービス，スマホアプリ

※現時点では組み込みなどにはあまり向いていない（と言われている）

Scrum

• アジャイル開発手法の代表例の一つ
• 作業，会議，成果物を定めたもの

特徴

• 要求の高いものから実現する（プロダクトバックログ）

• 短い期間で目標・実施・検査・改善を行う（スプリント）

• 動作するもので要求の確認を行う（スプリントレビュー）

• プロダクト：ユーザ要求を満たす「完成物」

• プロセス：チームの作業を円滑に進めるための進行方法

役割

• プロダクトオーナー：プロダクトの責任者．プロダクトバックログの管理．
• 開発チーム：開発をする人．上下関係はなし．
• スクラムマスター：教育・ファシリテータ

成果物

• プロダクトバックログ：プロダクトへの要求一覧．開発中も変化する．
• スプリントバックログ：スプリントで行うタスクリスト．
• リリース判定可能なプロダクト：「動く」ソフトウェアプロダクト．

会議

Scrumのメリット

• 変化に強い：顧客の要求変更に柔軟に対応できる
• コミュニケーションの活性化：デイリースクラムやレビューでチーム内の情報共有が進む
• 早期リリースとフィードバック：スプリントごとに動作する成果物を提供
• 継続的な改善：スプリントごとに振り返り、プロセスを改善
• 自己組織化チーム：チームが自律的に判断し、主体的に開発を進められる
• 進捗の見える化：成果物とバックログにより、状況が把握しやすい

Scrumのデメリット

• 導入ハードル：既存の開発プロセスからの移行には意識改革が必要
• 運用コスト：定期的なミーティングに時間とリソースが必要
• 習熟が必要：フレームワークの理解不足では効果が出にくい
• 全員の積極的な参加が前提：関与が弱いとスクラムの利点が活かせない
• プロジェクトの適性が必要：組み込み系や長期的な仕様固定型には不向きな場合もある
• チームの特性に依存：文化・価値観・スキルが合わないと機能しにくい

全体のまとめ

• ソフトウェア開発プロセスは、計画的・体系的な開発を実現するための手順
• 開発モデルは、プロセスをどのように進めるかを定めたスタイル
• ウォーターフォールモデル、プロトタイピングモデル、インクリメンタルモデルなどが代表的な開発モデル
• アジャイル開発は、変化に柔軟に対応し、顧客とのコミュニケーションを重視する開発手法
• スクラムはアジャイル開発の一つで、短い開発期間で反復的に開発を進める手法
• 開発モデルの選択は、プロジェクトの特性に応じて最適なものを選ぶことが重要