「アジャイル開発を活用して組織力をあげたい」、「アジャイル開発は何をすればいいのかよくわかっていない」
上記のようなお悩みはございませんか？
本記事では以下3つをわかりやすく解説しています。
- アジャイル開発とは？
- ウォータフォールとの違いは？
- どのように実践していくのか？
それぞれ詳しく解説していますので、アジャイル開発について知りたい方はぜひご参考にしてください。
＜＜あわせて読みたい＞＞
メタバースとは？メタバースの語源や意味、具体例をわかりやすく解説！
DXとは？なぜDXと略すの？デジタルトランスフォーメーションの意味や定義をわかりやすく解説
書籍『リーダーの仮面』の図説資料をプレゼント！
株式会社識学 代表取締役社長 安藤広大の執筆した書籍「リーダーの仮面」は、結果の出せるリーダーになるために必要なテクニックをまとめたリーダーシップ本の決定版！
誰でも実践できるマネジメントの原理原則をPDF17ページにググっと凝縮！
ぜひ、DL頂き、皆さまの日々のマネジメントに生かしてください！
目次
アジャイル開発とは？
アジャイル開発とは、ソフトウェア開発手法のひとつです。アジャイル開発とよく比較される手法にウォーターフォール開発がありますが、これら二つには大きな違いがあります。二つの違いを正しく理解し、正しく活用することで、組織力の向上を目指しましょう。
ウォーターフォール開発
ソフト開発の大まかな工程は下記の4つに分けられます。
- 仕様定義
- 設計
- 実装
- 評価
ウォーターフォール開発は、最初の工程の「仕様定義」で、すべての仕様を決めてから次の工程に移ります。ウォーターフォール開発では、滝（ウォーターフォール）の流れのように、後の工程から前の工程に戻ることはできません。
ウォーターフォール開発のメリット・デメリット
ウォーターフォール開発のメリットは、すべての仕様が決まっているため、開発全体のボリューム（期間やコスト）を把握しやすくなることです。
一方でデメリットは、途中で仕様変更が生じると、手戻り作業をしなければならないため、計画に大きな遅れがでてしまうリスクがあります。
アジャイル開発
アジャイル開発では、「仕様定義→設計→実装→評価」の工程を、小さな機能単位やブロック単位で迅速に開発を進めていきます。ウォーターフォール開発とは違い、最初の工程ですべての仕様は決まっておらず、開発をしながら仕様を決めていきます。
アジャイル開発のメリット・デメリット
アジャイル開発のメリットは、小さな機能やブロック単位で開発をするため、顧客に対してプロジェクトの途中でも成果物を見せることが可能となり、顧客の要望に応じて柔軟に対応ができることです。
一方でデメリットは、柔軟に対応し過ぎることで当初の計画からずれてしまうことが挙げられます。また、全体像が把握しにくく、初期段階で開発全体のボリューム（期間やコスト）が把握できない点もデメリットです。
アジャイル開発に向いているプロジェクト
アジャイル開発に向いているプロジェクトは、WEB系やアプリ系のようにライフサイクルが短く、頻繁にアップデートしなければならないものです。
近年は、組み込み系（車載や家電）などのライフサイクルが3年以上のものにも使用され始めています。この理由は、市場規模が拡大して海外とも戦っていくうえで、開発の方向性を定められなくなってきていることです。
したがって、柔軟な仕様変更に対応できるアジャイル開発を選ぶ組織が増えてきています。
アジャイル開発の種類
よく知られているアジャイル開発の手法が下記の3つです。
- スクラム
- エクストリーム・プログラミング
- ユーザー機能駆動開発
それでは1つずつ解説していきます。
スクラム
スクラム開発とは、プロジェクトメンバーがスクラムを組み、一丸となって開発を進める手法で、特徴は2つあります。1つはプロダクトオーナー、スクラムマスター、開発チームで役割分担を明確にしてから開発を行うことです。
残りが、プロダクトバックログと呼ばれる開発項目のリスト作成を行うことです。
エクストリーム・プログラミング（XP）
エクストリームプログラミング（XP）とは、プログラミングを中心的に考える手法です。開発現場におけるプラクティス（経験則）をエクストリーム（極端）なレベルまで実践していきます。XPの特徴は、4つの価値、5つの基本原則、4種にカテゴライズされた19のプラクティスといったXP独自の考え方やプラクティスがあることです。
ユーザー機能駆動開発（FDD）
ユーザー機能駆動開発（FDD）とは、ユーザーにとっての機能的価値（フューチャー）を観点に開発を進める手法で、アジャイル開発の手法の中でも、大規模開発向きです。
FDDの一番の特徴は、開発単位のフューチャーを2週間で区切ることです。
2週間で開発できないものは分割、調整を行います。2週間ごとにユーザーが機能を確認できるため、柔軟な開発の軌道修正が可能です。
スクラムの基礎知識
アジャイル開発手法でもよく知られているプロダクトバックログ、役割（ロール）、スプリントについて詳しく解説します。
プロダクトバックログ
プロダクトバックログとは、プロダクト（製品）の実現したい要求のリストを並べたものです。このリストは、要求の価値やリスク、必要性によって並び替え、順位が高いものから開発を始めます。一度、プロダクトバックログを作成してもそれで完成ではなく、必要性の変更や、新たな要求があるたびにリストを並び替え、常に最新状態となるようにしなければなりません。
役割（ロール）
スクラムの役割が下記の3つです。
- プロダクトバックログの責任者であるプロダクトオーナー
- プロセスがうまく回るようにするスクラムマスター
- 実際に開発をする開発チーム
それでは1つずつ解説していきます。
プロダクトオーナー
プロダクトオーナーはプロダクトバックログの責任者ですが、メンテナンスだけが仕事ではありません。他にも以下の仕事があります。
- プロダクトの方針を明確にして共有する
- プロダクトバックログの項目を関係者に説明する
- 予算の管理をする
- おおよその全体日程の作成する
- 顧客とプロダクトバックログの認識合わせを実施する
- 作成したプロダクトが要求と一致するかの確認をする
このように、プロダクトオーナーは全体をマネジメントする立場であり、プロダクトの責任者でもあります。
スクラムマスター
スクラムマスターは、プロセスをうまく回したり、プロダクトオーナーや開発チームを支えることが仕事です。スクラムの進め方や成果物、ルールをプロダクトオーナーや開発チームに理解させる役割で、他にも以下の仕事があります。
- 会議や打ち合わせの進行役
- プロダクトオーナーや開発チームの相談役
- 開発の妨害リストを作成し、優先順位付けや解決方法の検討、解決の依頼を行う
スクラムマスターは開発現場全体が見渡せるポジションなので、メンバー全員の様子を常に観察して、円滑に仕事を進めることが大切な役割となります。
開発チーム
開発チームは、プロダクトを開発するうえですべての仕事（要求分析、設計、コーディング、評価、ドキュメント作成など）を遂行する能力が必要となります。評価専任の部隊、設計専任の部隊といった、特定のことしかできないチームは必要ありません。
チーム内で得手・不得手はあるかもしれませんが、全員が複数のことをこなせるチームが求められます。
開発チーム内の仕事の進め方は、外部から邪魔されないようにしなければなりません。開発チームメンバー全員の合意のもと仕事を進めていき、責任をもって仕事を進めることで、開発チーム全体の能力向上につながります。
スプリント
スクラムにおける小さな開発単位をスプリントと呼びます。スプリントは、最長1か月の固定期間に区切り、短い場合は1週間で固定しますが、もし、スプリント最終日に作業が残っていたとしても、スプリント期間は延長しません。
スプリントを中断する権利はプロダクトオーナーが持っており、作業中のスプリントに開発の意味がなくなった場合のみ中断を決断します。また、1回のスプリントでは、「設計→実装→評価」が1周できるように期間を設定します。
このように、固定期間で区切って開発を繰り返すことで生まれるメリットが、プロジェクト全体の進捗が把握しやすくなることや、リスクマネジメントをしやすくなることです。
スプリント計画ミーティング
スプリント計画ミーティングでは、「今回のスプリントで、プロダクトバックログのどの項目をどう開発するか」を検討をします。使用してよい時間は、2週間のスプリントでは4時間、4週間のスプリントであれば8時間までとします。
また、スプリント計画ミーティングは2部構成です。第1部は、プロダクトオーナー、スクラムマスター、開発チームが参加し、プロダクトバックログの中のどの項目を開発するのか検討します。
そして、その項目がどれくらいの開発ボリュームがあるのかを、過去の実績から予測を立てるのです。さらに、「どこまで完成すればプロダクトバックログの項目の実現完了といえるか」という受け入れ基準を事前に作成します。
スプリントバックログ
第2部では開発チームのみ参加し、第1部で選択したプロダクトバックログの項目を完了させるために、すべての必要作業を洗い出します。これらの必要作業を「タスク」と呼び、タスクの一覧のことを「スプリントバックログ」と呼びます。
ひとつのタスクの大きさは、1日以内に完了するものとし、スプリント期間中に自由にタスクの追加、削除をすることが可能です。タスクを洗い出した後に、スプリント期間中に完了できないことが発覚した場合は、プロダクトオーナーと相談して、下記の対策により全体の作業量を調整します。
- プロダクトバックログの項目を外す
- 実装方法の再検討をする
また、プロダクトバックログの項目の担当は、作業者自身が選択を行います。
デイリースクラム
開発チームは毎日、同じ場所、同じ時間にデイリースクラムと呼ばれる状況確認のための会議を行いますが、昨今では、在宅でも可能なWeb会議が主流となりつつあります。
デイリースクラムは15分間で終了し、延長は禁止です。
各メンバーは、下記3点について簡潔に報告します。
- 前日やったこと
- 本日やること
- 困っていること
デイリースクラムはあくまで開発チーム内のための会議であり、上司に報告する場でも、また問題解決の場でもありません。問題が報告された場合は、デイリースクラム終了後に改めて問題解決に必要な人を呼び、会議を行います。このようにすることで、全員の時間を節約するように心がけます。
スプリントレビュー
スプリントレビューでは、プロダクトオーナーがプロダクトの確認を行います。
開発チームがすることは、プロダクトオーナーが実際に開発したものを見て、触れるように準備し、説明することです。
プロダクトオーナーは確認したあと、スプリントバックログの項目が問題なく完成していれば項目完了としますが、完成していなければ、再びプロダクトバックログに戻します。
スプリント単位で確認を行うことのメリットは、プロジェクトの最後に確認して問題が発覚し、手戻りしてしまうリスクを抑えられることです。また、スプリントレビューに使用してよい時間は、2週間のスプリントでは2時間、4週間のスプリントであれば4時間とします。
スプリントレトロスペクティブ
スプリントレトロスペクティブとは、振り返りのことです。
スプリントレトロスペクティブはスプリントの最後に実施し、使用してよい時間は、2週間のスプリントでは2時間、4週間のスプリントでは4時間となります。
ここで話し合う内容は「今回のスプリントにおいて問題がなかったか」と「さらに成果をあげるにはどうすればいいか」の2点です。話し合ったうえで、次のスプリントに向けて具体的に何を実施するのかを考えて、仕事のやり方を改善していきます。
このように、スプリント単位でより良いやり方に変え続けるように仕組み化されていることが大切なポイントです。
まとめ
本記事では、組織力向上を目指すためのアジャイルの代表的な手法の紹介（スクラム、エクストリーム・プログラミング、ユーザー機能駆動開発）。
あわせて、その中で特に有名なスクラムに関して解説いたしました。
今回の記事ではスクラムの基礎的な考え方に絞って説明をしましたが、実際にスクラムを始めてみると、運営する上で課題にぶつかることもあるかと思います。課題をなくしていくこともひとつの改善活動です。
また、組織力向上に近道はありません。アジャイル開発を正しく理解し、正しく運営することにより、組織が成熟されていきます。
株式会社識学 代表取締役社長 安藤広大の執筆した書籍『数値化の鬼』が、なんと発売後 約１か月で１２万部を突破しました！
この感謝を皆様にも還元すべく、株式会社識学では、『数値化の鬼』の図解解説資料を作成いたしました！
一度書籍をお読みになった方も、まだお手元にない方もどなたでも満足いただける完成度となっています！
眺めるもヨシ、印刷して目の付くところに飾るもヨシ、使い方は自由自在！
是非、こちらからDLしてくださいね！
