チェンジ・マネジメント3.0の何が3.0なのか

最近、宣伝づいているようで恐縮なのですが（実際、宣伝なのですが）、先週末に達人出版会より"How to Change the World〜チェンジ・マネジメント3.0"がリリースされました。

おかげさまでみなさんにTwitterやブログでも取り上げていただき、翻訳者はじめ関係者一同、心より感謝しています。

ところで、この「3.0」ってなんなんでしょうか？

Management 3.0とChange Management 3.0

ご存知の通り、原書の著者であるJurgen Appelo氏は、"Management 3.0"の著者でもあります。チェンジ・マネジメント3.0は元々、"Management 3.0"の研修コースの一部（書籍の"Management 3.0"にはそれに相当する章はない）であり、それ故にその3.0を継承していると考えるのが妥当かと思っています。

Manaement 3.0とは

では、"Management 3.0"の3.0というのは何を示しているのでしょうか？
これは書籍の中に書かれています。また、このブログの過去エントリでもそこを引用しながら以下のように記しています。

著者はMANAGEMENT 1.0から3.0を以下のように定義しています。

Management 1.0 = Hierarchies
Management 2.0 = Fads
Management 3.0 = Complexity

要するに、1.0は階層型組織におけるトップダウン型（場合によっては科学的管理とかコマンド＆コントロールとも呼ばれる）のマネジメントであり、2.0は基本的な構造は1.0を引きずりながらその上にいろんなadd-onを載せたもの、そして3.0はこれまでとは全く違う複雑系の理論やホリスティックな考え方に基づくマネジメントであるということです。

扱っているのは複雑で適応的な社会システムを変える方法

つまり、本書が扱っているのも、CAS (Complex Adaptive System)なのです。それを表す文言も中にいくつか出て来ています。

我々はみんな、複雑な社会システムを変える方法を知りたいのだ。

社会システムのような複雑なものの振る舞いを変えるためには、チェンジ・マネジメントの４つの側面を理解する必要がある。

そして、それを全く新しい手法や考え方を持ち出すのではなく、その４つの側面に対応する既存の有名なモデルをラッピングする形のスーパーモデルで説明しようとするのが本書の真骨頂なのです。

「How to Change the World〜チェンジ・マネジメント3.0〜」が出ました！

３月末頃からユルユルと翻訳作業を進めてきた"How to Change the World"(Jurgen Appelo著)の日本語版を、昨日（7/13）無事に出版することができました。

本書は電子書籍版（PDF/EPUB）のみで、達人出版会さんのサイトから購入できます。

• How to Change the World 〜チェンジ・マネジメント3.0〜 - 達人出版会

この本との出会い

過去の関連記事は、こちら

• Always All Ways: [IT] Change Management 3.0
• Lulu.comで「世界を変える方法」を買ってみた - Always All Ways

著者のJurgenは、このブログでも再三取り上げている書籍「Management 3.0」を書いた人で、私が最も影響を受けた人物500人のうちの一人です。ご興味があれば是非、ダウンロードして目を通してみてください。

AgileとChange

アジャイル開発の現場においては、変化を抱擁し変化に適応していくことが求められます。そして、アジャイル開発の導入・適用においては、組織レベルでの変化やトランスフォーメーションが欠かせません。
そこでは、チェンジ・エージェントとして適切に振る舞える人が必要であり、優秀なチェンジ・エージェントになるために必要なことが80ページ足らずのコンパクトな小冊子にまとめられたのが"How to Change the World"です。

Fearless ChangeとHow to Change the World

Changeやチェンジ・エージェントというキーワードから、Linda Risingの"Fearless Change"を思い出された方もいらっしゃるかもしれません。そんな方は是非、無料でダウンロード可能な

• "Questions for Change Management 3.0"(pdf)

を併せてお読みになることをおすすめします。
その中にはチェンジ・エージェントが考えるべき問いが、"Fearless Change"のパターンとのリファレンス付きでリストアップされています。

謝辞

今回の翻訳に際しては、原著がそもそもJurgenの自費出版のような形だったこともあり、翻訳の許諾を得るために著者本人に直接コンタクトを取るところから始まりました。日本語版の出版を快諾してくれたJurgenをはじめ、共訳者の川口さん・吉羽さん、レビューをしてくださった原田さん・ナイスビアの永瀬さん・高江洲さん、契約面でお手伝いいただいたアギレルゴコンサルティングの谷口さん、達人出版会の髙橋さん、その他本書の出版に関わってくださったすべての人々に感謝です。

