ギルドワークスの 現場コーチ では、色々なクライアントの現場、チームのふりかえりに、アドバイザーやファシリテーターとして参加しています。
ふりかえりでは様々な手法、フレームワークを使いますが、代表的なものにKPT(Keep/Problem/Try)というものがあります。
KPTの解説は プロジェクトファシリテーション実践編 ふりかえりガイド をご覧ください。
そのKPTを用いたふりかえりをやっているチームを見ていると「KeepやProblemを深堀りして、次に活かせるTryを出すチーム」と「表面をなぞるだけになって浅いTryで止まってしまうチーム」があります。この違いの要因は色々ありますが、そのうちの1つである「Problemの深堀りの仕方」について書いてみます。
KeepやProblemにおける「なぜ?」の大事さ
KeepやProblemではなぜそれが起こったか?というのが大事になります。
例えば「前倒しで納品できた」というKeepがあがったとします。これ自体は良いこと(Good)ではありますが事象に過ぎません。なぜ「前倒しできたのか?」の理由を導き出してノウハウ、習慣にしないと今後に活かすことは難しいでしょう。
同じくProblemに対しても「なぜ、こうなったのか?」を考えないと表面的な原因にとどまってしまいがちです。
ですので、正攻法としては「なんでなんで?」と理由を深堀りしていく質問をしていくのですが、これは言い方やその場の雰囲気によっては、詰問しているようになってしまいます(悪気はなくても)。実際にこのように聞かれることで「そんな、なんでばかり言われても…」と萎縮してしまい、本来言いたかった意見や考えを言わないようになってしまうこともあります。
このような場合の質問の仕方は色々工夫の余地がありますが、 「タイムスリップして、もう一度やり直せるとしたらどうします?同じアクションをします?それとも違うことをします?」 という聞き方を時々します。そしてその違うアクションをするという話になった時にそこに対して「それはなぜそう思いました?」という風に入っていきます。
「あくまでタイムスリップしたら…」という仮説の話なので、(起こってしまった事実に対する「なぜ?」とは違い)詰問されている感が弱くなる面もあるようです。
また、別の質問としては、他の人、チームに 「あなただったら(もしくはあなたのチームだったら)どうする?」 とも聞いたりします。こうすることでそのProblemを出してくれた当事者は他の人の意見を聞くことで改めて「自分だったらどうするかな?」をふりかえることもできます。
このような現場コーチを始めとして、ギルドワークスのやっていることに興味を持たれた方はお気軽に 【ギルドワークスに依頼する】 をご覧の上、 お問合せ ください。
この記事もどうですか?
-
AWSクレデンシャルの漏洩を未然に防ぐgit-secrets
この記事は、 ギルドワークス アドベントカレンダー の10日目の記事です。 業務でAWSを触ることもあり、AWSクレデンシャル情報に触れる機会も増えてきました。 AWSアクセスキーの漏洩の話を聞くこともときどきあり、漏洩を未然に防ぐために …
-
GitHub最新人気リポジトリ【2018年版】
これは ギルドワークスイベントカレンダー 13日目の記事となります。 普段、仕事やプライベートで、何か新しい技術を学ぶ時、githubでサンプルコードを探して、手元で動かすということを行っています。 そこで今回は2018年も終わりに近づいて…
-
つたえるために意味を考え、名前をつける
Photo via VisualHunt ギルドワークスの佐々木です。 最近、ランディングページをRuby on Railsに組み込む仕事をよく行います。HTML/CSSで組んだマークアップを、haml( http://haml.info/…