Intelligent Technology's Technical Blog

株式会社インテリジェントテクノロジーの技術情報ブログです。

スクラムガイドを読む(第1回)

こんにちは、斎藤です。

アジャイル開発やスクラムに関して、日本でも徐々に広まりつつあり、書籍やネットを見ている限りではよく考えられた素晴らしいプロセスフレームワークのように思えます。

しかし、実際に実践したことが無い者にとっては、いざやってみると色々な問題に遭遇してうまくいかないのではないかという不安もあります。

今回は、原点に立ち返ってスクラムを開発した、Ken SchwaberとJeff Sutherlandによって書かれたスクラムガイドを読み、スクラムフレームワークを理解しながらウォータフォール型開発との違いなどについても書いていきたいと思います。


スクラムガイドの日本語版はここにあります。

スクラムというものがどういうものかを理解したいのであれば、上記のスクラムガイドを読んで頂く方が短時間で早いと思います。

この記事ではスクラムガイドの全文を引用していますが、輪読のようなつもりで読んで頂ければ幸いです。

まず始めに、スクラムはKenSchwaberとJeffSutherlandによって開発されたものですが、スクラムという考え方・用語を最初に論文として発表したのは、日本人の竹内弘高さんと野中郁次郎さんです。日本生まれ、アメリカ育ちの開発フレームワークということになります。

スクラムの原典を読み解くスクラムの元となった論文と現在のスクラムとの比較記事を平鍋さんが書かれており、1986年に発表された論文「The New New Product Development Games」を参考にして現在のスクラムが1993年に作られたという話は興味深いです。

1993年というと今から21年も前のことで、私はまだ30代前半で「XPエクストリーム・プログラミング」でペアプログラミングというものが提唱されていたのを思い出します。その頃は、ずいぶん変わった開発方法だなと感じていました。その後、日本では流行ることなく、次第にウォータフォール型の開発方法が主流になってしまいました。その間、アメリカを始めとしてアジャイル開発は着実に広まって行き、いつのまにか日本は取り残されてしまったというのは、非常に残念なことです。

長くなるため、2回に分けて書いていきます。
「スクラムガイドを読む(第2回)」はこちらです。

第1回目は、スクラムガイドの下記の内容に関して書いていきます。

スクラムガイドの目的
スクラムの概要
 スクラムフレームワーク
スクラムの理論
スクラム
 スクラムチーム
 プロダクトオーナー
 開発チーム
 スクラムマスター

それでは、「スクラムガイド」を読み進めていきましょう。

スクラムガイドの目的

スクラムは、複雑なプロダクトを開発・維持するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割、イベント、成果物、そして、それらをまとめるルールが含まれる。スクラムは、KenSchwaberとJeffSutherlandによって開発されたものである。スクラムガイドは、この両者が共に執筆・提供・支援する。

スクラムの概要

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。スクラムとは、次のようなものである。

  • 軽量
  • 理解が容易
  • 習得は非常に困難

この「習得は非常に困難」というのが、非常に気になります。
頭で理解するのは容易であるが、いざやってみると大変でうまくいかないのではないかと。
認定スクラムマスター研修というのがあり、実践する前に受けてみたい気もしますが、やはり実践から学ぶというのが最も早く習得する方法ではないかと思います。
アジャイルサムライ読書会などのコミュニティに参加して、ディスカッションおよびワークショップを通してアジャイル開発を体験していくのも良さそうです。

スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることのできるフレームワークである。プロダクト管理や開発プラクティスの相対的効果を明確にすることで、改善を可能にするのである。

アジャイルスクラムではプロダクト開発という言い方をするため、製品開発にしか向かない開発手法ではないかと思われがちですが、普通のアプリケーション開発にも適用できると思っています。
実際に海外のアプリケーション開発では、ウォータフォールよりもアジャイル開発の方が主流になっている国も多いです。

下記のIPAのサイトでは、各国におけるアジャイルの普及状況や日本でアジャイル開発が進まない原因などについて調査・分析されています。
IPAのアジャイル開発に関する調査報告書

スクラムフレームワーク

スクラムフレームワークは、スクラムチームとその役割・イベント・成果物・ルールで構成される。それぞれに目的があり、スクラムの利用や成功に欠かせないものである。
スクラムフレームワークを使用する戦略にはさまざまなものがあり、それらについては別のところで記述するものとする。
スクラムのルールは、役割・イベント・成果物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体を通して説明する。

アジャイルというと、継続的インテグレーションのCIツール(Jenkins等)やプラクティスと呼ばれる下記のような活動が有名ですが、スクラムでは役割・イベント・成果物・ルールに関してのみ規定していて、具体的なプラクティスまではあまり触れておらず、プロジェクトの進め方を中心に規定しています。

アジャイルのプラクティスの主なもの

スクラムの理論

スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。

経験主義というのがスクラムの基本的な考え方になっています。
アジャイルの見積り方法として有名なポーカプランニングでは抽象的なポイントとして求めますが、実際の工数を求める際にはチームの直近のベロシティ(生産性)から予測するというのも経験主義に基づいたやり方です。
「反復的で漸進的な手法」は継続的インテグレーション(CI:Continuous Integration)に良く表れています。
従来からある、PDCAサイクル(Plan Do Check Action)とも通じるところがあります。

  • 透明性:Doの結果が見える化により共有され
  • 検査:Checkして
  • 適応:Actionで改善していく

透明性

経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、この点が標準化され、関係者全員が共通理解を持つことである。
例:

  • プロセスを指す用語が、関係者全員で共有されていなければならない。
  • 「完了(Done)」の定義が、作業をする人と成果物を受け取る人で共有されていなければならない。

見える化」は最近良く聞く言葉ですが、英語ではなんて表現されているんだろうと思い、英語版スクラムガイドの原著の方を見てみたところ、

Significant aspects of the process must be visible to those responsible for the outcome.

単純にvisibleの略なんですね。

検査

スクラムでは、好ましくない変化を検知できるように、成果物や進捗がゴールに向かっているかを頻繁に検査しなければならない。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行うことで、検査は最大の効果をもたらすものである。

アジャイルスクラムで誤解されていることのひとつとして、勝手に好きなように開発するだけと思っている人がいるかもしれません。そういう人にとっては「頻繁に検査しなければならない」というのは意外かもしれません。しかし、「検査を頻繁にやりすぎて作業の妨げになってはいけない」というのも重要で、大規模開発プロジェクトで最近良く取り入れられているPMOが、頻繁にチェックをやり過ぎて開発作業の妨げになっていることも多々あることへの警鐘としても受け止めたいと思います。

適応

プロセスに不備があり、成果物であるプロダクトを受け入れられないと検査人が判断した場合、プロセスやその構成要素を調整しなければならない。調整はできるだけ早く行い、これ以上の逸脱を防がなければならない。
スクラムでは、検査と適応を行う4つの機会を公式に設けている。詳しくは、「スクラムイベント」の節で説明する。

  • スプリント計画ミーティング
  • デイリースクラム
  • スプリントレビュー
  • スプリントレトロスペクティブ

スクラム

スクラムは、複雑なプロダクト開発を支援するためのフレームワークである。スクラムは、スクラムチームとその役割・イベント・成果物・ルールで構成される。それぞれに目的があり、スクラムの利用や成功に欠かせないものである。
スクラムのルールは、役割・イベント・成果物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体を通して説明する。

スクラムチーム

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。

スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完了」したプロダクトを漸進的に届けることで、動作するプロダクトが常に利用可能な状態にしている。

「反復的・漸進的に届ける」というやり方も、アジャイルスクラムの大きな特徴のひとつで、スプリントを繰り返しながら開発し、スプリント毎にリリース(実際には内部リリース)していきます。
「フィードバックの機会を最大化」とは、リリースしたものを実際のエンドユーザに触ってもらい、改善点や要望のフィードバックを受けたり、スプリントレトロスペクティブ(ふりかえり)により、自分たちで進め方の改善点を見いだしていく活動に繋がっています。

プロダクトオーナー

プロダクトオーナーは、プロダクトの価値と開発チームの作業を最大化することに責任を持つ。その作業は、組織・スクラムチーム・個人によって、大きく異なる。

プロダクトオーナーは、プロダクトバックログの管理に責任を持つ唯一の人物である。プロダクトバックログの管理には、次のようなものがある。

  • プロダクトバックログの項目を明確に表現する。
  • ゴールとミッションを達成できるようにプロダクトバックログの項目を並び替える。
  • 開発チームが行う作業の価値を保証する。
  • 全員にプロダクトバックログ見える化・透明化・明確化し、スクラムチームに次の作業を伝える。
  • プロダクトバックログの項目を開発チームが理解できるようにする。上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。

プロダクトオーナーは1人の人間であり、委員会であってはならない。委員会の要求をプロダクトオーナーがプロダクトバックログに反映することもできるが、優先度を変えるにはプロダクトオーナーが納得しなければならない。

プロダクトオーナーが成功するには、組織全体でプロダクトオーナーの意見を尊重しなければならない。プロダクトオーナーの決定は、プロダクトバックログの内容や順番付けという形で見える化されている。開発チームの作業に依頼できるのは、プロダクトオーナーだけである。また、開発チームもその他からの作業依頼を受け付けてはいけない。

プロダクトオーナは従来でいうところのPM・PLの役割と責任を持った人に近いと思います。
では、スクラムマスターは何に相当するかと言えば、PMOの役割と責任を持った人に相当すると思われます。
プロダクトオーナーをプロジェクトリーダ、スクラムマスターをPMOと読み替えてみると、なんとなくうなずけます。

