スクラムは経験的だが、経験的に用いられていない理由

今回のポイント（TL;DR）

1. 経験主義の柱がない
2. スクラムは自身の経験的モデルを発明/開発した
3. スクラムは経験主義であるが、ほとんどの使い方が経験主義ではない
4. 真の経験主義とは帰納的推論である
5. プロダクト開発には、演繹的推論、帰納的推論、そして仮説的推論が必要である
6. ほとんどのスクラムやアジャイルは決定論的累積反復であり、帰納的ではない

まず始めに、スクラムは経験的なデザインモデルを中核に据えているが、スクラムの利用においては、ほとんどが経験的ではないと言っていきたい。これを理解するためには、少し遡る必要がある。

1. 帰納的推論

1620年、フランシス・ベーコン卿は、『ノヴム・オルガヌム』を発表した。ベーコン卿の仕事により、帰納的推論、もしくは経験主義の誕生したのである。

経験主義の父と呼ばれるフランシス・ベーコン卿は、自然現象を探求する「科学的方法」を確立し、普及させたと言われている。アリストテレスの時代から科学を支配してきた演繹的推論とは対照的にベーコン卿は、観察・計測・実験によって仮説を検証し、洗練させるという帰納的方法論を導いた。
アリストテレス派が、「水は生命維持に必要であり、その不足は死をもたらす」と論理的に推論した。これだと砂漠は乾燥しているので、生命が存在しないのではないだろうか。しかし、これはあくまで経験に基づいた推測であり、観察者の主観的な経験に過ぎず、観察されたものについて集めた客観的な事実に基づいているわけではない。
ベーコン派は、この仮説を検証するために、さまざまな条件下で、さまざまな生命体を使って水不足の実験を行いたいだろう。その結果として、生命の水への依存度について、より厳密でより明確な結論が導き出されるだろう。

プリンストン大学（Princeton University）

この記事は、間違いなく議論を呼ぶことになるであろう。この一行が肝心である。

観察・計測・実験によって仮説の検証と洗練を行う

みなさんのアプリにおけるスクラムでは、このようなことをしているだろうか。それとも、多かれ少なかれ反復的に作業を行なっているでだろうか。これには違いがある。

仮説（名詞）: さらなる調査の出発点として限られたエビデンスに基づいて行われる推測または提案された説明のこと。哲学では、推論の基礎として、その真偽を問わずになされる命題のこと。似たような言葉に、セオリーや推測がある。

仮説の定義、仮説とその意味について、1つの論文を書くことができるし、実際に書いている人物もいる。この時点で、なんとなくイメージを掴めただろうから、この辺りで留めておこう。

2. 経験的プロセス制御と経験主義の柱

このトピックを探るにあたり、もう少し歴史が必要となる。上記の項目はすべてスクラムの創作である。ケン・シュウェイバーの言葉を借りれば、「わたしたち自身の発案」である。

みなさんから嫌われる前に、私はこの問題についてケン・シュウェイバーとeメールで話をし、彼は非常に寛大な対応をしてくれた。私はケンが素晴らしい知性を持っていると思うし、彼を高く評価している。だからこの記事は、「Get Scrum」や「Get Jeff and Ken」の記事ではなく、事実を理解し、ツールの応用を理解するためのものである。そう、ツールの話なのだ。

スクラムは、適切な文脈で、デザインされた通りに用いれば、実際には素晴らしいツールであり、大きな実用性を持ち合わせている。スクラムは、聖杯ではないし、万能薬でもないのだ。

では、このようなことはどこから来たのだろうか？

1994年にオックスフォード大学出版局から出版された教科書『Process Dynamics, Modeling, and Control』は、学術的かつ理論的なモデリングに関する書籍である。著者のBabatunde A. (“Tunde”) Ogunnaike（ツンデ）はDデュポン社に勤務し、化学と数学の理論モデリングの専門家であった。

ケンからの返信によると、「ツンデは今、デラウェア大学の工学部の学部長をしている。彼はプロセスダイナミクスの新版を出版し、我々の世界が急速に複雑化していることを明らかにしている。彼は、予測的思考はしばしば状況を正しく理解する妨げになるので、統計学は第二の天性でなければならない思考法であると主張してる」と述べている。

ツンデは、統計的モデルであるプロセスコントロールの理論の一部として、経験的プロセスモデリングを作成した。この書籍の中にでてくる数学は、心が揺さぶられるようなものだと信じている。

この画像は、原著の416ページに掲載されているもので。当時ツンデが提案したモデルである。私は、ケンが言及した後の書籍を見たことがなく、オンラインでも見つけることができなかった。

