アジャイル スクラム

スクラムとは何か?現状を把握するフレームワーク|19個の要素に分解

スクラム アジャイル
この記事は約8分で読めます。

純粋なスクラムを理解したい場合にはCore Scrumスクラムガイドを読むことをおすすめします。両者は用語や表現に微妙な差異がありますが、両方を読むことで幅が広がります。

現時点(2020年3月)でCore Scrumは2014年、スクラムガイドは2017年に更新されています。

アジャイル宣言は2001年から止まっていますね。

本記事ではもっとさらりとスクラムを説明します。

代表的なアジャイル開発手法

スクラムはアジャイルの手法のひとつであるため、先にアジャイルを理解します。

アジャイル宣言の4つの価値を覚えていらっしゃいますでしょうか。

  • 個人との対話
  • 動くソフトウェア
  • 顧客との協調
  • 変化への対応

これらの価値観を胸に、俊敏にカイゼンし続けている状態がアジャイル(Be Agile)です。

※ Be Agile rather than Do Agile.

ただ、アジャイルの原理原則だけでは、なにをどうすればいいのか分かりません。

アジャイルを実践するためのHowについて、数々のアジャイル開発手法(方法論)が生み出され、その中で最も普及が進んでいるのがスクラムです。

流行っているからスクラムが優れている、というわけではなく、それぞれに適した開発手法を選べばよいと思います。

※スクラムと並んで有名なXP(エクストリーム・プログラミング)については別記事にします。

スクラムとはなにか

アジャイルになるために現状を把握するためのフレームワークです。

(生産性があがったり、楽しくなるものでもない、とのことです。)

フレームワーク(骨組み)ですから、中身はみなさんが埋めることになります。

ちなみに、Java、PHP、Javascript、Ruby、C#などの様々なプログラム言語にもフレームワークというものがあります。それらをただ使っている、だけでは意味がありません。

フレームワークが何を背景として作られているかを理解し、正しく運用することで初めて本来の価値を発揮できます。

せっかくフレームワークを導入しているのに重複したコードが点在していたり、ルールに則っていないソースコードを見てガッカリした経験はありませんか。

スクラムも同じです。

スクラムの背景を理解して、正しく運用し、アジャイルにカイゼンし続けている状態になれていたら、自分たちのチームはスクラムになっている、と胸をはれます。

そして、カイゼンし続けることがアジャイルであるため、スクラムというフレームワークが足かせ、ボトルネック、上限になってもいけないと考えています。時には枠からはみ出したり、変えたり、増やしたり、減らしたりも試す価値があります。あくまで、スクラムという手段が目的にならないように。

スクラムにおける19個の要素

スクラムには19個の要素があります。

  1. 透明性
  2. 検査
  3. 適応
  4. スプリントプランニング(スプリント計画)
  5. デイリースクラム
  6. プロダクトバックログリファインメント(リファインメント)
  7. スプリントレビュー
  8. スプリントレトロスペクティブ(レトロ、振り返り)
  9. プロダクトオーナー(PO)
  10. 開発チーム
  11. スクラムマスター
  12. プロダクトバックログ
  13. 受け入れ条件(Acceptance Criteria)
  14. 完了の定義(Doneの定義)
  15. スプリントバックログ
  16. スプリント:1〜4週間単位をタイムボックスとするイテレーション開発
  17. 潜在的リリース可能なプロダクトインクリメント(Potentially Shippable Product Increment)
  18. インペディメント(障害)リスト:スクラムチームに対する阻害要因の一覧
  19. スプリント中止(スプリントストップ)

極端に言いますと、上記以外のものはスクラムでは定義されていません。

例えば、ベロシティ、バーンダウンチャート、かんばんボード、インセプションデッキはスクラムで定義されていません。また、テスト駆動開発(TDD)、ペア・プログラミング、ユーザーストーリー、リファクタリング、持続可能な開発などはXP(エクストリーム・プログラミング)のプラクティスとなります。

ただ、実際のスクラムチームは必要に応じて他のアジャイルプラクティスを適用することが多いです。

それも、単に流行っているから、隣のチームがやっているから、過去のプロジェクトでやっていたから、といった理由で導入するのではなく、アジャイルであるために必要かどうか、という視点で判断します。

スクラムの役割(ロール)

スクラムにおいての役割は3つのみ定義されています。

  • 開発チーム:6〜9名
  • プロダクトオーナー:1名
  • スクラムマスター:1名

プロダクトオーナーはひとりしかおりませんので、開発チームと一緒になって要求分析をします。

(要求分析はウォーターフォール開発の要件定義に近いです。ただ、要件という言葉は作るものを定義する、変えられないもの、というニュアンスがあるため、アジャイルではユーザーやビジネスの価値を表す可変な要求という言葉を好みます。)

ひとりのプロダクトオーナーに仮説検証、要求分析、プロダクトバックログ作成などの、何を作るか?というところを任せようとする場合がありますが、それは無理があります。

なんでもやってくれるプロダクトオーナーは都合の良い概念でしかありません。

