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

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

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

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

関連記事

我慢することの難しさ

もうずいぶん前の感じがしますが…2009年1月に納品したプロジェクトで、私が感じたことの1つに「自分には我慢が足りないなぁ」があります。 そのエントリにも書いていましたが、PJメンバーにいた新人と若手 …

インプットとアウトプットのバランス

仕事ではインプットに対してどのようなアウトプット(成果物)を出すかが大事です。 一握りの創造性豊かな人以外にとって、そのアウトプットの元ネタとなるインプットが存在していることが大半です。 インプットは …

週次フリカエリ

最近、お客様への納品が終わったプロジェクトで採用した「プチフリカエリ」について書きます。 (私の所属企業、かつ、知っている範囲では)「フリカエリ」は(大規模プロジェクトでは)工程の終了時、(小規模プロ …

できるだけ文字を打たないことでミスを少なくする

文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。 1つは前に書いた文章の揺らぎです。 もう1つは低レベルな話ですが「出来るだけ文字を打たない」ことです。 …

ドキュメント修正の大事さ

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。 言いたいこと 仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコード …

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