ギルドワークスの 現場コーチ では、色々なクライアントの現場、チームのふりかえりに、アドバイザーやファシリテーターとして参加しています。
ふりかえりでは様々な手法、フレームワークを使いますが、代表的なものにKPT(Keep/Problem/Try)というものがあります。
KPTの解説は プロジェクトファシリテーション実践編 ふりかえりガイド をご覧ください。
そのKPTを用いたふりかえりをやっているチームを見ていると「KeepやProblemを深堀りして、次に活かせるTryを出すチーム」と「表面をなぞるだけになって浅いTryで止まってしまうチーム」があります。この違いの要因は色々ありますが、そのうちの1つである「Problemの深堀りの仕方」について書いてみます。
KeepやProblemにおける「なぜ?」の大事さ
KeepやProblemではなぜそれが起こったか?というのが大事になります。
例えば「前倒しで納品できた」というKeepがあがったとします。これ自体は良いこと(Good)ではありますが事象に過ぎません。なぜ「前倒しできたのか?」の理由を導き出してノウハウ、習慣にしないと今後に活かすことは難しいでしょう。
同じくProblemに対しても「なぜ、こうなったのか?」を考えないと表面的な原因にとどまってしまいがちです。
ですので、正攻法としては「なんでなんで?」と理由を深堀りしていく質問をしていくのですが、これは言い方やその場の雰囲気によっては、詰問しているようになってしまいます(悪気はなくても)。実際にこのように聞かれることで「そんな、なんでばかり言われても…」と萎縮してしまい、本来言いたかった意見や考えを言わないようになってしまうこともあります。
このような場合の質問の仕方は色々工夫の余地がありますが、 「タイムスリップして、もう一度やり直せるとしたらどうします?同じアクションをします?それとも違うことをします?」 という聞き方を時々します。そしてその違うアクションをするという話になった時にそこに対して「それはなぜそう思いました?」という風に入っていきます。
「あくまでタイムスリップしたら…」という仮説の話なので、(起こってしまった事実に対する「なぜ?」とは違い)詰問されている感が弱くなる面もあるようです。
また、別の質問としては、他の人、チームに 「あなただったら(もしくはあなたのチームだったら)どうする?」 とも聞いたりします。こうすることでそのProblemを出してくれた当事者は他の人の意見を聞くことで改めて「自分だったらどうするかな?」をふりかえることもできます。
このような現場コーチを始めとして、ギルドワークスのやっていることに興味を持たれた方はお気軽に 【ギルドワークスに依頼する】 をご覧の上、 お問合せ ください。
この記事もどうですか?
-
プログラマなら「道具」に愛着を持とう
プログラマという仕事は、「職人」と例えられることが多いのではないかと思います。確かに、凄腕のプログラマの方の仕事に対する凄みは、熟練の職人を思わせるものが多いです。 そんな職人の方たちに共通していると感じるのが、「道具」への愛着です。例えば…
-
ギルドワークスに参加して、プロダクトづくりの価値観が変わりました 〜 ギルドメンバーインタビュー Vol.1 ソフトウェアエンジニア兼プロダクトオーナー見習い Takahashi Toshiaki 〜
ギルドワークスのなかにはいったいどんな人がいて、いま何を考えているのか…メンバーのリアルな姿をインタビューを通してお伝えします。 第一回目は、ソフトウェアエンジニア兼プロダクトオーナー見習いTakahashi Toshiakiが登場。時節柄…
-
ドメインモデル中心のアーキテクチャ
ギルドワークスの増田です。 河上さんが書いていた ヘキサゴナルアーキテクチャ に関連して、ドメインモデル中心のアーキテクチャについて考えてみます。 「ドメイン駆動設計」本のアーキテクチャへの疑問 私の設計の考え方は、6年ほど前に出会ったエリ…