引き算で作る強い組織

なんか、id:kent4989さんの記事にかぶせて書くというのが続いて恐縮ですが、
アジャイル開発に求められる人材像に関する雑感 - 勘と経験と読経
を読んでまたいろいろと刺激を受けたので、いくつか考えたことをまとめておきたいと思います。

プラスアルファかマイナスアルファか？

id:kent4989さんいわく、

これまでの就職や就社では「賢い」ということが重視されてきたのだと考えているのだけど、これからは「賢いプラスアルファ」が必要ということなのだろうか。じゃあ、アルファの部分に入るのは何なのだろうか。

とのことですが、ここで引っかかった点がふたつあります。
「いやいや、もともと賢いだけじゃないさまざまな要素は求められてきていたでしょ？」っていうのがまず１点。そして、氏がプラスアルファの要素として挙げているのって、程度の差こそあれ、氏が冒頭で「PMの97本」や平鍋さんのブログをわざわざ引用している通り、幼稚園で当たり前のように必要とされるものだよね？というのがもう１点。（さらに言えば、この話ってわざわざアジャイル開発に限って言う話でもないよね？というのもありますがw。）

この２点から考えると、幼稚園で学んだことが実践できなくなってしまった要因（社会的通念や規範意識、あるいは「空気」といったもの？）をいかに取り除くか（何をマイナスアルファするか）の方が重要なのではないかというのが私の仮説です。

社会人基礎力と多様性

社会人基礎力についても同様です。
「企業や若者を取り巻く環境変化により」まず変わらなければいけないのは、「社会的基礎力」の一部を封じることで経済成長を実現してきた社会や企業のあり方ではないでしょうか？（よく言われるように「一度の失敗も許されないような環境を作っておいてチャレンジしろと言ったって……」というやつですよ。）
これは、以前のエントリにも書いた、

上で述べたように、自己組織化というのはそれ自体が太古の昔からあるもので、そもそもそっちの方がデフォルトであるとも言えます。ただそれ自体に良い/悪いという概念がないため、道徳・社会規範・ビジネス価値などの視点から有用な方向付けを行うために生まれたのがCommand and Control型のマネジメントや組織であると考えられます。
しかしながら、世の中のComplexityに対応していくためにはそれでは難しいということで、自己組織化が改めて見直されているというのがアジャイル開発への流れの中で見られる現象です。
But...Self-Organization Is Not Enough: 自己組織化チームに関する誤解とマネージャの役割 - Always All Ways

と似た構造に私には見えます。

そしてもうひとつ大事なのは、「社会的基礎力」とはすべての人が等しくバランスよくすべての能力を持つ必要もないし、そこには人それぞれの特徴をいかした「多様性」があってよいだろうということです。（多様性とは社会的基礎力のバラツキのことである、と言ったら言い過ぎでしょうか。）そして、チームや組織における「多様性」こそがイノベーションを生み出す力になるのではないだろうかと思うわけです。

育成の観点から

まぁ、そうは言っても、「幼稚園で学んだこと」や「社会的基礎力」を封じてきた障壁を取り除くだけで、うまくその力が発揮できるかというと、きっとそうではないでしょう。また、そういう「基礎力」を現実世界においてさまざまな「応用力」や「経験」と組み合わせて成果を出していくにはそれなりのトレーニングが必要でしょう。（幼稚園児を集めてきたら、アジャイル開発で素晴らしいシステムが構築できるというわけでもないですよね？）

逆に言えば、これこそがマネージャーの重要な役割の一つなのだと思います。

そのあたりについては、下記の参考記事でも書いているような

• 自己組織化のシステムを作ること（Development）、そのシステムを守ること（Protection）、そしてその方向付けをすること（Direction）
• 「経験から学ぶ力」を高める仕組みを組織の活動に組み入れて行くこと

など、マネージャーが意識して取り組むべきことがいろいろ考えられると私自身は思っています。

ここでも「人ではなくシステム（系）をマネージせよ」（Manage the System, Not the People）というのが通用すると思います。

参考記事

• 経験学習とプロジェクトマネージャの育成 - Always All Ways
• But...Self-Organization Is Not Enough: 自己組織化チームに関する誤解とマネージャの役割 - Always All Ways

個人のふるい落としかマネージャーのシフトか

記事の最後でid:kent4989さんは、以下のような見解（危惧）を示されています。

