スクラムの歴史と3本柱について

はじめに

あけましておめでとうございます。オザサです。

昨年の12月に認定スクラムマスター研修を受け、試験も合格、無事に認定スクラムマスターとなりました。

研修を受けた後、スクラムに関わるあらゆることが気になりだし、様々な書籍を横断的に読んでまいりました。その中で得た学びを社内外に発信すべく本ブログを執筆しました。

あまりにも多くのことを学んだので何遍かに分けるつもりです。

研修においては、James Coplien氏と川口恭伸氏、また同時翻訳をしてくださった方、また、同じ研修を受けた方々に感謝申し上げます。

スクラムの歴史

スクラム以前ソフトウェア開発の話

1968年、NATO後援の国際会議にて、ソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとするウォーターフォール・モデルの原形が提唱された。(https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A9%E3%83%BC%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A9%E3%83%BC%E3%83%AB%E3%83%BB%E3%83%A2%E3%83%87%E3%83%AB)

大まかにいうと製造業や建築業の知見をソフトウェア開発に活かそうという試みである。

アジャイル開発が主流になる以前は、ウォーターフォールモデルが主流だったとされているが、厳密にウォータフォールで行われるというケースは少なく、あくまで工程に着目する開発、というのが広く用いられていた。(『More Effective Agile』より)

工程に着目し、理想主義的で予測可能な状態にあるものに対して有効な手段であるため、変化の激しい環境やソフトウェアのような抽象的なものには不向きであると今日では認識されている。

多くの書籍で言及されているこのモデルの問題点は、「事前に要求を特定し開発を進めることは現実的ではない」という点にある。

このモデルはNassim Nicholas Taleb氏の『反脆弱性』でいうところの脆いシステムとも言える。曰くその性質について下記のように言及している。

物事が計画どおりの針路に従うかどうかに依存している。
逸脱は少なければ少ないほどよい。
逸脱は利益よりも害が多いからだ。

この逸脱を不確実性によってもたらされるものであると仮定した場合、やはり不確実性の高いソフトウェア開発においては反脆いシステムである必要がある。

話をスクラムに戻す。

スクラムの源流

『スクラム仕事が四倍早くなる世界標準のチーム戦術』にも記載があるが、ソフトウェア開発者であったJeff Sutherland氏はウォーターフォールのやり方に疑問を持っており、新たな開発手法を模索していた。

研修の中では、Scrumの源流として3つの要素をCoplien氏が挙げていた。

1.The new new product development game by Hirotaka Takeuchi and Ikujiro Nonaka

2.Borland Software Craftsmanship: A New Look at Process, Quality and Productivity

3.Iterative, Incremental Development, Timeboxes

である。ここでは1について言及したい。

1.The new new product development game by Hirotaka Takeuchi and Ikujiro Nonaka

野中郁次郎氏と竹内弘高氏によって1986年に発表された論文である。

この論文はNASAや富士ゼロックス、ホンダ、キャノンなどの企業を研究することで、新たな新製品開発のプロセスを明らかにしたものである。

その要点は論文の一文にまとまっているので紹介する。

Stop running the relay race and take up rugby.

パスリレーをやめてラグビーのように行おう(本稿著者意訳)

この論文では図のような製品開発タイプについて言及しており、TypeCのチームをその様子からスクラムと名付けている。

the-history-of-scrum-and-its-three-pillars-1

このTypeCにはホンダやキャノンといった日本の製造業が挙げられている。

よって、ある意味では日本の製造業からスクラム開発の着想が得られているとのことだが、元を辿れば、この製造業に多大な影響を与えたのは、アメリカの統計学者であったWilliam Edwards Deming氏である。

Deming氏は元々第2次世界大戦後の1951年の日本における国勢調査の計画立案にかかわるため来日。日本に滞在中、日本科学技術連盟からの招待もあり、多くの日本の技術者に対して「統計的工程管理法」を教えた。その中で継続的な品質改善を行うことの重要性を説いたという。

その上で改善の手法として、PDCAサイクルの元となる考えを示した。(PDCAサイクル自体は講義を受けた日本科学技術連盟が提唱している。)

