アジャイル開発
このページでは経験したアジャイル開発の手法や考え方についてまとめています。
アジャイル開発とは
アジャイル開発とは、ソフトウェア開発の手法の一つで、従来のウォーターフォールモデルに代わるものとして提唱されました。ウォーターフォールモデルでは、要件定義、設計、実装、テストという一連の工程を順番に進めていくため、一度進んだ工程に戻ることが難しいという問題がありました。そのため、要件が変更された場合に対応しにくいという問題がありました。
アジャイル開発では、短い期間で小さな機能を開発し、その都度リリースすることで、要件の変更にも柔軟に対応できるようにしています。また、開発チームと顧客とのコミュニケーションを重視し、顧客の要望を取り入れながら開発を進めていくことが特徴です。
アジャイル開発のメリット
アジャイル開発のメリットは以下の通りです。
- 顧客の要望を柔軟に取り入れることができる
- 開発の進捗状況を早い段階で確認できる
- チーム全体で開発に参加することで、モチベーションが向上する
- バグや問題点を早い段階で発見しやすくなる
- リリースごとにフィードバックを受け取ることで、次の開発に生かせる
アジャイル開発の手法
アジャイル開発にはいくつかの手法がありますが、経験したアジャイル開発手法はスクラムのため、以降ではスクラムについて説明します。
スクラム
スクラムは、アジャイル開発の手法の一つで、開発チームが自己組織化して、短い期間で成果物を作り出すことを目指す手法です。スクラムでは、開発を複数のイテレーション（スプリント）に分け、各スプリントごとに一定期間（通常2週間から1ヶ月程度）で成果物を作り出します。スプリントごとに計画を立て、その計画を実行し、成果物をレビューして改善するというサイクルを繰り返します。
チーム構成
スクラム開発では以下のような役割分担が一般的です。
- プロダクトオーナー：顧客の要望を受け入れ、プロダクトバックログを作成する
- スクラムマスター：スクラムの運用をサポートし、障害を取り除く
- 開発チーム：プロダクトバックログに基づいて開発を行う
スプリント計画会議
スクラムでは、スプリントごとにスプリント計画会議を行います。スプリント計画会議では、プロダクトバックログからスプリントバックログを作成し、スプリント中に開発する成果物を決定します。スプリント計画会議では、プロダクトオーナーが優先順位を決め、開発チームが見積もりを行い、スプリントバックログを作成します。
デイリースクラム
スクラムでは、スプリント中にデイリースクラムと呼ばれる日次のミーティングを行います。デイリースクラムでは、開発チーム全員が立って行うことが一般的で、各メンバが昨日や今日の作業内容、進捗状況、問題点などを共有します。デイリースクラムを通じて、開発チーム全体が進捗状況を把握し、問題点を共有することができます。
リファインメント
スクラムでは、スプリント計画会議以外にもリファインメントと呼ばれるミーティングを行います。リファインメントでは、プロダクトバックログに新しい要求が追加された場合や、スプリントバックログに含まれるタスクの見積もりが必要な場合などに行います。リファインメントを通じて、開発チーム全体がプロダクトバックログやスプリントバックログを共有し、開発に必要な情報を整理することができます。
レトロスペクティブ
スクラムでは、スプリントごとにレトロスペクティブと呼ばれる振り返りのミーティングを行います。レトロスペクティブでは、前回のスプリントでうまくいったこと、うまくいかなかったこと、改善すべき点などについて振り返り、次のスプリントに生かすためのアクションを考えます。レトロスペクティブを通じて、開発チーム全体が成長し、開発プロセスを改善していくことができます。
可能な限り精神的負荷を減らすために、レトロスペクティブはリーダーが主導することが一般的です。リーダーは、参加者全員が自由に意見を述べられるように配慮し、議論が偏らないように誘導する役割を担います。具体的には、議論が進まない場合には、タイマーを使って時間を区切り、次のアクションに進むよう促す、お酒等を用意してレトロスペクティブ後は業務終了とするなどの工夫があります。
スプリントレビュー
スクラムでは、スプリントごとにスプリントレビューと呼ばれる成果物のレビューを行います。スプリントレビューでは、開発チームが作成した成果物を顧客やステークホルダーに紹介し、フィードバックを受け取ります。スプリントレビューを通じて、顧客の要望を取り入れ、次のスプリントに生かすことができます。
その他
スクラムには他にも、バーンダウンチャートやスクラムボードなどのツールを使って進捗管理を行うことが一般的です。バーンダウンチャートは、スプリント中の進捗状況をグラフで可視化するために使われ、スクラムボードは、タスクの進捗状況をボード上に可視化するために使われます。
使用ツール
スクラムでは、タスク管理やコミュニケーションのために、以下のようなツールを使用することが一般的です。
- タスク管理：JIRA、Trello、Backlog、Redmine、figmaなど
- コミュニケーション：Slack、Teamsなど
- ドキュメント管理：Confluence、Wikiなど
- バージョン管理：Git、GitHub、Bitbucketなど
- CI/CD：Jenkins、CircleCI、Travis CIなど
個人的な経験では、以下のツール構成で行っていました。 - タスク管理：Backlog、GitHubIssueが混在 - コミュニケーション：開発企業内はSlack、顧客とはTeams - ドキュメント管理：開発企業内はWiki、Excel、Word、PowerPoint等が混在、顧客向けはSharePointへアップロード可能な形の主にPowerPointドキュメント - バージョン管理：GitHub(git) - CI/CD：ArgoCD、GitHubActionsが混在
情報が散逸してしまうことが多かったため、情報の一元管理を心がけることが重要であり、これが行われていない場合はタスクの認識齟齬や進捗の把握、作業工数の増大等が発生しやすく、プロジェクトの遅延や品質低下につながります。
したがって、以下の構成で行うことが望ましいと考えています。
- タスク管理：開発チームはGitHubIssueに限定（プロダクトオーナー、スクラムマスターは顧客向けのツールを併用）
- コミュニケーション：開発プロジェクト内のコミュニケーションはGitHubIssue、またはGitHubDiscussionを使用（企業内のコミュニケーションはSlack、Teams等）
- ドキュメント管理：GitHubWiki、またはGitHubRepository内のドキュメント管理（企業間のドキュメント管理は別途SharePoint等を使用）
- バージョン管理：GitHub(git)
- CI/CD：特殊な状況を除いてGitHubActions
このように、プロジェクト内部での情報共有をGitHubを中心に行うことで、情報の一元管理を実現し、プロジェクトの進捗をスムーズにすることができます。情報の連携が適切に取られることで、プロジェクトの遅延や品質低下を防ぐことができます。
| 日付 | 時間帯 | 活動内容 | 司会 | 時間 | 参加者 | 会場 | アウトプット先 |
|---|---|---|---|---|---|---|---|
| 1日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | スプリント計画会議 | プロダクトオーナー | 1時間 | PO, SM, 開発チーム全員 | 会議室 | GitHub Issueボード | |
| 昼 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 夕方 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 2日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 3日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 昼 | リファインメント | プロダクトオーナー | 1時間 | PO, SM, 開発チーム全員 | 会議室 | GitHub Issueボード | |
| 4日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 5日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 昼 | レトロスペクティブ | スクラムマスター | 1時間 | SM, 開発チーム全員 | 会議室 | GitHub Issueボード | |
| 6日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 7日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 昼 | レトロスペクティブ | スクラムマスター | 1時間 | SM, 開発チーム全員 | 会議室 | GitHub Issueボード | |
| 8日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 9日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 10日目 | 朝 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion |
| 朝 | 開発 | 開発チーム | 4時間 | 開発チーム全員 | 開発環境 | GitHub Issueボード | |
| 昼 | デイリースクラム | スクラムマスター | 15分 | 開発チーム全員 | 立ち会議 | GitHub Issue/Discussion | |
| 昼 | スプリントレビュー | プロダクトオーナー | 1時間 | PO, SM, 開発チーム全員 | 会議室 | GitHub Issueボード | |
| 昼 | スプリントレトロスペクティブ | スクラムマスター | 1時間 | SM, 開発チーム全員 | 会議室 | GitHub Issueボード |