しかし「コミュニティ適応性」でも「情熱」でも「社会人基礎力」でも、何かのトレーニングで簡単に獲得できるようなものではないのが気になるところ。このところ大手サプライヤーでも人材転換の話題が出ているが、これで自社人材に簡単にプラスアルファの力がつくとは思えない。ハードルを上げてふるい落とすといった方向となってしまうのではないだろうか。

もし、実際にそういうことになるのであれば、その企業・組織は力を失っていく一方なのではないかと私は思います。

私が上で述べたような仮説の上に立つならば、やるべきことは新たな能力やスキルを身につけるためのプラスアルファの方策やそれに基づくメンバーのふるい落としではなく、マネジメントの弊害を取り除き、メンバーのマインドセットの変革を促す引き算の施策なのではないでしょうか？

• 工業化を中心とした高度成長時代から続く旧来の思考によるマネジメントの弊害を取り除くこと
• そこで解き放ったメンバーのマインドセットを適切にガイドするチェンジ・エージェントの育成

そして、そこで読むべき本で言えば、個々人レベルでの「自己啓発本」のような話ではなくて、例えば、"Switch"や"Fearless Change"、"Leading Change"、"Influencer"などにより近い話なのではないかという気がしています。

Switch: How to Change Things When Change Is Hard

Fearless Change: Patterns for Introducing New Ideas

Leading Change

Influencer: The Power to Change Anything

社会的必然性としてのアジャイル

今朝、巷でちょっと盛り上がっていたやつに私も乗っかっておきます（笑）。
# 最初は乗っかるつもりはなかったのですが、読めば読むほど味わい深いので、私なりの解釈や思うところを書き記しておきたいと思った次第です。
# 元記事の著者お二人の意図に反した解釈を勝手にしている部分もあるかもしれませんが、あくまで私なりの解釈とそれらについての個人的見解とご理解くださいね。

元記事ふたつ

• ウォーターフォールのほうが楽だという話 - 勘と経験と読経
• ウォーターフォールの方が楽ですか？ | Ryuzee.com

著者のお二人は個人的にもお付き合いがありどちらも尊敬している人です。ユーモアまじりの記事の中でそれぞれの視点や考え方が出ていて興味深く読みました。
まず、両記事を読んで私が感じたのは、（おそらくお二方も承知の上で敢えて書かれているのだと思いますが）

• 「どちらが楽か」というのは、PMやコーチとしてメンバーのメンタルモデルに思いを巡らすのは有用かつ必要なことだとは思うけれども、「問い」の立て方としてはあまり筋のよいものではないな。

ということです。
とは言え、これはこれでいろいろ考えるきっかけにはなりました。

社会的必然性としてのアジャイル

そんな中で、この一連の話の中で何か一つだけポイントとなる箇所を選べと言われたら、私は迷わずRyuzeeさんの記事の以下の部分を挙げると思います。

ちなみに、工場でのものづくりにおいて、少ない品種の大量生産から多品種少量生産に変わったのは、社会的必然性があったからで、ウォーターフォールからアジャイルへの流れも社会的必然性と僕は捉えている。

さらに言えば、これは単にソフトウェアやシステム開発の話にとどまらず、経営全体の話の中で認識しておくべきことかと思います。（そのあたりが、このブログの過去記事の経営にとってのアジャイルだとかエンタープライズ・アジリティについて考えるシリーズとかにつながるものと考えます。）

で、本当にそうなのか？
というのをビジュアルに示しているのが、Steve Denningがよく使っているこのグラフたちです。

(Source: How Do You Explain Radical Management (Or Agile) To A CFO? - Forbes)

マネジメント手法との因果関係は明確でないし、結果からサンプルを作為的に抽出しすぎではないかとの批判もあるかと思いますが、Steveの言うところのRadical Management（システム開発におけるアジャイルに相当）を採用する企業と従来型から転換できなかった企業の株価を見れば、歴然でしょ？というグラフです。

コミットメントや最大限の努力に関する誤解

あと、これはその後のtwitter上でのやりとりでも議論されていましたが、まだまだコミットメントとか最大限の努力についての誤解が多いのかな、という印象です。
そのあたりの解説は、id:kent4989さんの方の記事でも引用されている

• [Agile]コミットメントとは何か？ | Ryuzee.com

を落ち着いて読めばRyuzeeさんの言わんとしている真意は誤解なく伝わると思うのですが、なかなか難しいのですかね？
ちなみに、私の昔のブログでも

• Always All Ways: [IT] Ryuzeeさんに講演してもらった 〜Scrumと組織〜