この考え方は当時の日本としては画期的なものであり、トヨタの文化と適合し、「リーン生産方式」へと後に昇華された。

トヨタの源流は豊田自動織機であり、自動織機を製造していた。この自動織機は、織が正しく行われなかった際、異常を検知して直ちに動作を停止するよう制御されており、問題の検出を機械的に行うことが可能であったという。問題を直ちに検知し対応する。

のちにトヨタ生産方式でいう所の「ジャストインタイム」に繋がるトヨタの文化があったのだろう。

2.Borland Software Craftsmanship: A New Look at Process, Quality and Productivity

https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/QPW

本稿では内容については触れない。

3.Iterative, Incremental Development, Timeboxes

こちらについても本稿では内容については触れない。

以上の3つの要素をもとに、Smalltalkのより良い開発手法について取りまとめたものがJeff Sutherland氏によって生み出され、それをKen Schwaber氏と共に抽象化/汎用化したものとしてScrumを提唱したという。

なお、アジャイルソフトウェア開発宣言が生まれるのはその後2001年のことである。

各語の関係性については川口恭伸氏の絵が有名であろうから詳しくはそれを参照されたい。

the-history-of-scrum-and-its-three-pillars-2
https://speakerdeck.com/kawaguti/agile-and-lean-from-altitude-12-000-feets?slide=3

OODAループとスクラムの3本柱

OODAループ

今日ではPDCAサイクルではなく、OODAループが注目されており、Jeff Sutherland氏曰くその考えをScrumに導入しているとしている(https://www.aglx.consulting/post/ooda-the-mindset-of-scrum)が、このOODAループを提唱したアメリカのJohn Boyd氏はトヨタ生産方式も学んでいたことから、ある意味で考えが昇華されていると言えるだろう。

John Boyd氏はアメリカ空軍大佐で、飛行機乗りであった。朝鮮戦争における空対空戦闘は、米国軍のF86戦闘機とソ連製のMiG15が主たるものであった。機体性能だけでみるとMiG15の方が優れているにも関わらず、10対1で圧倒的にF86の方が撃墜される確率は低かったという。この結果に疑問を持ったBoyd氏が研究を重ねた結果分かったのは、F86の方がコックピットからの視界が広く、相手より反応が早くできたことであるという。

この観察から始まる行動までの流れを理論化したものがOODAループである。

(余談だが、Jeff Sutherland氏も空軍パイロットであった。飛行機が着艦する様子からバーンダウンチャートを生み出したとのこと。)

話を戻して、OODAループとは、

Observe 観察
Orient 方向づけ
Deside 意思決定
Act 行動

のループを指しており、経験主義/実証主義的なアプローチである。

the-history-of-scrum-and-its-three-pillars-3

https://ja.wikipedia.org/wiki/OODA%E3%83%AB%E3%83%BC%E3%83%97

アメリカの経営評論家Tom Petersは1989年に

OODAループで定義されている機動性ことが「競争優位」の源泉であり、単なるスピードやサイズよりも重要だと書い

たそうな。

OODAループにおいてはある種不確実性をチャンスと見做す。この考え方は『反脆弱性』の反脆いシステムに繋がる。曰くそのシステムによって、

試行錯誤は繰り返すごとに価値を増し、失敗よりも投資に近くなる

という。

スクラムないしはアジャイル開発にも同様のことが言えるだろう。

その過程では問題を明らかにすること(観察される状態にする)が全ての始まりたり得る。つまり透明性、そして検査と適応である。これがスクラムの3本柱とされている。(『スクラムガイド』より)

Coplien氏は研修の中で

スクラムはいかに自分がダメなのかを曝け出す。問題を明らかにするのであって問題を解決してくれるフレームワークではない。スクラムを銀の弾丸みたいに捉えている人がいるがその期待には応えられない。

と述べた。

これは『Clean Agile』における

希望がプロジェクトを破壊する前に、アジャイルで希望を破壊する。

とも繋がる発言であると捉えられる。

しかし、このことに立ち向かうには勇気が必要である。それは問題を曝け出すことに対する恐れに対応するためだ。

それはどうやったら手に入るのか、それはまたの機会に。