これを書こうと思った理由
あるアジャイル（スクラム）のプロジェクトに関わったのだが深夜までの残業・休日出勤が何度もあるような大炎上だった。自分は開発者としてこの炎上プロジェクトに関わったのだが、本当にこのやり方でいいのか？と疑問に思うことが多々あった。そこで何が悪かったのか振り返りながらアジャイル開発（スクラム）の進め方を自衛のためにも勉強したいと思った。
アジャイル開発はきちんと理解されているか
アジャイルというのは（身の回りで言えば）意外と失敗事例は多いように感じる1。完全な失敗ではなくても一部のメンバーが毎日深夜まで残業してなんとかリリースまで漕ぎ着けた、みたいな状態のプロジェクトが多い印象。でも、そもそもこれはアジャイル開発という手法のせいではなくアジャイル開発をよく知らないで進めているせいなのではないか。つまりアジャイル開発への無理解が原因で開発者の負担が高くなってしまうのではないか、と思った。
なぜ残業する必要があったか
思いつく限り挙げると以下の通り。
- 仕様変更があった（アジャイルは仕様変更に強いはずでは…。）
- 開発中にバグが見つかった
- 開発を進めるうちに本来考慮してないといけないのに未考慮だった機能がみつかった。
- 似た機能間でデザインが統一されてない、仕様変更の影響範囲として想定されていない箇所に影響がでているとか。
アジャイル、スクラムとは何かを理解する
従来型開発では、Scope（要件）が固定だったのに対して、アジャイルではTimeとCostが固定になる2。例えば１週間と５人で何をつくれるか、というのを考えるのがアジャイルだ。しかし、スクラムには定められた技法はない。でも大雑把に言えば、市場の動向に合わせて仕様を変える必要がある等、仕様変更の予想されるプロジェクトに対して（軽量な）仕事を繰り返しかつインクリメンタルに行い要求を達成することで仕様変更に対応しつつ、要求されたものをチームの能力を最大化することに集中してつくるらしい3。
また、定められた技法がないとはいえ、以下が有効だとされる3。
- テスト駆動開発
- 受け入れテスト駆動開発
- リファクタリング
- 継続的インテグレーション
バックログ
スクラムで開発する場合、まずバックログを作る必要がある。「プロダクトバックログ」は機能や技術的改善要素を優先順位を付けて記述したもの。プロダクトバックログには「ユーザーストーリー」形式がよく用いられる。
このプロダクトバックログからチームのスプリント期間に実行するべきタスクを抜き出したものが「スプリント・バックログ」になる。言い換えれば、プロダクトバックログを管理可能な単位に細分化したものが「スプリント・バックログ」で、このスプリント期間4内にタスクで指定されたコーディング/テスト/ドキュメンテーションを完了させなければいけない。
スクラムの工程
スクラムの工程は
- 「計画ミーティング」
- 「製品基準の調整・レビュー・配布」
- 「スプリント」
- 「スプリントレビュー」
- 「振り返り」
- 「クロージャ」
からなる3。このうち「計画ミーティング」、「スプリント」、「スプリントレビュー」、「振り返り」を繰り返す。また、スプリント期間中には、「デイリースクラム」といって、毎日15分間「昨日何を完成させたか」「今日何を完成させるか」「何か障害または障害の予兆があるか」を開発者間で話し合う。
計画ミーティングではスプリントの最終的に目指すものについて合意するが、スプリント期間中にプロダクトオーナーが「その最終目標はやっぱり嫌」となった場合にはスプリントを中止することもありうる。中止後には中止された理由をレビューしつつ、新たなスプリントの計画ミーティングを行う。
それ以外の工程の内容は、名前からなんとなく想像がつくと思うので割愛。
メンバー
以下、スクラムに登場するメンバー3。
- チーム
開発者のチーム。通常５〜９人。 - プロダクトオーナー
顧客の意思の代表と成る製品の責任者。顧客の要望（ユーザーストーリー）をプロダクトバックログに優先順位を付けて反映させる。 - スクラムマスター
スクラムフレームワークが正しく適用されていることを保証する役割。プロジェクトそのものを管理するわけではない。
結局なにが理由で失敗したのか
アジャイル・スプリントとは何かを（ウィキペディアで）振り返った上で#なぜ残業する必要があったかのような事態が発生した理由を考えてみると、たぶん以下が原因じゃないかと思った。
- 自動テストを取り入れなかった
- テスト駆動開発や継続的インテグレーションを行うには自動テストを取り入れるべきだったのに、テストは**100%**手作業で行い、エビデンスを取る昔ながらの方法だった。またリファクタリングも全く行わなかった。そのため十分なテストやインスペクションを行う時間が取れず、結果的にバグや未考慮部分への対応が遅れの原因の一因になった。
- プロダクトバックログの細分化が不十分だった
- バックログというシステムを取り入れはしたものの、作った課題の優先度はすべて高〜緊急で、タスクの細分化はほぼしなかった。「優先度」を形骸化させずにきちんとタスクごとに設定するべきだった。また、タスクの粒度に関しても、例えば「掲示板機能」というタスクをひとつだけ作るのではなく、掲示板機能の実装に必要なタスクを細分化してスプリント・バックログ内に管理すべきだった。これらを全くしなかったのでスケジュールの把握・調整ができなかった。
- メンバーにアジャイルの経験があまりなかった。
- そのため「ん？このやり方で本当に大丈夫？」と疑問を出す人がいても、経験がないから正解がわからなかった。開発の経験すらあまりないという人もいた。結果的に「とりあえず手探りで進めてみて、駄目なら残業でなんとかする」という空気になってしまった。
まとめ
「よくわからないけどなんとなくアジャイルで手探りで進めてみよう」だと失敗すると思います。
脚注
1 ちょっと古いですがこの辺の資料もアジャイル失敗の具体例かもしれません。
・(2008年7月)「アジャイル開発における失敗事例」
・(2013年3月)「アジャイルがダメだと思う7つの理由」
・(2017年9月)「なぜアジャイル開発の導入は失敗するのか」
2 アジャイルとは何か？今あらためて誤魔化さずに実践的に説明してみる
3 以下のウィキペディアを参考にしました。
・wikipedia スクラム
・wikipedia Scrum
4 wikipedia Scrumによると、スプリントは通常１週間〜４週間の範囲で行うが、一般的なのは２週間らしい。