勝手に注釈付き参考文献
シンプルにするのはいいけれど、参考文献がないのはどういうことなの？という思いから
とはいえ、網羅的なものにはしない（疲れるので）
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね）
スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard business review, 64(1), 137-146.
最初のスクラムは、Jeffのプロジェクトでやっていたものだった。上記のように「みんなが模索していた時代」なので、その話を聞きつけたKen Schwaber（とMike Beedleも？）がやってきて、協力してスクラムの理論を作っていくことになる。JeffとKenの2人の見解をまとめたものが、Kenの論文として出版される。著者名にKenしかないが、実際は複数人で書いたものらしい（要出典）。
Schwaber, K. (1995). Scrum Development Process: Advanced Development Methods. In Proceedings of OOPSLA’95 Workshop on Business Object Design and Implementation, London, UK.
「スクラム」に関する最初の論文
Gartner, L. (1996). The Rookie Primer. Radcliffe Rugby Football Club.
「スクラム」とは何なのかをラグビーの説明書で調べたみたいだ
繰り返しになるが、当時は「みんなが模索していた時代」なので、似たようなことをやっている人たちは他にもいた。たとえば、James Coplienが、ボーランド社のコンパイラのチームを観察研究していた。その後『組織パターン』となるこの研究は、以下の論文として出版されている。JeffとCoplienはお互いに知見を共有していたようだ。たとえば「デイリースクラム」はこのプロジェクトに由来している。
Coplien, J. O. (1994, June). Borland software craftsmanship: A new look at process, quality and productivity. In Proceedings of the 5th Annual Borland International Conference (Vol. 5).
また、当時はMitchell M. Waldropの『Complexity: The Emerging Science at the Edge of Order and Chaos』（邦訳：『複雑系』）が流行し、複雑系やカオス理論に対する関心が高まっていた。ものすごく噛み砕いて言えば、先のことなんかよくわからん！（計画なんて無理じゃね？）という感じ。
スクラムが複雑性やカオスを扱うきっかけとなった論文は以下に挙げたものなどいくつかあるが、なかでもBabatundeの論文はKenのお気に入りのようで、頻繁に引き合いに出される。
James, G. (1987). Chaos: Making a new science. Viking Penguin, 9-31.
Langton, C. G. Artificial Life VI,(1988).
Babatunde, A. O., & Ray, W. H. (1994). Process dynamics, modeling and control. Oxford University Press.
Kenは上記に影響を受けて「スクラムはカオスをコントロールする」という論文を書いている。
Schwaber, K. (1996). Controlled chaos: Living on the edge. American Programmer, 9, 10-16.
また、カオスや複雑性は「人々」「要求」「技術」から生じるノイズが原因だとして、概念図として、「ステーシーのチャート」を用いるようになる。ただ、これは根拠がはっきりしないためか、最近では使われないようだ。代わりに、Snowdenの「クネビンフレームワーク」が使用されることが多い。
Stacey, R. D. (1999). Strategic management and organisational dynamics: The challenge of complexity to ways of thinking about organisations (3rd edition). Pearson education.
Snowden, D. J., & Boone, M. E. (2007). A leader's framework for decision making. Harvard business review, 85(11), 68.（邦訳：「臨機応変の意思決定手法「クネビン・フレームワーク」による」）
その後、Mike Beedleがファーストオーサーとなり、KenとJeffも名を連ねている論文が1999年に発表される。Mikeの趣味だと思われるが、パターンランゲージがスクラムの世界に持ち込まれている。以下の図にも記載されているとおり、前述のCoplienの組織パターンともリンクされている。なお、これは後に『A Scrum Book』のスクラムパターンとして結実する。
Beedle, M., Devos, M., Sharon, Y., Schwaber, K., & Sutherland, J. (1999). SCRUM: An extension pattern language for hyperproductive software development. Pattern languages of program design, 4, 637-651.
こうした複雑系への対応策として、スクラムは「「経験主義」と「リーン思考」に基づいている」とスクラムガイドに記載されている。
「経験主義」はempiricismの訳語であり、辞書にこう載っているので他に訳しようがないのだが、これを哲学における「（イギリス）経験論」のことだと思うとよくわからないことになってしまう。観念は経験や感覚から生ずる……みたいな意味ではない。大陸合理主義と対比しても意味はない。
スクラムにおける「経験主義」とは、前述のBabatundeがデュポン社に導入したプロセス制御理論に由来するもので、「複雑なプロセスは事前に予測・定義することはできず、経験的なモデルを必要とする」ことを意味している。つまり、試行錯誤しながらプロセスを制御していきましょう、ということ。簡単。
Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall.（邦訳：『アジャイルソフトウェア開発スクラム』）
「リーン」については検索すればいくらでも出てくるのだけど、簡単に言えばMITのジェームズ・P・ウォマックらが1980年代に日本の自動車産業を研究し、ムダを排除した生産方式の様子を「リーン（ぜい肉の取れた、体が締まった）」と名付けた、というもの。
スクラムも以下の書籍から多くの概念を拝借していると思われる。たとえば、工場の班長から「スクラムマスター」の概念をもらっている（Jeffいわく）。明言はないが、おそらく「プロダクトオーナー」もチーフエンジニア（当時は主査と呼ばれていた：車種のトップの人のこと）からもらっているはず。
James P. Womack, Daniel T. Jones, Daniel Roos, & Massachusetts Institute of Technology. (1991). The machine that changed the world: The story of lean production. Harper Collins.（邦訳：『リーン生産方式が、世界の自動車産業をこう変える。―最強の日本車メーカーを欧米が追い越す日』）
その後、ウォマックは「リーン・シンキング」という概念を提唱。タイトルは原著を踏襲しているのだろうが、文中では「リーン思考」として出てくるので、スクラムガイドでも「〜思考」とした。
Womack, J. J., & Jones, J. DT (1996) Lean Thinking-Banish Waste and Create Wealth in Your Corporation. Simon & Shuster, New York, 400.（邦訳：『リーン・シンキング』）
リーンの話をすると忘れがちなのが、なんでムダを省くのか？ってところだ。それは上の図にもあるように「価値の流れを生み出すため」である。あるいは「創造的な仕事をするため」である。いずれにしても、ムダをやめるのには目的があるのだ。
検査（inspect）と適応（adapt）は「複雑な環境下で検査を繰り返しながら適応していきましょう」という意味なので、出てきて当然というか、当たり前の話である。元々はそれぞれスプリントレビューとスプリントレトロスペクティブで行われるものだったが、現在はもっと細かい単位（デイリースクラムとか）でやりましょうという感じになっているので、特に2つのイベントに限定されない。
ただ、この2つの言葉がいつからセットで使われ始めたのかは定かではない。
Kenの最初の論文には "adaptation to change（変化に対する適応）" や "adaptively（適応的に/適応型で）" という表現は登場するが、"adapt" そのものは見られない。では、どこが出典なのかというと、Kenの2004年の本が初出とされることが多いようだ。
Schwaber, K. (2004). Agile project management with Scrum. Microsoft press.（邦訳：『スクラム入門-アジャイルプロジェクトマネジメント』）
もちろん文中でも登場するのだが、それよりも前に「序文」でMike Cohnが「you’ll learn [snip] how to use its frequent inspect-and-adapt cycles（これからスクラムの検査と適応のサイクルを学びます）」と唐突に説明を始めている。どこで知ったんだ、その言葉。
透明性（transparency）は「誰の目にも見える」という意味。「透明」だったら何も見えないじゃん、とかいうツッコミはとりあえず脇に置いておこう。英語っぽい表現なんだよねえ。直訳の日本語だと適していないのかもしれない。でも、まあ定訳なので仕方ないです。
で、透明性についても初出がKenの2004年の本のようだ。特に断りもなく「I also reminded the team members that Scrum requires transparency.（私はチームメンバーにスクラムには透明性が求められると伝えた）」と出てくる。そうですか。
ちなみに似たような表現として「Information Radiator（情報ラジエーター）」というのがある。冷却するんじゃなくて、情報を放射するという意味ね。ラジオを思い浮かべるといいだろう。これはAlistair Cockburnが提唱した言葉で、KPT以外にヒット作にめぐまれないAlistairの傑作だと思う！
Cockburn, A. (2001). Agile software development: the cooperative game. Pearson Education.
価値基準はKenの最初の本には載っていて、いつの間にか忘れられたんだけど、スクラムガイド2016年版から戻ってきた。そのことについて、JeffとKenが語っている動画があるので見るとよい。
価値基準はすべて漢字2文字で統一したかったので、「確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）」とした。ただ、この訳語を使うべきというつもりもないので、英語を併記することにした。
「確約（Commitment）」だけ、少し補足が必要だろう。辞書を引くと「献身、責任、約束」などがあるが、上記の動画でKenが「がんばりますー、やってみますー」みたいな気持ちでは、ゴールを達成できるわけがないだろ、みたいなことを言っていたので、少し強めの表現を使いたかったのだ。そこで、約束よりも強い「確約」にした。まあ、日常的には「コミットメント」としてもよいです。
ちなみに「価値を届ける」ときの価値は「Value」で、価値基準は「Values」。アジャイルやXPなどは歴史的な経緯で仕方なく、Valuesでも「価値」になってるけど、本来は「価値基準」がよかった。
作成物は「artifact」の訳語なんだけど、artifactは訳すのが超絶難しくて、辞書には「人工物 、成果物、加工品」などがあるけど、どれもしっくりこなかった。なかでも「成果物」にするのは絶対によくなくて、たとえばプロダクトバックログなんか別に成果ちゃうやろ！と思っていたのだ。そんなとき、翻訳レビューアの守田さん（だったと記憶してるけど）が「作成物はどう？」って言ってくれたので、即採用したのだった。
はじめて見た人は「はて……インクリメントとは……」と途方に暮れるかもしれない。これは、最終成果物となる製品などの部分集合を意味している。スプリントで生み出される何かだと考えてほしい。用語の初出は、Kenの最初の本に「Product Increments」として登場したときだろう。スクラムでは、成果物をIncrementally（漸進的に/増加的に）に作るため、増分を意味する「インクリメント（Increment）」が使われたのだと思われる。でも、ソフトウェア以外の世界でも使うのかな？
「スクラムチームは（中略）通常は10人以下である」とあるが、なぜ10人なのか。まず、以下の論文から最適なチーム規模は「4.6人」というのを参考値にしているようだ。
Hackman, J. R., & Vidmar, N. (1970). Effects of size and task type on group performance and member reactions. Sociometry, 37-54.
スクラムでも基本的には「5人まで」がよいとされているが、XP由来のペアワーク／ペアプログラミングを考慮して、最適値の2倍の9.2人（≒10人）まで許容しているのかな？と思う（要出典）。
今回から「スクラムチーム（中略）自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する」と記載され、従来の「自己組織化」が「自己管理」に変わった。「自己組織化」は、前述の竹内・野中論文にある6つの特性のひとつ「Self-organizing project teams（自己組織化されたプロジェクトチーム）」が元ネタになっていると思われる。とはいえ、彼らのオリジナルの言葉ではなく、当時はこういう言い回しが流行ったのではないか。Wikipediaによれば「1977年のノーベル化学賞を受賞した化学者・物理学者であるイリヤ・プリゴジン」が定義したそうな。それにしても、HBRの論文は参考文献がないから、これは論文というより、エッセイなんじゃなかろうか。査読してるの？
チームの話題でよく引用される本：
Lencioni, P. (2002). The five dysfunctions ofa team. Jossey-Bass （邦訳：『あなたのチームは、機能してますか？』）
Kotter, J. P., & Rathgeber, H. (2006). Our iceberg is melting: Changing and succeeding under any conditions. Macmillan.（邦訳：『カモメになったペンギン』）
Kotter, J. P. (1995). Leading change: Why transformation efforts fail.（邦訳：『企業変革力』）
Derby, E., Larsen, D., & Schwaber, K. (2006). Agile retrospectives: Making good teams great. Pragmatic Bookshelf.（邦訳：『アジャイルレトロスペクティブズ』）
序文をKen Schwaberが書いている
Schwaber, K., & Sutherland, J. (2012). Software in 30 days: how agile managers beat the odds, delight their customers, and leave competitors in the dust. John Wiley & Sons.（邦訳：『Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド』）
Sutherland, J., & Sutherland, J. J. (2014). Scrum: the art of doing twice the work in half the time. Currency.（邦訳：『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』）
Sutherland, J., & COPLIE, J. (2019). A Scrum Book: The Spirit of the Game. Pragmatic Bookshelf.
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). The secret history of agile innovation. Harvard Business Review, 4. （邦訳：「アジャイル開発を経営に活かす６つの原則」）
Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing agile. Harvard Business Review, 94(5), 40-50.
Rigby, D. K., Sutherland, J., & Noble, A. (2018). Agile at scale. Harvard Business Review, 96(3), 88-96.（邦訳：「アジャイル 全社展開の実践法」）
【再掲】Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall.（邦訳：『アジャイルソフトウェア開発スクラム』）
【再掲】Schwaber, K. (2004). Agile project management with Scrum. Microsoft press.（邦訳：『スクラム入門-アジャイルプロジェクトマネジメント』）
Schwaber, K. (2007). The enterprise and scrum. Microsoft press.
【再掲】Schwaber, K., & Sutherland, J. (2012). Software in 30 days: how agile managers beat the odds, delight their customers, and leave competitors in the dust. John Wiley & Sons.（邦訳：『Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド』）
【再掲】Schwaber, K. (1995). Scrum Development Process: Advanced Development Methods. In Proceedings of OOPSLA’95 Workshop on Business Object Design and Implementation, London, UK.
【再掲】Schwaber, K. (1996). Controlled chaos: Living on the edge. American Programmer, 9, 10-16.
iki-iki
