アジャイル開発というものが流行り出してからまずまずの時が流れました。エンジニアなら誰でも名前くらいは聞いたことがあるくらいには市民権を得てきたのではないでしょうか。
DX白書2024によると、IT部門でのアジャイル開発の普及率は、「全面的に取り入れている」と「一部取り入れている」を合わせて44.5%であり、「取り入れていないが、検討中」まで含めると57.9%と過半数になっています。
図1: アジャイルのアプローチをDXの推進プロセスに取り入れているかの状況（出典: DX白書2024）
ただ、実際のプロジェクトの中でゴリゴリにアジャイル開発を行う機会のあったエンジニアはそれほど多くないと思われます（少なくとも私の会社では）。
かくいう私も、研修や勉強会などでアジャイルという言葉を聞く機会はありますが、実際のプロジェクトではウォーターフォール開発が主流で、アジャイルをやった経験なくここまで来ました。
巷の本や記事で見たことはあるので何となく理解しているつもりですが、細かい用語や実践としてどうやるかはよくわかっていません。気になっているけどなかなかお近づきができない、そんな甘く切ない存在でした。
そんな中、チャンスが訪れました。とあるプロジェクトでアジャイル開発をやる必要が出てきたのです。そこで、思いを成就させるべくアジャイル開発、特にスクラムについてキャッチアップしたことを当記事にまとめたいと思います。
アジャイル開発とは
アジャイルの歴史は、2001年に米国ユタ州で17人のソフトウェア開発者が集まり、「アジャイル宣言（Agile Manifesto）」を発表したことに始まります。この宣言では、「個人との対話」「動くソフトウェア」「顧客との協調」「変化への対応」の4つを重視する考え方が示され、従来の計画重視のウォーターフォール型開発の限界を克服することを目指しました。
アジャイル開発の基本的な進め方の方針は次のとおりです。
- 関係者は目的の達成のためお互いに協力し合いながら進める
- 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの事態や計画を調整する
このアジャイルの方針を体現するための開発手法にはいくつかの種類があり、その中でも特に代表的なものとして「スクラム」「エクストリーム・プログラミング（XP）」「カンバン」が挙げられます。それぞれの主な特徴を以下に説明します。
スクラム
スクラムはアジャイル開発で最も広く使われる手法であり、チームで効率的に開発を進めることができるフレームワークです。チーム一体となってプロジェクトを遂行して行くことに重点を置くことから、ラグビーのスクラムが語源になっています。
一定の期間（通常は2〜4週間）の「スプリント」と呼ばれる短い開発サイクルに分けて進めます。各スプリントごとに目標を定め、達成した成果物を確認します。
エクストリーム・プログラミング（XP）
エクストリーム・プログラミング（XP）は、プログラミング技術の向上と高品質なコードを重視した開発手法です。特に顧客との密なコミュニケーションと、短い反復でのリリースが特徴です。
事前の計画よりも仕様・要件の途中変更への柔軟な対応を重視した手法で、4つの価値（コミュニケーション／シンプル／フィードバック／勇気）をチーム内で共有します。
カンバン
カンバンは、作業の視覚化と制限による効率的な作業管理を目指す手法です。タスクを「To Do（未着手）」「In Progress（進行中）」「Done（完了）」のような列で示し、タスクがどの段階にあるかを一目でわかるようにします。主な特徴は以下の通りです。
- 視覚化：タスクやプロセスをボードで視覚化し、現在の状況を全員が把握できるようにします
- 作業制限：進行中のタスク数に制限を設け、作業の集中力を高め、効率を維持します
- 継続的改善：改善点を見つけ、フローを調整しながらプロセスを最適化します
他にも多くの手法が存在します。ここからは、最も一般的で私のプロジェクトでも採用することになったスクラムについて詳細を見ていきます。
スクラムについて
スクラムはソリューション開発手法・フレームワークの１つです。ソフトウェア開発以外のチームにも適用できるのが特徴で、元々は論文The New New Product Development Game (Hirotaka Takeuchi & Ikujiro Nonaka, 1986)の内容をソフトウェア開発に応用したものです。
スクラムは「経験主義」と「リーン思考」に基づいています。
経験主義は、「知識は経験から生まれ、意思決定は観察に基づく」というものであり、
リーン思考は「ムダを省き、本質に集中する」という考え方です。
この経験主義とリーン思考に基づいて開発を進めるため、スクラムでは以下の3つの柱を実現する必要があります。
-
透明性
作成物の現在の状況や問題点を常に明らかにします。これにより適切な意思決定が可能になります。 -
検査
作成物と進捗状況を定期的に確認します。これにより潜在的に望ましくない変化や問題を検知することができます。
効果的な検査は透明性が実現されていることにより実現されます。 -
適応
進め方に問題があったり、より良い方法があったりした場合、できるだけ早く調整します。これにより、ムダを省き常に本質的な開発に注力できます。
検査によって問題を検知した瞬間に適応することが期待されます。
この3つの柱を具体的に実践するために、スクラムでは3つの作成物、3つのロール（チームメンバーの役割）、5つのイベントで構成されています。
アジャイル開発やスクラムについて学ぶ中でまず思うこと、それは「横文字が多すぎて何が何だかわからない」です。
これらの用語はロール、作成物、イベントのいずれかに分類されます。一つずつ整理しながら見ていきましょう。
作成物
スクラムで作成される成果物についての用語をまとめます。
プロダクトバックログ
プロダクトバックログは、プロダクトの実現に必要なものを抽出し、順番に並び替えた一覧です。プロダクトにつき1つだけ作られます。
プロダクトバックログの項目の順番は、プロダクトを完成させる上でその項目を実現させたときに得られる価値やリスク、必要性などによって決定します。そして順番が上位のものから開発されます。
プロダクトバックログは一度作って完成ではなく、絶えず更新されます。項目の内容が変わったり、新しい項目が追加されたり、順番も変わります。
スプリントバックログ
プロダクトバックログの項目を実現するために必要な作業の一覧をスプリントバックログといいます。開発チームの作業計画の役割を果たします。
スプリントバックログは、開発チームがプロダクトバックログ項目を実現するための作業を洗い出して作る作業計画です。スプリント期間中に自由に作業を追加したり削除したりできます。
また、一つの作業は1日以内に終わるように分割するのが一般的です。
インクリメント
インクリメントは、スプリントごとに作成するもので、これまでのスプリントで達成したプロダクトバックログ項目と、今回のスプリントで完成したプロダクトバックログ項目を合わせたものです。つまり、これまでに完了したプロダクトバックログ項目の一覧、その時のプロダクトの状態と言えます。
インクリメントはスプリント単位で「完成」している状態である必要があります。「完成」の定義はスクラムチームで共通の基準を設けて定める必要があります。
例えばソフトウェアなら、スプリント終了時にインクリメントが作成された段階で「ビルドとテストが成功し、正常に動作する」という基準が考えられます。
スプリントが終了した時点で完成の定義を満たしたプロダクトをつくらなければいけません。
ロール
スクラムの基本単位は、スクラムチームという小さなチームです。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数の開発者で構成されます。サブチームや階層は存在しません。
3つのロールには明確な責任が定義されています。
プロダクトオーナー
スクラムチームから生み出されるプロダクトの価値を最大化する責務があります。1チームに1人だけ用意します。
プロダクトオーナーはプロダクトバックログの管理の責任者で、プロダクトバックログの項目の並び順の決定やプロダクトバックログの項目が完成したかの評価について最終的な責任を持ちます。
また、顧客などのステークホルダーにプロダクトバックログの内容を説明したり作る順番や時期を相談したりして協業を促進します。
開発者
開発者はスクラムチームに通常3~9人存在し、開発チームを構成します。
開発チームの主な役割は、プロダクトオーナーが順位付けしたプロダクトバックログの項目を順番に開発していくことです。
開発チームはプロダクトを作るために必要な全ての作業ができなければいけません。例えば、要件の分析や設計、コーディング、ドキュメンテーションといった作業が必要になります。これらの作業はチーム内で機能横断的に行われる必要があります。つまり、「設計チーム」や「コーディングチーム」のように特定作業専門のサブチームを作るのではなく、なるべく個人が複数の作業をすることがのぞまれます。
開発チーム内での仕事の進め方は、開発チームのメンバーの合意のもとで決め、プロダクトオーナーを含め外部から仕事の進め方を指示されることはありません。自己組織化していることが求められます。
スクラムマスター
スクラムマスターは、スクラムのルールや思想、進め方をプロダクトオーナーや開発者に理解させ、スクラムチームの進捗を妨げる障害を排除するように働きかけ、スクラムを確立して効果的に実践させる環境を整える責任を持ちます。
具体的な活動としては、まだチームがスクラムに慣れていない段階では、スクラムのやり方を教えたりイベントの進行役をやったりするような先生役やトレーナーとして振る舞うことが多くなります。チームがスクラムに慣れてきたら、プロダクトオーナーや開発チームの求めに応じて作業をサポートしたり、より生産性を高まるように変化を促したりする活動にシフトしていきます。
またスクラムマスターはスクラムチームだけでなく組織に対しても支援を行います。組織へのスクラムの導入の指導・トレーニングや組織とスクラムチームとの障壁の除外などを実施します。
イベント
スクラムにおける各イベントは、作成物の透明性を保ち、検査と適応をするための機会です。それらを実現するための必要最低限の場を設けるために設計させています。
全てのイベントは、複雑さを低減するために同じ時間と場所で開催されることが望ましいです。
スプリント
スクラムでは最長1ヶ月の固定の期間に区切って開発を繰り返します。この固定期間のことをスプリントと言います。
開発チームはスプリントのなかでプロダクトバックログを完成させるための作業を全て行います。前のスプリントが終わり次第、新しいスプリントが始まります。
スプリントの期間は必ず一定にしなければなりません。期間を固定することで、開発チームにリズムができて集中できるようになり、ゴールに対する進捗の検査と適応をしやすくなることが期待されます。
例えスプリントの最終日に作業が残っていても、スプリントは終了し、期間は延長しません。
スプリントは下記で紹介する他の全てのイベントの入れ物になります。
スプリントプランニング
スプリントを始めるにあたり、まずはスプリントで実行する作業の計画を立てます。計画は、スプリントプランニングというイベントで決定します。
スプリントプランニングでは、3つのトピックを扱います。
-
このスプリントで達成したいゴールは何か
プロダクトオーナーは、今回のスプリントでプロダクトの価値と有用性をどのように高めることができるかを提案します。そして、スクラムチーム全体でスプリントの目標を簡潔にまとめたスプリントゴールを定義します。 -
このスプリントで何をするか
スプリントゴールを達成するために今回のスプリントで完成させるプロダクトバックログを選択します。選択するプロダクトバックログの個数は、それぞれの項目の見積りサイズや開発チームの過去の実績、今回のスプリントで作業に使える時間（キャパシティ）などを踏まえて定めます。 -
選択したプロダクトバックログ項目をどのように実現するのか
開発チームは選択したプロダクトバックログ項目ごとに必要な作業を計画し、スプリントバックログを作成します。
スプリントプランニングを行う前に、プロダクトバックログに上位の項目について事前準備をしておくとスプリントプランニングが効率的に進みます。例えば、項目の内容を具体的にする、項目のサイズを分割する、項目に必要な作業時間を見積もるといった準備が考えられます。
スプリントプランニングに使える時間は、1ヶ月のスプリントの場合最大で8時間です。スプリントの期間が1ヶ月より短ければそれに合わせて短くする必要があります。
デイリースクラム
スプリントプランニングが終わると、開発チームは計画に基づいて日々作業を進めていくことになります。その中で毎日行われるのがデイリースクラムです。
デイリースクラムは15分で行うものとし、延長はしません。複雑さをなくすために毎日同じ時間と場所で開催します。
デイリースクラムでは、開発チームのメンバーが主に以下の3つの質問に答える形で進めることが多いです。
- スプリントゴールを達成するために、自分が昨日やったことは何か
- スプリントゴールを達成するために、自分が今日やることは何か
- スプリントゴールを達成する上で、障害となるものがあるか
これにより、スプリントがゴールに向かって進んでいるか、作業の進捗状況はどうなっているか、開発メンバー間で協力が必要なことはないかを確認できます。
デイリースクラムは問題解決の場ではないと同時に唯一の議論の場ではありません。問題があった場合には、デイリースクラムの終了後に改めて必要なメンバーを集めて適宜会議を設定することができます。
デイリースクラムの結果を踏まえて開発チームはスプリントでの作業の進捗と今後の進め方をプロダクトオーナーへ報告できるようにしておきます。
スプリントレビュー
スプリントの最後に、プロダクトオーナー主催でスプリントの成果をレビューするイベントを開催します。これをスプリントレビューと言います。スプリントレビューにはスクラムチームのメンバーと必要なステークホルダーが参加します。
スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することです。
そのために、開発チームがスプリント中に完成させたインクリメントを実際に披露します。プレゼンテーションだけに限定せずに、実際に動作する環境で操作しながら確認できるようにします。それにより、フィードバックを引き出し、次にやるべきことを整理し、プロダクトバックログに落とし込みます。
スプリントレビューに使える期間は、スプリントが1ヶ月の場合最大4時間です。スプリントの期間が1ヶ月より短ければスプリントレビューの時間も応じて短くすることが多いです。
スプリントレトロスペクティブ
スプリントレトロスペクティブはスプリントレビューの後に行われる、スプリント内で最後のイベントです。
スクラムチームは、個人やチームの活動、プロセス、ツール、完成の定義に関して問題がなかったか検査を行い、次回のスプリント以降に改善します。改善事項を次のスプリントのスプリントバックログに追加することも可能です。
このように仕事のやり方を常に検査して、より良いやり方に変え続けていくことはアジャイル開発における重要な特徴の一つで、スクラムではスプリント単位でそれが行われるように仕組み化されています。
スプリントレトロスペクティブをもってスプリントは終了します。スプリントが1ヶ月の場合、スプリントレトロスペクティブは最大3時間です。これもスプリントの期間に応じて短縮することが多いです。
スクラムの価値基準
ここまでスクラムの基本構造である、3つの作成物、3つのロール（チームメンバーの役割）、5つのイベントについて説明しました。
スクラムが成功するかは、この基本構造の中で次の5つの価値基準を実践できる可動かにかかっています。
-
確約（Commitment）
各メンバーはお互いにサポートし、チームとしてゴールを達成することを確約する -
集中（Focus）
可能な限りゴールに向けて進捗できるようにスプリントの作業に集中する -
公開（Openness）
スクラムチームとステークホルダーは、全ての作業や課題を公開する -
尊敬（Respect）
お互いに能力のある個人として尊敬し、尊敬される -
勇気（Courage）
正しいことをする勇気や困難な問題に取り組む勇気を持つ
スクラム実践に使える便利ツール
ここで、スプリントを回すために便利なツールを紹介したいと思います。
スクラム管理ツール
スクラムを推進するうえで管理するべき対象は以下のものがあると考えられます。
- スケジュール
- スプリント
- 各スプリント内のイベント
- プロダクトバックログ
- 順番（優先度）
- 内容
- スプリントバックログ
- 対応するプロダクトバックログ項目
- 担当者
- 開始日・終了日
- 内容
- レポート
- 進捗・予算等の予実
- ドキュメント
- 議事録
- ノウハウ
これらの項目の管理は、以下の機能により達成されると考えます。
- カレンダー
イベントのスケジューリングに用います。 - バックログ
プロダクトバックログの視覚化・並び替えに用います。 - カンバン
スプリントバックログのリアルタイムの進捗状況確認に用います。 - ガントチャート
スプリント単位やプロジェクト単位の全体的な進捗確認に用います。 - レポート
進捗・品質・コストの状況を集約し、スプリントレトロスペクティブで用います。 - ドキュメント
議事録やナレッジの共有に用います。
これらの機能について、主なツールにおいてどれが使用できるかを一覧にしてまとめてみました。
| ツール | 概要 | カレンダー | バックログ | カンバン | ガントチャート | レポート | ドキュメント |
|---|---|---|---|---|---|---|---|
| Jira | スクラムテンプレートがある | × | ○ | ○ | ○ | ○ | × |
| Trello | さまざまな形態のチームマネジメントに使える | ○ | × | ○ | △（タイムラインあり） | × | × |
| Backlog | UIに優れたプロジェクト管理ツール | × | ○ | ○ | ○ | × | ○ |
| Lychee Redmine | オープンソースのRedmineを元に開発されたプロジェクト管理ツール | ○ | ○ | ○ | ○ | ○ | × |
全てを包括しているツールはなさそうでしたが、バックログ管理機能などスクラム特有の機能を持つツールが使いやすいのではないかと思いました。
開発ツール
アジャイルによるソフトウェア開発を行う上では、開発の速さと柔軟性が必要不可欠です。
速く柔軟な開発を実現するためのツールを1つご紹介します。
Adalo
Adaloは、プログラミング不要でアプリを簡単に作成できるノーコード開発プラットフォームです。直感的なUIと豊富なテンプレートを備え、初心者からプロまで幅広く利用されています。アプリ開発プロセスを効率化し、ドラッグ＆ドロップ操作だけでWebやモバイルアプリを構築可能です。
アジャイル開発との相性も良く、迅速なプロトタイプ作成や変更の即時反映が可能なため、短いサイクルでの開発やユーザーからのフィードバックを即座に反映できる環境を提供します。Adaloは、プロジェクトの初期段階から最終リリースまで、アジャイル開発を効果的にサポートするツールとして注目されています。
直感的なUIで使い方がわかりやすいことに加え、ドキュメントも豊富にあるため、ツールの学習コストが非常に低いと感じました。
図：学習コンテンツとしてさまざまな講座も用意されている
私もその学習コンテンツであるハンズオンでアプリを構築する講座を1つ受け、インスタグラムのような投稿アプリを作ってみました。
使用感を一言で言うと、「ワイヤーフレームにデータベースをつけてそのままアプリにできるツール」という感じでしょうか。
FigmaのようにUIをデザインしたり画面遷移を設計したりするだけでなく、それにプラスしてデータベースの定義やデータの受け渡しも設定することで、単なるモックではなくバックエンドもあるアプリとして完成させることができます。
完成したアプリはドメインを取得してサイトに公開できます。
Adaloを使ってみて特に感動したのは、データの設定がとてもやりやすいということです。
まず、データベースの定義を簡単な入力で行うことができます。
データベースを新規作成し、データベースに入れたい属性を名前とその型とともに追加すれば完了です。
データベース間で関連する属性は、そのリレーションを選択して設定できます。
通常はSQLで定義しなければならないこうしたデータベース定義も全てGUIから行うことができます。
また、実装する上で難易度が高いことも多い画面から画面へのデータの受け渡しも簡単に実装することができます。
例えば、インスタグラムのようにポストの一覧画面から選択して詳細画面に遷移する場合、一覧画面で持っている各ポストのデータを詳細画面に渡す必要があります。
この場合も、一覧のクリック操作に紐づけて渡すデータも設定できるのです。
図：Click Actionの中で次の画面に渡すデータを指定できる
こうした便利な機能により、インスタのようなアプリをたった数時間で構築することができました。
大規模な業務アプリ開発には適さないかもしれませんが、アジャイルによる簡単な新規サービス開発などに使用すると良いかもしれません。
まとめ
アジャイルの概要とその中のスクラムの詳細、アジャイル開発で使えるツールをご紹介しました。
一通り調査してみて、アジャイルはフレームワークとして明快であり導入もしやすそうだと感じました。ただ、現状では十分に浸透し成果が出ているとは思えません。それには何か訳があるのではないかと思います。次は、実際のプロジェクトでアジャイルを実践し、その良いところややりにくいところを見つけ、より良い仕組みにするにはどうしたら良いかを考えたいと思います。