Always All Ways

Apologies, Glances and Messed Up Chances

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

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

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

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

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

Don't answer questions

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

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で「涙が出てきた」「魂が震えた」と書かれていたのが印象的でした。