サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

Agile 仕事のやり方 改善 旧館より

フリカエリ

投稿日:2012年2月28日 更新日:


[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。

今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。
以下は、今のチームでやっている工夫や気づいたことです。

W(分かったこと)を書き出す

KPTに似たようなフレームワークで「YWT」というものがあります。
Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も・・・。

Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
それを「W(分かったこと)」として書き出します。
分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

日常的に書き出す仕組み

youRoomをコミュニケーションツールとして使っています。
そこにイテレーション開始時に”あらかじめ”フリカエリ用のスレッドを立てておきます。そして、日常の開発などで「あっ!これはPかも」「次はこんなこと(T)したいなぁ」と思えば、すぐに書き込むようにしています。

イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
早く対応した分だけ、チームのパフォーマンスが上がります。
なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

Problemの深掘り

これは最近やり始めたことです。

Pに対してTを書き出しますが、中には「本当にそれでPは解決する?もう少し深く話した方がいいのでは?」というものもあります。
例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。
こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。
(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな?」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

ProblemのTry以外にも、チャレンジしたいTryを書く

(Pとは関係なくても)「こんなことにチャレンジしたい!」という意味のTも書き出すようにしています。
そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

(サインアップのように)「自分がやりたい!」と手を挙げることで、その質やコミット感が強くなるのが良い点です。
Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
ですので、前向きにやる…とのが難しいこともあります。

それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

同じProblemが上がっていないかを見る

同じチームで何度かフリカエリをやっていると「あれ、これって前も同じようなPが上がっていなかったっけ?」というシーンが出てくることもあります。
同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか?を見るようにしています。
そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

気づき:暗黙知となったKは減っていく

同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。
新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。

このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。

大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか?ということです。
その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by Acarlos1000 on Visualhunt.com / CC BY

-Agile, 仕事のやり方, 改善, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

Javaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想]

仕事でJavaを使ってのシステム構築をしています。 勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。 で、思い立って以前に買って積読していた↓をちゃんと読んでみました。 ■( …

打合せ前に少しだけ調べておく

とある社内での打合せの席で思ったことです。 「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。 その打合せは部門も違い、お互い初対面でした。 ただ、事前に「○○さん …

発表資料に対する責任

関係者が順々にプレゼンしていくある会議での出来事です。 ある発表者が冒頭で「え~、これから××についてご説明いたします。が…この資料、私が書いたものでないので、詳細な質問はご容赦ください…」というよう …

「インセプションデッキ」ワークショップをやってみました

先日、社内で「インセプチョンデッキ」のワークショップをやってみました。 社内SNSでの募集期間が1週間も無かったのですが、10人強の方が参加してくれました。参加者の皆様、ありがとうございました。 イン …

教えてもらう、教える時に気をつけていること

仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。 ↓は自分が教える = 伝え手の場合に気をつけていることです。 1:論理や順序の飛躍をしない …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。