という記事の中でコミットメントに対する考え方を書いています。

向き不向きの話で終わらせてよいのか？

話を元に戻しますが、もう一つ興味深いのは、Ryuzeeさんの記事の書き方として

• XXな場合はウォーターフォールの方が楽かもしれない
• ○○な人はウォーターフォールの方が楽かもしれない

となっているところの読み方です。
Ryuzeeさんが意図されているかどうかわかりませんが、私にはこれが「ダメな顧客、ダメな開発者・開発チーム大集合のリスト」に見えてしょうがないのです。
もちろん、商品・サービスの特性や組織の文脈によってそこでのプロセスや方法論に向き不向きがあるとは思います。が、それを「うちはこういう組織でこういう商売なんだから、これでいい」と考えるのか「社会の変化などを考えると、そもそもこういう組織だったりこういう商品やサービスを提供していること自体がマズいのではないか？」というところまで踏み込んで考えられるのかは大きな違いだと思います。
そして、それを考えることこそが、「社会的必然性としてのアジャイル」や「エンタープライズ・アジリティ」を考えることに他ならないのではないでしょうか。（誤解のないように言っておきますと、なにも「アジャイル開発が向かないような組織は会社としてももうダメだ」などという暴言を吐くつもりはないですからね。ただ組織の文脈ありきで向き不向きを判断するのではなくもう一歩踏み込んで考えてみてもいいのでは？という話です。）

エンタープライズ・アジリティについて考える (3)

「エンタープライズ・アジリティについて考える」シリーズの第３回です。
過去の記事はこちら。

• Always All Ways: [IT] エンタープライズ・アジリティについて考える (1)
• エンタープライズ・アジリティについて考える (2) - Always All Ways

過去２回では、エンタープライズあるいはエンタープライズ・アジャイルといったものをどういう範囲で捉えるか、どう定義して考えるかというような話をしました。今回からそろそろ本題に入りたいと思います。とは言え、このシリーズは明確な全体構想やストーリーがあって書いているわけではありません。相変わらず、思いついたところや書きたいところから順不同に書いていますが、ご容赦ください。

組織レベルでの３つの大きなTransformation

情報システム開発や製品開発におけるアジャイルな組織への転換においても、メンタルモデルというかマインドセットというかをはじめとして、さまざまな意識の転換が必要です。（このあたりは、Ryuzeeさんもいろんなところで語られています。例えば、Agileな開発からAgileな組織へ（Agile Japan 2012）#aj12 | Ryuzee.com。）

それとも重なるところは多いですが、特にエンタープライズレベルでの事業活動全体を視野に入れた場合、以下の3つについてどう考え、取り組んでいくかというのがキーになってくるような気がしています。

• Project vs. Product
• Project Culture vs. Team Culture
• Cost Accounting vs. Throughput Accounting

Project ≠ Product

ご存知の通り、ScrumではProduct Ownerというロールがあります。Project Ownerではなく、Product Ownerです。そのため、「Scrumって製品開発には向いてるけど、エンタープライズ系の業務システムとかには向いてないよね」とかそんな話もちらほら聞こえたりもしますね。まぁ、ここで言葉の定義であれこれ議論するのは本質ではないと思いますので深追いはしませんが、今後「エンタープライズ・アジリティ」について考えていく上で意識しておきたい点のみ、少し解説しておきます。（これは、先週Mary Poppendieckから聴いた話が元ネタです。）

Maryが言っていたことを一言でまとめると「プロジェクトとプロダクトではFunding Model（資金調達・予算確保のやり方）が違う。それを変えないとうまくいかない。」ということです。プロジェクトは事前に全体予算を決めるバッチ・ファンディングであるのに対して、プロダクトはインクリメンタル・ファンディングである、と。
その他そこから派生する違いとしては、「タスクを管理する⇔ワークフローを管理する」「終わりがある⇔終わりがない」「プロジェクトチームは解散する⇔プロダクトチームは製品とともに存続する」などがあります。ここを意識してどう組織を考えていくか、製品開発/システム開発部門以外の人たちとどうコミュニケーションをとっていくかというのが重要かと思います。

プロジェクト文化とチーム文化

これも上の話（特に最後のあたりの「プロダクトチームは製品とともに存続する」）と幾分重なるところもありますが、とても大事な話です。これに関しては、Tobias Mayer氏が昨日、素敵なブログ記事を書いています。

• Team Culture, Project Culture -Agile Anarchy-

