ケン・シュエーバーが意図的にスクラムから除外した項目
意図的にスクラムの一部とされていないものや、スクラムと矛盾するもの、またスクラムを役立たないものにしてしまうものを挙げてみます。
スクラム警察が来てあなたを牢屋に入れてしまうわけでもありませんし、意図的に何かを排除することに意味があるように思えないかもしれません。ところがスクラムに必要だという思い込みがあると、時に人は、意図せず、気にせずに行動してしまいます。下記のリストに挙げた一件一件について、どういった問題を解決しようとしているのか、そしてあなたのシステムの最適化目標にそった解決法があるのかどうか、考えてください。
以下は意図的にスクラムに含めなかった事柄です。
- デイリーステータスミーティング
- ベロシティ
- ストーリーポイント、フィボナッチ数列
- スクラムオブスクラム
- 一つのプロダクトに複数のプロダクトオーナー（例：チーム一つにつき、プロダクトオーナーひとり）
- プロダクトバックログ内のタスク
- チーフプロダクトオーナーやリリーストレインエンジニアといった余分な役割
- 運営レポートとしてのバーンダウンチャート（またはバーンダウンチャートそのもの）
- コーディネーター（調整役）、モーチベーター、または進捗報告者としてのスクラムマスター
- 監視ツールとしてのスプリントバックログ
- 単機能チーム
スクラムに当初意図されていたことは、フィードバックループを繋ぎ、仕事をコントロールしやすくするためのフレームワーク及びメタプロセスであることです。あなたが仕事で経験しているスクラムは、これらの意図から離れていったものである可能性が高いと考えられます。
スクラムにデイリーステータスミーティングは含まれない
ケン・シュエーバーは、スクラムガイドにこう記しました。
デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対す る進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは開発者のための15分のイベントである。開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 日の作業 の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、 自己管理を促進する。
もうおわかりですね。デイリースクラムを自己組織及び再計画のイベントとみなしていない会社では、デイリーステータスミーティングを、進捗報告するための「スタンドアップ」と呼ぶことになってしまいます。
スクラムにベロシティは含まれない
ケン・シュエーバーによるスクラムの定義には、ベロシティは含まれていません。ベロシティは時々、エクストリーム・プログラミングの手法から取り入れられることがあります。しかし、ベロシティの発案元であるエクストリーム・プログラミングの人たちさえ、今では後悔している有様です。このままベロシティを続けるべきなのでしょうか？私はそれよりも、プロダクトをいつでも出荷可能な状態にしておくことに集中すべきと考えます。ベロシティに焦点をあてるということは、部分的な最適化であり、これはビジネス成果に悪影響を及ぼします。詳しくは、https://seattlescrum.com/why-i-barely-mention-velocity-anymoreをご覧ください。
スクラムにストーリーポイントやフィボナッチ数列は含まれない
スクラムは、見積もり方法を指定していません。スクラムガイドも、見積もりについてはほとんど言及していません。
もちろん、相対見積もりが絶対見積もりよりも有益だとみなされる場合は少なくないでしょう。果てしなく続くフィボナッチ数列は本当に必要でしょうか？フィボナッチ数列に秘訣があると聞いて、それを鵜呑みにしてもよいのでしょうか？
二進数を理解する人は、2の冪（べき）で事足りるということに気づくでしょう。見積もりをする際に選択肢が三つを超えるならば、正確なふりをしている可能性が高いといえます。
スクラムに「スクラムオブスクラム」は含まれない
2001年に出版された最初のスクラム本には、「スクラムオブスクラム」についての記載がありました。それは、組織をアジャイルにする方法を誰も知らないという問題に投げつけられた急拵えの解決案でした。ところが2004年に、ケン・シュエーバーは２作目の著書中で「スクラムオブスクラム」は自己組織するチームと矛盾すると指摘しました。幸いにも、「スクラムオブスクラム」に代わる手法はあります。
スクラムには、一つのプロダクトにつき一人ののプロダクトオーナーしか存在しない
スクラムの定義にはこのように書かれています。
スクラムチームが⼤きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。
一つのプロダクトに複数のプロダクトオーナーが存在すると（例：チームごとに別々のプロダクトオーナー）、なぜ害になるのでしょうか。私のスクラム漫画 「スクラム導入後にアジリティが減少してしまう理由」 をご参照ください。
そもそも、プロダクトとは何を指すのでしょうか。全体像を捉えるには、現実的なプロダクトの定義を広げられるだけ広げたものを思い浮かべてください。
スクラムでは、プロダクトバックログ内にタスクは含まれない
スクラムの要点を得ているかどうかを判断するポイントの一つは、プロダクトバックログにタスクが含まれているか否かです。
スクラムは歴史的に何を(what)からどうやって(how)を引き離してきました。問題を解決する方法は、自己管理するクロスファンクショナルなチームに委ねられています。もしあなたのチームが「何を」から「どうやって」を引き離せないなら、そのチームはまだ自己管理ができずクロスファンクショナルでもない状態にあるということです。したがって、プロダクトバックログにあるアイテムは、「タスク」ではなくプロダクトバックログアイテム（PBIs）と呼ぶのが適切です。
プロダクトバックログアイテムを「タスク」ではなく「ユーザーストーリー」と呼んでも間違いではないかもしれませんが、「ユーザーストーリー」はさまざまなスクラムチームがエクストリームプログラミングから借りている考え方であるということを念頭に置いておいてください。プロダクトバックログアイテムをうまく作成する方法については、https://scrumtrainingseries.com/BacklogRefinementMeeting/ をご覧ください。
チームがスプリント計画中にスプリントタスクを作成しようとすることもあるかもしれません（スプリントタスクについては、https://scrumtrainingseries.com/SprintPlanningMeeting/をご参照ください）。スクラムでは、「どのように」についての決断を最後の最後まで引き伸ばします。
スクラムに余分な役割はない
一つのプロダクトにプロダクトオーナーは一人しかいないため、チーフプロダクトオーナーは存在しません。
「リリーストレインエンジニア」というものも存在しません。この役割が、適応性を低下させるのではなくむしろ向上させるようなやり方で、解決すべき問題を解決する方法はあるのでしょうか？作り上げた役割に責任を与えると、自己管理が不十分であまりクロスファンクショナルでもないチームが形成されることになってしまいます。
会社はよく、新しい役割や部署を作ったり構造や手順を新しくしたりして、組織をさらに複雑にすることで問題を解決しようとします。これらの試みには即効性はあるかもしれませんが、害が伴います。スクラムは、組織（会社）の複雑さをできるだけ減らすこと、そして根本的な問題解決に取り組むことを追求します。
スクラムにバーンダウンチャートは含まれない
2001年に出版されたスクラム本ではバーンダウンチャートが推奨されていました。しかし出版後ほどなく、バーンダウンチャートは見積もりや短期的な効果に焦点を当てすぎてチームの自己管理能力を下げかねないということがわかりました。複雑な仕事はニュートン力学に必ずしも当てはまらないということです。そのためバーンダウンチャートは、その後ずっとスクラムの定義から姿を消したままです。試しにバーンダウンチャートを使ってみると、それがなぜスクラムから姿を消したのかわかるはずです。
スクラムマスターはコーディネーター（調整役）やモーチベーター、または進捗報告者ではない
スクラムマスターはプロジェクトマネージャーの別名として考案されたものではありません。
調整
スクラムマスターは、調整はチームの責任であるということをチームに教える立場にあります。スクラムマスターが調整役になると、チームは自ら調整をする責任がないと学んでしまいます。
モチベーション（動機）
チームメンバーにモチベーションがなかったら、スクラムマスターが解決に向けて働きかけるべき組織的な障害物があると考えられます。健全な会社では、良い仕事をすること、そしてその仕事がいかに喜んでもらえるかということからモチベーションが生じます。（給料の支払いは生じます。）
進捗報告
アジャイルソフトウェア開発宣言の著者たちは、「動くソフトウェアこそが進捗の最も重要な尺度」 https://agilemanifesto.org/iso/ja/principles.htmlであると述べています 。スクラムにおいては、論理的であることより経験的であることに重きを置きます。スプリントレビューでは、プロダクトについてのレポートではなく、実際に動くプロダクトを全員が見ることになります。
スクラムマスターの責任についての詳細は、スクラムマスターチェックリスト をご覧ください。
監視ツールとしてのスプリントバックログ
スクラムの定義によると、
スプリントバックログは、開発者による、開発者のための計画である。
とあります。
マイクロソフト勤務の人が、ケン・シュエーバーに「なぜチームの自己管理作成物（例えばスプリントバックログのタスクボードやスプリントバーンダウンチャート）を社内全体に公開するべきではないのか」と質問していたのを耳にしたことがあります。スクラムで定義されている透明性が曲解されていることにお気づきでしょうか。ケンはまず、チームは自己組織するものである、と改めて明言しました。そして、どうしてチーム外の人間がそのチームのスプリント中に干渉したがるのか知りたいものだ、と付け加えました。
スプリントレビューは、仕事の結果をチーム外に見せる最適な機会です。チーム外からのフィードバックは、その時に歓迎されます。プロダクトオーナーはその後、フィードバックにどのように適応するか決定します。
スクラムには単機能チームは存在しない
1986年のハーバードビジネスレビューに掲載されたある文献は、クロスファンクショナル（機能横断型）チームの成果という魔法をもたらし、今日に至るまでスクラムガイドを通してスクラムに影響を与え続けています。著者の竹内弘高氏と野中郁次郎氏はこのように述べています。
Under the old approach, a product development process moved like a relay race, with one group of functional specialists passing the baton to the next group. Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.
過去のアプローチでは、プロダクト開発のプロセスはリレー競争のように進みました。機能スペシャリストの１グループがバトンを次のグループに渡す、とういう具合にです。 ラグビーのアプローチでは、プロダクト開発のプロセスは、メンバーが最初から最後まで協力する、多種分野にわたる厳選されたチームの絶え間ない相互作用から生まれます。1
クロスファンクショナル（機能横断型）チーム正反対の位置にあるのが単機能チームです。単機能チームは、組織や会社の至るところに存在します。
- 分析（要求の詳細を記述）
- コーディング（コーディングが仕事の大半を占めるが、テストは十分にしない）
- QA（テストのみ）
- インテグレーション（結合）
- 偽のDevOps（本物のDevOpsは多機能）
- プロダクト（プロダクトマネジメント）
- UX/UI
- サポート（ときに、サポート部がコントロール部になってしまうこともある）
- マーケティング
- アーキテクチャ
- リスク管理
- 情報セキュリティ
- メンテナンス
- オペレーション
- 消火活動
- その他諸々
世界にあるすべてのものが「スクラム」と呼ばれる必要はありません。 単機能チームまたは部署の存在は、必ずしも有害ではありません。 スクラムと呼ばれるものが生み出される前に、人間は何千年もの間仕事をこなしてきました。仕事の種類（特に物理的な依存関係）によっては、順次アプローチが必要になる場合があります。ケン・シュエーバーでさえも、以下のように記述しています。
If waterfall meets current needs, keep doing it.
ウォーターフォール開発や従来のプロジェクト管理が現在の状態に合っている場合は、引き続き使用してください。
しかし、単機能チーム（または部署）を「スクラム」チームと呼ぶことは矛盾です。 スクラムではないものにスクラム用語を使用する正当な理由はありますか？ ジョージオーウェルはこう記しました。
If thought corrupts language, language can also corrupt thought.
思考が言語を破壊する場合、言語も思考を破壊する可能性があります。
スクラム用語を乱用すると、スクラムが実際に何であるかを悟ることができなくなります。
裕福な方法論者になる方法
単機能チームの「プロダクトオーナー」2が、単機能チームに対応する方法論を発明したら私は大儲けすることができる、と話してきたことがあります。ケン・シュエイバー、竹内氏や野中氏は単機能チームの存在に気づいていないと思ったのでしょうか？スクラムは機能的な障害をおおい隠すのではなく、明らかにすることを目的としているのです。
2000年頃、従来の組織設計にまったく変更を加える必要がないように「調整」できるラショナル統一プロセス（RUP）と呼ばれるもので大金を稼ぐ人が出てきました。 もちろん、それは惨事でした。 アリスター・コーバーン （アジャイルソフトウェア開発宣言 の共著者）は明らかにRUPのファンではありませんでした。
I am interested in fending off the fat methodology army, the vast quantity of RUP, [Arthur] Anderson [now Accenture], SEI [Software Engineering Institute] salespeople putting ideas into CIOs’ minds that they should have lots of paperwork to be “safe”.
肥えた方法論者の大群や、膨大な量のRUP、そして[Arthur ] Anderson [now Accenture ]、SEI [Software Engineering Institute ]の営業担当者が吹き込もうする「安全」であるためには多くの事務処理が必要であるという考えからCIOたちを守ることが、私の目下の関心だ。
RUPの大暴走に一役買ったある人物は、RUPをSAFeと名付けて、巨大で根本的に不正なものに再パッケージ化しました。。まさに、「一度だまされたらだました者の恥、二度だまされたらだまされた者の恥」の一言に尽きます。
英語版（原文）は、 https://seattlescrum.com/things-ken-schwaber-intentionally-omits-from-scrum/にてご覧ください。
