コラム

ウォーターフォールやアジャイルといったシステム開発手法に注目が集まっています。開発プロジェクトに最適な手法を具体的に把握する必要があるからです。たとえばウォーターフォールでは、当初から仕様を明確にしやすいシステム開発に向いていますが、ビジネスの変化のスピードに追従するのが難しいといった声も聞きます。

そこで、今回はシステム開発手法の種類にふれたうえで、ウォーターフォール開発とアジャイル開発の特徴や違い・使い分、代表的なアジャイル開発のスタイルであるスクラム開発などについて詳しくみていきます。

システム開発手法の種類

システム開発手法とは、ITシステムを開発する手順や役割などをモデル化したものです。代表的な手法は、次のようになります。

手法	特徴
ウォーターフォール	要件定義から基本設計・詳細設計、テストなどを発注側や開発担当者が各工程で確認し完了させていく手法。ひとつずつ確認するため、手戻りのコストが大きい。
アジャイル	自律的なチームが、スピーディーな開発を繰り返してフィードバックを得る手法。顧客や市場の変化に追従するために、品質を維持しながら仕様変更しやすく作っていく。
プロトタイプ	開発の初期段階で機能や動作を検証する試作品(プロトタイプ)を作る手法。機能や性能などを実用レベルまで修正したあと本開発をおこなう。
DevOps (デブオプス)	開発チームと運用チームを一体としてシステムを継続的に開発・運用していく手法。一体のチームであるため、開発・評価などのサイクルが早く、リリースの頻度も高くなる。

ウォーターフォール開発もアジャイル開発も発注側が求めるシステムの要件に合わせて、使い分けていかなければならない開発手法だといえるでしょう。

ウォーターフォール開発とは

ここからは、従来の主流の開発手法であるウォーターフォール開発についてみていきます。ウォーターフォール開発は、要件定義・基本設計・詳細設計・実装・単体テスト・結合テストというように、滝のように上流工程から下流工程に進んでいく開発手法です。後戻りにコストがかかることから、その名が付けられました。

ウォーターフォール開発の特徴

ウォーターフォール開発の特徴は次のようになります。

• 作るシステムや計画を最初から明確にする
• 工程ごとに評価して完了させて、その成果物を次の工程で利用する
• 品質レベルを統一しやすい
• 開発期間は長い

—

計画も含めて、全ての開発工程は発注側も含めて評価していくため品質は高いものの、実用的なシステム完成までに長い時間を要します。また、システムは構築するまで使用できません。

計画する段階で全ての仕様が決まっているため、仕様変更が難しい点も知っておきましょう。

開発の流れ

開発の流れは、次のように上流から下流に移行していきます。これは、高層ビルやダムなどの巨大建築物の工事を思い浮かべると分かりやすいでしょう。

最初の計画通りに開発を進めるので、必要な予算や期間が大きく変化しなければ、プロジェクト管理しやすいといえるでしょう。

メリットとデメリット

ウォーターフォール開発には次のメリットがあります。

• 人的・時間的コストがあらかじめ把握しやすい
• 進捗状況が分かりやすい
• 品質レベルを統一しやすい

—

工程ごとに必要な人員・時間をある程度把握できるので、管理しやすい点は魅力です。また、進捗状況に対して引継ぎも行いやすく、初期工程で設計を完了させることから、品質レベルも統一しやすいといえます。

これ対して、デメリットは次の4つです。

• あらかじめ仕様を明確にする必要がある
• 改善も含めた仕様変更がやりにくい
• 仕様変更があると、開発期間の遅延・開発費用の増大などが起こりやすい
• システムが使えるようになるまで時間がかかる

—

とくに、工程ごとに完了させなければ次の段階に進めず、仮に手戻りが発生した場合の大きなコストがかかる点は知っておくとよいでしょう。この場合、前の工程も合わせて見直す必要があるため、綿密な設計・企画、機能・要件の確認が大切になります。各工程の遅れが次工程の進捗に影響を与えやすいため、計画時にバッファを大きくとり、全体のスケジュールが長くなる傾向にあります。

システムの仕様をあらかじめ明確にしやすい既存業務のシステム化などに向いていると言われています。