この中で彼は、プロジェクト中心のマインドセットを持っている限り、Scrumは最適なソリューションとはなり得ないと言っています。彼の話はいつも割と極端な方に振れる傾向がありますが、考えさせられる点は多いのでぜひ原文を通読していただきたいと思います。

なお、一昨日のエントリ（プロジェクト向きのアジャイル開発手法：DSDM - Always All Ways）で紹介したDSDMはプロジェクト向きでPRINCE2などとも相性がよいらしいと噂には聞いていますので、もしプロジェクト文化のもとでアジャイルを取り入れていくのならば、そちらを検討してみるのもいいかもしれません。（私はまったく不勉強につき、何もコメントできませんが。）

いずれにしても、自分たちがやろうとしていることがどういう文化やマインドセットを前提としているのかというのは、自分たちで理解しておく必要があると思いますし、エンタープライズ全体を巻き込みたいなら、その前提をきちんと説明し理解してもらう必要があります。

コスト会計よりスループット会計

最後は、以前のエントリ（経営にとってのアジャイル（または最近のSteve Denningの記事がツボにはまるという話） - Always All Ways）で紹介したSteve Denningの記事にあった話です。
エンタープライズ・アジリティを高めるためには、事業の意思決定の仕方およびそのベースとなる財務・会計の考え方の変革を伴わねばなりません。既にCFOを含む経営陣がスループット会計のような考え方になじんでおり、それをもとに意思決定をしているならば、それほど大きな苦労もなくアジャイル開発の考え方も受け入れられるでしょう。逆にそうでない場合には、２つの選択肢があります。CFOや経営陣の考えを変えてもらうか、今の考え方のままで理解できるようなモデルで説明するか、です。
とりあえずアジャイル開発を導入・展開するためだけであればどちらのやり方をとってもいいのでしょうが、やはり「エンタープライズ・アジリティ」ということを標榜したいのであれば、会社の意思決定の考え方・財務/会計の考え方の変革を迫っていく必要があるように思います。そこで本当にスループット会計がいいのか、もっと別のよいものがあるのかわかりませんけれども。
かくいう私もスループット会計なんかはゴールドラット博士の本で出てきてたなぁ…くらいのあやふやな理解ですので、改めて勉強してみたいと思います。

まとめ

今回も、なんとなく書き散らかしている感が満載ですね。
いずれにしても、アジャイル開発ってなんのためにやってるんだ？という目的と、その目的のために何が最適なのかを考えていくと、上の３点についてエンタープライズレベルで認識を合わせたり変革を進めたりということが必要なんだろうと思います。

ザ・ゴール ― 企業の究極の目的とは何か

経営にとってのアジャイル（または最近のSteve Denningの記事がツボにはまるという話）

このブログでも今まで、アジャイル開発におけるマネジメントやマネージャーの役割について何回か取り上げてきました。が、今までのはそれでもまだ、どちらかというと「現場より」のマネジメントの話でした。（会社の役職で言えば課長から部長くらいのイメージですかね。）

で、もう少し上のいわゆる役員以上くらいをイメージした時に、どうやってアジャイル開発を説明していくかとか売り込んでいくか、あるいはその層をどうやって味方にしていくかという課題に関して、最近のSteve Denningが書いているものが結構ツボにはまる内容なので、注目記事をいくつかセレクトして簡単にご紹介しておきたいと思います。

地球上で最も守られている経営の秘法：アジャイル

まず、割と新しいところで最もインパクトのあった記事がこちらです。

• The Best-Kept Management Secret On The Planet: Agile - Forbes

この記事は、掲載されてすぐにTwitterでも欧米のアジャイル界隈では結構話題になったので読まれた方も多いかと思います。（日本のアジャイル界隈ではあまり話題にならなかったような気もしますが…）

この中では、いくつかの過去の例を出しながら、画期的な新しいやり方が期待されていないところから生まれてきた場合、それが認められるまでに時間がかかるということを示しています。そして、アジャイルについても、本来、経営的に見てもすごいことであるにもかかわらず、それがソフトウェア開発というギークなところから出てきたために、いわゆるマネジメント関連の書籍でも正面から取り上げられることが少なく、過小評価されていると述べています。

なお、この記事の中では、マネジメントの書籍で珍しくアジャイルについてきちんと言及しているものとして、Mark Addlesonの"Beyond Management: Taking Charge at Work"を紹介しています。

なぜCxOはアジャイルを理解できないのか？

それに続く一番新しい記事としては、

