【初心者向け】アジャイル開発の3つのプロセス手法とは？

アジャイル開発には、スクラム・エクストリーム・プログラミング（XP）・ユーザー機能駆動開発（FDD）の3つのプロセス手法があります

それぞれ特徴があり、これからアジャイル開発を検討されている担当者の方は、必ず知っておきたい手法だと言えます。

今回の記事では、アジャイル開発の基礎知識から、3つのプロセス手法を分かりやすく解説します。

1.アジャイル開発とは

アジャイル開発とは、機能単位の小さいサイクルで開発する手法の一つです。

優先度の高い要件から「計画→設計→実装→テスト」といった順で開発を進めていくため、プロジェクトの仕様変更に強く、プロダクトの価値を最大化しやすいのが特徴です。

従来は、ウォーターフォール開発と言って、最初にプロジェクトの要件や設計を細かく決めた後に、大きなサイクルを回して開発を進めていました。

この手法は、進捗管理がしやすく、プロジェクト全体の計画が立てやすいメリットがありますが、開発途中で仕様が変更になると、開発工数が増えるデメリットがあります。

また、仕様変更に伴うユーザー意見の反映が難しいため、実際にできあがったものがイメージと異なってしまう場合もあります。

しかしながら、アジャイル開発では、優先度の高い機能から着手するため、素早くリリースし、調整していくことが可能です。

結果的に、プロダクトの質を高めつつも、納品までの期間を短縮することができます。

また、アジャイル開発と似た意味を持つ「リーン開発」という言葉があります。

これはどちらもプロダクトを開発するという点では共通ですが、アジャイルは「素早さ」を目指すのに対し、リーンでは「ユーザー満足度」を重視します。

両者は、それぞれ必要とされる場面は異なりますが、相性が良いため、開発時にはどちらも意識するとよいでしょう。

関連記事：アジャイル開発における最大のメリットとは？初心者が知っておきたい成功事例も合わせて解説

2.アジャイル開発のプロセス手法

アジャイル開発の概要を理解したところで、実際のプロセス手法を紹介していきます。

2-1.スクラム：

スクラムは、アジャイル開発の中で最も有名なプロセス手法で、チームで仕事を進めるための枠組みを作り、その中で臨機応変にプロジェクトを進めていきます。

アジャイル開発の自由度を保ちながらも、決められた役割に責任を持ちながら体制を構築していく手法で、特徴は大きく2つです。

2-1-1.担当者ごとに「役割」がある

スクラムでは、ロールと呼ばれる3つの役割がチームのメンバーに割り振られます。

・プロダクトオーナー：プロダクト開発の責任者。優先順位付け、メンバーへの依頼、スケジュール管理を行なう

・開発チーム：実際に開発を行なうエンジニアメンバーです。要件設計/機能設計・コーディング・運用・テストなどといった幅広いスキルが求められる

・マネージャー：プロダクトオーナーと開発チームの中継役です。スクラムのルールをオーナーと協力して開発メンバーに伝え、開発チームからの現場の声をプロダクトオーナーに共有します。

これら3つの役割が上手く噛み合わさり、開発チーム一致団結してプロダクトを開発していきます。

2-1-2.開発サイクルを何度も行なう

スクラムでは、1週間～4週間のスパンで、目標設定・開発・フィードバックを行ないます。

アジャイル開発では、2週間～2か月で回すことが多いですが、スクラムはそのなかでもスピード重視のプロセス手法だと言えます。

開発サイクルの流れは以下の通りです。

ステップ1.バックログを作成する

バックログとは、ユーザーにとって必要な機能を一覧化したものです。

スタート時には、その中から実装すべきものを選定し、より詳細なものに分解したものをバックログとして作成します。

ここで重要なのは、メンバーのスキルを総動員して、自信をもって終わらせることができるかしっかり確認することです。

プロジェクトが始まると、イレギュラーな対応も出てくるため、一人一人が責任もって仕事をするという心構えが大切になります。

ステップ2.デイリースクラムを実施する

デイリースクラムとは、毎日作業開始前に行なわれるミーティングのことです。

毎日、各自の進捗状況や抱えている課題、解決したことなどを共有し、進捗を確認します。

15分しかないため、事前に準備しておいたり、あらたに課題が出たときは、別途ミーティングを設けるなどのルールを設けます。

デイリースクラムのルールはすべてを一度に実施しようとすると、失敗するため、効果のあるものから取り入れていくことをおすすめします。

ステップ3.スプリントレビューをおこなう

スプリントビューは、開発期間の終わりに実施するミーティングの1つです。プロジェクトによっては、1週間～1か月の場合もあります。

スプリントビューでは、プロダクトのデモが行われ、開発状況をしっかり確認できるため、重要なミーティングとなります。

開発チームにとっては、完成品を見せて、ユーザーから直接フィードバックをが得られるため、自分たちが開発したものとユーザーニーズにズレがないか確認し、方向性を確かめます。

ここで得られるバックログ（タスク一覧）をもとに、次回の開発内容が決まるため、どこをどう改善すればよいかの見通しも立ちやすくなります。

ステップ4：スプリントレトロスペクティブを行なう

スプリントレトロスペクティブとは、スクリプトの最後に行われる振り返りのミーティングです。

スプリントレトロスペクティブの目的は、今後の開発をよりよく実施し、プロダクトの品質を上げることです。

スクラムマスターと開発チームが、次回以降の改善点をおよそ1～3時間かけて出し合います。スクラムはスピード重視で行なうため、この振り返りが非常に大切だと言えます。

