ギルドワークスの 現場コーチ では、色々なクライアントの現場、チームのふりかえりに、アドバイザーやファシリテーターとして参加しています。
ふりかえりでは様々な手法、フレームワークを使いますが、代表的なものにKPT(Keep/Problem/Try)というものがあります。
KPTの解説は プロジェクトファシリテーション実践編 ふりかえりガイド をご覧ください。
そのKPTを用いたふりかえりをやっているチームを見ていると「KeepやProblemを深堀りして、次に活かせるTryを出すチーム」と「表面をなぞるだけになって浅いTryで止まってしまうチーム」があります。この違いの要因は色々ありますが、そのうちの1つである「Problemの深堀りの仕方」について書いてみます。
KeepやProblemにおける「なぜ?」の大事さ
KeepやProblemではなぜそれが起こったか?というのが大事になります。
例えば「前倒しで納品できた」というKeepがあがったとします。これ自体は良いこと(Good)ではありますが事象に過ぎません。なぜ「前倒しできたのか?」の理由を導き出してノウハウ、習慣にしないと今後に活かすことは難しいでしょう。
同じくProblemに対しても「なぜ、こうなったのか?」を考えないと表面的な原因にとどまってしまいがちです。
ですので、正攻法としては「なんでなんで?」と理由を深堀りしていく質問をしていくのですが、これは言い方やその場の雰囲気によっては、詰問しているようになってしまいます(悪気はなくても)。実際にこのように聞かれることで「そんな、なんでばかり言われても…」と萎縮してしまい、本来言いたかった意見や考えを言わないようになってしまうこともあります。
このような場合の質問の仕方は色々工夫の余地がありますが、 「タイムスリップして、もう一度やり直せるとしたらどうします?同じアクションをします?それとも違うことをします?」 という聞き方を時々します。そしてその違うアクションをするという話になった時にそこに対して「それはなぜそう思いました?」という風に入っていきます。
「あくまでタイムスリップしたら…」という仮説の話なので、(起こってしまった事実に対する「なぜ?」とは違い)詰問されている感が弱くなる面もあるようです。
また、別の質問としては、他の人、チームに 「あなただったら(もしくはあなたのチームだったら)どうする?」 とも聞いたりします。こうすることでそのProblemを出してくれた当事者は他の人の意見を聞くことで改めて「自分だったらどうするかな?」をふりかえることもできます。
このような現場コーチを始めとして、ギルドワークスのやっていることに興味を持たれた方はお気軽に 【ギルドワークスに依頼する】 をご覧の上、 お問合せ ください。
この記事もどうですか?
-
isNotSummer()よりisSummer()だよね
ギルドワークスの増田です。 前回 if文の条件式の書き方あれこれ に書いた内容の続編です。 if文の条件式で論理演算式をべた書きしていた部分を、メソッドに抽出し、さらに、そのメソッドを、演算対象のデータを持つServiceDateクラスに移…
-
CenterではなくCoreを探し駆動していく 〜人間中心設計についてもう一度考えてみた〜
ギルドワークスの佐々木です。 私はエンジニアですが、バックグラウンドとして 人間中心設計 (Human Centered Design:HCD)を学んできました。このエントリーでは、このHCDを否定するわけではなく、もう一歩進めて、User…
-
「雪山」には一人では登れない、だからリアルなチームが必要②
前半 で市谷が語ったギルドワークスのスタンス。それを実現するためには一人では難しい。ではどんなチームで実現していくのか。ひきつづき市谷がインタビューに答えます。 クライアントとひとつのチームに -前半で伺った仕事のスタンス、仕事ができる人に…
- いきなり最強チーム