こんにちは、斎藤です。
アジャイル開発やスクラムに関して、日本でも徐々に広まりつつあり、書籍やネットを見ている限りではよく考えられた素晴らしいプロセスフレームワークのように思えます。
しかし、実際に実践したことが無い者にとっては、いざやってみると色々な問題に遭遇してうまくいかないのではないかという不安もあります。
今回は、原点に立ち返ってスクラムを開発した、Ken SchwaberとJeff Sutherlandによって書かれたスクラムガイドを読み、スクラムのフレームワークを理解しながらウォータフォール型開発との違いなどについても書いていきたいと思います。
スクラムガイドの日本語版はここにあります。
スクラムというものがどういうものかを理解したいのであれば、上記のスクラムガイドを読んで頂く方が短時間で早いと思います。
この記事ではスクラムガイドの全文を引用していますが、輪読のようなつもりで読んで頂ければ幸いです。
まず始めに、スクラムはKenSchwaberとJeffSutherlandによって開発されたものですが、スクラムという考え方・用語を最初に論文として発表したのは、日本人の竹内弘高さんと野中郁次郎さんです。日本生まれ、アメリカ育ちの開発フレームワークということになります。
スクラムの原典を読み解くでスクラムの元となった論文と現在のスクラムとの比較記事を平鍋さんが書かれており、1986年に発表された論文「The New New Product Development Games」を参考にして現在のスクラムが1993年に作られたという話は興味深いです。
1993年というと今から21年も前のことで、私はまだ30代前半で「XPエクストリーム・プログラミング」でペアプログラミングというものが提唱されていたのを思い出します。その頃は、ずいぶん変わった開発方法だなと感じていました。その後、日本では流行ることなく、次第にウォータフォール型の開発方法が主流になってしまいました。その間、アメリカを始めとしてアジャイル開発は着実に広まって行き、いつのまにか日本は取り残されてしまったというのは、非常に残念なことです。
長くなるため、2回に分けて書いていきます。
「スクラムガイドを読む(第2回)」はこちらです。
第1回目は、スクラムガイドの下記の内容に関して書いていきます。
スクラムガイドの目的
スクラムの概要
スクラムフレームワーク
スクラムの理論
スクラム
スクラムチーム
プロダクトオーナー
開発チーム
スクラムマスター
それでは、「スクラムガイド」を読み進めていきましょう。
この「習得は非常に困難」というのが、非常に気になります。
頭で理解するのは容易であるが、いざやってみると大変でうまくいかないのではないかと。
認定スクラムマスター研修というのがあり、実践する前に受けてみたい気もしますが、やはり実践から学ぶというのが最も早く習得する方法ではないかと思います。
アジャイルサムライ読書会などのコミュニティに参加して、ディスカッションおよびワークショップを通してアジャイル開発を体験していくのも良さそうです。
スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることのできるフレームワークである。プロダクト管理や開発プラクティスの相対的効果を明確にすることで、改善を可能にするのである。
アジャイルやスクラムではプロダクト開発という言い方をするため、製品開発にしか向かない開発手法ではないかと思われがちですが、普通のアプリケーション開発にも適用できると思っています。
実際に海外のアプリケーション開発では、ウォータフォールよりもアジャイル開発の方が主流になっている国も多いです。
下記のIPAのサイトでは、各国におけるアジャイルの普及状況や日本でアジャイル開発が進まない原因などについて調査・分析されています。
IPAのアジャイル開発に関する調査報告書
アジャイルというと、継続的インテグレーションのCIツール(Jenkins等)やプラクティスと呼ばれる下記のような活動が有名ですが、スクラムでは役割・イベント・成果物・ルールに関してのみ規定していて、具体的なプラクティスまではあまり触れておらず、プロジェクトの進め方を中心に規定しています。
アジャイルのプラクティスの主なもの
- ユーザストーリ
- プランニングポーカー
- スタンドアップミーティング
- レトロスペクティブ
- タスクかんばん
- バーンダウンチャート
- ペアプログラミング
- テスト駆動開発
- リファクタリング
- 継続的インテグレーション
経験主義というのがスクラムの基本的な考え方になっています。
アジャイルの見積り方法として有名なポーカプランニングでは抽象的なポイントとして求めますが、実際の工数を求める際にはチームの直近のベロシティ(生産性)から予測するというのも経験主義に基づいたやり方です。
「反復的で漸進的な手法」は継続的インテグレーション(CI:Continuous Integration)に良く表れています。
従来からある、PDCAサイクル(Plan Do Check Action)とも通じるところがあります。
- 透明性:Doの結果が見える化により共有され
- 検査:Checkして
- 適応:Actionで改善していく
「見える化」は最近良く聞く言葉ですが、英語ではなんて表現されているんだろうと思い、英語版のスクラムガイドの原著の方を見てみたところ、
Significant aspects of the process must be visible to those responsible for the outcome.
単純にvisibleの略なんですね。
検査
スクラムでは、好ましくない変化を検知できるように、成果物や進捗がゴールに向かっているかを頻繁に検査しなければならない。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行うことで、検査は最大の効果をもたらすものである。
アジャイルやスクラムで誤解されていることのひとつとして、勝手に好きなように開発するだけと思っている人がいるかもしれません。そういう人にとっては「頻繁に検査しなければならない」というのは意外かもしれません。しかし、「検査を頻繁にやりすぎて作業の妨げになってはいけない」というのも重要で、大規模開発プロジェクトで最近良く取り入れられているPMOが、頻繁にチェックをやり過ぎて開発作業の妨げになっていることも多々あることへの警鐘としても受け止めたいと思います。
スクラム
スクラムは、複雑なプロダクト開発を支援するためのフレームワークである。スクラムは、スクラムチームとその役割・イベント・成果物・ルールで構成される。それぞれに目的があり、スクラムの利用や成功に欠かせないものである。
スクラムのルールは、役割・イベント・成果物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体を通して説明する。スクラムチーム
スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。
スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完了」したプロダクトを漸進的に届けることで、動作するプロダクトが常に利用可能な状態にしている。
「反復的・漸進的に届ける」というやり方も、アジャイルやスクラムの大きな特徴のひとつで、スプリントを繰り返しながら開発し、スプリント毎にリリース(実際には内部リリース)していきます。
「フィードバックの機会を最大化」とは、リリースしたものを実際のエンドユーザに触ってもらい、改善点や要望のフィードバックを受けたり、スプリントレトロスペクティブ(ふりかえり)により、自分たちで進め方の改善点を見いだしていく活動に繋がっています。
プロダクトオーナー
プロダクトオーナーは、プロダクトの価値と開発チームの作業を最大化することに責任を持つ。その作業は、組織・スクラムチーム・個人によって、大きく異なる。
プロダクトオーナーは、プロダクトバックログの管理に責任を持つ唯一の人物である。プロダクトバックログの管理には、次のようなものがある。
- プロダクトバックログの項目を明確に表現する。
- ゴールとミッションを達成できるようにプロダクトバックログの項目を並び替える。
- 開発チームが行う作業の価値を保証する。
- 全員にプロダクトバックログを見える化・透明化・明確化し、スクラムチームに次の作業を伝える。
- プロダクトバックログの項目を開発チームが理解できるようにする。上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
プロダクトオーナーは1人の人間であり、委員会であってはならない。委員会の要求をプロダクトオーナーがプロダクトバックログに反映することもできるが、優先度を変えるにはプロダクトオーナーが納得しなければならない。
プロダクトオーナーが成功するには、組織全体でプロダクトオーナーの意見を尊重しなければならない。プロダクトオーナーの決定は、プロダクトバックログの内容や順番付けという形で見える化されている。開発チームの作業に依頼できるのは、プロダクトオーナーだけである。また、開発チームもその他からの作業依頼を受け付けてはいけない。
プロダクトオーナは従来でいうところのPM・PLの役割と責任を持った人に近いと思います。
では、スクラムマスターは何に相当するかと言えば、PMOの役割と責任を持った人に相当すると思われます。
プロダクトオーナーをプロジェクトリーダ、スクラムマスターをPMOと読み替えてみると、なんとなくうなずけます。
開発チーム
開発チームは、リリース判断可能な「完了」したプロダクトのインクリメントを、各スプリントの終わりに届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバだけである。
開発チームは、自らの作業を構成・管理するものであり、そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。開発チームには、次のような特徴がある。
開発チームが自己組織化されており、機能横断的なのがスクラムの特徴です。
従来の開発プロセスでは、プロジェクトリーダがトップダウン的に指示を出し開発メンバーはそれに従うという体制ですが、スクラムでは「チーム外からの指示ではなく、自らが選択する。」というところが、大きく違うところです。受け身や指示待ちではだめだと良く言われますが、それを実践しているのがスクラムというものでしょう。
開発チームは3人から9人が最適な人数ということです。
確かに、この位の人数がプロジェクトの規模としてちょうど良いという感じがします。
それ以上の規模のプロジェクトの場合はどうするのかというと、開発するシステムをサブシステムや機能で分割し、複数のスクラムチームが並行して開発を進めるということでしょう。開発チーム間でのコミュニケーションが大量に発生しないように、うまく分割することが実際の開発では重要になると思われます。
複数のスクラムチームの事をScrum of Scrumと呼びます。
スクラムマスターの役割と責任はPMOのようなものだと書きましたが、PMOはプロジェクトを管理するという意味合いが強いのに対して、スクラムマスターはサーバントリーダ(支援や奉仕をするリーダ)としているところがこれまでのプロジェクトマネージメントとは異なるところです。
役に立たない事を妨害リストとも呼ぶらしいですが、それを外部の人達に理解してもらうようにするのも大切な役割です。
スクラムを実践した事が無い場合、周りの人からもほんとにうまくいくのかと思われているため、これが一番結構大変な仕事であることは想像に固くありません。
プロダクトオーナーの支援
スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
開発チームの支援
スクラムマスターは、さまざまな形で開発チームを支援する。
スクラムマスターはあくまで支援するのであって、指示したり管理するのではありません。
プロジェクトリーダとは別の役割を持っているのです。
スクラムの考え方の中心は開発チームが主役で、そのチームが自ら考え行動できるようにスクラムマスターがサポートしてあげることに最大の役割があります。
現実にはプロダクトオーナ、スクラムマスタ、開発チームメンバーのいずれかを兼任する場合もあるのでしょうが、開発チームメンバーとプロダクトオーナやスクラムマスターは兼任しても良いが、プロダクトオーナとスクラムマスターは兼任してはいけないそうです。