稀に神様のようなプロダクトオーナーがいるかもしれませんが、多くはプロダクト開発以外の仕事を持っていたり、まだ経験が浅かったり、求められるスキルに及ばなかったり、そもそも物量が多すぎたりします。

そして、ひとりに任せてしまうと、ひとりのプロダクトオーナーの視座がプロダクトの上限になってしまいます。

よって、プロダクトオーナーの民主化が必要で、開発チームと一緒にやる、もしくはプロダクトオーナーチームをつくる、というのも手段のひとつでしょう。

また、プロダクトオーナーはプロダクトバックログの優先順位をROI(投資対効果)に従って決定します。

得られる価値が高い、という視点だけでなく、大きなリスクを回避できるもの、問題を解決できるものも、そして開発の優先順位によるコストの増減、実際にリリースをする単位などを考慮して、プロダクトバックログに優先順位をつけて並べます。

重要度順ではなく、ROIを考慮した優先順位です。

「優先度」も英語では「priority」ではありますが、ここでは明確に「優先順位」という言葉を使います。

「優先度 高」「優先度 A」というものが並んだら、結局、何から手をつけて良いか分からなくなるからです。

ちなみに、役割は対等でありフラット(階層構造ではない)です。プロダクトオーナーが偉いとかありません。スクラムマスターがプロジェクトマネージャーというわけでもありません。

(スクラムではプロジェクトマネージャーという役割は定義されておりませんが、ソフトウェア開発は例外なくプロジェクトであるため、プロジェクトマネジメントは必須です。プロジェクトマネジメントをスクラムチームができるならそれでいいですし、難しいのであれば、別途、プロジェクトマネージャーを立てる必要があります。)

スクラムマスターはスクラムがうまく回るようにスクラムのイベントや、開発時にファシリテートしますが、プロダクトオーナーや開発チームに対するコーチングも行います。

スクラムマスターは自分がいなくてもスクラムが回るように、開発チームが自己組織化していくことを促しますが、スクラムを健全に回すことはとてもとても難しいです。

真にアジャイルなスクラムにしていくためには、組織が阻害要因となることが多いです。そのため、スクラムマスターは組織の変革者としての役割も担います。つまに、インペディメント(障害物)リストの問題解決をしていくことになります。

開発チームには、よくある、プログラマー、システムエンジニア、デザイナー、テスター、DBエンジニア、データサイエンティスト、アーキテクチャ、運用担当などの役割(職業)は定義されていません。

もちろん、上記の役割(職業)や専門性が不要なわけでもありません。

重要なことは、開発チーム全体が価値のあるプロダクトを作り出すことに責任を持つということです。

自分の得意とする専門性の殻に閉じこもるのではなく、どうすればよりよいプロダクトを作り出せるかをプロダクトオーナーと一緒に考えます。

ただ、ものを作ればいい、ではないのです。

スクラムの三本の柱(3つの原則)

チームやプロダクトのゴール、あるべき姿、構想があることが前提となります。

  • 「透明性」とは、スクラムチームが何かを見たら瞬時に次にすべきことが分かる状態
  • 「検査」とは、ゴールと現実とのギャップを定期的に把握している状態
  • 「適応」とは、ゴールと現実とのギャップを埋めるための行動を起こし続けている状態

透明性は見える化、可視化と表現することもできます。ただ、求められているものはスピード感であり、見に行けばある、加工すれば分かるというものではなく、生の情報で瞬時に理解でき行動できるという状態です。もちろん、その情報の確からしさも重要です。誤った情報によるロスコストは計り知れません。

アジャイル宣言では「計画より変化への対応」とありますが、計画は必要です。ただ、綿密で絶対的な計画ではなく、構想・変化しうる目標です。その目標があることでチームの方向性が定まります。また、変化しうるものであるため、定期的な計画づくりが重要です。

その目指すべきゴールと現実とのギャップを検査して把握することが重要です。なんらかの変化や問題があるはずです。

そして検査した結果で現実とのギャップがあることが分かったら、ゴールに近づくための行動を起こします。これを継続することが大事です。いま取り組んでいることを変えるだけでなく、ゴール・構想自体を変えることもあるでしょう。

常に見える化し、常に検査し、常に適応する状態を維持できたら、、、理想的ですね!

これを実践できたらプロジェクトはほぼ失敗しないでしょう。

近くの人にスクラムを説明してみましょう

ここまで読んでくださった方はなんとなくスクラムが何なのかを分かってきたのではないでしょうか。

そのくらいの知識で近くの人にスクラムが何であるか説明してみましょう。

言葉に出して人に聞いてもらうことで、より深く理解できたり、分からないことが明らかになってくると思います。知ったかぶりでも、なんちゃってでも、手がふるえても、顔を真っ赤にしても、照れながらでもよいのでアウトプットすることが大事です。

Core Scrum (コアスクラム) の日本語訳|スクラムガイドとどちらが原典?アジャイル開発で最も普及している手法 l 2014年版
スクラムでは「スクラムガイド」が有名ですが、Scrum AllianceによるとCore Scrum(コアスクラム)が原典のようです。このCore Scrumを理解して守っていればスクラムと言えます。スクラムは「現状を把握する(見...