改めて考える！ソフトウェア開発の手法と違い

2021.10.18 2022.01.26 ストレージチャンネル

伝統的なソフトウェア開発手法といえば「ウォーターフォール開発モデル」。これは、滝の水が上流から下流へと流れていくように、各プロセスが1つの連なりを持ってプロジェクトを進めていくという手法です。一般的には、以下のようなプロセスが順番に進んでいきます。

要件定義
概要設計
詳細設計
テスト設計
コーディング
テスト
リリース

各工程では特定のドキュメントを作成することを成果物として、それが品質基準を満たしていれば次のプロセスへと進みます。そのため、ソフトウェアの品質担保を同時に進めながら開発が行えるというメリットがあります。一方では、開発途中での要件変更に対応できないなどのデメリットもあり、新しいソフトウェア開発手法が登場するきっかけにもなっています。

本稿では、数あるソフトウェア開発手法をウォーターフォール開発モデルと比較しつつ、その概要とメリットなどについてご紹介します。

開発スピードを高め、柔軟なプロジェクトを推進する「アジャイル開発モデル」

ウォーターフォール開発モデルの代替として、2001年頃から注目されたソフトウェア開発手法が「アジャイル開発モデル」です。アジャイル（Agile）とは「俊敏」「素早い」という意味で、文字通り従来のソフトウェア開発モデルに比べて俊敏で素早い開発を目指すことができます。

アジャイル開発モデルは要件ごとに個別開発を進めていくのが特徴であり、複数の開発はそれぞれ「イテレーション」と呼ばれる期間を設け、その中で開発プロセスを繰り返していきます。たとえば、1つのイテレーションでは以下のような開発プロセスが進められます。

要件定義
詳細設計
コーディング
テスト

アジャイル開発モデルでは「要件定義をあえて曖昧にする」というのがポイントです。その理由は、ソフトウェア開発において「要件変更は当たり前に発生するもの」という考えに基づいているからであり、故にウォーターフォール開発モデルに比べて高い柔軟性を持っています。

開発者チームの信頼性とコミュニケーションを重視する「スクラム開発」

スクラム開発は、アジャイル開発モデルの一種であり、優先順位の高い要件から短い期間での開発を繰り返すという点に特徴があります。開発期間は「イテレーション」ではなく「スプリント」と呼び、1週間～4週間程度で設けるのがポイントです。また、スクラム開発ではプロジェクトを統括するプロジェクト・マネージャーは存在しません。

その代わりに、ビジネス上の責任を持つ「プロダクトオーナー」、スクラム開発の運用をサポートする「スクラムマスター」、プロダクトオーナーの要求を実装しソフトウェアを実際に開発する「チーム」で構成されています。このスクラム開発では、以下の2ポイントを徹底するのが重要とされています。

なにを作る必要があるのか？プロダクトに対する要望を優先順位で並べ替え、「スプリント計画」でタスクを作成する
1週間～4週間で区切られた開発期間「スプリント」にて開発プロセスを繰り返す

ここで大切なのがプロジェクト全体の透明性を高めることであり、「プロダクトバックログ」と「スプリントバックログ」が必要になります。プログラムバックログとは、スプリント計画時に必要な要素をまとめたものであり、ここで優先順位や作業コストについて検討します。これが全体としての計画になります。

スプリントバックログは、開発・まとめ・レビュー・調整で構成され、スプリントごとに実現すべきことをまとめたものになります。スプリント中は日次でミーティングを行い、前日の進捗・当日の予定・現時点の課題を共有し、チームとして滞りなくソフトウェア開発が進められるようにします。

ウォーターフォール開発モデルに比べてかなりスピーディにソフトウェア開発が進められるという利点はありますが、チームコミュニケーションありきの開発手法ですので、チームメンバーが定期的に入れ替わるような開発には不向きです。

開発チームと運用チームが協力をして、素早いリリースを目指す「DevOps」

ここ10年程度で一気に知名度と注目を集めているソフトウェア開発手法がDevOps（Development and Operations）です。最初に提唱したのは「Flickr」というWebサービスの開発者であり、「開発チームと運用リームが協力した体制を整えることで、1日10回以上のリリースを可能にした」という事例を紹介しています。

ソフトウェア開発会社やWebサービス提供会社では、開発チームと運用チームが対立関係になることが多く、別々の活動によってサービスを支えています。しかし、本来は同じビジネス目標を掲げるべきチーム同士なので、両チームが協力することによって、今までにない開発スタイルを手に入れられるというわけです。

DevOpsではまず、以下4つの組織文化を重視します。

互いを尊重する

開発チームと運用チームの役割は違くとも、一緒に働いている相手を心から思いやること、1人1人の能力や功績を評価して皆が優秀な人間と認めること

互いを信頼する

「自分以外の皆はすべて優秀」と認めることで信頼が生まれ、仕事を安心して任せることができ、問題を一人で抱え込まないことにも繋がり、各人の心的負担が大きく軽減することにも寄与する

失敗を責めない

新しいことに挑戦すると最初のうちは失敗の連続だが、その失敗を責めず、チャレンジした結果の失敗なのだということを認め、評価する

一緒に考える

何か問題が起こったときはその当事者を非難するのではなく、同じ問題が起こらないためにどうすればよいのか一緒になって考え、それが建設的な組織文化を生み出しす

DevOpsは定期的な機能リリースを行うWebサービス分野でよく採用されているソフトウェア開発手法です。ただし、DevOpsを正しく行うためには適切なツールの導入が必要であり、それに苦慮するチームもあります。

信頼性がソフトウェアの重要な機能の1つとして位置づける「SRE」

SRE（Site Reliability Engineering）はGoogleが提唱するソフトウェア開発手法であり「開発のスピードアップを求める」という目的ではDevOpsと共通している部分がありますが、開発チームと運用チームが協力するのではなく「開発も行える運用チーム」という存在に焦点を当てたのがSREの特徴です。

運用専門のエンジニアの概念はソフトウェア開発会社ごとに大きく異なり、SREではサイト・サービスの信頼性を高めるために、積極的にコードを記述した、可能な限りシステムの自動化を行い、属人化させないためにドキュメントを整備したり情報京数することなどが求められます。

クラウドコンピューティングの充実によって運用専門エンジニアがハードウェア自体の安定性を特に気にする必要がなくなり、それに代わってインフラに関する技術だけではなくアプリケーション開発の技術も求められるようになりました。この背景もあり、近年SREに注目が集まっています。