どうもこんにちは！
サバ缶（@tech_begin）です。
システムを開発する際、その手法はいくつかの種類があります。
開発現場で使用する開発手法はさまざまですが、どんな開発手法でも対応できるように知っておくことは大切です。
会議や上司との会話の中で、とき折り耳にする言葉なので今のうちに理解しておきましょう！
システム開発手法の種類について
以下の４種類あります。
- ウォーターフォール
- スパイラル
- アジャイル
- プロトタイプ
また、開発工程には以下のようなものがあります。
- 要件定義
- 設計
- 製造
- テスト
以下でそれぞれ詳しく見ていきましょう。
ウォーターフォール
全ての工程を一貫してシステムを完成させる手法です。
要件定義から順にシステム開発を進めていきます。
ウォーターフォールのメリット
ウォーターフォールは、要件定義からテストにかけて順に進めていく特徴から、3つのメリットが挙げられます。
- プロジェクトの計画を立てやすい
- 計画が立てやすいため、人員の確保がしやすく予算も立てやすい
- 進捗管理もしやすく、どのタスクが遅れているのかが把握しやすい
ウォーターフォールのデメリット
ウォーターフォールの特徴がゆえのデメリットもあります。
- 前工程に不備があり、手戻りが発生するとコストと時間がかかる
- 要件定義後の仕様変更が難しいため、ユーザの意見を取り入れることが難しい
ウォーターフォールが採用される場面
メリットデメリットそれぞれを踏まえて、以下のような場面で採用されることが多いです。
- 要求内容が明確であり、途中で仕様変更が起きない
- プロジェクト参加者もシステム内容を熟知している
スパイラル
スパイラルという開発手法は、要求ごとに要件定義から実装・テストを繰り返していきます。
少しずつ開発していくので、変更・追加に対応しやすいことが特徴です。
ウォーターフォールと同様の工程を１サイクルとして、これを繰り返し開発を進めていきます。
スパイラルのメリット
スパイラルでは、全体の設計を行わず実装していく機能ごとに計画を立てます。
そのため、ウォーターフォールに比べて柔軟性がある開発手法となります。
- スケジュールや仕様変更に対応しやすい
- 開発途中の仕様変更の手戻りも最小限に抑えられる
スパイラルのデメリット
プロジェクト全体の計画がないがゆえのデメリットもあります。
- 全体計画がないため、プロジェクト（開発）期間が長引く恐れがある
- 短い期間で繰り返し開発を行うため、顧客からの依頼が度々あると最終的な開発コストが膨れ上がる
スパイラルが採用される場面
後述するアジャイルとの違いは、品質重視という点です。
- 要求内容の変更が頻繁に行われる可能性が高い場合
- プロジェクト参加者も開発するシステム全体の内容を熟知していない
- 品質を重視しつつ、改良を繰り返していきたい場合
アジャイル
アジャイルは「総称」のことです。
アジャイルは、迅速かつ細かい変更に適応するように開発を行う手法です。
アジャイル開発の中には、いくつか種類があります。
- エクストリーム・プログラミング（XP）
- ピープルウェアを重視
- コミュニケーションを重視
- 開発者（のモチベーション）を重視
- 顧客との協調を重視
- その他
- ペアプログラミング
- オンサイトユーザ
- テストファースト
何を重視するのかなどによって、細かく分けられます。
大枠の考え方はアジャイルに依存するので、総合的な観点でまとめます。
アジャイルの特徴
アジャイル開発の中でも有名なのが「スクラム」と呼ばれるものです。
「イテレーション」と呼ばれるサイクルで、設計→開発→テストを行います。
このイテレーションの周期は、日次・週次・月次など様々です。
イテレーションごとに進捗状況や動作確認を行うため、チーム内のコミュニケーションを密に取る必要があります。
アジャイルのメリット
イテレーションごとにリリースを行うため、仕様変更が起きても柔軟に対応できます。
- 細かいサイクルで開発を行うことで、開発スピードが早くなる
- リリースタイミングが多いので、不具合や仕様変更の対応を行いやすい
- メンバーだけでなく顧客とのコミュニケーションも増えるため、ニーズに応えやすい
アジャイルのデメリット
先述のスパイラルに似たように思われるかもしれませんが、アジャイルは仕様や要件1つ1つに計画を立てます。
- 最終的な納期はあるが、イテレーションごとに仕様変更などを行なっていると、全体のスケジュール管理が困難になってくる
- 技術力に乏しいメンバーがいると、その場しのぎの開発になってしまい、品質の低下を招く恐れもある
アジャイルが採用される場面
スパイラルと似ていますが、実は異なるものです。
違いはアジャイルの方が「プロジェクトの計画重視」という点です。
- 要求内容の変更が頻繁に行われる可能性が高い場合
- プロジェクト参加者も開発するシステム全体の内容を熟知していない
- プロジェクトの計画を重視しつつ、改良を繰り返していきたい場合
プロトタイピング
ユーザの期待と反するというリスクを未然に防ぐため、試作品（プロトタイプ）を作成する手法です。
実施にユーザーが使用する場面を考えて、パフォーマンスなども考慮します。
- 使い捨て型
- プロトタイプの検証後、破棄し、新たにシステムを開発していく。
- 発展型
- プロトタイプの検証後、拡張して開発を進めていく。
プロトタイピングのメリット
試作品（プロトタイプ）を作ることで、完成形のイメージがしやすくなります。
- 事前に見せることで、顧客がイメージしやすくなり要求が明確になる
- 開発途中の想定外な課題を事前に見つけることができる
課題が明確になると、予期せぬ問題にかける工数（開発するコスト）が減らせるので、コスト削減にも役立ちます。コストが減るのは顧客としては嬉しいですよね。
プロトタイピングのデメリット
試作品なので、完成形に近づけようとすればするほど時間がかかります。
- 大規模なシステムには向かない
- 要件が細かくなる反面、無理な要求も増える恐れがある
- 中途半端なものを作っても検証できないので、必然的に完成形に近いものを作る必要がある
顧客側のメリットが多い反面、開発者側の負担が大きくなりがちな印象です。
プロトタイピングが採用される場面
- 顧客のイメージと実際のシステムのギャップを埋めたい場合
- まずは手をつけて動作を見たい場合
まとめ
わたし自身、全ての開発手法の案件に携わったわけではないので実情を多く語ることはできません。
しかし、このような開発のなかで失敗談なども先輩から多く耳にしました。
これからIT業界の現場で働きたいと思っている方、初めての開発手法の現場で不安な方のご参考に慣れれば幸いです。
適切な知識を持った顧客と開発者。
お互いの認識を合わせた上で、どのように開発を進めていくか決定し、プロジェクト成功へ導くかが重要ですね。
当記事について何か不備などございましたら、わたしのTwitterにてお気軽にご連絡いただけると幸いです。