従来のウォーターフォールの限界

ウォーターフォール開発の原型が提唱されたのは、1960年代の国際会議でした。つまり、基本的な考え方は数十年前から変わっていません。そのため、従来のウォーターフォール開発に関しては次のような限界がみえています。

• 仕様変更に大きなコストがかかる
• 下流になるほど手戻りとなった場合のコストが増大する
• 途中で結合テストがやりにくい
• そもそも、最初に仕様を明確化するのが大変

—

社内に大規模なシステムを構築する場合には役立つ面もあるものの、柔軟にシステムの要件を変えるプロジェクトには適さない開発手法だといえるでしょう。

アジャイル開発とは

ここからは、アジャイル開発の特徴や流れについて詳しくみていきます。アジャイル開発は、自律的なチームにより、スピーディーな開発を繰り返していく開発手法です。

アジャイル開発の特徴

スピーディーな開発を繰り返して、顧客や市場がもとめるシステムを突き詰めていきます。

アジャイルには、次のようにいくつかのスタイルがあります。また、これらのスタイルを開発チームが自律的に取り入れていきます。

スタイル	特徴
スクラム	チームワークを重視する。ユーザーへの価値を示すプロダクトバックログと作業計画のスプリントバックログを定義する。メンバーごとに短い期間での開発サイクルを回し、改善していくなどの動きが必要となる。
エクストリーム・プログラミング(XP)	現場中心の柔軟な対応を重視する。コミュニケーション、フィードバックといった点に価値を置き、柔軟な対応・仕様変更、情報共有を行う。コーディング規約やチェック体制を整えるペアプログラミングなどの原則がある。
ユーザー機能駆動開発(FDD)	ユーザー目線の機能の付加を重視する。そのため、ユーザーのニーズを聞き出すコミュニケーション能力とビジネスモデルを把握する理解力が大切。また、機能性が高まりやすい点も特徴。

ここでは、アジャイル開発のひとつであるスクラム開発を例にして、開発の役割と流れを説明します。

スクラム開発の役割分担

スクラム開発では、スクラムチームと呼ぶ小さなチームを作ります。このスクラムチームには次の役割を持ったメンバーがいます。

• プロダクトオーナー：発注側の人間が担当して、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。実際の開発作業はおこなわず、状況変化にあわせてプロダクトバックログを更新していく。
• 開発チーム：実際に開発をおこなうメンバーで構成される。メンバー１人ひとりが専門性を持ちながら、自分の役割だけにこだわらず、１つのゴールを目指して全員で協力する。
• スクラムマスター：スクラムの促進と支援に責任を持つ。プロダクトオーナーや開発チーム・ステークホルダーを支援する。

—

ウォーターフォール開発のプロジェクトマネジメントでは、プロジェクトマネージャーが大きな権限を持っていますが、スクラム開発ではプロジェクトマネージャーを配置せず、開発チーム全体で自律的に調整していきます。スクラムマスターは「マスター」(師匠)であり、「マネージャー」(管理者)というよりメンター・コーチのような存在です。

スクラム開発の流れ

スクラム開発では、「スプリント」と呼ぶ、短い開発サイクルを繰り返していきます。スプリントには、1か月以内の短い期間を設定します。そして各スプリントの終わりに、その成果となるプロダクトをプロダクトオーナーに提示して評価してもらいます。

スプリントの大まかな流れは次のとおりです。

• バックログの作成と更新：必要な機能や技術的な要件を洗い出し、優先順位付けする。プロダクトオーナーが作成・更新していき、それを全員が参照して、現在の開発状況を把握できるようにする。
• スプリントプランニング：プロダクトバックログから次のスプリントで何を作るか、開発チーム全体で調整・決定する。
• スプリント：短い一定期間の開発作業。この期間に、設計・実装・テストをおこない、バックログの一部を消化する。
• スプリントレビュー：スプリントの終わりに、その成果となるプロダクトをプロダクトオーナーに提示して評価してもらう。
• スプリントレトロスペクティブ(振り返り)：開発チームの現状の把握と、今後の改善策を検討する。

