スクラム導入には組織の取り組みが必要なことを電車にたとえてわかりやすく説明してみる
スクラムは、アジャイル開発方法論の中でも最も広く知られており、実際に適用されることも多い手法です。しかし、人に依存する面や精神論が強調されてしまい、マネジメント手法としての仕組みについて理解が広まっていないように思います。そこで、スクラムを電車にたとえながら、その仕組みと、メリットや副作用について説明してみます。
Yamanote Line 山手線 | Melvinnnnnnnnnnn (FN2187) | Flickr CC BY-SA 2.0
はじめに
私はエンタープライズ領域でのアジャイル導入に関わり、様々な立場の方にスクラムの説明していますが、その中で、2つの誤解があると思っています。
1つ目は「スクラムは開発部門が取り組むもの」という誤解。スクラムを機能させるには、経営層とビジネス部門と開発部門が協力しなければなりません。
2つ目は「スクラムの成功には、スクラムマスター（SM）やプロダクトオーナー（PO）の人選が最重要だ」という誤解。もちろん、重要なのですが、組織としてスクラムの仕組みが機能しなければ、どんなに優秀な人をアサインしても、その能力が発揮されることはありません。
こうした誤解を解くには、経営層・ビジネス部門・開発部門がスクラムの仕組みを理解し、その上で「この仕組みを機能させるためにはどうするか」を組織として考える必要があります。電車のたとえは、より多くの人にスクラムの仕組みを理解しやすくするために考えたものです。
スクラムを電車にたとえる
こんな電車があるとします。
- 電車は、出発ホームから定期的に出発し、到着ホームまで進む
- 出発ホームには、電車に乗りたい乗客が一列に並んで待っている
- 次の電車に乗れそうな乗客には切符を渡す。ただし、乗車の準備ができていなければ渡さない
- 電車が来ると列に並んでいる順番に切符を持っている人だけを定員まで乗せて、電車は出発する
- 次の電車が来るまで、乗客の並び順は好きに変えていい
これはスクラムの基本的な仕組みであるスプリントとプロダクト＆スプリントバックログの関係を示しています。
電車は定期的に出発する
スクラムでは、定期的にスプリントと呼ばれる短期間の作業が繰り返し実行されます。このスプリントが電車の運行に相当します。
切符を渡す
スプリントの開始前に、プロダクトバックログからスプリント内で実行できそうなタスクを選び、そのタスクがスプリントで作業できる状態（準備完了）になっているかを確認します。要件が曖昧で、すぐに作業着手できないような場合は要件の詳細化が必要なので「準備不足」と判断されます。これが、切符を渡す行為に相当します。もし、電車に乗り込む準備ができていなければ切符は渡しません。
電車に乗る
スプリントが開始されると、選択されたタスク（切符を持っている乗客）がスプリントバックログに移動し、チームはこれらのタスクに取り組みます。これが、乗客が電車に乗ることにあたります。
出発ホームの乗客の並び順を変える
スプリント中にもプロダクトバックログのタスクの優先順位を変更したり、新しいタスクを追加したりすることができます。これが、乗客が次の電車を待つ間に並び順を変えることにあたります。
スクラムのメリット
では、このスクラムの仕組みは、どこが優れているのかについて説明していきます。
なお、比較対象としてウォーターフォール（以下WF）をあげています。この記事では「WFとは、初期にすべての要求を分析し、それを達成するための計画をたて、要件定義→基本設計→実装→テストとフェーズを経ながら進めていくプロセス」を意味します。
出発した電車はホームのことを気にしない
スクラムの仕組みの最も重要なメリットは安全に変化を取り込めることです。これは電車とホームが分離していることに意味があります。
WFでは、最初に定めた要求からはじめ、要件定義→基本設計と詳細化していきます。この「最初の要求」を達成することが目標として作業を進めます。ところが、近年では「最初の要求」の精度が悪くなりがちです。競合の動向や消費者の流行に影響を受けたり、AIなど試行錯誤が求められるケースなど、VUCAな時代になってきています。
WFでは変更管理によって変更を取り入れますが「最初の要求」を基準として管理します。そのため変更量が大きくなると問題になります。作業者は「最初の要求」にあわせて作業を進めているため、変更が多くなるほどオーバーヘッドが増え、無駄が多くなってしまうのです。つまり、WFでの変更管理は、ほぼ確実に開発側の作業に影響を与えます。
一方で、スクラムの場合は要求が常に変更されていくことが前提になっています。そこで「今後やりたいこと」をプロダクトバックログで管理し、「今やるべきこと」はスプリントバックログに移してから管理します。スプリントを開始すると、スプリントバックログの変更はできません。つまり、スプリント中にプロダクトバックログの内容をどんなに変更してもスプリントの作業には全く影響しません。
電車のたとえで説明すると、電車に乗り込んだ乗客は飛び降りることはできませんし、後から誰かが飛び乗ることもできません。一方で、出発した電車は、出発ホームに誰がどう並んでいるのかを気にすることもありません。
このようにタスクリストが「今後やりたいこと（プロダクトバックログ）」と「今やるべきこと（スプリントバックログ）」に分離されていることで、将来の予定に対する変更が、開発作業に影響を与えないようになっているのです。
いつ全員を運び終わるのかが曖昧
逆に言えば、スクラムでは中長期の目標に対する進捗を管理するのが仕組みとして苦手です。全部で50個の機能を作るとして、WFでは、その50個に対する計画を立案し、その目標に対する進捗を可視化するようにします。一方で、スプリントには「目の前の10個ができたかどうか」を明確にすることはできますが、それが「全体の50個に対して、どこまで進んがのか」を示すには向いていません。そもそも、その50個すら増えたり、変わったりするからです。
そのため、スクラムではスプリントとは別の仕組みで中長期の進捗管理をする必要があります。ここでは説明しませんが、一般的にはエピックやリリースバージョンといった概念でタスクをグルーピングし、複数のスプリントをまたがった管理をすることが推奨されます。
スクラムを機能させるために
電車であれば、安定して運行するために以下のような当たり前のルールが存在します。これらはスクラムにも通じます。
- 電車に間に合うのは乗客の責任
- 電車に乗るには切符が必要
電車に間に合うのは乗客の責任
電車は、あらかじめダイヤに記載された時間になると出発ホームにやってきて、その時点で待っている乗客を乗せて出発してしまいます。間に合わなければ、乗ることはできません。電車に乗りたければ、間に合うように来るのが乗客の責任です。
スクラムでも、同じようにスプリントプランニングの時点でプロダクトバックログに記載されていないものは実施しません。作業が足らなくても開発側は作業を開始するので、そのスプリントで実行したいことは、そのスプリントの開始までにプロダクトバックログに記載し、優先順位を決めておく必要があります。
いつスプリントが開始されるかは、将来まで確定しています。常に締切があるので「締切に間に合うためには、いつまでに準備を完了すべきか」がわかりやすいのです。要件の整理には、部署間調整、調査や検討を行うでしょう。こうした要件整理のための作業スケジュールが明確になれば、効率的に準備が行えるようになります。
また、仮に準備が締切に間に合わないとしても、その次の開始タイミングが明確なため、再スケジュールもしやすくなります。もし、優先度が高く、どうしても次のスプリントに間に合うべきなら急いで準備をすればいいですし、逆に、調整を急いで混乱することがわかれば、先の締切にむけて準備スケジュールを調整することができます。
これによって曖昧な要件の押し込みがなくなります。ウォーターフォールでは、リリース後の改修が相当先になってしまうため、「調整しきれていない曖昧な要件だけど、とりあえずいれておこう」ということが発生しがちです。もちろん、基本設計などの後工程で詳細化を行いますが、要件定義は完了しているため「やるべき」ということになっています。しかし、そんな要件は大きな見積もりブレが起きたり、そもそも、作ったけど意味がなかったということになりがちです。
スクラムでは、開発開始タイミングがたくさんあるため、その時点で必要だと思った機能だけを作り続けることができるようになります。
電車に乗るには切符が必要
締切があることで準備が効率的になりますが、注意すべきなのは「準備ができたかどうか」を明確にすることです。
電車に乗るのに切符が必要なように、スクラムにおいてもプロダクトバックログからスプリントバックログへの移動には条件があります。それは、対象タスクの開発をはじめる準備が完了していることです。これは「実施すべき作業への分解が可能で、見積もりができる状態」を意味します。これをチームで明確にするために、準備完了に必要な成果物のフォーマットや、その記載レベルなどを共有するのが良いでしょう。もちろん、対象としているサービスによって具体的な内容は異なるので、各チームでドキュメント化し、共有します。これをDoR（Difinition of Ready/準備の定義）を呼ぶこともあります。
つまり、要件を提示されても、チームが「この部分が曖昧なので見積もりができない。もっと明確にしてほしい」ということがあれば、準備が完了していないことになり、そのスプリントでは実施できません。乗車準備ができていないなら、切符はもらえず、列に並んでいても乗車は断られます。
このやりとりをスプリントプランニング内でやると時間がかかるので、1つ前のスプリントまでにタスクの確認をしておく必要があります。これはリファインメントとよばれる作業で、全員で次のスプリントに向けてタスクの準備が完了しているかを確認します。リファインメントをきちんと実施できていると、スプリントプランニングでの混乱を避けることができます。プロダクトバックログリファインメントというイベント名で呼ばれることが多いです。
補足：切符がなくても電車に乗れるケース
準備が完了していなくても、開発側がアイテムを受け取ることがあります。技術的な実現方法が不明瞭など、開発側の理由によって要件が曖昧になっているケースです。こうした場合は、要件のアイテムとは別に「技術的な調査を行う」というタスクを作り、スプリントバックログに乗せることができます。このタスクは「やってみないとわからない」ことが多いので、見積もりは「とりえず、この期限でやってみよう」というように決めます。
スクラムとは組織が使いこなすもの
こうして振り返ってみると、電車そのものの性能も重要ですが、出発ホームにいる乗客の管理が非常に重要であることがわかります。
電車の性能というのは開発チームの能力といえるでしょう。生産性が高いほど定員も増え、より多くの人を運ぶことができます。また、安定した運行ができれば、それだけ中長期の見通しもしやすくなります。しかし、その電車の安定運行には「乗客の質が良いこと」が前提であることもわかります。
出発ホームにいる乗客の管理とは、プロダクトバックログの管理のことです。スクラムガイドには以下のように記載されてます。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
どうやら、POが出発ホームにいる乗客の管理責任者のようです。ただし、プロダクトバックログの作成は、PO1人でやることではありません。大きな組織であれば、経営層との合意形成やビジネス部門との調整なくしてはうまくいきません。もちろん、開発チームとの調整も必要でしょう。つまり、プロダクトバックログの管理責任は、直接的にはPOが持ちますが、間接的には経営層やビジネス部門、さらには開発部門が持っているといえそうです。
スクラムでもWFでも要件の管理が重要であることは変わりません。ただ、その役割分担は違うように思います。WFでは「要件の詳細化は開発部門が推進し、ビジネス部門が協力する」というような建て付けですが、スクラムの場合は「要件の詳細化はビジネス側が推進し、開発部門が協力する」ようになります。そして、開発をしている横で、次に開発する要件を詳細化する、ということを永遠にやり続けます。
こうしている理由は明確で、変化に対応しながら効率的に開発をするためには、開発行為と要件の詳細化を常に並行して実施する必要があるからです。これを交互にシーケンシャルにしていると無駄です。電車の運転手が出発ホームの乗客の整理を手伝ってはいけないことはないですが、動いていない電車は無駄です。
スクラムに取り組むには役割やスキルの見直しが必要
これまで説明してきた内容を正しく理解できれば、スクラムは「開発部門が効率的にシステム開発を行うための手法」というよりも「組織がビジネスとシステム開発の関係性を管理するための手法」だということが理解できると思います。組織がビジネスの状況に応じて、どんな機能を、いつのタイミングで、どのぐらいの完成度で作り上げるかについての管理能力を高めます。
ただし、スクラムを機能させるためには役割やスキルの見直しが必要です。これがWFでの取り組みが長い組織ほど難しくなります。
悪意のある言い方をすると、ビジネス部門（あるいは企画部門）が「曖昧な要件を投げておけば、開発側が一生懸命に詳細化してくれるので、そのレビューをすればいい」という経験しかないとすると、非常に負荷が高くなったように感じますし、そもそも、要件を詳細化するノウハウを持っていないことがあります。
一方で、開発部門にしても、下請け・請負的な作業しかしてきていないと「これは要件が曖昧だから、もっと明確にしないと作業できません」と言えずに、見積もりはブレ続け、使われない機能が作られることになります。また、成果物にしても、単に機能仕様を満たせばいいといったようなことではなく、継続的に開発を行うことを前提にした保守性や運用性の高いシステム構成に変える必要もでてきます。
さらに双方での作業効率をあげるならば、より、要件が粗くても正しく伝わる状態を目指すべきで、そのためには双方が協力的に取り組み、経験から生まれる学習効果を有効に活用する必要もあります。
スクラムに取り組む場合、ここまで理解した上でPOやSMのアサインを考えて欲しいと思っています。
（アジャイルコーチを雇うことも良いことです。ただし、組織の役割とスキルの見直しがなければ機能しないでしょう）
まとめ
DXを推進し、変化に対応し続けるには、組織としてのビジネスとITの整合性をとれるようになる必要があります。そのためにスクラムは有効な手段です（スクラムだけが有効なわけではないですが）。ただし、スクラムの仕組みは、これまで以上にビジネスがITに寄り、ITがビジネス寄ることを前提にしています。電車のたとえで、この点を理解してもらえばうれしいです。
補足
どこから思いついたのか
スクラムを電車にたとえるのはScaled Agile Framework（SAFe）の「アジャイルリリーストレイン」から着想を得ています。リリーストレインは、複数のチームやコンポーネント間でリリースサイクルの調整が必要な場合に、電車のように定期的なリリースサイクルを前提にすることで継続的な価値提供を行う考え方です。よって、定期的なリリースサイクルを電車にたとえるアイデアは、この記事がオリジナルではありません。
このアイデアに、出発ホームや切符という概念を追加することで、スクラムの仕組みを適切に説明できると考えて執筆したものです。
その他の副作用
これまで上げた以外にも、スクラムには仕組みとしての課題があります。よく知られているのは以下のものでしょう。
- 何を作るか確定しない状態でチームを手配する必要がある（電車を用意しないとダメ）
- 開発リソースの増減に対応しにくい（電車の大きさは簡単に変えられない）
- スプリントプランニングやスプリントレビューなど、実装作業以外のコミュニケーション時間が多い（電車は出発や到着するたびに乗降する）
こうした副作用があるにせよ、継続的に安定して変化を取り入られるというメリットは非常に大きいと思います。
この説明において、抜けていること
当然ですが、電車による説明は完璧ではなく、スクラムの一側面しか表現していません。以下のようなことは抜けているので、注意してください。
- 実際には定員ではなく重量（ストーリーポイント）と積載量（ベロシティ）を考える
- でも、体重や荷物ほど明確に事前測定できるものではない
- 乗客は、必ずしも到着できない（予定した作業が完了しないこともある）
- 電車のダイヤを守ることを前提に、積載量を超える人や荷物は途中で降ろしてしまう
追記
匿名希望さんからフィードバックをいただきました。残念ながら不健全な状況のようですね...
・電車が発車した後でも、走行中に乗客が飛び乗ってくる
・無賃電車もなんのその
・ダイヤ通りの運行と満員電車の両立
今って、こんな感じなのかな
