アジャイル開発とスクラム開発について教えて！

ウォーターフォール開発の欠点

システム開発、またソフトアウェアの開発には、大きく言って２つの流れがあります。

1つが、従来の主流である『ウォーターフォール開発』。

もう1つが、米国では主流となっており、日本でも採用する企業が増加している『アジャイルソフトウェア開発』です。

ウォーターフォールのメリットとデメリット

1. メリット・・・プロジェクトの管理がしやすくなる
2. デメリット・・・クライアントの仕様変更に柔軟に対応できない

ウォーターフォールは、もともと「滝」という意味です。

最初に要件の定義を厳密に行い、滝が流れるように一方向で納品に向かいます。

この方法の良いところは、厳密な管理によってプロジェクトの管理がしやすくなるということです。

一方欠点としては、最初に仕様（設計図）を事細かに決めるので、クライアントの仕様変更に柔軟に対応できないといったことがあげられます。

これに対し、アジャイル開発はその欠点を克服しようという試みなのです。

アジャイル開発について

アジャイルソフトウェア開発では、少人数の開発チームが目的の達成のために作業を進める体制をとり、納品を繰り返す開発スタイルとなることが特徴です。

アジャイル開発の特徴

「短期間でできること」「実現できること」「リリースできること」を定めて、適宜クライアントからのヒアリングを繰り返すことで、ウォーターフォールと違って優先順位を柔軟に決めていくのです。

例えば…ゲームソフトで言えば、「ハイスコアのランキング機能」といった、プラスアルファのものが当初は付属していなくとも、ゲーム自体のリリースは可能です。

これに、後々から市場の反応を見て、「対戦機能」であったり、「ユーザー同士のチャット機能」などを追加していくことができます。

ゲーム本体そのものとは違ったユーティリティ部分を、優先順位をつけてアップデートしていくことは合理的と言えます。

スクラム開発について

アジャイル開発は、柔軟性という点では確かに優れています。

しかし、ウォーターフォール開発のように決められたことを、組織的にきちんと管理していくという点で、ノウハウの蓄積やフレームワークの確立に課題がありました。

いわば、自由と管理の間で葛藤があったと言えるでしょう。

こうした中で、「チームのコミュニケーションを重視したアジャイル手法」である「スクラム」という方法論が浮上してきました。

スクラム開発では役割が存在する

スクラム開発では、アジャイル開発の自由さを最大限尊重しながらも、決められた役割に責任を持つ体制を整えます。

1. プロダクトオーナー
2. スクラムマスター
3. 開発メンバー

主には「プロダクトオーナー」、「スクラムマスター」、「開発メンバー」と呼ばれる役割が存在します。

プロダクトオーナー

プロジェクトの責任者であり、クライアントと一緒に製品の方向性を考えます。

それをチーム全体に説明し、納得してもらうことで、スムーズに開発を進めることを役割としています。

ただし、プロダクトオーナーは基本的には開発を行わず、管理に徹します。

予算配分の実行権も持っていますが、方向性に関してはあくまでクライアントとの合意のもとに意思決定を行っていきます。

またプロジェクトマネージャーとしての役割も果たし、プロジェクト全体を俯瞰的に見る立場であることを求められます。

スクラムマスター

直感的な言い方をすれば、中間管理職、もしくは開発実務のリーダー的存在です。

自分が所属しているスクラムのルールや進め方をプロダクトオーナーとの調整のもと決定し、それを開発メンバーに納得させる役割を担います。

もちろん開発メンバーからのフィードバックもできる限りプロダクトオーナーに説明し、効果的な実践を促すなどの調整も行います。

また、タスクの中で特定のメンバーのみが過度な負担を被ったり、作業遅れが生じてしまわないような配慮も行います。

プロダクトオーナーは、開発メンバーと一定の距離感を持った専任の者である方がうまくいきますが、スクラムマスターや開発メンバーと兼任されることも多くあります。

開発メンバー

従来のアジャイル開発では、個々の開発メンバーの自発性と調整能力に期待し、全体のプロジェクト管理等は自主管理とミーティングによって随時調整する、というスタイルでした。

しかし、スクラム開発においては、緩やかながらも管理体制を確立し、開発メンバーは実際に開発を行うことに専念し、必要なものや事柄などについては、忌憚なくスクラムマスターに伝えて調整してもらうという分担がなされています。

もちろん、各メンバーに「設計」「ドキュメント作成」「コーディング」「テスト」「運用」といった基本的スキルがあることが前提です。

しかし、ウォーターフォール開発のように、決められたことだけをその都度行うということではなく、適宜他のメンバーのフォローなども積極的に行っていくことが求められています。

役割を実行していくためのスプリント

スクラム開発では、開発の1つの期間単位のことを「スプリント」と言います。

これは一般的なアジャイル開発の「イテレーション」に相当するものですが、組織的な流れを取り入れたということで別の呼称になっています。

では、具体的にスプリントがどのような流れになっているのか見てみましょう。

バックログの作成

製品で実現するべきリストです。

リストは固定的なものではなく、優先順位に基づいて改変可能です。

スプリントプランニングミーティング

スプリントプランニングミーティングでは、バックログごとに工数の見積もりを行い、それぞれの作業を各メンバーに割り振ります。

デイリースクラム

毎朝行うものであるため、「朝会」とも呼ばれます。

状況確認といった程度のもので、時間にして5～15分程度で終わります。

「昨日のタスクの仕上がり状況」、「今日のタスク」や「発生している問題」などについて、情報を共有します。

スプリントレビュー

スプリントの最終日には、プロダクトオーナーが製品をチェックします。

これを、スプリントレビューと言います。

これは、最終的にクライアントに納品するものではありませんが、必ず動いている状態であることが必須です。

モックアップやドキュメントの説明は却下されます。

スプリントレトロスペクティブ

スプリント最終日には、今回のスプリントの反省会といえるスプリントレトロスペクティブが開催されます。

このミーティングでは、組織的に蓄積された「ノウハウ」や、「浮き上がってきた課題」などを共有し、「知識創造」「ノウハウの共有や継承」といったことを目指します。

さいごに

こちらの記事もオススメ！

スクラムのオススメ本