アジャイル開発のメリット

アジャイル開発のメリットは次の３つです。

• 短い開発サイクルのなかで、繰り返し成果物をリリースできる
• リリースを繰り返すなかで、少しずつ機能や品質を向上できる
• 顧客や市場のニーズに応えやすい

—

このように、繰り返しプロダクトをリリースして、少しずつ機能や品質を充実させていくのがアジャイル開発の魅力です。顧客や市場のニーズに応えて仕様変更や機能改善を行いやすい点は、ビジネスの正解が分かっていないようなデジタルトランスフォーメーションやリーンスタートアップで効果を発揮するでしょう。また、Webサービスのように継続的に機能や品質を改善していく場合にも向いています。

アジャイル開発の失敗パターン

一方で、アジャイル開発にはいくつかの失敗パターンがあります。

• ミニウォーターフォール化：作るべきプロダクトの仕様を分解してプロダクトバックログを作り、それを更新しないまま逐次開発していく。これでは、小さなウォーターフォール開発を繰り返しているだけになってしまいます。プロダクトオーナーは、発注側として開発内容を丸投げするのではなく、スクラムチームのメンバーとしてプロダクトの価値を最大化する役割があります。
• スクラムチームの主体性不足：アジャイル開発では、何をどう作るか開発チームが主体的にコントロールしていきます。同時に、開発メンバー自身が開発対象のビジネス領域を理解して、設計・実装・テストしていくことが求められます。スクラムマスターは、プロジェクト管理者ではなく、スクラムチームがスクラムを実現できるよう支援する役割があります。
  ウォーターフォールに慣れたメンバーが、自分の専門領域や従来の役割にこだわっているとアジャイル開発の効果を発揮しにくくなります。各メンバーがチームの中で主体性を発揮していくことが欠かせません。

• ステークホルダーの理解不足：アジャイル開発では、短いサイクルでプロダクトをリリースしていきます。ウォーターフォール開発と比較すると、機能不足で未完成な印象を受けるでしょう。場合によっては、いつまでもシステムが完成しないと勘違いする場合もあります。

—

システムを活用するビジネス側が、それを使って何を評価・検証するのかが重要です。

ウォーターフォール開発とアジャイル開発との違い

アジャイル開発とウォーターフォール開発の違いは次のようになります。

	ウォーターフォール開発	アジャイル開発
仕様変更	開発開始後はコスト大	開発開発後もコスト小
開発サイクルと期間 (企画からリリースまでは同じ流れ)	1工程ごとに評価・完了し、次の工程にうつる。そのため、仮に全体的な改善点があった場合は別のプロジェクトで試すしかない。開発期間は長くなる	反復開発であるため何度もプロダクトをリリースできる。改善や要件変更もしやすい。
開発のクオリティ	全体的に設計に従うために品質を統一しやすい	それぞれの開発チームによって品質が一定しないことがある

開発者のスキルについても、ウォーターフォール開発であれば担当工程のみを知っていれば参加できます。一方、アジャイル開発では一通り結果を示せるスキルが必要とされることから、要求されるスキルは高いといえるでしょう。

2つの開発手法をどう使い分けるのか

ここからは、2つの開発手法の使い分けをみていきましょう。仕様変更がポイントになることに加え、発注側が求めるシステムに合わせて適した開発手法を選択していく必要があります。

開発手法	向いている開発ケース
アジャイル開発	SoE：System of Engagementと呼ばれるシステム SNSやECサイト・Webアプリなど
ウォーターフォール開発	SoR：System of Recordsと呼ばれるシステム 生産管理や販売管理など基幹システム

まとめ

ここまでウォーターフォール開発とアジャイル開発の概要や違いについて、ふれてきました。例えば、システムの柔軟性では、ウォーターフォール開発はアジャイル開発に及ばないものの、しっかりとした要件定義や質の担保であればウォーターフォール開発の方が成果を出しやすいなどの違いがあります。

メリットやデメリットに加え、成否のポイントを知ることで開発プロジェクトを成功させやすくなります。開発手法はあくまで目的に対する手段である点を把握し、システムの目的に合わせて適切な開発を行っていきましょう。