「この書籍は、プロセスコントロールのための大学院の教科書（sic）で、一度に1つの章ごとに（読むとよい）」とケンは述べている。1,300ページにも及ぶため、私もそう思う。

この経験的アプローチに踏み込んだのが第13章であり、本書全体は、この解説者の頭脳をはるかに超えた化学式や統計式に彩られている。

私はケンに、「あなたがディポン社やツンデらの研究からインプットと知識に基づいて独自のモデルを開発し、長年に渡って『Agile Press』がそれをすべての経験主義の基礎と仮定してきたことは明らかではないか」と提起した。

私は、ケンに「スクラムが解釈や独自のモデルを持つことは全く問題ない。ただし、これは歴史的に確立している科学的テキストではなく、スクラムで使われ、スクラムによって作られ、スクラムやおそらく他の文脈で役に立つモデルだということははっきりさせたい」と言った。私は結局のところPST（Professional Scrum Trainer）なので、事実を教えたいのだ。

これを読むまで、あなたは蒸気圧室について何もしなかったのではないだろうか。私は知らなかった。

経験主義の柱についての質問

デイブ・ウエスト（ケンが作ったScrum.orgのCEOで、私が仲間と呼んでいる人物の一人）は、私たち3人の間でのメールで、ケンに向けて、次のように付け加えた。

ケンは、実に賢い（とてもスマート）である。デイブも私も、ケンが歴史を説明してくれるのを聞いて学びを得た。

つまり、経験的プロセス制御は、私の知る限り、ツンデらの研究に由来しており、ケンとジェフがスクラムを作った時に適用し、そう名付けられたのだ。

この経験的プロセス制御の柱は、スクラムによる発明であり、元々は、可視化（Visibility）、 検査（Inspection）、 適応（Adaptation） ^{[2004, Beedle and Schwaber]}として知られ、後に透明性・検査・適応に変更された。上図にある信頼（TRUST）の基礎は、Scrum.orgが追加したもので、経験的モデルとアプローチを用いるためには、信頼が強い基礎が必要だからだ。

はっきりさせておきたいが、私はケンをプロパガンダ（事実の錯覚）として非難しているわけでない。彼は決して誰かを騙そうとしたわけではない。我々自身がそうやっていることなのだ。「Pillars of Empiricism」でググってみて自分の目で確かめてほしい。彼が信じ、複雑なプロダクト開発の助けになると期待したプロセスを作ろうとしただけなのだ。私たちの多くにとって、彼は成功したのだ。

スクラムは経験主義に基づいているのか？: その通りだ

スクラムは経験的モデルなのか？: 適用方法によるため、読んでみてほしい

3. 帰納・演繹・仮説・反復・累積・外適応

我々が行なっているスクラムの使い方は本当に帰納的なのだろうか、それとも単に反復と累積に演繹的な振る舞いを加えただけなのだろうか。

帰納法とは、「観察・計測・実験によって仮説を検証し、洗練させること」だと覚えておいてほしい。

ユーザーストーリーやそれに類するものは、仮説ではなく、確定しているものである。顧客として、何らかの知覚的な価値を得るために、ある特定のものが欲しいのだ。これが（受け入れ基準のリストを入れ込む）ときに行われることを知っている。我々はすでに望むアウトカムを決定しているのだ。

スプリントレビューでのフィードバックというのは、これを確認するためのもので、せいぜいいくつかの創発的な学習というところだ。つまりは、我々が偶然に何かを発見したとか、顧客が突然に新しいアイデアを思いついたとか、結局XやYは必要がなかったと気づいたとかだ。

スプリントレビューは、実際の顧客と一緒に行われることはほとんどなく、多くはプロダクトオーナーや同様の代表的な役割を担う人への「儀礼としてのプレゼンテーション」であるため、後者（何かを発見したとか、新しいアイデアを思いついたとか）はいずれにせよほとんど起こらないのだ。もし毎回のスプリントで実際の顧客が参加するならば、素晴らしいことをしている。

ユーザーストーリーやほとんどのPBI（Product Backlog Item）は、実験や仮説ではないのだ。それらは明確に定義された要件なのだ。それを実現する方法は、実験的、探索的かもしれないが、それを経験的と呼ぶには少し無理がある。つまり、ソフトウェアの場合、開発者はあるフィーチャーや機能をどのようにコーディングするかを考え、ラピッドプロトタイピングや小さな実験を行うかもしれないが、それは開発プロセスのすべてではなく、一部に経験的な要素があることを意味している。

