Mike Beedle beedlem@fti-consulting.com
Martin Devos mdevos@argo.be
Yonat Sharon yonat@usa.net
Ken Schwaber virman@aol.com
Jeff Sutherland jeff.sutherland@idx.com
山田正樹/メタボリックス(masaki@metabolics.co.jp) 日本語版 (2001/12/14)
SCRUM開発方法論のパターンは、既存の組織的パターン言語に対する拡張として提示される。過去数年にわたって、SCRUM開発方法論は超生産的ソフトウェア開発のための有効なツールとして急速に認識されるようになってきた。しかし、SCRUMパターンを他の既存の組織的パターンと結合することによって、高度に適応的な、しかしよく構造化されたソフトウェア開発組織へと導いてくれることになる。また、SCRUMをパターンに分解することによって、特定の状況において適用可能なSCRUMの一部分のみを取り入れるときのガイドとなるだろう。
注: この論文を通して我々は読者が他の組織パターン[OrgPatt], [Coplien95]に馴染んでいることを前提とする。またここで記述したすべてのパターン名はボールド-イタリックで次のように示す: DeveloperConrtolsProcess。一方パターンに関連する事柄はイタリックで次のように示す: Backlog。
反復可能で、定義されたプロセスというものは本当にソフトウェア開発において存在するのだろうか。これらは可能なばかりでなく必要不可欠なのだと考える人々もいる。例えばソフトウェア開発へのアプローチとしてCMM(Capability Maturiy Model、能力成熟度モデル)を好むような人々である。CMMではプロセスの5つの段階 - 初期段階、反復可能段階、定義された段階、管理された段階、最適化されている段階 - を定義し、ユーザに18のKPA(key process areas)において自らのプロセスを定義するように要求する。
しかし、塹壕の中で日々戦っている我々の多くは"反復可能でよく定義された"プロセスというやり方は以下のような多くの誤った前提に基づいていることに、徐々に気付いてきた。
これらの仮定にまつわる問題は、非カオス的な振る舞いを仮定しているということだ。とても小さな未知のものでさえ、結果として大きな影響を与えうるのだ。
実際問題として、不確定性を排除することはできない。我々の多くは、ソフトウェア開発に対する反復可能/定義されたアプローチの向こう側にある答えを探し求めてきた。それがより"適応的なアプローチ"である。
SCRUMでは、上で間違った前提として議論したカオスの存在を率直に認める。その上で、これらの問題を解決するための手法を提供する。これらの手法は複雑性管理 - つまり自己組織化、経験主義的なプロセス管理、知識創造 - に基づいている。
その意味で、SCRUMは単なる"繰り返し的でインクリメンタルな"開発方法論ではなく、"適応的な"ソフトウェア開発方法論なのである。
SCRUMの目標は、できる限り質の高いソフトウェアを、Sprint(全力疾走)と呼ぶ短いタイムボックス(固定の時間間隔、典型的な場合には1ヶ月程度)を3~8回繰り返すうちに出荷することである。
開発サイクルの各段階(要求、分析、設計、展開、出荷)は一つあるいは一連のSprintにマップされる。伝統的なソフトウェア開発の各段階を便宜上、特にマイルストーンの追跡のために残しておくことにする。そこで例えば、要求段階はプロトタイプの出荷を含む一つのSprintを使う。分析と設計の段階には、それぞれ一つのSprintを使う。一方展開の段階には3から5のいずれかのSprintを使ってよい。
反復可能でよく定義されたプロセスとは反対に、SCRUMではSprintの中であらかじめ定義されたプロセスというものはない。替わりにScrum Meetingが割り当てられた作業を完成へと導く。
各SprintではBacklogと呼ばれるいくつかの作業項目(work item)を行う。規則として、ひとつのSprint内でBacklogにそれ以上の項目が外部的に追加されることはない。もともとのあらかじめ割り当てられていたBacklogから結果として生じた内部的な項目は追加してよい。ひとつのSprintの目標はできる限り質の高いソフトウェアを完成することであるが、たいていは実際に出荷されるソフトウェアはそれには及ばない(Worse Is Betterパターン)。最終的な成果は、完全ではないNamedStableBasesをSprintごとに出荷することである。
図１. ラグビーのチームもScrum Meetingを行う(ここには写っていない)
Sprintの間、Scrum Meetingは以下の事項を決めるために毎日行われる。
Scrum Meetingは開発チームに"チームのメンバの知識を社会化する"ようにし向け、深い文化的な超越性を持つ。
"知識の社会化"は自己組織的なチーム構造を促進する。そこでは開発プロセスは日々進化する。
各Sprintの最後に以下のものに対するDemoを行う。
残りの仕事と新しいタスクを集め、改めて優先度を付け直すと、新しいBacklogが作られ、新しいSprintの開始となる。SCRUMのパターンに合わせて、その他の多くのorgパターン(組織とプロセスのパターン)を利用することも可能だ。Coplienのorgパターンはその幅の広さからいっても自明な選択だが、そのほかのorgパターンにも利用する価値のあるものがあるだろう。[OrgPatt], [Coplien95]
「システムがそれを要求しているのだ」とか「システムがそれを許さないのだ」というのは人の振る舞いに対する(しばしばやむを得ない)正当化として受け入れられるようになりつつある。我々が恐れているのは現在の方法論が我々に「十分ソフトな」ソフトウェアを作るのを許さないことだ。なぜならば今の方法論や設計のパラダイムは、適応性を禁じているように見えるからである。従って、ソフトウェアの実務に携わっている者の大半は、彼らが「あらかじめ指定する」ことができるものについて、アプリオリに計画を立てることのできる最適な解が存在するという暗黙の信念を持って仕事をするような専門家になりつつある。
ひとたび技術が組織に取り入れられると、今度はその技術がユーザの行動空間をある程度決める構造を制約するものとなってしまうことが多い。そのために、我々はソフトウェアをあまりにもハードウェアのように作ってしまうのである。あたかも変更が困難であるかのように、あたかも変更が困難でなければならないかのように...
それとは対照的に、SCRUMは「よりソフトな」ソフトウェアを作らせてくれる。だから前もって完全な要求を記述する必要はない。ユーザは何が可能かわからないし、彼が可能だと思った技術以前の紙の上の解を求めてくるだろう。しかし実はソフトウェア開発者さえ、何を作ることができるかを作る前から知っていることはないのである。したがってユーザは何が可能かを実際に感じたり触ったりすることなく知ることはできないのだ。[Blu96]
明らかに我々は、ソフトウェアを作るためのより柔軟なアプローチを必要としている。我々は前もって完全な要求を持ったり、コンテキストや環境を固定することは「不可能なのだ」ということを認識しなければならない。我々のシステムはそのコンテキストを変換する。システムと新たなコンテキストには新たな問題が生じる。
この問題はユーザ要求を特定するための進歩した方法論を持ってしても解決されていない。その代わりに、本質的に新たな代案を産み出すもっと複雑なプロセスが必要とされている。SCRUMを用いた経験主義的なやり方は可能な代案のうちの一つである。
下の図はSCRUMパターンとほかのorgパターンの間の関係を示している。
図2. SCRUMパターン言語の束
あなたは、発見、創造、テストなどをかなり高い比率で必要とするようなソフトウェア開発チームを管理しているソフトウェア開発者、あるいはコーチである。例えば、問題点がどこにあるかを的確に指摘しなければならないような第一次出荷とか、新しいオブジェクト･モデルを作り出さなければならないとか、まったく新しいあるいは変化の激しいテクノロジーを使っているといったようなプロジェクトだ。
科学的な調査、革新、発明、アーキテクチャ、エンジニアリング、その他無数のビジネス状況における作業がこのような振る舞いを呈する。
あるいはあなたは「知識労働者」、つまりエンジニア、作家、科学研究者、芸術家、はたまたこれらの環境においてチームの活動を監督しているコーチや管理者かもしれない。
(非適合的変数: 見積もり、計画、追跡、人間の快適さ)
注: 非適合的変数とは、このコンテキストにおいて解が問題を解決するために調整可能な変数のことである。
ソフトウェア開発、科学的研究、芸術的なプロジェクト、革新的なデザインのような経験的で予測不可能なプロセスを制御する最善の方法は何だろうか? このようなプロセスではその成果物が何であるかとか、プロセスが何を達成すべきかを定義するのは非常に難しい。
[注: 「非適合的」事例はある種のアンチ･パターンとして参照される。ここでは私はその尋常ではない本質を示すために、ディルバート風の名前を使うことにする。]
(+) 発見、創造、テストなどを含む活動に対する正確な見積もりは難しい。なぜならばたいていの場合、それには大きなばらつきがあり、環境の些細な違いが結果に大きな影響を及ぼす可能性が高いからだ。
これらの不確定性は、少なくとも以下の4つの事柄に起因している。
「非適合的な」例: YouGotTheWrongNumber 新奇性の高いあるいは変わりやすい要求/アーキテクチャ/技術に関するプロジェクトや除去の困難なバグのあるようなプロジェクトにおいては、プロジェクトの見積もりの精度は数段低くなるのが常である。
(-) 見積もりは重要である。人はある程度の将来にどんな仕事があって、そのためにはどれだけの資源を用意しておかなければならないかをあらかじめ決定できなければならない。
「非適合的な」例: SetMeUpForFailuer 見積もりの行われていないプロジェクトは、管理が難しい。
(+) 計画や仕事の優先度の付け替えには時間が掛かる。知識労働者の時間を計画立案ミーティングに使うのは生産性を低下させるだけだ。さらに、もしシステムがカオス的であるならば、いくら計画を立てても不確定性を減らすことはできない。
「非適合的な」例: ParalysisByPlanning 非常な詳細に至る、あらゆる事柄の計画にみんなの時間を費やすようなプロジェクトは、計画を適えることはできない。
(+) あまりにも詳細な計画は巨大になり、それを守るのが難しくなる。単に常識程度のものを適用したり、顧客を呼ぶのは易しい。また計画が大きくなればなるほど、その中には誤りも含まれるようになる(あるいは、その正しさを確認するためのコストが膨らむ)。
(-) 計画をまったく立てないとすれば、チーム･メンバ間に不確定性が増え、ついにはやる気をなくすだろう。
「非適合的な」例: LostVision 何に対してもスケジュールを立てないようなプロジェクトは、予期するものに対する制御を失うことになるだろう。ある程度のスケジュールの圧力がなければ、誰も何もしないし、さらに悪いことに、独立に作られたそれぞれの部品を一つに統合するのが困難になるだろう。
(+) モニタリングのやり過ぎは時間を無駄にし、開発者の息の根を止める。
(+) システムはそもそもカオス的なので、いくら追跡を行ったところで指標の不確定性は減少しない。
(+) 多すぎるデータは意味がない - Haystack症候群。
「非適合的な」例: MeasuredToDeath 非常な詳細に至る、あらゆる事柄の追跡にみんなの時間を費やすようなプロジェクトは、計画を適えることはできない(空気が全部なくなるまでタイヤ圧を計り続ける!)。
(-) モニタリングを十分にやらないといつかは障害にぶち当たり、アサインに空白が生じるだろう。
「非適合的な」例: WhatHappendHere? 何に対しても追跡をしないようなプロジェクトは、自分たちがしていることに対する制御を失うことになるだろう。そしてついには何をしてきたのか誰にも分からなくなってしまうだろう。
毎日のScrum Meetingで短い時間(15分以内)チームのメンバと会う。そこでやることは参加者全員に次の三つの質問をするだけ。
Scrum Meetingは通常、毎日同じ場所、同じ時間に行う。そうすることによって強固な文化を創り出すことができる。同様にScrum Meetingはチームの状態、問題、計画の社会化を強化するための儀式なのである。Scrum Masterはミーティングを指揮し、チームの全メンバのすべてのタスクをプロジェクトで共有のBacklogに記録する。Scrum Masterはまた、すべての障害の記録を取り、開発者が新しい課題に取り組んでいる間にその障害を解決する。
Scrum Meetingは開発者のタスクをスケジュールするだけではなく、プロジェクトに関わっているすべての人の活動をスケジュールできる/すべきである。例えば構成管理をやっている統合の担当者、アーキテクト、Scrum Master、Firewall[Coplien95]、Coach[Beedle97]、QAチームなど。
Scrum Meetingは、知識労働者が一ヶ月程度のSprintに割り当てられた中期の目標を果たせるようにする。
Scrum Meetingは、自発的なチームが開催してもよい。その場合には誰かが完了した活動、予定している活動(Backlog)、すべての障害の記録を取る役を引き受ける。Backlogに載っているすべての活動と障害は、解決を目指してチーム･メンバに配布する。
Backlogと障害のフォーマットは、紙切れに項目をリストしただけのものから、インターネット/イントラネット上のソフトウェアで扱えるようにしたもの[Schwaber97]までいろいろある。SCRUMのサイクルは調整可能だが、2時間から48時間が普通だろう。
見積もりの過小あるいは過多は簡単に起こる。そしてそれは、開発者の時間の空白や、課題の完了の遅れを引き起こす。したがって、小さな課題の状況を頻繁にサンプリングするのは悪くない。不確定性の度合いが大きいプロセスでは、既存のプロジェクト計画の手法(ガント･チャート、PERT図など)「だけ」を使っているわけにはいかない。なぜならば分析/達成/生成の変化の割合がきわめて高いからだ。その代わりに、定期的なタスクの再優先順位づけが、短い時間間隔における系統的な知識のサンプリングを提供してくれる、適応的なメカニズムとなる。
SCRUMのミーティングは、「参加的な文化」[Weinberg97]を作り出すのにも役立つ。なぜならSCRUMのミーティングは以下のような生産的な価値を奨励するからだ。
この同じメカニズムが、チーム･メンバの社会化、外面化、内面化、進行中の物事についての技術的な知識の結合を促進する。しがたって、技術的な専門家が実践的なコミュニティにおける財産となる[Nonaka95]。Scrum Meetingは深い文化的な超越性を持った儀式なのである。 同じ時間に、同じ場所で、同じ人が行うミーティングは、帰属意識を高め、知識を分かち合う習慣を作り出す。
プログラミングの割り当てはどちらかといえば確率的な性質を持つことから、システム･ダイナミクス[Senge94]の観点では、ソフトウェア開発とはスケジューリング問題であると言える。見積もりを当てるのは難しい。なぜならば
その結果、ソフトウェア開発はカオス的な「ビール･ゲーム」のようなものとなる。そこでは、小さな課題に対して頻繁なモニタリング[Goldratt90], [Senge90]を実行しなければ、開発者の空いている時間の「棚卸し」は見積もりも制御も難しいものになってしまうだろう。その意味で、Scrum Meetingはチームの体温を常に測り続ける「体温計」に相当するものになる。
毎日のScrum Meetingを通して資源を便宜主義的にシフトしていることから、複雑さの理論[Holland95], [Holland98]の観点では、SCRUMはエージェントのより迅速な相互作用を強いることによる「群集化」、つまり自己組織化プロセスの促進を行っていることになる。
自己組織的なマルチ･エージェント･システムの緩和は、単位時間当たりのエージェント間の交換の平均に比例することから言っても、上記は理解できる。また実際、"相互作用の頻度"は"創発的な"振る舞いを制御するために押すことのできるレバーの一つなのである。これは化学的な反応に酵素や触媒を加えることに似ている。
これはSCRUMではSCRUMのミーティングの頻度をその最適上界頻度(時間当たりのミーティング回数)まで上げること、(下で述べる)hyperlinksをその最適上界まで増やすことを意味している。そうしなければ、組織は知識を社会化することにばかり時間を使って、タスクを実行する時間がなくなってしまうだろう。
(Mike Beedle) シカゴのNike Securitiesで我々は、1997年2月以来SCRUMのミーティングを使って我々の(BPRとソフトウェア開発を含む)プロジェクトを走らせている。このプロジェクトに参加する人は全員、1週間のSCRUM手法のトレーニングを受けることになっている。
(Yonat Sharon) Elementrix Technologiesでは、既に過去5ヶ月間走ってきたプロジェクトがあった。まだほんの一部(全体の20%)しかできておらず、できている部分にもまだたくさんのバグがあった。プロジェクト管理者は一日おきの状況報告ミーティング(このときには我々の中ではだれもSCRUMの用語に馴染んでいなかった)を始めた。次の1ヶ月間にプロジェクト全体が完了し、品質も大きく向上した。2週間後にはβバージョンが出荷された。ミーティングは中断され、それ以来プロジェクトはほとんど進捗しなくなった。私はプロジェクトの成功をScrum Meetingだけに帰するつもりはないが、この達成に大きな役割を果たしていたと思う。
RAFAELの私のソフトウェア･チームのリーダの一人は、Scrum Meetingの変種をやってみた。彼は一日に一回開発者を一人一人回って、さっきの三つの質問をし、バックログも管理した。これはチーム構築に影響はなかったが、頻繁なサンプリングが可能になった。
FormFollowsFuntionやビジネス環境におけるCaseTeamなどを通して完全に実現することができるDeveloperControlsProcessのような構造は、高度に適応的で超生産的なチーム構造である[Coplien95], [Beedle97]。
このパターンの応用結果としては
あなたは、発見、創造、テストなどがかなり高い比率で含まれているようなソフトウェア開発チームを管理しているソフトウェア開発者、あるいはコーチである。
あなたは、きれいなインタフェース、コンポーネント、オブジェクトで仕事を分割できるようにシステムを構築、あるいは拡張しようとしている。
我々は、できるだけ邪魔されずに仕事をしたいという開発者の要求と、できるだけ本当の進捗を知りたいという顧客や管理者の要求のバランスを取りたい。
開発者は邪魔されずに仕事をする時間が必要である。しかし後方支援も必要だし、管理者やユーザは真の進捗がどれくらいかを確実に知りたいと思っている。(不適合性: 何のコントロールもない開発者は何も作り出さないだろう)
システムが出荷されるまでに、システムが古くなってしまったり、大幅な変更が必要になることがよく起こる。問題は、環境からの入力のほとんどが開発の初期段階に集められたもので、一方ユーザは出荷されたシステムや中間リリースを使ってほとんどのことを学ぶものだと言うことにある。(不適合性: 厳しすぎる管理は物事のスピードをダウンさせる)
中には、与えられた解決の記法を使わなければ問題を記述することさえ難しいという邪悪な問題もある。この手の問題に関しては、開発者が開発の開始時にきれいな設計をして、その成功を約束してくれるなどと期待するのは間違っている。実験、フィードバック、創造性が必要なのだ。(不適合性: まず解決法を考えずに、要求を書き下せるという主張は間違っている)
我々はチームの誰もが問題を完全に理解して、開発のすべての段階に注意を払ってほしいと思っている。これはチームの規模と開発するシステムの規模に制限を設けることになる。SCRUMでは信頼が中心的な価値を持ち、特にSprintの成功には重要な鍵となるので、SelfSelectingTeamsは役に立つ[Coplien95]。(不適合性: 大きなチームはうまく機能しない、なぜなら何人の人があることに一緒に取り組めるかについては上限がある - 制限された合理性問題 - からである)
プロジェクト管理者、顧客のような多くの人々にとって、伝統的な開発で提供されてきたような進捗や制御を諦めるのは難しい。大変リスクが大きいように感じるわけだ。チームがちゃんと出荷できることに何の保証もない。顧客やユーザのニーズは常に変化し続けるので、最終的な仕様をもらえることは滅多にない。できることは彼らのニーズが変化し、プロセスに合わせて理解が進むのにしたがって製品を進化させていくことが関の山だ。我々の開発プロセスでは、この学習サイクルとその恩恵は用いない。(不適合性: 硬直したプロセスは制約しすぎることが多いので、システムを出荷まで持っていけない)
開発者とプロジェクト管理者はしばしば偽りの生活を送っている、あるいは送らざるを得ない羽目に陥っている。彼らは自分たちが計画を立てることができ、予測をすることができ、出荷することができ、従ってシステムを出荷する最良の方法を知っていると主張しなければならないのだ。彼らは実際にはあるやり方でビルドしながら、別のやり方でビルドできると主張し、結果として本当の制御ができなくなっている。(不適合性: 硬直した計画は制約しすぎることが多いので、システムを出荷まで持っていけない)
プロセスが軌道に乗っていることを証明するために多大なオーバーヘッドが生じる。我々はPERT図とかそんなものに従ってやってきて、システムがちゃんとできると信じている。今のところ、プロセスの自動化は管理者や開発者の管理的な仕事を増やし、その結果机上の空論となるような開発プロセスをほんの少しばかり生み出す。(不適合性: 作業と成果は同義語ではない。プロジェクト計画は作業を示してくれないばかりか、進捗や成果もほとんど保証してくれない)
各SprintではBacklogからあらかじめ割り当てられた一定量の仕事をする。チームをそれをコミットする。規則として、Sprintの間外部から仕事が追加されることはない。外部からの仕事は全体のBacklogに追加される。Sprintから生じた障害もBacklogに追加する。Sprintは新しい機能のDemonstration(DemoAfterSprint)をもって終了する。
開発者には、外部からの割り込みに邪魔されず、チャンスや洞察力を生かして仕事のやり方を自由に変えられるように、創造的になり、設計空間を探索したり、実際の仕事をしたりして学ぶことができるような空間を与えなさい。同時に、管理者や他の関係者にも、証拠作りのためのドキュメントや報告書ではない真の進捗を見せて信頼を得るようにしなさい。これをBacklogの一部を小さなチームに割り当てた、Sprintという短いサイクルで行いなさい。Sprintではだいたい30日の期間で、みんなが納得した量の仕事をこなし、成果物を出荷する。その一ヶ月で何が達成できるかという見積もりと優先度に基づいて、BacklogをSprintに割り当てる。凝集度が高く、結合度の低い塊を選ぶ。小さな管理ではなく、可能性を高めることに焦点を当てる。
Sprintの間、徐々にカオスが忍び寄ってくる。チームは前に進むに連れて、コースや仕事のやり方を変えていく。チームを外部からかばうことによって、チームが彼らの腕前と経験と創造性を持って、最善の成果物を最善の方法で出荷できるように働くことに集中させよう。
各Sprintでは目に見える、実際に使える出荷物を作り出す。これはDemoでデモンストレーションする。増加分は中間的なものでもユーザに引き渡し可能なものでよいが、それ自身が動作するものでなければならない。Sprintの目標は、できる限り質の高いソフトウェアを、アリバイとしての紙の上のマイルストーンではない真の進捗を確認しながら、完成させることである。
システム開発は予測不可能でカオス的である。開発はプロセスを通して熟慮が必要な経験的なプロセスである。方法論は単に実際の仕事のフレームワークを提供し、創造性の必要とされる場所を指し示してくれるに過ぎない。しかし我々はしばしば完全に定義されたプロセスとして、ブラックボックス的なプロセスを歩んでいく。予期しない結果が起きる。我々は予測できないことに対する計測と反応を制御できなくなる。
システムを構築するときに、多くの成果物が生成される一方、多くの新しい洞察も得られる。この新たな成果物が将来の思考を導いてくれる。よいツールや内容の分かったコンポーネントによって生産性が増大すれば、Backlogをさらに追加し、システムにより多くの機能を追加し、製品をもっと早くリリースできる可能性が高まる。
したがってSprintの間、我々は日々Scrum Meetingでコミュニケーションを最適化し、共有される情報を最大化する。
Sprintは外部の要求や機会から邪魔されずに開発者が仕事できるような安全な環境と時間枠を用意する。また、Sprintの最後にちゃんと動くコードのような役に立つ出荷物をScrum Teamが作り出せるということを顧客も管理者もユーザも信頼できるような、一連の仕事をあらかじめ割り振る。チームはやるべきことをやることに集中し、管理者はもっとうまくやろうという道に立ちふさがるものを取り除く仕事をする。
ArgoのFlemish教育部門で、我々は1997年1月以来多数のエンド･ユーザ･プロジェクトやデータベース/ドキュメント管理/ワークフローのフレームワークの開発にSprintを使い続けている。Backlogは約一ヶ月のSprintに分割される。各Sprintの終わりには、動くSmalltalkのイメージが他の現行のアプリケーションと統合した形で出荷される。チームは毎日Scrum Meetingでミーティングし、月例ミーティングでのDemoの後運営委員会とともにBacklogを再優先順位付けする。
参加者(これにはDemoとBacklogの再優先順位付けの間同席したユーザも含まれる)による高度で効果的な所有権。
Sprintの最後に、我々はSprintの最初に何を計画したかに対する最良の見積もりを持つことになる。Sprintの最後のレビュー･セッションで、 監督者は将来に向けて計画を変える機会を持つ。この点でプロジェクトはまったく柔軟である。目標、成果物、出荷日と出荷コストを再定義することができる。
SCRUMによって、我々は大きな計画後の柔軟性を持つ(顧客にとっても開発者にとっても)。
Sprint中の毎日のScrum Meetingで、あるチーム･メンバがまったく(あるいはあまり)生産的でないタスクで時間を無駄にしたことが判明するかも知れない。あるいは最初に管理側が割り当てたよりも仕事に時間が掛かることが判明するかも知れない。それは例えば開発者が最初の前提ほどには割り当てられた仕事に有能でも経験者でもないことが分かったり、彼らが政治的な権力闘争に励んでいたせいかもしれない。しかしSCRUMの透明性の高い方法を使えば、こういった問題に対処することができる。これがScrum MeetingとSprintを通して証明してきたSCRUM方法論の強さなのである。
Sprintでバックログをグループ化するのが難しいという点は、管理者や顧客にとって優先順位が明確になっていないと言うことかも知れない。
この方法論は強力な指導を必要とする人々には向いていない。
あなたは、カオス状態に陥ってしまって次に何をすればいいかの情報を必要としているあるソフトウェア･プロジェクトあるいはその他のプロジェクトに関係している。
プロジェクトの各段階で、次にすべき仕事をどうしたらうまく組織立てることができるか?
PERT図やガント･チャートでとらえられるプロジェクト計画は、たいていすべき仕事をアプリオリにとらえている。しかし、実際にやってみようとするとうまくいかない。柔軟性が欠けているからである。タスクはPERT図やガント･チャート作成時に割り当てられるが、本当のプロジェクトで必要になるときにはその優先度や数が増えたり減ったりする。したがって時間に伴ってタスクの数が大幅に変化するような場合にはこれらはいいツールとは言えない。
単にタスクのデータベースをどんな形にしろ作らないと言うだけでは、やはりプロジェクトは失敗に終わってしまう。そこには何らかのプロジェクト制御が必要なのである。
SCRUMチームでは仕事を組織立てるのにBacklogを使う。
Backlogは優先度の付いたリストである。もっとも優先度の高いバックログ(残務、滞貨、仕掛品)は最初にやり、もっとも優先度の低いバックログは最後にやる。成果物に対する機能、追加、拡張に対して議論する価値はない。成果物の成功や妥当性にとって、その時点でより重要か、より重要でないかということだけが問題となる。
Backlogは成果物に対して行う仕事である。仕事が完了すれば、成果物の形を現在の形から理想の形に変わる。しかしSCRUMでは、Backlogは成果物や成果物が使われる環境が変化するに連れて変化する。バックログはダイナミックなもので、Backlogの完了によって定義される成果物がもっとも適切で競争力を持ち役に立つ製品となるように管理側が常に変えていく。
バックログのリストの元になるものは多数ある。製品マーケティング部門は彼らなりの製品のビジョンを叶えるための仕事を追加するだろう。営業部門は新たな売り上げにつながり、インストールされた製品に役立つ機能を付け加えるための仕事を追加するだろう。技術部門は製品がもっとも革新的で生産的な技術を使えるようにするための仕事を追加するだろう。 顧客サポート部門は現行製品の欠陥を修正するための仕事を追加するだろう。
仕事の優先順位を付けられるのは一人だけである。この人物は製品のビジョンを叶えることに全責任を負う。職位は通常プロダクト･マネージャとかプロダクト･マーケティング･マネージャとかだろう。もし誰かが仕事の優先度を変えてほしいと思ったら、この人物に優先度を変えてもいいと説得しなければならない。もっとも優先度の高いバックログはもっとも詳細に定義されている。また優先度は依存性の観点からも考慮される。
市場や組織の財政上どれくらい早急に製品が必要とされているかに応じて、一つの製品のバックログに対して一つ以上のScrum Teamが仕事に当たる。ひとつのScrum Teamはすぐにでもそのバックログをやっつけることができるようになっている(新たに結成されたか、あるいは一つのSprintを終わったところ)ので、チームはまずプロダクト･マネージャに会う。もっとも優先度の高いバックログに焦点を絞って、チームは一回のSprintの繰り返し(30日)で終わらせることができると信じるBacklogを選択する。同時に、Scrumチームは待ち行列の中から同時に片付けることのできるもっと易しいものを選ぶこともある(バックログの優先度を変える)。例えば共通のモジュールやインタフェースの開発が必要となり、一つのSprint内に含めるのが有意義である複数の仕事があるような場合である。
チームは最高優先度のバックログから凝集度の高いグループを選び出す。これが完成すれば、一つの目的、マイルストーンに到達したことになるわけだ。これを「Sprintの目的」と呼ぶ。Sprintの間、この目的が達成される限りにおいては、チームが何をやろうと、何をやらなかろうと勝手である。
ここでチームはバックログをタスクに分解する。このタスクは仕事の別々の断片で、各チーム･メンバが契約してそれを分担する。タスクを行うことによって、Sprintの目的を達成し、バックログを完了する。
プロジェクトの仕事は以下に従って動的に識別され、優先順位付けされる
SCRUMは、全体のサイクル、および仕事の進捗の間で高度な情報の共有を行うプロセスを作り出す知恵である。
SCRUMのキーとなるのは、我々がリリースに向けて仕事を完了する日をはっきりと決める、機能に優先順位付けをする、利用可能な資源を特定する、アーキテクチャについて重要な決定をする、という点である。もっと従来からある方法論に較べると、計画立案のフェーズは短い。我々は何か起これば最初の計画や方法に変更が必要になることが分かっているからである。SCRUMは開発に対して経験主義的なアプローチをとる。つまり環境との相互作用が許されるだけではなく奨励され、スコープ、技術、機能は当然変化するものととらえ、日常的な情報の共有とフィードバックがパフォーマンスを高め、信頼を高める。
SCRUMを他の組織パターン[OrgPatt]、特にJames O. Copienのパターン[Coplien95]と併用すると、適応的で、なおかつよく構造化されたソフトウェア開発組織を作ることができるだろう。
これを適用することによって、よく定義された役割と関係、意義ある超越的な儀式を持つ強い文化を創る出すこともできるだろう。
我々は長年にわたりフィードバックを返してくれたすべてのSCRUMユーザとレビューアに感謝の意を表したいと思います。またScrum Meetingパターンの初期のレビュー･セッションに参加してくれたChichago Patterns Group(特にBrad Appleton, Joe Seda, Bob Haugen)にも感謝します。最後にPLOP98のshepherdであったLinda Risingが我々に与えてくれたコメントと指導が我々の論文をよりよいものにしてくれたことを感謝します。
(Mike Beedleからの個人的な謝辞) Jeff SutherlandとKen Schwaberには90年代前半にSCRUM手法をソフトウェアに適用してくれたこと、そして彼らが見つけたことを私と分かち合ってくれたことを感謝します。SCRUMは私がこの手法を使ったソフトウェア･プロジェクトで多大な貢献をしてくれました。
[Beedle97] Michael A. Beedle, cOOherentBPR ﾐ A pattern language to build agile
organizations, PLoP ’97 Proccedings, Tech. Report #wucs-97-34, Washington
University, 1997.
[Coplien95] James O. Coplien and Douglas C. Schmidt, Pattern Languages of Program
Design (A Generative Development-Process Pattern Language), Addison and Wesley,
Reading, 1995.
[Goldratt90] Eliyahu Goldratt, Theory of Constraints, North River Press, Great
Burlington (MA), 1990.
[Holland95] John Holland, Hidden Order ﾐ How Adaptation Builds Complexity, Helix
Books, Addison-Wesley, Reading MA, (1995).
[Holland98] John Holland, Emergence ﾐ from chaos to order, Helix Books, Addison-
Wesley, Reading MA, (1998).
[Nonaka95] I. Nonaka and H. Takeuchi, The Knowledge Creating Company,
Oxford University Press, New York, 1995.
野中 郁次郎 (著), 竹内 弘高 (著), 梅本 勝博 (翻訳)、
知識創造企業、
東洋経済新報社、1996。
[OrgPatt] Org Patterns web site:
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ProjectIndex
[Schwaber97] Kenn Schwaber’s, SCRUM web page:
http://www.controlchaos.com
[Schwaber97-2] personal communication.
[Senge90] Peter Senge, The Fifth Discipline - The art and Practice of the
Learning Organization, Doubleday/Currency, New York, 1990.
ピーター・M. センゲ (著), Peter M. Senge (原著), 守部 信之 (翻訳) 、
最強組織の法則―新時代のチームワークとは何か、
徳間書店、1995。
[Sutherland97] Jeff Sutherland, SCRUM web page:
http://www.tiac.net/users/jsuth/scrum/index.html
http://www.jeffsutherland.org/scrum/index.html
[Weinberg97] Gerald Weinberg, Quality Software Management ﾐ Vol. 4., Anticipating
Change, Dorset House, New York, 1997.
G.M.ワインバーグ (著), 大野 徇郎 (翻訳)、
ワインバーグのシステム変革法 ソフトウェア文化を創る〈4〉 、
共立出版、2000。
Coplienの生成的開発プロセス･パターン･ランゲージの翻訳は以下にある。
http://www.kame-net.com/jplop/Translation/GDP/patternIndex.htm