DeFactoryでは、スクラム同様、「アイディア検証～ユーザーヒアリング～プロダクト開発～ユーザーテスト」までを最短14営業日で行なうことができます。

スクラムの手法を取り入れつつ、経験豊富なエンジニアとマネージャーが伴走支援しますので、初めてスクラム手法を行なう方でも、安心していただければと思います。

2-2.エクストリーム・プログラミング（XP）

エクストリーム・プログラミング（XP）とは、スクラムがスピード重視でプロダクトを作るのに対して、柔軟性を重視したプロセス手法です。

アジャイル開発は、要件定義からテストまでの流れを繰り返していきますが、その中でもエクストリーム・プログラミングは、ユーザー要望や仕様変更に柔軟に対応します。

エクストリーム・プログラミングは柔軟性を持たせるために「共同」「開発」「管理者」「顧客」の4つのプラクティス（アジャイルを実現するための取り組み）から成り立っています。

2-2-1.共同プラクティス

共同プラクティスとは、開発チームとユーザーのどちらも持つべき習慣のことです。

反復：1～2週間で終わるような開発を何度も繰り返す

共通言語：用語集を作ることでコミュニケーションを円滑にする

開けた作業時間：作業に集中しやすくコミュニケーションが取りやすい環境を構築する

回顧：失敗を次に生かす仕組み作り

短期間で何度もコミュニケーションを取り、改善を重ねていくため、一人一人がルールを遵守することが重要になってくるといえるでしょう。

2-2-2.開発プラクティス

開発プラクティスは、エンジニアなど開発チームを対象としたプラクティス（アジャイルを実現するための取り組み）です。

ペアプログラミング：1つのプログラムを2人で共同開発する

テスト駆動開発：実装する前にテストコードを書き、それに適合するように実装する

リファクタリング：仕様変更をせず内部構造を変える

YANGI：無駄な開発をせず、今必要なものだけ開発する

最も特徴的なのがペアプログラミングで、一人がコードを書いているときは、もう一人が全体設計を考えます。

この役を交代しながら、開発をすることで、短期間で質の高いプロダクトを開発することができます。

他に様々なプログラミング手法があるため、適切な開発方法を行なっていく必要があると言えるでしょう。

2-2-3.管理者プラクティス

管理者プラクティスとは、管理者を対象とした取り組みです。

責任の受け入れ：一方通行でなく開発チームがユーザー目線で実現できるようにする

援護：利害関係者や周囲との関係から妨害となるものを把握する

四半期ごとの見直し：進捗状況を一定期間ごとに確認し見直す

ミラー：チームの状況をこまめに共有する

最適なペースの仕事：関係者の労働時間を管理する

管理者は、チームのメンバーに自律・自発的な行動を促し、成果を最大限に引き出すことに注力します。

2-2-4.顧客プラクティス

顧客プラクティスとは、顧客（ユーザー）を対象とした取り組みです。

ストーリーの作成：機能の要件を端的にまとめ、それをもとにディスカッションする

リリース計画：課題をどれくらいの期間で実施するかチームで決める

受け入れテスト：顧客の立場からストーリーが実現しているか確認する

短期リリース：プロダクトを2週間～8週間という短い感覚でリリースする

DeFactoryでは、対象ユーザーの「声を直接聴く」という顧客プラクティスを重要視しています。

・根源的な欲求や見えていないニーズの発見

・ヒアリングを通じた「ユーザーの行動と行動の結果」から情報を得る

・オープンクエスチョンで且つ主観的ではなく客観的な行動を探る

これらを通じてユーザーにとって付加価値の高いプロダクト開発を目指しています。

2-3.ユーザー機能駆動開発（FDD）

ユーザー機能駆動開発（FDD）とは、「ユーザー目線」に着目して開発を進めるプロセス手法です。

ユーザーが欲しい機能を明確にし、動作を反復して行い、ユーザーにとって価値あるプロダクトを開発していきます。

この手法では、早い段階からユーザーとのコミュニケーションが重要となりますので、どのメンバーをどうアサインするが重要になってきます。

ユーザー機能に重点を置いている分、他の機能よりも質の高いものを開発しやすいと言えるでしょう。

3.まとめ：「アジャイル開発」に関する支援を承ります

今回は、アジャイル開発におけるプロセス手法についてお伝えしました。

１，スクラム：スピード重視

２，エクストリーム・プログラミング（XP）：柔軟性重視

３，ユーザー機能駆動開発（FDD）：ユーザー重視

アジャイル開発は、ユーザーとコミュニケーションをとりながら、高速でサイクルを回していきますが、プロダクトの特徴や納期によって、どのプロセス手法を使い分ければよいか分からない方もいるはずです。

プロダクト開発初期段階で、どのプロセス手法を使うかは、重要な決断になるといえるでしょう。もし社内で判断が難しい場合は、外部のベンダーに依頼するのも一つの手です。

DeFactoryでは、アイディア着想、ユーザーヒアリング、テストマーケティング、アジャイル・MVP開発と、プロダクト開発における立ち上げ支援を全力サポートいたします。

また、経験豊富なエンジニアと事業開発経験者で、開発だけでなく事業設計から「一気通貫」した事業開発の伴走を行ないます。

事業開発や立ち上げを検討しているご担当者様がいましたら、問い合わせページから資料請求や無料相談などお気軽にご連絡くださいませ。

【DeFactoryの3つの特徴】

・最短14営業日程度で納品

・事業構築力、スピード、高品質を実現する体制

・キャンペーンにより事業構想フォローを無料実施

サービスページ：MVP特化型開発「DeFactory」

関連記事：アジャイル開発の2つのデメリット！解決方法も合わせて解説