家の所有者として、きれいに見えるように芝生を刈りたいとする。業者が所有者が決めたアウトカムを知っている（そして馬鹿げた受け入れ基準（A/C）を書くことだってできる）が、業者は、それを達成する方法をかなりよく考える。蛇や石にぶつかったり、草刈機が壊れたりするかもしれないが、それを解決するのは、経験的ではなく、創発的なものだ。刈り取られる草は既知のものであり、実験によって証明されるべき仮説ではない。もしトピアリー（訳注: 樹枝を動物・星・円錐などの形態に刈り込むこと）を望まれたらそれは経験的なことかもしれない😁

真の実験とは、技術的なスパイク（アイテムの調査）や、見つけるまで何が見つかるかわからない真のR&D（研究開発）だけかもしれない。我々はアイデア（仮説）を持ち、その仮説を検証するために実験を作成し、設計し、現時点では不確定な結論に達するのだ。簡単に言えば、我々はそれを知るまで、何をしっているかわからないのだ。あるいは、「何がわからないのか、わかるまでわからない」ということだろう。ともあれ、話がそれてしまった。

帰納法とは対照的に演繹法は、秩序ある世界での5つのなぜ分析で用いられる。我々は質問をして、「なぜなら」で答える。「なぜXが起きこったのか、なぜならY」というようにだ。それぞれの答えは、事実に基づいた答えである。演繹法については、アーサー・コナン・ドイル卿の著書を読むとよく理解できる。

十分な質問をして、事実に基づいた答えを得ることで、根本的な原因を推し量るのだ。実験をして、事実を明らかにすることもあるので、未知のものを解明するために帰納的になることもあるが、正直なところ、それほど一般的なことではない。大抵のことは知られているのだが、その時その時の探求者には知られていないだけかもしれない。知識がないからといって、その発見を経験的にすることはできないし、むしろ無駄な発見かもしれないため、他の人の研究を利用したり、誰かがすでに解決していないかどうかを調べる方がよいだろう。

私のトヨタ時代のヒントがある。5つのなぜ分析が有効かどうかを検証するために、「したがって（therefore）」を修飾語として用いるのだ。5つのなぜを逆から見て、それぞれの文の後に「したがって」XまたはYと言ってみるのだ。私が何年も前に作ったこのスライドをみてほしい。なぜを問うには「なぜなら（because）」を使い、なぜを確認するには「したがって（therefore）」を使うのだ。次のスライドが参考なるだろう。

実験は、アイデアのセッションで行われることもあるが、アイデアが思いついたときに実験を誘発することもあるだろう。例えば、COVIDに対処するために、今、どんなプロダクトを売ればいいだろうか（訳注: 本記事は2年前のCOVID -19発生時の記事）。それを知るために実験をしてみるのだ。事前にアウトカムを決められないが、何かを発見したい、理論を検証したい、というような実験をやってみるのだ。そして、アウトカムが確定した上で、反復して提供するモードに素速く移行するのだ。

作業をしているうちに発見されたからといって、それが経験的になるわけではない。創発と経験主義は違うのだ。創発とは、生み出されるということだ。何か他のことをすることによって何かを学べば、それは創発なのだ。仮説定義し、それを検証するために実験を行えば、それは帰納的（経験的）なものだ。偶然に発見されたアウトカムも創発的である。つまり、偶然に何かを発見した場合、「創発」が可能になるのだ。

外適応とは、進化生物学の用語で、自然淘汰によって作られた形質とは別の用途に使われるようになった形質を表す。現代社会では、本来意図していなかった用途に再利用されることを指す（調理が電子レンジ調理になったり、失敗した接着剤がポストイットになったり）。

仮説的推論とは、基本的に既知の情報から結論を導き出すことである。

ググってみた仮説的の例: 陪審員として初日に彼が有罪であると結論づけた。しかし、確信が持てない。ここでは、観察に基づいて意思決定を行ったが、それが正しい意思決定であるかどうか確信が持てないのだ。日々の意思決定もまた、仮説的推論の一例なのだ。

他の例としては、「雨が降れば、草が濡れる」「草が濡れていれば、雨が降ったに違いない

仮説的推論は、検証すべき仮説を形成するのに有効である。「もしかしたらの論理」とも呼ばれる。

つまり、仮説、帰納、演繹を行うのだ。その結果、創発と外適応ができるかもしれない。

もしあなたがソフトウェアを書いているのなら、これは何をすべきかを知っていること（理解）、それをどうやるのか（スキル）、アイデアを試すこと（帰納）、そして、問題を解決すること（演繹）の組み合わせであると付け加えておこう。