• Why Can't The C-Suite Grasp Agile Management? - Forbes

があります。
C-suiteというのは、時々CxOとも表されますが、CEOやCOO、CFO、CIOなどのいわゆる「チーフなんちゃらオフィサー」と称される経営幹部のことですね。そういう経営幹部がなぜアジャイルを理解できないのか、という話。

記事は、"Leadership in a Wiki World: Leveraging Collective Knowledge To Make the Leap To Extraordinary Performance"の著者であるRod Collinsとの対談形式となっていて読みやすいです。

アジャイルの財務インパクト

もう一つ、去年の記事になってしまいますが、財務的な効果やインパクトに着目した記事がこちら。

• How Do You Explain Radical Management (Or Agile) To A CFO? - Forbes

Cost AccountingとThroughput Accountingの話、そして聞き手に合わせてどういうストーリーを組み立てるのがよいのかなど、とても勉強になります。

日本では

日本でも、たとえば昨年出版された「日本企業にいま大切なこと」（野中郁次郎・遠藤功）でスクラムが取り上げられていたりもして、アジャイル開発あるいはアジャイル・マネジメントといったものが経営幹部層にもリーチしていっているのではないかと思います。というか、この領域はまさに諸外国にさきがけて日本がリードしていかねばならないのではないかな、と思います。

The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century

Beyond Management: Taking Charge at Work

Leadership in a Wiki World: Leveraging Collective Knowledge to Make the Leap to Extraordinary Performance

日本企業にいま大切なこと (PHP新書)

"How"の質問に答えてはいけない

先週は、リーンソフトウェア開発のポッペンディーク夫妻（メアリーとトム）が来日していました。幸運なことに私も、

• 月曜日はリーダーシップ・ワークショップの一日目に出て〜とんかつ食べに行って〜
• 火曜日はリーダーシップ・ワークショップの二日目に出て〜しゃぶしゃぶ食べに行って〜
• 水曜日はSECセミナーでの午前中の講演を聴いて〜
• 金曜日は夫妻を囲む会でミニレクチャー聴いて懇親会で飲んで〜

という形でいろいろと直接お話をする機会を得ることができました。

本当は、「メアリーから学んだ５つのこと」みたいなタイトルでまとめてみたかったのですが、なかなかうまくまとまりそうにないので、以前のエントリとも絡めて一つだけ書いておきたいと思います。

Don't answer questions

これは、以前のエントリ（Scrumを教えるのに最適なフレームワークはScrum - Always All Ways）で紹介したTobiasのブログに出てくる５つの「やってはいけない」の４番目の項目です。
今からふりかえってみれば、メアリーのワークショップではまさにこの５箇条がしっかり守られていたように感じます。そしてその中でも、この４番目の「質問には答えてはいけない」というのは非常に強く意識されているように思いました。（意識されているというよりは、むしろ身体に染み付いて無意識の習慣になっているのかもしれません。）

Especially don't answer "How" questions

もちろん、彼女は質問も受け付けずに突き放していたというわけではないですよ。誤解を避けるために、Tobiasのブログから該当部分を抜粋しておきたいと思います。

Especially don't answer "How" questions [ref]. These are usually asked as challenges, and attempting to answer them will likely lead to positioning and entrenchment. Instead of offering answers, whether from intuition or experience, seek instead a better question—there is almost always one or more of those lurking below the surface. A classic example is the "How do we manage bugs in Scrum?" question. This is not a useful question, a better one being "Why do we have bugs?" [ref].
Top 5 Scrum Workshop Dont's

ここでのポイントは、

• 特に"How"を問う質問には答えるな。
• 代わりに、よりよい質問を探しなさい。

ということですね。
古典的な例として挙がっているのは、「Scrumではバグをどう管理するのか？」という問いに答えるのではなく「なぜバグが発生するのか？」と問いかけなさい、というやつです。

信念と自信に裏付けられた質問

こういう話をすると、たまに「質問をはぐらかしている」とか「問題をすりかえている」と思う人もいるかもしれませんが、今回のメアリーの話で少しもそういう印象にはならなかったのは、やはり彼女の言葉が信念と自信に裏付けられていて、彼女が質問を言い換えてくれることで我々自身が本当に考えて取り組むべき課題に目を向けさせてくれたからだと思います。
懇親会の席でとある参加者の質問を通訳してメアリーに投げかけたのですが、そこへのメアリーの回答を聞いたその方がtwitterで「涙が出てきた」「魂が震えた」と書かれていたのが印象的でした。