開発チーム

開発チームは、リリース判断可能な「完了」したプロダクトのインクリメントを、各スプリントの終わりに届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバだけである。
開発チームは、自らの作業を構成・管理するものであり、そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。開発チームには、次のような特徴がある。

  • 自己組織化されている。プロダクトバックログをリリース判断可能なインクリメントに変える方法は、誰も(スクラムマスターでさえも)教えてくれない。
  • 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
  • ある人にしかできない作業があったとしても、メンバの肩書きは開発者だけである。このルールに例外はない。
  • メンバに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。
  • テストやビジネス分析などに特化したサブチームは存在しない。

開発チームが自己組織化されており、機能横断的なのがスクラムの特徴です。

従来の開発プロセスでは、プロジェクトリーダがトップダウン的に指示を出し開発メンバーはそれに従うという体制ですが、スクラムでは「チーム外からの指示ではなく、自らが選択する。」というところが、大きく違うところです。受け身や指示待ちではだめだと良く言われますが、それを実践しているのがスクラムというものでしょう。

開発チームの規模

開発チームに最適な人数は、小回りが利く程度に少なく、重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、チームの規模が小さいと、スキル不足が原因で出荷判断可能なインクリメントをスプリントで届けられない可能性もでてくる。メンバが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと、経験的プロセスの管理が複雑になってしまう。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数には含まれない。

開発チームは3人から9人が最適な人数ということです。
確かに、この位の人数がプロジェクトの規模としてちょうど良いという感じがします。
それ以上の規模のプロジェクトの場合はどうするのかというと、開発するシステムをサブシステムや機能で分割し、複数スクラムチームが並行して開発を進めるということでしょう。開発チーム間でのコミュニケーションが大量に発生しないように、うまく分割することが実際の開発では重要になると思われます。
複数スクラムチームの事をScrum of Scrumと呼びます。

スクラムマスター

スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。スクラムマスターは、スクラムチームのサーバントリーダー(訳注:メンバが成果を上げるために支援や奉仕をするリーダーのこと)である。
スクラムマスターは、スクラムチームとのやり取りで役に立つこと/立たないことをスクラムチームの外部の人たちに理解してもらうようにする。スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。

スクラムマスターの役割と責任はPMOのようなものだと書きましたが、PMOはプロジェクトを管理するという意味合いが強いのに対して、スクラムマスターはサーバントリーダ(支援や奉仕をするリーダ)としているところがこれまでのプロジェクトマネージメントとは異なるところです。
役に立たない事を妨害リストとも呼ぶらしいですが、それを外部の人達に理解してもらうようにするのも大切な役割です。
スクラムを実践した事が無い場合、周りの人からもほんとにうまくいくのかと思われているため、これが一番結構大変な仕事であることは想像に固くありません。

プロダクトオーナーの支援

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。

  • 効果的なプロダクトバックログの管理方法を探す。
  • ビジョン・ゴール・プロダクトバックログの項目を明確に開発チームに伝える。
  • 明確で簡潔なプロダクトバックログの項目の作成方法を開発チームに教える。
  • 経験主義における長期のプロダクト計画について理解する。
  • アジャイルを理解・実践する。
  • 要望・必要に応じてスクラムイベントをファシリテートする。

開発チームの支援

スクラムマスターは、さまざまな形で開発チームを支援する。

  • 自己組織化・機能横断的な開発チームをコーチする。
  • 高価値のプロダクトを作る方法を開発チームに教育・指導する。
  • 開発チームの進捗を妨げるものを排除する。
  • 要望・必要に応じてスクラムイベントをファシリテートする。
  • スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。

組織の支援

スクラムマスターは、さまざまな形で組織を支援する。

  • スクラムの導入を指導・コーチする。
  • 組織にあったスクラムの推進方法を計画する。
  • スクラムと経験的プロダクト開発を従業員や関係者に理解・実施してもらう。
  • スクラムチームの生産性を高めるような変化を促す。
  • 他のスクラムマスターと一緒に組織へのスクラム導入の効果を高める。

スクラムマスターはあくまで支援するのであって、指示したり管理するのではありません。
プロジェクトリーダとは別の役割を持っているのです。
スクラムの考え方の中心は開発チームが主役で、そのチームが自ら考え行動できるようにスクラムマスターがサポートしてあげることに最大の役割があります。
現実にはプロダクトオーナ、スクラムマスタ、開発チームメンバーのいずれかを兼任する場合もあるのでしょうが、開発チームメンバーとプロダクトオーナやスクラムマスターは兼任しても良いが、プロダクトオーナとスクラムマスターは兼任してはいけないそうです。

「スクラムガイドを読む(第2回)」はこちらです。