もし、何がほしいかわかっていても、どうすればいいのかわからず、そこに到達するためにいろいろと試すのであれば、それは経験的アプローチと言える。CV19の治療法/ワクチンを見つけることは間違いなく経験的アプローチであるが、演繹や仮説、外適応も用いている。これら全てが必要なのだ。あなたもそのはずだ。

4. 確定的な累積反復

経験主義とは、決定されたバックログアイテムに基づいて顧客のフィードバックに対応することはない。それは反復なのだ。経験主義とは、理論や未知のアウトカムについて実験し、何が起こるかをみて、次に何をすべきかを決定することである。プロジェクトにおけるほとんどのアウトカムは、計画的であり、予測可能であり、期待されるものなのだ。問題や予期せぬことが起こることを創発といい、創発的学習と呼ぶこともある。

私がみてきたスクラムが用いられる仕事の大半は、上記の確定的な累積反復の説明に合致している。つまり、理解されている要求リストを累積的な反復の方法で提供しているのだ。作業が完了するにつれ、我々の作業の蓄積を作り出し、できれば価値のある作業を作り出したいと思っている。

• 誰が何を望んでいるかに基づいて、自分が何をすべきかを知っている
• 実現するために、どんなツールやメソッドを使うかを決めている
• 作業を小さな塊に分割し、短時間に提供している
• フィードバックを得て、そのフィードバックに基づいて作業を微調整している
• 妥当性のある明確な要件を反復している

実際、スクラムにおけるほとんどの変更というのは、要件がうまく表現されていないこと、あるいは、何かを作ったがうまく機能しなかったことが原因なのだ。後者は、テストが不十分であったり、要件を理解していなかったりすることが原因であることが多い。そう、スキルの低さもだが、それはまた別の問題だ。

どうすればいいのかわからないものに対しては、実験をして解決する。このような実験は経験的なものである。ユーザー要件が経験的に基づくものであることは滅多にない。

顧客にとって、まったく未検証で未実証の漠然としたものなので、我々は、実験してもらい、その結果に基づいて本当に望んでいることを絞り込みたいと思うだろう。本当にそうなのか？

COVIDワクチンの調査は明確にされているが、それがいつ見つかるのか、どうやって作るのか、作れるのか、効果があるのか、誰もわからないのだ（訳注: 本記事は2年前のCOVID-19発生時のもの）。唯一の合格基準は「効果がある」、「安全である」だけだ。したがって、仮説と望ましいアウトカムがはっきりしているが、そこに至る道筋がはっきりしていない。だからこそ、現代科学の手法の中心には経験主義があるのだ。

5. 我々の実践は、スクラムフォールなのか、H20スクラムなのか、WAgileなのか

いや、そうではない。スクラムの重要な相違点は、各スプリントで完成した作業を提供しようとすることだ。実際、スクラムガイドには、「プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。」とある（訳注: スクラムガイド2017年版）。

従来のウォーターフォール型プロジェクトでは、完成されたフェーズで作業するが、完成されたフィーチャー、機能、能力ではない。最後までいかないとリリースできるものは何もない。これがスクラムの、いや、アジャイルの重要な差別化要因なのだ。経験的であるかどうかは全く関係がない。

最終的な考え

経験的理論や帰納的推論に基づいていることで、真に経験的な仕事を達成することができるが、スクラムの大部分は反復的で累積的なものになってしまっている。これはスクラムの問題ではない。スクラムは、経験的な作業を完全にサポートしているが、それを用いたくなかったり、そのように用いることができなかったりするのは、我々の問題なのだ。

問題は、ほとんどの組織がそれを経験的に用いることができないか、用いようとしないことだ。そして、反復的で累積的なアプローチになり、最悪の場合は、2週間のミニウォーターフォールプロジェクトや、あるサイクルでは3ヶ月プロジェクトになってしまう。ほとんどの作業は、ユーザー要件を短納期にまとめたものになる。これらは、アウトカムが未定義か不確定な実験ではないのだ。

また、スキルごとにチームが分かれていると、ウォーターフォール型の特徴であるチームからチームへの作業の「受け渡し」が発生し、さらに悪化していく。

スクラムは機能するが、ほとんどの企業は実際にスクラムを用いているわけではなく、用いていると言っているだけなのだ。また、この文中の「スクラム」という言葉を「アジャイル」という言葉に置き換えることもできるだろう。これは人的要因と結びついた組織設計の問題であり、もっと率直に言えば、リーダーシップのあり方の問題なのだ。