ジェフ・サザーランドがスクラムを思いついた源流
川口恭伸氏（以下、川口）：“先アジャイル期”から簡単に話していきますね。「Roots of Scrum」でジェフ・サザーランドが何を言っているかという話をしていきたいと思います。
Co-Creator、ケン・シュウェイバーとジェフ・サザーランドの2人がスクラムを作ったということですが、その源流になっているのが何かという話をしてもらったということです。
「スクラムの源流って何がありますか？」ということです。
まず、ジェフ・サザーランドさん。ジェフ・サザーランドさんは、いろいろな企業でCTOとかをやられていましたが、1993年にEaselという会社で最初のスクラムを考案して実施した方です。
（スライドを示して）そのジェフさんが「スクラムを思いついた源流は何ですか」というところを紹介しているのがこれです。文字がちょっと多いんですけれど。
まず1つはチームプロセスだと。「シリコンバレーの起業家たちがやっていたのは、実はチームでなにかを作るというプロセスなんですよ」と。
2番目が竹内・野中論文といって、日本の1980年代で一番強かった製造業を研究した新規事業開発の論文があるんですけれど、それから取ってきて参考にしたと。それから、自分の中にあるビジョンの話があって、ちょっとテクニカルですがEaselでやっていたオブジェクト指向の話（がある）。
それから進化生物学と複雑適応系の話があります。これはどういうことかというと、複雑系は先が読めないので、その中でどういうふうにアクションしていくかというのが進化生物学とか複雑適応系という話です。
もちろん源流にあるのは、当時あったソフトウェアのプロセスとか、生産性の研究がベースにあって考えているということです。
最後にiRobotというものが出てくる。iRobotというのは、当時、ちょうどジェフさんたちがボストンの起業家育成オフィスみたいなところに（いた時）、実はiRobotも同居していたらしくて。ルンバの会社ですね。iRobotはどこかに買われましたね。ちょっと忘れましたけれど。そんな話です。
ぜんぜん終わらないなこれ。やばいな（笑）。
北米のトヨタ自動車のミッションと、竹内・野中論文
川口：実はもう1つ、（ジェフ・サザーランドさんは）「北米のトヨタ自動車をけっこう勉強して、それを参考にしました」と言われていて。北米のトヨタ自動車は、ミッションを3つに分けた。
1つ目がまず米国の企業として地域に貢献する。2つ目が社内のチームメンバーの安定と幸福に貢献する。3つ目に初めて、お客さまに付加価値を提供すると言っていて。
だから、優先順位がまず地域なんですよ。地域社会にいる人々、チームメンバー、社内の人々、労働者と言われる人々です。あと（優先順位）がお客さまという、優先順位がすごくおもしろいという話です。
トヨタの話はまた出てきますが、竹内・野中論文は何を言っていたかというと、80年代のホンダさんの「シティ」を作ったり、富士ゼロックスさんを研究した論文なんですが、Type A、B、Cのプロセスがあると。
AはいわゆるNASAがやっているようなやり方で、分析から開発から設計、実装とかを別の人たちがやっていて、文章で受け渡しているプロセス。これはどうも遅いというか、変化に適応するのがしんどいぞと言っている。
富士ゼロックスがやっていたType Bは刺身型といって、前工程と後工程の人がオーバーラップするようなタイプ。
Type Cはもっと全部入ってくる。大部屋にガッと入ってきて必要な人たちを巻き込んでいって、前の人たちが抜けずに一緒の部屋でやるのがType C。これがホンダのシティを作ったスクラム型です。
このCの型をとって、野中先生たちが“スクラム”と呼びました。
ラグビーのスクラムですが、ここから取ってスクラムという名前がついたんですね。そこから名前を取るぐらい、日本の論文とか日本の1980年代の製造業がいいということで勉強して、取ったということですね。
北米のトヨタ自動車の取り組み
川口：当時トヨタがどういうことをやっていたかというと、有効フロンティアという、いわゆる規模を取るかスピードを取るかの間、直線状のどこかしか最適解がないというバランスで先読みをするとそこしか取れないのですが、そうではなくて、いろいろやっていくと、もっといいポイントが取れることがあるみたいな。
試行錯誤によってもっといいバランスを取れみたいな感じが、トヨタがやりたい、やっていることらしいんです。これは野中先生の本から取っているみたいなんですけれど。
なので、スクラムではどうしたいかというと、最初に計画して「ここに向かって契約どおりいくんだ」ではなく、反復的にちょっとずつうまくなっていく。後半になって物が出てくるとお客さんから要望が変化してくるので、それをちゃんと受け入れて、歓迎する。毎回毎回、動くソフトウェアを頻繁に提供する。
もちろん、開発者だけがやるんじゃなくて、ビジネスの人と一緒になって反復を繰り返すということですね。このあたりがスクラムの重要なコンセプトということです。
コマンド＆コントロール型の組織から自律分散組織へ
川口：ただ、そういうことをやろうとすると、組織の中ではいろいろ軋轢があるわけですよ。ビジネスマンと開発者が一緒にやるということは、つまりどっちかが優位を取って、どっちかが指示をしてどっちかが作るとか、中央集権的な指示型ではない。
（スライドを示して）右側の分散型で、ビジネスマンにも視点があるし、開発者にも多様な視点がある。それを総合しながら、後から出てくる話を取っていきながら、実践して学んで失敗しながら現地でやっていくみたいな。
右側の組織にいかなきゃいけないんだけれど、やはりみんな頭が固いので、そうはいかないところとの対立があると言っているのが、スクラムを作った人たちのお話です。
そのためにコマンド＆コントロール型、「指示をしたらやっとけ」じゃなくて、やる人たちがみんなで集まって、自分たちで認知しながら自律しながら、しかも他家受粉でお互いに学び合いながら、自分が自分の仕事を管理している。経営陣がそれを邪魔するのではなくて、手助けをするかたちの組織にしていこうと言っているんですね。
最近では自律分散組織という話が盛り上がってきていると思うんです。もちろんAWSさんもアジャイルなもの（をやっているの）だと思いますが、ジェフたちはこの時点で言っている。
福井厚氏（以下、福井）：すばらしい。
川口：スクラムはそういったものが前提にあるという話ですね。
2001年のGoogleではすでに自律分散組織みたいなことをやってるみたいな話があって。これは資料に出ているやつで、エンジニアリングのマネジメント（をする人）をなくしたというのがGoogleの話で。これはなかなかラディカルですごいなと思います。
その上で、スクラムのチームをクロスファンクショナルなチームにして、そこに知識がすべて集まるようにするという感じです。ただそれだけじゃなくて、経営陣とか顧客とかを巻き込みながらやっていくのが上級者というような話をしています。
トヨタ・プリウスの創発的戦略
川口：これは1990年代です。プリウスという車があります。（登場したのは）1998年ぐらいだったと思うんですけれど。創発的戦略のことは、野中先生の『流れを経営する』という本で、プリウスを作った時の（ことを）かなり詳しくインタビューされています。
名前が出てこなくなってしまいましたが、その後、副社長をやられた主査の方とかが話をされているのが、野中先生の本に載っています。
非常に分散型の組織でいろいろなリソースを持ってきて、中でフェーズを重複させながら、非常に短い期間でプリウスを作り上げたという非常に有名なストーリーがあります。
プリウス、大変なんですよね。エンジンもあればモーターがあって、それをくっつけるところもあって、すごく大変です。だから、みんなの力を結集しないと作れなかったのですが、これが非常に優れているという話です。
それをやるために、常にマージをしながら動くソフトウェアを作って、自己組織化でみんなでプロダクトを作っていくみたいな話です。
そのためには、みんなで真実を見つめながら、情報を透明に明らかにして、「自分は何をするんだ」ということを自分から明らかにして、指示されるのではなくて、コミットメントで動かしていく。これがスクラムの基本的な考え方だと。
そのためには、同じ場所にコロケーションで集まって、ダイナミックに相互作用して、フェイス・トゥ・フェイスで場を作る、場をエナジャイズしなければいけないという話が出てくるわけです。
スクラムは知っていると思うので、このあたりは飛ばしていきます。（スライドを示して）こんな感じでイテレーティブになっていくということです。
川口：スライドはトヨタウェイを参照していて、日本人としてはスクラムが非常に意義深いなと思います。
（スライドを示して）これは、ジェフ・サザーランドの資料なので、（ジェフ・サザーランドの資料に使われているのは）すばらしいなと思います。
「経験的なプロセス制御」と呼んでいて。やってみて、要件・技術・チームを考えてやってみて、アウトプットで確認をして、プロダクトを一つひとつ変更しながら戻ってグルグル回していく。「検査と適用」と言いますが、やってみて直す、やってみて直す。
もちろん失敗するためにやるのではなくて、仮説をはっきりして、「そっちにいけば絶対うまくいくんだ」とみんなで信じている方向にいくんだけれど、でもやはりうまくいかない部分とかフィードバックがあるわけですよ。それを制御していく。
生物はそうやって失敗しながら淘汰しながらうまくいっていくという、進化生物学というものがあるみたいですが、それと同じように、我々は複雑過ぎるので。
AWSで作っているサーバーのインフラとかはメチャクチャ複雑になっちゃったりするので、こけることもある。カオスエンジニアリングをしながら、こけたところをなんとかしながら（進めていく）みたいな話と、基本的には同じかなと思います。
福井：うん、まさしく。
川口：こけないようにするのはしんどいという話ですね。それをやるためには、現場の人たち、やっている人たちが自己組織化して、自分たちで考えていくというのがよい。
権威的なアプローチというのは、誰か知っている人が来て「あれもしとけよ」「こうなっているから」「指示どおりにやりなさいよ」と言われるのではなくて、組織構造で自分たちでやる。これが重要だと。これがスクラムです。
1993年にスクラムが始まって、最初にガント・チャートをやめたり、ジョブタイトル、役職名をやめたりすることをやっているということです。この時点では、XPでやっているエンジニアの人も採用しているということをお話しています。これがスクラムの話ですね。
（次回につづく）
